Patch file clarification & Co

Signed-off-by Luca Ceresoli <[email protected]>

---
  Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Makefile +0 -0

index c3427ed..1acc2b2 100644

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 <[email protected]>

Cc Thomas Petazzoni <[email protected]>

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

---
 docs/manual/patch-policy.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

docs/manual/patch-policy.txt +2 -2

index 0b4604e..d50c971 100644
@@ -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.

Signature · 1 line

1.9.1

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 <[email protected]>

Cc Thomas Petazzoni <[email protected]>

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

---
 docs/manual/patch-policy.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

docs/manual/patch-policy.txt +2 -2

index 0b4604e..d50c971 100644
@@ -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.

Signature · 1 line

1.9.1

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 <[email protected]>

Cc Thomas Petazzoni <[email protected]>

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

---
 docs/manual/patch-policy.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

docs/manual/patch-policy.txt +2 -2

index 0b4604e..d50c971 100644
@@ -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.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Luca" == Luca Ceresoli <[email protected]> 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 <[email protected]>

Cc Thomas Petazzoni <[email protected]>

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

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 <[email protected]>

Cc Thomas Petazzoni <[email protected]>

Cc Arnout Vandecappelle <[email protected]>

---
Changes v1 -> v2:
- Rewrite it almost entirely (Arnout, Thomas).

---
 COPYING | 8 ++++++++
 1 file changed, 8 insertions(+)

COPYING +0 -0

index d511905..3596777 100644

COPYING +2 -0

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

Signature · 1 line

1.9.1

Luca, All,

On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:

Quoted 19 lines

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 <[email protected]>

Cc Thomas Petazzoni <[email protected]>

Cc Arnout Vandecappelle <[email protected]>

---
Changes v1 -> v2:
- Rewrite it almost entirely (Arnout, Thomas).

---
 COPYING | 8 ++++++++
 1 file changed, 8 insertions(+)

COPYING +0 -0

index d511905..3596777 100644

COPYING line 2

Quoted 2 lines

COPYING +2 -0

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

COPYING line 5

Quoted 2 lines

COPYING +2 -0

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

Quoted 8 lines

COPYING +2 -0

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

Signature · 1 line

1.9.1

Quoted 15 lines

On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:

Quoted 14 lines

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 <[email protected]>

Cc Thomas Petazzoni <[email protected]>

Cc Arnout Vandecappelle <[email protected]>

---
Changes v1 -> v2:
- Rewrite it almost entirely (Arnout, Thomas).

---
 COPYING | 8 ++++++++
 1 file changed, 8 insertions(+)

Quoted 7 lines

COPYING line 2

Quoted 7 lines

COPYING +2 -0

index d511905..3596777 100644
@@ -1,3 +1,11 @@
+Except for the patches provided for packages, Buildroot is licensed
+under the GNU General Public License, version 2.

Quoted 5 lines

COPYING line 5

Quoted 2 lines

COPYING +2 -0

+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:

Quoted 7 lines

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.

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-

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.

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.

Quoted 13 lines

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:

Quoted 7 lines

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.

Quoted 19 lines

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

Quoted 5 lines

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.

Quoted 3 lines

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.

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?

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.

Arnout, Luca, All,

On 2016-02-04 00:57 +0100, Arnout Vandecappelle spake thusly:

Quoted 16 lines · Yann E. MORIN

Quoted 15 lines

On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:

Quoted 14 lines

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 <[email protected]>

Cc Thomas Petazzoni <[email protected]>

Cc Arnout Vandecappelle <[email protected]>

---
Changes v1 -> v2:
- Rewrite it almost entirely (Arnout, Thomas).

---
  COPYING | 8 ++++++++
  1 file changed, 8 insertions(+)

Quoted 7 lines

Quoted 7 lines

COPYING line 2

Quoted 7 lines

COPYING +2 -0

index d511905..3596777 100644
@@ -1,3 +1,11 @@
+Except for the patches provided for packages, Buildroot is licensed
+under the GNU General Public License, version 2.

