Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 74.125.82.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52B856B1.7090807@hortonworks.com>
References: <013BA16A-0673-438E-8001-B65662AEC2E7@gmail.com>
	<036EC86B-01B6-4110-A74E-E4B9A7D40354@apache.org>
	<2A3D82CE-DF7E-43C3-BE87-3C71277BA564@gmail.com>
	<CAAS6=7jc2bHJK_H14bRFEkuDhvfECKw7Qz3=aXuMBhQTuWHx1g@mail.gmail.com>
	<CA+nPnMxrp=Uvk40h1gVpNDhSwZHujsWgV4fG8O26biQQL+nvUQ@mail.gmail.com>
	<CAAS6=7i=KTZvAg7VVaC9eO-RDj7hT3Omco2887PHtV+fw=mmKQ@mail.gmail.com>
	<52B856B1.7090807@hortonworks.com>
Date: Mon, 23 Dec 2013 16:47:05 +0000
Message-ID: 
 <CAOGo0VbqnysAtq5dcet9rrNOaowQpwHFwhxw+L3ZFjQzTAY=2g@mail.gmail.com>
Subject: Re: LICENSE and NOTICE Role Models
From: sebb <sebbaz@gmail.com>
To: general@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On 23 December 2013 15:28, Kevin Minder <kevin.minder@hortonworks.com> wrote:
> I was thinking that the real problem is that each new project is forced to
> rediscover the right thing to do each time.  From my POV there really aren't
> that many licenses out there.  If there were just a wiki that said...
> 1) If you include source with X license, then Y must go in LICENSE and Z in
> NOTICE.
> 2) If you use a binary with X license, then Y must go in LICENSE and Z in
> NOTICE.
> As new or "one off" license are discovered the legal or whomever actually
> knows the rules adds to the wiki.
>

As far as LICENSE is concerned, the rule is simple, the full license
text must be provided with the bundle that includes the bits.
This can either be in the LICENSE file itself, or (generally better)
the file name should be noted in LICENSE.
Since 3rd party licenses may vary between versions, the LICENSE file
should state the product name *and version* for example:

"MegaCorp Foobar version 3.2.1 is included under license XYZ, see file
res/licenses/XYZ.txt"

A separate issue is whether the inclusion is allowed - but if it is,
the above applies.

For the NOTICE file the rule is also simple - it is for *required" notices only.
However, the problem here is that it is not always obvious what is required.
For some licenses, it is sufficient to have the license text.

I don't think a Wiki page is suitable as the formal documentation for
this however.
It needs to be part of the foundation website.

> On 12/22/13 10:08 PM, Marvin Humphrey wrote:
>>
>> On Wed, Dec 11, 2013 at 2:24 AM, Stephen Connolly
>> <stephen.alan.connolly@gmail.com> wrote:
>>
>>> It would be great if we could get a resolution on some of the JIRA's in
>>> legal, e.g.
>>>
>>> https://issues.apache.org/jira/browse/LEGAL-26
>>> https://issues.apache.org/jira/browse/LEGAL-27
>>> https://issues.apache.org/jira/browse/LEGAL-31
>>> https://issues.apache.org/jira/browse/LEGAL-136
>>
>> +1
>>
>> The continuing lack of clear resolution also impacts the Incubator.
>> Podlings
>> challenge us with "You say do X, but Apache Foo does Y -- where is it
>> documented that we have to do X?"  Then we go down the path of hunting up
>> Board member quotes and past threads on legal-discuss.
>>
>> It would make things easier on all Apache TLPs and Incubator podlings if
>> we
>> could get the following elements in sync:
>>
>> *   Apache Legal policy documentation.
>> *   http://www.apache.org/dev/licensing-howto.html
>> *   Maven's processes.
>> *   The actual LICENSE/NOTICE practices for the ASF's top ten or so most
>>      popular products.
>>
>>> The most critical one to the Maven PMC is LEGAL-26:
>>
>> Perhaps, though the way that Maven would implement LEGAL-26
>> (LICENSE/NOTICE in
>> svn) is impacted by LEGAL-27 (LICENSE/NOTICE must reference *only* bundled
>> dependencies).
>>
>> I'm not on the Legal Affairs committee, but I did write most of the
>> Licensing
>> How-To.  Come January, I'd like to do what I can to move the process
>> forward.
>> A lot of valuable developer time has been wasted over the years rehashing
>> these issues over and over again, and it's not like most developers relish
>> this stuff.  Clear policy documentation would be a valuable contribution
>> to
>> all of the Foundation's projects.
>>
>> Marvin Humphrey
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader of
> this message is not the intended recipient, you are hereby notified that any
> printing, copying, dissemination, distribution, disclosure or forwarding of
> this communication is strictly prohibited. If you have received this
> communication in error, please contact the sender immediately and delete it
> from your system. Thank You.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org