incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Multi-licensed dependencies
Date Sat, 31 Mar 2012 13:38:02 GMT
On Fri, Mar 30, 2012 at 2:08 PM, sebb <sebbaz@gmail.com> wrote:

> On 30 March 2012 17:38, Leo Simons <mail@leosimons.com> wrote:
> > On Thu, Mar 29, 2012 at 8:42 PM, sebb <sebbaz@gmail.com> wrote:
> >> On 29 March 2012 18:43, Roy T. Fielding <fielding@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message