You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2012/03/29 18:17:13 UTC
Multi-licensed dependencies
On Thu, Mar 29, 2012 at 7:07 AM, Fabian Christ
<ch...@googlemail.com> wrote:
> Am 26. März 2012 17:20 schrieb Roy T. Fielding <fi...@gbiv.com>:
>> On Mar 26, 2012, at 4:41 PM, Karl Wright wrote:
>>> On Mon, Mar 26, 2012 at 10:24 AM, sebb <se...@gmail.com> wrote:
>>>> On 26 March 2012 02:38, Shinichiro Abe <sh...@gmail.com> wrote:
>>>> The LICENSE file includes references to lots of jars that are dual
>>>> licensed under CDDL v1.0 and GPL v2.
>>>> However, there is no indication which license has been chosen by the project.
>>>>
>>>> I think this is a blocker.
>>
>> A project does not choose a license. The license is provided by the copyright
>> owner. We do not change that license, nor do we reduce the number of the
>> available licenses to choose from, for downstream recipients. Therefore,
>> it doesn't make any sense to indicate which one is "chosen".
>>
>
> I am following all these discussions for doing a first release of
> Apache Stanbol (incubating) but get totally confused. According to
>
> http://apache.org/legal/resolved.html#mutually-exclusive
>
> you have to choose the license and include only the license that you
> have chosen.
Hi, Fabian,
With Roy objecting to the practice codified in that documentation, it seems as
though we no longer have consensus in either the Incubator PMC or the ASF at
large as to what you ought to do. For the time being, I suggest you do either
one. :)
If an Incubator PMC member feels strongly enough about this issue -- either
way -- and believes that it should block all future affected releases, please
speak up on this thread. Otherwise, we should accept that in the absence of
consensus, we can advise but should not vote -1 on a given release candidate
until the matter is resolved.
Personally, I agree with Roy. Perhaps it might seem a little odd to include
the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more
permissive license), but the key here is that it is both legally OK for us to
distribute a product bundling such a dependency without explicitly justifying
our usage, and legally OK for a downstream consumer to distribute a product
bundling ours which asserts usage of the dependency under a different
rationale.
Regarding the current documented recommendation, though, I don't think it is
actively harmful, because I don't believe we are doing anything which violates
the terms under which multi-licensed products are typically made available.
Therefore, in my opinion we can put this controversy in a queue for
legal-discuss@a.o, to be dealt with after the more pressing matter of bundled
jar files. :)
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Multi-licensed dependencies
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 29, 2012, at 9:37 PM, Marvin Humphrey wrote:
> On Thu, Mar 29, 2012 at 11:42 AM, sebb <se...@gmail.com> wrote:
>> On 29 March 2012 18:43, Roy T. Fielding <fi...@gbiv.com> wrote:
>
>>> I prefer to put our license in the file and then, at the bottom, refer
>>> to a list of other licenses per dependency (if included in this package),
>>> wherein the dependency licenses are in separate files near the dependency.
>>
>> However, this does not agree with the following [1]:
>>
>>>>>
>> ...
>> When an artifact contains code under several licenses, the LICENSE
>> file should contain details of all these licenses. For each component
>> which is not Apache licensed, details of the component and the license
>> under which the component is distributed should be appended to the
>> LICENSE file.
>> <<<
>>
>> [1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses
Pointers are sufficient.
> It is also at odds with the Apache HTTPD LICENSE file we've been treating as a
> canonical sample. The documentation on www.apache.org/dev may have been
> contaminated by well-meaning volunteers and changed from Roy's original
> meaning, but I assume that the HTTPD LICENSE and NOTICE files haven't gotten
> away from him and are still 100% consonant with both the letter and the intent
> of the ALv2.
I know more about the letter and intent of the ASF's license and licensing
policy than anyone else at the foundation. This was discussed and approved
on the licensing list some time ago.
> While Roy's suggestion of referencing licenses spread over multiple files
> seems like a perfectly sane alternative, I'd argue against documenting it as
> best practice unless HTTPD changes their LICENSE file to match.
httpd's license refers to small snippets of code all over the tree; all of
the licenses are fairly close to BSD. It is simply more convenient to
list all of those in one place. Inclusion of entire jar files is different.
As is including huge and nasty license files, like the GPL. You do not
want to mix all those licenses together, particularly since most of those
licenses won't be included in your source distributions.
Also, you cannot mix the GPL license in with the others. We are
not shipping a combined work as GPL. We can ship an aggregated work, wherein
the aggregation consists of separate components in separate directories
with their own license files, or we can ship an overlayed work -- where
the GPL distribution is unpacked on top of an Apache-licensed distribution.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Multi-licensed dependencies
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Mar 29, 2012 at 11:42 AM, sebb <se...@gmail.com> wrote:
> On 29 March 2012 18:43, Roy T. Fielding <fi...@gbiv.com> wrote:
>> I prefer to put our license in the file and then, at the bottom, refer
>> to a list of other licenses per dependency (if included in this package),
>> wherein the dependency licenses are in separate files near the dependency.
>
> However, this does not agree with the following [1]:
>
>>>>
> ...
> When an artifact contains code under several licenses, the LICENSE
> file should contain details of all these licenses. For each component
> which is not Apache licensed, details of the component and the license
> under which the component is distributed should be appended to the
> LICENSE file.
> <<<
>
> [1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses
It is also at odds with the Apache HTTPD LICENSE file we've been treating as a
canonical sample. The documentation on www.apache.org/dev may have been
contaminated by well-meaning volunteers and changed from Roy's original
meaning, but I assume that the HTTPD LICENSE and NOTICE files haven't gotten
away from him and are still 100% consonant with both the letter and the intent
of the ALv2.
While Roy's suggestion of referencing licenses spread over multiple files
seems like a perfectly sane alternative, I'd argue against documenting it as
best practice unless HTTPD changes their LICENSE file to match.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Multi-licensed dependencies
Posted by Rob Weir <ro...@apache.org>.
On Fri, Mar 30, 2012 at 2:08 PM, sebb <se...@gmail.com> wrote:
> On 30 March 2012 17:38, Leo Simons <ma...@leosimons.com> wrote:
> > On Thu, Mar 29, 2012 at 8:42 PM, sebb <se...@gmail.com> wrote:
> >> On 29 March 2012 18:43, Roy T. Fielding <fi...@gbiv.com> wrote:
> >>> On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote:
> >>>> Personally, I agree with Roy. Perhaps it might seem a little odd to
> include
> >>>> the text of e.g. the GPLv2 in one of our LICENSE files (alongside a
> more
> >>>> permissive license), but the key here is that it is both legally OK
> for us to
> >>>> distribute a product bundling such a dependency without explicitly
> justifying
> >>>> our usage, and legally OK for a downstream consumer to distribute a
> product
> >>>> bundling ours which asserts usage of the dependency under a different
> >>>> rationale.
> >>>
> >>> I prefer to put our license in the file and then, at the bottom, refer
> >>> to a list of other licenses per dependency (if included in this
> package),
> >>> wherein the dependency licenses are in separate files near the
> dependency.
> >>
> >> However, this does not agree with the following [1]:
> >>
> >>>>>
> >> ...
> >> When an artifact contains code under several licenses, the LICENSE
> >> file should contain details of all these licenses. For each component
> >> which is not Apache licensed, details of the component and the license
> >> under which the component is distributed should be appended to the
> >> LICENSE file.
> >> <<<
> >>
> >> [1]
> http://www.apache.org/dev/release.html#distributing-code-under-several-licenses
> >
> > ...the license file SHOULD contain ...
> >
> > I believe at least some of these
> > how-to-put-the-license(s)-into-the-file(s) statements are not
> > necessarily backed up by "it must be this way legally" or "this is
> > unambiguously always the best way" kind of thoughts, but more by "this
> > is a good standard way to do it, that is easy to do and
> > (automatically) verify". So Roy saying "I prefer" does not necessarily
> > conflict with the SHOULD in the policy.
> >
> > I very much like the approach where the Incubator teaches the
> > documented policies that have been defined by Legal. While it's
> > probably good to have Roy's preferences (which I trust are good ones)
> > reflected in our policy docs, that should happen via legal-discuss in
> > this case, and even after that,
> > we should not change what we teach our podlings
>
> This is precisely the issue - there is no single unified message at
> present.
> The approach depends a lot on who happens to be mentoring/reviewing
> releases.
>
> > until the docs have changed. It gets way too confusing way
> > too quickly, otherwise.
>
> It's already confusing.
>
> Nor do the documents have a single - or even consistent - approach.
>
> I think a lot of this stems from the fact that the documents tend to
> describe processes and procedures without providing the underlying
> rationale.
>
>
+1 That is the key observation. We need more principles, agreed on and
documented, than we need more policies and rules.
For example, the core licensing criteria makes a simple but solid statement
that has allowed us to adapt to the changing licensing landscape by
applying these principles to new situations:
http://www.apache.org/legal/resolved.html#criteria
It would be great if we had similar compact statement on the intent of
LICENSE and NOTICE.
-Rob
> The statement from Roy about open source and the ASF incorporation was
> very useful in understanding the existing doumentation.
>
> I think the foundation assumptions need to be clearly documented so
> the derived processes and rules can be better understood.
>
> >
> > cheerio,
> >
> >
> > Leo
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Multi-licensed dependencies
Posted by sebb <se...@gmail.com>.
On 30 March 2012 17:38, Leo Simons <ma...@leosimons.com> wrote:
> On Thu, Mar 29, 2012 at 8:42 PM, sebb <se...@gmail.com> wrote:
>> On 29 March 2012 18:43, Roy T. Fielding <fi...@gbiv.com> wrote:
>>> On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote:
>>>> Personally, I agree with Roy. Perhaps it might seem a little odd to include
>>>> the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more
>>>> permissive license), but the key here is that it is both legally OK for us to
>>>> distribute a product bundling such a dependency without explicitly justifying
>>>> our usage, and legally OK for a downstream consumer to distribute a product
>>>> bundling ours which asserts usage of the dependency under a different
>>>> rationale.
>>>
>>> I prefer to put our license in the file and then, at the bottom, refer
>>> to a list of other licenses per dependency (if included in this package),
>>> wherein the dependency licenses are in separate files near the dependency.
>>
>> However, this does not agree with the following [1]:
>>
>>>>>
>> ...
>> When an artifact contains code under several licenses, the LICENSE
>> file should contain details of all these licenses. For each component
>> which is not Apache licensed, details of the component and the license
>> under which the component is distributed should be appended to the
>> LICENSE file.
>> <<<
>>
>> [1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses
>
> ...the license file SHOULD contain ...
>
> I believe at least some of these
> how-to-put-the-license(s)-into-the-file(s) statements are not
> necessarily backed up by "it must be this way legally" or "this is
> unambiguously always the best way" kind of thoughts, but more by "this
> is a good standard way to do it, that is easy to do and
> (automatically) verify". So Roy saying "I prefer" does not necessarily
> conflict with the SHOULD in the policy.
>
> I very much like the approach where the Incubator teaches the
> documented policies that have been defined by Legal. While it's
> probably good to have Roy's preferences (which I trust are good ones)
> reflected in our policy docs, that should happen via legal-discuss in
> this case, and even after that,
> we should not change what we teach our podlings
This is precisely the issue - there is no single unified message at present.
The approach depends a lot on who happens to be mentoring/reviewing releases.
> until the docs have changed. It gets way too confusing way
> too quickly, otherwise.
It's already confusing.
Nor do the documents have a single - or even consistent - approach.
I think a lot of this stems from the fact that the documents tend to
describe processes and procedures without providing the underlying
rationale.
The statement from Roy about open source and the ASF incorporation was
very useful in understanding the existing doumentation.
I think the foundation assumptions need to be clearly documented so
the derived processes and rules can be better understood.
>
> cheerio,
>
>
> Leo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Multi-licensed dependencies
Posted by Leo Simons <ma...@leosimons.com>.
On Thu, Mar 29, 2012 at 8:42 PM, sebb <se...@gmail.com> wrote:
> On 29 March 2012 18:43, Roy T. Fielding <fi...@gbiv.com> wrote:
>> On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote:
>>> Personally, I agree with Roy. Perhaps it might seem a little odd to include
>>> the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more
>>> permissive license), but the key here is that it is both legally OK for us to
>>> distribute a product bundling such a dependency without explicitly justifying
>>> our usage, and legally OK for a downstream consumer to distribute a product
>>> bundling ours which asserts usage of the dependency under a different
>>> rationale.
>>
>> I prefer to put our license in the file and then, at the bottom, refer
>> to a list of other licenses per dependency (if included in this package),
>> wherein the dependency licenses are in separate files near the dependency.
>
> However, this does not agree with the following [1]:
>
>>>>
> ...
> When an artifact contains code under several licenses, the LICENSE
> file should contain details of all these licenses. For each component
> which is not Apache licensed, details of the component and the license
> under which the component is distributed should be appended to the
> LICENSE file.
> <<<
>
> [1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses
...the license file SHOULD contain ...
I believe at least some of these
how-to-put-the-license(s)-into-the-file(s) statements are not
necessarily backed up by "it must be this way legally" or "this is
unambiguously always the best way" kind of thoughts, but more by "this
is a good standard way to do it, that is easy to do and
(automatically) verify". So Roy saying "I prefer" does not necessarily
conflict with the SHOULD in the policy.
I very much like the approach where the Incubator teaches the
documented policies that have been defined by Legal. While it's
probably good to have Roy's preferences (which I trust are good ones)
reflected in our policy docs, that should happen via legal-discuss in
this case, and even after that, we should not change what we teach our
podlings until the docs have changed. It gets way too confusing way
too quickly, otherwise.
cheerio,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Multi-licensed dependencies
Posted by sebb <se...@gmail.com>.
On 29 March 2012 18:43, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote:
>> Personally, I agree with Roy. Perhaps it might seem a little odd to include
>> the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more
>> permissive license), but the key here is that it is both legally OK for us to
>> distribute a product bundling such a dependency without explicitly justifying
>> our usage, and legally OK for a downstream consumer to distribute a product
>> bundling ours which asserts usage of the dependency under a different
>> rationale.
>
> I prefer to put our license in the file and then, at the bottom, refer
> to a list of other licenses per dependency (if included in this package),
> wherein the dependency licenses are in separate files near the dependency.
However, this does not agree with the following [1]:
>>>
...
When an artifact contains code under several licenses, the LICENSE
file should contain details of all these licenses. For each component
which is not Apache licensed, details of the component and the license
under which the component is distributed should be appended to the
LICENSE file.
<<<
[1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses
> ....Roy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Multi-licensed dependencies
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote:
> Personally, I agree with Roy. Perhaps it might seem a little odd to include
> the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more
> permissive license), but the key here is that it is both legally OK for us to
> distribute a product bundling such a dependency without explicitly justifying
> our usage, and legally OK for a downstream consumer to distribute a product
> bundling ours which asserts usage of the dependency under a different
> rationale.
I prefer to put our license in the file and then, at the bottom, refer
to a list of other licenses per dependency (if included in this package),
wherein the dependency licenses are in separate files near the dependency.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org