Kevan- 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 sbt/maven. Thanks, Jakob On Thu, Dec 1, 2011 at 4:33 PM, sebb <seb...@gmail.com> wrote: > On 1 December 2011 21:58, Chris Douglas <cdoug...@apache.org> wrote: >> On Thu, Dec 1, 2011 at 1:05 PM, Kevan Miller <kevan.mil...@gmail.com> 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 -- http://paranamer.codehaus.org/info/license.html >> >> 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 http://www.apache.org/legal/resolved.html > >>> 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. > > http://www.apache.org/dev/release.html#distributing-code-under-several-licenses > > 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: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
