Return-Path: 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 4C4A59BD8 for ; Fri, 23 Mar 2012 17:10:17 +0000 (UTC) Received: (qmail 80149 invoked by uid 500); 23 Mar 2012 17:10:16 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 80085 invoked by uid 500); 23 Mar 2012 17:10:16 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 80076 invoked by uid 99); 23 Mar 2012 17:10:16 -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 17:10:16 +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; Fri, 23 Mar 2012 17:10:16 +0000 Received: by vcbfl13 with SMTP id fl13so3548595vcb.6 for ; Fri, 23 Mar 2012 10:10:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.12 with SMTP id d12mr4789572vdj.99.1332522615617; Fri, 23 Mar 2012 10:10:15 -0700 (PDT) Received: by 10.220.199.67 with HTTP; Fri, 23 Mar 2012 10:10:15 -0700 (PDT) In-Reply-To: <4F6CA02B.40508@apache.org> References: <4F6C5701.6060501@googlemail.com> <4F6C62DC.8010101@googlemail.com> <4F6C732C.4040004@googlemail.com> <4F6C7D1A.4010302@googlemail.com> <4F6C95CC.8030700@apache.org> <4F6CA02B.40508@apache.org> Date: Fri, 23 Mar 2012 13:10:15 -0400 Message-ID: Subject: Re: [RELEASE] NOTICE and LICENSE file From: Rob Weir To: ooo-dev@incubator.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 23, 2012 at 12:09 PM, Pedro Giffuni wrote: > On 03/23/12 10:47, Rob Weir wrote: >> >> On Fri, Mar 23, 2012 at 11:25 AM, Pedro Giffuni =C2=A0wr= ote: >>> >>> On 03/23/12 08:43, Rob Weir wrote: >>>> >>>> ... >>> >>> >>>> Further searching helps here ;-) >>>> I have found [4]: >>>> >>>> ... >>>> All the licenses on all the files to be included within a package shou= ld >>>> 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. >>>> ... >>>> >>>> Thus, I derive from this best practice that an identification of the >>>> files >>>> to which the mentioned license in the LICENSE file applies to should b= e >>>> 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 inclu= des >>>> 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= to >>>> 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.". =C2=A0That is perfectly accurate. > > > I noticed but you implied it when speaking of LICENSE_source > LICENSE_binary. > Our binary and source packages contain different code, with different licensees and different notice requirements. Of course it makes sense to think of these as different. The point about releases is that at Apache we're not just making applications available to users. We're making open source code available to other developers, to use as they wish. The source code package should not just be an after thought. It is an important part of what we're doing. And an important part is to make sure we get the LICENSE and NOTICE correct, and not mix up the source and binary package obligations. He help developers who use our code if we get this right. > >>> 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 > > > You really need to take a course on logic. > > >>> 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: =C2=A0Are there any additional obligations placed = on >> someone who redistributes our binary packages, based on the additional >> components included there? =C2=A0Does 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: > > > We include MPL already in the LICENSE (category B section). > This would be wrong if this is in our source package, since our source package does not include any MPL code. Remember,the binaries we have in our binary packages are just one of a wide spectrum of binaries that a developer could produce from our source package. With different choice of flags, they could exclude or include many different 3rd party OSS dependencies. So it is inaccurate and not-helpful for us to list the arbitrary choices from our binary packages, and assume that applies to everyone who builds from our source package. If we want to provide supplemental documentation that explains the required licence and notice implications based on each build flag, then that would be fine. But we should not assume a developer is making identical choices to us. > Even lawyers can distinguish if they are using binaries or source. > Per above, this is not a simple either/or alternative. Our source package only needs to cover the requirements of what our source package includes. It should not be guessing at what build flag the developer might enable or disable. However, our binary package should be explicit, since we know exactly what we built. > Pedro.