Patchwork [v4,09/22] manual: add advice about GPL compliance for Buildroot

login
register
mail settings
Submitter Luca Ceresoli
Date May 17, 2012, 5:33 p.m.
Message ID <1337276001-26149-10-git-send-email-luca@lucaceresoli.net>
Download mbox | patch
Permalink /patch/159989/
State Accepted
Headers show

Comments

Luca Ceresoli - May 17, 2012, 5:33 p.m.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
 docs/manual/using.txt |   27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)
Thomas De Schampheleire - May 17, 2012, 8:56 p.m.
Op 17 mei 2012 19:35 schreef "Luca Ceresoli" <luca@lucaceresoli.net> het
volgende:
>
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> ---
>  docs/manual/using.txt |   27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/docs/manual/using.txt b/docs/manual/using.txt
> index 42d4061..fcbd24b 100644
> --- a/docs/manual/using.txt
> +++ b/docs/manual/using.txt
> @@ -284,3 +284,30 @@ Buildroot, with the name used in the manifest file:
>  * +BSD-2c+: BSD 2-clause license;
>  * +PROPRIETARY+: marks a non-opensource package;
>   Buildroot does not save any licensing info or source code for these
packages.
> +
> +Complying with the Buildroot license
> +------------------------------------
> +
> +Buildroot itself is an opensource 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.
> +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
> +in the device storage.
> +
> +Nevertheless, the general view of the Buildroot developers is that you
should
> +release the Buildroot source code along with the source code of other
packages
> +when releasing a product that contains GPL-licensed software.
> +This is because the
> +http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU GPL]
> +defines the "'complete source code'" for an executable work as "'all the
> +source code for all modules it contains, plus any associated interface
> +definition files, plus the scripts used to control compilation and
installation
> +of the executable'".
> +Buildroot is part of the 'scripts used to control compilation and
> +installation of the executable', and as such it is considered part of the
> +material that must be redistributed.
> +
> +Keep in mind this is only the Buildroot developers' opinion, and you
should
> +consult your legal department or lawyer in case of any doubt.

Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Arnout Vandecappelle - May 20, 2012, 12:37 p.m.
On 05/17/12 19:33, Luca Ceresoli wrote:
> Signed-off-by: Luca Ceresoli<luca@lucaceresoli.net>
> ---
>   docs/manual/using.txt |   27 +++++++++++++++++++++++++++
>   1 file changed, 27 insertions(+)
>
> diff --git a/docs/manual/using.txt b/docs/manual/using.txt
> index 42d4061..fcbd24b 100644
> --- a/docs/manual/using.txt
> +++ b/docs/manual/using.txt
> @@ -284,3 +284,30 @@ Buildroot, with the name used in the manifest file:
>   * +BSD-2c+: BSD 2-clause license;
>   * +PROPRIETARY+: marks a non-opensource package;
>     Buildroot does not save any licensing info or source code for these packages.
> +
> +Complying with the Buildroot license
> +------------------------------------
> +
> +Buildroot itself is an opensource 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.
> +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
> +in the device storage.
> +
> +Nevertheless, the general view of the Buildroot developers is that you should
> +release the Buildroot source code along with the source code of other packages
> +when releasing a product that contains GPL-licensed software.
> +This is because the
> +http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU GPL]
> +defines the "'complete source code'" for an executable work as "'all the
> +source code for all modules it contains, plus any associated interface
> +definition files, plus the scripts used to control compilation and installation
> +of the executable'".
> +Buildroot is part of the 'scripts used to control compilation and
> +installation of the executable', and as such it is considered part of the
> +material that must be redistributed.
> +
> +Keep in mind this is only the Buildroot developers' opinion, and you should
> +consult your legal department or lawyer in case of any doubt.

Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Luca Ceresoli - July 5, 2012, 1:52 p.m.
Hi,

