Return-Path: X-Original-To: apmail-legal-discuss-archive@www.apache.org Delivered-To: apmail-legal-discuss-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3695B1023E for ; Wed, 11 Dec 2013 10:25:11 +0000 (UTC) Received: (qmail 9445 invoked by uid 500); 11 Dec 2013 10:25:09 -0000 Delivered-To: apmail-legal-discuss-archive@apache.org Received: (qmail 8726 invoked by uid 500); 11 Dec 2013 10:25:05 -0000 Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: Reply-To: legal-discuss@apache.org List-Id: Delivered-To: mailing list legal-discuss@apache.org Received: (qmail 8632 invoked by uid 99); 11 Dec 2013 10:25:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Dec 2013 10:25:01 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of stephen.alan.connolly@gmail.com designates 209.85.160.43 as permitted sender) Received: from [209.85.160.43] (HELO mail-pb0-f43.google.com) (209.85.160.43) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Dec 2013 10:24:55 +0000 Received: by mail-pb0-f43.google.com with SMTP id rq2so9668843pbb.30 for ; Wed, 11 Dec 2013 02:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dxSOjsBP4VimY+g4FgqD6ELfz226pH51AfB42mPYd4I=; b=PYvQPAamLi/St4XktNMdxZKxPhVMrgRi0rUDeNaLMN1cUhwGHiUI57ZAau3/dpjAy9 BBClrFDmS66K5RSqVMsRCoF+nTpkdDAxlnaZil0W09s7XBJlP75AbTkORezurZodftvv bIzZIF5qu5M4TGqzsllqOKGnzcVZnL/r2RqEL5LTex00X5BaC1oFP61yzLfx9zG98JIh x4syGr7VjTVBX7uEoaKUrC8pohjvatWLpEH4OJSJL79c+AO274tpQ9PlSbSy8F3zeCJD asoSCnDl1tygRKQXnFgYbt/45RxDrRAJtSuVOZ8zdteTRry7fHBFsL2x71UMTXTAlbvr s3Nw== MIME-Version: 1.0 X-Received: by 10.67.21.226 with SMTP id hn2mr669580pad.69.1386757473985; Wed, 11 Dec 2013 02:24:33 -0800 (PST) Received: by 10.68.48.163 with HTTP; Wed, 11 Dec 2013 02:24:33 -0800 (PST) In-Reply-To: References: <013BA16A-0673-438E-8001-B65662AEC2E7@gmail.com> <036EC86B-01B6-4110-A74E-E4B9A7D40354@apache.org> <2A3D82CE-DF7E-43C3-BE87-3C71277BA564@gmail.com> Date: Wed, 11 Dec 2013 10:24:33 +0000 Message-ID: Subject: Re: LICENSE and NOTICE Role Models From: Stephen Connolly To: "legal-discuss@apache.org" Cc: general@incubator.apache.org Content-Type: multipart/alternative; boundary=001a11333020a0683704ed3fa270 X-Virus-Checked: Checked by ClamAV on apache.org --001a11333020a0683704ed3fa270 Content-Type: text/plain; charset=ISO-8859-1 All, 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 Legal-discuss, As PMC Chair of a TLP I find the situation with regards to these very confusing. We have had some people state the opinion that our current practice with regards to LICENSE & NOTICE files is not "correct" yet these issues are still unresolved in the LEGAL JIRA and thus, I presume, no legal decision has been formed. Absence a clear decision from the legal PMC we have no choice but to presume that our current interpretation is just as valid as any other interpretation and therefore are continuing with our current practice, e.g. The most critical one to the Maven PMC is LEGAL-26: we have a number of SCM primary roots, for example all our plugins are within http://svn.apache.org/repos/asf/maven/plugins/trunk/ individual plugins are sub-folders within the whole, e.g. http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/ We currently view the primary roots as "expected checkout points" and the individual plugins as not being so. Most developers familiar with Subversion will know that /trunk/ is a root identifier and should expect to find the LICENSE and NOTICE information at that point. Maven tooling generates a project site for every component, so you will have a page such as http://maven.apache.org/plugins/maven-deploy-plugin/source-repository.htmlwhich tells you how to checkout the code of the specific module. In some cases we have multiple modules released together as one operation, e.g. http://maven.apache.org/surefire/index.html, so you have http://maven.apache.org/surefire/source-repository.html as the real root (though in this case this is a GIT based project and at least with GIT the situation is more clear, namely put a LICENSE & NOTICE file in the root of the GIT repository... since you cannot checkout a "partial" GIT repository) So the net result is that http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/does not have a LICENSE & NOTICE file *because* it is a tag of http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/which is only a partial of the "root" http://svn.apache.org/repos/asf/maven/plugins/trunk/. FTR, "best effort" can result in nothing happening at all... after all we can be an incompetent PMC, as long as we are doing our "best effort" there is no guarantee that "our best" is "good enough"... LEGAL-26 needs a very clear and exact ruling. "Expected checkout points" is too vague... I may only be interested in the java code of Maven's deploy plugin... is now http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/an expected checkout point? what about http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/org/apache/maven/plugin/deploy/or even http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/org/apache/maven/plugin/deploy/DeployRequest.java IMHO we should just put a standard LICENSE and NOTICE file at the root of the ASF SVN tree and projects that need to be exceptions to that general LICENSE and NOTICE should have to put the file at the point where it makes sense that is closest in scope to the content requiring the altered LICENSE and NOTICE... so, as examples are better at divining meaning, *if* we had copy&pasted some BSD code into the Maven Deploy Plugin *then* it would require a custom LICENSE and NOTICE file as the one inherited from the root would no longer be valid within that subtree... but in this case we do not have any such code, so we are fine to retain the inherited code. On 11 December 2013 05:24, Marvin Humphrey wrote: > On Tue, Dec 10, 2013 at 8:10 PM, P. Taylor Goetz > wrote: > > It's kind of interesting to see how this has changed over time and varies > > from project to project. > > Here's Roy Fielding in June 2008, saying exactly the same thing you'll hear > from us now: > > http://s.apache.org/Y4v > > If the notices aren't required by the bits in the package, then they > don't belong in NOTICE. That means there will be a different NOTICE > file > required for each differently packaged set of bits. We must do this by > hand. > > Because the file is named "NOTICE", people tend to think it's for anything > notice-ish. This is a pernicious misconception which keeps coming back > over > and over like a weed, and it used to be that not a lot of people besides > Roy > were effective at combatting it. Here's Roy in 2008 again: > > http://s.apache.org/ZIU > > > Furthermore, I assume it is not problematic to have more stuff in the > > NOTICE file(s) than is really required. > > Yes, it is problematic. Consider it a tax on all downstream > recipients. > > Roy can't be everywhere, though, and there are a lot of TLPs who have messy > licensing documentation because they didn't get proper guidance. > > The Licensing How-To, added earlier this year, provides a cookbook approach > which is supposed to yield appropriately sparse LICENSE and NOTICE files. > > http://www.apache.org/dev/licensing-howto.html > > Hopefully the Incubator is now more consistently graduating projects whose > licensing documentation approaches the unchanging minimalist ideal. > > Marvin Humphrey > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org > For additional commands, e-mail: general-help@incubator.apache.org > > --001a11333020a0683704ed3fa270 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

