[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Yann E. MORIN]

Some users want to be able to easily ship the manifest of the legal-info
directly in the target filesystem.

Those users currently hack their ways around, usign a post-build script
that calls back to generate legal-info; this is a bit hackish...

Add an option to that effect.

Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
 Config.in | 8 ++++++++
 Makefile  | 7 ++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/Config.in b/Config.in
index 62d2dc3473..d6a2c8930c 100644
--- a/Config.in
+++ b/Config.in
@@ -692,6 +692,14 @@ config BR2_REPRODUCIBLE
 	  This is labeled as an experimental feature, as not all
 	  packages behave properly to ensure reproducibility.
 
+config BR2_LEGAL_IN_TARGET
+	bool "Include legal-info manifest in target"
+	help
+	  If you say 'y' here, then the listing of all the packages
+	  included in the build, as well as their version, license(s),
+	  upstrem URL, etc.. will be stored in a manifest file in the
+	  rootfs, in the file: /usr/share/doc/legal-info/manifest.csv
+
 endmenu
 
 comment "Security Hardening Options"
diff --git a/Makefile b/Makefile
index 54f940659c..7bff89a36f 100644
--- a/Makefile
+++ b/Makefile
@@ -688,7 +688,7 @@ $(TARGETS_ROOTFS): target-finalize
 target-finalize: ROOTFS=
 
 .PHONY: target-finalize
-target-finalize: $(PACKAGES)
+target-finalize: $(PACKAGES) $(if $(BR2_LEGAL_IN_TARGET),legal-info)
 	@$(call MESSAGE,"Finalizing target directory")
 	# Check files that are touched by more than one package
 	./support/scripts/check-uniq-files -t target $(BUILD_DIR)/packages-file-list.txt
@@ -746,6 +746,11 @@ endif
 	@$(call MESSAGE,"Sanitizing RPATH in target tree")
 	$(TOPDIR)/support/scripts/fix-rpath target
 
+ifeq ($(BR2_LEGAL_IN_TARGET),y)
+	$(INSTALL) -D -m 0644 $(LEGAL_MANIFEST_CSV_TARGET) \
+		$(TARGET_DIR)/usr/share/doc/legal-info/$(notdir $(LEGAL_MANIFEST_CSV_TARGET))
+endif
+
 	@$(foreach d, $(call qstrip,$(BR2_ROOTFS_OVERLAY)), \
 		$(call MESSAGE,"Copying overlay $(d)"); \
 		rsync -a --ignore-times --keep-dirlinks $(RSYNC_VCS_EXCLUSIONS) \
-- 
2.14.1

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Florian Fainelli]

Hi Yann,

On 04/26/2018 12:32 PM, Yann E. MORIN wrote:
> Some users want to be able to easily ship the manifest of the legal-info
> directly in the target filesystem.
> 
> Those users currently hack their ways around, usign a post-build script
> that calls back to generate legal-info; this is a bit hackish...
> 
> Add an option to that effect.
> 
> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Luca Ceresoli <luca@lucaceresoli.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

Tested-by: Florian Fainelli <f.fainelli@gmail.com>

Thanks for the quick patch!

