On 24 June 2012 14:11, Emmanuel Lécharny <elecha...@gmail.com> wrote: > Le 6/24/12 10:46 AM, Chris Douglas a écrit : >> >> Kevan- > > > Hi, jumping on this thread, because we have had similar discussions on > another incubating project I'm mentoring... > >> >> 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 fact that many projects at the ASF are not releasing correctly is not a > good reason for not doing it correctly for Kafka. Moreover, I'm pretty sure > that sooner or later, those projects will have to comply to what seems to be > a reasonable requirement.
+1 >> >> 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. > > > AFAICT, the important thing is that those who will download Kafka (or any > other ASF project) can't be fooled when includig it into their own projects. > The N&L files are here to facilitate our user's work, by listing all the > external third party components we depend on, and that includes transitive > dependencies. -1 The N&L files only apply to what is included in the release archive itself. If there are other dependencies, these can be listed in a DEPENDENCIES or README file. There's an entirely separate issue here, i.e. which dependencies are allowed for an ASF project, regardless of whether the dependencies are bundled or not. That is addressed here: http://www.apache.org/legal/resolved.html > It's also a guarantee that we have checked that no depency contains a > transitive dependency that is *not* compatible with our licence. How good > will it be to include a dependency that includes a GPL3 licensed 3rd party > itself ? See above. > Having checked all the transitive dependencies ourself is the only way to > provide a guarantee to your users, and by listing those transitive Agreed. > dependencies in the N&L files is the only way to go. No, because the N&L files only apply to what is actually being shipped. For example, a source release of a project with no 3rd party source will have N&L files that only mention the ASF. It's important not to encumber the end-user with N&L information that does not apply. > At least this is my interpretation on the various discussions we have had in > the ast two months while tryibg to cut a release on Syncope (incubator) and > SSHD (a MINA subproject). > > Hope it helps... > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