It would be great if we coul= d get a resolution on some of the JIRA's in legal, e.g.

<= div>https://issu= es.apache.org/jira/browse/LEGAL-26

Legal-discuss,

As PMC Chair of a TLP I find the = situation with regards to these very confusing. We have had some people sta= te the opinion that our current practice with regards to LICENSE & NOTI= CE files is not "correct" yet these issues are still unresolved i= n the LEGAL JIRA and thus, I presume, no legal decision has been formed. Ab= sence a clear decision from the legal PMC we have no choice but to presume = that our current interpretation is just as valid as any other interpretatio= n and therefore are continuing with our current practice, e.g.

The most critical one to the Maven PMC is LEGAL-26:

we have a number of SCM primary roots, for example al= l our plugins are within http://svn.apache.org/repos/asf/maven/plugins/trunk/ ind= ividual plugins are sub-folders within the whole, e.g. http://svn= .apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/ We curre= ntly view the primary roots as "expected checkout points" and the= individual plugins as not being so. Most developers familiar with Subversi= on will know that /trunk/ is a root identifier and should expect to find th= e LICENSE and NOTICE information at that point.

Maven tooling generates a project site for every compon= ent, so you will have a page such as=A0http://maven.apache.org/= plugins/maven-deploy-plugin/source-repository.html which tells you how = to checkout the code of the specific module.=A0

