[Buildroot] [PATCH v2 0/5] Patch file clarification & Co

[Buildroot] [PATCH v2 0/5] Patch file clarification & Co

[Luca Ceresoli]

Hi,

several Buildroot users reportedly asked details about how the patches
bundled with Buildroot are licensed.

Following the discussion during the Buildroot Developer Days today,
this small series is aimed at clarifying patch licensing in the places
where it makes sense: COPYING, the manual and the legal-info output.

This v2 is a refinement of v1 based on the comments received.

Note that patches are not saved by 'make legal-info' in current
Buildroot master, but there's a patchset by Yann E. Morin to add this
feature. Patch 5 of the present series applies to legal-info, and it
only applies on top of Yann's series (it would be useless on master
anyway).

Patches 1-4 apply also on current master.

Luca Ceresoli (5):
  Update copyright year
  docs/manual: slightly clarify patch licensing
  COPYING: add exception about patch licensing
  docs/manual: add section about patch licensing
  legal-info: explicitly state how patches are licensed

 COPYING                          |  8 ++++++++
 Makefile                         |  2 +-
 docs/manual/legal-notice.txt     | 16 ++++++++++++++--
 docs/manual/patch-policy.txt     |  4 ++--
 support/legal-info/README.header |  2 +-
 5 files changed, 26 insertions(+), 6 deletions(-)

-- 
1.9.1

[Buildroot] [PATCH v2 1/5] Update copyright year

[Luca Ceresoli]

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index c3427ed..1acc2b2 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@
 #
 # Copyright (C) 1999-2005 by Erik Andersen <andersen@codepoet.org>
 # Copyright (C) 2006-2014 by the Buildroot developers <buildroot@uclibc.org>
-# Copyright (C) 2014-2015 by the Buildroot developers <buildroot@buildroot.org>
+# Copyright (C) 2014-2016 by the Buildroot developers <buildroot@buildroot.org>
 #
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
-- 
1.9.1

[Buildroot] [PATCH v2 2/5] docs/manual: slightly clarify patch licensing

[Luca Ceresoli]

Adding a patch is a modification to Buildroot. Thus this sentence might be
interpreted as "Patches are released under the Buildroot license".

Being a legal matter, the last thing we want is to be
ambiguous. Reword the sentence to avoid any misunderstandings.

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

---
Changes v1 -> v2:
- "they modify" -> "they apply to" (Thomas).
---
 docs/manual/patch-policy.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
index 0b4604e..d50c971 100644
--- a/docs/manual/patch-policy.txt
+++ b/docs/manual/patch-policy.txt
@@ -90,8 +90,8 @@ 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 that is
-modified.
+Patches are released under the same license as the software they apply
+to.
 
 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

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Luca Ceresoli]

Several people have been asking what is the license of the patches
provided by Buildroot. COPYING is the authoritative place to state it.

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>

---
Changes v1 -> v2:
 - Rewrite it almost entirely (Arnout, Thomas).
---
 COPYING | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/COPYING b/COPYING
index d511905..3596777 100644
--- a/COPYING
+++ b/COPYING
@@ -1,3 +1,11 @@
+Except for the patches provided for packages, Buildroot is licensed
+under the GNU General Public License, version 2.
+
+Patches provided by Buildroot for packages are released under the same
+license as the software that they modify.
+
+-----------------------------------------------------------------
+
 		    GNU GENERAL PUBLIC LICENSE
 		       Version 2, June 1991
 
-- 
1.9.1

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

[Luca Ceresoli]

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[]).
 
 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

[Buildroot] [PATCH v2 5/5] legal-info: explicitly state how patches are licensed

[Luca Ceresoli]

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 support/legal-info/README.header | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/support/legal-info/README.header b/support/legal-info/README.header
index 0b5aa66..316f799 100644
--- a/support/legal-info/README.header
+++ b/support/legal-info/README.header
@@ -18,7 +18,7 @@ This material is composed of the following items.
    sources/ subdirectory (except for the non-redistributable packages, which
    have not been saved). Patches that were applied are also saved, along
    with a file named 'series' that lists the patches in the order they were
-   applied.
+   applied. Patches are under the same license as the original package.
  * A manifest file listing the configured packages and related information.
  * The license text of the packages; they have been saved in the licenses/
    subdirectory.
-- 
1.9.1

[Buildroot] [PATCH v2 1/5] Update copyright year

[Luca Ceresoli]

Hi,

Luca Ceresoli wrote:
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> ---
>   Makefile | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index c3427ed..1acc2b2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2,7 +2,7 @@
>   #
>   # Copyright (C) 1999-2005 by Erik Andersen <andersen@codepoet.org>
>   # Copyright (C) 2006-2014 by the Buildroot developers <buildroot@uclibc.org>
> -# Copyright (C) 2014-2015 by the Buildroot developers <buildroot@buildroot.org>
> +# Copyright (C) 2014-2016 by the Buildroot developers <buildroot@buildroot.org>

Ignore this patch, it's already on master. Sorry for the noise.

-- 
Luca

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Thomas Petazzoni]

Dear Luca Ceresoli,

On Mon,  1 Feb 2016 23:19:54 +0100, Luca Ceresoli wrote:

