Return-Path: 
 <ooo-dev-return-15414-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 D80069B57
	for <apmail-incubator-ooo-dev-archive@minotaur.apache.org>;
 Fri, 23 Mar 2012 15:47:50 +0000 (UTC)
Received: (qmail 98296 invoked by uid 500); 23 Mar 2012 15:47:50 -0000
Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org
Received: (qmail 98245 invoked by uid 500); 23 Mar 2012 15:47:50 -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 98236 invoked by uid 99); 23 Mar 2012 15:47:50 -0000
Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Mar 2012 15:47:50 +0000
Received: from localhost (HELO mail-vb0-f47.google.com) (127.0.0.1)
  (smtp-auth username robweir, mechanism plain)
  by minotaur.apache.org (qpsmtpd/0.29) with ESMTP;
 Fri, 23 Mar 2012 15:47:50 +0000
Received: by vbbfr13 with SMTP id fr13so1755962vbb.6
        for <ooo-dev@incubator.apache.org>;
 Fri, 23 Mar 2012 08:47:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.35.12 with SMTP id d12mr4681902vdj.99.1332517669112; Fri,
 23 Mar 2012 08:47:49 -0700 (PDT)
Received: by 10.220.199.67 with HTTP; Fri, 23 Mar 2012 08:47:49 -0700 (PDT)
In-Reply-To: <4F6C95CC.8030700@apache.org>
References: <4F6C5701.6060501@googlemail.com>
	<4F6C62DC.8010101@googlemail.com>
	<4F6C732C.4040004@googlemail.com>
	<4F6C7D1A.4010302@googlemail.com>
	<CAP-ksojd6zQ2iw3UXGWCquo3Z_CXuEA=3h0XaOQLxVJu5Qr-PA@mail.gmail.com>
	<4F6C95CC.8030700@apache.org>
Date: Fri, 23 Mar 2012 11:47:49 -0400
Message-ID: 
 <CAP-ksogtvGaByKYeA8MwO9enH8Uc672p8G-5dKd_OSE9Cxm5wA@mail.gmail.com>
Subject: Re: [RELEASE] NOTICE and LICENSE file
From: Rob Weir <robweir@apache.org>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 23, 2012 at 11:25 AM, Pedro Giffuni <pfg@apache.org> wrote:
> On 03/23/12 08:43, Rob Weir wrote:
>>
>> ...
>
>
>> Further searching helps here ;-)
>> I have found [4]:
>> <quote>
>> ...
>> All the licenses on all the files to be included within a package should
>> be
>> included in the LICENSE document. This LICENSE (courtesy of Apache HTTPD=
)
>> is
>> a good example. The Apache License is at the top of the LICENSE document=
.
>> After that, the license for each non-Apache licensed component is
>> included,
>> along with a clear explanation of which files that license applies to.
>> ...
>> </quote>
>> Thus, I derive from this best practice that an identification of the fil=
es
>> to which the mentioned license in the LICENSE file applies to should be
>> given.
>>
>> But note the further complexity with AOO, that we have binary as well
>> as source packages in our release. =C2=A0And our binary packages include=
s
>> 3rd party category-b libraries that are not included in our source
>> package. =C2=A0So we need to make this clear somehow in our LICENSE.
>>
>> Maybe we need a LICENCE_source and LICENCE_binary file in SVN that
>> contains the respective. =C2=A0Then we can rename or cat that together t=
o
>> produce the appropriate license for a package.
>
>
> This is not accurate.
>
> As I have mentioned tirelessly there is not such thing as a
> source release and a binary release, just a release. That
> means the one true LICENSE file includes all the source
> and binary components.
>

And again Pedro, I have not used the term "source release" or "binary
release". I said, "we have binary as well as source packages in our
release.".  That is perfectly accurate.

> Rob's statement is not exactly false because we have an
> exception in our release process as for the italian case
> (and so far only the italian case) we will be bundling GPLd
> dictionaries.
>

Not exactly false =3D=3D true

> Adding the GPL to our LICENSE file would be pretty
> confusing for our users, besides this is only for the
> italian case, so I think for that case having the GPL
> in the dictionary should be enough. Also, we should
> add a disclaimer that dictionaries (if included) don't
> constitute derivate works.
>
> All just IMHO, I won't block any attempt to automate
> the generation of those files, in fact, I think I'll just not
> touch those files anymore :).
>

Think of it this way:  Are there any additional obligations placed on
someone who redistributes our binary packages, based on the additional
components included there?  Does the ASF have any obligations, in
terms of required notices, etc., for the binaries we distribute?

Note, for example, clause 3.3 of the MPL 1.1:

"3.3. Description of Modifications.

You must cause all Covered Code to which You contribute to contain a
file documenting the changes You made to create that Covered Code and
the date of any change. You must include a prominent statement that
the Modification is derived, directly or indirectly, from Original
Code provided by the Initial Developer and including the name of the
Initial Developer in (a) the Source Code, and (b) in any notice in an
Executable version or related documentation in which You describe the
origin or ownership of the Covered Code. "

-Rob