Luca Ceresoli wrote:
> Signed-off-by: Luca Ceresoli<luca@lucaceresoli.net>
> ---
>   docs/manual/using.txt |   27 +++++++++++++++++++++++++++
>   1 file changed, 27 insertions(+)
>
> diff --git a/docs/manual/using.txt b/docs/manual/using.txt
> index 42d4061..fcbd24b 100644
> --- a/docs/manual/using.txt
> +++ b/docs/manual/using.txt
> @@ -284,3 +284,30 @@ Buildroot, with the name used in the manifest file:
>   * +BSD-2c+: BSD 2-clause license;
>   * +PROPRIETARY+: marks a non-opensource package;
>     Buildroot does not save any licensing info or source code for these packages.
> +
> +Complying with the Buildroot license
> +------------------------------------
> +
> +Buildroot itself is an opensource 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.
> +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
> +in the device storage.
> +
> +Nevertheless, the general view of the Buildroot developers is that you should
> +release the Buildroot source code along with the source code of other packages
> +when releasing a product that contains GPL-licensed software.
> +This is because the
> +http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU GPL]
> +defines the "'complete source code'" for an executable work as "'all the
> +source code for all modules it contains, plus any associated interface
> +definition files, plus the scripts used to control compilation and installation
> +of the executable'".
> +Buildroot is part of the 'scripts used to control compilation and
> +installation of the executable', and as such it is considered part of the
> +material that must be redistributed.
> +
> +Keep in mind this is only the Buildroot developers' opinion, and you should
> +consult your legal department or lawyer in case of any doubt.

The above text has been Acked-By two Buildroot developers and had no 
negative
comments after ~6 weeks, which is good.

Nevertheless, I think it lacks some parts that I would like to be clarified.

A Buildroot tree is made up of the following parts:
  1. the various makefiles and scripts that build the toolchain, handle
     package compilation and generate a root filesystem, which is the heart
     of Buildroot;
  2. patches to packages;
  3. small, proprietary, project-specific applications or libraries whose
     source code resides in the Buildroot tree (not present in mainline).

The above clarification text, as well as the COPYING text, obviously applies
to point 1, but IMO points 2 and 3 need a different policy.

Patches to packages are modifications to externally-developed code, so I
think they fall under the same license as the package.
If this is correct, a clarification should be added to the above text and,
more important, to COPYING, much like the note at the beginning of the
Linux COPYING file.

Point 3 refers to the method described by Thomas Petazzoni in
http://elinux.org/images/2/2a/Using-buildroot-real-project.pdf, page 30.
The idea is that small "project-specific applications or libraries" can be
kept inside the Buildroot tree to simplify its integration.

Technically, it's how makedevs works in Buildroot. Is makedevs considered "a
part of Buildroot"? It think it is.
But one may want to develop another small utility in the same way inside the
Buildroot tree, but keeping it proprietary. As such, it should be clear
whether or not it is allowed to keep such code inside the Buildroot tree
without it falling under the Buildroot license.

My personal feeling is that Buildroot should allow to keep such proprietary
code in the tree, but with a clear way to determine that they are not
considered a derived work of Buildroot.
The discrimination could be: whatever is a package (in the Buildroot
meaning) *and* has <PKG>_LICENSE = PROPRIETARY in its .mk is considered not
to be a part of Buildroot and can have a different license.
This clause should be part of COPYING and documented in the manual too.
The legal-info code does not currently save the Buildroot tree, but when it
will be able to do so it should also be able to skip such packages.

Of course this would allow a more flexible usage of Buildroot in real life,
but at the cost of making the licensing policy more complex.

What areyour opinions?

Thanks,
Luca
Arnout Vandecappelle - July 5, 2012, 8:23 p.m.
On 07/05/12 15:52, Luca Ceresoli wrote:
> The above text has been Acked-By two Buildroot developers and had no negative
> comments after ~6 weeks, which is good.
>
> Nevertheless, I think it lacks some parts that I would like to be clarified.
>
> A Buildroot tree is made up of the following parts:
>   1. the various makefiles and scripts that build the toolchain, handle
>      package compilation and generate a root filesystem, which is the heart
>      of Buildroot;
>   2. patches to packages;
>   3. small, proprietary, project-specific applications or libraries whose
>      source code resides in the Buildroot tree (not present in mainline).
>
> The above clarification text, as well as the COPYING text, obviously applies
> to point 1, but IMO points 2 and 3 need a different policy.
>
> Patches to packages are modifications to externally-developed code, so I
> think they fall under the same license as the package.

  Good point.  Without clarification, the patches would carry buildroot's