> ---
>  Config.in | 8 ++++++++
>  Makefile  | 7 ++++++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/Config.in b/Config.in
> index 62d2dc3473..d6a2c8930c 100644
> --- a/Config.in
> +++ b/Config.in
> @@ -692,6 +692,14 @@ config BR2_REPRODUCIBLE
>  	  This is labeled as an experimental feature, as not all
>  	  packages behave properly to ensure reproducibility.
>  
> +config BR2_LEGAL_IN_TARGET
> +	bool "Include legal-info manifest in target"
> +	help
> +	  If you say 'y' here, then the listing of all the packages
> +	  included in the build, as well as their version, license(s),
> +	  upstrem URL, etc.. will be stored in a manifest file in the
> +	  rootfs, in the file: /usr/share/doc/legal-info/manifest.csv
> +
>  endmenu
>  
>  comment "Security Hardening Options"
> diff --git a/Makefile b/Makefile
> index 54f940659c..7bff89a36f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -688,7 +688,7 @@ $(TARGETS_ROOTFS): target-finalize
>  target-finalize: ROOTFS=
>  
>  .PHONY: target-finalize
> -target-finalize: $(PACKAGES)
> +target-finalize: $(PACKAGES) $(if $(BR2_LEGAL_IN_TARGET),legal-info)
>  	@$(call MESSAGE,"Finalizing target directory")
>  	# Check files that are touched by more than one package
>  	./support/scripts/check-uniq-files -t target $(BUILD_DIR)/packages-file-list.txt
> @@ -746,6 +746,11 @@ endif
>  	@$(call MESSAGE,"Sanitizing RPATH in target tree")
>  	$(TOPDIR)/support/scripts/fix-rpath target
>  
> +ifeq ($(BR2_LEGAL_IN_TARGET),y)
> +	$(INSTALL) -D -m 0644 $(LEGAL_MANIFEST_CSV_TARGET) \
> +		$(TARGET_DIR)/usr/share/doc/legal-info/$(notdir $(LEGAL_MANIFEST_CSV_TARGET))
> +endif
> +
>  	@$(foreach d, $(call qstrip,$(BR2_ROOTFS_OVERLAY)), \
>  		$(call MESSAGE,"Copying overlay $(d)"); \
>  		rsync -a --ignore-times --keep-dirlinks $(RSYNC_VCS_EXCLUSIONS) \
> 


-- 
Florian

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Thomas Petazzoni]

Yann, Florian,

On Thu, 26 Apr 2018 21:32:52 +0200, Yann E. MORIN wrote:
> Some users want to be able to easily ship the manifest of the legal-info
> directly in the target filesystem.
> 
> Those users currently hack their ways around, usign a post-build script
> that calls back to generate legal-info; this is a bit hackish...
> 
> Add an option to that effect.
> 
> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Luca Ceresoli <luca@lucaceresoli.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

I'd like to challenge the usefulness of having the manifest on the
target. What is the actual use case ?

Indeed, for license compliance of copyleft license (i.e at least GPL,
LGPL), having the name of the software package, its version and its
license is not sufficient, you also need to provide the full
corresponding source code.

So what is the need for having just the manifest ? Obviously the
complexity of the patch is low, but it's yet another Config.in option,
so I'd like to be sure there is a real, useful use case for it.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Florian Fainelli]

On 04/27/2018 06:46 AM, Thomas Petazzoni wrote:
> Yann, Florian,
> 
> On Thu, 26 Apr 2018 21:32:52 +0200, Yann E. MORIN wrote:
>> Some users want to be able to easily ship the manifest of the legal-info
>> directly in the target filesystem.
>>
>> Those users currently hack their ways around, usign a post-build script
>> that calls back to generate legal-info; this is a bit hackish...
>>
>> Add an option to that effect.
>>
>> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
>> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>> Cc: Florian Fainelli <f.fainelli@gmail.com>
>> Cc: Luca Ceresoli <luca@lucaceresoli.net>
>> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> 
> I'd like to challenge the usefulness of having the manifest on the
> target. What is the actual use case ?

The use case is primarily to have the exact list of
software/versions/licenses to be displayed in e.g: an UI "legal
disclaimer" page and possibly use parts of the manifest to issue
appropriate warnings to developers that shipping a system with GPLv3
software packages may conflict with the security mechanisms deployed on
the device.

> 
> Indeed, for license compliance of copyleft license (i.e at least GPL,
> LGPL), having the name of the software package, its version and its
> license is not sufficient, you also need to provide the full
> corresponding source code.
> 
> So what is the need for having just the manifest ? Obviously the
> complexity of the patch is low, but it's yet another Config.in option,
> so I'd like to be sure there is a real, useful use case for it.
> 
> Thanks!
> 
> Thomas
> 