> +Patches provided by Buildroot for packages are released under the same
> +license as the software that they modify.

they apply to ? :-)

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 2/5] docs/manual: slightly clarify patch licensing

[Yann E. MORIN]

Luca, All,

On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:
> Adding a patch is a modification to Buildroot. Thus this sentence might be
> interpreted as "Patches are released under the Buildroot license".
> 
> Being a legal matter, the last thing we want is to be
> ambiguous. Reword the sentence to avoid any misunderstandings.
> 
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
> Changes v1 -> v2:
> - "they modify" -> "they apply to" (Thomas).
> ---
>  docs/manual/patch-policy.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
> index 0b4604e..d50c971 100644
> --- a/docs/manual/patch-policy.txt
> +++ b/docs/manual/patch-policy.txt
> @@ -90,8 +90,8 @@ 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 that is
> -modified.
> +Patches are released under the same license as the software they apply
> +to.
>  
>  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
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2 2/5] docs/manual: slightly clarify patch licensing

[Yann E. MORIN]

Luca, All,

On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:
> Adding a patch is a modification to Buildroot. Thus this sentence might be
> interpreted as "Patches are released under the Buildroot license".
> 
> Being a legal matter, the last thing we want is to be
> ambiguous. Reword the sentence to avoid any misunderstandings.
> 
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
> Changes v1 -> v2:
> - "they modify" -> "they apply to" (Thomas).
> ---
>  docs/manual/patch-policy.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
> index 0b4604e..d50c971 100644
> --- a/docs/manual/patch-policy.txt
> +++ b/docs/manual/patch-policy.txt
> @@ -90,8 +90,8 @@ 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 that is
> -modified.
> +Patches are released under the same license as the software they apply
> +to.
>  
>  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
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Yann E. MORIN]

Luca, All,

On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:
> Several people have been asking what is the license of the patches
> provided by Buildroot. COPYING is the authoritative place to state it.
> 
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnout Vandecappelle <arnout@mind.be>

> ---
> Changes v1 -> v2:
>  - Rewrite it almost entirely (Arnout, Thomas).
> ---
>  COPYING | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/COPYING b/COPYING
> index d511905..3596777 100644
> --- a/COPYING
> +++ b/COPYING
> @@ -1,3 +1,11 @@
> +Except for the patches provided for packages, Buildroot is licensed
> +under the GNU General Public License, version 2.

There a gotcha here. The manual states, in chapter 12.3:

    Buildroot [is] released under the GNU General Public License,
    version 2 or (at your option) any later version.

So, we have to clarify: is it GPLv2 or GPLV2+ ?

It's too late today for me to go digging; I'll do that tomorrow. Just
rmind me before the end of the week if there's not feedback from my part
on this topic.

Until then, NAK.

> +Patches provided by Buildroot for packages are released under the same
> +license as the software that they modify.

Here's an alternative proposal, to replace both sentences:

    Buildroot comes with its own license, reproduced below.

    Buildroot also bundles patch files, which are applied to the
    sources of the various packages. Those patches are not covered
    by the license of Buildroot. See those individual packages for
    their license (running 'make legal-info' after your build may
    help).

Regards,
Yann E. MORIN.

> +-----------------------------------------------------------------
> +
>  		    GNU GENERAL PUBLIC LICENSE
>  		       Version 2, June 1991
>  
> -- 
> 1.9.1
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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

[Yann E. MORIN]

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
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Arnout Vandecappelle]

On 04-02-16 00:02, Yann E. MORIN wrote:
> Luca, All,
> 
> On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:
>> Several people have been asking what is the license of the patches
>> provided by Buildroot. COPYING is the authoritative place to state it.
>>
>> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
>> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Cc: Arnout Vandecappelle <arnout@mind.be>
> 
>> ---
>> Changes v1 -> v2:
>>  - Rewrite it almost entirely (Arnout, Thomas).
>> ---
>>  COPYING | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/COPYING b/COPYING
>> index d511905..3596777 100644
>> --- a/COPYING
>> +++ b/COPYING
>> @@ -1,3 +1,11 @@
>> +Except for the patches provided for packages, Buildroot is licensed
>> +under the GNU General Public License, version 2.
> 
> There a gotcha here. The manual states, in chapter 12.3:
> 
>     Buildroot [is] released under the GNU General Public License,
>     version 2 or (at your option) any later version.
> 
> So, we have to clarify: is it GPLv2 or GPLV2+ ?
> 
> It's too late today for me to go digging; I'll do that tomorrow. Just
> rmind me before the end of the week if there's not feedback from my part
> on this topic.
> 
> Until then, NAK.
> 
>> +Patches provided by Buildroot for packages are released under the same
>> +license as the software that they modify.
> 
> Here's an alternative proposal, to replace both sentences:
> 
>     Buildroot comes with its own license, reproduced below.
> 
>     Buildroot also bundles patch files, which are applied to the
>     sources of the various packages. Those patches are not covered
>     by the license of Buildroot. See those individual packages for
>     their license (running 'make legal-info' after your build may
>     help).

 Much better.

 Still better:

    Buildroot comes with its own license, reproduced below.

    Buildroot also bundles patch files, which are applied to the
    sources of the various packages. Those patches are not covered
    by the license of Buildroot, but are provided under the same
    license as the software they apply to. Run 'make legal-info' to
    collect the licenses of your selected packages and their patches.

