incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Homan <>
Subject Re: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating)
Date Fri, 02 Dec 2011 02:32:00 GMT
   You appear to have generated your list of jars from looking at
kafka-0.7.0-incubating.tar.gz, the binary distribution that has been
built as a customary courtesy as part of the release attempt.  This
includes quite a few jars that are not included in the source tree
since binary distributions do include transitive dependencies.  Are
you saying that entries need to be included in NOTICE and LICENSE for
jars/dlls that are included in binary releases?  A quick check shows
that neither Hadoop, nor HBase. nor Whirr (recently with a an
incubator release) do not do this.

If the answer is yes, then it looks like everyone (from my quick
sample) is out of compliance.  If the answer is no, then it looks like
the only libraries that need to be included are those that are
checkedin/included-in-a-source release, which is on the order of 17,
but can be decreased down to four or five if Hadoop is brought in via


On Thu, Dec 1, 2011 at 4:33 PM, sebb <> wrote:
> On 1 December 2011 21:58, Chris Douglas <> wrote:
>> On Thu, Dec 1, 2011 at 1:05 PM, Kevan Miller <> wrote:
>>> I took a quick look at some of these artifacts. I definitely see licenses missing
from the LICENSE file. For example:
>>> paranamer-2.2.jar --
>> The link you reference puts this jar in the public domain and no
>> LICENSE update is required.
> It should still be listed for completeness, otherwise reviewers (and
> possibly users) will ask the same question again.
>>> sbt-launch.jar -- has 4 license files -- license, licenses/LICENSE_Scala, licenses/LICENSE_Apache,
licenses/LICENSE_JLine (2 are missing from your LICENSE)
>>> hadoop -- has a unique license for the org.apache.hadoop.util.bloom.* classes.
>> Thanks for pointing these out. I'm certain that no project with lots
>> of dependencies updates its LICENSE every time it takes an update. One
> The Apache projects I know that include 3rd party jars do update the
> LICENSE (& NOTICE if reqd) file every time a new library is included
> in the distribution.
> It's really not difficult.
> Before deciding to use a 3rd party jar, the project needs to establish
> the license anyway, and check it is acceptable.
> All the required information is then to hand for updating the N&L files.
> For podlings there is a catch-up, but again that must be done *before*
> a release is made, because a release must only include code under
> allowable licenses.
>> gets around this by downloading dependencies rather than distributing
>> them?
> Yes, that can eliminate some of the work.
> However, there are still some requirements for non-included dependencies.
> See
>>> I don't know how many other problems there areā€¦ I'm sorry, but I don't have
time to generate this information for you (nor should I need to). This is something the Kafka
community needs to take on.
>> Thanks for what you've offered.
>> Many of the jars contain LICENSE files. Before spending hours crawling
>> through every dependency, can someone point to the documentation
>> requiring that the top-level LICENSE file contain the transitive
>> closure of all code redistributed through the artifact? -C
> You only need to establish the license for direct dependencies, but
> they do need to be in the one file.
> The podling only has to do this once for each dependency.
> It may be tedious, but it is necessary, not least so that the end
> users (and the release reviewers!) have all the necessary details to
> hand.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message