-- 
Florian

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Yann E. MORIN]

Florian, All,

On 2018-04-27 09:14 -0700, Florian Fainelli spake thusly:
> On 04/27/2018 06:46 AM, Thomas Petazzoni wrote:
> > Yann, Florian,
> > 
> > On Thu, 26 Apr 2018 21:32:52 +0200, Yann E. MORIN wrote:
> >> Some users want to be able to easily ship the manifest of the legal-info
> >> directly in the target filesystem.
> >>
> >> Those users currently hack their ways around, usign a post-build script
> >> that calls back to generate legal-info; this is a bit hackish...
> >>
> >> Add an option to that effect.
> >>
> >> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
> >> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> >> Cc: Florian Fainelli <f.fainelli@gmail.com>
> >> Cc: Luca Ceresoli <luca@lucaceresoli.net>
> >> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> > 
> > I'd like to challenge the usefulness of having the manifest on the
> > target. What is the actual use case ?
> 
> The use case is primarily to have the exact list of
> software/versions/licenses to be displayed in e.g: an UI "legal
> disclaimer" page

So, presumably you would also have that page display a URL where to find
all the rest of the legal-info, right?

This use-case is IMHO really valid: you want to inform the end user of
their rights, give the minimum relevant info, and point outside for the
big parts.

> and possibly use parts of the manifest to issue
> appropriate warnings to developers that shipping a system with GPLv3
> software packages may conflict with the security mechanisms deployed on
> the device.

There, I disagree. That should be part of a CI job to run legal-info for
each build, and parse the manifest to find things you don't like.

Regards,
Yann E. MORIN.

> > Indeed, for license compliance of copyleft license (i.e at least GPL,
> > LGPL), having the name of the software package, its version and its
> > license is not sufficient, you also need to provide the full
> > corresponding source code.
> > 
> > So what is the need for having just the manifest ? Obviously the
> > complexity of the patch is low, but it's yet another Config.in option,
> > so I'd like to be sure there is a real, useful use case for it.
> > 
> > Thanks!
> > 
> > Thomas
> > 
> 
> -- 
> Florian

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Luca Ceresoli]

Hi,

On 27/04/2018 15:46, Thomas Petazzoni wrote:
> Yann, Florian,
> 
> On Thu, 26 Apr 2018 21:32:52 +0200, Yann E. MORIN wrote:
>> Some users want to be able to easily ship the manifest of the legal-info
>> directly in the target filesystem.
>>
>> Those users currently hack their ways around, usign a post-build script
>> that calls back to generate legal-info; this is a bit hackish...
>>
>> Add an option to that effect.
>>
>> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
>> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>> Cc: Florian Fainelli <f.fainelli@gmail.com>
>> Cc: Luca Ceresoli <luca@lucaceresoli.net>
>> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> 
> I'd like to challenge the usefulness of having the manifest on the
> target. What is the actual use case ?
> 
> Indeed, for license compliance of copyleft license (i.e at least GPL,
> LGPL), having the name of the software package, its version and its
> license is not sufficient, you also need to provide the full
> corresponding source code.

I think this is partially wrong. I also think the patch is partially
wrong. And I even think the entire world is partially wrong, but that's
another story. :)

GPL asks (in certain cases) to display the copyright notice and the
license (or a link to it) (more or less) (and remember IANAL:). Android
phones are a good esample of it: in the last item of the last menu entry
of some obscure app there is an insanely long cat of license texts. One
might want to do a similar thing on a device with a suitable GUI. I
think this is a reasonable way to be compliant, although there are other
ways.

Hence this patch makes sense to me, but it is insufficient. It should
also store the license text in the rootfs, in order for a GUI
application to be able to load that text and visualize it.

Providing the full corresponding source code is a different topic IMO.
It is allowed by the GPL that the device does not contain it, and there
are obvious techincal motivations not to do so. But the license (that
one must make available) states one has the right of asking and
receiving the code. Continuing with the above example, the Android
phones do not contain the full source code.

