Automatically produce legal compliance info
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
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
@@ -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
@@ -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
@@ -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
@@ -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
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:
- inpackage/pkg-utils.mksome helper functions are defined for common actionssuch 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;-
Makefileimplements 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
Signed-off-by Luca Ceresoli<[email protected]>
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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
Signed-off-by Luca Ceresoli <[email protected]>--- docs/manual/using.txt | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)docs/manual/using.txt +0
-0
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>
PATCH v4 9/22 manual: add advice about GPL compliance for Buildroot
In reply to Luca CeresoliQuoted 30 lines · Luca Ceresoli
Signed-off-by Luca Ceresoli<[email protected]>--- docs/manual/using.txt | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)docs/manual/using.txt +17
-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. + +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
PATCH v4 9/22 manual: add advice about GPL compliance for Buildroot
In reply to Luca CeresoliHi,
Quoted 30 lines · Luca Ceresoli
Signed-off-by Luca Ceresoli<[email protected]>--- docs/manual/using.txt | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)docs/manual/using.txt +17
-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. + +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
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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
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
@@ -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
v4 cover Automatically produce legal compliance info
In reply to Luca CeresoliHi 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.htmlThis 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
v4 cover Automatically produce legal compliance info
In reply to Luca CeresoliLe 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.htmlThis 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
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.htmlThis 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>
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.htmlThis 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
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
v4 cover Automatically produce legal compliance info
In reply to Luca CeresoliLe 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.htmlThis 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
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.
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
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
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
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