legal-info: add option to store manifest in rootfs
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
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.
--- Config.in | 8 ++++++++ Makefile | 7 ++++++- 2 files changed, 14 insertions(+), 1 deletion(-)
Config.in +8 -0
@@ -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"
Makefile +6 -1
@@ -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) \
Signature · 1 line
2.14.1
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
Hi Yann,
Quoted 6 lines · 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...
Quoted 7 lines
Add an option to that effect.
Reported-by Florian Fainelli <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Florian Fainelli <[email protected]>Cc Luca Ceresoli <[email protected]>Cc Thomas Petazzoni <[email protected]>
Thanks for the quick patch!
Quoted 50 lines
--- Config.in | 8 ++++++++ Makefile | 7 ++++++- 2 files changed, 14 insertions(+), 1 deletion(-)Config.in +8
-0@@ -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"Makefile +6
-1@@ -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) \
Signature · 1 line
Florian
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
In reply to Yann E. MORINYann, Florian,
Quoted 6 lines · 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...
Quoted 7 lines
Add an option to that effect.
Reported-by Florian Fainelli <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Florian Fainelli <[email protected]>Cc Luca Ceresoli <[email protected]>Cc Thomas Petazzoni <[email protected]>
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
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
Quoted 11 lines · Thomas Petazzoni
Yann, Florian,
Quoted 8 lines · 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.
Quoted 8 lines
Quoted 5 lines
Reported-by Florian Fainelli <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Florian Fainelli <[email protected]>Cc Luca Ceresoli <[email protected]>Cc Thomas Petazzoni <[email protected]>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.
Quoted 14 lines
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
Signature · 1 line
Florian
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
Florian, All,
On 2018-04-27 09:14 -0700, Florian Fainelli spake thusly:
Quoted 18 lines · Thomas Petazzoni
Quoted 17 lines
Yann, Florian,
Quoted 13 lines · 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 <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Florian Fainelli <[email protected]>Cc Luca Ceresoli <[email protected]>Cc Thomas Petazzoni <[email protected]>
Quoted 6 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 16 lines
Quoted 13 lines
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
Signature · 1 line
Florian
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
Quoted 24 lines · Yann E. MORIN
Florian, All,
On 2018-04-27 09:14 -0700, Florian Fainelli spake thusly:
Quoted 21 lines · Thomas Petazzoni
Quoted 19 lines
Yann, Florian,
Quoted 6 lines · 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...
Quoted 7 lines
Add an option to that effect.
Reported-by Florian Fainelli <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Florian Fainelli <[email protected]>Cc Luca Ceresoli <[email protected]>Cc Thomas Petazzoni <[email protected]>I'd like to challenge the usefulness of having the manifest on the target. What is the actual use case ?
Quoted 6 lines
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 21 lines
Regards,
Yann E. MORIN.Quoted 16 lines
Quoted 13 lines
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
Signature · 1 line
Florian
Signature · 1 line
Florian
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
In reply to Thomas PetazzoniHi,
Quoted 17 lines · Thomas Petazzoni
Yann, Florian,
Quoted 6 lines · 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...
Quoted 7 lines
Add an option to that effect.
Reported-by Florian Fainelli <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Florian Fainelli <[email protected]>Cc Luca Ceresoli <[email protected]>Cc Thomas Petazzoni <[email protected]>
Quoted 7 lines
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.
Quoted 3 lines
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?
Signature · 1 line
Luca
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
Quoted 51 lines · Luca Ceresoli
Hi,
Quoted 17 lines · Thomas Petazzoni
Yann, Florian,
Quoted 6 lines · 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...
Quoted 7 lines
Add an option to that effect.
Reported-by Florian Fainelli <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Florian Fainelli <[email protected]>Cc Luca Ceresoli <[email protected]>Cc Thomas Petazzoni <[email protected]>Quoted 7 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Signature · 1 line
Florian
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
In reply to Luca CeresoliLuca, All,
On 2018-04-27 18:33 +0200, Luca Ceresoli spake thusly:
Quoted 19 lines · Thomas Petazzoni
Quoted 18 lines · Yann E. MORIN
Quoted 6 lines
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...
Quoted 7 lines
Add an option to that effect.
Reported-by Florian Fainelli <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Florian Fainelli <[email protected]>Cc Luca Ceresoli <[email protected]>Cc Thomas Petazzoni <[email protected]>I'd like to challenge the usefulness of having the manifest on the target. What is the actual use case ?
Quoted 7 lines
Quoted 4 lines
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. ;-)
Quoted 2 lines
And I even think the entire world is partially wrong, but that's another story. :)
Someone needs to take their pills... ;-)
Quoted 7 lines
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.
Quoted 3 lines
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.
Quoted 18 lines
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.
Quoted 3 lines
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?
Signature · 1 line
Luca
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
Hi,
Quoted 30 lines · Yann E. MORIN
Luca, All,
On 2018-04-27 18:33 +0200, Luca Ceresoli spake thusly:
Quoted 19 lines · Thomas Petazzoni
Quoted 18 lines · Yann E. MORIN
Quoted 6 lines
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...
Quoted 7 lines
Add an option to that effect.
Reported-by Florian Fainelli <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Florian Fainelli <[email protected]>Cc Luca Ceresoli <[email protected]>Cc Thomas Petazzoni <[email protected]>I'd like to challenge the usefulness of having the manifest on the target. What is the actual use case ?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 6 lines
I sent the patch as RFC. ;-)
Quoted 2 lines
And I even think the entire world is partially wrong, but that's another story. :)
Someone needs to take their pills... ;-)
%-)
Quoted 18 lines
Quoted 7 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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! :-]
Signature · 1 line
Luca
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
Quoted 72 lines · Luca Ceresoli
Hi,
Quoted 30 lines · Yann E. MORIN
Luca, All,
On 2018-04-27 18:33 +0200, Luca Ceresoli spake thusly:
Quoted 19 lines · Thomas Petazzoni
Quoted 18 lines · Yann E. MORIN
Quoted 6 lines
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...
Quoted 7 lines
Add an option to that effect.
Reported-by Florian Fainelli <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>Cc Florian Fainelli <[email protected]>Cc Luca Ceresoli <[email protected]>Cc Thomas Petazzoni <[email protected]>I'd like to challenge the usefulness of having the manifest on the target. What is the actual use case ?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 6 lines
I sent the patch as RFC. ;-)
Quoted 2 lines
And I even think the entire world is partially wrong, but that's another story. :)
Someone needs to take their pills... ;-)
%-)
Quoted 18 lines
Quoted 7 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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).
Quoted 6 lines
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!
Signature · 1 line
Florian
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
Hello,
Quoted 9 lines · Florian Fainelli
Quoted 9 lines
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.
Quoted 5 lines
Quoted 1 line
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
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
Quoted 19 lines · Thomas Petazzoni
Hello,
Quoted 9 lines · Florian Fainelli
Quoted 9 lines
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.Quoted 5 lines
Quoted 1 line
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!
Quoted 6 lines
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.
Signature · 1 line
Florian
RFC PATCH 1/1 legal-info: add option to store manifest in rootfs
In reply to Florian FainelliFlorian, All,
On 2018-04-27 14:39 -0700, Florian Fainelli spake thusly:
[--SNIP--]
Quoted 2 lines
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! ;-]
Quoted 2 lines
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_INFOI've slightly tested that, and it seems to be working...
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'