mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Date Tue, 16 Jul 2013 22:09:04 GMT
Le 7/16/13 11:34 PM, sebb a écrit :
> On 16 July 2013 18:34, Emmanuel Lécharny <elecharny@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

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.

You are answering a different question here - in many different ways,
but still, this was not my question -.

> 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.

So to speak, the tags *are* equivalent to a release  (a source release,
which is all in all what we do at the ASF...)

> 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 ?

> 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).
> 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. There is no guarantee that the N&L files applies for a binary
package. They may be *very* different.
> 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

> If they are external products - e.g. JUnit - then their LICENSE must
> be included and if necessary the NOTICE must be updated.
> 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.

Emmanuel Lécharny

View raw message