Return-Path: 
 <ooo-dev-return-7760-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 122149942
	for <apmail-incubator-ooo-dev-archive@minotaur.apache.org>;
 Sun, 23 Oct 2011 12:02:39 +0000 (UTC)
Received: (qmail 56224 invoked by uid 500); 23 Oct 2011 12:02:38 -0000
Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org
Received: (qmail 56179 invoked by uid 500); 23 Oct 2011 12:02:38 -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 56171 invoked by uid 99); 23 Oct 2011 12:02:38 -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 12:02:38 +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 12:02:31 +0000
Received: by ggnj1 with SMTP id j1so3376347ggn.6
        for <ooo-dev@incubator.apache.org>;
 Sun, 23 Oct 2011 05:02:11 -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=QzMTvD1/qDey/LK6k0x+TeRJ3yHY4YB7q0wv7kYeW+s=;
        b=ILloGHN8JNgOnDXqcqTVLc4kG1EyJf5VsJ/pnMxBb368Ko+zWEUZucJEi5pT5jgXoi
         UssyQksNWuPaju5yqQsibpZmDNiBdj7todJMxc2P8yqePCMaxiz8vUy4IUZmZ4hyK3XH
         +ZnzVAZMXDShJCqYrz7ztSAgW7VxD/M6/2/U4=
MIME-Version: 1.0
Received: by 10.236.186.34 with SMTP id v22mr9598195yhm.89.1319371330996; Sun,
 23 Oct 2011 05:02:10 -0700 (PDT)
Received: by 10.236.44.99 with HTTP; Sun, 23 Oct 2011 05:02:10 -0700 (PDT)
In-Reply-To: 
 <CAP-ksojddManaND2pgAi9PB-Mqiq1-2M+emNAcvWzt-JRkAxBA@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>
Date: Sun, 23 Oct 2011 13:02:10 +0100
Message-ID: 
 <CAKTa1miXTpPQG_1BxogBkDbvk5V=445tm8YyGmKHn=HTL7n4Cg@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 Thu, Oct 20, 2011 at 10:41 PM, Rob Weir <robweir@apache.org> wrote:
> On Thu, Oct 20, 2011 at 5:27 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>> On Tue, Oct 18, 2011 at 12:08 PM, Rob Weir <robweir@apache.org> wrote:

<snip>

>>> Now, for our SVN, we need to host the actual source of the MPL
>>> components, since we need to build the binaries on the platforms that
>>> we support. =A0And in several cases we have patches the original source=
.
>>> =A0Is this a problem?
>>
>> That normally is highly discouraged / not allowed.

Archiving the compressed source of weak copyleft dependencies in some
sort of repository[1] is something that Apache will need to become
comfortable with sometime soon

But developing downstream derivative works of weak copyleft
dependencies is likely to be a major issue

>> Why can't the patches be contributed back to the original projects?
>>
>
> 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 it
> 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?

Robert

[1] Many weak copyleft licenses require distributors to maintain the
code beyond the lifetime of the organisation which issued the original
license. We need to get used to the idea that Apache is likely to be
around much longer than commercial players.