incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
Date Fri, 22 Jun 2012 16:00:00 GMT

On Jun 21, 2012, at 6:33 PM, Marvin Humphrey wrote:

> On Thu, Jun 21, 2012 at 12:35 PM, Kevan Miller <> 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.

Yes. This is how I would define transitive dependencies. I wasn't sure why you raised the
direct/transitive dependency issue, in the first place. And wanted to be sure we were on the
same page (given the binary dependencies in the source).

>> 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.

My perspective, in 0.7.0 vote, Kafka put up source and binaries for a release vote. Issues
were raised with their LICENSE/NOTICE files (same ones being raised now). They believe they
fixed the issue by moving to a source-only release. Nothing else changed. This is bogus.

>> 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.

That's fine. I cast my vote. The IPMC can decide. My main issue is that the Kafka community
has not done anything to fix their licensing issues. Alan seems to agree that they need to
be fixed and wants to address in the next release -- that's good. 

> 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'm really not interested in reviewing the old vote threads. IMO, the podling brought some
of this on themselves by trying to avoid the issue. Contrast with Airavata. Looks like they
addressed their issues and seem to be in good shape. I may be missing something basic, but
that's my perspective...

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message