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 Thu, 21 Jun 2012 13:15:34 GMT

On Jun 21, 2012, at 1:20 AM, Alan D. Cabrera wrote:

> On Jun 19, 2012, at 8:13 AM, Kevan Miller wrote:
>> On Jun 18, 2012, at 9:51 PM, Jun Rao wrote:
>>> Kevin,
>>> Thanks for the comments. Just want to clarify on your points on
>>> LICENSE/NOTICE. Our LICENSE/NOTICE covers all jars included in the source,
>>> not those pulled in during building. We had a long discussion during our
>>> 1st release and in the end, we have reached the conclusion that we don't
>>> have to document LICENSE/NOTICE for jars not included in the source (since
>>> we are just doing a source release). Please correct me if you think this is
>>> blocking the release. We have to include a small number of jars in the
>>> source because there is no easy way to pull them in automatically.
>> Hi Jun,
>> Well, IMO, a source-only release does not free you from your responsibilities of
creating/reviewing the licensing of what your build produces.
>> Would it be ok if your source-only release builds binaries with artifacts that are
not open source or an approved open source license? How am I expected to review your release
if you can't/haven't documented your LICENSE/NOTICE files?
>> Your users will expect to build Kafka (not simply use Kafka source). IMO, you have
a responsibility/requirement to document the licensing of Kafka, not just the portions of
Kafka (i.e. Kafka source code) that you choose to document.
> There's precedent for not doing this, e.g. the previous release of Kafka and I am certain
other ASF releases.  Precedence has great weight.  

Licensing issues were raised with the last release of Kafka. A source-only release was created
to avoid the issue -- a practice which is debatable, at very best, and I is IMO wrong. From
an ASF perspective, all releases are source releases. In some instances, projects also create/distribute
binary artifacts. So now, a new release is being created. Yet, no progress has been made to
address the same licensing issues.

I see your note in the current vote thread. That seems to be a good plan. I think we differ
on what is required/optional and when that work should occur.

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

> FWIW, what I did last time was hand review every single jar and make sure that it's AL
2.0 compatible; yes someone owes me a beer.  I wish there was a rat target for sbt.

Yep. This is something the PPMC should/must be doing. And we should be able to verify by comparing
binary artifacts against LICENSE/NOTICE files.

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

View raw message