flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Metzger <rmetz...@apache.org>
Subject Re: Feedback on first release candidate artifacts (0.6-incubating)
Date Wed, 06 Aug 2014 17:36:52 GMT
The reason why I kicked of the whole discussion is the following sentence
in the guide Henry posted [1]:
"LICENSE and NOTICE must always be tailored to the content of the specific
distribution they reside within. Dependencies which are not included in the
distribution MUST NOT be added to LICENSE and NOTICE. As far as LICENSE and
NOTICE are concerned, *only bundled bits matter."*

The top level LICENSE / NOTICE files end up only in the source release,
which does not contain the source/binary of the dependencies (only
references to them, in the pom files).
Either I've oversight something or Spark and Cassandra have wrong NOTICE
files in their source releases.
I could not find a similar discussion on the legal list here:
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/. But maybe
thats the right place to ask that question.

[1]: http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled

On Wed, Aug 6, 2014 at 5:12 PM, Stephan Ewen <sewen@apache.org> wrote:

> Okay, this seems to be tricky, and different projects do it in different
> ways.
> Some projects seem to do it the way I prepared it (Spark or Cassandra) .
> See the root level files
> https://github.com/apache/spark/blob/master/NOTICE
> or https://github.com/apache/cassandra/blob/trunk/NOTICE.txt
> Which way is correct?
> Having a fat NOTICE file may be ugly, but it would put us on the safe side,
> no?
> Robert suggested to have two LICENSE and NOTICE files, one at the source
> root, one for the binary distribution. If we go that way, then anyone that
> adds Flink as a Maven dependency (which bundles the bits) needs to figure
> out that the relevant NOTICE file is only available in the binary
> distribution - that the source NOTICE file is not listing all required
> entries. Would that really be correct?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message