Skip to contentSkip to conversation

Automatically produce legal compliance info

PATCH Superseded Luca Ceresoli 6 participants 37 messages May 17, 2012 – Jul 19, 2012 Kbuild

lore
Share & tools
lore
#0 lore raw

v4 cover Automatically produce legal compliance info

Hi,

here is the third version of the legal-info feature implementation.

Links to discussion of previous versions:
v1: http://lists.busybox.net/pipermail/buildroot/2012-January/049590.html
v2: http://lists.busybox.net/pipermail/buildroot/2012-March/051132.html
v3: http://lists.busybox.net/pipermail/buildroot/2012-May/053574.html

This version is only a minor update to fix various issues reported by other developers. There are not changes to the general structure, so please see the link above for v3 for a detailed presentation.

Let me repeat only my plea to all Buildroot developers to read and give feedback on patch 9.
It gives an advice from Buildroot developers to Buildroot users about how to comply with both Buildroot's and the packages' licenses.
Of course this must match as much as possible what the developers think, so please read it and give either your different views or your ack (preferably with a formal Acked-by tag).

Thanks.

Changelog
=========

The implementation is all in the first commit, which is commented on its own. A few patches follow to make non-GENTARGETS packages warn about their dumbness. A couple of patches add documentation about the legal-info stuff. Other commits define licenses for some packages.

Changed in v4:
- rebased on the current next branch;
- legal-info must depend on dirs (or downloads may fail);
- manual: clarify that legal-info needs a config;
- manual: document PROPRIETARY packages;
- uppercase header in manifest.csv;
- removed useless qstrip;
- don't filter-out host-makedevs from TARGETS_LEGAL_INFO (which is a bad, incomplete and hard to maintain); instead exclude packages with empty _SOURCE (assumed to be part of Buildroot) from being processed in GENTARGETS; this fixes the previously incorrect behaviour for mcookie;
- added message "Collecting legal info";
- s/cannot produce any legal info/legal-info not yet implemented/ for manual packages to be more correct;
- other very minor changes.

Changed in v3:
- moved the $(1)-legal-info target near the end of GENTARGETS_INNER, out of the may of target sequencing where it used to be in the previous patch sets;
- improved readability by creating a set of functions to produce a warning, to add a line to the csv, etc as suggested by ThomasDS (this made the core code shorter and cleaner);
- clarified the BSD-like licenses, differentiating 2/3/4 clauses and others;
- clarified *GPL licenses, and dropped definitions for packages that do not have a clear and simple use of those licenses (tslib, busybox, qt);
- dropped warning patches for tinyhttpd, xfsprogs, microperl, fis, doom-wads, uemacs and cups which have now been converted to GEN/AUTOTARGETS;
- updated after the split of Makefile.package.in in pkg-*.mk and related cleanups;
- added a few lines of explanation in the message of the first big commit that implements all the logic;
- documented the legal-info stuff in the manual;
- added advice about Buildroot license compliance;
- various improvements here and there.

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.

The following changes since commit 56901908c63ed7b2aedffaa4b2143ce87a15d837:

wpa_supplicant: explicitly disable libnl by default (2012-05-16 15:26:48 +0200)

are available in the git repository at:

git at github.com:lucaceresoli/buildroot.git tags/legal-info-v4

for you to fetch changes up to c9343867ce99c8f0cf6cfc40657db295eb7c9552:

berkeleydb: define license (2012-05-17 19:02:19 +0200)

Luca

----------------------------------------------------------------
Luca Ceresoli (22):
legal-info: infrastructure to collect legally-relevant material
gettext: 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
ttcp: warn that legal-info is not implemented
vpnc: warn that legal-info is not implemented
manual: document usage of the legal-info feature
manual: add advice about GPL compliance for Buildroot
linux: define license
m4: define license
mpc: define license
fakeroot: define license
bzip2: define license
directfb: define license
iostat: define license
lzo: define license
lzop: define license
libusb: define license
pcre: define license
netsnmp: define license
berkeleydb: define license

 Makefile                                   |   42 ++++++++-
 docs/manual/adding-packages-gentargets.txt |   21 +++++
 docs/manual/using.txt                      |  130 ++++++++++++++++++++++++++++
 linux/linux.mk                             |    2 +
 package/berkeleydb/berkeleydb.mk           |    2 +
 package/bzip2/bzip2.mk                     |    2 +
 package/directfb/directfb.mk               |    2 +
 package/fakeroot/fakeroot.mk               |    2 +
 package/gettext/gettext.mk                 |    3 +
 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/mpc/mpc.mk                         |    2 +
 package/netkitbase/netkitbase.mk           |    3 +
 package/netkittelnet/netkittelnet.mk       |    3 +
 package/netsnmp/netsnmp.mk                 |    2 +
 package/newt/newt.mk                       |    3 +
 package/pcre/pcre.mk                       |    2 +
 package/pkg-gentargets.mk                  |   61 +++++++++++++
 package/pkg-utils.mk                       |   25 ++++++
 package/ttcp/ttcp.mk                       |    3 +
 package/vpnc/vpnc.mk                       |    3 +
 support/legal-info/README.header           |   24 +++++
 support/legal-info/README.warnings-header  |    4 +
 26 files changed, 348 insertions(+), 3 deletions(-)
 create mode 100644 support/legal-info/README.header
 create mode 100644 support/legal-info/README.warnings-header
Signature · 1 line
1.7.9.5
#1 lore raw

PATCH v4 1/22 legal-info: infrastructure to collect legally-relevant material

This allows to automatically collect material that may be needed to comply with the license of packages that Buildroot prepares for the target device.

The core of the implementation is made by the following parts:
- in package/pkg-utils.mk some helper functions are defined for common actions such as generating a warning, producing info about a package etc;
- in package/pkg-gentargets.mk, within the GENTARGETS framework, a new <PKG>-legal-info target produces all the info for a given package;
- Makefile implements the top-level targets:
- legal-info-prepare creates the output directory and produces legal info about Buildroot itself and the toolchain, which mostly means just warning the user that this is not implemented;
- legal-info, the only target that is supposed to be used directly, depends on all of the above and finishes things by producing the README files from the various pieces.

