Automatically produce legal compliance info

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

---

?Makefile ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 52 ++++++++++++++++++++++++-
?package/Makefile.package.in ? ? ? ? ? ? ? | ? 59 +++++++++++++++++++++++++++++
?support/legal-info/README.header ? ? ? ? ?| ? 24 ++++++++++++
?support/legal-info/README.warnings-header | ? ?4 ++

?4 files changed, 136 insertions(+), 3 deletions(-) ?create mode 100644 support/legal-info/README.header ?create mode 100644 support/legal-info/README.warnings-header

Makefile +0 -0

index d508888..b78aaf8 100644
@@ -284,6 +284,15 @@ TARGET_DIR:=$(BASE_DIR)/target

?TOOLCHAIN_DIR=$(BASE_DIR)/toolchain
?TARGET_SKELETON=$(TOPDIR)/fs/skeleton

Makefile +3 -0

+LEGAL_REPORT=$(LEGAL_INFO_DIR)/README
+LEGAL_INFO_SEPARATOR="::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::"
+

?ifeq ($(BR2_CCACHE),y)
?CCACHE:=$(HOST_DIR)/usr/bin/ccache
?CCACHE_CACHE_DIR=$(HOME)/.buildroot-ccache

Makefile +4 -0

@@ -362,6 +371,10 @@ HOST_DEPS = $(sort $(foreach dep,\
 ? ? ? ? ? ? ? ?$($(dep))))
 ?HOST_SOURCE += $(addsuffix -source,$(sort $(TARGETS_HOST_DEPS) $(HOST_DEPS)))
 
+TARGETS_LEGAL_INFO:=$(patsubst %,%-legal-info,\
+ ? ? ? ? ? ? ? $(filter-out host-makedevs,\
+ ? ? ? ? ? ? ? $(TARGETS) $(BASE_TARGETS) $(TARGETS_HOST_DEPS) $(HOST_DEPS))))
+

?# all targets depend on the crosscompiler and it's prerequisites ?$(TARGETS_ALL): __real_tgt_%: $(BASE_TARGETS) %

Makefile +0 -0

@@ -395,8 +408,9 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:

? ? ? ?" > $@

?.PHONY: all world dirs clean distclean source outputmakefile \
+ ? ? ? legal-info legal-info-prepare legal-info-clean \
? ? ? ?$(BASE_TARGETS) $(TARGETS) $(TARGETS_ALL) \
- ? ? ? $(TARGETS_CLEAN) $(TARGETS_DIRCLEAN) $(TARGETS_SOURCE) \
+ ? ? ? $(TARGETS_CLEAN) $(TARGETS_DIRCLEAN) $(TARGETS_SOURCE) $(TARGETS_LEGAL_INFO) \
? ? ? ?$(DL_DIR) $(TOOLCHAIN_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
? ? ? ?$(HOST_DIR) $(BINARIES_DIR) $(STAMP_DIR)

Makefile +0 -0

@@ -406,7 +420,7 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:

?# dependencies anywhere else
?#
?#############################################################
-$(DL_DIR) $(TOOLCHAIN_DIR) $(BUILD_DIR) $(HOST_DIR) $(BINARIES_DIR) $(STAMP_DIR):
+$(DL_DIR) $(TOOLCHAIN_DIR) $(BUILD_DIR) $(HOST_DIR) $(BINARIES_DIR) $(STAMP_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR):
? ? ? ?@mkdir -p $@

?$(STAGING_DIR):

Makefile +0 -0

@@ -513,6 +527,37 @@ source: dirs $(TARGETS_SOURCE) $(HOST_SOURCE)

?external-deps:
? ? ? ?@$(MAKE) -Bs DL_MODE=SHOW_EXTERNAL_DEPS $(EXTRAMAKEARGS) source | sort -u

Makefile +6 -0

+legal-info-clean:
+ ? ? ? @rm -fr $(LEGAL_INFO_DIR)
+
+legal-info-prepare: $(LEGAL_INFO_DIR)
+ ? ? ? @echo "package,version,license,license files,source archive" \
+ ? ? ? ? ? ? ? >>$(LEGAL_MANIFEST_CSV)

+ ? ? ? ? ? ? ? >>$(LEGAL_WARNINGS)
+ ? ? ? @echo "WARNING: The toolchain has not be saved" \
+ ? ? ? ? ? ? ? >>$(LEGAL_WARNINGS)
+ ? ? ? @cp $(CONFIG_DIR)/.config $(LEGAL_INFO_DIR)/buildroot.config

Makefile +1 -0

+

?show-targets:
? ? ? ?@echo $(TARGETS)

Makefile +0 -0

@@ -634,7 +679,8 @@ endif
 

?clean:
? ? ? ?rm -rf $(STAGING_DIR) $(TARGET_DIR) $(BINARIES_DIR) $(HOST_DIR) \
- ? ? ? ? ? ? ? $(STAMP_DIR) $(BUILD_DIR) $(TOOLCHAIN_DIR) $(BASE_DIR)/staging
+ ? ? ? ? ? ? ? $(STAMP_DIR) $(BUILD_DIR) $(TOOLCHAIN_DIR) $(BASE_DIR)/staging \
+ ? ? ? ? ? ? ? $(LEGAL_INFO_DIR)

?distclean: clean
?ifeq ($(DL_DIR),$(TOPDIR)/dl)

package/Makefile.package.in +0 -0

index 59adce1..262cc6a 100644
@@ -505,6 +505,8 @@ ifndef $(2)_SOURCE

?endif
?endif

+$(2)_LICENSE ? ? ? ? ? ? ? ? ? ?= unknown
+
?ifndef $(2)_PATCH
?ifdef $(3)_PATCH
? $(2)_PATCH = $($(3)_PATCH)

package/Makefile.package.in +0 -0

@@ -644,6 +646,62 @@ $(1)-rsync: ? ? ? ? ? ? ? ?$$($(2)_TARGET_RSYNC)
 ?$(1)-source: ? ? ? ? ? $$($(2)_TARGET_RSYNC_SOURCE)

?endif

package/Makefile.package.in +56 -0

+# legal-info: produce legally relevant info.
+ifneq ($$($(3)_LICENSE),PROPRIETARY)
+ifneq ($$($(3)_SITE_METHOD),local)
+ifneq ($$($(3)_SITE_METHOD),override)
+# Packages that have a tarball need it downloaded and extracted beforehand
+$(1)-legal-info: ? ? ? $(1)-extract $(REDIST_SOURCES_DIR)
+endif
+endif
+endif
+
+$(1)-legal-info:
+ ? ? ? @echo -n "$$($(3)_NAME),$$($(3)_VERSION),$$($(3)_LICENSE)," \
+ ? ? ? ? ? ? ? >>$(LEGAL_MANIFEST_CSV)
+ifeq ($$($(3)_LICENSE),PROPRIETARY)
+# Proprietary packages: nothing to save
+ ? ? ? @echo "not saved,not saved" >>$(LEGAL_MANIFEST_CSV)
+else ifeq ($$($(3)_SITE_METHOD),local)
+# Packages without a tarball: don't save and warn
+ ? ? ? @echo "not saved,not saved" >>$(LEGAL_MANIFEST_CSV)
+ ? ? ? @echo "WARNING: $$($(3)_NAME): sources and license files not saved" \
+ ? ? ? ? ? ? ? "(local packages not handled)" \
+ ? ? ? ? ? ? ? >>$(LEGAL_WARNINGS)
+else ifeq ($$($(3)_SITE_METHOD),override)
+ ? ? ? @echo "not saved,not saved" >>$(LEGAL_MANIFEST_CSV)
+ ? ? ? @echo "WARNING: ?$$($(3)_NAME): sources and license files not saved" \
+ ? ? ? ? ? ? ? "(override packages not handled)" \
+ ? ? ? ? ? ? ? >>$(LEGAL_WARNINGS)
+else
+# Other packages
+# Save license files if defined
+ifeq ($(call qstrip,$$($(3)_LICENSE_FILES)),)
+ ? ? ? @echo -n "not saved," >>$(LEGAL_MANIFEST_CSV)
+ ? ? ? @echo -e "$(LEGAL_INFO_SEPARATOR)\n\t $$($(3)_NAME):" \
+ ? ? ? ? ? ? ? "unknown license file(s)\n$(LEGAL_INFO_SEPARATOR)\n\n" \
+ ? ? ? ? ? ? ? ? ? ? ? >>$(LEGAL_LICENSES_TXT)
+ ? ? ? @echo "WARNING: $$($(3)_NAME): cannot save license" \
+ ? ? ? ? ? ? ? "($(3)_LICENSE_FILES not defined)" >>$(LEGAL_WARNINGS)
+else
+ ? ? ? @mkdir -p $(LICENSE_FILES_DIR)/$$($(3)_NAME)/
+ ? ? ? @cp $(addprefix $$($(2)_DIR)/,$$($(3)_LICENSE_FILES)) \
+ ? ? ? ? ? ? ? $(LICENSE_FILES_DIR)/$$($(3)_NAME)/
+ ? ? ? @echo -n "$$($(3)_LICENSE_FILES)," >>$(LEGAL_MANIFEST_CSV)
+ ? ? ? @for F in $$($(3)_LICENSE_FILES); do \
+ ? ? ? ? ? ? ? echo -e "$(LEGAL_INFO_SEPARATOR)\n\t $$($(3)_NAME):" \
+ ? ? ? ? ? ? ? ? ? ? ? "$$$${F} file\n$(LEGAL_INFO_SEPARATOR)\n" \
+ ? ? ? ? ? ? ? ? ? ? ? >>$(LEGAL_LICENSES_TXT); \
+ ? ? ? ? ? ? ? cat $$($(2)_DIR)/$$$${F} >>$(LEGAL_LICENSES_TXT); \
+ ? ? ? ? ? ? ? echo >>$(LEGAL_LICENSES_TXT); \
+ ? ? ? ? ? ? ? done
+endif
+# Copy the source tarball (just hardlink if possible)
+ ? ? ? @cp -l $(DL_DIR)/$$($(3)_SOURCE) $(REDIST_SOURCES_DIR) 2>/dev/null || \
+ ? ? ? ? ?cp $(DL_DIR)/$$($(3)_SOURCE) $(REDIST_SOURCES_DIR)
+ ? ? ? @echo "$$($(3)_SOURCE)" >>$(LEGAL_MANIFEST_CSV)
+endif
+

?$(1)-show-depends:
? ? ? ? ? ? ? ? ? ? ? ?@echo $$($(2)_DEPENDENCIES)

package/Makefile.package.in +1 -0

@@ -687,6 +745,7 @@ $$($(2)_TARGET_PATCH): ? ? ? ? ? ? ? ? ? ? ?PKG=$(2)
 ?$$($(2)_TARGET_PATCH): ? ? ? ? ? ? ? ? RAWNAME=$(patsubst host-%,%,$(1))
 ?$$($(2)_TARGET_EXTRACT): ? ? ? ? ? ? ? PKG=$(2)
 ?$$($(2)_TARGET_SOURCE): ? ? ? ? ? ? ? ? ? ? ? ?PKG=$(2)
+$$($(2)_TARGET_LEGAL_INFO): ? ? ? ? ? ?PKG=$(2)
 ?$$($(2)_TARGET_UNINSTALL): ? ? ? ? ? ? PKG=$(2)
 ?$$($(2)_TARGET_CLEAN): ? ? ? ? ? ? ? ? PKG=$(2)
 ?$$($(2)_TARGET_DIRCLEAN): ? ? ? ? ? ? ?PKG=$(2)

support/legal-info/README.header new file +24 -0

new file mode 100644
index 0000000..156ef7e
@@ -0,0 +1,24 @@
+Most of the packages that were used by Buildroot to produce the image files,
+including Buildroot itself, have open-source licenses. It is your
+responsibility to comply to the requirements of these licenses.
+To make this easier for you, Buildroot collected in this directory some
+material you may need to get it done.
+
+This material is composed of the following items.
+ * The scripts used to control compilation of the packages and the generation
+ ? of image files, i.e. the Buildroot sources.
+ ? Note: this has not be saved due to technical limitations, you must collect
+ ? it manually.
+ * The Buildroot configuration file; this has been saved in buildroot.config.
+ * The toolchain (cross-compiler and related tools) used to generate all the
+ ? compiled programs.
+ ? Note: this has not be saved due to technical limitations, you must collect
+ ? it manually.
+ * The source code for all packages; this has been saved in the sources/
+ ? subdirectory (except for the proprietary packages, which have not been
+ ? saved); patches applied to some packages by Buildroot are included in the
+ ? Buildroot sources and were not duplicated in the sources/ subdirectory.
+ * A manifest file listing the configured packages and related information;
+ * The license text of the packages; they have been saved in the licenses/
+ ? subdirectory.
+

support/legal-info/README.warnings-header new file +4 -1

new file mode 100644
index 0000000..cd08290
@@ -0,0 +1,4 @@
+Due to technical limitations or lack of license definition in the package
+makefile, some of the material listed above could not been saved, as the
+following list details.
+
--

1.7.5.4

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 18 lines · Luca Ceresoli

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

---
  Makefile                                  |   52 ++++++++++++++++++++++++-
  package/Makefile.package.in               |   59 +++++++++++++++++++++++++++++
  support/legal-info/README.header          |   24 ++++++++++++
  support/legal-info/README.warnings-header |    4 ++
  4 files changed, 136 insertions(+), 3 deletions(-)

create mode 100644 support/legal-info/README.header create mode 100644 support/legal-info/README.warnings-header

Makefile +0 -0

index d508888..b78aaf8 100644
@@ -284,6 +284,15 @@ TARGET_DIR:=$(BASE_DIR)/target
  TOOLCHAIN_DIR=$(BASE_DIR)/toolchain
  TARGET_SKELETON=$(TOPDIR)/fs/skeleton
 

Makefile TARGET_DIR:=$(BASE_DIR)/target · line 292

Quoted 6 lines

Makefile +6 -0

+LEGAL_INFO_DIR=$(BASE_DIR)/legal-info
+REDIST_SOURCES_DIR=$(LEGAL_INFO_DIR)/sources
+LICENSE_FILES_DIR=$(LEGAL_INFO_DIR)/licenses
+LEGAL_MANIFEST_CSV=$(LEGAL_INFO_DIR)/manifest.csv
+LEGAL_LICENSES_TXT=$(LEGAL_INFO_DIR)/licenses.txt
+LEGAL_WARNINGS=$(LEGAL_INFO_DIR)/.warnings

I'm not sure if this should be a hidden file, as it is quite important for a user to really see this.

Quoted 51 lines

Makefile +20 -2

+LEGAL_REPORT=$(LEGAL_INFO_DIR)/README
+LEGAL_INFO_SEPARATOR="::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::"
+
  ifeq ($(BR2_CCACHE),y)
  CCACHE:=$(HOST_DIR)/usr/bin/ccache
  CCACHE_CACHE_DIR=$(HOME)/.buildroot-ccache

@@ -362,6 +371,10 @@ HOST_DEPS = $(sort $(foreach dep,\
                $($(dep))))
  HOST_SOURCE += $(addsuffix -source,$(sort $(TARGETS_HOST_DEPS) $(HOST_DEPS)))
 
+TARGETS_LEGAL_INFO:=$(patsubst %,%-legal-info,\
+               $(filter-out host-makedevs,\
+               $(TARGETS) $(BASE_TARGETS) $(TARGETS_HOST_DEPS) $(HOST_DEPS))))
+
  # all targets depend on the crosscompiler and it's prerequisites
  $(TARGETS_ALL): __real_tgt_%: $(BASE_TARGETS) %
 