[--SNIP--]

Quoted 24 lines

Quoted 5 lines

COPYING line 5

Quoted 2 lines

COPYING +2 -0

+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:

Quoted 7 lines

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.

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Luca" == Luca Ceresoli <[email protected]> writes:

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, All,

On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:

Quoted 13 lines

Quoted 13 lines

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 <[email protected]>

Cc Thomas Petazzoni <[email protected]>

Cc Arnout Vandecappelle <[email protected]>

---
Changes v1 -> v2:
- Rewrite it almost entirely (Arnout, Thomas).

---
 COPYING | 8 ++++++++
 1 file changed, 8 insertions(+)

Quoted 7 lines

COPYING line 2

Quoted 7 lines

COPYING +2 -0

index d511905..3596777 100644
@@ -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.

Quoted 25 lines · Yann E. MORIN

Luca, All,

On 2016-02-01 23:19 +0100, Luca Ceresoli spake thusly:

Quoted 13 lines

Quoted 13 lines

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 <[email protected]>

Cc Thomas Petazzoni <[email protected]>

Cc Arnout Vandecappelle <[email protected]>

---
Changes v1 -> v2:
- Rewrite it almost entirely (Arnout, Thomas).

---
 COPYING | 8 ++++++++
 1 file changed, 8 insertions(+)

Quoted 7 lines

COPYING line 2

Quoted 7 lines

COPYING +2 -0

index d511905..3596777 100644
@@ -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:

Quoted 8 lines

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?

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Luca" == Luca Ceresoli <[email protected]> writes:

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.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Luca" == Luca Ceresoli <[email protected]> writes:

Hi,

Quoted 19 lines

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.

Quoted 6 lines

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?

Signed-off-by Luca Ceresoli <[email protected]>

Acked-by Thomas Petazzoni <[email protected]>

---
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(-)

docs/manual/legal-notice.txt +0 -0

index 5895224..49c4965 100644
@@ -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];

They are not distributed under the Buildroot license.

docs/manual/patch-policy.txt +1 -1

index d50c971..fe432a7 100644
@@ -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.

Signature · 1 line

1.9.1

Review

Quoted 3 lines

+==== Patches to packages

(quoted diff) +2 -0

+
+Buildroot is bundled with a set of patches that it applies to packages

... that are applied to...

docs/manual/legal-notice.txt material that must be redistributed. · line 168

Quoted 4 lines

docs/manual/legal-notice.txt +4 -0

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

Quoted 1 line

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

and so are released...

Quoted 1 line

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

Quoted 1 line

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

Quoted 13 lines

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);

Quoted 4 lines

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

Quoted 11 lines

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

Quoted 1 line

They are not distributed under the Buildroot license.

Quoted 5 lines

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

Signed-off-by Luca Ceresoli <[email protected]>

Acked-by Thomas Petazzoni <[email protected]>

---
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(-)

docs/manual/legal-notice.txt +14 -2

index 5895224..49c4965 100644
@@ -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.

docs/manual/patch-policy.txt +0 -0

index d50c971..fe432a7 100644

docs/manual/patch-policy.txt +0 -0

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

Signed-off-by Luca Ceresoli <[email protected]>

Acked-by Thomas Petazzoni <[email protected]>

Acked-by "Yann E. MORIN" <[email protected]>

---
 support/legal-info/README.header | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Dear Luca Ceresoli,

Quoted 6 lines · Luca Ceresoli

Signed-off-by Luca Ceresoli <[email protected]>

Acked-by Thomas Petazzoni <[email protected]>

Acked-by "Yann E. MORIN" <[email protected]>

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

Quoted 10 lines

Dear Luca Ceresoli,

Quoted 6 lines · Luca Ceresoli

Signed-off-by Luca Ceresoli <[email protected]>

Acked-by Thomas Petazzoni <[email protected]>

Acked-by "Yann E. MORIN" <[email protected]>

---
 support/legal-info/README.header | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Quoted 2 lines

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.