---
 Makefile                                  |   42 ++++++++++++++++++--
 package/pkg-gentargets.mk                 |   61 +++++++++++++++++++++++++++++
 package/pkg-utils.mk                      |   25 ++++++++++++
 support/legal-info/README.header          |   24 ++++++++++++
 support/legal-info/README.warnings-header |    4 ++
 5 files changed, 153 insertions(+), 3 deletions(-)
 create mode 100644 support/legal-info/README.header
 create mode 100644 support/legal-info/README.warnings-header
Makefile +39 -3
index 96f9412..28af586 100644
@@ -250,6 +250,14 @@ TARGET_DIR:=$(BASE_DIR)/target
 TOOLCHAIN_DIR=$(BASE_DIR)/toolchain
 TARGET_SKELETON=$(TOPDIR)/fs/skeleton
 
+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
+LEGAL_REPORT=$(LEGAL_INFO_DIR)/README
+
 ifeq ($(BR2_CCACHE),y)
 CCACHE:=$(HOST_DIR)/usr/bin/ccache
 CCACHE_CACHE_DIR=$(HOME)/.buildroot-ccache
@@ -330,6 +338,9 @@ HOST_DEPS = $(sort $(foreach dep,\
 		$($(dep))))
 HOST_SOURCE += $(addsuffix -source,$(sort $(TARGETS_HOST_DEPS) $(HOST_DEPS)))
 
+TARGETS_LEGAL_INFO:=$(patsubst %,%-legal-info,\
+		$(TARGETS) $(BASE_TARGETS) $(TARGETS_HOST_DEPS) $(HOST_DEPS))))
+
 # all targets depend on the crosscompiler and it's prerequisites
 $(TARGETS_ALL): __real_tgt_%: $(BASE_TARGETS) %
 
@@ -346,8 +357,9 @@ prepare: $(BUILD_DIR)/buildroot-config/auto.conf
 world: prepare dirs dependencies $(BASE_TARGETS) $(TARGETS_ALL)
 
 .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)
 
@@ -357,7 +369,7 @@ world: prepare dirs dependencies $(BASE_TARGETS) $(TARGETS_ALL)
 # 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):
@@ -484,6 +496,28 @@ 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)
+	@$(call MESSAGE,"Collecting legal info")
+	@$(call legal-license-file,buildroot,COPYING,COPYING)
+	@$(call legal-manifest,PACKAGE,VERSION,LICENSE,LICENSE FILES,SOURCE ARCHIVE)
+	@$(call legal-manifest,buildroot,$(BR2_VERSION_FULL),GPLv2+,COPYING,not saved)
+	@$(call legal-warning,the Buildroot source code has not been saved)
+	@$(call legal-warning,the toolchain has not been saved)
+	@cp $(CONFIG_DIR)/.config $(LEGAL_INFO_DIR)/buildroot.config
+
+legal-info: dirs 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)
+
 show-targets:
 	@echo $(TARGETS)
 
@@ -605,7 +639,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)
@@ -673,6 +708,7 @@ endif
 	@echo '  source                 - download all sources needed for offline-build'
 	@echo '  source-check           - check all packages for valid download URLs'
 	@echo '  external-deps          - list external packages used'
+	@echo '  legal-info             - generate info about license compliance'
 	@echo
 	@echo '  make V=0|1             - 0 => quiet build (default), 1 => verbose build'
 	@echo '  make O=dir             - Locate all output files in "dir", including .config'
package/pkg-gentargets.mk +61 -0

79 lines not on this page · raw message

package/pkg-utils.mk +25 -0
index 953dbc9..43cc76c 100644
@@ -83,3 +83,28 @@ define sep
 
 
 endef
+
+#
+# legal-info helper functions
+#
+LEGAL_INFO_SEPARATOR="::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::"
+legal-warning=echo "WARNING: $(1)" >>$(LEGAL_WARNINGS)
+legal-warning-pkg=echo "WARNING: $(1): $(2)" >>$(LEGAL_WARNINGS)
+define legal-warning-pkg-savednothing # pkg, {local|override}
+	$(call legal-warning-pkg,$(1),sources and license files not saved ($(2) packages not handled))
+endef
+legal-manifest=echo "$(1),$(2),$(3),$(4),$(5)" >>$(LEGAL_MANIFEST_CSV)
+define legal-license-header
+	echo -e "$(LEGAL_INFO_SEPARATOR)\n\t$(1):" \
+		"$(2)\n$(LEGAL_INFO_SEPARATOR)\n\n" >>$(LEGAL_LICENSES_TXT)
+endef
+define legal-license-nofiles
+	$(call legal-license-header,$(1),unknown license file(s))
+endef
+define legal-license-file # pkg, filename, file-fullpath
+	$(call legal-license-header,$(1),$(2) file) && \
+	cat $(3) >>$(LEGAL_LICENSES_TXT) && \
+	echo >>$(LEGAL_LICENSES_TXT) && \
+	mkdir -p $(LICENSE_FILES_DIR)/$(1)/ && \
+	cp $(3) $(LICENSE_FILES_DIR)/$(1)/
+endef
support/legal-info/README.header new file +24 -0
new file mode 100644
index 0000000..3321adb
@@ -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 been 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 been 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 -0
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.
+
Signature · 1 line
1.7.9.5
#2 lore raw

PATCH v4 1/22 legal-info: infrastructure to collect legally-relevant material

Quoted 16 lines · Luca Ceresoli

This allows to automatically collect material that may be needed to comply with the license of packages that Buildroot prepares for the target device.

