[v2,4/5] docs/manual: add section about patch licensing

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

---
Changes v1 -> v2:
- "they modify" -> "they apply to" (Thomas).
---
 docs/manual/legal-notice.txt | 16 ++++++++++++++--
 docs/manual/patch-policy.txt |  2 +-
 2 files changed, 15 insertions(+), 3 deletions(-)

Luca, All,

On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> 
> ---
> Changes v1 -> v2:
> - "they modify" -> "they apply to" (Thomas).
> ---
>  docs/manual/legal-notice.txt | 16 ++++++++++++++--
>  docs/manual/patch-policy.txt |  2 +-
>  2 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/manual/legal-notice.txt b/docs/manual/legal-notice.txt
> index 5895224..49c4965 100644
> --- a/docs/manual/legal-notice.txt
> +++ b/docs/manual/legal-notice.txt
> @@ -131,11 +131,13 @@ Buildroot, with the name used in the manifest files:
>    http://apache.org/licenses/LICENSE-2.0.html[
>    Apache License, version 2.0];
>  
> +[[legal-info-buildroot]]
>  === Complying with the Buildroot license
>  
>  Buildroot itself is an open source software, released under the
> -http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU General Public
> -License, version 2] or (at your option) any later version.
> +http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU General
> +Public License, version 2] or (at your option) any later version, with
> +the exception of the package patches detailed below.

As previously said, we have to clarify this. However, since yout patch
does not change it, and merely wraps lines:

>  However, being a build system, it is not normally part of the end product:
>  if you develop the root filesystem, kernel, bootloader or toolchain for a
>  device, the code of Buildroot is only present on the development machine, not
> @@ -156,3 +158,13 @@ material that must be redistributed.
>  
>  Keep in mind that this is only the Buildroot developers' opinion, and you
>  should consult your legal department or lawyer in case of any doubt.
> +
> +==== Patches to packages
> +
> +Buildroot is bundled with a set of patches that it applies to packages

... that are applied to...

> +to fix cross-compilation or other issues. See xref:patch-policy[] for
> +the technical details.
> +
> +These patches are effectively a derived work of the upstream package,

... a derived work of the package they are applied to...

> +and they are released under the same license as the software they

and so are released...

> +apply to.

So, we still have the problem of patches that are applied to packages
that can be had under a non-public license, like e.g. Qt, polarssl...
for which there exists a proprietary alternative?

In my opinion, the patches we carry are only available under the FLOSS
license we can get them:

  - if we cherry-picked them from upstream, then the only license we
    ever had for those patches is the FLOSS license, not the proprietary
    one; so they can't be applied to the proprietary version of the
    package (but a licensee may get those patches from the licensor, and
    replace our patches with the ones it got from the licensor);

  - if we wrote them, the only solution we have is to make them public
    domain, or they could not be applied either (we don't know the
    licensing terms for that proprietary version, so we can't license
    them under those terms);

  - if we got them from somewhere else (e.g. openwrt, gentoo,
    alpine...), then we'd have to get the licensing terms from those
    providers, and I guess most of them either don't know (most
    probable) or would only provide them under the usual FLOSS license
    of that package (not knowing better than us in points 1 and 2 above).

So, this situation is really complex, and we can't deal with that in
such a simple way.

> They are not distributed under the Buildroot license.

Well, what of a patch to a GPLv2 package? It is the same license as
Buidlroot's license... What I mean, is that some patches might be
covered by the same licensing terms, but that it's not because of
Buildroot, but because of the package they are applied to. I'd like we
make that clearer...

But as I explained above, it is far from trivial. We need to think a bit
more about it...

So NAK on my part.

Regards,
Yann E. MORIN.

> diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
> index d50c971..fe432a7 100644
> --- a/docs/manual/patch-policy.txt
> +++ b/docs/manual/patch-policy.txt
> @@ -91,7 +91,7 @@ If something goes wrong in the steps _3_ or _4_, then the build fails.
>  === Format and licensing of the package patches
>  
>  Patches are released under the same license as the software they apply
> -to.
> +to. (see xref:legal-info-buildroot[]).
>  
>  A message explaining what the patch does, and why it is needed, should
>  be added in the header commentary of the patch.
> -- 
> 1.9.1
>

