[Buildroot] legal-info: multiple licenses separator

[Buildroot] legal-info: multiple licenses separator

[Thomas De Schampheleire]

Hi Luca, all,

FOO_LICENSE_FILES is a space-separated list according to the manual,
and the code correctly reflects this.
The manual does not specify whether FOO_LICENSE is space-separated or
comma-separated, and the code has a mix of both. I think we should
clarify this and line up everything with the decision.

I believe the comma provides more clarity for complex licenses like
FOO_LICENSE = GPLv2+, GPLv2 (py-smbus)
I believe it is more clear here that GPLv2 applies to py-smbus, and
GPLv2+ to all the rest.

However, the comma conflicts with the comma separator of the CSV
manifest. This looks like:
"foo","1.2","GPLv2+, GPLv2 (py-smbus)","COPYING"
while the quotes probably make standard CSV imports work correctly,
basic command-line tools like cut won't because it would also split on
the intermediate comma. With awk you can split on "," and manually
remove the leading and trailing " on the line, but it's a bit more
complex.

I think that if we accept the comma in FOO_LICENSE, we should replace
the separator in the manifest with something else, for example a
semicolon ; which would not typically appear in any of the other
fields.

Thanks for your input,
Thomas

[Buildroot] legal-info: multiple licenses separator

[Luca Ceresoli]

Hi Thomas,

Thomas De Schampheleire wrote:
> Hi Luca, all,
>
> FOO_LICENSE_FILES is a space-separated list according to the manual,
> and the code correctly reflects this.
> The manual does not specify whether FOO_LICENSE is space-separated or
> comma-separated, and the code has a mix of both. I think we should
> clarify this and line up everything with the decision.

We agreed FOO_LICENSE is just a text string.
It should be formatted such that it is as far as possible concise,
informative and correct.

>
> I believe the comma provides more clarity for complex licenses like
> FOO_LICENSE = GPLv2+, GPLv2 (py-smbus)
> I believe it is more clear here that GPLv2 applies to py-smbus, and
> GPLv2+ to all the rest.

Yes, this is the most clear syntax to me, and IIRC we agreed to use
this in the past.

>
> However, the comma conflicts with the comma separator of the CSV
> manifest. This looks like:
> "foo","1.2","GPLv2+, GPLv2 (py-smbus)","COPYING"
> while the quotes probably make standard CSV imports work correctly,
> basic command-line tools like cut won't because it would also split on
> the intermediate comma. With awk you can split on "," and manually
> remove the leading and trailing " on the line, but it's a bit more
> complex.

Yeah, you definitely have a point.

>
> I think that if we accept the comma in FOO_LICENSE, we should replace
> the separator in the manifest with something else, for example a
> semicolon ; which would not typically appear in any of the other
> fields.

I'm OK with this change. Before that we'll have to fix a few packages 
though.

At a quick analysis it seems we have 7 packages with ';' in their _LICENSE:

   $ git grep -E '_LICENSE[^_].*;' -- package/  | wc -l
   7
   $

And one of them has both ';' and ',':

   $ git grep -hE '_LICENSE[^_].*;' -- package/|grep ,
   NODEJS_LICENSE = MIT (core code); MIT, Apache and BSD family licenses 
(Bundled components)
   $

-- 
Luca

[Buildroot] legal-info: multiple licenses separator

[Thomas De Schampheleire]

Hi Luca,

On Wed, Oct 9, 2013 at 3:28 PM, Luca Ceresoli <luca@lucaceresoli.net> wrote:

>> I think that if we accept the comma in FOO_LICENSE, we should replace
>> the separator in the manifest with something else, for example a
>> semicolon ; which would not typically appear in any of the other
>> fields.
>
>
> I'm OK with this change. Before that we'll have to fix a few packages
> though.
>
> At a quick analysis it seems we have 7 packages with ';' in their _LICENSE:
>
>   $ git grep -E '_LICENSE[^_].*;' -- package/  | wc -l
>   7
>   $
>
> And one of them has both ';' and ',':
>
>   $ git grep -hE '_LICENSE[^_].*;' -- package/|grep ,
>   NODEJS_LICENSE = MIT (core code); MIT, Apache and BSD family licenses
> (Bundled components)
>   $

