| Message ID | 1454365196-26319-4-git-send-email-luca@lucaceresoli.net |
|---|---|
| State | Superseded |
| Headers | show |
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
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 >
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, 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.
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, 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.
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
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."
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" == 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.
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, 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" == 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?
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.
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
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(+)