On Jun 21, 2012, at 3:33 PM, Marvin Humphrey wrote: >> So, attempting to clarify: >> >> I think Alan's (Kafka's) position is that dependencies don't matter since >> they are not distributing binary artifacts. >> >> I would agree with Alan, if Kafka source was simply intended to be used in >> source form. That's not the case. The Kafka project is designed to be >> built/compiled into a distribution. So, IMO, Kafka must document their >> dependencies. Note that if Kafka only had compile-time/test-time >> dependencies and simply built .jar files (and someone else was responsible >> for bundling everything together into a "distribution"), then I'd have a >> different opinion. > > OK, that's what I was missing. :) > > If Kafka is indeed intended for use as an application/end-product, then it > seems appropriate to document the licensing of unbundled dependencies -- but > not legally mandatory since those bits aren't in the release artifacts. > > As someone who's not involved in Kafka, I don't feel it's my role to make the > policy call as to whether the additional licensing info really ought to be > there.
Agreed, it should be in there, not must be in there. If others feel differently then they are free to ratify a new rule about this. Piggy backing refinements in policy on top of votes is, IMO, one the biggest frustrations podlings have with the Incubator. >> In this case, the Kafka source release contains AL v2 licensed source code >> along with some binary artifacts under several licenses (you're welcome to >> comment on this, also). > > /ASF Member hat on > > I agree with Roy that the ASF releases only source code, and that therefore > binary files such as jars do not belong in our canonical source releases. > > The one TLP that I follow closely where this has been an issue with past > releases has changed its way of doing things. I hope that other TLPs have > made similar adaptations. > > /ASF Member hat off, IPMC Member hat on /ASF Member hat on :) It's my understanding that there are other graduated projects that distribute jars w/ their source code. With that said, the statement " jars do not belong in our canonical source releases" strikes as an aesthetic statement. Sometimes, it's required because of the way the project build system is organized. /ASF Member hat off, IPMC Member hat on :) > > At the least, I don't think a podling ought to graduate if their releases > contain binary artifacts. Problematic past practices of TLPs should not serve > as precedents for podlings. Oh, but past practices are used to justify all sorts of things here at ASF. If there is no concrete rule prohibiting it. If you and Kevan feel strongly about it I invite you to join the project and update it yourselves. This is, of course, open source. ;) > /IPMC Member hat off > > As to whether this particular release should be blocked because there are jars > in the "source" archive, I think it probably should, though I'm not planning > to get involved in the VOTE. > > I'm sympathetic that Kafka drew the short straw before and got whipsawed > during their first incubating release over NOTICE disagreements. (What was it > -- 9, 10 release candidates?) However, I'm not how much flexibility we have > with regards to the issue at hand. I think that it warrants saying again, piggy backing refinements in policy on top of votes is, IMO, one the biggest frustrations podlings have with the Incubator. If you feel strongly about a refinement then start and manage its ratification on general@i.a.o or members@a.o *on its own separate thread*. If you feel strongly about how a project's build is organized, roll up your sleeves and join in on the fun. Regards, Alan