> So what is the need for having just the manifest ? Obviously the
> complexity of the patch is low, but it's yet another Config.in option,
> so I'd like to be sure there is a real, useful use case for it.

As I said the patch (with additions) would make sense. I'm not saying it
should be applied, but we should provide users with an alternative. Uhm,
maybe one can do 'make legal-info; cp <legal-stuff> ${ROOTFS}/usr/share'
in a post-build script?

-- 
Luca

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Florian Fainelli]

On 04/27/2018 09:31 AM, Yann E. MORIN wrote:
> Florian, All,
> 
> On 2018-04-27 09:14 -0700, Florian Fainelli spake thusly:
>> On 04/27/2018 06:46 AM, Thomas Petazzoni wrote:
>>> Yann, Florian,
>>>
>>> On Thu, 26 Apr 2018 21:32:52 +0200, Yann E. MORIN wrote:
>>>> Some users want to be able to easily ship the manifest of the legal-info
>>>> directly in the target filesystem.
>>>>
>>>> Those users currently hack their ways around, usign a post-build script
>>>> that calls back to generate legal-info; this is a bit hackish...
>>>>
>>>> Add an option to that effect.
>>>>
>>>> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
>>>> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>>>> Cc: Florian Fainelli <f.fainelli@gmail.com>
>>>> Cc: Luca Ceresoli <luca@lucaceresoli.net>
>>>> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
>>>
>>> I'd like to challenge the usefulness of having the manifest on the
>>> target. What is the actual use case ?
>>
>> The use case is primarily to have the exact list of
>> software/versions/licenses to be displayed in e.g: an UI "legal
>> disclaimer" page
> 
> So, presumably you would also have that page display a URL where to find
> all the rest of the legal-info, right?

Yes.

> 
> This use-case is IMHO really valid: you want to inform the end user of
> their rights, give the minimum relevant info, and point outside for the
> big parts.

I think so too.

> 
>> and possibly use parts of the manifest to issue
>> appropriate warnings to developers that shipping a system with GPLv3
>> software packages may conflict with the security mechanisms deployed on
>> the device.
> 
> There, I disagree. That should be part of a CI job to run legal-info for
> each build, and parse the manifest to find things you don't like.

Well of course, but the idea is also to make sure that someone gets a
chance to see a warning if they accidentally decided to ship a
development rootfs to someone. Anyhoo, first use case described is the
intended one FWIW.

> 
> Regards,
> Yann E. MORIN.
> 
>>> Indeed, for license compliance of copyleft license (i.e at least GPL,
>>> LGPL), having the name of the software package, its version and its
>>> license is not sufficient, you also need to provide the full
>>> corresponding source code.
>>>
>>> So what is the need for having just the manifest ? Obviously the
>>> complexity of the patch is low, but it's yet another Config.in option,
>>> so I'd like to be sure there is a real, useful use case for it.
>>>
>>> Thanks!
>>>
>>> Thomas
>>>
>>
>> -- 
>> Florian
> 

-- 
Florian

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Florian Fainelli]

