Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 stephen.alan.connolly@gmail.com designates 209.85.160.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAS6=7jc2bHJK_H14bRFEkuDhvfECKw7Qz3=aXuMBhQTuWHx1g@mail.gmail.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>
Date: Wed, 11 Dec 2013 10:24:33 +0000
Message-ID: 
 <CA+nPnMxrp=Uvk40h1gVpNDhSwZHujsWgV4fG8O26biQQL+nvUQ@mail.gmail.com>
Subject: Re: LICENSE and NOTICE Role Models
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
To: "legal-discuss@apache.org" <legal-discuss@apache.org>
Cc: general@incubator.apache.org
Content-Type: multipart/alternative; boundary=001a11333020a0683704ed3fa270

--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 <marvin@rectangular.com> wrote:

> On Tue, Dec 10, 2013 at 8:10 PM, P. Taylor Goetz <ptgoetz@gmail.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 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--