@@ -395,8 +408,9 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:
        ">  $@
 
  .PHONY: all world dirs clean distclean source outputmakefile \
+       legal-info legal-info-prepare legal-info-clean \
        $(BASE_TARGETS) $(TARGETS) $(TARGETS_ALL) \
-       $(TARGETS_CLEAN) $(TARGETS_DIRCLEAN) $(TARGETS_SOURCE) \
+       $(TARGETS_CLEAN) $(TARGETS_DIRCLEAN) $(TARGETS_SOURCE) $(TARGETS_LEGAL_INFO) \
        $(DL_DIR) $(TOOLCHAIN_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
        $(HOST_DIR) $(BINARIES_DIR) $(STAMP_DIR)
 

@@ -406,7 +420,7 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake:
  # dependencies anywhere else
  #
  #############################################################
-$(DL_DIR) $(TOOLCHAIN_DIR) $(BUILD_DIR) $(HOST_DIR) $(BINARIES_DIR) $(STAMP_DIR):
+$(DL_DIR) $(TOOLCHAIN_DIR) $(BUILD_DIR) $(HOST_DIR) $(BINARIES_DIR) $(STAMP_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR):
        @mkdir -p $@
 
  $(STAGING_DIR):

@@ -513,6 +527,37 @@ source: dirs $(TARGETS_SOURCE) $(HOST_SOURCE)
  external-deps:
        @$(MAKE) -Bs DL_MODE=SHOW_EXTERNAL_DEPS $(EXTRAMAKEARGS) source | sort -u
 
+legal-info-clean:
+       @rm -fr $(LEGAL_INFO_DIR)
+
+legal-info-prepare: $(LEGAL_INFO_DIR)
+       @echo "package,version,license,license files,source archive" \
+>>$(LEGAL_MANIFEST_CSV)
+       @mkdir -p $(LICENSE_FILES_DIR)/buildroot
+       @cp COPYING $(LICENSE_FILES_DIR)/buildroot/COPYING
+       @echo -e "$(LEGAL_INFO_SEPARATOR)\n\t buildroot:" \
+               "COPYING file\n$(LEGAL_INFO_SEPARATOR)\n\n" \

Makefile source: dirs $(TARGETS_SOURCE) $(HOST_SOURCE) · line 545

Quoted 6 lines

Makefile +6 -0

+>>$(LEGAL_LICENSES_TXT)
+       @cat COPYING>>$(LEGAL_LICENSES_TXT)
+       @echo>>$(LEGAL_LICENSES_TXT)
+       @echo "buildroot,$(BR2_VERSION_FULL),GPLv2,COPYING,not saved" \
+>>$(LEGAL_MANIFEST_CSV)
+       @echo "WARNING: The Buildroot source code has not be saved" \

s/be/been
This should be fixed in a few places in the patchset.

Quoted 5 lines

Makefile +5 -0

+>>$(LEGAL_WARNINGS)
+       @echo "WARNING: The toolchain has not be saved" \
+>>$(LEGAL_WARNINGS)
+       @cp $(CONFIG_DIR)/.config $(LEGAL_INFO_DIR)/buildroot.config
+

Makefile source: dirs $(TARGETS_SOURCE) $(HOST_SOURCE) · line 560

Quoted 10 lines

Makefile +10 -0

+legal-info: legal-info-clean legal-info-prepare $(REDIST_SOURCES_DIR) \
+               $(TARGETS_LEGAL_INFO)
+       @cat support/legal-info/README.header>>$(LEGAL_REPORT)
+       @if [ -r $(LEGAL_WARNINGS) ]; then \
+               cat support/legal-info/README.warnings-header \
+                       $(LEGAL_WARNINGS)>>$(LEGAL_REPORT); \
+               cat $(LEGAL_WARNINGS); fi
+       @echo "Legal info produced in $(LEGAL_INFO_DIR)"
+       @rm -f $(LEGAL_WARNINGS)
+

I think the readability of this can be improved by creating a set of functions to produce a warning, to add a line to the csv, etc. Moreover, the details about the format of these files will be grouped in one place.
For example (untested):

define legal-add-warning # (pkg, warning)
@echo "WARNING: $(1): $(warning)">>$(LEGAL_WARNINGS)
endef
define legal-add-csv-line # (pkg, version, license, license file, source file) @echo "$(1),$(2),$(3),$(4),$(5)">>$(LEGAL_MANIFEST_CSV)
endef
Example calls would be:
$(call legal-add-warning,buildroot,source code has not been saved) $(call legal-add-csv-line,$$($(3)_NAME),$$($(3)_VERSION),$$($(3)_LICENSE),not saved,not saved)

These functions can be used in Makefile, in Makefile.package.in below, and even for packages that do not follow gentargets but still want to hook into the legal infrastructure.

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

---
 linux/linux.mk |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

linux/linux.mk +0 -0

index ae236d4..e6f2388 100644

Lucas, All,

Quoted 10 lines · On Wednesday 07 March 2012 21:58:16 Luca Ceresoli wrote:

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

---
  linux/linux.mk |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

linux/linux.mk +0 -0

index ae236d4..e6f2388 100644

linux/linux.mk line 7

Quoted 4 lines

linux/linux.mk +1 -0

@@ -4,6 +4,8 @@
  #
  ###############################################################################
  LINUX_VERSION=$(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
+LINUX_LICENSE = GPLv2-ONLY

What's the point of giving the version 'v2' and stating 'only'? I would rather see:
values meaning
-------------------------------

   GPLv2         GPLv2 only
   GPLv2+        GPLv2 or later
   LGPLv2.1      LGPLv2.1 only
   LGPLv2.1+     LGPLv2.1 or later
   ...           ...

Quoted 17 lines · Yann E. MORIN

Lucas, All,

Quoted 13 lines · On Wednesday 07 March 2012 21:58:16 Luca Ceresoli wrote:

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

---
?linux/linux.mk | ? ?2 ++
?1 files changed, 2 insertions(+), 0 deletions(-)

linux/linux.mk +0 -0

index ae236d4..e6f2388 100644
@@ -4,6 +4,8 @@

?#

Quoted 13 lines

Quoted 3 lines

?############################################################################### ?LINUX_VERSION=$(call qstrip,$(BR2_LINUX_KERNEL_VERSION)) +LINUX_LICENSE = GPLv2-ONLY

What's the point of giving the version 'v2' and stating 'only'? I would rather see:
? values ? ? ? ?meaning
? -------------------------------
? GPLv2 ? ? ? ? GPLv2 only
? GPLv2+ ? ? ? ?GPLv2 or later
? LGPLv2.1 ? ? ?LGPLv2.1 only
? LGPLv2.1+ ? ? LGPLv2.1 or later
? ... ? ? ? ? ? ...

When a project is GPL-licensed, it usually means it uses "either version X of
the License, or (at your option) any later version". There are rare cases (Linux, Busybox, any other?) chose to use a specific version, no later version.

So the "default" meaning of "GPLvX" is "GPL version X or later". Those rare cases that allow no upgrade are distinguished by adding "only".

This applies for example to:
- http://en.wikipedia.org/wiki/Linux_kernel
- http://en.wikipedia.org/wiki/Directfb
- http://en.wikipedia.org/wiki/Lzop

I prefer to do the same, and use a concise definition for the most frequent case. Of course this is a personal preference.

If we wanted to stay on the extra-safe side, we might use:
?values ? ? ? ? meaning ?-------------------------------
?GPLv2-ONLY ? ? GPLv2 only
?GPLv2+ ? ? ? ? GPLv2 or later
?LGPLv2.1-ONLY ?LGPLv2.1 only

?LGPLv2.1+ ? ? ?LGPLv2.1 or later
?... ? ? ? ? ? ?...
so there is no ambiguity whatsoever. Might that "+" sign create doubts in dummies reading it ("Hey, what's GPLv2+? a super-GPLv2?")?

Your opinions?

Luca

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 28 lines · Luca Ceresoli

Quoted 22 lines · Yann E. MORIN

Lucas, All,

Quoted 10 lines · On Wednesday 07 March 2012 21:58:16 Luca Ceresoli wrote:

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

---
  linux/linux.mk |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

linux/linux.mk +0 -0

index ae236d4..e6f2388 100644

linux/linux.mk line 8

Quoted 5 lines

linux/linux.mk +1 -0

@@ -4,6 +4,8 @@
  #
 
  ###############################################################################
  LINUX_VERSION=$(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
+LINUX_LICENSE = GPLv2-ONLY

What's the point of giving the version 'v2' and stating 'only'? I would rather see:
values meaning
-------------------------------

Quoted 5 lines

   GPLv2         GPLv2 only
   GPLv2+        GPLv2 or later
   LGPLv2.1      LGPLv2.1 only
   LGPLv2.1+     LGPLv2.1 or later
   ...           ...

Quoted 8 lines

When a project is GPL-licensed, it usually means it uses "either version X of
the License, or (at your option) any later version". There are rare cases (Linux, Busybox, any other?) chose to use a specific version, no later version.

So the "default" meaning of "GPLvX" is "GPL version X or later". Those rare cases that allow no upgrade are distinguished by adding "only".

I'm not sure this is correct. According to me, if the license file just specifies GPL version 2, then it really is only version 2. Only if the license file specifies the text 'or any later version, at your option', then it is GPLv2+.

I think the distinction GPLv2 / GPLv2+ / GPLv3 / GPLv3+ etc. is common, and can be reused.
So I agree with Yann here.

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

* This file is placed under the LGPL. Please see the file
* COPYING for more details.

* This file is placed under the GPL. Please see the file
* COPYING for more details.

* Licensed under GPLv2 or later, see file LICENSE in this source tree.

Quoted 3 lines · Thomas De Schampheleire

I think the distinction GPLv2 / GPLv2+ / GPLv3 / GPLv3+ etc. is common, and can be reused.
So I agree with Yann here.

Ouch, you're right guys. And so I went back to read the original licenses once more...

This is what the GPLv2 states (LGPLv2.0 is substantially equal):

Quoted 7 lines

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

So there are indeed three cases:
1. the Program specifies a version -> GPLv2 only
2. the Program specifies a version or "any later version" -> GPLv2+
3. the Program does not specify a version -> how to name this, simply GPL?

Let's take a real case: tslib.

The source files in src/ state:

Quoted 2 lines

* This file is placed under the LGPL. Please see the file
* COPYING for more details.

and the COPYING file in the root tslib directory contains an LGPL v2.0 license. The Program does not explicitly specify a version, but a specific version is present in COPYING. Is this case 1 or case 3? I think the comment in the source file rules, but it's only a feeling.

OTOH, most source files in tests/ state:

Quoted 2 lines

* This file is placed under the GPL. Please see the file
* COPYING for more details.

and there is no COPYING file carrying any GPL in the whole tslib distribution! So this must be case 3 (and we must assume that GPL means GNU General Public License, although a good lawyer may certainly prove it means any other thing from http://en.wikipedia.org/wiki/GPL_%28disambiguation%29).

This should be taken into account by Buildroot, which builds and installs both the library and the test programs.

Another example: busybox.

This is a messy as well. The LICENSE file carries this heading:

Quoted 7 lines

--- A note on GPL versions

BusyBox is distributed under version 2 of the General Public License (included in its entirety, below). Version 2 is the only version of this license which this version of BusyBox (or modified versions derived from this one) may be distributed under.

Review

Quoted 3 lines

------------------------------------------------------------------------

(quoted diff) +0 -0

 		GNU GENERAL PUBLIC LICENSE
 		Version 2, June 1991

That looks clear, but many source files seem to disagree:

$ head coreutils/uname.c

Quoted 1 line

* Licensed under GPLv2 or later, see file LICENSE in this source tree.

I checked four packages in detail, and two of them have an unclear choice of GPL version. I can't stand any more headache tonight, and I'm not sure I'll have more luck with other packages. This is so frustrating...

And what is import, is not [...]

Luca, Thomas, All,

Quoted 15 lines · On Monday 16 April 2012 23:19:30 Luca Ceresoli wrote:

Quoted 3 lines · Thomas De Schampheleire

I think the distinction GPLv2 / GPLv2+ / GPLv3 / GPLv3+ etc. is common, and can be reused.
So I agree with Yann here.

Ouch, you're right guys. And so I went back to read the original licenses once more...

This is what the GPLv2 states (LGPLv2.0 is substantially equal):

Quoted 7 lines

?Each version is given a distinguishing version number. ?If the Program ?specifies a version number of this License which applies to it and "any ?later version", you have the option of following the terms and conditions ?either of that version or of any later version published by the Free ?Software Foundation. ?If the Program does not specify a version number of ?this License, you may choose any version ever published by the Free Software ?Foundation.

And what is import, is not that the _license text_ says "or later", but if the _Program_ says "or later".

The _Program_ could say that in every boilerplate texts, or in an accompanying file, or by anyother means.

Quoted 4 lines

So there are indeed three cases:
? 1. the Program specifies a version -> ?GPLv2 only
? 2. the Program specifies a version or "any later version" -> ?GPLv2+ ? 3. the Program does not specify a version -> ?how to name this, simply GPL?

Yes, simply GPL. "GPL" by itself means "any version of the GPL", as it is written explicitly in the license text.

Quoted 13 lines

Let's take a real case: tslib.

The source files in src/ state:

Quoted 2 lines

? * This file is placed under the LGPL. ?Please see the file ? * COPYING for more details.

and the COPYING file in the root tslib directory contains an LGPL v2.0 license. The Program does not explicitly specify a version, but a specific version is present in COPYING. Is this case 1 or case 3? I think the comment in the source file rules, but it's only a feeling.

OTOH, most source files in tests/ state:

Quoted 2 lines

? * This file is placed under the GPL. ?Please see the file ? * COPYING for more details.

Quoted 7 lines

and there is no COPYING file carrying any GPL in the whole tslib distribution! So this must be case 3 (and we must assume that GPL means GNU General Public License, although a good lawyer may certainly prove it means any other thing from http://en.wikipedia.org/wiki/GPL_%28disambiguation%29).

This should be taken into account by Buildroot, which builds and installs both the library and the test programs.

What I would suggest in this case is to not specify any known license, but use a 'generic' text, such as:
?- unknown ? ?license is unknown
?- depends ? ?license depends on the options selected in the Program

In all three cases, only a lawyer may decide what licensing terms apply to such a program. For the tslib specific case, I'd use 'unknown' (which should be the default if no license is explictly specified, anyway).

In this case, the licensing manifest should be carefully analysed, and packages with unknown licenses carefully reviewed with help from a lawyer.

Quoted 10 lines

Another example: busybox.

This is a messy as well. The LICENSE file carries this heading:

Quoted 7 lines

?--- A note on GPL versions

?BusyBox is distributed under version 2 of the General Public License (included ?in its entirety, below). ?Version 2 is the only version of this license which ?this version of BusyBox (or modified versions derived from this one) may be ?distributed under.

Quoted 7 lines

Quoted 3 lines

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

That looks clear, but many source files seem to disagree:

$ head coreutils/uname.c

Quoted 1 line

? * Licensed under GPLv2 or later, see file LICENSE in this source tree.

What this means is that the work as a whole is available under the GPLv2, but that if you use individual files out-side of busybox, you can use that file under the license that is specified (IANAL!).

From the buildroot perspective, busybox is GPLv2.

Quoted 3 lines

I checked four packages in detail, and two of them have an unclear choice of GPL version. I can't stand any more headache tonight, and I'm not sure I'll have more luck with other packages. This is so frustrating...

Not sure? Use 'unknown'. This can be refined at a later stage, if need be.

A package with no license specified in the $(PKG)_LICENSE should default to 'unknown', to draw attention.

IMNSHO, it is highly preferrable for the buildroot community to be conservative on this point, and in case there is ambiguity, default to 'unknown', and let a lawyer do his/her work. ;-)

Quoted 8 lines

Quoted 3 lines

I checked four packages in detail, and two of them have an unclear choice of GPL version. I can't stand any more headache tonight, and I'm not sure I'll have more luck with other packages. This is so frustrating...

Not sure? Use 'unknown'. This can be refined at a later stage, if need be.

A package with no license specified in the $(PKG)_LICENSE should default to 'unknown', to draw attention.

Quoted 3 lines

IMNSHO, it is highly preferrable for the buildroot community to be conservative on this point, and in case there is ambiguity, default to 'unknown', and let a lawyer do his/her work. ;-)

Ideally, we'd try to make sure that the upstream developers clarify their license so as to remove the ambiguity. I think it is of benefit to no-one that such ambiguities exist.

Quoted 13 lines

Another example: busybox.

This is a messy as well. The LICENSE file carries this heading:

Quoted 10 lines

--- A note on GPL versions

BusyBox is distributed under version 2 of the General Public License (included in its entirety, below). Version 2 is the only version of this license which this version of BusyBox (or modified versions derived from this one) may be distributed under.

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

Quoted 3 lines

That looks clear, but many source files seem to disagree:

$ head coreutils/uname.c

Quoted 1 line

* Licensed under GPLv2 or later, see file LICENSE in this source tree.

What this means is that the work as a whole is available under the GPLv2, but that if you use individual files out-side of busybox, you can use that file under the license that is specified (IANAL!).

From the buildroot perspective, busybox is GPLv2.

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

---
 package/bzip2/bzip2.mk |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

package/bzip2/bzip2.mk +0 -0

index 1bc4449..028c2f2 100644

Quoted 10 lines · On Wednesday 07 March 2012 21:58:19 Luca Ceresoli wrote:

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

---
  package/bzip2/bzip2.mk |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

package/bzip2/bzip2.mk +0 -0

index 1bc4449..028c2f2 100644

package/bzip2/bzip2.mk BZIP2_VERSION:=1.0.5 · line 10

Quoted 4 lines

package/bzip2/bzip2.mk +1 -0

@@ -7,6 +7,8 @@ BZIP2_VERSION:=1.0.5
  BZIP2_SONAME=1.0.4
  BZIP2_SOURCE:=bzip2-$(BZIP2_VERSION).tar.gz
  BZIP2_SITE:=http://www.bzip.org/$(BZIP2_VERSION)
+BZIP2_LICENSE = BSD-like

I think it makes sense to have:

value meaning
-------------------------------

   BSD-4c        Original BSD 4-clause
   BSD           Alias for the above
   BSD-3c        BSD 3-clause
   BSD-2c        BSD 2-clause

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

---
 package/qt/Config.in |   15 +++++++++++++++
 package/qt/qt.mk     |    9 +++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)

package/qt/Config.in +15 -0

index 3a552d0..b430258 100644
@@ -55,6 +55,21 @@ config BR2_PACKAGE_QT_LICENSE_APPROVED
 	  LGPL v2.1: http://doc.trolltech.com/4.5/lgpl.html
 	  GPL  v3.0: http://doc.trolltech.com/4.5/gpl.html
 
+if BR2_PACKAGE_QT_LICENSE_APPROVED
+
+choice
+	prompt "License"
+
+config BR2_PACKAGE_QT_LICENSE_LGPL
+	bool "LGPL v2.1"
+
+config BR2_PACKAGE_QT_LICENSE_GPL
+	bool "GPL v3.0"
+
+endchoice
+
+endif # BR2_PACKAGE_QT_LICENSE_APPROVED
+
 config BR2_PACKAGE_QT_CONFIG_FILE
 	string "Config file"
 	help

package/qt/qt.mk +0 -0

index 776eb63..e8bc3a2 100644
@@ -20,6 +20,15 @@ QT_INSTALL_STAGING = YES
 
 ifeq ($(BR2_PACKAGE_QT_LICENSE_APPROVED),y)

This second RFC incorporates many of the additions and modifications that have been discussed, as well as many other improvements. Thanks Arnout, ThomasDS and others for their review, and the BDD participants for their suggestions.

  $ find legal-info/ -type f
  legal-info/README            # Lists saved stuff, warns about unsaved
  stuff legal-info/licenses.txt      # Text of all licenses
  legal-info/buildroot.config  # The buildroot config

  legal-info/licenses/buildroot/COPYING       # License files, one dir per
  pkg legal-info/licenses/busybox/LICENSE         # ...
  legal-info/licenses/...other packages...    # ...
  legal-info/manifest.csv                     # CSV table summarizing all
  info legal-info/sources/busybox-1.19.4.tar.bz2   # tarballs
  legal-info/sources/kmod-5.tar.xz            # ...
  legal-info/sources/libtool-2.2.10.tar.gz    # ...
  legal-info/sources/...other packages...     # ...

ISSUE 2: Packages with multiple licenses
========================================

Some packages (e.g. freetype, qt) allow to choose among different licenses.
- Should we add an option in menuconfig for choosing the license? This would allow to generate "customized" manifest and license files.
- Or should we save all licenses and and define the package license as, for instance:
QT_LICENSE = GPLv3 or LGPLv2.1 or COMMERCIAL?

ISSUE 3: packages without a license file
========================================

Some packages (e.g. tslib) do not have a license file. Instead, the license is written in a comment at the top of one or more source files. In such cases we planned that the package maintainer would manually copy this text into a file in the package directory (where the .mk lives) and the teach the infrastructure where it is, so it gets copied from there.

I haven't started working on an implementation of this feature yet, but at first sight it's not totally trivial. The problem is the <PKG>_LICENSE_FILES definition as it is implemented in the present RFC does not easily allow to discriminate between a file in $(O)/build/<pkg>-<ver>/ and a file in packages/<pkg>/.

This is how it works now:

        @cp $(addprefix $$($(2)_DIR)/,$$($(3)_LICENSE_FILES)) \
                $(LICENSE_FILES_DIR)/$$($(3)_NAME)/

It assumes the files are in the package build dir, $(2)_DIR, which allows a very simple and clean implementation.

In order to support a copy from the package directory, option 1 is to define the full path in <PKG>_LICENSE_FILES, and remove the addprefix from the above code snipped. Example:
FOO_LICENSE_FILES = $(BUILD_DIR)/foo-$(FOO_VERSION)/COPYING BAR_LICENSE_FILES = packages/bar/COPYING
which is not very pleasant to read, and is quite error-prone for the developer adding a package.

Option 2 would be to have two distinct constants for the two cases:
FOO_LICENSE_FILES_IN_BUILD_DIR = COPYING BAR_LICENSE_FILES_IN_PACKAGE_DIR = COPYING
Even with better constant names this would not be extremely beautiful IMHO.

Option 3 is to wait for a smarter idea coming from your reviews! :)

TODO in the next patchset before merging into mainline
======================================================

- Add to the documentation:
- some words of advice from Buildroot developers about how to comply to GPL

    and other open source licenses;

- brief instructions on using this stuff ('make legal-info');
- instructions in the GENTARGETS section about the _LICENSE and _LICENSE_FILES constants.

- Write a few lines of explanation in the log message of the first big commit, the one that implements all the logic.

- Save a defconfig instead of the whole .config for the Buildroot configuration? Which one would you better like?

Lucas, All,

   $ find legal-info/ -type f
   legal-info/README            # Lists saved stuff, warns about unsaved
   stuff legal-info/licenses.txt      # Text of all licenses
   legal-info/buildroot.config  # The buildroot config
   legal-info/licenses/buildroot/COPYING       # License files, one dir per
   pkg legal-info/licenses/busybox/LICENSE         # ...
   legal-info/licenses/...other packages...    # ...
   legal-info/manifest.csv                     # CSV table summarizing all
   info legal-info/sources/busybox-1.19.4.tar.bz2   # tarballs
   legal-info/sources/kmod-5.tar.xz            # ...

   legal-info/sources/libtool-2.2.10.tar.gz    # ...
   legal-info/sources/...other packages...     # ...
I would expect a one-directory-pre-package layout (personal opinion):
   legal-info/busybox/LICENSE
   legal-info/busybox/busybox-1.19.4.tar.bz2
   legal-info/kmod/COPYING
   legal-info/kmod/kmod-5.tar.bz2
   ...

[--SNIP--]

Quoted 9 lines

ISSUE 2: Packages with multiple licenses
========================================

Some packages (e.g. freetype, qt) allow to choose among different licenses.
- Should we add an option in menuconfig for choosing the license? This would allow to generate "customized" manifest and license files.
- Or should we save all licenses and and define the package license as, for instance:
QT_LICENSE = GPLv3 or LGPLv2.1 or COMMERCIAL?

It would probably be possible to do:

     QT_LICENSE = GPLv3
     ifeq ($(blabla),y)
     QT_LICENSE += LGPLv2.1
     endif

and so on...

Quoted 34 lines

ISSUE 3: packages without a license file
========================================

Some packages (e.g. tslib) do not have a license file. Instead, the license is written in a comment at the top of one or more source files. In such cases we planned that the package maintainer would manually copy this text into a file in the package directory (where the .mk lives) and the teach the infrastructure where it is, so it gets copied from there.

I haven't started working on an implementation of this feature yet, but at first sight it's not totally trivial. The problem is the<PKG>_LICENSE_FILES definition as it is implemented in the present RFC does not easily allow to discriminate between a file in $(O)/build/<pkg>-<ver>/ and a file in packages/<pkg>/.

This is how it works now:

         @cp $(addprefix $$($(2)_DIR)/,$$($(3)_LICENSE_FILES)) \
                 $(LICENSE_FILES_DIR)/$$($(3)_NAME)/

It assumes the files are in the package build dir, $(2)_DIR, which allows a very simple and clean implementation.

In order to support a copy from the package directory, option 1 is to define the full path in<PKG>_LICENSE_FILES, and remove the addprefix from the above code snipped. Example:
FOO_LICENSE_FILES = $(BUILD_DIR)/foo-$(FOO_VERSION)/COPYING BAR_LICENSE_FILES = packages/bar/COPYING
which is not very pleasant to read, and is quite error-prone for the developer adding a package.

Option 2 would be to have two distinct constants for the two cases:
FOO_LICENSE_FILES_IN_BUILD_DIR = COPYING BAR_LICENSE_FILES_IN_PACKAGE_DIR = COPYING
Even with better constant names this would not be extremely beautiful IMHO.

Quoted 1 line

Option 3 is to wait for a smarter idea coming from your reviews! :)