(borrowing from the update of the manual here).

 Note that this sentence doesn't clarify the issue of proprietary licenses. It's
basically still the same as what we have now in that respect.

 Regards,
 Arnout

> 
> Regards,
> Yann E. MORIN.
> 
>> +-----------------------------------------------------------------
>> +
>>  		    GNU GENERAL PUBLIC LICENSE
>>  		       Version 2, June 1991
>>  
>> -- 
>> 1.9.1
>>
> 

-- 
Arnout Vandecappelle      arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Yann E. MORIN]

Arnout, Luca, All,

On 2016-02-04 00:57 +0100, Arnout Vandecappelle spake thusly:
> On 04-02-16 00:02, Yann E. MORIN wrote:
> > On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:
> >> Several people have been asking what is the license of the patches
> >> provided by Buildroot. COPYING is the authoritative place to state it.
> >>
> >> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> >> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >> Cc: Arnout Vandecappelle <arnout@mind.be>
> > 
> >> ---
> >> Changes v1 -> v2:
> >>  - Rewrite it almost entirely (Arnout, Thomas).
> >> ---
> >>  COPYING | 8 ++++++++
> >>  1 file changed, 8 insertions(+)
> >>
> >> diff --git a/COPYING b/COPYING
> >> index d511905..3596777 100644
> >> --- a/COPYING
> >> +++ b/COPYING
> >> @@ -1,3 +1,11 @@
> >> +Except for the patches provided for packages, Buildroot is licensed
> >> +under the GNU General Public License, version 2.
[--SNIP--]
> >> +Patches provided by Buildroot for packages are released under the same
> >> +license as the software that they modify.
> > 
> > Here's an alternative proposal, to replace both sentences:
> > 
> >     Buildroot comes with its own license, reproduced below.
> > 
> >     Buildroot also bundles patch files, which are applied to the
> >     sources of the various packages. Those patches are not covered
> >     by the license of Buildroot. See those individual packages for
> >     their license (running 'make legal-info' after your build may
> >     help).
> 
>  Much better.
> 
>  Still better:
> 
>     Buildroot comes with its own license, reproduced below.
> 
>     Buildroot also bundles patch files, which are applied to the
>     sources of the various packages. Those patches are not covered
>     by the license of Buildroot, but are provided under the same
>     license as the software they apply to. Run 'make legal-info' to
>     collect the licenses of your selected packages and their patches.

Indeed, that's even better.

> (borrowing from the update of the manual here).
> 
>  Note that this sentence doesn't clarify the issue of proprietary licenses. It's
> basically still the same as what we have now in that respect.

Not really. It is implicitly addressed, since the above states:

    [The patches] are provided under the same license as the software
    they apply to.

So, if someone has a proprietary license for a package *we* only can get
under an Open Source license, that someone would potentially be tricked
into believing that the patches we carry are under the license he was
provided that package under. Which is not really true, see below...

There are only two options:


 1) Our patches are available under the same license as the package they
    apply to is publicly and commonly available under.

    This basically means the patches can't be applied to a proprietary-
    licensed package when it is only publicly and commonly available
    under a Free (aka GPL-like) license. However, for an Open Source
    (aka BSD-like) license, they might still be useable on a proprietary-
    licensed package; and even so, that might not be completely possible,
    see point 2, third paragraph, below.

    This position has the benefit of clarifying the status of existing
    patches, as we can't easily relicense them, while we can easily
    srand by the position that this was the intended situation to begin
    with.


 2) Our patches are available under a license that allows them to still
    be applied even if the recipient of the package they modify has been
    granted different licensing terms (aka proprietary) than the ones
    that package is publicly and commonly available under.

    This means that part of the software we write is no longer Free (as
    from a GPL-sided point-of-view), basically this is a blank check for
    including them in proprietary software.

    Furthermore, we can not know all the proprietary licenses each such
    package may be available under, by the mere fact that such licenses
    may not be publicly known. In most, if not all jurisdiction, one can
    not be bound by terms one does not have knowledge of. I.e. if we
    wanted our patches to be useable under those licenses, then we would
    have to provide our patches under a *very* liberal license, probably
    just the Public Domain, as any license, even the most liberal ones
    like the WTFPL, may have terms that contradicts terms of such a
    proprietary license (which we have no detail for).

    Finally, this can not apply to our existing patches, as we can not
    assume that the original submitters of those patches would have
    expected they be made available under any license beside the license
    under which the package is publicly and commonly available.  I.e.
    we're anyway screwed with existing patches.


Yet, IANAL, TINLA etc...

We *really* need to sort out this situation, so that we all agree on
what the license for our patches are. Needless to say that I will
strongly advocate that we settle on the first solution.

Until we sort this out, the proposal by Arnout is probably the best we
can provide so far.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Thomas Petazzoni]

Hello,

On Thu, 4 Feb 2016 21:42:24 +0100, Yann E. MORIN wrote:

> Not really. It is implicitly addressed, since the above states:
> 
>     [The patches] are provided under the same license as the software
>     they apply to.
> 
> So, if someone has a proprietary license for a package *we* only can get
> under an Open Source license, that someone would potentially be tricked
> into believing that the patches we carry are under the license he was
> provided that package under. Which is not really true, see below...
> 
> There are only two options:
> 
> 
>  1) Our patches are available under the same license as the package they
>     apply to is publicly and commonly available under.
> 
>     This basically means the patches can't be applied to a proprietary-
>     licensed package when it is only publicly and commonly available
>     under a Free (aka GPL-like) license. However, for an Open Source
>     (aka BSD-like) license, they might still be useable on a proprietary-

The BSD license is both a Free Software license and an Open Source
Software license. The GPL is both a Free Software license and an Open
Source Software license.

I think you wanted to make the distinction between copyleft licenses
and non-copyleft licenses, which has rigorously *nothing* to do in the
Free vs. Open debate.

>  2) Our patches are available under a license that allows them to still
>     be applied even if the recipient of the package they modify has been
>     granted different licensing terms (aka proprietary) than the ones
>     that package is publicly and commonly available under.
> 
>     This means that part of the software we write is no longer Free (as
>     from a GPL-sided point-of-view), basically this is a blank check for
>     including them in proprietary software.
> 
>     Furthermore, we can not know all the proprietary licenses each such
>     package may be available under, by the mere fact that such licenses
>     may not be publicly known. In most, if not all jurisdiction, one can
>     not be bound by terms one does not have knowledge of. I.e. if we
>     wanted our patches to be useable under those licenses, then we would
>     have to provide our patches under a *very* liberal license, probably
>     just the Public Domain, as any license, even the most liberal ones
>     like the WTFPL, may have terms that contradicts terms of such a
>     proprietary license (which we have no detail for).
> 
>     Finally, this can not apply to our existing patches, as we can not
>     assume that the original submitters of those patches would have
>     expected they be made available under any license beside the license
>     under which the package is publicly and commonly available.  I.e.
>     we're anyway screwed with existing patches.

Not to mention the fact that we often re-use patches from other
projects: from the upstream project, from OpenEmbedded, OpenWRT, Alpine
Linux, and others.

The Yocto Project documentation says "Patches to the Yocto Project
follow the upstream licensing
scheme." (http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html).
Not super clear.

> We *really* need to sort out this situation, so that we all agree on
> what the license for our patches are. Needless to say that I will
> strongly advocate that we settle on the first solution.

I don't think we have any other solution but to release them only under
the publicly available open-source license. As you put it, we do not
even know the terms of the Qt or MySQL commercial licenses, so we can
hardly release code under those licenses.

So I'd say we should restrict ourselves to the open-source license of
the publicly available versions. Those who use the commercial variant
of those packages are on their own, and if they are using a commercial
variant, they should have access to support from their vendor.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Yann E. MORIN]

Thomas, All,

On 2016-02-04 22:08 +0100, Thomas Petazzoni spake thusly:
> On Thu, 4 Feb 2016 21:42:24 +0100, Yann E. MORIN wrote:
> > Not really. It is implicitly addressed, since the above states:
> > 
> >     [The patches] are provided under the same license as the software
> >     they apply to.
> > 
> > So, if someone has a proprietary license for a package *we* only can get
> > under an Open Source license, that someone would potentially be tricked
> > into believing that the patches we carry are under the license he was
> > provided that package under. Which is not really true, see below...
> > 
> > There are only two options:
> > 
> > 
> >  1) Our patches are available under the same license as the package they
> >     apply to is publicly and commonly available under.
> > 
> >     This basically means the patches can't be applied to a proprietary-
> >     licensed package when it is only publicly and commonly available
> >     under a Free (aka GPL-like) license. However, for an Open Source
> >     (aka BSD-like) license, they might still be useable on a proprietary-
> 
> The BSD license is both a Free Software license and an Open Source
> Software license. The GPL is both a Free Software license and an Open
> Source Software license.
> 
> I think you wanted to make the distinction between copyleft licenses
> and non-copyleft licenses, which has rigorously *nothing* to do in the
> Free vs. Open debate.

Yep. I spent three hours hashing that mail out, and I still made a
mistake on that part. Sigh... :-/

Thanks for correcting me on this. :-)

> >  2) Our patches are available under a license that allows them to still
> >     be applied even if the recipient of the package they modify has been
> >     granted different licensing terms (aka proprietary) than the ones
> >     that package is publicly and commonly available under.
> > 
> >     This means that part of the software we write is no longer Free (as
> >     from a GPL-sided point-of-view), basically this is a blank check for
> >     including them in proprietary software.
> > 
> >     Furthermore, we can not know all the proprietary licenses each such
> >     package may be available under, by the mere fact that such licenses
> >     may not be publicly known. In most, if not all jurisdiction, one can
> >     not be bound by terms one does not have knowledge of. I.e. if we
> >     wanted our patches to be useable under those licenses, then we would
> >     have to provide our patches under a *very* liberal license, probably
> >     just the Public Domain, as any license, even the most liberal ones
> >     like the WTFPL, may have terms that contradicts terms of such a
> >     proprietary license (which we have no detail for).
> > 
> >     Finally, this can not apply to our existing patches, as we can not
> >     assume that the original submitters of those patches would have
> >     expected they be made available under any license beside the license
> >     under which the package is publicly and commonly available.  I.e.
> >     we're anyway screwed with existing patches.
> 
> Not to mention the fact that we often re-use patches from other
> projects: from the upstream project, from OpenEmbedded, OpenWRT, Alpine
> Linux, and others.

