You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Julien Vermillard <jv...@gmail.com> on 2013/07/09 16:27:52 UTC
[VOTE] release Apache MINA 3.0.0-M1
Hi !
Here the first milestone release for MINA 3.
Please take a look at the artifact here :
http://people.apache.org/~jvermillard/mina-3.0.0-M1-vote/
and vote :
[ ] +1 release Apache MINA 3.0.0-M1
[ ] +0 I don't care
[ ] -1 don't release !
--
Julien Vermillard :::: http://people.apache.org/~jvermillard/
Re: [VOTE] release Apache MINA 3.0.0-M1
Posted by sebb <se...@gmail.com>.
On 11 July 2013 09:43, Julien Vermillard <jv...@gmail.com> wrote:
> The question is : should we have NOTICE for test dependencies ?
Only bundled bits are relevant for the N&L files included in the bundle.
> --
> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>
>
> On Thu, Jul 11, 2013 at 12:59 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>> Le 7/10/13 9:03 PM, Julien Vermillard a écrit :
>>> I heard (from Emmanuel I think) we don't need to put notice files for
>>> apache products (thrift and log4j).
>> Yes. The are apache projects, covered by the MINA NOTICE file. No need
>> to add an extra file for each one of them, or to list them all.
>>>
>>> So (if true) the only missing is netty used for benchmark which is
>>> just tests no ?
>>
>> slf4j is not an Apache project, AFAICT.
>>
>> We are also using junit and mockito...
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by sebb <se...@gmail.com>.
On 17 July 2013 09:09, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 7/17/13 1:11 AM, sebb a écrit :
>> On 16 July 2013 23:09, Emmanuel Lécharny <el...@gmail.com> wrote:
>>> Le 7/16/13 11:34 PM, sebb a écrit :
>>>> On 16 July 2013 18:34, Emmanuel Lécharny <el...@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
>
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/17/13 1:11 AM, sebb a écrit :
> On 16 July 2013 23:09, Emmanuel Lécharny <el...@gmail.com> wrote:
>> Le 7/16/13 11:34 PM, sebb a écrit :
>>> On 16 July 2013 18:34, Emmanuel Lécharny <el...@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
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by sebb <se...@gmail.com>.
On 16 July 2013 23:09, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 7/16/13 11:34 PM, sebb a écrit :
>> On 16 July 2013 18:34, Emmanuel Lécharny <el...@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
>
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/16/13 11:34 PM, sebb a écrit :
> On 16 July 2013 18:34, Emmanuel Lécharny <el...@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/."
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
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by sebb <se...@gmail.com>.
On 16 July 2013 18:34, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 7/16/13 6:48 PM, sebb a écrit :
>>
>>>>>> It is important that the N&L files relate to the bits which are
>>>>>> actually included.
>>>>>>
>>>>>> This means that the N&L files at the top level of SVN can be used
>>>>>> directly for the source archive, as the archive and SVN should
>>>>>> generally agree (bar maybe the DOAP).
>>>>>>
>>>>>> The binary archive may need additional License (and occasionally)
>>>>>> Notice entries, depending what is additionally bundled.
>>>>> Yes. It has been corrected yesterday, and I just pushed the modifications.
>>>>>
>>>>>
>>>>>
>>>>> Btw, I really think that the
>>>>> http://www.apache.org/dev/licensing-howto.html is far from being easy to
>>>>> understand for not native english speakers, especially by those who have
>>>>> not a degree in law school...
>>>> What is not clear? Please raise that with Infra.
>>> You are wondering ??? ;-) In how many projects are you trying to get
>>> those files corrected ? I can't imagine I'm the only one not being able
>>> to decipher the pretty convoluted semi-legal text on this page.
>> I find that page quite clear, apart from the link to /legal, which is
>> very unhelpful.
>
> Being a english native speaker, you may find it pretty well written. I'm
> not, and I find that some of the sentences quite convoluted.
>
> I have already stated that instead of producing a bunch of verbose
> explainations and nothing else, the addition of samples could help.
>
> It's pretty much like if you were to read the API specification with no
> sample at all...
>
>
>>
>>> Legal texts are fine assuming you don't have to read them, and as soon
>>> as you have a lawyer reading above your shoulder and correcting you
>>> immediately when you do something wrong (kind of what you are doing
>>> here, and you must be blessed for taking care of those details !). We
>>> are dumb developpers, quite good at finding bugs, coding large software,
>>> but not very good when it comes to contracts...
>> That page is not intended as a legal text.
>
> It loooks like so to me. It's just a feeling, but it's shared by many
> people.
>
>
>
>>
>>> What do I find "not clear" ? Unless I read every single line ten times,
>>> I'm ot able to decide what to do or what not to do. What is a
>>> "dependency" ? This is a contextful terfm, which meeans something in a
>>> Maven context and something else in another context.
>> I don't see any distinction there.
>> A dependency is something the code depends on.
>
> Now you are specifically describing what is a dependency. But this is
> not even close to what a dependency is : is an image a dependency,
> assuming the code does not depend on it ?
>
> What I want to stress out is that the terms are vague, and swamped into
> a long list of sentences that does not help to clarify the intention of
> those who wrote those pages (not to mention the misleading links to
> other pages)
>
>> In a Maven context it will be a jar, in a C-project it might be a DLL, etc.
>
> That's better. Having such a sentence in this page would have helped.
>
> I have read the page many times in the past years, and I have been
> released at least 3 different projects (MINA, ApacheDS and Ldap API) for
> many years. I have trie dmy best to understand what were the
> requirement, and so far, I must say that I have miserabily failed.
>
> Blame me, but then I'm not the only one to blame. Julien has also spent
> many times trying to get the N&L files correct, and it seems he is as
> lame as I am. I know other people from other projects having the exact
> same problem (I have mentored the Shiro and Syncope projects, and they
> faced the same problem too : they are probably retarded...)
>
> *or* the existing documention is simply sub-optimal...
>
>>
>>> I can go on and on, but frankly, I have no time nor energy to fight with
>>> infra about the content of this file. I consider that it's a task that
>>> should be fulfiled by legal@a.o, and we probably need a working group to
>>> add some samples helping people like me to know what to do.
>> But unless you explain what you find difficult to understand, how can
>> anyone hope to fix it?
>
> true. Here, I'm just rambling, I know. May be when I will be done with
> my three current projects' bugs, after I have moved from my old house to
> the new one, once I have managed the trial I'm engaged in with my
> father's associate, and various other hazards I have to deal with this
> month and the next one, then yes, I will push a mail to legal.
>
>>
>>>> Transitive dependencies are no different from other dependencies - are
>>>> the bits actually included?
>>> No, because I have no idea what dependency are transitively included.
>> You may not know what the transitive dependencies are, but I would
>> hope you know what is actually in the binary archive.
>
> I know that I embed slf4j. I know that slf4j embeds at least 3 other
> jars itself. This is all I know...
>
> I'm expecting Slf4j to fulfill their duty regarding the inclusion of the
> needed NOTICE and LICENSE, and that it reflects in their own LICENCE and
> NOTICE file.
>
>>
>> Again, only the bits that are actually included in the archives matter
>> for the purpose of the N&L files.
>> If a file is needed at run-time or test-time - or even compile time -
>> if it is not included in the bundle then it has no business being
>> mentioned in the N&L files.
>>
>> If a file is included, it must be covered by the N&L files
>> If it is not included, the N&L files should not mention it.
>
> This has nothing to do with transitive dependencies.
>
>
>>
>>> This is again an extremely time consumming task, and I can't believe
>>> that it has not already been done on one of the 100 projects at the ASF,
>>> and gathered in a common place...
>> Sorry, what is time consuming?
> Searching for every transitive dependencies for dependencies we include
> into our packages.
>
>>
>> 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.
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)
So the N&L files in SVN/Git must relate to the files in the SCM tree;
almost always the source bundle is created from SCM so the same N&L
files will be suitable for the source bundle as well.
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.
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?
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/16/13 6:48 PM, sebb a écrit :
>
>>>>> It is important that the N&L files relate to the bits which are
>>>>> actually included.
>>>>>
>>>>> This means that the N&L files at the top level of SVN can be used
>>>>> directly for the source archive, as the archive and SVN should
>>>>> generally agree (bar maybe the DOAP).
>>>>>
>>>>> The binary archive may need additional License (and occasionally)
>>>>> Notice entries, depending what is additionally bundled.
>>>> Yes. It has been corrected yesterday, and I just pushed the modifications.
>>>>
>>>>
>>>>
>>>> Btw, I really think that the
>>>> http://www.apache.org/dev/licensing-howto.html is far from being easy to
>>>> understand for not native english speakers, especially by those who have
>>>> not a degree in law school...
>>> What is not clear? Please raise that with Infra.
>> You are wondering ??? ;-) In how many projects are you trying to get
>> those files corrected ? I can't imagine I'm the only one not being able
>> to decipher the pretty convoluted semi-legal text on this page.
> I find that page quite clear, apart from the link to /legal, which is
> very unhelpful.
Being a english native speaker, you may find it pretty well written. I'm
not, and I find that some of the sentences quite convoluted.
I have already stated that instead of producing a bunch of verbose
explainations and nothing else, the addition of samples could help.
It's pretty much like if you were to read the API specification with no
sample at all...
>
>> Legal texts are fine assuming you don't have to read them, and as soon
>> as you have a lawyer reading above your shoulder and correcting you
>> immediately when you do something wrong (kind of what you are doing
>> here, and you must be blessed for taking care of those details !). We
>> are dumb developpers, quite good at finding bugs, coding large software,
>> but not very good when it comes to contracts...
> That page is not intended as a legal text.
It loooks like so to me. It's just a feeling, but it's shared by many
people.
>
>> What do I find "not clear" ? Unless I read every single line ten times,
>> I'm ot able to decide what to do or what not to do. What is a
>> "dependency" ? This is a contextful terfm, which meeans something in a
>> Maven context and something else in another context.
> I don't see any distinction there.
> A dependency is something the code depends on.
Now you are specifically describing what is a dependency. But this is
not even close to what a dependency is : is an image a dependency,
assuming the code does not depend on it ?
What I want to stress out is that the terms are vague, and swamped into
a long list of sentences that does not help to clarify the intention of
those who wrote those pages (not to mention the misleading links to
other pages)
> In a Maven context it will be a jar, in a C-project it might be a DLL, etc.
That's better. Having such a sentence in this page would have helped.
I have read the page many times in the past years, and I have been
released at least 3 different projects (MINA, ApacheDS and Ldap API) for
many years. I have trie dmy best to understand what were the
requirement, and so far, I must say that I have miserabily failed.
Blame me, but then I'm not the only one to blame. Julien has also spent
many times trying to get the N&L files correct, and it seems he is as
lame as I am. I know other people from other projects having the exact
same problem (I have mentored the Shiro and Syncope projects, and they
faced the same problem too : they are probably retarded...)
*or* the existing documention is simply sub-optimal...
>
>> I can go on and on, but frankly, I have no time nor energy to fight with
>> infra about the content of this file. I consider that it's a task that
>> should be fulfiled by legal@a.o, and we probably need a working group to
>> add some samples helping people like me to know what to do.
> But unless you explain what you find difficult to understand, how can
> anyone hope to fix it?
true. Here, I'm just rambling, I know. May be when I will be done with
my three current projects' bugs, after I have moved from my old house to
the new one, once I have managed the trial I'm engaged in with my
father's associate, and various other hazards I have to deal with this
month and the next one, then yes, I will push a mail to legal.
>
>>> Transitive dependencies are no different from other dependencies - are
>>> the bits actually included?
>> No, because I have no idea what dependency are transitively included.
> You may not know what the transitive dependencies are, but I would
> hope you know what is actually in the binary archive.
I know that I embed slf4j. I know that slf4j embeds at least 3 other
jars itself. This is all I know...
I'm expecting Slf4j to fulfill their duty regarding the inclusion of the
needed NOTICE and LICENSE, and that it reflects in their own LICENCE and
NOTICE file.
>
> Again, only the bits that are actually included in the archives matter
> for the purpose of the N&L files.
> If a file is needed at run-time or test-time - or even compile time -
> if it is not included in the bundle then it has no business being
> mentioned in the N&L files.
>
> If a file is included, it must be covered by the N&L files
> If it is not included, the N&L files should not mention it.
This has nothing to do with transitive dependencies.
>
>> This is again an extremely time consumming task, and I can't believe
>> that it has not already been done on one of the 100 projects at the ASF,
>> and gathered in a common place...
> Sorry, what is time consuming?
Searching for every transitive dependencies for dependencies we include
into our packages.
>
> 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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by sebb <se...@gmail.com>.
On 16 July 2013 14:01, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 7/16/13 12:08 PM, sebb a écrit :
>> On 16 July 2013 08:41, Emmanuel Lécharny <el...@gmail.com> wrote:
>>> Le 7/16/13 1:14 AM, sebb a écrit :
>>>> Have you seen this?
>>>>
>>>> http://www.apache.org/dev/licensing-howto.html#mod-notice
>>>>
>>>> It suggests that additions to NOTICE should be quite rare.
>>> The NOTICE files just contain the Apache License reference as of today.
>>> The one used for binary contains a ref rto SLF4J and Protobuf, which are
>>> distributed with the bin. I think this corretly fits with the requirements.
>> I'm not sure that entries in NOTICE are required.
> Right... " If the dependency supplies a |NOTICE| file, its contents must
> be analyzed and the relevant portions bubbled up into the top-level
> |NOTICE| file."
>
> For protobuf, this is not needed. We just have to add the protobuf
> licence into the LICENSE-bin file.
> For SLF4J, this is exactly the same thing.
>
> I will remove anything related to those two jars from the NOTICE-bin
> file (which will ^robably be removed, as it has teh same content than
> NOTICE)
>
>
>>> The very same for the LICENSE files.
>> Yes, LICENSE does need entries (or pointers to other files) for all
>> included bits.
>
> +1
OK.
>>
>>>> It is important that the N&L files relate to the bits which are
>>>> actually included.
>>>>
>>>> This means that the N&L files at the top level of SVN can be used
>>>> directly for the source archive, as the archive and SVN should
>>>> generally agree (bar maybe the DOAP).
>>>>
>>>> The binary archive may need additional License (and occasionally)
>>>> Notice entries, depending what is additionally bundled.
>>> Yes. It has been corrected yesterday, and I just pushed the modifications.
>>>
>>>
>>>
>>> Btw, I really think that the
>>> http://www.apache.org/dev/licensing-howto.html is far from being easy to
>>> understand for not native english speakers, especially by those who have
>>> not a degree in law school...
>> What is not clear? Please raise that with Infra.
>
> You are wondering ??? ;-) In how many projects are you trying to get
> those files corrected ? I can't imagine I'm the only one not being able
> to decipher the pretty convoluted semi-legal text on this page.
I find that page quite clear, apart from the link to /legal, which is
very unhelpful.
> Legal texts are fine assuming you don't have to read them, and as soon
> as you have a lawyer reading above your shoulder and correcting you
> immediately when you do something wrong (kind of what you are doing
> here, and you must be blessed for taking care of those details !). We
> are dumb developpers, quite good at finding bugs, coding large software,
> but not very good when it comes to contracts...
That page is not intended as a legal text.
> What do I find "not clear" ? Unless I read every single line ten times,
> I'm ot able to decide what to do or what not to do. What is a
> "dependency" ? This is a contextful terfm, which meeans something in a
> Maven context and something else in another context.
I don't see any distinction there.
A dependency is something the code depends on.
In a Maven context it will be a jar, in a C-project it might be a DLL, etc.
> How do we manage the jars used only during tests ?
Same as for any other dependency - only the bits that are included matter.
If the code requires JUnit at test time and JavaMail at runtime, the
only thing that matters is whether or not the archive includes JUnit
and/or JavaMail.
> Another pb : there is a link on this page :
> http://www.apache.org/dev/licensing-howto.html#overview-of-files which
> refers to this other page : http://www.apache.org/legal/. Literarelly,
> it says :
>
> " The complete requirements for |LICENSE| and |NOTICE| are described
> elsewhere <http://www.apache.org/legal>." (elswhere -->
> http://www.apache.org/legal/) Now, find where in this page you have
> anything directly related to the NOTICE file... Yeah, if you dig a bit,
> you find it on http://www.apache.org/legal/src-headers.html#notice...
> Note that this link can be found when clicking on the " Source Header
> and Copyright Notice Policy
> <http://www.apache.org/legal/src-headers.html>" link. Not really user
> friendly...
I agree about that link.
> I can go on and on, but frankly, I have no time nor energy to fight with
> infra about the content of this file. I consider that it's a task that
> should be fulfiled by legal@a.o, and we probably need a working group to
> add some samples helping people like me to know what to do.
But unless you explain what you find difficult to understand, how can
anyone hope to fix it?
>
>>
>>> There are a few use cases that would
>>> benefit the whole community if they were included in this page, like :
>>> - junit, what to do regarding N&L files ?
>>> - slf4j/log4j, what to do regarding N&L files?
>> In that case, please ask on legal discuss / infra.
> That would be the Nth time I would ask them for such informations. I was
> able to find a mail I sent to them last year, and I've got only one
> answer from someone not part of the legal team.
>
> Seriously, it's years those questions are asked, and most certainly
> answered, with no will to collect the valuable answer on a single page
> for the common good. Not blaming them though, bt this is just a waste of
> energy from both sides...
>
>>
>>> - transitive dependencies like cal10n-api.jar (inlcuded by slf4j), what
>>> to do regarding N&L files ? (note that it could be a dependency of
>>> another jar than slf4j, I just picked this one because I know that slf4j
>>> depends on this jar).
>> Transitive dependencies are no different from other dependencies - are
>> the bits actually included?
> No, because I have no idea what dependency are transitively included.
You may not know what the transitive dependencies are, but I would
hope you know what is actually in the binary archive.
Again, only the bits that are actually included in the archives matter
for the purpose of the N&L files.
If a file is needed at run-time or test-time - or even compile time -
if it is not included in the bundle then it has no business being
mentioned in the N&L files.
If a file is included, it must be covered by the N&L files
If it is not included, the N&L files should not mention it.
> This is again an extremely time consumming task, and I can't believe
> that it has not already been done on one of the 100 projects at the ASF,
> and gathered in a common place...
Sorry, what is time consuming?
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.
> I'm a volunteer, this is a best effort work, and if I miss something,
> then I'd rather fix it once someone show me how to fix it rather than
> spending hours (days ?) to dig many external jars, many incomplet or
> cryptic web pages to get it right at first. And guess what ? I'm not the
> only one having through those balls...
Again, if web-pages seem cryptic to you, they won't fix themselves.
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/16/13 12:08 PM, sebb a écrit :
> On 16 July 2013 08:41, Emmanuel Lécharny <el...@gmail.com> wrote:
>> Le 7/16/13 1:14 AM, sebb a écrit :
>>> Have you seen this?
>>>
>>> http://www.apache.org/dev/licensing-howto.html#mod-notice
>>>
>>> It suggests that additions to NOTICE should be quite rare.
>> The NOTICE files just contain the Apache License reference as of today.
>> The one used for binary contains a ref rto SLF4J and Protobuf, which are
>> distributed with the bin. I think this corretly fits with the requirements.
> I'm not sure that entries in NOTICE are required.
Right... " If the dependency supplies a |NOTICE| file, its contents must
be analyzed and the relevant portions bubbled up into the top-level
|NOTICE| file."
For protobuf, this is not needed. We just have to add the protobuf
licence into the LICENSE-bin file.
For SLF4J, this is exactly the same thing.
I will remove anything related to those two jars from the NOTICE-bin
file (which will ^robably be removed, as it has teh same content than
NOTICE)
>> The very same for the LICENSE files.
> Yes, LICENSE does need entries (or pointers to other files) for all
> included bits.
+1
>
>>> It is important that the N&L files relate to the bits which are
>>> actually included.
>>>
>>> This means that the N&L files at the top level of SVN can be used
>>> directly for the source archive, as the archive and SVN should
>>> generally agree (bar maybe the DOAP).
>>>
>>> The binary archive may need additional License (and occasionally)
>>> Notice entries, depending what is additionally bundled.
>> Yes. It has been corrected yesterday, and I just pushed the modifications.
>>
>>
>>
>> Btw, I really think that the
>> http://www.apache.org/dev/licensing-howto.html is far from being easy to
>> understand for not native english speakers, especially by those who have
>> not a degree in law school...
> What is not clear? Please raise that with Infra.
You are wondering ??? ;-) In how many projects are you trying to get
those files corrected ? I can't imagine I'm the only one not being able
to decipher the pretty convoluted semi-legal text on this page.
Legal texts are fine assuming you don't have to read them, and as soon
as you have a lawyer reading above your shoulder and correcting you
immediately when you do something wrong (kind of what you are doing
here, and you must be blessed for taking care of those details !). We
are dumb developpers, quite good at finding bugs, coding large software,
but not very good when it comes to contracts...
What do I find "not clear" ? Unless I read every single line ten times,
I'm ot able to decide what to do or what not to do. What is a
"dependency" ? This is a contextful terfm, which meeans something in a
Maven context and something else in another context. How do we manage
the jars used only during tests ? Another pb : there is a link on this
page :
http://www.apache.org/dev/licensing-howto.html#overview-of-files which
refers to this other page : http://www.apache.org/legal/. Literarelly,
it says :
" The complete requirements for |LICENSE| and |NOTICE| are described
elsewhere <http://www.apache.org/legal>." (elswhere -->
http://www.apache.org/legal/) Now, find where in this page you have
anything directly related to the NOTICE file... Yeah, if you dig a bit,
you find it on http://www.apache.org/legal/src-headers.html#notice...
Note that this link can be found when clicking on the " Source Header
and Copyright Notice Policy
<http://www.apache.org/legal/src-headers.html>" link. Not really user
friendly...
I can go on and on, but frankly, I have no time nor energy to fight with
infra about the content of this file. I consider that it's a task that
should be fulfiled by legal@a.o, and we probably need a working group to
add some samples helping people like me to know what to do.
>
>> There are a few use cases that would
>> benefit the whole community if they were included in this page, like :
>> - junit, what to do regarding N&L files ?
>> - slf4j/log4j, what to do regarding N&L files?
> In that case, please ask on legal discuss / infra.
That would be the Nth time I would ask them for such informations. I was
able to find a mail I sent to them last year, and I've got only one
answer from someone not part of the legal team.
Seriously, it's years those questions are asked, and most certainly
answered, with no will to collect the valuable answer on a single page
for the common good. Not blaming them though, bt this is just a waste of
energy from both sides...
>
>> - transitive dependencies like cal10n-api.jar (inlcuded by slf4j), what
>> to do regarding N&L files ? (note that it could be a dependency of
>> another jar than slf4j, I just picked this one because I know that slf4j
>> depends on this jar).
> Transitive dependencies are no different from other dependencies - are
> the bits actually included?
No, because I have no idea what dependency are transitively included.
This is again an extremely time consumming task, and I can't believe
that it has not already been done on one of the 100 projects at the ASF,
and gathered in a common place...
I'm a volunteer, this is a best effort work, and if I miss something,
then I'd rather fix it once someone show me how to fix it rather than
spending hours (days ?) to dig many external jars, many incomplet or
cryptic web pages to get it right at first. And guess what ? I'm not the
only one having through those balls...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by sebb <se...@gmail.com>.
On 16 July 2013 08:41, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 7/16/13 1:14 AM, sebb a écrit :
>> Have you seen this?
>>
>> http://www.apache.org/dev/licensing-howto.html#mod-notice
>>
>> It suggests that additions to NOTICE should be quite rare.
>
> The NOTICE files just contain the Apache License reference as of today.
> The one used for binary contains a ref rto SLF4J and Protobuf, which are
> distributed with the bin. I think this corretly fits with the requirements.
I'm not sure that entries in NOTICE are required.
If not required, it must not be added.
> The very same for the LICENSE files.
Yes, LICENSE does need entries (or pointers to other files) for all
included bits.
>>
>> It is important that the N&L files relate to the bits which are
>> actually included.
>>
>> This means that the N&L files at the top level of SVN can be used
>> directly for the source archive, as the archive and SVN should
>> generally agree (bar maybe the DOAP).
>>
>> The binary archive may need additional License (and occasionally)
>> Notice entries, depending what is additionally bundled.
> Yes. It has been corrected yesterday, and I just pushed the modifications.
>
>
>
> Btw, I really think that the
> http://www.apache.org/dev/licensing-howto.html is far from being easy to
> understand for not native english speakers, especially by those who have
> not a degree in law school...
What is not clear? Please raise that with Infra.
> There are a few use cases that would
> benefit the whole community if they were included in this page, like :
> - junit, what to do regarding N&L files ?
> - slf4j/log4j, what to do regarding N&L files?
In that case, please ask on legal discuss / infra.
> - transitive dependencies like cal10n-api.jar (inlcuded by slf4j), what
> to do regarding N&L files ? (note that it could be a dependency of
> another jar than slf4j, I just picked this one because I know that slf4j
> depends on this jar).
Transitive dependencies are no different from other dependencies - are
the bits actually included?
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/16/13 1:14 AM, sebb a écrit :
> Have you seen this?
>
> http://www.apache.org/dev/licensing-howto.html#mod-notice
>
> It suggests that additions to NOTICE should be quite rare.
The NOTICE files just contain the Apache License reference as of today.
The one used for binary contains a ref rto SLF4J and Protobuf, which are
distributed with the bin. I think this corretly fits with the requirements.
The very same for the LICENSE files.
>
> It is important that the N&L files relate to the bits which are
> actually included.
>
> This means that the N&L files at the top level of SVN can be used
> directly for the source archive, as the archive and SVN should
> generally agree (bar maybe the DOAP).
>
> The binary archive may need additional License (and occasionally)
> Notice entries, depending what is additionally bundled.
Yes. It has been corrected yesterday, and I just pushed the modifications.
Btw, I really think that the
http://www.apache.org/dev/licensing-howto.html is far from being easy to
understand for not native english speakers, especially by those who have
not a degree in law school... There are a few use cases that would
benefit the whole community if they were included in this page, like :
- junit, what to do regarding N&L files ?
- slf4j/log4j, what to do regarding N&L files?
- transitive dependencies like cal10n-api.jar (inlcuded by slf4j), what
to do regarding N&L files ? (note that it could be a dependency of
another jar than slf4j, I just picked this one because I know that slf4j
depends on this jar).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by sebb <se...@gmail.com>.
Have you seen this?
http://www.apache.org/dev/licensing-howto.html#mod-notice
It suggests that additions to NOTICE should be quite rare.
It is important that the N&L files relate to the bits which are
actually included.
This means that the N&L files at the top level of SVN can be used
directly for the source archive, as the archive and SVN should
generally agree (bar maybe the DOAP).
The binary archive may need additional License (and occasionally)
Notice entries, depending what is additionally bundled.
In the case of Maven jars, these are usually derived from *parts* of
the source, so some may need simpler N&L files than even the source.
For example if the source contains 3rd party images/icons, SVN and the
source archive will need to take account of those, but the jars that
don't contain the images should not reference them.
On 14 July 2013 22:28, Julien Vermillard <jv...@gmail.com> wrote:
> yes you are right, I made another round of adjustment.
> src NOTICE is empty
> bin NOTICE is filled with slf4j and protobuff
> --
> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>
>
> On Sun, Jul 14, 2013 at 2:32 PM, Ashish <pa...@gmail.com> wrote:
>> On Sun, Jul 14, 2013 at 5:41 PM, Ashish <pa...@gmail.com> wrote:
>>
>>> We only need to add files to NOTICE if we bundle them right?
>>> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>>>
>>> And we need two NOTICE files, one for src and one to bin like in MINA2
>>>
>>
>> Correction: We have both in MINA3 as well :)
>>
>>
>>>
>>> For src, since we don't bundle anything, only simple Notice would do, for
>>> bin distro, we package protobuf & slf4j, along with Apache libs are the
>>> only things needed in notice.
>>>
>>> Sorry for this back and forth, but damn this legal stuff is confusing.
>>>
>>>
>>> On Sun, Jul 14, 2013 at 2:49 PM, Julien Vermillard <jv...@gmail.com>wrote:
>>>
>>>> Updated the files, if anybody could review, thanks :)
>>>> --
>>>> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>>>>
>>>>
>>>> On Thu, Jul 11, 2013 at 11:57 AM, Emmanuel Lécharny <el...@gmail.com>
>>>> wrote:
>>>> > Le 7/11/13 10:43 AM, Julien Vermillard a écrit :
>>>> >> The question is : should we have NOTICE for test dependencies ?
>>>> > I do think so. We do have a NOTICE-bin.txt in MINA 2 which contains a
>>>> > reference to those libs (see below).
>>>> >
>>>> > Reading
>>>> > http://www.apache.org/dev/licensing-howto.html#overview-of-files, here
>>>> > are the few rules we should follow (as I interpret them) :
>>>> >
>>>> > - The file name should be NOTICE, not NOTICE.txt
>>>> > - every dependency we include in a package *must* be listed in the
>>>> > NOTICE file, including the transitive dependencies... (yeah, sorry...)
>>>> > - as we may distribute a package without tests, the associated NOTICE
>>>> > file should not contain the reference to JUNIT, etc. But if we
>>>> > distribute a package containing the tests -and we do- then we must add
>>>> > those dependencies into the NOTICE file. As a matter of fact, we do have
>>>> > 2 NOTICE files in MINA2, to cover those two cases (and we have a
>>>> > specific module to generate those two packages)
>>>> >
>>>> > Hope it helps... And sorry for the burdan !
>>>> >
>>>> >
>>>> >
>>>> ----------------------------------------------------------------------------
>>>> > Apache MINA
>>>> > Copyright 2007-2012 The Apache Software Foundation.
>>>> >
>>>> > This product includes software developed at
>>>> > The Apache Software Foundation (http://www.apache.org/).
>>>> >
>>>> > Please refer to each LICENSE.<component>.txt file for the
>>>> > license terms of the components that Apache MINA depends on.
>>>> >
>>>> > Message logging is provided by the SLF4J library package,
>>>> > which is open source software, written by Ceki Gülcü, and
>>>> > copyright by SLF4J.ORG and QOS.ch. The original software is
>>>> > available from
>>>> >
>>>> > http://www.slf4j.org/
>>>> >
>>>> > Data compression support is provided by the JZLib library package,
>>>> > which is open source software, written by JCraft, and copyright
>>>> > by JCraft. The original software is available from
>>>> >
>>>> > http://www.jcraft.com/jzlib/
>>>> >
>>>> > Spring framework is provided by the Spring framework library
>>>> > package, which is open source software, written by Rod Johnson
>>>> > et al, and copyright by Springframework.org. The original
>>>> > software is available from
>>>> >
>>>> > http://www.springframework.org/
>>>> >
>>>> > OGNL is provided by the OGNL library package, which is open source
>>>> > software, written by Drew Davidson and Luke Blanshard. The original
>>>> > software is available from
>>>> >
>>>> > http://www.ognl.org/
>>>> >
>>>> >
>>>> ----------------------------------------------------------------------------
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >> --
>>>> >> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>>>> >>
>>>> >>
>>>> >> On Thu, Jul 11, 2013 at 12:59 AM, Emmanuel Lécharny <
>>>> elecharny@gmail.com> wrote:
>>>> >>> Le 7/10/13 9:03 PM, Julien Vermillard a écrit :
>>>> >>>> I heard (from Emmanuel I think) we don't need to put notice files for
>>>> >>>> apache products (thrift and log4j).
>>>> >>> Yes. The are apache projects, covered by the MINA NOTICE file. No need
>>>> >>> to add an extra file for each one of them, or to list them all.
>>>> >>>> So (if true) the only missing is netty used for benchmark which is
>>>> >>>> just tests no ?
>>>> >>> slf4j is not an Apache project, AFAICT.
>>>> >>>
>>>> >>> We are also using junit and mockito...
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> Regards,
>>>> >>> Cordialement,
>>>> >>> Emmanuel Lécharny
>>>> >>> www.iktek.com
>>>> >>>
>>>> >
>>>> >
>>>> > --
>>>> > Regards,
>>>> > Cordialement,
>>>> > Emmanuel Lécharny
>>>> > www.iktek.com
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> thanks
>>> ashish
>>>
>>> Blog: http://www.ashishpaliwal.com/blog
>>> My Photo Galleries: http://www.pbase.com/ashishpaliwal
>>>
>>
>>
>>
>> --
>> thanks
>> ashish
>>
>> Blog: http://www.ashishpaliwal.com/blog
>> My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by Julien Vermillard <jv...@gmail.com>.
yes you are right, I made another round of adjustment.
src NOTICE is empty
bin NOTICE is filled with slf4j and protobuff
--
Julien Vermillard :::: http://people.apache.org/~jvermillard/
On Sun, Jul 14, 2013 at 2:32 PM, Ashish <pa...@gmail.com> wrote:
> On Sun, Jul 14, 2013 at 5:41 PM, Ashish <pa...@gmail.com> wrote:
>
>> We only need to add files to NOTICE if we bundle them right?
>> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>>
>> And we need two NOTICE files, one for src and one to bin like in MINA2
>>
>
> Correction: We have both in MINA3 as well :)
>
>
>>
>> For src, since we don't bundle anything, only simple Notice would do, for
>> bin distro, we package protobuf & slf4j, along with Apache libs are the
>> only things needed in notice.
>>
>> Sorry for this back and forth, but damn this legal stuff is confusing.
>>
>>
>> On Sun, Jul 14, 2013 at 2:49 PM, Julien Vermillard <jv...@gmail.com>wrote:
>>
>>> Updated the files, if anybody could review, thanks :)
>>> --
>>> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>>>
>>>
>>> On Thu, Jul 11, 2013 at 11:57 AM, Emmanuel Lécharny <el...@gmail.com>
>>> wrote:
>>> > Le 7/11/13 10:43 AM, Julien Vermillard a écrit :
>>> >> The question is : should we have NOTICE for test dependencies ?
>>> > I do think so. We do have a NOTICE-bin.txt in MINA 2 which contains a
>>> > reference to those libs (see below).
>>> >
>>> > Reading
>>> > http://www.apache.org/dev/licensing-howto.html#overview-of-files, here
>>> > are the few rules we should follow (as I interpret them) :
>>> >
>>> > - The file name should be NOTICE, not NOTICE.txt
>>> > - every dependency we include in a package *must* be listed in the
>>> > NOTICE file, including the transitive dependencies... (yeah, sorry...)
>>> > - as we may distribute a package without tests, the associated NOTICE
>>> > file should not contain the reference to JUNIT, etc. But if we
>>> > distribute a package containing the tests -and we do- then we must add
>>> > those dependencies into the NOTICE file. As a matter of fact, we do have
>>> > 2 NOTICE files in MINA2, to cover those two cases (and we have a
>>> > specific module to generate those two packages)
>>> >
>>> > Hope it helps... And sorry for the burdan !
>>> >
>>> >
>>> >
>>> ----------------------------------------------------------------------------
>>> > Apache MINA
>>> > Copyright 2007-2012 The Apache Software Foundation.
>>> >
>>> > This product includes software developed at
>>> > The Apache Software Foundation (http://www.apache.org/).
>>> >
>>> > Please refer to each LICENSE.<component>.txt file for the
>>> > license terms of the components that Apache MINA depends on.
>>> >
>>> > Message logging is provided by the SLF4J library package,
>>> > which is open source software, written by Ceki Gülcü, and
>>> > copyright by SLF4J.ORG and QOS.ch. The original software is
>>> > available from
>>> >
>>> > http://www.slf4j.org/
>>> >
>>> > Data compression support is provided by the JZLib library package,
>>> > which is open source software, written by JCraft, and copyright
>>> > by JCraft. The original software is available from
>>> >
>>> > http://www.jcraft.com/jzlib/
>>> >
>>> > Spring framework is provided by the Spring framework library
>>> > package, which is open source software, written by Rod Johnson
>>> > et al, and copyright by Springframework.org. The original
>>> > software is available from
>>> >
>>> > http://www.springframework.org/
>>> >
>>> > OGNL is provided by the OGNL library package, which is open source
>>> > software, written by Drew Davidson and Luke Blanshard. The original
>>> > software is available from
>>> >
>>> > http://www.ognl.org/
>>> >
>>> >
>>> ----------------------------------------------------------------------------
>>> >
>>> >
>>> >
>>> >
>>> >> --
>>> >> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>>> >>
>>> >>
>>> >> On Thu, Jul 11, 2013 at 12:59 AM, Emmanuel Lécharny <
>>> elecharny@gmail.com> wrote:
>>> >>> Le 7/10/13 9:03 PM, Julien Vermillard a écrit :
>>> >>>> I heard (from Emmanuel I think) we don't need to put notice files for
>>> >>>> apache products (thrift and log4j).
>>> >>> Yes. The are apache projects, covered by the MINA NOTICE file. No need
>>> >>> to add an extra file for each one of them, or to list them all.
>>> >>>> So (if true) the only missing is netty used for benchmark which is
>>> >>>> just tests no ?
>>> >>> slf4j is not an Apache project, AFAICT.
>>> >>>
>>> >>> We are also using junit and mockito...
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Regards,
>>> >>> Cordialement,
>>> >>> Emmanuel Lécharny
>>> >>> www.iktek.com
>>> >>>
>>> >
>>> >
>>> > --
>>> > Regards,
>>> > Cordialement,
>>> > Emmanuel Lécharny
>>> > www.iktek.com
>>> >
>>>
>>
>>
>>
>> --
>> thanks
>> ashish
>>
>> Blog: http://www.ashishpaliwal.com/blog
>> My Photo Galleries: http://www.pbase.com/ashishpaliwal
>>
>
>
>
> --
> thanks
> ashish
>
> Blog: http://www.ashishpaliwal.com/blog
> My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by Ashish <pa...@gmail.com>.
On Sun, Jul 14, 2013 at 5:41 PM, Ashish <pa...@gmail.com> wrote:
> We only need to add files to NOTICE if we bundle them right?
> http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>
> And we need two NOTICE files, one for src and one to bin like in MINA2
>
Correction: We have both in MINA3 as well :)
>
> For src, since we don't bundle anything, only simple Notice would do, for
> bin distro, we package protobuf & slf4j, along with Apache libs are the
> only things needed in notice.
>
> Sorry for this back and forth, but damn this legal stuff is confusing.
>
>
> On Sun, Jul 14, 2013 at 2:49 PM, Julien Vermillard <jv...@gmail.com>wrote:
>
>> Updated the files, if anybody could review, thanks :)
>> --
>> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>>
>>
>> On Thu, Jul 11, 2013 at 11:57 AM, Emmanuel Lécharny <el...@gmail.com>
>> wrote:
>> > Le 7/11/13 10:43 AM, Julien Vermillard a écrit :
>> >> The question is : should we have NOTICE for test dependencies ?
>> > I do think so. We do have a NOTICE-bin.txt in MINA 2 which contains a
>> > reference to those libs (see below).
>> >
>> > Reading
>> > http://www.apache.org/dev/licensing-howto.html#overview-of-files, here
>> > are the few rules we should follow (as I interpret them) :
>> >
>> > - The file name should be NOTICE, not NOTICE.txt
>> > - every dependency we include in a package *must* be listed in the
>> > NOTICE file, including the transitive dependencies... (yeah, sorry...)
>> > - as we may distribute a package without tests, the associated NOTICE
>> > file should not contain the reference to JUNIT, etc. But if we
>> > distribute a package containing the tests -and we do- then we must add
>> > those dependencies into the NOTICE file. As a matter of fact, we do have
>> > 2 NOTICE files in MINA2, to cover those two cases (and we have a
>> > specific module to generate those two packages)
>> >
>> > Hope it helps... And sorry for the burdan !
>> >
>> >
>> >
>> ----------------------------------------------------------------------------
>> > Apache MINA
>> > Copyright 2007-2012 The Apache Software Foundation.
>> >
>> > This product includes software developed at
>> > The Apache Software Foundation (http://www.apache.org/).
>> >
>> > Please refer to each LICENSE.<component>.txt file for the
>> > license terms of the components that Apache MINA depends on.
>> >
>> > Message logging is provided by the SLF4J library package,
>> > which is open source software, written by Ceki Gülcü, and
>> > copyright by SLF4J.ORG and QOS.ch. The original software is
>> > available from
>> >
>> > http://www.slf4j.org/
>> >
>> > Data compression support is provided by the JZLib library package,
>> > which is open source software, written by JCraft, and copyright
>> > by JCraft. The original software is available from
>> >
>> > http://www.jcraft.com/jzlib/
>> >
>> > Spring framework is provided by the Spring framework library
>> > package, which is open source software, written by Rod Johnson
>> > et al, and copyright by Springframework.org. The original
>> > software is available from
>> >
>> > http://www.springframework.org/
>> >
>> > OGNL is provided by the OGNL library package, which is open source
>> > software, written by Drew Davidson and Luke Blanshard. The original
>> > software is available from
>> >
>> > http://www.ognl.org/
>> >
>> >
>> ----------------------------------------------------------------------------
>> >
>> >
>> >
>> >
>> >> --
>> >> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>> >>
>> >>
>> >> On Thu, Jul 11, 2013 at 12:59 AM, Emmanuel Lécharny <
>> elecharny@gmail.com> wrote:
>> >>> Le 7/10/13 9:03 PM, Julien Vermillard a écrit :
>> >>>> I heard (from Emmanuel I think) we don't need to put notice files for
>> >>>> apache products (thrift and log4j).
>> >>> Yes. The are apache projects, covered by the MINA NOTICE file. No need
>> >>> to add an extra file for each one of them, or to list them all.
>> >>>> So (if true) the only missing is netty used for benchmark which is
>> >>>> just tests no ?
>> >>> slf4j is not an Apache project, AFAICT.
>> >>>
>> >>> We are also using junit and mockito...
>> >>>
>> >>>
>> >>> --
>> >>> Regards,
>> >>> Cordialement,
>> >>> Emmanuel Lécharny
>> >>> www.iktek.com
>> >>>
>> >
>> >
>> > --
>> > Regards,
>> > Cordialement,
>> > Emmanuel Lécharny
>> > www.iktek.com
>> >
>>
>
>
>
> --
> thanks
> ashish
>
> Blog: http://www.ashishpaliwal.com/blog
> My Photo Galleries: http://www.pbase.com/ashishpaliwal
>
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by Ashish <pa...@gmail.com>.
We only need to add files to NOTICE if we bundle them right?
http://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
And we need two NOTICE files, one for src and one to bin like in MINA2
For src, since we don't bundle anything, only simple Notice would do, for
bin distro, we package protobuf & slf4j, along with Apache libs are the
only things needed in notice.
Sorry for this back and forth, but damn this legal stuff is confusing.
On Sun, Jul 14, 2013 at 2:49 PM, Julien Vermillard <jv...@gmail.com>wrote:
> Updated the files, if anybody could review, thanks :)
> --
> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>
>
> On Thu, Jul 11, 2013 at 11:57 AM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
> > Le 7/11/13 10:43 AM, Julien Vermillard a écrit :
> >> The question is : should we have NOTICE for test dependencies ?
> > I do think so. We do have a NOTICE-bin.txt in MINA 2 which contains a
> > reference to those libs (see below).
> >
> > Reading
> > http://www.apache.org/dev/licensing-howto.html#overview-of-files, here
> > are the few rules we should follow (as I interpret them) :
> >
> > - The file name should be NOTICE, not NOTICE.txt
> > - every dependency we include in a package *must* be listed in the
> > NOTICE file, including the transitive dependencies... (yeah, sorry...)
> > - as we may distribute a package without tests, the associated NOTICE
> > file should not contain the reference to JUNIT, etc. But if we
> > distribute a package containing the tests -and we do- then we must add
> > those dependencies into the NOTICE file. As a matter of fact, we do have
> > 2 NOTICE files in MINA2, to cover those two cases (and we have a
> > specific module to generate those two packages)
> >
> > Hope it helps... And sorry for the burdan !
> >
> >
> >
> ----------------------------------------------------------------------------
> > Apache MINA
> > Copyright 2007-2012 The Apache Software Foundation.
> >
> > This product includes software developed at
> > The Apache Software Foundation (http://www.apache.org/).
> >
> > Please refer to each LICENSE.<component>.txt file for the
> > license terms of the components that Apache MINA depends on.
> >
> > Message logging is provided by the SLF4J library package,
> > which is open source software, written by Ceki Gülcü, and
> > copyright by SLF4J.ORG and QOS.ch. The original software is
> > available from
> >
> > http://www.slf4j.org/
> >
> > Data compression support is provided by the JZLib library package,
> > which is open source software, written by JCraft, and copyright
> > by JCraft. The original software is available from
> >
> > http://www.jcraft.com/jzlib/
> >
> > Spring framework is provided by the Spring framework library
> > package, which is open source software, written by Rod Johnson
> > et al, and copyright by Springframework.org. The original
> > software is available from
> >
> > http://www.springframework.org/
> >
> > OGNL is provided by the OGNL library package, which is open source
> > software, written by Drew Davidson and Luke Blanshard. The original
> > software is available from
> >
> > http://www.ognl.org/
> >
> >
> ----------------------------------------------------------------------------
> >
> >
> >
> >
> >> --
> >> Julien Vermillard :::: http://people.apache.org/~jvermillard/
> >>
> >>
> >> On Thu, Jul 11, 2013 at 12:59 AM, Emmanuel Lécharny <
> elecharny@gmail.com> wrote:
> >>> Le 7/10/13 9:03 PM, Julien Vermillard a écrit :
> >>>> I heard (from Emmanuel I think) we don't need to put notice files for
> >>>> apache products (thrift and log4j).
> >>> Yes. The are apache projects, covered by the MINA NOTICE file. No need
> >>> to add an extra file for each one of them, or to list them all.
> >>>> So (if true) the only missing is netty used for benchmark which is
> >>>> just tests no ?
> >>> slf4j is not an Apache project, AFAICT.
> >>>
> >>> We are also using junit and mockito...
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Cordialement,
> >>> Emmanuel Lécharny
> >>> www.iktek.com
> >>>
> >
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
>
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by Julien Vermillard <jv...@gmail.com>.
Updated the files, if anybody could review, thanks :)
--
Julien Vermillard :::: http://people.apache.org/~jvermillard/
On Thu, Jul 11, 2013 at 11:57 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 7/11/13 10:43 AM, Julien Vermillard a écrit :
>> The question is : should we have NOTICE for test dependencies ?
> I do think so. We do have a NOTICE-bin.txt in MINA 2 which contains a
> reference to those libs (see below).
>
> Reading
> http://www.apache.org/dev/licensing-howto.html#overview-of-files, here
> are the few rules we should follow (as I interpret them) :
>
> - The file name should be NOTICE, not NOTICE.txt
> - every dependency we include in a package *must* be listed in the
> NOTICE file, including the transitive dependencies... (yeah, sorry...)
> - as we may distribute a package without tests, the associated NOTICE
> file should not contain the reference to JUNIT, etc. But if we
> distribute a package containing the tests -and we do- then we must add
> those dependencies into the NOTICE file. As a matter of fact, we do have
> 2 NOTICE files in MINA2, to cover those two cases (and we have a
> specific module to generate those two packages)
>
> Hope it helps... And sorry for the burdan !
>
>
> ----------------------------------------------------------------------------
> Apache MINA
> Copyright 2007-2012 The Apache Software Foundation.
>
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
>
> Please refer to each LICENSE.<component>.txt file for the
> license terms of the components that Apache MINA depends on.
>
> Message logging is provided by the SLF4J library package,
> which is open source software, written by Ceki Gülcü, and
> copyright by SLF4J.ORG and QOS.ch. The original software is
> available from
>
> http://www.slf4j.org/
>
> Data compression support is provided by the JZLib library package,
> which is open source software, written by JCraft, and copyright
> by JCraft. The original software is available from
>
> http://www.jcraft.com/jzlib/
>
> Spring framework is provided by the Spring framework library
> package, which is open source software, written by Rod Johnson
> et al, and copyright by Springframework.org. The original
> software is available from
>
> http://www.springframework.org/
>
> OGNL is provided by the OGNL library package, which is open source
> software, written by Drew Davidson and Luke Blanshard. The original
> software is available from
>
> http://www.ognl.org/
>
> ----------------------------------------------------------------------------
>
>
>
>
>> --
>> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>>
>>
>> On Thu, Jul 11, 2013 at 12:59 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>>> Le 7/10/13 9:03 PM, Julien Vermillard a écrit :
>>>> I heard (from Emmanuel I think) we don't need to put notice files for
>>>> apache products (thrift and log4j).
>>> Yes. The are apache projects, covered by the MINA NOTICE file. No need
>>> to add an extra file for each one of them, or to list them all.
>>>> So (if true) the only missing is netty used for benchmark which is
>>>> just tests no ?
>>> slf4j is not an Apache project, AFAICT.
>>>
>>> We are also using junit and mockito...
>>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
[MINA3] NOTICE content (was Re: [VOTE] release Apache MINA 3.0.0-M1)
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/11/13 10:43 AM, Julien Vermillard a écrit :
> The question is : should we have NOTICE for test dependencies ?
I do think so. We do have a NOTICE-bin.txt in MINA 2 which contains a
reference to those libs (see below).
Reading
http://www.apache.org/dev/licensing-howto.html#overview-of-files, here
are the few rules we should follow (as I interpret them) :
- The file name should be NOTICE, not NOTICE.txt
- every dependency we include in a package *must* be listed in the
NOTICE file, including the transitive dependencies... (yeah, sorry...)
- as we may distribute a package without tests, the associated NOTICE
file should not contain the reference to JUNIT, etc. But if we
distribute a package containing the tests -and we do- then we must add
those dependencies into the NOTICE file. As a matter of fact, we do have
2 NOTICE files in MINA2, to cover those two cases (and we have a
specific module to generate those two packages)
Hope it helps... And sorry for the burdan !
----------------------------------------------------------------------------
Apache MINA
Copyright 2007-2012 The Apache Software Foundation.
This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
Please refer to each LICENSE.<component>.txt file for the
license terms of the components that Apache MINA depends on.
Message logging is provided by the SLF4J library package,
which is open source software, written by Ceki Gülcü, and
copyright by SLF4J.ORG and QOS.ch. The original software is
available from
http://www.slf4j.org/
Data compression support is provided by the JZLib library package,
which is open source software, written by JCraft, and copyright
by JCraft. The original software is available from
http://www.jcraft.com/jzlib/
Spring framework is provided by the Spring framework library
package, which is open source software, written by Rod Johnson
et al, and copyright by Springframework.org. The original
software is available from
http://www.springframework.org/
OGNL is provided by the OGNL library package, which is open source
software, written by Drew Davidson and Luke Blanshard. The original
software is available from
http://www.ognl.org/
----------------------------------------------------------------------------
> --
> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>
>
> On Thu, Jul 11, 2013 at 12:59 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
>> Le 7/10/13 9:03 PM, Julien Vermillard a écrit :
>>> I heard (from Emmanuel I think) we don't need to put notice files for
>>> apache products (thrift and log4j).
>> Yes. The are apache projects, covered by the MINA NOTICE file. No need
>> to add an extra file for each one of them, or to list them all.
>>> So (if true) the only missing is netty used for benchmark which is
>>> just tests no ?
>> slf4j is not an Apache project, AFAICT.
>>
>> We are also using junit and mockito...
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] release Apache MINA 3.0.0-M1
Posted by Julien Vermillard <jv...@gmail.com>.
The question is : should we have NOTICE for test dependencies ?
--
Julien Vermillard :::: http://people.apache.org/~jvermillard/
On Thu, Jul 11, 2013 at 12:59 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Le 7/10/13 9:03 PM, Julien Vermillard a écrit :
>> I heard (from Emmanuel I think) we don't need to put notice files for
>> apache products (thrift and log4j).
> Yes. The are apache projects, covered by the MINA NOTICE file. No need
> to add an extra file for each one of them, or to list them all.
>>
>> So (if true) the only missing is netty used for benchmark which is
>> just tests no ?
>
> slf4j is not an Apache project, AFAICT.
>
> We are also using junit and mockito...
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: [VOTE] release Apache MINA 3.0.0-M1
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/10/13 9:03 PM, Julien Vermillard a écrit :
> I heard (from Emmanuel I think) we don't need to put notice files for
> apache products (thrift and log4j).
Yes. The are apache projects, covered by the MINA NOTICE file. No need
to add an extra file for each one of them, or to list them all.
>
> So (if true) the only missing is netty used for benchmark which is
> just tests no ?
slf4j is not an Apache project, AFAICT.
We are also using junit and mockito...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] release Apache MINA 3.0.0-M1
Posted by Julien Vermillard <jv...@gmail.com>.
I heard (from Emmanuel I think) we don't need to put notice files for
apache products (thrift and log4j).
So (if true) the only missing is netty used for benchmark which is
just tests no ?
--
Julien Vermillard :::: http://people.apache.org/~jvermillard/
On Wed, Jul 10, 2013 at 8:01 AM, Ashish <pa...@gmail.com> wrote:
> Build works fine, Rat check passes.
>
> Licence file needs to be updated to have entry for Netty, Log4j and Thrift
> are missing. Need to be added.
>
> Also do we need to provided .bz2 files as well? Most projects I have seen
> don't provide this.
> Haven't verified the signatures yet. I remember KEYS being moved to some
> central place. Not sure where.
>
>
> On Tue, Jul 9, 2013 at 7:57 PM, Julien Vermillard <jv...@gmail.com>wrote:
>
>> Hi !
>>
>> Here the first milestone release for MINA 3.
>>
>> Please take a look at the artifact here :
>> http://people.apache.org/~jvermillard/mina-3.0.0-M1-vote/
>>
>> and vote :
>>
>> [ ] +1 release Apache MINA 3.0.0-M1
>> [ ] +0 I don't care
>> [ ] -1 don't release !
>> --
>> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>>
>
>
>
> --
> thanks
> ashish
>
> Blog: http://www.ashishpaliwal.com/blog
> My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [VOTE] release Apache MINA 3.0.0-M1
Posted by Julien Vermillard <jv...@gmail.com>.
ok, let's cancel the vote and revert the release for fixing NOTICE files.
--
Julien Vermillard :::: http://people.apache.org/~jvermillard/
On Wed, Jul 10, 2013 at 10:36 AM, Julien Vermillard
<jv...@gmail.com> wrote:
> Keys file are here : http://apache.org/dist/mina/KEYS
> --
> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>
>
> On Wed, Jul 10, 2013 at 8:01 AM, Ashish <pa...@gmail.com> wrote:
>> Build works fine, Rat check passes.
>>
>> Licence file needs to be updated to have entry for Netty, Log4j and Thrift
>> are missing. Need to be added.
>>
>> Also do we need to provided .bz2 files as well? Most projects I have seen
>> don't provide this.
>> Haven't verified the signatures yet. I remember KEYS being moved to some
>> central place. Not sure where.
>>
>>
>> On Tue, Jul 9, 2013 at 7:57 PM, Julien Vermillard <jv...@gmail.com>wrote:
>>
>>> Hi !
>>>
>>> Here the first milestone release for MINA 3.
>>>
>>> Please take a look at the artifact here :
>>> http://people.apache.org/~jvermillard/mina-3.0.0-M1-vote/
>>>
>>> and vote :
>>>
>>> [ ] +1 release Apache MINA 3.0.0-M1
>>> [ ] +0 I don't care
>>> [ ] -1 don't release !
>>> --
>>> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>>>
>>
>>
>>
>> --
>> thanks
>> ashish
>>
>> Blog: http://www.ashishpaliwal.com/blog
>> My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [VOTE] release Apache MINA 3.0.0-M1
Posted by Julien Vermillard <jv...@gmail.com>.
Keys file are here : http://apache.org/dist/mina/KEYS
--
Julien Vermillard :::: http://people.apache.org/~jvermillard/
On Wed, Jul 10, 2013 at 8:01 AM, Ashish <pa...@gmail.com> wrote:
> Build works fine, Rat check passes.
>
> Licence file needs to be updated to have entry for Netty, Log4j and Thrift
> are missing. Need to be added.
>
> Also do we need to provided .bz2 files as well? Most projects I have seen
> don't provide this.
> Haven't verified the signatures yet. I remember KEYS being moved to some
> central place. Not sure where.
>
>
> On Tue, Jul 9, 2013 at 7:57 PM, Julien Vermillard <jv...@gmail.com>wrote:
>
>> Hi !
>>
>> Here the first milestone release for MINA 3.
>>
>> Please take a look at the artifact here :
>> http://people.apache.org/~jvermillard/mina-3.0.0-M1-vote/
>>
>> and vote :
>>
>> [ ] +1 release Apache MINA 3.0.0-M1
>> [ ] +0 I don't care
>> [ ] -1 don't release !
>> --
>> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>>
>
>
>
> --
> thanks
> ashish
>
> Blog: http://www.ashishpaliwal.com/blog
> My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [VOTE] release Apache MINA 3.0.0-M1
Posted by Ashish <pa...@gmail.com>.
Build works fine, Rat check passes.
Licence file needs to be updated to have entry for Netty, Log4j and Thrift
are missing. Need to be added.
Also do we need to provided .bz2 files as well? Most projects I have seen
don't provide this.
Haven't verified the signatures yet. I remember KEYS being moved to some
central place. Not sure where.
On Tue, Jul 9, 2013 at 7:57 PM, Julien Vermillard <jv...@gmail.com>wrote:
> Hi !
>
> Here the first milestone release for MINA 3.
>
> Please take a look at the artifact here :
> http://people.apache.org/~jvermillard/mina-3.0.0-M1-vote/
>
> and vote :
>
> [ ] +1 release Apache MINA 3.0.0-M1
> [ ] +0 I don't care
> [ ] -1 don't release !
> --
> Julien Vermillard :::: http://people.apache.org/~jvermillard/
>
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal