Le 7/17/13 1:11 AM, sebb a écrit : > On 16 July 2013 23:09, Emmanuel Lécharny <elecha...@gmail.com> wrote: >> Le 7/16/13 11:34 PM, sebb a écrit : >>> On 16 July 2013 18:34, Emmanuel Lécharny <elecha...@gmail.com> wrote: >>>> The N&L files only depend on what is in the archives. >>>> It's just a question of checking that everything that is included in >>>> the bundles is covered in the N&L files. >>>> The contents should be obvious from the assembly files; if not, just >>>> build the bundles and see what they contain. >>>> Sorry, but I don't see what's your point is here... Why should I build a >>>> bundle for a dependency I'm downloading from maven ? >>>> >>> I don't know how many different ways I can say this: >>> The N&L files need to agree with whatever the PMC releases or >>> distributes - i.e. the source and binary archives, and the Maven jars. >> And we now are so far ok regarding those three components. But still, >> it's in no way connected to the point I raised : what are those bloody >> transitive dependencies that are mentionned on >> http://www.apache.org/dev/licensing-howto.html : >> >> " Dependencies of Dependencies >> >> Dependencies of dependencies (including so-called "transitive >> dependencies") are no different from first-order dependencies for the >> purposes of assembling |LICENSE| and |NOTICE|: |LICENSE| and |NOTICE| >> need only be modified to accommodate them /if and only if their bits are >> bundled/." > As I keep saying - what's important is whether the bits are bundled or not: > > /if and only if their bits are bundled/
Bits of the original dependency, or bits of the transitive dependencies ? For instance, let's say I bundle A, which depends on B 1) As I bundle A which depends on B, I must comply to A *and* B N&L rules (ie, include them if required by them) 2) As I bundle A, I have to comply to its N&L requirement, but for B, I do nithing if I don't *explicitely* bundle it... To me, (2) is not covered by the rules in the apache page. Or if it is, then the semantic of the text on the ASF page s really fuzzy. > >> I don't know if I should un-jar the bundles I include into my >> distribution to check if the included dependency requires some >> NOTICE/LICENSE to be added in my own N&L file. > For anything that is bundled, you need to establish the N&L requirements. > > One way to do so might be to extract the L&N(if it exists) from the jar. > Or for some dependencies you might have to look at the website. > Whatever is needed to establish the licensing requirements. That's fine for direct dependencies. > > If you want to include an external jar in the archive, you have to > make sure that you abide by its licensing requirements. Sure. > > And remember that some licenses (e.g. GPL/LGPL) are not compatible > with the AL so such jars cannot be included in any ASF distributions. Yes, that at least has been clarified years ago (and it was a very long discussion...). > >> You are answering a different question here - in many different ways, >> but still, this was not my question -. > I don't think I am. See my first comment... > >>> The SCM (SVN/Git) counts as a distribution since it is generally >>> published to all (it's not reserved to developers) so it's important >>> that users see the N&L files at the published URL(s) >> SCM has to be kept out of the equation. What is in the SCM is *not* >> subject to NOTICE or LICENSE - except that we need to be able to >> generate the correct N&L files from what is in the SCM (just because >> anyone grabbing a tag should be able to regenerate everything, including >> the package itself, with the correct N&L. > On the contrary, the SCM is very important. > It counts as a distribution No, no, no. And no. A SCM is just a repository, it's certainly not a distribution. A distribution *has* to be voted by the PMC. The fact that it's public does not make it any special : it's just convenient. This is the reason we have all this release process. One of the reason for the SCM not to be seen as a distribution is that this is the place where we *collaboratively* clean up the IP when some code is pushed. If you are to consider a SCM as a distribution, then you are requiring it to be visible to a restricted set of people, until you are sure you are complying to any kind of legal rules that applies to source (IP, copyright, etc). > - so the N&L files should be prominent at > the top level - and it acts as a check list of files that have been > approved. This is a consequence of the fact that we have to include them in a distribution, not the opposite. They may perfectly be stored anywhere else but at the top level in the SCM, as soon as they are present in the package we release. There is no rule that forces you to have them at the top level. > When a committer adds a file, they need to be sure it has the > appropriate license. *we*, collectively, as the PMC. The committer may make a mistake, or may intentionally commit a file without the appropriate licence, as soon as it's added before the release. >>> So the N&L files in SVN/Git must relate to the files in the SCM tree; >> You mean : what is in SCM must be equal to what is in SCM here ??? >> That's quite idempotent... You probably wanted to say something like : >> "the tarball contains the same N&L than the tagged version in the SCM" ? >> >> Am I correct ? > No, I wrote that the N&L files which are at the top of SCM must be > appropriate for the files in SCM. This is wrong. The N&L (whatever the place they can be put in the SCM) are just there to guarantee that the release complies with the bundled components. They are *not* related to what is in the SCM (of course, here, I'm pulling hairs, but I want to insist on teh fact that N&L are *just* present for being included into the release). To be clear, we can perfectly imagine that a project goes on and commit many files, including many dependencies, up to a poit where a release is due. This is the last opportunity for the PMC to check that the N&L are compliant. Up to this point, the N&L files *may* be missing or inacurate. Of course, it would be better for the committers to try to update the N&L file son the fly... > For example, the SCM may contain some icons which don't have the AL > license; in that case the LICENSE file must contain - or point to a > copy of - their license file. Even if the icons are AL licensed, it's > sensible to add a note to the LICENSE file to say so. If the SCM icons aren't bundled into the releases, then this is certainly not required. > > So the N&L files in SCM must be kept up to date as files are added. No, they must not. They *should*. This is really a big difference with what you say. Bottom line, SCM != release. >>> almost always the source bundle is created from SCM so the same N&L >>> files will be suitable for the source bundle as well. >> Only for tags (but basically, the N&L files present in the tagged >> version *must* be the same that what we find in the tarball). > Yes, we create releases from tags. > But tags are created from trunk, generally with very few changes (just > some versions/URLs) so if the N&L files in trunk are OK they will be > OK in the tag. Agreed. But that does not imply that the N&L in trunk are correct at any time. They just have to be correct when you cut the release. And of course, when they aren't, then -1 will be raised ;-) > >>> The binary bundle normally consists of the compiled source, maybe plus >>> Javadoc, maybe with some example sources. >>> All that is derived from the SCM source so the same N&L applies. >> No. > The compiled source/javadoc and source examples are derived directly > from source, so have the same N&L. What I meant is that the N&L may differ from a source release and a binary release. I read you as "the binary N&L in the tag are equals to the N&L in the release", and I agree. > >> There is no guarantee that the N&L files applies for a binary package. > For what I wrote above, they do apply. > Some projects release binaries that are only derived from the project > source - no extra jars are included. > That's what I was saying. Understood. > >>> However, some projects include other items that are needed at run-time >>> - e.g. jars or DLLs. >>> The N&L must be updated to take account of any of these items that are >>> actually included in the binary archive. >>> If they are other Apache products, probably nothing needs to be added to N&L >> Agreed. >> >>> If they are external products - e.g. JUnit - then their LICENSE must >>> be included and if necessary the NOTICE must be updated. >> Agreed. >>> Is that clear now? >> On the bits you are rehashing, yes. But I still don't get what we should >> do with transitive dependencies, and it was what I pointed out. > Forget whether a file is a dependency or a transitive dependency or whatever. > > Are the bits included in the archive? > Yes or no? This is where it gets complicated : when I include A which depends on B, should I consider that B is bundled in the archive ? Seems to be a clear yes. SO now, I have to dig into A archive, checking for all it's dependencies, verify that it correctly includ ethe correct N&L for each of those dependencies etc... By enforcing that, you are trying to make the ASF to behave like what The Eclipse foundation is doing. I'm not sure this is the spirit of the Asf page describing how to comply with teh N&L requirements. Or may be The ASF must go there, but then, we are far from being able to do that atm !!! But this is another story. I think we went way to far in this matter on this dev list, but many very valid points where raised. I'd like to have this conversation on the legal/trademarks mailing list later, when I'll be less loaded. Thanks sebb ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