Damn, three hours later, and I even missed that one...

> The Yocto Project documentation says "Patches to the Yocto Project
> follow the upstream licensing
> scheme." (http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html).
> Not super clear.

Nope, that's not pretty clear, but I'm not too surprised. These are
tricky matters, and it is very easy to fall through the cracks...

> > We *really* need to sort out this situation, so that we all agree on
> > what the license for our patches are. Needless to say that I will
> > strongly advocate that we settle on the first solution.
> 
> I don't think we have any other solution but to release them only under
> the publicly available open-source license. As you put it, we do not
> even know the terms of the Qt or MySQL commercial licenses, so we can
> hardly release code under those licenses.

Not counting that there might not be a single proprietary license for a
pcakge. Terms may very well vary from one licensee to another, depending
on a lot of factors we do not even know (like the phase of the Moon).

> So I'd say we should restrict ourselves to the open-source license of
> the publicly available versions. Those who use the commercial variant
> of those packages are on their own, and if they are using a commercial
> variant, they should have access to support from their vendor.

ACK.

So, what about the following:

    Buildroot comes with its own license, reproduced below.

    Buildroot also bundles patch files, which are applied to the sources
    of the various packages. Those patches are not covered by the license
    of Buildroot, but are provided under the same license as the software
    they apply to is publicly and commonly available under. Run 'make
    legal-info' to collect the licenses of your selected packages and
    their patches.

as a preamble to the COPYING file?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Thomas Petazzoni]

Hello,

On Thu, 4 Feb 2016 22:40:26 +0100, Yann E. MORIN wrote:

> So, what about the following:
> 
>     Buildroot comes with its own license, reproduced below.
> 
>     Buildroot also bundles patch files, which are applied to the sources
>     of the various packages. Those patches are not covered by the license
>     of Buildroot, but are provided under the same license as the software
>     they apply to is publicly and commonly available under. Run 'make
>     legal-info' to collect the licenses of your selected packages and
>     their patches.
> 
> as a preamble to the COPYING file?

I don't like the "commonly" available, but "commonly" is vague and
subject to interpretation.

Also, I think there is a grammatical problem with your sentence, if you
read it again. What about:

	Those patches are not covered by the license of Buildroot.
	Instead, they are covered by the license of the software they
	apply to. When said software is available under multiple
	licenses, the Buildroot patches are only provided under
	the publicly accessible licenses.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Steve Calfee]

On Thu, Feb 4, 2016 at 1:51 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Also, I think there is a grammatical problem with your sentence, if you
> read it again. What about:
>
>         Those patches are not covered by the license of Buildroot.
>         Instead, they are covered by the license of the software they
>         apply to. When said software is available under multiple
>         licenses, the Buildroot patches are only provided under
>         the publicly accessible licenses.
>

I had an English teacher who used to joke:
Do not use a preposition to end a sentence with.

(to, for, with ...) are prepositions.

How about:
"Instead, they are covered by the license of the software to which the
patches are applied."

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Luca Ceresoli]

Hi Yann, all,

Yann E. MORIN wrote:
> Arnout, Luca, All,
>
> On 2016-02-04 00:57 +0100, Arnout Vandecappelle spake thusly:
>> On 04-02-16 00:02, Yann E. MORIN wrote:
>>> On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:
>>>> Several people have been asking what is the license of the patches
>>>> provided by Buildroot. COPYING is the authoritative place to state it.
>>>>
>>>> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
>>>> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>>> Cc: Arnout Vandecappelle <arnout@mind.be>
>>>
>>>> ---
>>>> Changes v1 -> v2:
>>>>   - Rewrite it almost entirely (Arnout, Thomas).
>>>> ---
>>>>   COPYING | 8 ++++++++
>>>>   1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/COPYING b/COPYING
>>>> index d511905..3596777 100644
>>>> --- a/COPYING
>>>> +++ b/COPYING
>>>> @@ -1,3 +1,11 @@
>>>> +Except for the patches provided for packages, Buildroot is licensed
>>>> +under the GNU General Public License, version 2.
> [--SNIP--]
>>>> +Patches provided by Buildroot for packages are released under the same
>>>> +license as the software that they modify.
>>>
>>> Here's an alternative proposal, to replace both sentences:
>>>
>>>      Buildroot comes with its own license, reproduced below.
>>>
>>>      Buildroot also bundles patch files, which are applied to the
>>>      sources of the various packages. Those patches are not covered
>>>      by the license of Buildroot. See those individual packages for
>>>      their license (running 'make legal-info' after your build may
>>>      help).
>>
>>   Much better.
>>
>>   Still better:
>>
>>      Buildroot comes with its own license, reproduced below.
>>
>>      Buildroot also bundles patch files, which are applied to the
>>      sources of the various packages. Those patches are not covered
>>      by the license of Buildroot, but are provided under the same
>>      license as the software they apply to. Run 'make legal-info' to
>>      collect the licenses of your selected packages and their patches.