In some cases we have multiple modules released togethe= r as one operation, e.g.=A0http://maven.apache.org/surefire/index.html, so you have=A0http://mave= n.apache.org/surefire/source-repository.html as the real root (though i= n this case this is a GIT based project and at least with GIT the situation= is more clear, namely put a LICENSE & NOTICE file in the root of the G= IT repository... since you cannot checkout a "partial" GIT reposi= tory)


FTR, "best effort" can result in nothing happ= ening at all... after all we can be an incompetent PMC, as long as we are d= oing our "best effort" there is no guarantee that "our best&= quot; is "good enough"...=A0


IMHO we should just put a standard LICENSE and NOTICE f= ile at the root of the ASF SVN tree and projects that need to be exceptions= to that general LICENSE and NOTICE should have to put the file at the poin= t where it makes sense that is closest in scope to the content requiring th= e altered LICENSE and NOTICE... so, as examples are better at divining mean= ing, *if* we had copy&pasted some BSD code into the Maven Deploy Plugin= *then* it would require a custom LICENSE and NOTICE file as the one inheri= ted from the root would no longer be valid within that subtree... but in th= is case we do not have any such code, so we are fine to retain the inherite= d code.



On 11 December 2013 05:24, Marvin Humphrey <marvin@rectangula= r.com> wrote:
On Tue, Dec 10, 2013 at 8:= 10 PM, P. Taylor Goetz <ptgoetz@gma= il.com> wrote:
> It's kind of interesting to see how this has changed over time and= varies
> from project to project.

Here's Roy Fielding in June 2008, saying exactly the same thing y= ou'll hear
from us now:

=A0 =A0 http://s.apac= he.org/Y4v

=A0 =A0 If the notices aren't required by the bits in the package, then= they
=A0 =A0 don't belong in NOTICE. =A0That means there will be a different= NOTICE file
=A0 =A0 required for each differently packaged set of bits. =A0We must do t= his by
=A0 =A0 hand.

Because the file is named "NOTICE", people tend to think it's= for anything
notice-ish. =A0This is a pernicious misconception which keeps coming back o= ver
and over like a weed, and it used to be that not a lot of people besides Ro= y
were effective at combatting it. =A0Here's Roy in 2008 again:

=A0 =A0 http://s.apac= he.org/ZIU

=A0 =A0 > Furthermore, I assume it is not problematic to have more stuff= in the
=A0 =A0 > NOTICE file(s) than is really required.

=A0 =A0 Yes, it is problematic. =A0Consider it a tax on all downstream reci= pients.

Roy can't be everywhere, though, and there are a lot of TLPs who have m= essy
licensing documentation because they didn't get proper guidance.

The Licensing How-To, added earlier this year, provides a cookbook approach=
which is supposed to yield appropriately sparse LICENSE and NOTICE files.
=A0 =A0 http://www.apache.org/dev/licensing-howto.html

Hopefully the Incubator is now more consistently graduating projects whose<= br> licensing documentation approaches the unchanging minimalist ideal.

Marvin Humphrey

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


--001a11333020a0683704ed3fa270--