On Jun 21, 2012, at 1:20 AM, Alan D. Cabrera wrote: > > On Jun 19, 2012, at 8:13 AM, Kevan Miller wrote: > >> >> On Jun 18, 2012, at 9:51 PM, Jun Rao wrote: >> >>> Kevin, >>> >>> Thanks for the comments. Just want to clarify on your points on >>> LICENSE/NOTICE. Our LICENSE/NOTICE covers all jars included in the source, >>> not those pulled in during building. We had a long discussion during our >>> 1st release and in the end, we have reached the conclusion that we don't >>> have to document LICENSE/NOTICE for jars not included in the source (since >>> we are just doing a source release). Please correct me if you think this is >>> blocking the release. We have to include a small number of jars in the >>> source because there is no easy way to pull them in automatically. >> >> Hi Jun, >> Well, IMO, a source-only release does not free you from your >> responsibilities of creating/reviewing the licensing of what your build >> produces. >> >> Would it be ok if your source-only release builds binaries with artifacts >> that are not open source or an approved open source license? How am I >> expected to review your release if you can't/haven't documented your >> LICENSE/NOTICE files? >> >> Your users will expect to build Kafka (not simply use Kafka source). IMO, >> you have a responsibility/requirement to document the licensing of Kafka, >> not just the portions of Kafka (i.e. Kafka source code) that you choose to >> document. > > There's precedent for not doing this, e.g. the previous release of Kafka and > I am certain other ASF releases. Precedence has great weight.
Licensing issues were raised with the last release of Kafka. A source-only release was created to avoid the issue -- a practice which is debatable, at very best, and I is IMO wrong. From an ASF perspective, all releases are source releases. In some instances, projects also create/distribute binary artifacts. So now, a new release is being created. Yet, no progress has been made to address the same licensing issues. I see your note in the current vote thread. That seems to be a good plan. I think we differ on what is required/optional and when that work should occur. > With that said, I think it's something good and extremely useful to strive > for. The lack of it, i.e. extensive documentation in LICENSE/NOTICE with > regards to transitive dependencies, is not a showstopper IMO unless there are > explicit rules prohibiting it on the ASF rules. I don't have a chapter and verse to quote you. I'll work on getting/creating some clarification. I may not be able to start on that for the next few days... > > FWIW, what I did last time was hand review every single jar and make sure > that it's AL 2.0 compatible; yes someone owes me a beer. I wish there was a > rat target for sbt. Yep. This is something the PPMC should/must be doing. And we should be able to verify by comparing binary artifacts against LICENSE/NOTICE files. --kevan --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
