* [Buildroot] legal-info: multiple licenses separator @ 2013-10-09 7:23 Thomas De Schampheleire 2013-10-09 13:28 ` Luca Ceresoli 0 siblings, 1 reply; 6+ messages in thread From: Thomas De Schampheleire @ 2013-10-09 7:23 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] legal-info: multiple licenses separator 2013-10-09 7:23 [Buildroot] legal-info: multiple licenses separator Thomas De Schampheleire @ 2013-10-09 13:28 ` Luca Ceresoli 2013-10-09 13:55 ` Thomas De Schampheleire 0 siblings, 1 reply; 6+ messages in thread From: Luca Ceresoli @ 2013-10-09 13:28 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] legal-info: multiple licenses separator 2013-10-09 13:28 ` Luca Ceresoli @ 2013-10-09 13:55 ` Thomas De Schampheleire 2013-10-10 6:44 ` Arnout Vandecappelle 0 siblings, 1 reply; 6+ messages in thread From: Thomas De Schampheleire @ 2013-10-09 13:55 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] legal-info: multiple licenses separator 2013-10-09 13:55 ` Thomas De Schampheleire @ 2013-10-10 6:44 ` Arnout Vandecappelle 2013-10-10 7:53 ` Thomas Petazzoni 0 siblings, 1 reply; 6+ messages in thread From: Arnout Vandecappelle @ 2013-10-10 6:44 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] legal-info: multiple licenses separator 2013-10-10 6:44 ` Arnout Vandecappelle @ 2013-10-10 7:53 ` Thomas Petazzoni 2013-10-10 8:17 ` Thomas De Schampheleire 0 siblings, 1 reply; 6+ messages in thread From: Thomas Petazzoni @ 2013-10-10 7:53 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] legal-info: multiple licenses separator 2013-10-10 7:53 ` Thomas Petazzoni @ 2013-10-10 8:17 ` Thomas De Schampheleire 0 siblings, 0 replies; 6+ messages in thread From: Thomas De Schampheleire @ 2013-10-10 8:17 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-10-10 8:17 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-10-09 7:23 [Buildroot] legal-info: multiple licenses separator Thomas De Schampheleire 2013-10-09 13:28 ` Luca Ceresoli 2013-10-09 13:55 ` Thomas De Schampheleire 2013-10-10 6:44 ` Arnout Vandecappelle 2013-10-10 7:53 ` Thomas Petazzoni 2013-10-10 8:17 ` Thomas De Schampheleire
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox