[Buildroot] Standardizing format for specifying license(s)

[Buildroot] Standardizing format for specifying license(s)

[Rahul Bedarkar]

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

[Buildroot] Standardizing format for specifying license(s)

[Alexander Dahl]

Hei hei, 

Am 2016-01-15 12:53, schrieb Rahul Bedarkar:
> 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

-- 
?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 ***

[Buildroot] Standardizing format for specifying license(s)

[Thomas Petazzoni]

Alexander,

On Fri, 15 Jan 2016 14:12:47 +0100, Alexander Dahl wrote:

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Standardizing format for specifying license(s)

[Luca Ceresoli]

Hi,

Thomas Petazzoni wrote:
> Alexander,
>
> On Fri, 15 Jan 2016 14:12:47 +0100, Alexander Dahl wrote:
>
>> 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?

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.

-- 
Luca

[Buildroot] Standardizing format for specifying license(s)

[Arnout Vandecappelle]

On 15-01-16 14:51, Thomas Petazzoni wrote:
> Alexander,
> 
> On Fri, 15 Jan 2016 14:12:47 +0100, Alexander Dahl wrote:
> 
>> 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?

 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.

> 
> 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.

> 
> 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


> 
> Examples:
> 
> MII_DIAG_LICENSE = GPL # No version specified
> tslib/tslib.mk:TSLIB_LICENSE = GPL, LGPL
> 
> Best regards,
> 
> Thomas
> 


-- 
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

[Buildroot] Standardizing format for specifying license(s)

[Thomas Petazzoni]

Rahul,

On Fri, 15 Jan 2016 17:23:34 +0530, Rahul Bedarkar wrote:

> 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.

> * 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)

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).

> * 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 MIT
GNU_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 "/".

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Standardizing format for specifying license(s)

[Rahul Bedarkar]

Hi Thomas,

On Friday 15 January 2016 07:14 PM, Thomas Petazzoni wrote:
> Rahul,
>
> On Fri, 15 Jan 2016 17:23:34 +0530, Rahul Bedarkar wrote:
>
>> 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.
>

OK. I will send patch against manual.

>> * 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 MIT
> GNU_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 "/".
>

Yes. Agree.

>> 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

[Buildroot] Standardizing format for specifying license(s)

[Thomas Petazzoni]

Rahul,

On Fri, 15 Jan 2016 20:00:31 +0530, Rahul Bedarkar wrote:

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com