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/
> 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.
If you want to include an external jar in the archive, you have to
make sure that you abide by its licensing requirements.
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.
> You are answering a different question here - in many different ways,
> but still, this was not my question -.
I don't think I am.
>> 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 - 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.
When a committer adds a file, they need to be sure it has the
appropriate license.
And the NOTICE file may perhaps need to be updated in order to include
certain source files. This is rare.
> So to speak, the tags *are* equivalent to a release (a source release,
> which is all in all what we do at the ASF...)
Yes.
>>
>> 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.
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.
So the N&L files in SCM must be kept up to date as files are added.
Obviously for most additions made by committers, no change is needed.
>> 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.
>>
>> 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.
> 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.
> They may be *very* different.
Yes, that's what I went on to say below.
>>
>> 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?
If yes, then the file may affect the N&L. If no, then it does not.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
