Return-Path: 
 <ooo-dev-return-7614-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 C0A5774A5
	for <apmail-incubator-ooo-dev-archive@minotaur.apache.org>;
 Thu, 20 Oct 2011 20:01:01 +0000 (UTC)
Received: (qmail 9597 invoked by uid 500); 20 Oct 2011 20:01:01 -0000
Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org
Received: (qmail 9548 invoked by uid 500); 20 Oct 2011 20:01:01 -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 9540 invoked by uid 99); 20 Oct 2011 20:01:01 -0000
Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Oct 2011 20:01:01 +0000
Received: from localhost (HELO mail-vx0-f175.google.com) (127.0.0.1)
  (smtp-auth username robweir, mechanism plain)
  by minotaur.apache.org (qpsmtpd/0.29) with ESMTP;
 Thu, 20 Oct 2011 20:01:01 +0000
Received: by vcbf1 with SMTP id f1so3051636vcb.6
        for <ooo-dev@incubator.apache.org>;
 Thu, 20 Oct 2011 13:01:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.187.136 with SMTP id cw8mr848533vcb.266.1319140860107;
 Thu, 20 Oct 2011 13:01:00 -0700 (PDT)
Received: by 10.220.161.20 with HTTP; Thu, 20 Oct 2011 13:01:00 -0700 (PDT)
In-Reply-To: 
 <CAKTa1mju_+-sNG5KLECHw=eJF__BOJhMs6DeN8rh8zUJ9RnhGQ@mail.gmail.com>
References: 
 <CAKTa1mju_+-sNG5KLECHw=eJF__BOJhMs6DeN8rh8zUJ9RnhGQ@mail.gmail.com>
Date: Thu, 20 Oct 2011 16:01:00 -0400
Message-ID: 
 <CAP-ksoiC-kAhtAawc+anx0K84zhdty8J7oGZNjTLy40Wwc+S2A@mail.gmail.com>
Subject: Re: [licensing] On Apache Releases [WAS Re: Clarification on
 treatment of "weak copyleft" components]
From: Rob Weir <robweir@apache.org>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 20, 2011 at 9:06 AM, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
> <snip>
>
> On Tue, Oct 18, 2011 at 5:08 PM, Rob Weir <robweir@apache.org> wrote:
>>
>> I'm trying, with some difficulty, to interpret what we can do based on the description here:
>>
>> http://www.apache.org/legal/resolved.html#category-b
>>
>> How does this fit into a release strategy that has both source and
>> binary releases.
>
> Let me turn that around and start to answer "how can an appropriate
> release strategy be formulated that abides by these rules?" :-)
>

I can't really say yet, since some aspects of those rules are still
obscure to me.  But let's push ahead with the discussion, and
hopefully arrive at clarity.

> IMHO understanding the way Apache uses these terms is key
>
> At Apache, a "source release" is (just) what's in version control when
> the release is cut, is canonical and mandatory. Other artifacts follow
> the "binary release" rules, are optional and secondary.
>

OK.  So obviously no "weak" copyleft source files in our source
release, i.e., in our source tarballs.

What was not clear was what we meant, in regards to weak copyleft, by
"Software under the following licenses may be included in binary form
within an Apache product if the inclusion is appropriately labeled".

Does this mean:

A) We can include MPL binaries such as a JAR or a native code lib,
DLL. or object file in a source release?

or

B) We can include MPL binary code only in our binary releases?

When it says "In an Apache product" is that something different than a
release?  Is a source release a product?

> "Source releases" are aimed at downstream developers. Amongst this
> audience are downstream packagers. An important aim of the "source
> release" rules is to allow downstream developers to confidently create
> derivative works without excessive effort checking licenses.
>
> "Binary releases" are everything else, including artifacts containing
> source code in combination with other works.
>
>
> More explanation? Questions? Opinions? Comments? Objections?
>

I think it is important that downstream developers can take our source
releases and build them without:

1) "Excessive license checking" as you say,

2) But also without excessive downloading of scattered prerequisites
from all over the web

So there is some tension here, between what we include in the source
release, as a convenience to the developer, and what we specify as a
pre-req for them to download and provision on their own.

The approach we currently have for these components, in OpenOffice, is:

1) The 3rd party components are stored in a separate repository, not
with the core product's SVN.  So we reduce the opportunity for
contamination.

2) The build script downloads the source for these components and
compiles them.

So we avoid the pre-req/provisioning issue.  And we don't need to
include the MPL code in the source distribution.  It comes down
automatically at build time,

That may satisfy the letter of what I'm reading.  But I'd be
interested to hear what you think, whether something like that had
been done at Apache before.

Maybe it would be better, for example, to allow two build modes, one
with and one without the copyleft components, and force the downstream
developer to explicitly enable the compilation with weak copyleft
components by changing a flag or something?

-Rob

> Robert
>