On Thu, Jun 21, 2012 at 12:35 PM, Kevan Miller <kevan.mil...@gmail.com> wrote: >> If a project has a gazillion dependencies, regardless of whether those >> dependencies are direct or transitive, that makes dealing with licensing more >> challenging, but it doesn't change our legal obligations. > > I think you and I agree. Though there may be some ambiguities in what we > mean by direct or transitive dependencies.
By "direct dependency", I meant a dependency where our code uses the dependency's API directly. By "transitive dependency", I meant "a dependency of a dependency": if A depends on B and B depends on C then A depends on C ... and thus C is a "transitive" dependency of A. I guess this "transitive dependency" terminology is a Maven thing. http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies > 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. > 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 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. /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. Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