The core of the implementation is made by the following parts:
- in package/pkg-utils.mk some helper functions are defined for common actions

    such as generating a warning, producing info about a package etc;
  - in package/pkg-gentargets.mk, within the GENTARGETS framework, a new
    <PKG>-legal-info target produces all the info for a given package;

- Makefile implements the top-level targets:
- legal-info-prepare creates the output directory and produces legal info about Buildroot itself and the toolchain, which mostly means just warning the user that this is not implemented;
- legal-info, the only target that is supposed to be used directly, depends on all of the above and finishes things by producing the README files from the various pieces.

Quoted 1 line

Regards,
Arnout

Signature · 6 lines
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#3 lore raw

PATCH v4 2/22 gettext: warn that legal-info is not implemented

In reply to Luca Ceresoli
---
 package/gettext/gettext.mk |    3 +++
 1 file changed, 3 insertions(+)
package/gettext/gettext.mk +3 -0
index f3605da..9778007 100644
@@ -113,6 +113,9 @@ $(STAGING_DIR)/$(GETTEXT_TARGET_BINARY): $(GETTEXT_DIR)/$(GETTEXT_BINARY)
 		autopoint envsubst gettext.sh gettextize msg* ?gettext)
 	touch -c $@
 
+gettext-legal-info:
+	@$(call legal-warning-pkg,gettext,legal-info not yet implemented)
+
 gettext: host-pkg-config $(if $(BR2_PACKAGE_LIBICONV),libiconv) $(STAGING_DIR)/$(GETTEXT_TARGET_BINARY)
 
 gettext-unpacked: $(GETTEXT_DIR)/.unpacked
Signature · 1 line
1.7.9.5
#4 lore raw

PATCH v4 3/22 netkitbase: warn that legal-info is not implemented

In reply to Luca Ceresoli
---
 package/netkitbase/netkitbase.mk |    3 +++
 1 file changed, 3 insertions(+)
package/netkitbase/netkitbase.mk +3 -0
index 83991f2..56480fc 100644
@@ -47,6 +47,9 @@ $(TARGET_DIR)/$(NETKITBASE_TARGET_BINARY): $(NETKITBASE_DIR)/$(NETKITBASE_BINARY
 	fi
 	touch -c $(TARGET_DIR)/$(NETKITBASE_TARGET_BINARY)
 
+netkitbase-legal-info:
+	@$(call legal-warning-pkg,netkitbase,legal-info not yet implemented)
+
 netkitbase: $(TARGET_DIR)/$(NETKITBASE_TARGET_BINARY)
 
 netkitbase-clean:
Signature · 1 line
1.7.9.5
#5 lore raw

PATCH v4 4/22 netkittelnet: warn that legal-info is not implemented

In reply to Luca Ceresoli
---
 package/netkittelnet/netkittelnet.mk |    3 +++
 1 file changed, 3 insertions(+)
package/netkittelnet/netkittelnet.mk +3 -0
index ff05318..43ba324 100644
@@ -48,6 +48,9 @@ $(TARGET_DIR)/$(NETKITTELNET_TARGET_BINARY): $(NETKITTELNET_DIR)/$(NETKITTELNET_
 	#rm -rf $(TARGET_DIR)/share/locale $(TARGET_DIR)/usr/info \
 	# $(TARGET_DIR)/usr/man $(TARGET_DIR)/usr/share/doc
 
+netkittelnet-legal-info:
+	@$(call legal-warning-pkg,netkittelnet,legal-info not yet implemented)
+
 netkittelnet: netkitbase $(TARGET_DIR)/$(NETKITTELNET_TARGET_BINARY)
 
 netkittelnet-clean:
Signature · 1 line
1.7.9.5
#6 lore raw

PATCH v4 5/22 newt: warn that legal-info is not implemented

In reply to Luca Ceresoli
---
 package/newt/newt.mk |    3 +++
 1 file changed, 3 insertions(+)
package/newt/newt.mk +3 -0
index ac450e0..b10e4f8 100644
@@ -58,6 +58,9 @@ $(TARGET_DIR)/usr/lib/libnewt.so.$(NEWT_VERSION): $(STAGING_DIR)/usr/lib/libnewt
 	-$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(TARGET_DIR)/usr/lib/libnewt.so*
 	touch -c $@
 
+newt-legal-info:
+	@$(call legal-warning-pkg,newt,legal-info not yet implemented)
+
 newt: slang $(TARGET_DIR)/usr/lib/libnewt.so.$(NEWT_VERSION)
 
 newt-source: $(DL_DIR)/$(NEWT_SOURCE)
Signature · 1 line
1.7.9.5
#7 lore raw

PATCH v4 6/22 ttcp: warn that legal-info is not implemented

In reply to Luca Ceresoli
---
 package/ttcp/ttcp.mk |    3 +++
 1 file changed, 3 insertions(+)
package/ttcp/ttcp.mk +3 -0
index 1acf120..080286b 100644
@@ -27,6 +27,9 @@ $(TTCP_DIR)/ttcp: $(TTCP_DIR)/.configured
 $(TARGET_DIR)/usr/bin/ttcp: $(TTCP_DIR)/ttcp
 	cp -af $(TTCP_DIR)/ttcp $(TARGET_DIR)/usr/bin/
 
+ttcp-legal-info:
+	@$(call legal-warning-pkg,ttcp,legal-info not yet implemented)
+
 ttcp: $(TARGET_DIR)/usr/bin/ttcp
 
 ttcp-source: $(DL_DIR)/$(TTCP_SOURCE)
Signature · 1 line
1.7.9.5
#8 lore raw

PATCH v4 7/22 vpnc: warn that legal-info is not implemented

In reply to Luca Ceresoli
---
 package/vpnc/vpnc.mk |    3 +++
 1 file changed, 3 insertions(+)
package/vpnc/vpnc.mk +3 -0
index d8d9654..f585dc4 100644
@@ -42,6 +42,9 @@ $(VPNC_TARGET_BINARY): $(VPNC_BINARY)
 		-C $(VPNC_DIR) install
 	$(STRIPCMD) $(STRIP_STRIP_UNNEEDED) $(VPNC_TARGET_BINARY)
 
+vpnc-legal-info:
+	@$(call legal-warning-pkg,vpnc,legal-info not yet implemented)
+
 vpnc: libgcrypt $(VPNC_TARGET_BINARY)
 
 vpnc-source: $(DL_DIR)/$(VPNC_SOURCE)
Signature · 1 line
1.7.9.5
#9 lore raw

PATCH v4 8/22 manual: document usage of the legal-info feature

In reply to Luca Ceresoli
---
 docs/manual/adding-packages-gentargets.txt |   21 ++++++
 docs/manual/using.txt                      |  103 ++++++++++++++++++++++++++++
 2 files changed, 124 insertions(+)
docs/manual/adding-packages-gentargets.txt +21 -0
index cfcee8c..7a7889e 100644
@@ -218,6 +218,27 @@ information is (assuming the package name is +libfoo+) :
   You can find some documentation for this syntax in the xref:makedev-syntax[].
   This variable is optional.
 
+* +LIBFOO_LICENSE+ defines the license (or licenses) under which the package
+  is released.
+  This name will appear in the manifest file produced by +make legal-info+.
+  If the license is one of those listed in xref:legal-info[],
+  use the same string to make the manifest file uniform.
+  Otherwise, describe the license in a precise and concise way, avoiding
+  ambiguous names such as +BSD+ which actually name a family of licenses.
+  If the root filesystem you generate contains non-opensource packages, you
+  can define their license as +PROPRIETARY+: Buildroot will not save any
+  licensing info or source code for this package.
+  This variable is optional. If it is not defined, +unknown+ will appear in
+  the +license+ field of the manifest file for this package.
+
+* +LIBFOO_LICENSE_FILES+ is a space-separated list of files in the package
+  tarball that contain the license(s) under which the package is released.
+  +make legal-info+ copies all of these files in the +legal-info+ directory.
+  See xref:legal-info[] for more information.
+  This variable is optional. If it is not defined, a warning will be produced
+  to let you know, and +not saved+ will appear in the +license files+ field
+  of the manifest file for this package.
+
 The recommended way to define these variables is to use the following
 syntax:
 
docs/manual/using.txt +103 -0

106 lines not on this page · raw message

Signature · 1 line
1.7.9.5
#10 lore raw

PATCH v4 9/22 manual: add advice about GPL compliance for Buildroot

In reply to Luca Ceresoli
---
 docs/manual/using.txt |   27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)
docs/manual/using.txt +27 -0
index 42d4061..fcbd24b 100644
@@ -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.
Signature · 1 line
1.7.9.5
#11 lore raw

PATCH v4 9/22 manual: add advice about GPL compliance for Buildroot

Op 17 mei 2012 19:35 schreef "Luca Ceresoli" <[email protected]> het volgende:

Quoted 11 lines
---
 docs/manual/using.txt |   27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)
