www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LEGAL-155) Please help us educate projects about LICENSE and NOTICE
Date Tue, 29 Jan 2013 08:21:14 GMT

    [ 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


Mime
View raw message