incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)
Date Sun, 24 Jun 2012 08:46:02 GMT
Kevan-

This argument is logical, but that doesn't make it legal and thus
required. It is also a constraint foreign to most TLPs, making its
rigid enforcement in the incubator unfair and arbitrary. Not to be
glib, but you clearly do have time to pursue this broadly and across
the foundation if, in fact, you're right and many- if not most- ASF
projects are improperly managing this obligation.

The references provided do not make the argument you're forwarding, at
least they do not distinguish it from the criteria we used for
evaluating Kafka 0.7.0. The claim is that Kafka "distributes" the
transitive closure of its dependencies NOT because they're mentioned
in the build source (where you carve out an exemption), but because
these deps are mentioned AND Kafka's build produces a server. This
distinction between "applications" and "libraries" is unmentioned in
the documentation. In fact, I cannot create an argument for
documenting the transitive closure of dependencies using those
references. The argument (as forwarded) requires this step to reach
its conclusion, but it appears to be novel and unsupported. The
passages you quote are already common ground; we both agree that the
artifact must contain an "appropriate LICENSE and NOTICE file", but we
disagree on the scope of "appropriate". I continue to disagree; I
don't think the case has been made.

The closest documentation I could find was here:
http://www.apache.org/legal/3party.html

Which claims to be a draft of a document that also doesn't give
concrete guidance on this point.

The vote has technically passed, but we clearly haven't reached
consensus and there are several members who didn't vote but have
reservations. How much time do you think is reasonable to obtain
clarification? -C

On Sat, Jun 23, 2012 at 8:16 AM, Kevan Miller <kevan.miller@gmail.com> wrote:
>
> On Jun 22, 2012, at 6:16 PM, Chris Douglas wrote:
>
>> Kevan-
>
> Hi Chris,
> Thanks for elaborating.
>
>>
>> Please appreciate that there is universal agreement that (1) listing
>> and maintaining all transitive dependencies and licenses is a sound
>> service
>
> It's more than "sound". We are required to meet the terms and conditions of the source/binary
artifacts. IIRC, Marvin stated this pretty well...
>
>> and (2) listing all dependencies distributed with source code
>> carry legal requirements w.r.t. the LICENSE and NOTICE files. We
>> disagree only on (3) the scope of legally required attribution extends
>> to the transitive closure of dependencies.
>
> I wasn't aware of a disagreement on transitive closure. I thought your position was that
"source-only" releases did not need to document their build-time/distribution licensing.
>
> I'll attempt to elaborate, the case for Kafka:
>
> 1) Kafka source contains some ALv2 and non-AL v2 licensed stuff (let's avoid the question
of binary vs. source)
> 2) Kafka source declares some dependencies on binary artifacts
> 3) These direct dependencies have additional transitive dependencies (in this case, declared
via pom.xml, the precise mechanics don't matter)…
>
> Kafka's LICENSE/NOTICE files document the licensing of the source code. Many projects
document their source and binary dependencies in the LICENSE/NOTICE files in the root directory
of their source. Some projects have separate source and binary licenses. There may be some
room for interpretation, here, along with some old-school/new-school thinking.
>
> Some transitive dependencies are compile/test-time only. We don't care about these. We
care about the run-time dependencies. Moreover we only care about the run-time dependencies
that we bundle.
>
> If Kafka only produced individual jar files (and not a runtiime environment), things
would be different. If you only produced jar files, you would need license/notice files in
your source and to produce jar files with license/notice files in the META-INF directory.
These jar files may have run-time dependencies and these dependencies may be encoded in some
meta-data (e.g. pom.xml). We don't care about these dependencies. The META-INF/LICENSE (NOTICE)
need only document the licensing of the source that produced the contents of the jar file.
>
> In the jar-only case, you aren't bundling the dependencies of your jars. Someone else
will be. And IMO, they would be responsible for the licensing of whatever bundling they create.
Just because a pom.xml file declares transitive dependencies, doesn't mean that the bundler
has to use these dependencies. The bundler may replace with their own preferred artifacts
with their own licensing (an behavior, of course).
>
> If Kafka was a jar-only project, we'd be basically done (though I've noted that you aren't
producing jar files with META-INF/LICENSE and NOTICE). That's a "new" requirement, I wouldn't
necessarily demand that in a 0.7.1 release. But would look for it in the future.
>
> Kafka is more than a jar-only project. Kafka is designed to create a messaging server.
Kafka builds kafka source into jar files, packages dependencies (direct/transitive), contains
shell scripts to launch a Kafka messaging server, etc… If you or anyone else on the project
disagrees with this, then let's discuss...
>
> So, Kafka is required to create the LICENSE/NOTICE files for the the Kafka messaging
server that your project is constructing. The LICENSE/NOTICE files must describe all artifacts
contained within the Kafka messaging server. Direct or transitive dependencies don't matter.
What matters is the contents of the Kafka messaging server.
>
>>
>> Now, a group of us believe that we investigated this thoroughly in the
>> Kafka 0.7.0 release and- based on its approval- we are exercising the
>> same procedure to release 0.7.1. If you believe this is mistaken, you
>> can either go to the trouble to obtain clarification from board@,
>> legal@, or find a reference that supports your position. Presented
>> with that evidence, I would reverse my vote. Alternatively, if you
>> believe the work is important enough regardless of policy, then do it.
>> The project would be grateful to receive that contribution. -C
>
> Thanks. Though I'm interested in the Kafka project from several technical aspects, I
just don't have time to participate. Plus, I'm also interested in seeing the project undertake
their ASF responsibilities.
>
> So, here's my attempt at documenting what's required of the project…
>
> Apache releases are described here:
> http://www.apache.org/dev/release.html#what
>
> All PMCs must approve their releases as described here:
> http://www.apache.org/dev/release.html#approving-a-release
>
> As described in the above -- "Before voting +1 PMC members are required to download the
signed source code package, compile it as provided, and test the resulting executable on their
own platform, along with also verifying that the package contains the required contents."
>
> Required contents is documented here:
> http://www.apache.org/dev/release.html#what-must-every-release-contain
>
> "Every ASF release must comply with ASF licensing policy. This requirement is of utmost
importance and an audit should be performed before any full release is created. In particular,
every artifact distributed must contain appropriate LICENSE and NOTICE files. More information
can be found in the foundation website and in the release licensing FAQ."
>
> IMO, the requirements are clear. Let me know if you are unconvinced, and I'll pursue
clarification. An explanation of your position (or summary of your prior investigation) would
be helpful.
>
> --kevan
> ---------------------------------------------------------------------
> 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