GPL and hence spread into the package's they're applied to.  OTOH the
Signed-off-by lines in the patches could be construed to imply that the
patch follows the license of the files that it's applied to (cfr. DCO).


> If this is correct, a clarification should be added to the above text and,
> more important, to COPYING, much like the note at the beginning of the
> Linux COPYING file.

  Ack.


> Point 3 refers to the method described by Thomas Petazzoni in
> http://elinux.org/images/2/2a/Using-buildroot-real-project.pdf, page 30.
> The idea is that small "project-specific applications or libraries" can be
> kept inside the Buildroot tree to simplify its integration.
>
> Technically, it's how makedevs works in Buildroot. Is makedevs considered "a
> part of Buildroot"? It think it is.
> But one may want to develop another small utility in the same way inside the
> Buildroot tree, but keeping it proprietary. As such, it should be clear
> whether or not it is allowed to keep such code inside the Buildroot tree
> without it falling under the Buildroot license.

  I would say that this falls under the 'mere aggregation' clause.  Whether
the source code of a proprietary program is in package/foo or in ../foo
really makes no difference at all.

  That said, it would be good to clarify that point.


> My personal feeling is that Buildroot should allow to keep such proprietary
> code in the tree, but with a clear way to determine that they are not
> considered a derived work of Buildroot.
> The discrimination could be: whatever is a package (in the Buildroot
> meaning) *and* has <PKG>_LICENSE = PROPRIETARY in its .mk is considered not
> to be a part of Buildroot and can have a different license.

  *Very* good point.  The GPL itself is too vague to really be sure of what
constitutes a derived work of buildroot.

  What about the finalize script?  Is that part of the derived work?  For sure,
whether it is or not should not depend on whether the file is within or
outside of the tree...


> This clause should be part of COPYING and documented in the manual too.
> The legal-info code does not currently save the Buildroot tree, but when it
> will be able to do so it should also be able to skip such packages.
>
> Of course this would allow a more flexible usage of Buildroot in real life,
> but at the cost of making the licensing policy more complex.

  The licensing of buildroot _is_ complex.  For the moment, it looks simple
because it is fuzzy, all the complexity is hidden.

  Regards,
  Arnout

Patch

diff --git a/docs/manual/using.txt b/docs/manual/using.txt
index 42d4061..fcbd24b 100644
--- a/docs/manual/using.txt
+++ b/docs/manual/using.txt
@@ -284,3 +284,30 @@  Buildroot, with the name used in the manifest file:
 * +BSD-2c+: BSD 2-clause license;
 * +PROPRIETARY+: marks a non-opensource package;
   Buildroot does not save any licensing info or source code for these packages.
+
+Complying with the Buildroot license
+------------------------------------
+
+Buildroot itself is an opensource 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.
+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
+in the device storage.
+
+Nevertheless, the general view of the Buildroot developers is that you should
+release the Buildroot source code along with the source code of other packages
+when releasing a product that contains GPL-licensed software.
+This is because the
+http://www.gnu.org/licenses/old-licenses/gpl-2.0.html[GNU GPL]
+defines the "'complete source code'" for an executable work as "'all the
+source code for all modules it contains, plus any associated interface
+definition files, plus the scripts used to control compilation and installation
+of the executable'".
+Buildroot is part of the 'scripts used to control compilation and
+installation of the executable', and as such it is considered part of the
+material that must be redistributed.
+
+Keep in mind this is only the Buildroot developers' opinion, and you should
+consult your legal department or lawyer in case of any doubt.