On 04/27/2018 09:33 AM, Luca Ceresoli wrote:
> Hi,
> 
> On 27/04/2018 15:46, Thomas Petazzoni wrote:
>> Yann, Florian,
>>
>> On Thu, 26 Apr 2018 21:32:52 +0200, Yann E. MORIN wrote:
>>> Some users want to be able to easily ship the manifest of the legal-info
>>> directly in the target filesystem.
>>>
>>> Those users currently hack their ways around, usign a post-build script
>>> that calls back to generate legal-info; this is a bit hackish...
>>>
>>> Add an option to that effect.
>>>
>>> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
>>> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>>> Cc: Florian Fainelli <f.fainelli@gmail.com>
>>> Cc: Luca Ceresoli <luca@lucaceresoli.net>
>>> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
>>
>> I'd like to challenge the usefulness of having the manifest on the
>> target. What is the actual use case ?
>>
>> Indeed, for license compliance of copyleft license (i.e at least GPL,
>> LGPL), having the name of the software package, its version and its
>> license is not sufficient, you also need to provide the full
>> corresponding source code.
> 
> I think this is partially wrong. I also think the patch is partially
> wrong. And I even think the entire world is partially wrong, but that's
> another story. :)
> 
> GPL asks (in certain cases) to display the copyright notice and the
> license (or a link to it) (more or less) (and remember IANAL:). Android
> phones are a good esample of it: in the last item of the last menu entry
> of some obscure app there is an insanely long cat of license texts. One
> might want to do a similar thing on a device with a suitable GUI. I
> think this is a reasonable way to be compliant, although there are other
> ways.
> 
> Hence this patch makes sense to me, but it is insufficient. It should
> also store the license text in the rootfs, in order for a GUI
> application to be able to load that text and visualize it.
> 
> Providing the full corresponding source code is a different topic IMO.
> It is allowed by the GPL that the device does not contain it, and there
> are obvious techincal motivations not to do so. But the license (that
> one must make available) states one has the right of asking and
> receiving the code. Continuing with the above example, the Android
> phones do not contain the full source code.
> 
>> So what is the need for having just the manifest ? Obviously the
>> complexity of the patch is low, but it's yet another Config.in option,
>> so I'd like to be sure there is a real, useful use case for it.
> 
> As I said the patch (with additions) would make sense. I'm not saying it
> should be applied, but we should provide users with an alternative. Uhm,
> maybe one can do 'make legal-info; cp <legal-stuff> ${ROOTFS}/usr/share'
> in a post-build script?

That is what I am currently doing, though I would rather see that as a
more global, and less platform specific option if there is usability for
other people.
-- 
Florian

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Yann E. MORIN]

Luca, All,

On 2018-04-27 18:33 +0200, Luca Ceresoli spake thusly:
> On 27/04/2018 15:46, Thomas Petazzoni wrote:
> > On Thu, 26 Apr 2018 21:32:52 +0200, Yann E. MORIN wrote:
> >> Some users want to be able to easily ship the manifest of the legal-info
> >> directly in the target filesystem.
> >>
> >> Those users currently hack their ways around, usign a post-build script
> >> that calls back to generate legal-info; this is a bit hackish...
> >>
> >> Add an option to that effect.
> >>
> >> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
> >> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> >> Cc: Florian Fainelli <f.fainelli@gmail.com>
> >> Cc: Luca Ceresoli <luca@lucaceresoli.net>
> >> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> > 
> > I'd like to challenge the usefulness of having the manifest on the
> > target. What is the actual use case ?
> > 
> > Indeed, for license compliance of copyleft license (i.e at least GPL,
> > LGPL), having the name of the software package, its version and its
> > license is not sufficient, you also need to provide the full
> > corresponding source code.
> 
> I think this is partially wrong. I also think the patch is partially
> wrong.

I sent the patch as RFC. ;-)

> And I even think the entire world is partially wrong, but that's
> another story. :)

Someone needs to take their pills... ;-)

> GPL asks (in certain cases) to display the copyright notice and the
> license (or a link to it) (more or less) (and remember IANAL:). Android
> phones are a good esample of it: in the last item of the last menu entry
> of some obscure app there is an insanely long cat of license texts. One
> might want to do a similar thing on a device with a suitable GUI. I
> think this is a reasonable way to be compliant, although there are other
> ways.

Yes, but on some devices, it may be very inconvenient to read the whole
stuff, and thus just the manifest plus an URL for the rest is probably
OK (not the letter of the licenses, but the spirit) And if that is the
only deviation from proper compliance and all the rest i OK, there is in
practive no issue.

> Hence this patch makes sense to me, but it is insufficient. It should
> also store the license text in the rootfs, in order for a GUI
> application to be able to load that text and visualize it.