Proposal:
- FOO_LICENSE_FILES = list of license files
- FOO_LICENSE_HOOK = macros to call to copy the license files

Quoted 13 lines

TODO in the next patchset before merging into mainline
======================================================

- Add to the documentation:
- some words of advice from Buildroot developers about how to comply to GPL

     and other open source licenses;

- brief instructions on using this stuff ('make legal-info');
- instructions in the GENTARGETS section about the _LICENSE and _LICENSE_FILES constants.

- Write a few lines of explanation in the log message of the first big commit, the one that implements all the logic.

Quoted 2 lines

- Save a defconfig instead of the whole .config for the Buildroot configuration? Which one would you better like?

A full .config, from experiemce...

And what about the linux, uClibc and busybox .config files? Unless I missed something in your email, you did not address these...

Quoted 6 lines · Yann E. MORIN

I would expect a one-directory-pre-package layout (personal opinion):

   legal-info/busybox/LICENSE
   legal-info/busybox/busybox-1.19.4.tar.bz2
   legal-info/kmod/COPYING
   legal-info/kmod/kmod-5.tar.bz2
   ...

I thought about the usage I would make of this material. The tarballs must go into some CD or website or similar. The licenses may be sent to documentation writers so they can typeset them in a document (if for some reason they do not want to use the produced licenses.txt file).

