On Jun 21, 2012, at 6:15 AM, Kevan Miller wrote: > > 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. As I mentioned before, we didn't organize the LICENSE/NOTICE files in this manner before and I'm certain that other projects have not done it as well. The fact that it's a source release doesn't seem relevant to me. I could be missing something. >> 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... I checked, there don't seem to be any. >> 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. Reviewing dependencies, yes. How LICENSE/NOTICE files are populated with regards to dependencies is your opinion; an opinion that I do share but don't feel it needs to hold up a release as long as the dependencies are reviewed. Regards, Alan --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org