Damn :)

Here are the ; ones, with a proposed change:

package/lttng-babeltrace/lttng-babeltrace.mk
-LTTNG_BABELTRACE_LICENSE = MIT; LGPLv2 for include/babeltrace/list.h;
GPLv3+ for formats/ctf/metadata/ctf-parser.h
+LTTNG_BABELTRACE_LICENSE = MIT, LGPLv2 (include/babeltrace/list.h),
GPLv3+ (formats/ctf/metadata/ctf-parser.h)

package/nodejs/nodejs.mk
NODEJS_LICENSE = MIT (core code); MIT, Apache and BSD family licenses
(Bundled components)

package/redis/redis.mk
REDIS_LICENSE = BSD-3c (core); MIT and BSD family licenses (Bundled components)

These two are the mixed case, not sure what the best way is. Maybe use -- ?

package/lttng-tools/lttng-tools.mk
-LTTNG_TOOLS_LICENSE = GPLv2; LGPLv2.1 for include/lttng/* and
src/lib/lttng-ctl/*
+LTTNG_TOOLS_LICENSE = GPLv2, LGPLv2.1 (include/lttng/, src/lib/lttng-ctl/)

package/lttng-modules/lttng-modules.mk
-LTTNG_MODULES_LICENSE = LGPLv2.1/GPLv2 for kernel modules; MIT for
lib/bitfield.h and lib/prio_heap/*
+LTTNG_MODULES_LICENSE = LGPLv2.1/GPLv2 (kernel modules), MIT
(lib/bitfield.h, lib/prio_heap/)

package/liburcu/liburcu.mk
-LIBURCU_LICENSE = LGPLv2.1+ for the library; MIT-like license for few
source files listed in LICENSE
+LIBURCU_LICENSE = LGPLv2.1+ (library), MIT-like (a few source files
listed in LICENSE)

package/lttng-libust/lttng-libust.mk
-LTTNG_LIBUST_LICENSE = LGPLv2.1; GPLv2 for lttng-gen-tp and ust-ctl
+LTTNG_LIBUST_LICENSE = LGPLv2.1, GPLv2 (lttng-gen-tp, ust-ctl)

Best regards,
Thomas

[Buildroot] legal-info: multiple licenses separator

[Arnout Vandecappelle]

On 10/09/13 15:55, Thomas De Schampheleire wrote:
> Hi Luca,
>
> On Wed, Oct 9, 2013 at 3:28 PM, Luca Ceresoli <luca@lucaceresoli.net> wrote:
>
>>> I think that if we accept the comma in FOO_LICENSE, we should replace
>>> the separator in the manifest with something else, for example a
>>> semicolon ; which would not typically appear in any of the other
>>> fields.
>>
>>
>> I'm OK with this change. Before that we'll have to fix a few packages
>> though.
>>
>> At a quick analysis it seems we have 7 packages with ';' in their _LICENSE:
>>
>>    $ git grep -E '_LICENSE[^_].*;' -- package/  | wc -l
>>    7
>>    $
>>
>> And one of them has both ';' and ',':
>>
>>    $ git grep -hE '_LICENSE[^_].*;' -- package/|grep ,
>>    NODEJS_LICENSE = MIT (core code); MIT, Apache and BSD family licenses
>> (Bundled components)
>>    $
>
> Damn :)
>
> Here are the ; ones, with a proposed change:
>
> package/lttng-babeltrace/lttng-babeltrace.mk
> -LTTNG_BABELTRACE_LICENSE = MIT; LGPLv2 for include/babeltrace/list.h;
> GPLv3+ for formats/ctf/metadata/ctf-parser.h
> +LTTNG_BABELTRACE_LICENSE = MIT, LGPLv2 (include/babeltrace/list.h),
> GPLv3+ (formats/ctf/metadata/ctf-parser.h)
>
> package/nodejs/nodejs.mk
> NODEJS_LICENSE = MIT (core code); MIT, Apache and BSD family licenses
> (Bundled components)
>
> package/redis/redis.mk
> REDIS_LICENSE = BSD-3c (core); MIT and BSD family licenses (Bundled components)
>
> These two are the mixed case, not sure what the best way is. Maybe use -- ?
>
> package/lttng-tools/lttng-tools.mk
> -LTTNG_TOOLS_LICENSE = GPLv2; LGPLv2.1 for include/lttng/* and
> src/lib/lttng-ctl/*
> +LTTNG_TOOLS_LICENSE = GPLv2, LGPLv2.1 (include/lttng/, src/lib/lttng-ctl/)
>
> package/lttng-modules/lttng-modules.mk
> -LTTNG_MODULES_LICENSE = LGPLv2.1/GPLv2 for kernel modules; MIT for
> lib/bitfield.h and lib/prio_heap/*
> +LTTNG_MODULES_LICENSE = LGPLv2.1/GPLv2 (kernel modules), MIT
> (lib/bitfield.h, lib/prio_heap/)
>
> package/liburcu/liburcu.mk
> -LIBURCU_LICENSE = LGPLv2.1+ for the library; MIT-like license for few
> source files listed in LICENSE
> +LIBURCU_LICENSE = LGPLv2.1+ (library), MIT-like (a few source files
> listed in LICENSE)
>
> package/lttng-libust/lttng-libust.mk
> -LTTNG_LIBUST_LICENSE = LGPLv2.1; GPLv2 for lttng-gen-tp and ust-ctl
> +LTTNG_LIBUST_LICENSE = LGPLv2.1, GPLv2 (lttng-gen-tp, ust-ctl)

  I thought you wanted to avoid commas? :-)  Anyway, I disagree with your 
cut argument: cut -d \" -f 6 should do the trick for you.

  If we are formalizing this more, then I'd like to point out that we in 
fact need three types of separators:

* between different components (e.g. core vs. bundled components in the 
nodejs example above);

* between different licenses that all apply to a single component 
(usually because they reuse source code from different sources, cfr. 
tcpdump);

* between different licenses that the user can choose for a single component.


  The distinction between the first two is a little bit vague. I think 
for buildroot, the important aspect is if they can still be part of 
separate programs once we've installed the package on the target. 
Concretely: it's a separate component if it's installed as a separate 
library in staging.


  However, perhaps we should take a step back on the legal info ofr a 
minute. Considering the number of corrections we have to make to it, and 
taking into account that we never check if it's still valid after version 
bumps, I wonder how useful our license manifest really is. In the end, 
your legal department will still need to check the correctness of the 
license information... Collecting the sources and the LICENSE_FILES _is_ 
really useful, but the specified licenses are only indicative. So I 
wouldn't spend too much time on formalizing it.


  Also, if we're going to formalize it more, perhaps we should consider 
moving to a real formal specification, e.g. spdx. That may make if 
possible in the future that a tool can at least verify the license 
information we provide.


  Regards,
  Arnout

-- 
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] legal-info: multiple licenses separator

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Thu, 10 Oct 2013 08:44:31 +0200, Arnout Vandecappelle wrote:

> > package/lttng-libust/lttng-libust.mk
> > -LTTNG_LIBUST_LICENSE = LGPLv2.1; GPLv2 for lttng-gen-tp and ust-ctl
> > +LTTNG_LIBUST_LICENSE = LGPLv2.1, GPLv2 (lttng-gen-tp, ust-ctl)
> 
>   I thought you wanted to avoid commas? :-)  Anyway, I disagree with your 
> cut argument: cut -d \" -f 6 should do the trick for you.

No, I don't think Thomas wanted to avoid commas, on the contrary. He
wanted to *allow* commas in the <pkg>_LICENSE variable, and to do this,
was proposing to change the CSV separator from comma to something else.

>   However, perhaps we should take a step back on the legal info ofr a 
> minute. Considering the number of corrections we have to make to it, and 
> taking into account that we never check if it's still valid after version 
> bumps, I wonder how useful our license manifest really is. In the end, 
> your legal department will still need to check the correctness of the 
> license information... Collecting the sources and the LICENSE_FILES _is_ 
> really useful, but the specified licenses are only indicative. So I 
> wouldn't spend too much time on formalizing it.

I do understand these arguments, but I continue to believe that the
license information is useful. If your legal department checks this,
and reports to you that there is a mistake, then you will send a patch
to Buildroot. If everybody does that, the licensing informations get
more and more correct and accurate. Pretty much like bugs in software
tend to progressively disappear as more and more people use the
software.

As an example, the berkeleydb bump from version 5 to 6 was done without
the appropriate license information change. But not later than one or
two days later, somebody else noticed that and the situation is in the
process of being fixed.

Also, remember that not all companies have legal departments. Many
small to medium size businesses do embedded Linux products. And for
them, having a license manifest that is 98% accurate is a lot better
than having no license manifest at all.

There may be some inaccuracies in the license informations that we
have, but generally, at least the information of whether the component
is under a non-copyleft or a copyleft license is correct, and this is
what matters most in my opinion to achieve basic license compliance.

>   Also, if we're going to formalize it more, perhaps we should consider 
> moving to a real formal specification, e.g. spdx. That may make if 
> possible in the future that a tool can at least verify the license 
> information we provide.

I do agree that having a look at SPDX is interesting. They define a
formal list of licenses (https://spdx.org/licenses/). However, I don't
know how/if they formalized how to specify which license applies to
which specific component inside a given package.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] legal-info: multiple licenses separator

[Thomas De Schampheleire]

Hi,

On Thu, Oct 10, 2013 at 9:53 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Arnout Vandecappelle,
>
> On Thu, 10 Oct 2013 08:44:31 +0200, Arnout Vandecappelle wrote:
>
>> > package/lttng-libust/lttng-libust.mk
>> > -LTTNG_LIBUST_LICENSE = LGPLv2.1; GPLv2 for lttng-gen-tp and ust-ctl
>> > +LTTNG_LIBUST_LICENSE = LGPLv2.1, GPLv2 (lttng-gen-tp, ust-ctl)
>>
>>   I thought you wanted to avoid commas? :-)  Anyway, I disagree with your
>> cut argument: cut -d \" -f 6 should do the trick for you.
>
> No, I don't think Thomas wanted to avoid commas, on the contrary. He
> wanted to *allow* commas in the <pkg>_LICENSE variable, and to do this,
> was proposing to change the CSV separator from comma to something else.
>
>>   However, perhaps we should take a step back on the legal info ofr a
>> minute. Considering the number of corrections we have to make to it, and
>> taking into account that we never check if it's still valid after version
>> bumps, I wonder how useful our license manifest really is. In the end,
>> your legal department will still need to check the correctness of the
>> license information... Collecting the sources and the LICENSE_FILES _is_
>> really useful, but the specified licenses are only indicative. So I
>> wouldn't spend too much time on formalizing it.
>
> I do understand these arguments, but I continue to believe that the
> license information is useful. If your legal department checks this,
> and reports to you that there is a mistake, then you will send a patch
> to Buildroot. If everybody does that, the licensing informations get
> more and more correct and accurate. Pretty much like bugs in software
> tend to progressively disappear as more and more people use the
> software.
>
> As an example, the berkeleydb bump from version 5 to 6 was done without
> the appropriate license information change. But not later than one or
> two days later, somebody else noticed that and the situation is in the
> process of being fixed.
>
> Also, remember that not all companies have legal departments. Many
> small to medium size businesses do embedded Linux products. And for
> them, having a license manifest that is 98% accurate is a lot better
> than having no license manifest at all.
>
> There may be some inaccuracies in the license informations that we
> have, but generally, at least the information of whether the component
> is under a non-copyleft or a copyleft license is correct, and this is
> what matters most in my opinion to achieve basic license compliance.
>
>>   Also, if we're going to formalize it more, perhaps we should consider
>> moving to a real formal specification, e.g. spdx. That may make if
>> possible in the future that a tool can at least verify the license
>> information we provide.
>
> I do agree that having a look at SPDX is interesting. They define a
> formal list of licenses (https://spdx.org/licenses/). However, I don't
> know how/if they formalized how to specify which license applies to
> which specific component inside a given package.

The SPDX specification is here:
https://spdx.org/sites/spdx/files/spdx-1.1.pdf

It seems you can either put the file in flat format (I think most
suitable for buildroot) and in RDF format (less readable if you ask
me).

In principle I'm positive towards moving to SPDX, but I have no prior
experience with it.

Best regards,
Thomas