Quoted 10 lines

[--SNIP--]

Quoted 9 lines

ISSUE 2: Packages with multiple licenses
========================================

Some packages (e.g. freetype, qt) allow to choose among different licenses.
- Should we add an option in menuconfig for choosing the license? This would allow to generate "customized" manifest and license files.
- Or should we save all licenses and and define the package license as, for instance:
QT_LICENSE = GPLv3 or LGPLv2.1 or COMMERCIAL?

Quoted 7 lines

It would probably be possible to do:

     QT_LICENSE = GPLv3
     ifeq ($(blabla),y)
     QT_LICENSE += LGPLv2.1
     endif

and so on...

Well, Qt allows to choose the license you want. So you can use all of it under the GPLv3, or all of it under LGPLv2.1, or all of it purchasing a commercial license.

The same applies to FreeType: "FreeType comes with two licenses from which you can choose the one which fits your needs best."
(http://freetype.org/license.html).

In such cases, for what concerns Buildroot, I think we should either that the package in Buildroot is always used with a given license (e.g. LGPLv2.1 for Qt) or allow the Buildroot user to choose via menuconfig.

Your code snippet is perfect for a package that has a GPLv3 part that's always compiled and an optional LGPLv2.1 part.

Quoted 1 line

Quoted 1 line

ISSUE 3: packages without a license file

Quoted 5 lines

Quoted 1 line

Option 3 is to wait for a smarter idea coming from your reviews! :)

