Return-Path: 
 <ooo-dev-return-7768-apmail-incubator-ooo-dev-archive=incubator.apache.org@incubator.apache.org>
X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org
Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id A16AA9ECE
	for <apmail-incubator-ooo-dev-archive@minotaur.apache.org>;
 Sun, 23 Oct 2011 13:56:57 +0000 (UTC)
Received: (qmail 3935 invoked by uid 500); 23 Oct 2011 13:56:57 -0000
Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org
Received: (qmail 3885 invoked by uid 500); 23 Oct 2011 13:56:57 -0000
Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:ooo-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:ooo-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:ooo-dev@incubator.apache.org>
List-Id: <ooo-dev.incubator.apache.org>
Reply-To: ooo-dev@incubator.apache.org
Delivered-To: mailing list ooo-dev@incubator.apache.org
Received: (qmail 3874 invoked by uid 99); 23 Oct 2011 13:56:57 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Oct 2011 13:56:57 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of robertburrelldonkin@gmail.com
 designates 209.85.161.175 as permitted sender)
Received: from [209.85.161.175] (HELO mail-gx0-f175.google.com)
 (209.85.161.175)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Oct 2011 13:56:49 +0000
Received: by ggnj1 with SMTP id j1so3410472ggn.6
        for <ooo-dev@incubator.apache.org>;
 Sun, 23 Oct 2011 06:56:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        bh=8+AmdTb0HPbdO9d6OeIb142DT9bt4bZ2WWX7TkjtkoE=;
        b=BOKekcTNve5lXuyhneR73rwlxw6/lhAb1fX6oet9pTH7iOxv1egUmL5xtp+j7G83Dp
         2BeoyW8eg7rAbdw0sa5H7TuxNQSRvyXfc7LiitsehbZMwdpPxSAghrX6qMvmKcQe5ii0
         s28w7Bt9trB7H0HTRTgKdq0+ZiBXXqIS9wjpI=
MIME-Version: 1.0
Received: by 10.236.124.97 with SMTP id w61mr29445399yhh.106.1319378188980;
 Sun, 23 Oct 2011 06:56:28 -0700 (PDT)
Received: by 10.236.44.99 with HTTP; Sun, 23 Oct 2011 06:56:28 -0700 (PDT)
In-Reply-To: 
 <CAP-ksoiv7XfRVR619kTVc3gJamBMk5B7XqL7bjmiwkW2+LUGyQ@mail.gmail.com>
References: 
 <CAP-ksog4_h6HOxpAAGfyG5s4TK_eJGAydc5PDPqoXg6g=RP-Lg@mail.gmail.com>
	<CAFG6u8EtyPhC2GOZq-03CqHFM0+qWTsKH1SmnqHjVyXF+pgOYQ@mail.gmail.com>
	<CAP-ksojddManaND2pgAi9PB-Mqiq1-2M+emNAcvWzt-JRkAxBA@mail.gmail.com>
	<CAKTa1miXTpPQG_1BxogBkDbvk5V=445tm8YyGmKHn=HTL7n4Cg@mail.gmail.com>
	<CAP-ksoiv7XfRVR619kTVc3gJamBMk5B7XqL7bjmiwkW2+LUGyQ@mail.gmail.com>
Date: Sun, 23 Oct 2011 14:56:28 +0100
Message-ID: 
 <CAKTa1mikMHvCyyiZAUBDSznA0gwEQqbaOiSVsbZ6x7S6qbpXxQ@mail.gmail.com>
Subject: Re: Clarification on treatment of "weak copyleft" components
From: Robert Burrell Donkin <robertburrelldonkin@gmail.com>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

On Sun, Oct 23, 2011 at 1:53 PM, Rob Weir <robweir@apache.org> wrote:

<snip>

>>> There is no intent to hoard. =A0From talking to developers on this
>>> project I get the sense that they want to upstream patches more than
>>> was done previously. =A0But contributing a patch is no guarantee that i=
t
>>> will be integrated by the other project in a timely manner. =A0Simply
>>> having it checked in by the 3rd party component, but not yet in their
>>> release, is also not optimal, for stability and supportability
>>> reasons. =A0Release schedules don't always sync up.
>>
>> Downstream packagers face similar issues and typically cope by
>> maintaining independent patch sets (applied at build time). Why not
>> just use patch sets?
>>
>
> That is what we do. =A0We store the original source in a tarball and
> then apply a patch at build time. =A0But we store both the source
> tarball and the patch on our servers.

Dependency managers frequently used elsewhere at Apache[1] typically
use meta-data to describe dependencies for location. Does the current
build system work in a similar way?

Robert

[1] eg http://ant.apache.org/ivy/ and http://maven.apache.org/