On 17 July 2013 09:09, Emmanuel Lécharny <elecha...@gmail.com> wrote:
> 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)
No; only A was bundled, so only A's license counts.
> 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...
Yes.
>
> 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.
What's wrong with the phrase:
/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.
>
> 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.
No, a release has to be voted on by the PMC.
> The fact that it's public does not make it any special : it's just
> convenient.
The fact that it is public is important.
That's why snapshots must not be promoted on non-developer pages.
> 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).
That generally only happens in Incubator projects.
>
>> - 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.
I disagree; since SCM is published, its N&L need to be visible.
>> 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.
No - that's a very bad idea.
>>>> 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.
Well yes, it's good to check the N&L at that point.
But how do they know what needs to be added if some files were added a
while ago?
> Of course, it would be better for the committers to try to update the
> N&L file son the fly...
But committers should not knowingly commit infringing code.
That is part of the CLA that they sign.
>> 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.
I don't see how you can keep track of source files that need changes
to the N&L unless you do it at the time.
> Bottom line, SCM != release.
I never said that; it is a distribution.
>>>> 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 ;-)
How does the reviewer know that there are additions to SCM that need
changes to N&L?
>>
>>>> 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 ?
It's not complicated. The question to answer is:
Are B's bits included in the archive?
> Seems to be a clear yes.
Are you sure?
> 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...
That is not the case.
>
> 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.
No, it's not; you are drawing an incorrect conclusion from an incorrect premise.
> 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.
Please try and understand the following first:
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/."
For the purpose of creating the N&L files, it is only the bits that
are actually bundled that matter.
As I keep repeating:
"Is it in the archive bundle or not?"
That is the question.
That is the ONLY question that matters as far as the N&L file contents
are concerned.
> Thanks sebb !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