Proposal:
- FOO_LICENSE_FILES = list of license files
- FOO_LICENSE_HOOK = macros to call to copy the license files

Meaning something like the current POST_{CONFIGURE|INSTALL_TARGET|...}_HOOKS? Good idea, concise and readable. But we should also provide a macro (or a script) to copy the license files, such as:

   $(call COPY_LICENSE_FILES,pkgname,pkgver,license_file(s))

that copies to $(O)/legal-info/pkgname-pkgver, cats into licenses.txt and fills manifest.csv.

Yann,
thanks for the review.

Quoted 2 lines · Yann E. MORIN

Lucas, All,

s/Lucas/Luca/ :)

Quoted 10 lines

? $ find legal-info/ -type f
? legal-info/README ? ? ? ? ? ?# Lists saved stuff, warns about unsaved ? stuff legal-info/licenses.txt ? ? ?# Text of all licenses
? legal-info/buildroot.config ?# The buildroot config
? legal-info/licenses/buildroot/COPYING ? ? ? # License files, one dir per ? pkg legal-info/licenses/busybox/LICENSE ? ? ? ? # ...
? legal-info/licenses/...other packages... ? ?# ...
? legal-info/manifest.csv ? ? ? ? ? ? ? ? ? ? # CSV table summarizing all ? info legal-info/sources/busybox-1.19.4.tar.bz2 ? # tarballs ? legal-info/sources/kmod-5.tar.xz ? ? ? ? ? ?# ...

Quoted 8 lines

? legal-info/sources/libtool-2.2.10.tar.gz ? ?# ...
? legal-info/sources/...other packages... ? ? # ...
I would expect a one-directory-pre-package layout (personal opinion):
? legal-info/busybox/LICENSE
? legal-info/busybox/busybox-1.19.4.tar.bz2
? legal-info/kmod/COPYING
? legal-info/kmod/kmod-5.tar.bz2
? ...

I thought about the usage I would make of this material. The tarballs must go
into some CD or website or similar. The licenses may be sent to documentation
writers so they can typeset them in a document (if for some reason they do not
want to use the produced licenses.txt file).

Quoted 18 lines

[--SNIP--]

Quoted 4 lines

ISSUE 2: Packages with multiple licenses
========================================

Quoted 9 lines

Some packages (e.g. freetype, qt) allow to choose among different licenses.
- Should we add an option in menuconfig for choosing the license? This would
? allow to generate "customized" manifest and license files.
- Or should we save all licenses and and define the package license as, for
? instance:
? ? QT_LICENSE = GPLv3 or LGPLv2.1 or COMMERCIAL?

Quoted 7 lines

It would probably be possible to do:
? ? QT_LICENSE = GPLv3
? ? ifeq ($(blabla),y)
? ? QT_LICENSE += LGPLv2.1
? ? endif

and so on...

Well, Qt allows to choose the license you want. So you can use all of it under
the GPLv3, or all of it under LGPLv2.1, or all of it purchasing a commercial license.

The same applies to FreeType: "FreeType comes with two licenses from which you
can choose the one which fits your needs best."
(http://freetype.org/license.html).

In such cases, for what concerns Buildroot, I think we should either that the
package in Buildroot is always used with a given license (e.g. LGPLv2.1 for Qt)
or allow the Buildroot user to choose via menuconfig.

Your code snippet is perfect for a package that has a GPLv3 part that's always
compiled and an optional LGPLv2.1 part.

Quoted 46 lines

Quoted 46 lines

ISSUE 3: packages without a license file
========================================

Some packages (e.g. tslib) do not have a license file. Instead, the license is
written in a comment at the top of one or more source files. In such cases we
planned that the package maintainer would manually copy this text into a file
in the package directory (where the .mk lives) and the teach the infrastructure
where it is, so it gets copied from there.

I haven't started working on an implementation of this feature yet, but at
first sight it's not totally trivial. The problem is the<PKG>_LICENSE_FILES
definition as it is implemented in the present RFC does not easily allow to
discriminate between a file in $(O)/build/<pkg>-<ver>/ and a file in packages/<pkg>/.

This is how it works now:
? ? ? ? @cp $(addprefix $$($(2)_DIR)/,$$($(3)_LICENSE_FILES)) \
? ? ? ? ? ? ? ? $(LICENSE_FILES_DIR)/$$($(3)_NAME)/
It assumes the files are in the package build dir, $(2)_DIR, which allows a
very simple and clean implementation.

In order to support a copy from the package directory, option 1 is to define
the full path in<PKG>_LICENSE_FILES, and remove the addprefix from the above
code snipped. Example:
? FOO_LICENSE_FILES = $(BUILD_DIR)/foo-$(FOO_VERSION)/COPYING ? BAR_LICENSE_FILES = packages/bar/COPYING
which is not very pleasant to read, and is quite error-prone for the developer
adding a package.

Option 2 would be to have two distinct constants for the two cases:
? FOO_LICENSE_FILES_IN_BUILD_DIR = COPYING
? BAR_LICENSE_FILES_IN_PACKAGE_DIR = COPYING
Even with better constant names this would not be extremely beautiful IMHO.

Quoted 5 lines

Quoted 1 line

Option 3 is to wait for a smarter idea coming from your reviews! :)

Proposal:
? - FOO_LICENSE_FILES = list of license files
? - FOO_LICENSE_HOOK = macros to call to copy the license files

Meaning something like the current POST_{CONFIGURE|INSTALL_TARGET|...}_HOOKS?
Good idea, concise and readable. But we should also provide a macro (or a script) to copy the license files, such as:

?$(call COPY_LICENSE_FILES,pkgname,pkgver,license_file(s))

that copies to $(O)/legal-info/pkgname-pkgver, cats into licenses.txt and fills manifest.csv.

I'll try to code something like this.

Quoted 20 lines

Quoted 12 lines

TODO in the next patchset before merging into mainline
======================================================

- Add to the documentation:
? - some words of advice from Buildroot developers about how to comply to GPL
? ? and other open source licenses;
? - brief instructions on using this stuff ('make legal-info'); ?- instructions in the GENTARGETS section about the _LICENSE and _LICENSE_FILES
? ?constants.

Quoted 7 lines

- Write a few lines of explanation in the log message of the first big commit,
? the one that implements all the logic.

- Save a defconfig instead of the whole .config for the Buildroot configuration?
? Which one would you better like?

Quoted 5 lines

A full .config, from experiemce...

And what about the linux, uClibc and busybox .config files? Unless I missed
something in your email, you did not address these...

I considered they are part of Buildroot, so they are kind of addressed... by the warning that says you have to tar your Buildroot on your own.

These may be added of course, but then we might ask ourselves if we should also save the post-built script, custom skeleton, additional device table files, whatever else... This would be hard to maintain.

Luca

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 2 lines

And what about the linux, uClibc and busybox .config files? Unless I missed something in your email, you did not address these...

I considered they are part of Buildroot, so they are kind of addressed... by the warning that says you have to tar your Buildroot on your own.

These may be added of course, but then we might ask ourselves if we should also save the post-built script, custom skeleton, additional device table files, whatever else... This would be hard to maintain.

This second RFC incorporates many of the additions and modifications that have been discussed, as well as many other improvements. Thanks Arnout, ThomasDS and others for their review, and the BDD participants for their suggestions.

Lucas, All,

Quoted 3 lines · On Wednesday 07 March 2012 21:58:00 Luca Ceresoli wrote:

This second RFC incorporates many of the additions and modifications that have been discussed, as well as many other improvements. Thanks Arnout, ThomasDS and others for their review, and the BDD participants for their suggestions.

Is there a public git tree we can pull from?

Hi,

during the latest two Buildroot Developers Days (in November 2011 and February 2012) and in this mailing list there has been some discussion about introducing in Buildroot the possibility to automatically derive legally relevant material, such as licensing info and source tarballs for open source packages.

I have submitted a first tentative RFC implementation of these features back in late January
(http://lists.busybox.net/pipermail/buildroot/2012-January/049590.html).

This second RFC incorporates many of the additions and modifications that have been discussed, as well as many other improvements. Thanks Arnout, ThomasDS and others for their review, and the BDD participants for their suggestions.

This code is now fully working, meaning that the core features are there and those things that cannot be handled produce big fat warnings.
I think this code does not need big changes before being merged (unless your review is catastrophic).

However I hit a few issues that still need to be sorted out, see the "ISSUE" sections below.

My approach is based on two per-package constants in eack .mk file, such as:
?FOOBAR_LICENSE = GPLv3 + LGPLv2.1
?FOOBAR_LICENSE_FILES = COPYING.LGPL demo-app/COPYING.GPL3
or:
?MYAPP_LICENSE = PROPRIETARY
?# MYAPP_LICENSE_FILES not relevant in this case
This is the only effort required to the package creator. If <PKG>_LICENSE is not specified it defaults to "unknown".

After running 'make legal-info', the following things will be produced in $(O)/legal-info/:
?$ find legal-info/ -type f
?legal-info/README ? ? ? ? ? ?# Lists saved stuff, warns about unsaved stuff ?legal-info/licenses.txt ? ? ?# Text of all licenses ?legal-info/buildroot.config ?# The buildroot config ?legal-info/licenses/buildroot/COPYING ? ? ? # License files, one dir per pkg ?legal-info/licenses/busybox/LICENSE ? ? ? ? # ... ?legal-info/licenses/...other packages... ? ?# ... ?legal-info/manifest.csv ? ? ? ? ? ? ? ? ? ? # CSV table summarizing all info ?legal-info/sources/busybox-1.19.4.tar.bz2 ? # tarballs ?legal-info/sources/kmod-5.tar.xz ? ? ? ? ? ?# ... ?legal-info/sources/libtool-2.2.10.tar.gz ? ?# ... ?legal-info/sources/...other packages... ? ? # ...

Given the technical difficulties, the toolchain and the BR sources are not saved. Warnings are generated to make sure the user is aware of this.

Following is an explanation of the open issues and future development directions. Actually issue 3 is the one where I mostly would like to have comments, so you may skip to it if your time is limited. Otherwise seat down comfortably and read on.

ISSUE 1: the License Repository Feature
=======================================

The original idea that came out of the last Buildroot Developer Day was to maintain in BR a "license repository" holding those licenses that are used without change by many projects, such as the GPL family. Packages that cannot use this mechanism would need to explicitly define the license file in <PKG>_LICENSE_FILES.

The idea of implementation was:
?if (<PKG>_LICENSE_FILES defined):
? ?copy $(<PKG>_LICENSE_FILES)
?else if (<PKG>_LICENSE = *GPL*, or any other known that's always equal):
? ?copy file from a "license repo dir" (one copy only per file); ?else:
? ?copy nothing and warn user

Unfortunately, as Will Moore also pointed out, I discovered that the same license (e.g. GPLv2) is not always identical between two packages, although the differences might be not substantial.

I do not have precise figures, but the number of variations might be quite large. In a config with ~25 packages enabled I got this:
?$ make external-deps|wc -l
?39
?$ find . -iname "COPYING*" -o -iname "LICENSE*" | \
? ?xargs grep -l 'Version 2,' | xargs md5sum | \
? ?awk '{print $1}'|sort|uniq|wc -l
?20

These are 20 different GPLv2 files! Some only have whitespace changes, some have other little differences. An example:

?$ diff -u0 -b ?./binutils-2.21.1/COPYING ./libtool-2.2.10/COPYING ?--- ./binutils-2.21.1/COPYING 2005-07-14 03:24:56.000000000 +0200 ?+++ ./libtool-2.2.10/COPYING ?2010-05-20 23:18:41.000000000 +0200 ? @@ -4 +4 @@
? - Copyright (C) 1989, 1991 Free Software Foundation, Inc. ? + Copyright (C) 1989, 1991 Free Software Foundation, Inc.,

An added comma.

? @@ -18 +18 @@
? -the GNU Library General Public License instead.) ?You can apply it to ? +the GNU Lesser General Public License instead.) ?You can apply it to

