incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 2)
Date Thu, 21 Jun 2012 16:57:16 GMT

On Jun 21, 2012, at 6:15 AM, Kevan Miller wrote:

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

As I mentioned before, we didn't organize the LICENSE/NOTICE files in this manner before and
I'm certain that other projects have not done it as well.  The fact that it's a source release
doesn't seem relevant to me.  I could be missing something.

>> 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 checked, there don't seem to be any. 

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

Reviewing dependencies, yes.  How LICENSE/NOTICE files are populated with regards to dependencies
is your opinion; an opinion that I do share but don't feel it needs to hold up a release as
long as the dependencies are reviewed.


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

View raw message