[jira] [Comment Edited] (LEGAL-155) Please help us educate projects about LICENSE and NOTICE

["Ate Douma (JIRA)" <ji...@apache.org>]

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

Ate Douma edited comment on LEGAL-155 at 1/29/13 8:19 AM:
----------------------------------------------------------

Thanks for the clarification Roy, this is very helpful and in line with what I expected.

While binaries don't need separate policy as you say, they typically are more difficult/complex in this matter simply because they often concern many 3rd party artifacts.

Although you didn't explicitly respond to it, I also draw the conclusion that if a 3rd party artifact (say a jar file, but of course likewise for source files) doesn't carry its own license and/or notice obligations in text format, we MUST go find this first elsewhere and determine it is available under an compatible license before we can actually bundle such 3rd party artifact in an ASF distribution.

I'm bringing this up again once more to clarify what I think is needed also for the recursive dependency approach.
In the example I gave before, using a direct openjpa dependency in my project and including this in a convenience binary distribution, say a demo war file, my distribution also will have the serp jar bundled, automatically pulled in by Maven during the build.
And although the openjpa jar does carry a notice for the serp project, it doesn't carry or even refers to the license for this jar. And it doesn't have to or even should as it of course isn't 'bundled' and distributed within the openjpa jar itself.
So this seems to me a clear use-case where taking the (3rd party) L&N files "at face value" would be the wrong thing to do. 
Thus I typically resolve to is verifying and collecting the 3rd party L&N files and obligations *after* a trial build and then fix it if needed, of course before the final distribution is produced.
IMO there really isn't any difference here between 'direct' or 'transitive' dependencies: they all need to be N&L file covered.

                
      was (Author: adouma):
    Thanks for the clarification Roy, this is very helpful and in line with what I expected.

While binaries don't need separate policy as you say, they typically are more difficult/complex in this matter simply because they often concern many 3rd party artifacts.

Although you didn't explicitly respond to it, I also draw the conclusion that if a 3rd party artifact (say a jar file, but of course likewise for source files) doesn't carry its own license and/or notice obligations in text format, we MUST go find this first elsewhere and determine it is available under an compatible license before we can actually bundle such 3rd party artifact in an ASF distribution.

                  
> 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