This updates a reference to another license.

?@@ -306,4 +306,3 @@
?- ? ?You should have received a copy of the GNU General Public License ?- ? ?along with this program; if not, write to the Free Software
?- ? ?Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA ?02110-1301 ?USA ?-
?+ ? ?You should have received a copy of the GNU General Public License along ?+ ? ?with this program; if not, write to the Free Software Foundation, Inc., ?+ ? ?51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

Just formatting changes here.

?@@ -339 +338 @@
?-library. ?If this is what you want to do, use the GNU Library General ?+library. ?If this is what you want to do, use the GNU Lesser General

Same as above.

Another example:

?$ diff -u0 -b ?./binutils-2.21.1/COPYING ?./iostat-2.2/LICENSE ?--- ./binutils-2.21.1/COPYING 2005-07-14 03:24:56.000000000 +0200 ?+++ ./iostat-2.2/LICENSE ? ? ?2004-11-25 11:53:11.000000000 +0100 ?@@ -5 +5 @@
?- ? ? 51 Franklin Street, Fifth Floor, Boston, MA ?02110-1301 ?USA ?+ ? ? 59 Temple Place, Suite 330, Boston, MA ?02111-1307 ?USA

Apparently the FSF offices have moved some time in the past.

?@@ -308 +308 @@
?- ? ?Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA ?02110-1301 ?USA ?+ ? ?Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA ?02111-1307 ?USA

Same as above.

I did not investigate a lot to discover if there are more substantial differences. I wanted to stay on the safe side, so I just did not implement the "license repository" and the second step of the algorithm. All packages that want their license files copied must define <PKG>_LICENSE_FILES. Full stop.

The license repository feature may still be added in the future, but I think it should be discussed before. Asking the FSF may be an option, I guess they listen to an active community developing free software.

ISSUE 2: Packages with multiple licenses
========================================

Some packages (e.g. freetype, qt) allow to choose among different licenses.
- Should we add an option in menuconfig for choosing the license? This would ?allow to generate "customized" manifest and license files.
- Or should we save all licenses and and define the package license as, for ?instance:
? ?QT_LICENSE = GPLv3 or LGPLv2.1 or COMMERCIAL?

I think the first option is more nice and still legally correct, so I implemented it for Qt to see how it would look. You can see the implementation in a patch near the bottom of this set. It's not currently documented at all, I'd first like to know if the approach is good or option 2 (or whatever else) is better.

ISSUE 3: packages without a license file
========================================

Some packages (e.g. tslib) do not have a license file. Instead, the license is written in a comment at the top of one or more source files. In such cases we planned that the package maintainer would manually copy this text into a file in the package directory (where the .mk lives) and the teach the infrastructure where it is, so it gets copied from there.

I haven't started working on an implementation of this feature yet, but at first sight it's not totally trivial. The problem is the <PKG>_LICENSE_FILES definition as it is implemented in the present RFC does not easily allow to discriminate between a file in $(O)/build/<pkg>-<ver>/ and a file in packages/<pkg>/.

This is how it works now:
? ? ? ?@cp $(addprefix $$($(2)_DIR)/,$$($(3)_LICENSE_FILES)) \
? ? ? ? ? ? ? ?$(LICENSE_FILES_DIR)/$$($(3)_NAME)/
It assumes the files are in the package build dir, $(2)_DIR, which allows a very simple and clean implementation.

In order to support a copy from the package directory, option 1 is to define the full path in <PKG>_LICENSE_FILES, and remove the addprefix from the above code snipped. Example:
?FOO_LICENSE_FILES = $(BUILD_DIR)/foo-$(FOO_VERSION)/COPYING ?BAR_LICENSE_FILES = packages/bar/COPYING
which is not very pleasant to read, and is quite error-prone for the developer adding a package.

Option 2 would be to have two distinct constants for the two cases:
?FOO_LICENSE_FILES_IN_BUILD_DIR = COPYING ?BAR_LICENSE_FILES_IN_PACKAGE_DIR = COPYING
Even with better constant names this would not be extremely beautiful IMHO.

Option 3 is to wait for a smarter idea coming from your reviews! :)

TODO in the next patchset before merging into mainline
======================================================

- Add to the documentation:
?- some words of advice from Buildroot developers about how to comply to GPL ? ?and other open source licenses;
?- brief instructions on using this stuff ('make legal-info');
?- instructions in the GENTARGETS section about the _LICENSE and _LICENSE_FILES ? constants.

- Write a few lines of explanation in the log message of the first big commit, ?the one that implements all the logic.

- Save a defconfig instead of the whole .config for the Buildroot configuration? ?Which one would you better like?

POSSIBLE FUTURE IMPROVEMENTS
============================

IMHO these should be planned after the merge of the first core functionality:
I would like to keep it as simple as possible for a first step.

- How to handle local and override packages?
?- Modify the -source target (_DOWNLOAD macros) to produce tarball? ? ?But adds a lot of work for normal builds that is used only rarely. ?- Modify the legal-info stuff to re-download them and make a tarball? ?- Assume they are not / almost never used in production and just save ? ?nothing? Meaning just like the present patchset does, generating a warning. ? ?My vote here.

- The toolchain is not currently saved (internal, external, ct-NG, no ?discrimination). Actually, only GENTARGETS-based packages are handled, so the ?best approach might be to "simply" migrate the toolchains to GENTARGETS.

- Save the Buildroot sources too. If the sources are not a git clone this might ?be as simple as tar of the current directory and exclude dl and output, but ?this has never been tested. Also, make sure this works for out-of-tree BR ?builds.

- Add a hook for a post-legal-info script.

SHOW US THE CODE NOW
====================

Ok, the patches are there.
- The implementation is all in the first commit.
- A few patches follow to make non-GENTARGETS packages warn about their ?dumbness.
- Other commits define licenses for some packages.
- A couple of support commits (for testing only) closes the series.

Changed in v2:
- squashed together patches 1-4 from RFC v1; now all the legal-info mechanism ?is implmented in a unique patch.
- rebase on top of current master
- don't clean $(REDIST_SOURCES_DIR): it is a subdir of $(LEGAL_INFO_DIR), so ?doesn't need to be cleaned twice
- added legal-info-clean target
- made legal-info target .PHONY
- remove the output/legal-info dir before populating it
- when saving source tarballs, create hardlinks instead of copies if possible
- add infrastructure to warn the user about info that has not been saved: a ?.warnings file is filled with such info and displayed to the user at the ?end of the legal-info processing
- ensure manual (non-GENTARGETS-based) packages return error, at least; this ?required to explicitly create a -legal-info target for each of them, or ?they would have been silently skipped.
- list also Buildroot in the manifest file! :)
- save the Buildroot .config
- save license files listed in <PKG>_LICENSE_FILES, both in a separate ?directory for each package and all together in a unique file
- various cleanups.

Luca

Luca Ceresoli (31):
?legal-info: infrastructure to collect legally-relevant material ?cups: warn that legal-info is not implemented
?fis: warn that legal-info is not implemented ?doom-wad: warn that legal-info is not implemented ?gettext: warn that legal-info is not implemented ?microperl: warn that legal-info is not implemented ?netkitbase: warn that legal-info is not implemented ?netkittelnet: warn that legal-info is not implemented ?newt: warn that legal-info is not implemented ?tinyhttpd: warn that legal-info is not implemented ?ttcp: warn that legal-info is not implemented ?uemacs: warn that legal-info is not implemented ?vpnc: warn that legal-info is not implemented ?xfsprogs: warn that legal-info is not implemented ?mpc: define license
?linux: define license
?m4: define license
?busybox: define license
?bzip2: define license
?directfb: define license
?iostat: define license
?lzo: define license
?lzop: define license
?tslib: define license
?libusb: define license
?pcre: define license
?netsnmp: define license
?berkeleydb: define license
?qt: define license choice
?foobar: create a fake proprietary package (testing only) ?Create test configs (testing only)

