incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Multi-licensed dependencies
Date Fri, 30 Mar 2012 18:08:43 GMT
On 30 March 2012 17:38, Leo Simons <> wrote:
> On Thu, Mar 29, 2012 at 8:42 PM, sebb <> wrote:
>> On 29 March 2012 18:43, Roy T. Fielding <> 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
>>>> 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]
> ...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

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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message