You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by sebb <se...@gmail.com> on 2019/03/09 12:15:47 UTC
Re: Clarifiying our license criteria
It would also be very useful to document the *intent* of the rules, e.g.
"What we really want is for downstream consumers to feel safe that any
product originating from us is available under the terms of the ALv2."
This makes it easier to understand - and change if requirements change.
An analogy:
Rule: "vehicles must drive on the right"
Rationale/Intent: "vehicles travelling in opposite directions should
be able to pass each other safely"
This allows for the alternative:
Rule: "vehicles must drive on the left"
On Wed, 20 Feb 2019 at 15:40, Shane Curcuru <as...@shanecurcuru.org> wrote:
>
> Marvin Humphrey wrote on 2/20/19 10:26 AM:
> > On Tue, Feb 19, 2019 at 10:48 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >>
> >> Marvin Humphrey wrote on Tue, Feb 19, 2019 at 08:48:45 -0800:
> >
> >>> 2. The license, as applied in practice, must not impose significant
> >>> restrictions beyond those imposed by the Apache License 2.0.
> >>
> >> How about s/as applied in practice//?
> ...snip...
>
> > Ralph Goers puts it like this in the 2008 thread I referenced earlier:
> >
> > https://markmail.org/message/624q772go45oplyj
> >
> > Part of the consideration is not only what the license is but how the
> > third party component is used. There are cases where use of a GPL
> > component may be allowed and there are cases where the LGPL will be
> > disallowed.
> >
> > The phrase "as applied in practice" attempts to take that intent into account:
> > the license gets applied in specific context, and sometimes that context
> > allows for licenses which which we would not allow in other contexts.
> >
> > Perhaps "as applied in context" is better?
>
> "As applied in our project's expected development activities", which is
> more of what we mean, but is far too long.
>
> We can't completely encapsulate our license criteria in an
> understandable way to outsiders in two sentences - it's just not
> possible. Partly because it's complicated, and partly because it's not
> just what some licenses say, it's how included software under license
> "Q" is used *in the context of typical Apache development*.
>
> The principle of least surprise is a big part of this; although that's
> not a legal diagnosis, it's a process one. The point of allowing
> (L)GPL/*-SA works in some places in our products is not about how or
> where the license applies to that bit of IP within our product; it's
> about the likelihood of a user who wants to modify our product to build
> something new needing to change that big of IP (and potentially being
> surprised by the share-alike qualities thereof).
>
> I don't see how the bullet point criteria are ever going to be
> comprehensive without some "in our context of software development"
> phrase, which we can then explain later on. In general I like Marvin's
> approach here.
>
> >
> > 2. The license, as applied in context, must not impose significant
> > restrictions beyond those imposed by the Apache License 2.0.
> >
> >> I think we should clarify the intended meaning of the term
> >> "significant", since it's a subjective term. We might be able to do so
> >> by annotating the CatA/CatB/CatX lists with the rationales for the
> >> classifications we have already made?
> >
> > The term "significance" is there literally to allow for the dismissal of any
> > restrictions Legal Affairs doesn't deem "significant". Personally, I'm
> > thinking of the fact that there are technical arguments why Category A
> > licenses may not be perfectly subsumed by the ALv2, yet we still advertise
> > packages bundling Category A dependencies as "under the Apache License 2.0"
> > without qualification. Combining licenses is complicated[1].
> >
> > As for clarifying the CatA/CatB/CatX classifications: that's a worthy
> > exercise, but I don't think we should attempt to wedge those
> > classifications into this section.
>
> Rather than clarifying, what would be incredibly valuable - both for
> others and for ourselves - would be an expanded description of why some
> of the licenses are put in each of the categories. Since the
> distinction is partly process-based (not just license compatibility
> based), having more examples would help. Like: *-SA image files for
> icons are fine, because someone combining our software into a bigger
> product is likely to update the API, but not likely to update the
> existing icon design files themselves.
>
> Obviously, that takes more work... 8-)
>
> >
> > Marvin Humphrey
> >
> > [1] https://opensource.com/law/11/9/mpl-20-copyleft-and-license-compatibility
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
>
> --
>
> - Shane
> Director & Member
> The Apache Software Foundation
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarifiying our license criteria
Posted by Hen <ba...@apache.org>.
Done in staging (assuming it'll get pushed tomorrow).
On Wed, Mar 20, 2019 at 1:45 AM Hen <ba...@apache.org> wrote:
> Noting that said document was published.
>
> Noting that it classified the criteria as:
>
> ----
>
> This policy can be summarized as:
>
>
> - The license must meet the Open Source Definition (OSD)
> <https://opensource.org/osd>.
>
> - The license, as applied in practice, must not impose significant
> restrictions beyond those imposed by the Apache License 2.0.
>
> ----
>
> I propose we add that 2nd bullet to resolved.html and remove the current
> #2 and #3 items.
>
> (I'll go ahead and do this at the weekend if no disagreement).
>
> Hen
>
>
> On Thu, Mar 14, 2019 at 12:42 PM Ross Gardler <rg...@outlook.com>
> wrote:
>
>> The intent is documented in the soon to be published apache way doc.
>> Perhaps list content from that?
>>
>> Get Outlook for Android <https://aka.ms/ghei36>
>>
>> ------------------------------
>> *From:* sebb <se...@gmail.com>
>> *Sent:* Saturday, March 9, 2019 4:15:47 AM
>> *To:* legal-discuss@apache.org
>> *Subject:* Re: Clarifiying our license criteria
>>
>> It would also be very useful to document the *intent* of the rules, e.g.
>>
>> "What we really want is for downstream consumers to feel safe that any
>> product originating from us is available under the terms of the ALv2."
>>
>> This makes it easier to understand - and change if requirements change.
>>
>> An analogy:
>> Rule: "vehicles must drive on the right"
>> Rationale/Intent: "vehicles travelling in opposite directions should
>> be able to pass each other safely"
>> This allows for the alternative:
>> Rule: "vehicles must drive on the left"
>>
>> On Wed, 20 Feb 2019 at 15:40, Shane Curcuru <as...@shanecurcuru.org> wrote:
>> >
>> > Marvin Humphrey wrote on 2/20/19 10:26 AM:
>> > > On Tue, Feb 19, 2019 at 10:48 AM Daniel Shahaf <
>> d.s@daniel.shahaf.name> wrote:
>> > >>
>> > >> Marvin Humphrey wrote on Tue, Feb 19, 2019 at 08:48:45 -0800:
>> > >
>> > >>> 2. The license, as applied in practice, must not impose
>> significant
>> > >>> restrictions beyond those imposed by the Apache License 2.0.
>> > >>
>> > >> How about s/as applied in practice//?
>> > ...snip...
>> >
>> > > Ralph Goers puts it like this in the 2008 thread I referenced earlier:
>> > >
>> > >
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarkmail.org%2Fmessage%2F624q772go45oplyj&data=02%7C01%7C%7Ca2b5c160e704408539fe08d6a489017c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636877305668039822&sdata=SvGYH15P5FlUbCi4MoRVSak0SWkuBD0ku7XlEzK2JIo%3D&reserved=0
>> > >
>> > > Part of the consideration is not only what the license is but how
>> the
>> > > third party component is used. There are cases where use of a GPL
>> > > component may be allowed and there are cases where the LGPL will
>> be
>> > > disallowed.
>> > >
>> > > The phrase "as applied in practice" attempts to take that intent into
>> account:
>> > > the license gets applied in specific context, and sometimes that
>> context
>> > > allows for licenses which which we would not allow in other contexts.
>> > >
>> > > Perhaps "as applied in context" is better?
>> >
>> > "As applied in our project's expected development activities", which is
>> > more of what we mean, but is far too long.
>> >
>> > We can't completely encapsulate our license criteria in an
>> > understandable way to outsiders in two sentences - it's just not
>> > possible. Partly because it's complicated, and partly because it's not
>> > just what some licenses say, it's how included software under license
>> > "Q" is used *in the context of typical Apache development*.
>> >
>> > The principle of least surprise is a big part of this; although that's
>> > not a legal diagnosis, it's a process one. The point of allowing
>> > (L)GPL/*-SA works in some places in our products is not about how or
>> > where the license applies to that bit of IP within our product; it's
>> > about the likelihood of a user who wants to modify our product to build
>> > something new needing to change that big of IP (and potentially being
>> > surprised by the share-alike qualities thereof).
>> >
>> > I don't see how the bullet point criteria are ever going to be
>> > comprehensive without some "in our context of software development"
>> > phrase, which we can then explain later on. In general I like Marvin's
>> > approach here.
>> >
>> > >
>> > > 2. The license, as applied in context, must not impose significant
>> > > restrictions beyond those imposed by the Apache License 2.0.
>> > >
>> > >> I think we should clarify the intended meaning of the term
>> > >> "significant", since it's a subjective term. We might be able to do
>> so
>> > >> by annotating the CatA/CatB/CatX lists with the rationales for the
>> > >> classifications we have already made?
>> > >
>> > > The term "significance" is there literally to allow for the dismissal
>> of any
>> > > restrictions Legal Affairs doesn't deem "significant". Personally,
>> I'm
>> > > thinking of the fact that there are technical arguments why Category A
>> > > licenses may not be perfectly subsumed by the ALv2, yet we still
>> advertise
>> > > packages bundling Category A dependencies as "under the Apache
>> License 2.0"
>> > > without qualification. Combining licenses is complicated[1].
>> > >
>> > > As for clarifying the CatA/CatB/CatX classifications: that's a worthy
>> > > exercise, but I don't think we should attempt to wedge those
>> > > classifications into this section.
>> >
>> > Rather than clarifying, what would be incredibly valuable - both for
>> > others and for ourselves - would be an expanded description of why some
>> > of the licenses are put in each of the categories. Since the
>> > distinction is partly process-based (not just license compatibility
>> > based), having more examples would help. Like: *-SA image files for
>> > icons are fine, because someone combining our software into a bigger
>> > product is likely to update the API, but not likely to update the
>> > existing icon design files themselves.
>> >
>> > Obviously, that takes more work... 8-)
>> >
>> > >
>> > > Marvin Humphrey
>> > >
>> > > [1]
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Flaw%2F11%2F9%2Fmpl-20-copyleft-and-license-compatibility&data=02%7C01%7C%7Ca2b5c160e704408539fe08d6a489017c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636877305668039822&sdata=Wvv0VnJR%2BvYEyG6ext736Cg9tbEzqAVcx%2FU%2FQjvs6Zg%3D&reserved=0
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> > > For additional commands, e-mail: legal-discuss-help@apache.org
>> > >
>> > >
>> >
>> >
>> > --
>> >
>> > - Shane
>> > Director & Member
>> > The Apache Software Foundation
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> > For additional commands, e-mail: legal-discuss-help@apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
Re: Clarifiying our license criteria
Posted by Hen <ba...@apache.org>.
Noting that said document was published.
Noting that it classified the criteria as:
----
This policy can be summarized as:
- The license must meet the Open Source Definition (OSD)
<https://opensource.org/osd>.
- The license, as applied in practice, must not impose significant
restrictions beyond those imposed by the Apache License 2.0.
----
I propose we add that 2nd bullet to resolved.html and remove the current #2
and #3 items.
(I'll go ahead and do this at the weekend if no disagreement).
Hen
On Thu, Mar 14, 2019 at 12:42 PM Ross Gardler <rg...@outlook.com> wrote:
> The intent is documented in the soon to be published apache way doc.
> Perhaps list content from that?
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* sebb <se...@gmail.com>
> *Sent:* Saturday, March 9, 2019 4:15:47 AM
> *To:* legal-discuss@apache.org
> *Subject:* Re: Clarifiying our license criteria
>
> It would also be very useful to document the *intent* of the rules, e.g.
>
> "What we really want is for downstream consumers to feel safe that any
> product originating from us is available under the terms of the ALv2."
>
> This makes it easier to understand - and change if requirements change.
>
> An analogy:
> Rule: "vehicles must drive on the right"
> Rationale/Intent: "vehicles travelling in opposite directions should
> be able to pass each other safely"
> This allows for the alternative:
> Rule: "vehicles must drive on the left"
>
> On Wed, 20 Feb 2019 at 15:40, Shane Curcuru <as...@shanecurcuru.org> wrote:
> >
> > Marvin Humphrey wrote on 2/20/19 10:26 AM:
> > > On Tue, Feb 19, 2019 at 10:48 AM Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
> > >>
> > >> Marvin Humphrey wrote on Tue, Feb 19, 2019 at 08:48:45 -0800:
> > >
> > >>> 2. The license, as applied in practice, must not impose significant
> > >>> restrictions beyond those imposed by the Apache License 2.0.
> > >>
> > >> How about s/as applied in practice//?
> > ...snip...
> >
> > > Ralph Goers puts it like this in the 2008 thread I referenced earlier:
> > >
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarkmail.org%2Fmessage%2F624q772go45oplyj&data=02%7C01%7C%7Ca2b5c160e704408539fe08d6a489017c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636877305668039822&sdata=SvGYH15P5FlUbCi4MoRVSak0SWkuBD0ku7XlEzK2JIo%3D&reserved=0
> > >
> > > Part of the consideration is not only what the license is but how
> the
> > > third party component is used. There are cases where use of a GPL
> > > component may be allowed and there are cases where the LGPL will be
> > > disallowed.
> > >
> > > The phrase "as applied in practice" attempts to take that intent into
> account:
> > > the license gets applied in specific context, and sometimes that
> context
> > > allows for licenses which which we would not allow in other contexts.
> > >
> > > Perhaps "as applied in context" is better?
> >
> > "As applied in our project's expected development activities", which is
> > more of what we mean, but is far too long.
> >
> > We can't completely encapsulate our license criteria in an
> > understandable way to outsiders in two sentences - it's just not
> > possible. Partly because it's complicated, and partly because it's not
> > just what some licenses say, it's how included software under license
> > "Q" is used *in the context of typical Apache development*.
> >
> > The principle of least surprise is a big part of this; although that's
> > not a legal diagnosis, it's a process one. The point of allowing
> > (L)GPL/*-SA works in some places in our products is not about how or
> > where the license applies to that bit of IP within our product; it's
> > about the likelihood of a user who wants to modify our product to build
> > something new needing to change that big of IP (and potentially being
> > surprised by the share-alike qualities thereof).
> >
> > I don't see how the bullet point criteria are ever going to be
> > comprehensive without some "in our context of software development"
> > phrase, which we can then explain later on. In general I like Marvin's
> > approach here.
> >
> > >
> > > 2. The license, as applied in context, must not impose significant
> > > restrictions beyond those imposed by the Apache License 2.0.
> > >
> > >> I think we should clarify the intended meaning of the term
> > >> "significant", since it's a subjective term. We might be able to do
> so
> > >> by annotating the CatA/CatB/CatX lists with the rationales for the
> > >> classifications we have already made?
> > >
> > > The term "significance" is there literally to allow for the dismissal
> of any
> > > restrictions Legal Affairs doesn't deem "significant". Personally, I'm
> > > thinking of the fact that there are technical arguments why Category A
> > > licenses may not be perfectly subsumed by the ALv2, yet we still
> advertise
> > > packages bundling Category A dependencies as "under the Apache License
> 2.0"
> > > without qualification. Combining licenses is complicated[1].
> > >
> > > As for clarifying the CatA/CatB/CatX classifications: that's a worthy
> > > exercise, but I don't think we should attempt to wedge those
> > > classifications into this section.
> >
> > Rather than clarifying, what would be incredibly valuable - both for
> > others and for ourselves - would be an expanded description of why some
> > of the licenses are put in each of the categories. Since the
> > distinction is partly process-based (not just license compatibility
> > based), having more examples would help. Like: *-SA image files for
> > icons are fine, because someone combining our software into a bigger
> > product is likely to update the API, but not likely to update the
> > existing icon design files themselves.
> >
> > Obviously, that takes more work... 8-)
> >
> > >
> > > Marvin Humphrey
> > >
> > > [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Flaw%2F11%2F9%2Fmpl-20-copyleft-and-license-compatibility&data=02%7C01%7C%7Ca2b5c160e704408539fe08d6a489017c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636877305668039822&sdata=Wvv0VnJR%2BvYEyG6ext736Cg9tbEzqAVcx%2FU%2FQjvs6Zg%3D&reserved=0
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> > >
> >
> >
> > --
> >
> > - Shane
> > Director & Member
> > The Apache Software Foundation
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Clarifiying our license criteria
Posted by Ross Gardler <rg...@outlook.com>.
The intent is documented in the soon to be published apache way doc. Perhaps list content from that?
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: sebb <se...@gmail.com>
Sent: Saturday, March 9, 2019 4:15:47 AM
To: legal-discuss@apache.org
Subject: Re: Clarifiying our license criteria
It would also be very useful to document the *intent* of the rules, e.g.
"What we really want is for downstream consumers to feel safe that any
product originating from us is available under the terms of the ALv2."
This makes it easier to understand - and change if requirements change.
An analogy:
Rule: "vehicles must drive on the right"
Rationale/Intent: "vehicles travelling in opposite directions should
be able to pass each other safely"
This allows for the alternative:
Rule: "vehicles must drive on the left"
On Wed, 20 Feb 2019 at 15:40, Shane Curcuru <as...@shanecurcuru.org> wrote:
>
> Marvin Humphrey wrote on 2/20/19 10:26 AM:
> > On Tue, Feb 19, 2019 at 10:48 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >>
> >> Marvin Humphrey wrote on Tue, Feb 19, 2019 at 08:48:45 -0800:
> >
> >>> 2. The license, as applied in practice, must not impose significant
> >>> restrictions beyond those imposed by the Apache License 2.0.
> >>
> >> How about s/as applied in practice//?
> ...snip...
>
> > Ralph Goers puts it like this in the 2008 thread I referenced earlier:
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarkmail.org%2Fmessage%2F624q772go45oplyj&data=02%7C01%7C%7Ca2b5c160e704408539fe08d6a489017c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636877305668039822&sdata=SvGYH15P5FlUbCi4MoRVSak0SWkuBD0ku7XlEzK2JIo%3D&reserved=0
> >
> > Part of the consideration is not only what the license is but how the
> > third party component is used. There are cases where use of a GPL
> > component may be allowed and there are cases where the LGPL will be
> > disallowed.
> >
> > The phrase "as applied in practice" attempts to take that intent into account:
> > the license gets applied in specific context, and sometimes that context
> > allows for licenses which which we would not allow in other contexts.
> >
> > Perhaps "as applied in context" is better?
>
> "As applied in our project's expected development activities", which is
> more of what we mean, but is far too long.
>
> We can't completely encapsulate our license criteria in an
> understandable way to outsiders in two sentences - it's just not
> possible. Partly because it's complicated, and partly because it's not
> just what some licenses say, it's how included software under license
> "Q" is used *in the context of typical Apache development*.
>
> The principle of least surprise is a big part of this; although that's
> not a legal diagnosis, it's a process one. The point of allowing
> (L)GPL/*-SA works in some places in our products is not about how or
> where the license applies to that bit of IP within our product; it's
> about the likelihood of a user who wants to modify our product to build
> something new needing to change that big of IP (and potentially being
> surprised by the share-alike qualities thereof).
>
> I don't see how the bullet point criteria are ever going to be
> comprehensive without some "in our context of software development"
> phrase, which we can then explain later on. In general I like Marvin's
> approach here.
>
> >
> > 2. The license, as applied in context, must not impose significant
> > restrictions beyond those imposed by the Apache License 2.0.
> >
> >> I think we should clarify the intended meaning of the term
> >> "significant", since it's a subjective term. We might be able to do so
> >> by annotating the CatA/CatB/CatX lists with the rationales for the
> >> classifications we have already made?
> >
> > The term "significance" is there literally to allow for the dismissal of any
> > restrictions Legal Affairs doesn't deem "significant". Personally, I'm
> > thinking of the fact that there are technical arguments why Category A
> > licenses may not be perfectly subsumed by the ALv2, yet we still advertise
> > packages bundling Category A dependencies as "under the Apache License 2.0"
> > without qualification. Combining licenses is complicated[1].
> >
> > As for clarifying the CatA/CatB/CatX classifications: that's a worthy
> > exercise, but I don't think we should attempt to wedge those
> > classifications into this section.
>
> Rather than clarifying, what would be incredibly valuable - both for
> others and for ourselves - would be an expanded description of why some
> of the licenses are put in each of the categories. Since the
> distinction is partly process-based (not just license compatibility
> based), having more examples would help. Like: *-SA image files for
> icons are fine, because someone combining our software into a bigger
> product is likely to update the API, but not likely to update the
> existing icon design files themselves.
>
> Obviously, that takes more work... 8-)
>
> >
> > Marvin Humphrey
> >
> > [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Flaw%2F11%2F9%2Fmpl-20-copyleft-and-license-compatibility&data=02%7C01%7C%7Ca2b5c160e704408539fe08d6a489017c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636877305668039822&sdata=Wvv0VnJR%2BvYEyG6ext736Cg9tbEzqAVcx%2FU%2FQjvs6Zg%3D&reserved=0
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
>
> --
>
> - Shane
> Director & Member
> The Apache Software Foundation
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org