?Makefile ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 52 ++++++++++++++++++++++++-
?configs/legal_info_test2_defconfig ? ? ? ?| ? ?8 ++++
?configs/legal_info_test_defconfig ? ? ? ? | ? 20 ++++++++++
?linux/linux.mk ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +
?package/Config.in ? ? ? ? ? ? ? ? ? ? ? ? | ? ?1 +
?package/Makefile.package.in ? ? ? ? ? ? ? | ? 59 +++++++++++++++++++++++++++++
?package/berkeleydb/berkeleydb.mk ? ? ? ? ?| ? ?2 +
?package/busybox/busybox.mk ? ? ? ? ? ? ? ?| ? ?2 +
?package/bzip2/bzip2.mk ? ? ? ? ? ? ? ? ? ?| ? ?2 +
?package/cups/cups.mk ? ? ? ? ? ? ? ? ? ? ?| ? ?4 ++
?package/directfb/directfb.mk ? ? ? ? ? ? ?| ? ?2 +
?package/fis/fis.mk ? ? ? ? ? ? ? ? ? ? ? ?| ? ?4 ++
?package/foobar/Config.in ? ? ? ? ? ? ? ? ?| ? ?5 ++
?package/foobar/foobar.mk ? ? ? ? ? ? ? ? ?| ? 15 +++++++
?package/foobar/source/foobar.c ? ? ? ? ? ?| ? ?7 +++
?package/games/doom-wad/doom-wads.mk ? ? ? | ? ?4 ++
?package/gettext/gettext.mk ? ? ? ? ? ? ? ?| ? ?4 ++
?package/iostat/iostat.mk ? ? ? ? ? ? ? ? ?| ? ?2 +
?package/libusb/libusb.mk ? ? ? ? ? ? ? ? ?| ? ?2 +
?package/lzo/lzo.mk ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +
?package/lzop/lzop.mk ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +
?package/m4/m4.mk ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +
?package/microperl/microperl.mk ? ? ? ? ? ?| ? ?4 ++
?package/mpc/mpc.mk ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +
?package/netkitbase/netkitbase.mk ? ? ? ? ?| ? ?4 ++
?package/netkittelnet/netkittelnet.mk ? ? ?| ? ?4 ++
?package/netsnmp/netsnmp.mk ? ? ? ? ? ? ? ?| ? ?2 +
?package/newt/newt.mk ? ? ? ? ? ? ? ? ? ? ?| ? ?4 ++
?package/pcre/pcre.mk ? ? ? ? ? ? ? ? ? ? ?| ? ?2 +
?package/qt/Config.in ? ? ? ? ? ? ? ? ? ? ?| ? 15 +++++++
?package/qt/qt.mk ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?9 ++++
?package/tinyhttpd/tinyhttpd.mk ? ? ? ? ? ?| ? ?4 ++
?package/tslib/tslib.mk ? ? ? ? ? ? ? ? ? ?| ? ?2 +
?package/ttcp/ttcp.mk ? ? ? ? ? ? ? ? ? ? ?| ? ?4 ++
?package/uemacs/uemacs.mk ? ? ? ? ? ? ? ? ?| ? ?4 ++
?package/vpnc/vpnc.mk ? ? ? ? ? ? ? ? ? ? ?| ? ?4 ++
?package/xfsprogs/xfsprogs.mk ? ? ? ? ? ? ?| ? ?4 ++
?support/legal-info/README.header ? ? ? ? ?| ? 24 ++++++++++++
?support/legal-info/README.warnings-header | ? ?4 ++

?39 files changed, 296 insertions(+), 3 deletions(-) ?create mode 100644 configs/legal_info_test2_defconfig ?create mode 100644 configs/legal_info_test_defconfig ?create mode 100644 package/foobar/Config.in ?create mode 100644 package/foobar/foobar.mk ?create mode 100644 package/foobar/source/foobar.c ?create mode 100644 support/legal-info/README.header ?create mode 100644 support/legal-info/README.warnings-header

--
1.7.5.4

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 14 lines

However I hit a few issues that still need to be sorted out, see the "ISSUE" sections below.

My approach is based on two per-package constants in eack .mk file, such as:
FOOBAR_LICENSE = GPLv3 + LGPLv2.1
FOOBAR_LICENSE_FILES = COPYING.LGPL demo-app/COPYING.GPL3
or:
MYAPP_LICENSE = PROPRIETARY
# MYAPP_LICENSE_FILES not relevant in this case
This is the only effort required to the package creator. If<PKG>_LICENSE is not specified it defaults to "unknown".

After running 'make legal-info', the following things will be produced in $(O)/legal-info/:

Quoted 12 lines

  $ find legal-info/ -type f
  legal-info/README            # Lists saved stuff, warns about unsaved stuff
  legal-info/licenses.txt      # Text of all licenses
  legal-info/buildroot.config  # The buildroot config
  legal-info/licenses/buildroot/COPYING       # License files, one dir per pkg
  legal-info/licenses/busybox/LICENSE         # ...
  legal-info/licenses/...other packages...    # ...
  legal-info/manifest.csv                     # CSV table summarizing all info
  legal-info/sources/busybox-1.19.4.tar.bz2   # tarballs
  legal-info/sources/kmod-5.tar.xz            # ...
  legal-info/sources/libtool-2.2.10.tar.gz    # ...
  legal-info/sources/...other packages...     # ...

I'm a bit confused by licenses.txt: if we already have each individual license file in the licenses/<package> directory, why do we need an aggregated set in licenses.txt ?

Quoted 91 lines

Given the technical difficulties, the toolchain and the BR sources are not saved. Warnings are generated to make sure the user is aware of this.

Following is an explanation of the open issues and future development directions. Actually issue 3 is the one where I mostly would like to have comments, so you may skip to it if your time is limited. Otherwise seat down comfortably and read on.

ISSUE 1: the License Repository Feature
=======================================

The original idea that came out of the last Buildroot Developer Day was to maintain in BR a "license repository" holding those licenses that are used without change by many projects, such as the GPL family. Packages that cannot use this mechanism would need to explicitly define the license file in<PKG>_LICENSE_FILES.

The idea of implementation was:
if (<PKG>_LICENSE_FILES defined):

    copy $(<PKG>_LICENSE_FILES)
  else if (<PKG>_LICENSE = *GPL*, or any other known that's always equal):
    copy file from a "license repo dir" (one copy only per file);

else:
copy nothing and warn user

Unfortunately, as Will Moore also pointed out, I discovered that the same license (e.g. GPLv2) is not always identical between two packages, although the differences might be not substantial.

I do not have precise figures, but the number of variations might be quite large. In a config with ~25 packages enabled I got this:

  $ make external-deps|wc -l
  39
  $ find . -iname "COPYING*" -o -iname "LICENSE*" | \
    xargs grep -l 'Version 2,' | xargs md5sum | \
    awk '{print $1}'|sort|uniq|wc -l
  20

These are 20 different GPLv2 files! Some only have whitespace changes, some have other little differences. An example:

  $ diff -u0 -b  ./binutils-2.21.1/COPYING ./libtool-2.2.10/COPYING
  --- ./binutils-2.21.1/COPYING 2005-07-14 03:24:56.000000000 +0200
  +++ ./libtool-2.2.10/COPYING  2010-05-20 23:18:41.000000000 +0200
   @@ -4 +4 @@
   - Copyright (C) 1989, 1991 Free Software Foundation, Inc.
   + Copyright (C) 1989, 1991 Free Software Foundation, Inc.,

An added comma.

@@ -18 +18 @@
-the GNU Library General Public License instead.) You can apply it to +the GNU Lesser General Public License instead.) You can apply it to

This updates a reference to another license.

@@ -306,4 +306,3 @@

  -    You should have received a copy of the GNU General Public License
  -    along with this program; if not, write to the Free Software
  -    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
  -
  +    You should have received a copy of the GNU General Public License along
  +    with this program; if not, write to the Free Software Foundation, Inc.,
  +    51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

Just formatting changes here.

@@ -339 +338 @@
-library. If this is what you want to do, use the GNU Library General +library. If this is what you want to do, use the GNU Lesser General

Same as above.

Another example:

  $ diff -u0 -b  ./binutils-2.21.1/COPYING  ./iostat-2.2/LICENSE
  --- ./binutils-2.21.1/COPYING 2005-07-14 03:24:56.000000000 +0200
  +++ ./iostat-2.2/LICENSE      2004-11-25 11:53:11.000000000 +0100
  @@ -5 +5 @@
  -     51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
  +     59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Apparently the FSF offices have moved some time in the past.

@@ -308 +308 @@
- Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Same as above.

Quoted 8 lines

I did not investigate a lot to discover if there are more substantial differences. I wanted to stay on the safe side, so I just did not implement the "license repository" and the second step of the algorithm. All packages that want their license files copied must define<PKG>_LICENSE_FILES. Full stop.

The license repository feature may still be added in the future, but I think it should be discussed before. Asking the FSF may be an option, I guess they listen to an active community developing free software.

For me treating each license as a different one is OK. As you say, it's for sure the safest option. It will keep the logic in buildroot simple.

Quoted 11 lines

ISSUE 2: Packages with multiple licenses
========================================

Some packages (e.g. freetype, qt) allow to choose among different licenses.
- Should we add an option in menuconfig for choosing the license? This would allow to generate "customized" manifest and license files.
- Or should we save all licenses and and define the package license as, for instance:
QT_LICENSE = GPLv3 or LGPLv2.1 or COMMERCIAL?

Quoted 5 lines

I think the first option is more nice and still legally correct, so I implemented it for Qt to see how it would look. You can see the implementation in a patch near the bottom of this set. It's not currently documented at all, I'd first like to know if the approach is good or option 2 (or whatever else) is better.

In any case, a commercial license cannot be used without having a legal agreement with the package author. Since this is a rare case, I don't think we should try to handle this in buildroot. I'd let the user handle this case.

Personally, I don't think that many people will be careful in selecting the appropriate license from the config system. We'd need a default, and the question becomes what's the default? Some people will prefer v3 and others v2.
I'd keep it up to the user to fix the csv and related files to reflect their choice. We can already copy all licenses as you suggest, but I don't know whether a user should remove the non-appropriate files or not to be legally ok...

TODO in the next patchset before merging into mainline
======================================================

- Add to the documentation:
- some words of advice from Buildroot developers about how to comply to GPL

    and other open source licenses;

- brief instructions on using this stuff ('make legal-info');
- instructions in the GENTARGETS section about the _LICENSE and _LICENSE_FILES constants.

- Write a few lines of explanation in the log message of the first big commit, the one that implements all the logic.

- Save a defconfig instead of the whole .config for the Buildroot configuration? Which one would you better like?
A full .config is better I think, as it doesn't depend on the defaults in buildroot (e.g. version bump).