Standardizing format for specifying license(s)
Hi all,
In package.mk, as of now, there is no standard format for specifying licenses under which package is released. In some cases we comma separate licenses while in others space separated list. It's difficult to parse manifest file generated by legal-info target in such cases. One of requirements of parsing manifest file would be checking for license compatibility of dependent packages.
With that in mind, I'm proposing following initial format which allows ease in parsing manifest file.
* If package is licensed under multiple licenses e.g. bluez5_utils libraries and programs are licensed under different licenses. In such case, comma separate licenses e.g. BLUEZ5_UTILS_LICENSE=GPLv2+, LGPLv2.1+ If there is clear distinction between which component is licensed
under what license then annotate the license with libraries or programs or others keywords. e.g. BLUEZ5_UTILS_LICENSE=GPLv2+ (programs), LGPLv2.1+ (libraries)
* If package is dual licensed e.g. dbus then slash separate licenses. e.g. DBUS_LICENSE = AFLv2.1 / GPLv2+
There was effort to comma separate licenses
https://git.busybox.net/buildroot/log/?qt=grep&q=comma+separate+licenses
but just comma separating licenses in many cases is not correct from point of different licensing terms and parsing manifest file.
Any suggestions and thoughts are welcome.
Regards,
Rahul
Hei hei,
Am 2016-01-15 12:53, schrieb Rahul Bedarkar:
Quoted 1 line
Any suggestions and thoughts are welcome.
If not already done, I would suggest to have those license stuff compatible with SPDX [1]. I noticed license names in at least some packages are not the same as the identifiers on
https://spdx.org/licenses/ ? so if someone wants to generate SPDX stuff from a buildroot project, it maybe would be better to have a format for names and delimiters which make it easier towards SPDX package data.
Greets
Alex
[1] https://en.wikipedia.org/wiki/Software_Package_Data_Exchange
Signature · 4 lines
?With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.? (Jean-Luc Picard, quoting Judge Aaron Satie) *** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 ***
Alexander,
Quoted 6 lines · Alexander Dahl
If not already done, I would suggest to have those license stuff compatible with SPDX [1]. I noticed license names in at least some packages are not the same as the identifiers on
https://spdx.org/licenses/ ? so if someone wants to generate SPDX stuff from a buildroot project, it maybe would be better to have a format for names and delimiters which make it easier towards SPDX package data.
We normally try to use the SPDX license code, at least for "new" licenses (i.e licenses for which we don't yet have a single Buildroot package under that license). However, for the first licenses (like GPL, LGPL, etc.), we have started using an encoding that is not the one from SPDX. I would personally be in favor to move to SPDX license codes everywhere, but that would break things for people that are currently parsing our license information. Is this reasonable to do nonetheless?
The Buildroot documentation already has a license of license abbreviations:
https://buildroot.org/downloads/manual/manual.html#legal-info-list-licenses.
Note that http://spdx.org/sites/spdx/files/SPDX-2.0.pdf, page 82 and 83, has a description of a syntax for composite license expressions.
One case that SPDX doesn't allow to encode is "GPL" or "LGPL", i.e the cases where the software is said to be licensed under the GPL or LGPL, but without any version information. Yes this sucks because in practice it means you don't know the corresponding license text. But sometimes, this is the only information provided by the package source code.
Examples:
MII_DIAG_LICENSE = GPL # No version specified
tslib/tslib.mk:TSLIB_LICENSE = GPL, LGPL
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Hi,
Quoted 11 lines · Thomas Petazzoni
Alexander,
Quoted 6 lines · Alexander Dahl
If not already done, I would suggest to have those license stuff compatible with SPDX [1]. I noticed license names in at least some packages are not the same as the identifiers on
https://spdx.org/licenses/ ? so if someone wants to generate SPDX stuff from a buildroot project, it maybe would be better to have a format for names and delimiters which make it easier towards SPDX package data.
Quoted 7 lines
We normally try to use the SPDX license code, at least for "new" licenses (i.e licenses for which we don't yet have a single Buildroot package under that license). However, for the first licenses (like GPL, LGPL, etc.), we have started using an encoding that is not the one from SPDX. I would personally be in favor to move to SPDX license codes everywhere, but that would break things for people that are currently parsing our license information. Is this reasonable to do nonetheless?
Changing our format to comply with SPDX would be a good idea IMHO. If there's a well-defined and suitable standard out there it makes no sense to define another one.
Obviously I understand this might be annoying to somebody. But we never formally specified how "composite" licenses must be written and so, strictly speaking, any parsing activity not based on a reliable ground.
Signature · 1 line
Luca
Quoted 11 lines · Thomas Petazzoni
Alexander,
Quoted 6 lines · Alexander Dahl
If not already done, I would suggest to have those license stuff compatible with SPDX [1]. I noticed license names in at least some packages are not the same as the identifiers on
https://spdx.org/licenses/ ? so if someone wants to generate SPDX stuff from a buildroot project, it maybe would be better to have a format for names and delimiters which make it easier towards SPDX package data.
Quoted 7 lines
We normally try to use the SPDX license code, at least for "new" licenses (i.e licenses for which we don't yet have a single Buildroot package under that license). However, for the first licenses (like GPL, LGPL, etc.), we have started using an encoding that is not the one from SPDX. I would personally be in favor to move to SPDX license codes everywhere, but that would break things for people that are currently parsing our license information. Is this reasonable to do nonetheless?
Like Luca, I believe that we can still afford to change it now.
However, I'm not sure if it is worth it. SPDX short tags often look ugly
(BSD-3-Clause) and is anyway not sufficient (see below). For the list of tags we have, it's easy enough to convert it to the SPDX tag automatically by a post-processing tool if someone feels so inclined.
Quoted 7 lines
The Buildroot documentation already has a license of license abbreviations:
https://buildroot.org/downloads/manual/manual.html#legal-info-list-licenses.Note that http://spdx.org/sites/spdx/files/SPDX-2.0.pdf, page 82 and 83, has a description of a syntax for composite license expressions.
Unfortunately this syntax is a bit unwieldy. The license identifier must be
either one of the official ones, or something matching LicenseRef-[-+.a-zA-Z0-9]+ - for somewhat complicated licenses, it looks ugly. If it is a composite expression, it must be enclosed in (). And if there is an exception, it again must come from the official list - if it's not in the list, a new LicenseRef must be created. I could live with converting spaces to -, but anything beyond that is not a good idea IMHO.
Also, it doesn't allow to express some of the things we want to express in our
license statements. In particular, the "GPLv2+ (programs), LGPLv2 (library)" is not possible. In SPDX, every individual (source or binary) file is supposed to have a concluded license, and the concluded license of the package is the thing that applies when all files are distributed together.
So I don't think we should go for fully formal SPDX, and I see little advantage
in choosing something that resembles formal SPDX but is not quite it. I think that for someone who uses SPDX, the licensing info we give is never anything more than a hint so there is no need to make it almost-SPDX.
Bottom line: I'm completely in-line with the OP's proposal, as amended by
ThomasP (/ -> or). And I'm open to converting some or all existing tags to the SPDX ones.
Quoted 6 lines
One case that SPDX doesn't allow to encode is "GPL" or "LGPL", i.e the cases where the software is said to be licensed under the GPL or LGPL, but without any version information. Yes this sucks because in practice it means you don't know the corresponding license text. But sometimes, this is the only information provided by the package source code.
Yeah, so that would have to become LicenseRef-GPL...
Regards,
Arnout
Quoted 10 lines
Examples:
MII_DIAG_LICENSE= GPL # No version specified
tslib/tslib.mk:TSLIB_LICENSE = GPL, LGPLBest regards,
Thomas
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
Rahul,
Quoted 6 lines · Rahul Bedarkar
In package.mk, as of now, there is no standard format for specifying licenses under which package is released. In some cases we comma separate licenses while in others space separated list. It's difficult to parse manifest file generated by legal-info target in such cases. One of requirements of parsing manifest file would be checking for license compatibility of dependent packages.
Makes sense. If you want to formalize the format for the <pkg>_LICENSE variable, then what I would suggest is that you submit some patches against the Buildroot manual, which is the ultimate reference for such things. Then we can comment on the patch itself, and progressively agree on defining the appropriate format, in a way that can directly be merged into the documentation once a consensus has been reached.
Quoted 7 lines
* If package is licensed under multiple licenses e.g.
bluez5_utilslibraries and programs are licensed under different licenses. In such case, comma separate licenses e.g. BLUEZ5_UTILS_LICENSE=GPLv2+, LGPLv2.1+ If there is clear distinction between which component is licensed
under what license then annotate the license with libraries or programs or others keywords. e.g. BLUEZ5_UTILS_LICENSE=GPLv2+ (programs), LGPLv2.1+ (libraries)
No problem with that, this is normally what we are already doing (except of course for a few non-conforming packages that may remain after Gustavo's cleanup on this topic).
Quoted 2 lines
* If package is dual licensed e.g. dbus then slash separate licenses. e.g.
DBUS_LICENSE= AFLv2.1 / GPLv2+
We normally use "or" in this case:
CPPDB_LICENSE = Boost-v1.0 or MITGNU_EFI_LICENSE = BSD-3c and/or GPLv2+ (gnuefi), BSD-3c (efilib) LIBICAL_LICENSE = MPLv1.0 or LGPLv2.1
etc.
To me, using a "or" makes it really explicit, much more than a "/".
Quoted 4 lines
There was effort to comma separate licenses
https://git.busybox.net/buildroot/log/?qt=grep&q=comma+separate+licenses
but just comma separating licenses in many cases is not correct from point of different licensing terms and parsing manifest file.
Why ? This effort done by Gustavo was only to replace cases where different parts of the package are covered by different licenses, and the changes done by Gustavo completely match point (1) of your specific above.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Hi Thomas,
Quoted 11 lines · Thomas Petazzoni
Rahul,
Quoted 6 lines · Rahul Bedarkar
In package.mk, as of now, there is no standard format for specifying licenses under which package is released. In some cases we comma separate licenses while in others space separated list. It's difficult to parse manifest file generated by legal-info target in such cases. One of requirements of parsing manifest file would be checking for license compatibility of dependent packages.
Quoted 7 lines
Makes sense. If you want to formalize the format for the <pkg>_LICENSE variable, then what I would suggest is that you submit some patches against the Buildroot manual, which is the ultimate reference for such things. Then we can comment on the patch itself, and progressively agree on defining the appropriate format, in a way that can directly be merged into the documentation once a consensus has been reached.
OK. I will send patch against manual.
Quoted 5 lines
Quoted 2 lines
* If package is dual licensed e.g. dbus then slash separate licenses. e.g.
DBUS_LICENSE= AFLv2.1 / GPLv2+We normally use "or" in this case:
Quoted 8 lines
CPPDB_LICENSE= Boost-v1.0 or MITGNU_EFI_LICENSE= BSD-3c and/or GPLv2+ (gnuefi), BSD-3c (efilib)LIBICAL_LICENSE= MPLv1.0 or LGPLv2.1etc.
To me, using a "or" makes it really explicit, much more than a "/".
Yes. Agree.
Quoted 9 lines
Quoted 4 lines
There was effort to comma separate licenses
https://git.busybox.net/buildroot/log/?qt=grep&q=comma+separate+licenses
but just comma separating licenses in many cases is not correct from point of different licensing terms and parsing manifest file.Why ? This effort done by Gustavo was only to replace cases where different parts of the package are covered by different licenses, and the changes done by Gustavo completely match point (1) of your specific above.
Yes, it matches with point (1). I think one exception is dbus which has licenses comma separated but it's dual licensed.
Overall it looks like, what I am proposing is already in place but there are some non conforming packages and it's not documented.
Regards,
Rahul
Rahul,
Quoted 2 lines · Rahul Bedarkar
Overall it looks like, what I am proposing is already in place but there are some non conforming packages and it's not documented.
Absolutely. And it definitely makes sense to document it properly, and then to fix the non-conforming packages.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com