For example, my TV set has a similarly long list of legalese, and I
once tried to browse it to the end. I bailed out after 5 minutes of
scrolling... It was basically taking ~1s to scroll every single line...
Having just the list (aka the manifest) plus the URL would be more
usable! ;-)

So I think that what Florian needs is acceptable.

But! IANAL.

Regards,
Yann E. MORIN.

> Providing the full corresponding source code is a different topic IMO.
> It is allowed by the GPL that the device does not contain it, and there
> are obvious techincal motivations not to do so. But the license (that
> one must make available) states one has the right of asking and
> receiving the code. Continuing with the above example, the Android
> phones do not contain the full source code.
> 
> > So what is the need for having just the manifest ? Obviously the
> > complexity of the patch is low, but it's yet another Config.in option,
> > so I'd like to be sure there is a real, useful use case for it.
> 
> As I said the patch (with additions) would make sense. I'm not saying it
> should be applied, but we should provide users with an alternative. Uhm,
> maybe one can do 'make legal-info; cp <legal-stuff> ${ROOTFS}/usr/share'
> in a post-build script?
> 
> -- 
> Luca

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Luca Ceresoli]

Hi,

On 27/04/2018 22:02, Yann E. MORIN wrote:
> Luca, All,
> 
> On 2018-04-27 18:33 +0200, Luca Ceresoli spake thusly:
>> On 27/04/2018 15:46, Thomas Petazzoni wrote:
>>> On Thu, 26 Apr 2018 21:32:52 +0200, Yann E. MORIN wrote:
>>>> Some users want to be able to easily ship the manifest of the legal-info
>>>> directly in the target filesystem.
>>>>
>>>> Those users currently hack their ways around, usign a post-build script
>>>> that calls back to generate legal-info; this is a bit hackish...
>>>>
>>>> Add an option to that effect.
>>>>
>>>> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
>>>> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>>>> Cc: Florian Fainelli <f.fainelli@gmail.com>
>>>> Cc: Luca Ceresoli <luca@lucaceresoli.net>
>>>> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
>>>
>>> I'd like to challenge the usefulness of having the manifest on the
>>> target. What is the actual use case ?
>>>
>>> Indeed, for license compliance of copyleft license (i.e at least GPL,
>>> LGPL), having the name of the software package, its version and its
>>> license is not sufficient, you also need to provide the full
>>> corresponding source code.
>>
>> I think this is partially wrong. I also think the patch is partially
>> wrong.
> 
> I sent the patch as RFC. ;-)
> 
>> And I even think the entire world is partially wrong, but that's
>> another story. :)
> 
> Someone needs to take their pills... ;-)

%-)

>> GPL asks (in certain cases) to display the copyright notice and the
>> license (or a link to it) (more or less) (and remember IANAL:). Android
>> phones are a good esample of it: in the last item of the last menu entry
>> of some obscure app there is an insanely long cat of license texts. One
>> might want to do a similar thing on a device with a suitable GUI. I
>> think this is a reasonable way to be compliant, although there are other
>> ways.
> 
> Yes, but on some devices, it may be very inconvenient to read the whole
> stuff, and thus just the manifest plus an URL for the rest is probably
> OK (not the letter of the licenses, but the spirit) And if that is the
> only deviation from proper compliance and all the rest i OK, there is in
> practive no issue.
> 
>> Hence this patch makes sense to me, but it is insufficient. It should
>> also store the license text in the rootfs, in order for a GUI
>> application to be able to load that text and visualize it.
> 
> For example, my TV set has a similarly long list of legalese, and I
> once tried to browse it to the end. I bailed out after 5 minutes of
> scrolling... It was basically taking ~1s to scroll every single line...
> Having just the list (aka the manifest) plus the URL would be more
> usable! ;-)
> 
> So I think that what Florian needs is acceptable.