docs/manual/using.txt +0 -0
index 42d4061..fcbd24b 100644

docs/manual/using.txt Buildroot, with the name used in the manifest file: · line 286

Quoted 3 lines
docs/manual/using.txt +0 -0
@@ -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.

docs/manual/using.txt Buildroot, with the name used in the manifest file:

Quoted 8 lines
docs/manual/using.txt +8 -0
+
+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:

docs/manual/using.txt Buildroot, with the name used in the manifest file: · line 296

Quoted 2 lines
docs/manual/using.txt +2 -0
+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

docs/manual/using.txt Buildroot, with the name used in the manifest file:

Quoted 3 lines
docs/manual/using.txt +3 -0
+in the device storage.
+
+Nevertheless, the general view of the Buildroot developers is that you

should

docs/manual/using.txt Buildroot, with the name used in the manifest file: · line 300

Quoted 1 line
docs/manual/using.txt +1 -0
+release the Buildroot source code along with the source code of other

packages

docs/manual/using.txt Buildroot, with the name used in the manifest file:

Quoted 6 lines
docs/manual/using.txt +6 -0
+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

docs/manual/using.txt Buildroot, with the name used in the manifest file:

Quoted 6 lines
docs/manual/using.txt +6 -0
+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

docs/manual/using.txt Buildroot, with the name used in the manifest file: · line 313

Quoted 1 line
docs/manual/using.txt +1 -0
+consult your legal department or lawyer in case of any doubt.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120517/f7dbf5b7/attachment.html>

#12 lore raw

PATCH v4 9/22 manual: add advice about GPL compliance for Buildroot

In reply to Luca Ceresoli
Quoted 30 lines · Luca Ceresoli
---
  docs/manual/using.txt |   27 +++++++++++++++++++++++++++
  1 file changed, 27 insertions(+)
docs/manual/using.txt +17 -0
index 42d4061..fcbd24b 100644
@@ -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]

docs/manual/using.txt Buildroot, with the name used in the manifest file: · line 313

Quoted 10 lines
docs/manual/using.txt +10 -0
+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.
Signature · 6 lines
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#13 lore raw

PATCH v4 9/22 manual: add advice about GPL compliance for Buildroot

In reply to Luca Ceresoli

Hi,

Quoted 30 lines · Luca Ceresoli
---
  docs/manual/using.txt |   27 +++++++++++++++++++++++++++
  1 file changed, 27 insertions(+)
docs/manual/using.txt +17 -0
index 42d4061..fcbd24b 100644
@@ -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]

docs/manual/using.txt Buildroot, with the name used in the manifest file: · line 313

Quoted 10 lines
docs/manual/using.txt +10 -0
+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

#14 lore raw

PATCH v4 9/22 manual: add advice about GPL compliance for Buildroot

Quoted 13 lines · Luca Ceresoli

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

Quoted 5 lines

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

Quoted 3 lines

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.

Quoted 11 lines

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.

