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] [Commented] (LEGAL-155) Please help us educate projects about LICENSE and NOTICE
Date Mon, 28 Jan 2013 22:15:13 GMT

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

Ate Douma commented on LEGAL-155:
---------------------------------

First of all: THANKS for putting the new documentation together and online.

Secondly: I think the choice to remove mentioning 'binaries' from the text is confusing matters
greatly.

Benson of course was correct in stating that ** Apache Releases Are Source Releases **.
However, AFAIK it also is correct to say that everything we *distribute* as Apache projects
needs to be properly copyrighted, licensed and legally attributed.
And we *may* provide so called 'binary' distributions for convenience, so we *need* N&L
instructions for those distributions also.

To me, the N&L requirements for source releases never really have been much of a issue,
or at least not confusing.

The real pain always is in dealing with (Java/maven/or similar) 3rd party dependencies which
are bundled too inside the distribution.
And of those 3rd party dependencies, those from sibling Apache projects aren't really causing
the biggest issues either.
It is those non-ASF 3rd party dependencies, which in many case have incomplete, invalid or
non-existing N&L statements embedded. 

Not clearly describing what bundling a dependency is (source or binary) really makes the instructions
very confusing.
If it is source, what does 'recursive traversal' mean then?
If it is binary, I only need to look at the final bundled set of artifacts inside the distribution,
so no need to do recursive traversal either.

I also agree with Marvin that dependencies with incomplete or missing N&L info doesn't
dissolve the responsibility to checking further.
The reason we provide these N&L files is for downstream users, and they need to be made
aware of the actual N&L info for as much as we reasonably can know or can/must discover.

As an example, take for instance the binary dependency org.apache.openjpa:openjpa:jar:2.2.1
has on net.sourceforge.serp:serp:jar:1.13.1
The serp-1.13.1.jar file does not have any NOTICE or LICENSE file embedded. Does that mean
we don't have to clarify this jar is provided by the serp project under the BSD license?
The actual license is (only) available online here: http://serp.sourceforge.net/#license

Assuming that we should do proper checking like for the serp library and provide the appropriate
license attribution, another important question comes up.
If we are allowed to only 'point' to the license, are we then allowed to 'point' to a location
outside the distribution itself like the license url for the serp library?
That url might not be reliable and/or the content might be changed, so I would assume not.

Its not 100% clear to me what Roy meant with 'Pointers are sufficient' in http://s.apache.org/Hqj
Does it include pointing to external and thus potentially mutable web resources?
IMO for these cases the only reliable choice is appending a hard-copy of that online license
text at the time of building the distribution. 

Or let say a dependency does bundle a license file itself, but that license text is more encompassing
than actually used from the dependency itself (which is more common than one might think).
Also in such cases I don't think it is OK to just 'point' to the license file within the bundled
dependency because the more important rule is that only included bits must be covered.

I really think it actually is more complicated to allow 'pointers' for other licenses, copyrights
and/or notices, except maybe for embedded 3rd party sources (e.g. multi-file javascript libraries
come to mind).
Maybe Roy can elaborate more precisely what he meant, but until this is made very clear, I'm
inclined to not use nor support 'pointers' in most cases. 
                
> 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