Well, sure, it makes some sense _practically_, but not _legally_ AFAICU,
because to be compliant you still would need a written license statement
(e.g. in the printed user manual).

Do we want to support every way that makes sense? We have two at least:
store the manifest and store manifest + license text. If we want to
support both, maybe that would actually carry more complexity than
usefulness, I'm afraid.

But of course I might be partially wrong! :-]
-- 
Luca

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Florian Fainelli]

On 04/27/2018 02:23 PM, Luca Ceresoli wrote:
> Hi,
> 
> On 27/04/2018 22:02, Yann E. MORIN wrote:
>> Luca, All,
>>
>> On 2018-04-27 18:33 +0200, Luca Ceresoli spake thusly:
>>> On 27/04/2018 15:46, Thomas Petazzoni wrote:
>>>> On Thu, 26 Apr 2018 21:32:52 +0200, Yann E. MORIN wrote:
>>>>> Some users want to be able to easily ship the manifest of the legal-info
>>>>> directly in the target filesystem.
>>>>>
>>>>> Those users currently hack their ways around, usign a post-build script
>>>>> that calls back to generate legal-info; this is a bit hackish...
>>>>>
>>>>> Add an option to that effect.
>>>>>
>>>>> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
>>>>> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>>>>> Cc: Florian Fainelli <f.fainelli@gmail.com>
>>>>> Cc: Luca Ceresoli <luca@lucaceresoli.net>
>>>>> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
>>>>
>>>> I'd like to challenge the usefulness of having the manifest on the
>>>> target. What is the actual use case ?
>>>>
>>>> Indeed, for license compliance of copyleft license (i.e at least GPL,
>>>> LGPL), having the name of the software package, its version and its
>>>> license is not sufficient, you also need to provide the full
>>>> corresponding source code.
>>>
>>> I think this is partially wrong. I also think the patch is partially
>>> wrong.
>>
>> I sent the patch as RFC. ;-)
>>
>>> And I even think the entire world is partially wrong, but that's
>>> another story. :)
>>
>> Someone needs to take their pills... ;-)
> 
> %-)
> 
>>> GPL asks (in certain cases) to display the copyright notice and the
>>> license (or a link to it) (more or less) (and remember IANAL:). Android
>>> phones are a good esample of it: in the last item of the last menu entry
>>> of some obscure app there is an insanely long cat of license texts. One
>>> might want to do a similar thing on a device with a suitable GUI. I
>>> think this is a reasonable way to be compliant, although there are other
>>> ways.
>>
>> Yes, but on some devices, it may be very inconvenient to read the whole
>> stuff, and thus just the manifest plus an URL for the rest is probably
>> OK (not the letter of the licenses, but the spirit) And if that is the
>> only deviation from proper compliance and all the rest i OK, there is in
>> practive no issue.
>>
>>> Hence this patch makes sense to me, but it is insufficient. It should
>>> also store the license text in the rootfs, in order for a GUI
>>> application to be able to load that text and visualize it.
>>
>> For example, my TV set has a similarly long list of legalese, and I
>> once tried to browse it to the end. I bailed out after 5 minutes of
>> scrolling... It was basically taking ~1s to scroll every single line...
>> Having just the list (aka the manifest) plus the URL would be more
>> usable! ;-)
>>
>> So I think that what Florian needs is acceptable.
> 
> Well, sure, it makes some sense _practically_, but not _legally_ AFAICU,
> because to be compliant you still would need a written license statement
> (e.g. in the printed user manual).
> 
> Do we want to support every way that makes sense? We have two at least:
> store the manifest and store manifest + license text. If we want to
> support both, maybe that would actually carry more complexity than
> usefulness, I'm afraid.
> 
> But of course I might be partially wrong! :-]

Let's drop this, I was not thinking this would go into such a lengthy
discussion, I will keep the local hack I have with make legal-info in
post-build.sh. Thanks a lot for your help Yann!
-- 
Florian

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Thomas Petazzoni]

Hello,

