Automatically produce legal compliance info

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

---
 Makefile                    |    9 ++++++++-
 package/Makefile.package.in |    6 ++++++
 2 files changed, 14 insertions(+), 1 deletions(-)

Makefile +0 -0

index 912012f..507fd78 100644

Quoted 1 line · On Sunday 29 January 2012 16:11:34 Luca Ceresoli wrote:

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

Reviewed-by Arnout Vandecappelle (Essensium/Mind)<[email protected]>

Quoted 13 lines

---
  Makefile                    |    9 ++++++++-
  package/Makefile.package.in |    6 ++++++
  2 files changed, 14 insertions(+), 1 deletions(-)

Makefile +0 -0

index 912012f..507fd78 100644
@@ -354,6 +354,11 @@ HOST_DEPS = $(sort $(foreach dep,\
  		$($(dep))))
  HOST_SOURCE += $(addsuffix -source,$(sort $(TARGETS_HOST_DEPS) $(HOST_DEPS)))
 

Makefile HOST_DEPS = $(sort $(foreach dep,\ · line 361

Quoted 5 lines

Makefile +5 -0

+TARGETS_LEGAL_INFO:=$(patsubst %,%-legal-info,\
+		$(filter-out makedevs,\
+		$(patsubst host-%,%,\
+		$(TARGETS) $(BASE_TARGETS) $(TARGETS_HOST_DEPS) $(HOST_DEPS))))
+

Are we creating the legal info of the target or the SDK here? If it is
for the target, the host-% are not needed since they are not distributed. I think there should be a separate command for the SDK's legal info.

[snip]

Makefile

Quoted 3 lines

+$(1)-legal-info: $(1)-source

Makefile +2 -0

+			@echo -e "$(1)\t$$($(3)_VERSION)\t$$($(3)_LICENSE)"
+

Minor detail: if this patch is separate from the one that saves the source
tarball, the dependency on $(1)-source is unnecessary.

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

Makefile +1 -0

+legal-info: legal-info-prepare-manifest $(TARGETS_LEGAL_INFO)
 
 show-targets:
 	@echo $(TARGETS)

package/Makefile.package.in +0 -0

index 8e73f34..e117223 100644

package/Makefile.package.in +0 -0

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

Quoted 1 line · On Sunday 29 January 2012 16:11:35 Luca Ceresoli wrote:

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

Reviewed-by Arnout Vandecappelle (Essensium/Mind)<[email protected]>

[snip]

Makefile TARGETS_LEGAL_INFO:=$(patsubst %,%-legal-info,\ · line 369

Quoted 3 lines

  dirs: $(DL_DIR) $(TOOLCHAIN_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \

Makefile +1 -1

-	$(HOST_DIR) $(BINARIES_DIR) $(STAMP_DIR)
+	$(HOST_DIR) $(BINARIES_DIR) $(STAMP_DIR) $(LEGAL_INFO_DIR)

Since legal-info-prepare-manifest already depends on LEGAL_INFO_DIR, this is redundant.

[snip]

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

Quoted 4 lines

Makefile +4 -0

+legal-info-prepare-manifest: $(LEGAL_INFO_DIR)
+	@rm -f $(LEGAL_MANIFEST_CSV)
+	@echo "package,version,license">$(LEGAL_MANIFEST_CSV)
+

I might be wrong, but I think this won't rebuild the manifest if the
directory already exists. You'd need a dependency on FORCE (and add the phony FORCE target).

Again a minor comment: the clean target is missing here (but it's added
in the next patch). But for me, the first three patches can be rolled into one.

Quoted 13 lines

Makefile +1 -0

+legal-info: legal-info-prepare-manifest $(TARGETS_LEGAL_INFO)
 
  show-targets:
  	@echo $(TARGETS)

package/Makefile.package.in +0 -0

index 8e73f34..e117223 100644
@@ -653,8 +653,10 @@ $(1)-rsync:		$$($(2)_TARGET_RSYNC)
  $(1)-source:		$$($(2)_TARGET_RSYNC_SOURCE)
  endif
 

package/Makefile.package.in $(1)-rsync: $$($(2)_TARGET_RSYNC) · line 659

Quoted 5 lines

package/Makefile.package.in +3 -1

-$(1)-legal-info:	$(1)-source
+$(1)-legal-info:	$(1)-source $(LEGAL_INFO_DIR)
  			@echo -e "$(1)\t$$($(3)_VERSION)\t$$($(3)_LICENSE)"
+			@echo "$(1),$$($(3)_VERSION),$$($(3)_LICENSE)" \
+				>>$(LEGAL_MANIFEST_CSV)

Same here: will the manifest be rebuilt if the directory already exists?

Anybody has something against squashing the first 3 or 4 patches as Arnout suggests?

Quoted 14 lines · Arnout Vandecappelle

Quoted 2 lines · On Sunday 29 January 2012 16:11:35 Luca Ceresoli wrote:

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

Reviewed-by Arnout Vandecappelle (Essensium/Mind)<[email protected]>

[snip]

Quoted 5 lines

?dirs: $(DL_DIR) $(TOOLCHAIN_DIR) $(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
- ? ? ? $(HOST_DIR) $(BINARIES_DIR) $(STAMP_DIR)
+ ? ? ? $(HOST_DIR) $(BINARIES_DIR) $(STAMP_DIR) $(LEGAL_INFO_DIR)

Quoted 2 lines

?Since legal-info-prepare-manifest already depends on LEGAL_INFO_DIR, this ?is redundant.

I used to think some Buildroot user might want to 'make dirs'. I understand this is pretty useless, so I'll remove it.

Quoted 5 lines

[snip]

Quoted 1 line

Quoted 8 lines

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

Quoted 4 lines

Makefile +4 -0

+legal-info-prepare-manifest: $(LEGAL_INFO_DIR)
+ ? ? ? @rm -f $(LEGAL_MANIFEST_CSV)
+ ? ? ? @echo "package,version,license">$(LEGAL_MANIFEST_CSV)
+

?I might be wrong, but I think this won't rebuild the manifest if the directory already exists. ?You'd need a dependency on FORCE (and add the phony FORCE target).

It is rebuilt because legal-info-prepare-manifest is PHONY.

Quoted 4 lines

?Again a minor comment: the clean target is missing here (but it's added in the next patch). ?But for me, the first three patches can be rolled into one.

I could move the clean target to the 2nd patch, but actually this maintenance burden is quite annoying, and is going to be even more since this patchset will definitely have further changes.

Anybody has something against squashing the first 3 or 4 patches as Arnout suggests?

Quoted 14 lines

Quoted 14 lines

+legal-info: legal-info-prepare-manifest $(TARGETS_LEGAL_INFO)

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

package/Makefile.package.in +0 -0

index 8e73f34..e117223 100644
@@ -653,8 +653,10 @@ $(1)-rsync: ? ? ? ? ? ? ? ?$$($(2)_TARGET_RSYNC)
 ?$(1)-source: ? ? ? ? ?$$($(2)_TARGET_RSYNC_SOURCE)

?endif

Quoted 8 lines

Quoted 6 lines

-$(1)-legal-info: ? ? ? $(1)-source
+$(1)-legal-info: ? ? ? $(1)-source $(LEGAL_INFO_DIR)
? ? ? ? ? ? ? ? ? ? ? ?@echo -e "$(1)\t$$($(3)_VERSION)\t$$($(3)_LICENSE)"
+ ? ? ? ? ? ? ? ? ? ? ? @echo "$(1),$$($(3)_VERSION),$$($(3)_LICENSE)" \
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? >>$(LEGAL_MANIFEST_CSV)

?Same here: will the manifest be rebuilt if the directory already exists?

It is rebuilt as well because $(1)-info-prepare-manifest is PHONY.

Luca

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

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

Makefile +0 -0

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

package/Makefile.package.in +0 -0

index e117223..0d7e081 100644

package/Makefile.package.in +0 -0

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

Quoted 1 line · On Sunday 29 January 2012 16:11:36 Luca Ceresoli wrote:

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

Darn, I've been adding Reviewed-by tags even though I said I wouldn't :-)

[snip]

Quoted 2 lines

(quoted diff) +0 -0

@@ -633,7 +635,8 @@ endif
 

Makefile endif · line 639

Quoted 5 lines

Makefile +2 -1

  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) $(REDIST_SOURCES_DIR)

$(REDIST_SOURCES_DIR) is a subdir of $(LEGAL_INFO_DIR), so doesn't need
to be cleaned twice.

Quoted 12 lines

Makefile +0 -0

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

package/Makefile.package.in +0 -0

index e117223..0d7e081 100644
@@ -653,10 +653,11 @@ $(1)-rsync:		$$($(2)_TARGET_RSYNC)
  $(1)-source:		$$($(2)_TARGET_RSYNC_SOURCE)
  endif
 

package/Makefile.package.in $(1)-rsync: $$($(2)_TARGET_RSYNC) · line 660

Quoted 6 lines

package/Makefile.package.in +2 -1

-$(1)-legal-info:	$(1)-source $(LEGAL_INFO_DIR)
+$(1)-legal-info:	$(1)-source $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR)
  			@echo -e "$(1)\t$$($(3)_VERSION)\t$$($(3)_LICENSE)"
  			@echo "$(1),$$($(3)_VERSION),$$($(3)_LICENSE)" \
  				>>$(LEGAL_MANIFEST_CSV)
+			@cp $(DL_DIR)/$$($(3)_SOURCE) $(REDIST_SOURCES_DIR)

Actually, for local and override packages (of which you said they are not
supported at the moment), $(1)-source should create a tar file.

This is only for testing the proprietary package handling, not to be committed in any serious repository.

package/foobar/source/foobar.c new file +2 -0

+FOOBAR_LICENSE = PROPRIETARY
 
+++ b/package/foobar/source/foobar.c

Quoted 6 lines · Luca Ceresoli

This is only for testing the proprietary package handling, not to be committed in any serious repository.

+FOOBAR_LICENSE = PROPRIETARY

package/foobar/source/foobar.c line 7

Quoted 9 lines

+++ b/package/foobar/source/foobar.c

package/foobar/source/foobar.c new file +7 -0

@@ -0,0 +1,7 @@
+#include <stdlib.h>
+
+int main(void)
+{
+ ?printf("Hello, World!\n");
+ ?return 0;
+}

<sarcasm>
OMG OMG... buildroot is forking into a?proprietary?applications DB... where is ./ where we need them?
</sarcasm>

/me takes a cup of water and relaxes... ;-)
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 7 lines · Diego Iastrubni

Quoted 6 lines · Luca Ceresoli

This is only for testing the proprietary package handling, not to be committed in any serious repository.

+FOOBAR_LICENSE = PROPRIETARY

Quoted 16 lines

package/foobar/source/foobar.c line 7

Quoted 9 lines

+++ b/package/foobar/source/foobar.c

package/foobar/source/foobar.c new file +7 -0

@@ -0,0 +1,7 @@
+#include <stdlib.h>
+
+int main(void)
+{
+ ?printf("Hello, World!\n");
+ ?return 0;
+}

<sarcasm>
OMG OMG... buildroot is forking into a?proprietary?applications DB... where is ./ where we need them?
</sarcasm>

Perhaps you missed the recently added support for closed source binary firmware blobs?

<sarcasm>
Your panic threshold setting may have to be tweaked up a bit. </sarcasm>

If this proposal or something like it is included in the build system, then those firmware blob licenses could also be handled with the new bit of infrastructure.

Mike

Quoted 7 lines

/me takes a cup of water and relaxes... ;-)
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

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

Quoted 2 lines · Diego Iastrubni

Quoted 1 line · Luca Ceresoli

If this proposal or something like it is included in the build system, then those firmware blob licenses could also be handled with the new bit of infrastructure.

  $ make legal-info
  busybox  1.19.3       GPL_V2_ONLY
  bzip2    1.0.5        BSD
  directfb 1.4.15       LGPL_V2.1
  foobar   1.2.3.4      PROPRIETARY
  freetype 2.4.8        unknown
  iostat   2.2          GPL_V2

...

  $ cat output/legal-info/manifest.csv 
  package,version,license
  busybox,1.19.3,GPL_V2_ONLY
  bzip2,1.0.5,BSD
  directfb,1.4.15,LGPL_V2.1
  foobar,1.2.3.4,PROPRIETARY
  freetype,2.4.8,unknown
  iostat,2.2,GPL_V2
  ...

  $ ls output/legal-info/sources/
  autoconf-2.65.tar.bz2
  automake-1.11.1.tar.bz2
  binutils-2.21.1.tar.bz2
  busybox-1.19.3.tar.bz2
  bzip2-1.0.5.tar.gz
  DirectFB-1.4.15.tar.gz
  fakeroot_1.9.5.tar.gz
  freetype-2.4.8.tar.bz2
  ...

The implementation takes only ~35 lines of code so it should be simple to review.

Now the long list of open issues.

The semantics of the _LICENSE variable is still non well defined. It might be a generic string (e.g. FOOBAR_LICENSE = modified 3-clause BSD), or one from a well-defined list of known licenses.
The former interpretation is probably the more useful for producing a manifest file. The latter might be useful to help an automated implementation of the last goal listed above: save the complete text of all license files to a directory.

Copying the source tarball does not currently work for packages with _SITE_METHOD equal to local, as there is no tarball associated to it.

Other methods, such as file and all versioning systems, are not tested, but they should work as there's a tarball in the download dir.

Non-gentargets and non-autotargets packages are not tested. I guess they need a $(PKG)-legal-info target to be defined manually.

It might be useful to remove the output/legal-info dir before populating it, to be sure there are no remnants of previous runs. It would not have a big additional cost, since the computations and copies must be done anyway.

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

This is a first tentative implementation of these features.

This code is not yet fully working, but I wanted to share it with you to receive some early comments. I also wanted to allow those who will participate to the next Buildroot Developer Day next Friday to have an idea of this proposal in advance, in case this were object of discussion during the meeting.

My approach is based on the creation of a per-package _LICENSE constant in eack .mk file, such as:
FOOBAR_LICENSE = GPL_V3
MYAPP_LICENSE = PROPRIETARY
This is the only effort required to the package creator. Where it is not specified it defaults to "unknown".

My overall goal is to add a new 'make legal-info' target that:
- produces a manifest file listing all packages, including closed-source ones (and, why not, prints out to stdout the same info);
- copies source code tarballs for all non-proprietary packages (although I'm saving also tarballs for BSD-licensed packages for now);
- save the complete text of all license files that must be included in the product documentation (typically COPYING and LICENSE files); this is to simplify the work of who must provide these info to documentation writers.

This patchset implements the first two points, albeit with some issues that I discuss below.
About the third point I devised a few different possible implementations, but each of them has relevant drawbacks, so I left this point out for the moment.

Here's what is currently implmented:

  $ make legal-info
  busybox  1.19.3       GPL_V2_ONLY
  bzip2    1.0.5        BSD
  directfb 1.4.15       LGPL_V2.1
  foobar   1.2.3.4      PROPRIETARY
  freetype 2.4.8        unknown
  iostat   2.2          GPL_V2
  ...
  $ cat output/legal-info/manifest.csv 
  package,version,license
  busybox,1.19.3,GPL_V2_ONLY
  bzip2,1.0.5,BSD
  directfb,1.4.15,LGPL_V2.1
  foobar,1.2.3.4,PROPRIETARY
  freetype,2.4.8,unknown
  iostat,2.2,GPL_V2
  ...
  $ ls output/legal-info/sources/
  autoconf-2.65.tar.bz2

  automake-1.11.1.tar.bz2
  binutils-2.21.1.tar.bz2
  busybox-1.19.3.tar.bz2
  bzip2-1.0.5.tar.gz
  DirectFB-1.4.15.tar.gz
  fakeroot_1.9.5.tar.gz
  freetype-2.4.8.tar.bz2
  ...

Luca, All,

Quoted 55 lines · On Sunday 29 January 2012 16:11:33 Luca Ceresoli wrote:

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

This is a first tentative implementation of these features.

This code is not yet fully working, but I wanted to share it with you to receive some early comments. I also wanted to allow those who will participate to the next Buildroot Developer Day next Friday to have an idea of this proposal in advance, in case this were object of discussion during the meeting.

My approach is based on the creation of a per-package _LICENSE constant in eack .mk file, such as:
? FOOBAR_LICENSE = GPL_V3
? MYAPP_LICENSE = PROPRIETARY
This is the only effort required to the package creator. Where it is not specified it defaults to "unknown".

My overall goal is to add a new 'make legal-info' target that:
?- produces a manifest file listing all packages, including closed-source ones ? ?(and, why not, prints out to stdout the same info);
?- copies source code tarballs for all non-proprietary packages (although I'm ? ?saving also tarballs for BSD-licensed packages for now);
?- save the complete text of all license files that must be included in the ? ?product documentation (typically COPYING and LICENSE files); this is to ? ?simplify the work of who must provide these info to documentation writers.

This patchset implements the first two points, albeit with some issues that I discuss below.
About the third point I devised a few different possible implementations, but each of them has relevant drawbacks, so I left this point out for the moment.

Here's what is currently implmented:

? $ make legal-info
? busybox ?1.19.3 ? ? ? GPL_V2_ONLY
? bzip2 ? ?1.0.5 ? ? ? ?BSD
? directfb 1.4.15 ? ? ? LGPL_V2.1
? foobar ? 1.2.3.4 ? ? ?PROPRIETARY
? freetype 2.4.8 ? ? ? ?unknown
? iostat ? 2.2 ? ? ? ? ?GPL_V2
? ...
? $ cat output/legal-info/manifest.csv
? package,version,license
? busybox,1.19.3,GPL_V2_ONLY
? bzip2,1.0.5,BSD
? directfb,1.4.15,LGPL_V2.1
? foobar,1.2.3.4,PROPRIETARY
? freetype,2.4.8,unknown
? iostat,2.2,GPL_V2
? ...
? $ ls output/legal-info/sources/
? autoconf-2.65.tar.bz2

Quoted 8 lines

? automake-1.11.1.tar.bz2
? binutils-2.21.1.tar.bz2
? busybox-1.19.3.tar.bz2
? bzip2-1.0.5.tar.gz
? DirectFB-1.4.15.tar.gz
? fakeroot_1.9.5.tar.gz
? freetype-2.4.8.tar.bz2
? ...

That's a pretty nice feature! Great!

However, I can see something missing for GPL/LGPL packages. GPL/LGPL states that you must also provide "the scripts used to control compilation and installation of the executable."

Which means that, for packages such as Linux, busybox and uClibc (maybe others as well), the associated .config file should be bundled as well.

Also, the config/build/install instructions for each GPL/LGPL package must be provided. This could probably be done by bundling the buildroot sources too in output/legal-info/sources/, or by leveraging the package infrastructure to output the executed commands for every packages.

Also, for packages that get patches applied by buildroot, you must make sure that the tarballs for those packages do contain the pathced code, or that the patches are bundled as well. From what I see, you currently only copy the downladed tarballs. Of course, if buildroot is also copied to the output/legal-info/sources/ the patches will be there.

Quoted 13 lines

However, I can see something missing for GPL/LGPL packages. GPL/LGPL states that you must also provide "the scripts used to control compilation and installation of the executable."

Which means that, for packages such as Linux, busybox and uClibc (maybe others as well), the associated .config file should be bundled as well.

Also, the config/build/install instructions for each GPL/LGPL package must be provided. This could probably be done by bundling the buildroot sources too in output/legal-info/sources/, or by leveraging the package infrastructure to output the executed commands for every packages.

Quoted 5 lines

Also, for packages that get patches applied by buildroot, you must make sure that the tarballs for those packages do contain the pathced code, or that the patches are bundled as well. From what I see, you currently only copy the downladed tarballs. Of course, if buildroot is also copied to the output/legal-info/sources/ the patches will be there.

I agree with Yann: I think we should package buildroot itself as well.

In fact, I think we should:
- make distclean
- create the manifest
- download all needed sources
- run a pre-legal-package script for customization
- create a .tar file with the whole

The pre-legal-package script (whatever the name) is similar to the post-build script, and allows projects to modify certain things. For example, modify the defconfig to disable some proprietary things that are not useful or usable by the customer.

Also, I think the DL_DIR setting should be modified so that it points to the location where the source tarballs are downloaded. This way, the customer can directly use these sources from that location when re-building buildroot.

I haven't done a technical review of your patches, but I went through them and agree with the principle. Thanks for posting them before the developer day, it will certainly help the discussion!

Yann, Thomas,
thanks for your follow-ups.

Quoted 36 lines · Thomas De Schampheleire

Quoted 15 lines

However, I can see something missing for GPL/LGPL packages. GPL/LGPL states
that you must also provide "the scripts used to control compilation and installation of the executable."

Which means that, for packages such as Linux, busybox and uClibc (maybe others as well), the associated .config file should be bundled as well.

Also, the config/build/install instructions for each GPL/LGPL package must be provided. This could probably be done by bundling the buildroot sources too in output/legal-info/sources/, or by leveraging the package infrastructure to output the executed commands for every packages.

Quoted 5 lines

Also, for packages that get patches applied by buildroot, you must make sure that the tarballs for those packages do contain the pathced code, or that the patches are bundled as well. From what I see, you currently only copy the downladed tarballs. Of course, if buildroot is also copied to the output/legal-info/sources/ the patches will be there.

I agree with Yann: I think we should package buildroot itself as well.

In fact, I think we should:
- make distclean
- create the manifest
- download all needed sources
- run a pre-legal-package script for customization
- create a .tar file with the whole

The pre-legal-package script (whatever the name) is similar to the post-build script, and allows projects to modify certain things. For example, modify the defconfig to disable some proprietary things that are not useful or usable by the customer.

Quoted 8 lines

Also, I think the DL_DIR setting should be modified so that it points to the location where the source tarballs are downloaded. This way, the customer can directly use these sources from that location when re-building buildroot.

I haven't done a technical review of your patches, but I went through them and agree with the principle. Thanks for posting them before the developer day, it will certainly help the discussion!

I think the best way is to just package BR itself in the legal-info subdir. I'll have to check if/how it is feasible.
I'd also copy the current .config, which IMHO is part of the "scripts used to control compilation".

OTOH I don't think a pre-legal-package script would be a good idea, as it would easily allow to trick and create a fake GPL-compliant release. In other words, what I use for building must go directly in the stuff to be released.

Quoted 9 lines

I think the best way is to just package BR itself in the legal-info subdir. I'll have to check if/how it is feasible.
I'd also copy the current .config, which IMHO is part of the "scripts used to control compilation".

OTOH I don't think a pre-legal-package script would be a good idea, as it would easily allow to trick and create a fake GPL-compliant release. In other words, what I use for building must go directly in the stuff to be released.

I don't think we should attempt a guaranteed GPL-compliant release. We have no control over what someone did with its buildroot repository, whether or not they modified the LICENSE variables etc. A malicious company will be able to create a non-compliant tarball in many ways. By modifying buildroot itself, by using a pre-legal-package script, but also by post-processing the tarball. It's not something we should try to guard against IMO.

Moreover, I think there are valid use cases. For example, in our case, we build a proprietary package from within buildroot. This means we need the sources available. A customer shouldn't get these sources. But our .config or defconfig does enable the package. As a result, if the customer does 'make', there will be an attempt to find the proprietary sources, and the build will fail.
A pre-legal-package script could make such modifications to the defconfig file: disable the proprietary packages.
Another use cas is where the pre-legal-package script could copy in binary proprietary applications from elsewhere.
Or add a README file specific for the project.
Or maybe modify the login banner to indicate in the target image that this is no official release, but one built by the customer. Or ...

None of these are attempts to trick the customer or to be deviant from GPL or other license obligations.

Quoted 35 lines · Thomas De Schampheleire

Quoted 10 lines

I think the best way is to just package BR itself in the legal-info subdir. I'll have to check if/how it is feasible.
I'd also copy the current .config, which IMHO is part of the "scripts used to control compilation".

OTOH I don't think a pre-legal-package script would be a good idea, as it would easily allow to trick and create a fake GPL-compliant release. In other words, what I use for building must go directly in the stuff to be released.

I don't think we should attempt a guaranteed GPL-compliant release. We have no control over what someone did with its buildroot repository, whether or not they modified the LICENSE variables etc. A malicious company will be able to create a non-compliant tarball in many ways. By modifying buildroot itself, by using a pre-legal-package script, but also by post-processing the tarball. It's not something we should try to guard against IMO.

Moreover, I think there are valid use cases. For example, in our case, we build a proprietary package from within buildroot. This means we need the sources available. A customer shouldn't get these sources. But our .config or defconfig does enable the package. As a result, if the customer does 'make', there will be an attempt to find the proprietary sources, and the build will fail.
A pre-legal-package script could make such modifications to the defconfig file: disable the proprietary packages.
Another use cas is where the pre-legal-package script could copy in binary proprietary applications from elsewhere.
Or add a README file specific for the project.
Or maybe modify the login banner to indicate in the target image that this is no official release, but one built by the customer. Or ...

Quoted 2 lines

None of these are attempts to trick the customer or to be deviant from GPL or other license obligations.

After having slept on it, and after your clarifications, I think you're probably right.

On one hand, it's not feasible to have Buildroot enforce a compliant release, and I would not take the risk of saying it does even if it did.

On the other hand, there are ways a pre-legal-package script may be useful, as your examples demonstrate.

By the law you must release the sources, but not necessarily make them straightforward to use. So to fulfill legal obligations you probably don't need such a script (provided that BR can package all the code that must be released).

But there are also FOSS-friendly device vendors that might want to sell a product with some proprietary software on them, while releasing the open-source part in a way that is fully usable except for the absence of the proprietary parts.

Bottom line: I think the script you suggest would be useful, but non strictly necessary. So I consider it something that might be added later, unless it's a simple addition to the current patchset. I'd prefer to keep the first patchset thin, for better review/discussion and to ease Peter's integration work.