On 22 June 2012 01:29, Jun Rao <jun...@gmail.com> wrote: > Kevan, > > I agree that to the benefit of users, it would be reasonable for Apache > projects to include license/notice for all dependant jars (directly or > indirectly) in a release. However, this has to be done automatically by > tools, not manually by human beings. IMO, without such tools, it's unfair > (and error prone) to make this a requirement for all Apache projects.
Note that the N&L files only apply to the jars that are actually included in a release. So any automated solution needs to take account of whether the dependency is actually present or not. In fact dependencies are irrelevant here - what counts is presence in the release. One reason the N&L files must agree with their contents is so the end-user knows what they are getting. It's important to provide full disclosure of the terms of all the components of the release. > Thanks, > > Jun > > On Thu, Jun 21, 2012 at 12:35 PM, Kevan Miller <kevan.mil...@gmail.com>wrote: > >> >> On Jun 21, 2012, at 1:50 PM, Marvin Humphrey wrote: >> >> > On Thu, Jun 21, 2012 at 6:15 AM, Kevan Miller <kevan.mil...@gmail.com> >> wrote: >> >> On Jun 21, 2012, at 1:20 AM, Alan D. Cabrera wrote: >> > >> >>> 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 feel like I'm missing something. There shouldn't be any difference >> between >> > a first-order dependency and a transitive dependency. All that matters >> is >> > whether or not the dependency is bundled, right?[1] Why would we need >> ASF >> > rules regarding *transitive* dependency license documentation in >> particular? >> >> Because Alan and I disagreed and nobody else had commented? ;-) >> >> > >> > So long as we bundle the bits, we have to bundle the licensing -- >> possibly >> > bubbling up any relevant ALv2 NOTICE provisions into the top-level NOTICE >> > since that's what the ALv2 requires. On the other hand, if the bits >> aren't >> > bundled, then the licensing shouldn't be bundled either. >> > >> > If the bundled dependencies of the canonical ASF source release and a >> > convenience binary differ, then their licensing must be analyzed >> separately >> > and may differ. >> > >> > 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. 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. >> >> 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). The Kafka LICENSE/NOTICE files only contain the >> licenses for this source code and the binary artifacts contained within the >> source release. They don't document the dependencies that they will bundle >> into a distribution. >> >> --kevan >> >> > >> > Marvin Humphrey >> > >> > [1] Leaving aside concerns about copyleft, field of use restrictions, >> etc. >> > >> > --------------------------------------------------------------------- >> > 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
