incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
Date Thu, 21 Jun 2012 22:33:00 GMT
On Thu, Jun 21, 2012 at 12:35 PM, Kevan Miller <kevan.miller@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message