On Fri, 27 Apr 2018 14:39:20 -0700, Florian Fainelli wrote:

> > Well, sure, it makes some sense _practically_, but not _legally_ AFAICU,
> > because to be compliant you still would need a written license statement
> > (e.g. in the printed user manual).
> > 
> > Do we want to support every way that makes sense? We have two at least:
> > store the manifest and store manifest + license text. If we want to
> > support both, maybe that would actually carry more complexity than
> > usefulness, I'm afraid.
> > 
> > But of course I might be partially wrong! :-]  
> 
> Let's drop this, I was not thinking this would go into such a lengthy
> discussion, I will keep the local hack I have with make legal-info in
> post-build.sh. Thanks a lot for your help Yann!

Well, could you share some details about your specific use-case ? As
explained by Luca, having just the list of software components and the
name of their license isn't enough, the complete license text is needed
for licence compliance.

Knowing this, what is the use-case for having just the manifest ?

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Yann E. MORIN]

Florian, All,

On 2018-04-27 14:39 -0700, Florian Fainelli spake thusly:
[--SNIP--]
> Let's drop this, I was not thinking this would go into such a lengthy
> discussion,

That's been just 4-5 mails so far. This is *far* from being a lengthy
discussion, especialy by Buildroot standards! ;-]

> I will keep the local hack I have with make legal-info in
> post-build.sh. Thanks a lot for your help Yann!

Alternatively, you can use a br2-external tree, with:

  - Config.in is empty

  - external.desc contains:
        name: LEGAL_IN_TARGET
        desc: Isntall legal-info in rootfs

  - external.mk contains something like:
        target-finalize: legal-info

        TARGET_FINALIZE_LEGAL_INFO_DIR = $(TARGET_DIR)/usr/share/legal-info

        define TARGET_FINALIZE_LEGAL_INFO
            $(INSTALL) -D -m 0644 $(LEGAL_MANIFEST_CSV_TARGET) \
                $(TARGET_FINALIZE_LEGAL_INFO_DIR)/$(notdir $(LEGAL_MANIFEST_CSV_TARGET))
            mkdir -p $(TARGET_FINALIZE_LEGAL_INFO_DIR)/licenses
            cp -a $(LICENSE_FILES_DIR_TARGET)/* \
                $(TARGET_FINALIZE_LEGAL_INFO_DIR)/licenses/
        endef
        TARGET_FINALIZE_HOOKS += TARGET_FINALIZE_LEGAL_INFO

I've slightly tested that, and it seems to be working...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs

[Florian Fainelli]

On 04/28/2018 03:20 AM, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 27 Apr 2018 14:39:20 -0700, Florian Fainelli wrote:
> 
>>> Well, sure, it makes some sense _practically_, but not _legally_ AFAICU,
>>> because to be compliant you still would need a written license statement
>>> (e.g. in the printed user manual).
>>>
>>> Do we want to support every way that makes sense? We have two at least:
>>> store the manifest and store manifest + license text. If we want to
>>> support both, maybe that would actually carry more complexity than
>>> usefulness, I'm afraid.
>>>
>>> But of course I might be partially wrong! :-]  
>>
>> Let's drop this, I was not thinking this would go into such a lengthy
>> discussion, I will keep the local hack I have with make legal-info in
>> post-build.sh. Thanks a lot for your help Yann!
> 
> Well, could you share some details about your specific use-case ? As
> explained by Luca, having just the list of software components and the
> name of their license isn't enough, the complete license text is needed
> for licence compliance.
> 
> Knowing this, what is the use-case for having just the manifest ?

The use case is to have an UI page which is able to list the different
packages included, their version, a link to their license as well as
their sources. This is by no means meant to be a lawyer proof license
compliance page, just something that can eventually be used as a
template to reach that goal.

You and others have convinced me into keeping this a local modification,
I see no point in continuing this discussion any further given it was
asked as seemingly naive question.
-- 
Florian