I would like to preserve from the original wording by Yann the fact that
'make legal-info' _may_ _help_ to collect the needed info. It's safer in
the case legal-info provides incomplete or incorrect information, e.g.
when FOO_LICENSE is incorrect (it has happened in the past, it will in
the future).

>> (borrowing from the update of the manual here).
>>
>>   Note that this sentence doesn't clarify the issue of proprietary licenses. It's
>> basically still the same as what we have now in that respect.
>
> Not really. It is implicitly addressed, since the above states:
>
>      [The patches] are provided under the same license as the software
>      they apply to.
>
> So, if someone has a proprietary license for a package *we* only can get
> under an Open Source license, that someone would potentially be tricked
> into believing that the patches we carry are under the license he was
> provided that package under. Which is not really true, see below...
>
> There are only two options:
>
>
>   1) Our patches are available under the same license as the package they
>      apply to is publicly and commonly available under.
>
>      This basically means the patches can't be applied to a proprietary-
>      licensed package when it is only publicly and commonly available
>      under a Free (aka GPL-like) license. However, for an Open Source
>      (aka BSD-like) license, they might still be useable on a proprietary-
>      licensed package; and even so, that might not be completely possible,
>      see point 2, third paragraph, below.
>
>      This position has the benefit of clarifying the status of existing
>      patches, as we can't easily relicense them, while we can easily
>      srand by the position that this was the intended situation to begin
>      with.
>
>
>   2) Our patches are available under a license that allows them to still
>      be applied even if the recipient of the package they modify has been
>      granted different licensing terms (aka proprietary) than the ones
>      that package is publicly and commonly available under.
>
>      This means that part of the software we write is no longer Free (as
>      from a GPL-sided point-of-view), basically this is a blank check for
>      including them in proprietary software.
>
>      Furthermore, we can not know all the proprietary licenses each such
>      package may be available under, by the mere fact that such licenses
>      may not be publicly known. In most, if not all jurisdiction, one can
>      not be bound by terms one does not have knowledge of. I.e. if we
>      wanted our patches to be useable under those licenses, then we would
>      have to provide our patches under a *very* liberal license, probably
>      just the Public Domain, as any license, even the most liberal ones
>      like the WTFPL, may have terms that contradicts terms of such a
>      proprietary license (which we have no detail for).
>
>      Finally, this can not apply to our existing patches, as we can not
>      assume that the original submitters of those patches would have
>      expected they be made available under any license beside the license
>      under which the package is publicly and commonly available.  I.e.
>      we're anyway screwed with existing patches.

At first I thought we had a choice between 1) and 2). But after
reconsidering it, option 2) is most likely just illegal, and definitely
risky.

My vote is for option 1) too.

We had several rewrite proposals so far. I'll wait a few more days for
more comments, then resubmit. Peter, your opinion would be most welcome.
-- 
Luca

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Peter Korsgaard]

>>>>> "Luca" == Luca Ceresoli <luca@lucaceresoli.net> writes:

Hi,

 > At first I thought we had a choice between 1) and 2). But after
 > reconsidering it, option 2) is most likely just illegal, and definitely
 > risky.

 > My vote is for option 1) too.

 > We had several rewrite proposals so far. I'll wait a few more days for
 > more comments, then resubmit. Peter, your opinion would be most welcome.

Yes, option 1 seems the best option to me as well.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH v2 2/5] docs/manual: slightly clarify patch licensing

[Arnout Vandecappelle]

On 01-02-16 23:19, Luca Ceresoli wrote:
> Adding a patch is a modification to Buildroot. Thus this sentence might be
> interpreted as "Patches are released under the Buildroot license".
> 
> Being a legal matter, the last thing we want is to be
> ambiguous. Reword the sentence to avoid any misunderstandings.
> 
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

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

 Please still add this in 2016.02.


 Regards,
 Arnout

> 
> ---
> Changes v1 -> v2:
> - "they modify" -> "they apply to" (Thomas).
> ---
>  docs/manual/patch-policy.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
> index 0b4604e..d50c971 100644
> --- a/docs/manual/patch-policy.txt
> +++ b/docs/manual/patch-policy.txt
> @@ -90,8 +90,8 @@ 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 that is
> -modified.
> +Patches are released under the same license as the software they apply
> +to.
>  
>  A message explaining what the patch does, and why it is needed, should
>  be added in the header commentary of the patch.
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Arnout Vandecappelle]