On 01-02-16 23:19, Luca Ceresoli wrote:
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> 
> ---
> Changes v1 -> v2:
> - "they modify" -> "they apply to" (Thomas).
> ---
>  docs/manual/legal-notice.txt | 16 ++++++++++++++--
>  docs/manual/patch-policy.txt |  2 +-
>  2 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/manual/legal-notice.txt b/docs/manual/legal-notice.txt
> index 5895224..49c4965 100644
> --- a/docs/manual/legal-notice.txt
> +++ b/docs/manual/legal-notice.txt
> @@ -131,11 +131,13 @@ Buildroot, with the name used in the manifest files:
>    http://apache.org/licenses/LICENSE-2.0.html[
>    Apache License, version 2.0];
>  
> +[[legal-info-buildroot]]
>  === Complying with the Buildroot license
>  
>  Buildroot itself is an open source software, released under the
> -http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU General Public
> -License, version 2] or (at your option) any later version.
> +http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU General
> +Public License, version 2] or (at your option) any later version, with
> +the exception of the package patches detailed below.
>  However, being a build system, it is not normally part of the end product:
>  if you develop the root filesystem, kernel, bootloader or toolchain for a
>  device, the code of Buildroot is only present on the development machine, not
> @@ -156,3 +158,13 @@ material that must be redistributed.
>  
>  Keep in mind that this is only the Buildroot developers' opinion, and you
>  should consult your legal department or lawyer in case of any doubt.
> +
> +==== Patches to packages
> +
> +Buildroot is bundled with a set of patches that it applies to packages
> +to fix cross-compilation or other issues. See xref:patch-policy[] for
> +the technical details.
> +
> +These patches are effectively a derived work of the upstream package,
> +and they are released under the same license as the software they
> +apply to. They are not distributed under the Buildroot license.
> diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
> index d50c971..fe432a7 100644
> --- a/docs/manual/patch-policy.txt
> +++ b/docs/manual/patch-policy.txt
> @@ -91,7 +91,7 @@ If something goes wrong in the steps _3_ or _4_, then the build fails.
>  === Format and licensing of the package patches
>  
>  Patches are released under the same license as the software they apply
> -to.
> +to. (see xref:legal-info-buildroot[]).

 Small nit: the (see ) part should come before the period. So

+to (see xref:legal-info-buildroot[]).


 With that:
 Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

 Regards,
 Arnout

>  
>  A message explaining what the patch does, and why it is needed, should
>  be added in the header commentary of the patch.
>

Dear Yann,

On 04/02/2016 00:34, Yann E. MORIN wrote:
[...]
>> +==== Patches to packages
>> +
>> +Buildroot is bundled with a set of patches that it applies to packages
> 
> ... that are applied to...
> 
>> +to fix cross-compilation or other issues. See xref:patch-policy[] for
>> +the technical details.
>> +
>> +These patches are effectively a derived work of the upstream package,
> 
> ... a derived work of the package they are applied to...
> 
>> +and they are released under the same license as the software they
> 
> and so are released...
> 
>> +apply to.
> 
> So, we still have the problem of patches that are applied to packages
> that can be had under a non-public license, like e.g. Qt, polarssl...
> for which there exists a proprietary alternative?
> 
> In my opinion, the patches we carry are only available under the FLOSS
> license we can get them:
> 
>   - if we cherry-picked them from upstream, then the only license we
>     ever had for those patches is the FLOSS license, not the proprietary
>     one; so they can't be applied to the proprietary version of the
>     package (but a licensee may get those patches from the licensor, and
>     replace our patches with the ones it got from the licensor);
> 
>   - if we wrote them, the only solution we have is to make them public
>     domain, or they could not be applied either (we don't know the
>     licensing terms for that proprietary version, so we can't license
>     them under those terms);

