Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Date: Sat, 23 Feb 2013 07:16:13 +0000 (UTC)
From: "Marvin Humphrey (JIRA)" <jira@apache.org>
To: legal-discuss@apache.org
Message-ID: <JIRA.12627357.1358105598775.327928.1361603773971@arcas>
In-Reply-To: <JIRA.12627357.1358105598775@arcas>
References: <JIRA.12627357.1358105598775@arcas>
Subject: [jira] [Commented] (LEGAL-155) Please help us educate projects
 about LICENSE and NOTICE
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LEGAL-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585063#comment-13585063 ] 

Marvin Humphrey commented on LEGAL-155:
---------------------------------------

sebb writes:

> The N&L files must only apply to _included bits_.
>
> It does not matter whether the included bits were part of a dependency chain
> or not.
>
> The fact that Maven may use the dependency chain to determine which bits to
> bundle is completely irrelevant.

First, since the ASF is technology-neutral and the subject material of this
document is relevant to all projects, it is important to avoid mention of
specific build tools or downstream distribution channels.  Details regarding
Maven, CPAN, RPMs, app stores, and what-have-you belong elsewhere.

Second, I confess that I did not consider the possibility that a build process
could pull in something other than a "dependency" which might have licensing
implications.  Having a build tool insert some component into a distribution
which is unnecessary (because apparently the product does not "depend" on it)
yet which affects the licensing (!) sounds absurd and evil.  In fact, that
sounds so wrong that I can't believe it's actually what you mean; I suspect
that instead the words "dependency chain" must mean totally different things
to the two of us.

In any case, I have struck the sentence "Perform a recursive traversal of
the product's dependency chain..." as you suggested.  In my view, this edit
damages the document at a fundamental level; it changes the search algorithm
for discovering components from a deep dive to a surface scan and thus
increases the likelihood that bundled child dependencies will be missed.
However, consensus language describing dependency discovery not seem to be
achievable in any reasonable time frame.

Between this change and the restored section on binary distributions, I
believe that the most pressing concerns have been addressed -- so unless
someone specifically objects, I expect to publish a link to this document on
www.apache.org/dev a few days from now.
                
> Please help us educate projects about LICENSE and NOTICE
> --------------------------------------------------------
>
>                 Key: LEGAL-155
>                 URL: https://issues.apache.org/jira/browse/LEGAL-155
>             Project: Legal Discuss
>          Issue Type: Task
>            Reporter: Benson Margulies
>
> Dear Legal,
> The incubator continues to struggle to educate projects in the proper construction and maintenance of LICENSE and NOTICE files. INCUBATOR-125 is an attempt to write some documentation. This document suffers from its authors' inability to even find a single point of reference on the ASF website for theory of these files. 
> Since podlings are unusual only in their need to set up initial versions, it seems to me that most of this documentation should be produced and maintained at the foundation level, and the incubator should be pointing to it, instead of maintain detailed alternatives with risk of divergence.
> If there is existing documentation, please comment and point me to it. If there is not, can we collaborate to write it?
> In this area, I have a particular curiosity and concern about convenience binaries.
> A typical Apache project has very limited needs for complexity in these files for its *releases*. Only sources with external provenance (e.g., results of an SGA) or bundled dependencies trigger it. Far more dependencies get bundled in convenience binaries. But convenience binaries are, merely, conveniences, not legally, releases from the foundation. I've never seen any discussion of this; does the foundation's liability umbrella even extend over them? I doubt it, for all the usual reasons given in emphasizing that the real release is the source release. So I wonder about what policies or guidelines should exist for their legal boilerplate.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org