On 04-02-16 00:02, Yann E. MORIN wrote:
> Luca, All,
> 
> On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:
>> > Several people have been asking what is the license of the patches
>> > provided by Buildroot. COPYING is the authoritative place to state it.
>> > 
>> > Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
>> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> > Cc: Arnout Vandecappelle <arnout@mind.be>
>> > ---
>> > Changes v1 -> v2:
>> >  - Rewrite it almost entirely (Arnout, Thomas).
>> > ---
>> >  COPYING | 8 ++++++++
>> >  1 file changed, 8 insertions(+)
>> > 
>> > diff --git a/COPYING b/COPYING
>> > index d511905..3596777 100644
>> > --- a/COPYING
>> > +++ b/COPYING
>> > @@ -1,3 +1,11 @@
>> > +Except for the patches provided for packages, Buildroot is licensed
>> > +under the GNU General Public License, version 2.
> There a gotcha here. The manual states, in chapter 12.3:
> 
>     Buildroot [is] released under the GNU General Public License,
>     version 2 or (at your option) any later version.
> 
> So, we have to clarify: is it GPLv2 or GPLV2+ ?
> 
> It's too late today for me to go digging; I'll do that tomorrow. Just
> rmind me before the end of the week if there's not feedback from my part
> on this topic.

 Reminder :-)

 But I did the digging. The situation is of course complicated.

 We don't have many files that specify a license by themselves. All of them
specify 'or later', except for makedevs.c (obviously, because it is copied from
busybox), toolchain-wrapper.c (added by Peter in 2011), and the manual itself,
which specify v2 only.

 The top-level Makefile is the only thing of which you could say that it has
project-wide scope. And that says 'or later'.

 So, what does that mean for buildroot as a whole? I think it is GPLv2+, except
for the package patches and except for the files that explicitly specify a
different license. Can we fit that in the formulation that evolved in this thread?


 Regards,
 Arnout

> 
> Until then, NAK.
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

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

[Arnout Vandecappelle]

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.
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Luca Ceresoli]

Arnout, All,

On 10/02/2016 23:35, Arnout Vandecappelle wrote:
> On 04-02-16 00:02, Yann E. MORIN wrote:
>> Luca, All,
>>
>> On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:
>>>> Several people have been asking what is the license of the patches
>>>> provided by Buildroot. COPYING is the authoritative place to state it.
>>>>
>>>> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
>>>> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>>> Cc: Arnout Vandecappelle <arnout@mind.be>
>>>> ---
>>>> Changes v1 -> v2:
>>>>  - Rewrite it almost entirely (Arnout, Thomas).
>>>> ---
>>>>  COPYING | 8 ++++++++
>>>>  1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/COPYING b/COPYING
>>>> index d511905..3596777 100644
>>>> --- a/COPYING
>>>> +++ b/COPYING
>>>> @@ -1,3 +1,11 @@
>>>> +Except for the patches provided for packages, Buildroot is licensed
>>>> +under the GNU General Public License, version 2.
>> There a gotcha here. The manual states, in chapter 12.3:
>>
>>     Buildroot [is] released under the GNU General Public License,
>>     version 2 or (at your option) any later version.
>>
>> So, we have to clarify: is it GPLv2 or GPLV2+ ?
>>
>> It's too late today for me to go digging; I'll do that tomorrow. Just
>> rmind me before the end of the week if there's not feedback from my part
>> on this topic.
> 
>  Reminder :-)
> 
>  But I did the digging. The situation is of course complicated.
> 
>  We don't have many files that specify a license by themselves. All of them
> specify 'or later', except for makedevs.c (obviously, because it is copied from
> busybox), toolchain-wrapper.c (added by Peter in 2011), and the manual itself,
> which specify v2 only.
> 
>  The top-level Makefile is the only thing of which you could say that it has
> project-wide scope. And that says 'or later'.
> 
>  So, what does that mean for buildroot as a whole? I think it is GPLv2+, except
> for the package patches and except for the files that explicitly specify a
> different license. Can we fit that in the formulation that evolved in this thread?

Here's what I've been able to come up with so far. It's basically:
- the sum of the present thread, plus
- a reduced and modified version of the preamble suggested in the
  GNU GPL itself (section "How to Apply These Terms to Your New
  Programs"), plus
- the statement that BR is GPLv2+ except where differently stated,
  as Arnout suggested.

I'm sure this needs further discussion and improvements.

-------------------------8<----------------------

With the exceptions below, Buildroot is	distributed under the terms of
the GNU General Public License, reproduced below; either version 2 of
the License, or (at your option) any later version.

Some files in Buildroot contain a different license statement. Those
files are licensed under the license contained in the file itself.

Buildroot also bundles patch files, which are applied to the sources
of the various packages. Those patches are not covered by the license
of Buildroot. Instead, they are covered by the license of the software
to which the patches are applied. When said software is available
under multiple licenses, the Buildroot patches are only provided under
the publicly accessible licenses.

-------------------------8<----------------------

-- 
Luca

[Buildroot] [PATCH v2 2/5] docs/manual: slightly clarify patch licensing

[Peter Korsgaard]

>>>>> "Luca" == Luca Ceresoli <luca@lucaceresoli.net> writes:

 > Adding a patch is a modification to Buildroot. Thus this sentence might be
 > interpreted as "Patches are released under the Buildroot license".

 > Being a legal matter, the last thing we want is to be
 > ambiguous. Reword the sentence to avoid any misunderstandings.

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

 > ---
 > Changes v1 -> v2:
 > - "they modify" -> "they apply to" (Thomas).

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Peter Korsgaard]

>>>>> "Luca" == Luca Ceresoli <luca@lucaceresoli.net> writes:

Hi,

 > Here's what I've been able to come up with so far. It's basically:
 > - the sum of the present thread, plus
 > - a reduced and modified version of the preamble suggested in the
 >   GNU GPL itself (section "How to Apply These Terms to Your New
 >   Programs"), plus
 > - the statement that BR is GPLv2+ except where differently stated,
 >   as Arnout suggested.

 > I'm sure this needs further discussion and improvements.

 > -------------------------8<----------------------

 > With the exceptions below, Buildroot is	distributed under the terms of
 > the GNU General Public License, reproduced below; either version 2 of
 > the License, or (at your option) any later version.

 > Some files in Buildroot contain a different license statement. Those
 > files are licensed under the license contained in the file itself.

 > Buildroot also bundles patch files, which are applied to the sources
 > of the various packages. Those patches are not covered by the license
 > of Buildroot. Instead, they are covered by the license of the software
 > to which the patches are applied. When said software is available
 > under multiple licenses, the Buildroot patches are only provided under
 > the publicly accessible licenses.

This sounds good to me. Do anyone disagree or can this be committed to
master?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v2 3/5] COPYING: add exception about patch licensing

[Luca Ceresoli]

Hi Peter,

On 25/02/2016 11:57, Peter Korsgaard wrote:
>>>>>> "Luca" == Luca Ceresoli <luca@lucaceresoli.net> writes:
> 
> Hi,
> 
>  > Here's what I've been able to come up with so far. It's basically:
>  > - the sum of the present thread, plus
>  > - a reduced and modified version of the preamble suggested in the
>  >   GNU GPL itself (section "How to Apply These Terms to Your New
>  >   Programs"), plus
>  > - the statement that BR is GPLv2+ except where differently stated,
>  >   as Arnout suggested.
> 
>  > I'm sure this needs further discussion and improvements.
> 
>  > -------------------------8<----------------------
> 
>  > With the exceptions below, Buildroot is	distributed under the terms of
>  > the GNU General Public License, reproduced below; either version 2 of
>  > the License, or (at your option) any later version.
> 
>  > Some files in Buildroot contain a different license statement. Those
>  > files are licensed under the license contained in the file itself.
> 
>  > Buildroot also bundles patch files, which are applied to the sources
>  > of the various packages. Those patches are not covered by the license
>  > of Buildroot. Instead, they are covered by the license of the software
>  > to which the patches are applied. When said software is available
>  > under multiple licenses, the Buildroot patches are only provided under
>  > the publicly accessible licenses.
> 
> This sounds good to me. Do anyone disagree or can this be committed to
> master?

Given your approval I just sent v3 with the above text as-is, so anybody
can formally Ack/Nack and you can apply it without manual copy-pasting.

-- 
Luca

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

[Luca Ceresoli]

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

-- 
Luca

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

[Yann E. MORIN]

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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2 5/5] legal-info: explicitly state how patches are licensed

[Thomas Petazzoni]

Dear Luca Ceresoli,

On Mon,  1 Feb 2016 23:19:56 +0100, Luca Ceresoli wrote:
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> ---
>  support/legal-info/README.header | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This patch is still in the queue, but no longer applies on master. Can
you respin, if it is still needed?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 5/5] legal-info: explicitly state how patches are licensed

[Luca Ceresoli]

Dear Thomas, Yann,

On 06/03/2016 16:14, Thomas Petazzoni wrote:
> Dear Luca Ceresoli,
> 
> On Mon,  1 Feb 2016 23:19:56 +0100, Luca Ceresoli wrote:
>> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
>> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>> ---
>>  support/legal-info/README.header | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> This patch is still in the queue, but no longer applies on master. Can
> you respin, if it is still needed?

It never applied on master! :) It only applies on top of Yann's legal
series (it would be useless on master anyway). Thus it is not even
outdated, it is not _yet_ applicable...

I explained that in the cover letter, but now I realize I should have
done it [also] in notes to the patch itself as the cover letter is not
visible from patchwork. Will think about it next time.

Yann, since this patch is actually a completion to your legal series,
and since is cleanly applies on top of it, you might want to take it as
part of your series. Otherwise I'll resend when your legal series will
be applied.

-- 
Luca

[Buildroot] [PATCH v2 5/5] legal-info: explicitly state how patches are licensed

[Yann E. MORIN]

Luca, All,

On 2016-03-06 23:52 +0100, Luca Ceresoli spake thusly:
> On 06/03/2016 16:14, Thomas Petazzoni wrote:
> > Dear Luca Ceresoli,
> > 
> > On Mon,  1 Feb 2016 23:19:56 +0100, Luca Ceresoli wrote:
> >> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> >> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> >> ---
> >>  support/legal-info/README.header | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > This patch is still in the queue, but no longer applies on master. Can
> > you respin, if it is still needed?
> 
> It never applied on master! :) It only applies on top of Yann's legal
> series (it would be useless on master anyway). Thus it is not even
> outdated, it is not _yet_ applicable...
> 
> I explained that in the cover letter, but now I realize I should have
> done it [also] in notes to the patch itself as the cover letter is not
> visible from patchwork. Will think about it next time.
> 
> Yann, since this patch is actually a completion to your legal series,
> and since is cleanly applies on top of it, you might want to take it as
> part of your series. Otherwise I'll resend when your legal series will
> be applied.

OK, I'll cary it. Thanks! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'