incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
Date Fri, 22 Jun 2012 00:37:35 GMT
On 22 June 2012 01:29, Jun Rao <junrao@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.miller@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.miller@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-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message