Why can't we license these patches under the FLOSS license they are
publicly available under? Of course this implies "they can't be applied
to the proprietary version of the package", just like you state in the
first case. This is a limitation, but I think it is legal. Don't you
think so?

> 
>   - if we got them from somewhere else (e.g. openwrt, gentoo,
>     alpine...), then we'd have to get the licensing terms from those
>     providers, and I guess most of them either don't know (most
>     probable) or would only provide them under the usual FLOSS license
>     of that package (not knowing better than us in points 1 and 2 above).
> 
> So, this situation is really complex, and we can't deal with that in
> such a simple way.
> 
>> They are not distributed under the Buildroot license.
> 
> Well, what of a patch to a GPLv2 package? It is the same license as
> Buidlroot's license... What I mean, is that some patches might be
> covered by the same licensing terms, but that it's not because of
> Buildroot, but because of the package they are applied to. I'd like we
> make that clearer...

Aaaah, yes, you're right... Well, I guess we all got what I meant, but
indeed I wrote something ambiguous. :(

Luca, All,

On 2016-02-26 23:08 +0100, Luca Ceresoli spake thusly:
> On 04/02/2016 00:34, Yann E. MORIN wrote:
[...]
> > So, we still have the problem of patches that are applied to packages
> > that can be had under a non-public license, like e.g. Qt, polarssl...
> > for which there exists a proprietary alternative?
> > 
> > In my opinion, the patches we carry are only available under the FLOSS
> > license we can get them:
> > 
> >   - if we cherry-picked them from upstream, then the only license we
> >     ever had for those patches is the FLOSS license, not the proprietary
> >     one; so they can't be applied to the proprietary version of the
> >     package (but a licensee may get those patches from the licensor, and
> >     replace our patches with the ones it got from the licensor);
> > 
> >   - if we wrote them, the only solution we have is to make them public
> >     domain, or they could not be applied either (we don't know the
> >     licensing terms for that proprietary version, so we can't license
> >     them under those terms);
> 
> Why can't we license these patches under the FLOSS license they are
> publicly available under?

Ah, my bad, I was not clear.

What I meant with that second point wa that, *if* we wanted to make
those patches available for the non-FLOSS license, then we'd have had to
license them in a very liberal way, and the only real possibility would
have been public domain, as any other license, hoever permissive it may
be, could clash with the proprietary license.

Now, I am absolutely *not* advocating for that.

In fact, I've always been, and will always be, advocating for the
patches to be made available under the _publicly available_ FLOSS
license of the package they are applied to, which is the conclusion we
came to, and which we wrote in COPYING (and soon in the manual).

> Of course this implies "they can't be applied
> to the proprietary version of the package", just like you state in the
> first case. This is a limitation, but I think it is legal. Don't you
> think so?

 1- I think it is perfectly legit, yes.
 2- I do not see that as a limitation, no.
 3- I am 100% fine with that! ;-)

> >   - if we got them from somewhere else (e.g. openwrt, gentoo,
> >     alpine...), then we'd have to get the licensing terms from those
> >     providers, and I guess most of them either don't know (most
> >     probable) or would only provide them under the usual FLOSS license
> >     of that package (not knowing better than us in points 1 and 2 above).
> > 
> > So, this situation is really complex, and we can't deal with that in
> > such a simple way.
> > 
> >> They are not distributed under the Buildroot license.
> > 
> > Well, what of a patch to a GPLv2 package? It is the same license as
> > Buidlroot's license... What I mean, is that some patches might be
> > covered by the same licensing terms, but that it's not because of
> > Buildroot, but because of the package they are applied to. I'd like we
> > make that clearer...
> 
> Aaaah, yes, you're right... Well, I guess we all got what I meant, but
> indeed I wrote something ambiguous. :(

Yes, I did get your meaning, of course! ;-)

But legalese stuff is suffficiently complex that we have to be as clear
as possible when we write such stuff. In the end, I think we pretty much
covered all the bases with that blurb we've added now, no?

Thank you for working on this topic! :-)

Regards,
Yann E. MORIN.