Quoted 6 lines

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

Quoted 6 lines

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

Signature · 6 lines
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
#15 lore raw

PATCH v4 10/22 linux: define license

In reply to Luca Ceresoli
---
 linux/linux.mk |    2 ++
 1 file changed, 2 insertions(+)
linux/linux.mk +2 -0
index f165dda..bd3e23e 100644
@@ -4,6 +4,8 @@
 #
 ###############################################################################
 LINUX_VERSION=$(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
+LINUX_LICENSE = GPLv2
+LINUX_LICENSE_FILES = COPYING
 
 # Compute LINUX_SOURCE and LINUX_SITE from the configuration
 ifeq ($(LINUX_VERSION),custom)
Signature · 1 line
1.7.9.5
#16 lore raw

PATCH v4 11/22 m4: define license

In reply to Luca Ceresoli
---
 package/m4/m4.mk |    2 ++
 1 file changed, 2 insertions(+)
package/m4/m4.mk +2 -0
index 173bba8..1e891c5 100644
@@ -7,6 +7,8 @@
 M4_VERSION = 1.4.16
 M4_SOURCE = m4-$(M4_VERSION).tar.bz2
 M4_SITE = $(BR2_GNU_MIRROR)/m4
+M4_LICENSE = GPLv3+
+M4_LICENSE_FILES = COPYING
 M4_CONF_ENV = gl_cv_func_gettimeofday_clobber=no
 
 ifneq ($(BR2_USE_WCHAR),y)
Signature · 1 line
1.7.9.5
#17 lore raw

PATCH v4 12/22 mpc: define license

In reply to Luca Ceresoli
---
 package/mpc/mpc.mk |    2 ++
 1 file changed, 2 insertions(+)
package/mpc/mpc.mk +2 -0
index e5ee489..5ad47a9 100644
@@ -6,6 +6,8 @@
 
 MPC_VERSION = 0.9
 MPC_SITE = http://www.multiprecision.org/mpc/download
+MPC_LICENSE = LGPLv2.1+
+MPC_LICENSE_FILES = COPYING.LIB
 MPC_INSTALL_STAGING = YES
 MPC_DEPENDENCIES = gmp mpfr
 MPC_AUTORECONF = YES
Signature · 1 line
1.7.9.5
#18 lore raw

PATCH v4 13/22 fakeroot: define license

In reply to Luca Ceresoli
---
 package/fakeroot/fakeroot.mk |    2 ++
 1 file changed, 2 insertions(+)
package/fakeroot/fakeroot.mk +2 -0
index 64203b8..a9074cb 100644
@@ -6,5 +6,7 @@
 FAKEROOT_VERSION = 1.18.2
 FAKEROOT_SOURCE = fakeroot_$(FAKEROOT_VERSION).orig.tar.bz2
 FAKEROOT_SITE = http://snapshot.debian.org/archive/debian/20111201T093630Z/pool/main/f/fakeroot/
+FAKEROOT_LICENSE = GPLv3+
+FAKEROOT_LICENSE_FILES = COPYING
 
 $(eval $(call AUTOTARGETS,host))
Signature · 1 line
1.7.9.5
#19 lore raw

PATCH v4 14/22 bzip2: define license

In reply to Luca Ceresoli
---
 package/bzip2/bzip2.mk |    2 ++
 1 file changed, 2 insertions(+)
package/bzip2/bzip2.mk +2 -0
index 1bc4449..611e5a0 100644
@@ -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 = bzip2 license
+BZIP2_LICENSE_FILES = LICENSE
 BZIP2_INSTALL_STAGING=YES
 
 define BZIP2_FIX_MAKEFILE
Signature · 1 line
1.7.9.5
#20 lore raw

PATCH v4 15/22 directfb: define license

In reply to Luca Ceresoli
---
 package/directfb/directfb.mk |    2 ++
 1 file changed, 2 insertions(+)
package/directfb/directfb.mk +2 -0
index 7aa0398..d0d8421 100644
@@ -7,6 +7,8 @@ DIRECTFB_VERSION_MAJOR = 1.4
 DIRECTFB_VERSION = $(DIRECTFB_VERSION_MAJOR).16
 DIRECTFB_SITE = http://www.directfb.org/downloads/Core/DirectFB-$(DIRECTFB_VERSION_MAJOR)
 DIRECTFB_SOURCE = DirectFB-$(DIRECTFB_VERSION).tar.gz
+DIRECTFB_LICENSE = LGPLv2.1+
+DIRECTFB_LICENSE_FILES = COPYING
 DIRECTFB_AUTORECONF = YES
 DIRECTFB_INSTALL_STAGING = YES
 DIRECTFB_CONF_OPT = \
Signature · 1 line
1.7.9.5
#21 lore raw

PATCH v4 16/22 iostat: define license

In reply to Luca Ceresoli
---
 package/iostat/iostat.mk |    2 ++
 1 file changed, 2 insertions(+)
package/iostat/iostat.mk +2 -0
index 83eea07..6f2e8aa 100644
@@ -6,6 +6,8 @@
 
 IOSTAT_VERSION = 2.2
 IOSTAT_SITE = http://www.linuxinsight.com/files
+IOSTAT_LICENSE = GPL
+IOSTAT_LICENSE_FILES = LICENSE
 
 iostat-source: $(DL_DIR)/$(IOSTAT_SOURCE)
 
Signature · 1 line
1.7.9.5
#22 lore raw

PATCH v4 17/22 lzo: define license

In reply to Luca Ceresoli
---
 package/lzo/lzo.mk |    2 ++
 1 file changed, 2 insertions(+)
package/lzo/lzo.mk +2 -0
index 84f31f0..da5d6b7 100644
@@ -5,6 +5,8 @@
 #############################################################
 LZO_VERSION = 2.06
 LZO_SITE = http://www.oberhumer.com/opensource/lzo/download
+LZO_LICENSE = GPLv2+
+LZO_LICENSE_FILES = COPYING
 LZO_INSTALL_STAGING = YES
 
 $(eval $(call AUTOTARGETS))
Signature · 1 line
1.7.9.5
#23 lore raw

PATCH v4 18/22 lzop: define license

In reply to Luca Ceresoli
---
 package/lzop/lzop.mk |    2 ++
 1 file changed, 2 insertions(+)
package/lzop/lzop.mk +2 -0
index 6d1d674..1e98030 100644
@@ -6,6 +6,8 @@
 LZOP_VERSION = 1.03
 LZOP_SOURCE = lzop-$(LZOP_VERSION).tar.gz
 LZOP_SITE = http://www.lzop.org/download/
+LZOP_LICENSE = GPLv2+
+LZOP_LICENSE_FILES = COPYING
 LZOP_DEPENDENCIES = lzo
 
 $(eval $(call AUTOTARGETS))
Signature · 1 line
1.7.9.5
#24 lore raw

PATCH v4 19/22 libusb: define license

In reply to Luca Ceresoli
---
 package/libusb/libusb.mk |    2 ++
 1 file changed, 2 insertions(+)
package/libusb/libusb.mk +2 -0
index 9abfcfc..ac0f0d2 100644
@@ -6,6 +6,8 @@
 LIBUSB_VERSION = 1.0.9
 LIBUSB_SOURCE = libusb-$(LIBUSB_VERSION).tar.bz2
 LIBUSB_SITE = http://$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/project/libusb/libusb-1.0/libusb-$(LIBUSB_VERSION)
+LIBUSB_LICENSE = LGPLv2.1+
+LIBUSB_LICENSE_FILES = COPYING
 LIBUSB_DEPENDENCIES = host-pkg-config
 LIBUSB_INSTALL_STAGING = YES
 
Signature · 1 line
1.7.9.5
#25 lore raw

PATCH v4 20/22 pcre: define license

In reply to Luca Ceresoli
---
 package/pcre/pcre.mk |    2 ++
 1 file changed, 2 insertions(+)
package/pcre/pcre.mk +2 -0
index db896fd..d01ca84 100644
@@ -6,6 +6,8 @@
 
 PCRE_VERSION = 8.30
 PCRE_SITE = ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre
+PCRE_LICENSE = BSD-3c
+PCRE_LICENSE_FILES = LICENCE
 PCRE_INSTALL_STAGING = YES
 
 ifneq ($(BR2_INSTALL_LIBSTDCPP),y)
Signature · 1 line
1.7.9.5
#26 lore raw

PATCH v4 21/22 netsnmp: define license

In reply to Luca Ceresoli
---
 package/netsnmp/netsnmp.mk |    2 ++
 1 file changed, 2 insertions(+)
package/netsnmp/netsnmp.mk +2 -0
index 448e3fd..125782f 100644
@@ -7,6 +7,8 @@
 NETSNMP_VERSION = 5.7.1
 NETSNMP_SITE = http://$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/net-snmp
 NETSNMP_SOURCE = net-snmp-$(NETSNMP_VERSION).tar.gz
+NETSNMP_LICENSE = Various BSD-like
+NETSNMP_LICENSE_FILES = COPYING
 NETSNMP_INSTALL_STAGING = YES
 NETSNMP_CONF_ENV = ac_cv_NETSNMP_CAN_USE_SYSCTL=yes
 NETSNMP_CONF_OPT = --with-persistent-directory=/var/lib/snmp --disable-static \
Signature · 1 line
1.7.9.5
#27 lore raw

PATCH v4 22/22 berkeleydb: define license

In reply to Luca Ceresoli
---
 package/berkeleydb/berkeleydb.mk |    2 ++
 1 file changed, 2 insertions(+)
package/berkeleydb/berkeleydb.mk +2 -0
index d737896..b42c000 100644
@@ -7,6 +7,8 @@ BERKELEYDB_VERSION = 5.3.15
 BERKELEYDB_SITE = http://download.oracle.com/berkeley-db
 BERKELEYDB_SOURCE = db-$(BERKELEYDB_VERSION).NC.tar.gz
 BERKELEYDB_SUBDIR = build_unix
+BERKELEYDB_LICENSE = BerkeleyDB License
+BERKELEYDB_LICENSE_FILES = LICENSE
 BERKELEYDB_INSTALL_STAGING = YES
 BERKELEYDB_BINARIES = db_archive db_checkpoint db_deadlock db_dump \
 	db_hotbackup db_load db_log_verify db_printlog db_recover db_replicate \
Signature · 1 line
1.7.9.5
#28 lore raw

v4 cover Automatically produce legal compliance info

In reply to Luca Ceresoli

Hi Peter,

Quoted 3 lines · Luca Ceresoli

Hi,

here is the third version of the legal-info feature implementation.

Meaning the fourth, of course.

Quoted 18 lines

Links to discussion of previous versions:
v1: http://lists.busybox.net/pipermail/buildroot/2012-January/049590.html
v2: http://lists.busybox.net/pipermail/buildroot/2012-March/051132.html
v3: http://lists.busybox.net/pipermail/buildroot/2012-May/053574.html

This version is only a minor update to fix various issues reported by other developers. There are not changes to the general structure, so please see the link above for v3 for a detailed presentation.

Let me repeat only my plea to all Buildroot developers to read and give feedback on patch 9.
It gives an advice from Buildroot developers to Buildroot users about how to comply with both Buildroot's and the packages' licenses.
Of course this must match as much as possible what the developers think, so please read it and give either your different views or your ack (preferably with a formal Acked-by tag).

Quoted 1 line

Thanks.

Peter, are you considering to merge this patchset into mainline Buildroot?

If you are, I'll submit a rebased version in the next few days, with the addition
of the Signed-off-by tags received so far. There is no further change required
AFAIK, and only a trivial conflict.

I also think your opinion about patch 9 is very important, since you're the maintainer.

Thanks,
Luca

#29 lore raw

v4 cover Automatically produce legal compliance info

In reply to Luca Ceresoli

Le Thu, 17 May 2012 19:32:59 +0200,
Luca Ceresoli <[email protected]> a ?crit :

Quoted 13 lines

here is the third version of the legal-info feature implementation.

Links to discussion of previous versions:
v1:
http://lists.busybox.net/pipermail/buildroot/2012-January/049590.html
v2:
http://lists.busybox.net/pipermail/buildroot/2012-March/051132.html
v3: http://lists.busybox.net/pipermail/buildroot/2012-May/053574.html

This version is only a minor update to fix various issues reported by other developers. There are not changes to the general structure, so please see the link above for v3 for a detailed presentation.

Quoted 7 lines

Let me repeat only my plea to all Buildroot developers to read and give feedback on patch 9.
It gives an advice from Buildroot developers to Buildroot users about how to comply with both Buildroot's and the packages' licenses. Of course this must match as much as possible what the developers think, so please read it and give either your different views or your ack (preferably with a formal Acked-by tag).

Ok, this series has been around for a while. I think that the overall idea has been accepted by everybody, and has been discussed during the Buildroot Developers Meeting in February.

Even though I think there might be a few possibilities to make the code a bit nicer in patch 01/22, that's only internal implementation details that can be improved at a later point.

Therefore, I'm now hesitating between those two solutions:

(1) Pulling all this in the current master, so that it will be part of the next 2012.08 release. The chance of breaking seems fairly limited to me, and this code has been around for a while, and I'd like us to make progress on this.

(2) Be a bit safer, and wait the end of July to merge this into the -next branch, once 2012.08-rc1 has been released.

What's the community opinion on this? At the moment, I'm leaning towards (1), but I'd like to hear others opinion on this.

Best regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#30 lore raw

v4 cover Automatically produce legal compliance info

Op 16 jul. 2012 09:55 schreef "Thomas Petazzoni" < [email protected]> het volgende:

Quoted 40 lines

Le Thu, 17 May 2012 19:32:59 +0200,
Luca Ceresoli <[email protected]> a ?crit :

Quoted 13 lines

here is the third version of the legal-info feature implementation.

Links to discussion of previous versions:
v1:
http://lists.busybox.net/pipermail/buildroot/2012-January/049590.html
v2:
http://lists.busybox.net/pipermail/buildroot/2012-March/051132.html
v3: http://lists.busybox.net/pipermail/buildroot/2012-May/053574.html

This version is only a minor update to fix various issues reported by other developers. There are not changes to the general structure, so please see the link above for v3 for a detailed presentation.

Quoted 7 lines

Let me repeat only my plea to all Buildroot developers to read and give feedback on patch 9.
It gives an advice from Buildroot developers to Buildroot users about how to comply with both Buildroot's and the packages' licenses. Of course this must match as much as possible what the developers think, so please read it and give either your different views or your ack (preferably with a formal Acked-by tag).

Ok, this series has been around for a while. I think that the overall idea has been accepted by everybody, and has been discussed during the Buildroot Developers Meeting in February.

Even though I think there might be a few possibilities to make the code a bit nicer in patch 01/22, that's only internal implementation details that can be improved at a later point.

Therefore, I'm now hesitating between those two solutions:

(1) Pulling all this in the current master, so that it will be part of the next 2012.08 release. The chance of breaking seems fairly limited to me, and this code has been around for a while, and I'd like us to make progress on this.

Quoted 5 lines

(2) Be a bit safer, and wait the end of July to merge this into the -next branch, once 2012.08-rc1 has been released.

What's the community opinion on this? At the moment, I'm leaning towards (1), but I'd like to hear others opinion on this.

I'd go for (1). As you say, chances of breaking something is small. Plus, if we can get this into the August release, we'll start getting further feedback right away instead of waiting another three months.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120717/4e7f7ef6/attachment.html>

#31 lore raw

v4 cover Automatically produce legal compliance info

Le 17/07/2012 16:55, Thomas De Schampheleire a ?crit :

Quoted 45 lines

Op 16 jul. 2012 09:55 schreef "Thomas Petazzoni" < thomas.petazzoni at free-electrons.com> het volgende:

Quoted 43 lines

Le Thu, 17 May 2012 19:32:59 +0200,
Luca Ceresoli <[email protected]> a ?crit :

Quoted 13 lines

here is the third version of the legal-info feature implementation.

Links to discussion of previous versions:
v1:
http://lists.busybox.net/pipermail/buildroot/2012-January/049590.html
v2:
http://lists.busybox.net/pipermail/buildroot/2012-March/051132.html
v3: http://lists.busybox.net/pipermail/buildroot/2012-May/053574.html

This version is only a minor update to fix various issues reported by other developers. There are not changes to the general structure, so please see the link above for v3 for a detailed presentation.

Quoted 7 lines

Let me repeat only my plea to all Buildroot developers to read and give feedback on patch 9.
It gives an advice from Buildroot developers to Buildroot users about how to comply with both Buildroot's and the packages' licenses. Of course this must match as much as possible what the developers think, so please read it and give either your different views or your ack (preferably with a formal Acked-by tag).

Ok, this series has been around for a while. I think that the overall idea has been accepted by everybody, and has been discussed during the Buildroot Developers Meeting in February.

Even though I think there might be a few possibilities to make the code a bit nicer in patch 01/22, that's only internal implementation details that can be improved at a later point.

Therefore, I'm now hesitating between those two solutions:

(1) Pulling all this in the current master, so that it will be part of the next 2012.08 release. The chance of breaking seems fairly limited to me, and this code has been around for a while, and I'd like us to make progress on this.

(2) Be a bit safer, and wait the end of July to merge this into the -next branch, once 2012.08-rc1 has been released.

Quoted 6 lines
Quoted 2 lines

What's the community opinion on this? At the moment, I'm leaning towards (1), but I'd like to hear others opinion on this.

I'd go for (1). As you say, chances of breaking something is small. Plus, if we can get this into the August release, we'll start getting further feedback right away instead of waiting another three months.

Agreed.
I'd go for (1) too.

Maxime

Signature · 4 lines
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#32 lore raw

v4 cover Automatically produce legal compliance info

2012/7/17 Maxime Ripard <[email protected]>:

Quoted 31 lines

Le 17/07/2012 16:55, Thomas De Schampheleire a ?crit :

Quoted 30 lines

Op 16 jul. 2012 09:55 schreef "Thomas Petazzoni" < thomas.petazzoni at free-electrons.com> het volgende:

Quoted 27 lines

Le Thu, 17 May 2012 19:32:59 +0200,
Luca Ceresoli <[email protected]> a ?crit :

Quoted 2 lines

here is the third version of the legal-info feature implementation.

Ok, this series has been around for a while. I think that the overall idea has been accepted by everybody, and has been discussed during the Buildroot Developers Meeting in February.

Even though I think there might be a few possibilities to make the code a bit nicer in patch 01/22, that's only internal implementation details that can be improved at a later point.

Therefore, I'm now hesitating between those two solutions:

(1) Pulling all this in the current master, so that it will be part of the next 2012.08 release. The chance of breaking seems fairly limited to me, and this code has been around for a while, and I'd like us to make progress on this.

(2) Be a bit safer, and wait the end of July to merge this into the -next branch, once 2012.08-rc1 has been released.

What's the community opinion on this? At the moment, I'm leaning towards (1), but I'd like to hear others opinion on this.

Quoted 6 lines
Quoted 3 lines

I'd go for (1). As you say, chances of breaking something is small. Plus, if we can get this into the August release, we'll start getting further feedback right away instead of waiting another three months.

Agreed.
I'd go for (1) too.

I second (1) too.

Signature · 1 line
Sam
#33 lore raw

v4 cover Automatically produce legal compliance info

In reply to Luca Ceresoli

Le Thu, 17 May 2012 19:32:59 +0200,
Luca Ceresoli <[email protected]> a ?crit :

Quoted 10 lines

here is the third version of the legal-info feature implementation.

Links to discussion of previous versions:
v1: http://lists.busybox.net/pipermail/buildroot/2012-January/049590.html
v2: http://lists.busybox.net/pipermail/buildroot/2012-March/051132.html
v3: http://lists.busybox.net/pipermail/buildroot/2012-May/053574.html

This version is only a minor update to fix various issues reported by other developers. There are not changes to the general structure, so please see the link above for v3 for a detailed presentation.

Following the comments of several Buildroot contributors, I have merged the 22 patches of your series. Thanks a lot for your perseverance in getting this merged!

Now, I'd like to point something: the SPDX standard, documented at
http://spdx.org/. It is precisely designed to describe the list of packages that compose a system. Since it's a big XML nightmare, I'm not sure we want to support this, but at least they have a list of licenses, each associated with a short name, that would be good to follow as a convention, I think. See http://www.spdx.org/licenses/.
What do you think about this?

Best regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#34 lore raw

v4 cover Automatically produce legal compliance info

Le Tue, 17 Jul 2012 19:36:10 +0200,
Thomas Petazzoni <[email protected]> a ?crit :

Quoted 3 lines

Following the comments of several Buildroot contributors, I have merged the 22 patches of your series. Thanks a lot for your perseverance in getting this merged!

I have also added the execution of 'make legal-info' to my autobuilder. So all builds coming from the Free Electrons build server visible at
http://autobuild.buildroot.org will have the CSV file of the licenses. It is not directly visible in the webpage, but if you go in the "dir" link, and then look at the licenses-manifest.csv file, it corresponds to the output/legal-info/manifest.csv file.

Example:
http://autobuild.buildroot.org/results/a07c8611de688b6dccbfae00ff153ad89f3e7f77/licenses-manifest.csv

This way, the legal-info machinery will be exercised on many packages.

Best regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#35 lore raw

v4 cover Automatically produce legal compliance info

Quoted 14 lines · Thomas Petazzoni

Le Tue, 17 Jul 2012 19:36:10 +0200,
Thomas Petazzoni <[email protected]> a ?crit :

Quoted 3 lines

Following the comments of several Buildroot contributors, I have merged the 22 patches of your series. Thanks a lot for your perseverance in getting this merged!

I have also added the execution of 'make legal-info' to my autobuilder. So all builds coming from the Free Electrons build server visible at
http://autobuild.buildroot.org will have the CSV file of the licenses. It is not directly visible in the webpage, but if you go in the "dir" link, and then look at the licenses-manifest.csv file, it corresponds to the output/legal-info/manifest.csv file.

Quoted 4 lines

Example:
http://autobuild.buildroot.org/results/a07c8611de688b6dccbfae00ff153ad89f3e7f77/licenses-manifest.csv

This way, the legal-info machinery will be exercised on many packages.

Good!

I'm quickly looking at the latest daily autobuild e-mail reports, and I don't see evidence of any failure. But, in order to be sure, is there a specific error message for make legal-info? Maybe a specific string in the "Failure reason" line?

Thanks,
Luca

#36 lore raw

v4 cover Automatically produce legal compliance info

Le Thu, 19 Jul 2012 12:11:51 +0200,
Luca Ceresoli <[email protected]> a ?crit :

Quoted 4 lines

I'm quickly looking at the latest daily autobuild e-mail reports, and I don't see evidence of any failure. But, in order to be sure, is there a specific error message for make legal-info? Maybe a specific string in the "Failure reason" line?

Well, so far there doesn't seem to be any failure related to the legal-info mechanism. I just do "make legal-info" at the end of the build if the build was successful, and if "make legal-info" fails, the build would be reported as failed. The failure reason would then contain the "make error" line.

Best regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com