LICENSE field format

LICENSE field format

[Denys Dmytriyenko]

All,

We've had a number of discussions on the license matter recently. Trying to 
unify those brings us to the question of the LICENSE field format in recipes. 
As some projects are dual/triple licensed or use multiple licenses at the same 
time, it becomes hard to specify it all in the LICENSE field, especially when 
there are no rules defined. We do have several different formats used to 
separate multiple licenses, which is quite confusing and doesn't make it clear 
whether licenses are AND-ed or OR-ed (I know those are not legal terms, but 
for the purpose of this discussion that's fine :)) Here are some examples:

LICENSE = "License1 License2"
LICENSE = "License1|License2"
LICENSE = "License1, License2"
LICENSE = "License1+License2"
LICENSE = "License1/License2"

LICENSE = "Very Long License Name"
LICENSE = "License with some exceptions"

To make matters worse, src_distribute.bbclass splits the field at spaces and 
creates directories for each token. So, for the last two examples above, we 
end up with 4 directories for every license - each word is a separate 
directory...

I'd like to raise this issue and start a discussion on unifying the LICENSE 
field format (and fixing src_distribute.bbclass accordingly). Would be nice to 
collect some ideas here on the maillist and/or discuss it further during OEDEM 
next week. Please feel free to comment.

-- 
Denys

Re: LICENSE field format

[Maupin, Chase]

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Denys Dmytriyenko
> Sent: Wednesday, October 20, 2010 3:38 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] LICENSE field format
> 
> All,
> 
> We've had a number of discussions on the license matter recently. Trying
> to
> unify those brings us to the question of the LICENSE field format in
> recipes.
> As some projects are dual/triple licensed or use multiple licenses at the
> same
> time, it becomes hard to specify it all in the LICENSE field, especially
> when
> there are no rules defined. We do have several different formats used to
> separate multiple licenses, which is quite confusing and doesn't make it
> clear
> whether licenses are AND-ed or OR-ed (I know those are not legal terms,
> but
> for the purpose of this discussion that's fine :)) Here are some examples:
> 
> LICENSE = "License1 License2"
> LICENSE = "License1|License2"
> LICENSE = "License1, License2"
> LICENSE = "License1+License2"
> LICENSE = "License1/License2"
> 
> LICENSE = "Very Long License Name"
> LICENSE = "License with some exceptions"

I would vote for something along the following lines:

LICENSE = "License1|License2" 
	- This means the code is licensed under the terms of both licenses

LICENSE = "License1,License2"
	- This means the code can use either license exclusively

in the src_distribute class spaces should be replaced with "-"s.  Of course, this could lead to licenses like "GPLv3+-with-GCC-RLE".

We should avoid separating licenses with "/" because that will mess up the directory structure or "+" because that would be confusing when + is also used to mean "or later" for some licenses like the GPL.

> 
> To make matters worse, src_distribute.bbclass splits the field at spaces
> and
> creates directories for each token. So, for the last two examples above,
> we
> end up with 4 directories for every license - each word is a separate
> directory...
> 
> I'd like to raise this issue and start a discussion on unifying the
> LICENSE
> field format (and fixing src_distribute.bbclass accordingly). Would be
> nice to
> collect some ideas here on the maillist and/or discuss it further during
> OEDEM
> next week. Please feel free to comment.
> 
> --
> Denys
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: LICENSE field format

[Frans Meulenbroeks]

2010/10/20 Maupin, Chase <chase.maupin@ti.com>:
>> -----Original Message-----
>> From: openembedded-devel-bounces@lists.openembedded.org
>> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
>> Denys Dmytriyenko
>> Sent: Wednesday, October 20, 2010 3:38 PM
>> To: openembedded-devel@lists.openembedded.org
>> Subject: [oe] LICENSE field format
>>
>> All,
>>
>> We've had a number of discussions on the license matter recently. Trying
>> to
>> unify those brings us to the question of the LICENSE field format in
>> recipes.
>> As some projects are dual/triple licensed or use multiple licenses at the
>> same
>> time, it becomes hard to specify it all in the LICENSE field, especially
>> when
>> there are no rules defined. We do have several different formats used to
>> separate multiple licenses, which is quite confusing and doesn't make it
>> clear
>> whether licenses are AND-ed or OR-ed (I know those are not legal terms,
>> but
>> for the purpose of this discussion that's fine :)) Here are some examples:
>>
>> LICENSE = "License1 License2"
>> LICENSE = "License1|License2"
>> LICENSE = "License1, License2"
>> LICENSE = "License1+License2"
>> LICENSE = "License1/License2"
>>
>> LICENSE = "Very Long License Name"
>> LICENSE = "License with some exceptions"
>
> I would vote for something along the following lines:
>
> LICENSE = "License1|License2"
>        - This means the code is licensed under the terms of both licenses
>
> LICENSE = "License1,License2"
>        - This means the code can use either license exclusively
>
> in the src_distribute class spaces should be replaced with "-"s.  Of course, this could lead to licenses like "GPLv3+-with-GCC-RLE".
>
> We should avoid separating licenses with "/" because that will mess up the directory structure or "+" because that would be confusing when + is also used to mean "or later" for some licenses like the GPL.
>
>
As a non-native speaker I'm lost wrt the | and , usage.
e.g. perl says either artistic or gplv1+.
I'd say either the difference between | and , needs to be more clearly
explained or we need to have one form.

If spaces are an issue we could use _
I agree with Chase that using + should be restricted to mean "or later"

Frans

Re: LICENSE field format

[Denys Dmytriyenko]

On Wed, Oct 20, 2010 at 04:06:10PM -0500, Maupin, Chase wrote:
> > -----Original Message-----
> > From: openembedded-devel-bounces@lists.openembedded.org
> > [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> > Denys Dmytriyenko
> > Sent: Wednesday, October 20, 2010 3:38 PM
> > To: openembedded-devel@lists.openembedded.org
> > Subject: [oe] LICENSE field format
> > 
> > All,
> > 
> > We've had a number of discussions on the license matter recently. Trying
> > to
> > unify those brings us to the question of the LICENSE field format in
> > recipes.
> > As some projects are dual/triple licensed or use multiple licenses at the
> > same
> > time, it becomes hard to specify it all in the LICENSE field, especially
> > when
> > there are no rules defined. We do have several different formats used to
> > separate multiple licenses, which is quite confusing and doesn't make it
> > clear
> > whether licenses are AND-ed or OR-ed (I know those are not legal terms,
> > but
> > for the purpose of this discussion that's fine :)) Here are some examples:
> > 
> > LICENSE = "License1 License2"
> > LICENSE = "License1|License2"
> > LICENSE = "License1, License2"
> > LICENSE = "License1+License2"
> > LICENSE = "License1/License2"
> > 
> > LICENSE = "Very Long License Name"
> > LICENSE = "License with some exceptions"
> 
> I would vote for something along the following lines:
> 
> LICENSE = "License1|License2" 
> 	- This means the code is licensed under the terms of both licenses
> 
> LICENSE = "License1,License2"
> 	- This means the code can use either license exclusively
> 
> in the src_distribute class spaces should be replaced with "-"s.  Of course, 
> this could lead to licenses like "GPLv3+-with-GCC-RLE".
> 
> We should avoid separating licenses with "/" because that will mess up the 
> directory structure or "+" because that would be confusing when + is also 
> used to mean "or later" for some licenses like the GPL.

Chase,

I feel like those are just crutches and not the real solution to the problem. 
We should fix src_distribute class to work with the format we choose and not 
try to make the code happy by inventing workarounds in the format. In other 
words - the priority is to define a scalable, future-proof and easy to 
understand and follow format for the LICENSE field. And then make 
src_distribute class to behave accordingly - we can escape any special 
characters in there to make proper directory names, once we decide how to 
split the license field on individual items...

-- 
Denys

> > To make matters worse, src_distribute.bbclass splits the field at spaces
> > and
> > creates directories for each token. So, for the last two examples above,
> > we
> > end up with 4 directories for every license - each word is a separate
> > directory...
> > 
> > I'd like to raise this issue and start a discussion on unifying the
> > LICENSE
> > field format (and fixing src_distribute.bbclass accordingly). Would be
> > nice to
> > collect some ideas here on the maillist and/or discuss it further during
> > OEDEM
> > next week. Please feel free to comment.
> > 
> > --
> > Denys
> > 
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: LICENSE field format

[Frans Meulenbroeks]

2010/10/20 Denys Dmytriyenko <denis@denix.org>:
> All,
>
> We've had a number of discussions on the license matter recently. Trying to
> unify those brings us to the question of the LICENSE field format in recipes.
> As some projects are dual/triple licensed or use multiple licenses at the same
> time, it becomes hard to specify it all in the LICENSE field, especially when
> there are no rules defined. We do have several different formats used to
> separate multiple licenses, which is quite confusing and doesn't make it clear
> whether licenses are AND-ed or OR-ed (I know those are not legal terms, but
> for the purpose of this discussion that's fine :)) Here are some examples:
>
> LICENSE = "License1 License2"
> LICENSE = "License1|License2"
> LICENSE = "License1, License2"
> LICENSE = "License1+License2"
> LICENSE = "License1/License2"
>
> LICENSE = "Very Long License Name"
> LICENSE = "License with some exceptions"
>
> To make matters worse, src_distribute.bbclass splits the field at spaces and
> creates directories for each token. So, for the last two examples above, we
> end up with 4 directories for every license - each word is a separate
> directory...
>
> I'd like to raise this issue and start a discussion on unifying the LICENSE
> field format (and fixing src_distribute.bbclass accordingly). Would be nice to
> collect some ideas here on the maillist and/or discuss it further during OEDEM
> next week. Please feel free to comment.
>
> --
> Denys

What do others do?
I know debian has a license file. (and actually that could probably be
a good source of info to set our LICENSE field)

Frans

Re: LICENSE field format

[Denys Dmytriyenko]

On Wed, Oct 20, 2010 at 11:17:29PM +0200, Frans Meulenbroeks wrote:
> 2010/10/20 Denys Dmytriyenko <denis@denix.org>:
> > All,
> >
> > We've had a number of discussions on the license matter recently. Trying to
> > unify those brings us to the question of the LICENSE field format in recipes.
> > As some projects are dual/triple licensed or use multiple licenses at the same
> > time, it becomes hard to specify it all in the LICENSE field, especially when
> > there are no rules defined. We do have several different formats used to
> > separate multiple licenses, which is quite confusing and doesn't make it clear
> > whether licenses are AND-ed or OR-ed (I know those are not legal terms, but
> > for the purpose of this discussion that's fine :)) Here are some examples:
> >
> > LICENSE = "License1 License2"
> > LICENSE = "License1|License2"
> > LICENSE = "License1, License2"
> > LICENSE = "License1+License2"
> > LICENSE = "License1/License2"
> >
> > LICENSE = "Very Long License Name"
> > LICENSE = "License with some exceptions"
> >
> > To make matters worse, src_distribute.bbclass splits the field at spaces and
> > creates directories for each token. So, for the last two examples above, we
> > end up with 4 directories for every license - each word is a separate
> > directory...
> >
> > I'd like to raise this issue and start a discussion on unifying the LICENSE
> > field format (and fixing src_distribute.bbclass accordingly). Would be nice to
> > collect some ideas here on the maillist and/or discuss it further during OEDEM
> > next week. Please feel free to comment.
> >
> > --
> > Denys
> 
> What do others do?
> I know debian has a license file. (and actually that could probably be
> a good source of info to set our LICENSE field)

Debian uses "or" plus "and" keywords:

License: GPL-2+ or Artistic-2.0
License: GPL-2+ and BSD

Also, comma is used to change the priority of "or/and":

License: GPL-2+ or Artistic-2.0, and BSD

Licenses with spaces are allowed:

License: GPL-2+ with OpenSSL exception

And, BTW, "GPL version 2 or later" is specified as "GPL-2+". The format is 
detailed here:

http://dep.debian.net/deps/dep5/

I guess, we can try to adopt the "and/or" syntax...

-- 
Denys

Re: LICENSE field format

[Martyn Welch]

On 20/10/10 21:38, Denys Dmytriyenko wrote:
> All,
> 
> We've had a number of discussions on the license matter recently. Trying to 
> unify those brings us to the question of the LICENSE field format in recipes. 
> As some projects are dual/triple licensed or use multiple licenses at the same 
> time, it becomes hard to specify it all in the LICENSE field, especially when 
> there are no rules defined. We do have several different formats used to 
> separate multiple licenses, which is quite confusing and doesn't make it clear 
> whether licenses are AND-ed or OR-ed (I know those are not legal terms, but 
> for the purpose of this discussion that's fine :)) Here are some examples:
> 
> LICENSE = "License1 License2"
> LICENSE = "License1|License2"
> LICENSE = "License1, License2"
> LICENSE = "License1+License2"
> LICENSE = "License1/License2"
> 
> LICENSE = "Very Long License Name"
> LICENSE = "License with some exceptions"
> 
> To make matters worse, src_distribute.bbclass splits the field at spaces and 
> creates directories for each token. So, for the last two examples above, we 
> end up with 4 directories for every license - each word is a separate 
> directory...
> 
> I'd like to raise this issue and start a discussion on unifying the LICENSE 
> field format (and fixing src_distribute.bbclass accordingly). Would be nice to 
> collect some ideas here on the maillist and/or discuss it further during OEDEM 
> next week. Please feel free to comment.
> 

I think we can probably break this problem down into two parts:

1) Unifying the strings used to specify commonly used licenses, whilst
still providing enough flexibility to enter less common licenses.

2) Reliably itemizing a list of licenses, given 1)

Having spent some time recently working with python and knowing that
bitbake is essentially a python application, I can see how this has
shaped the bb recipe syntax. This to me suggests that part one may be
efficiently solved by allowing the LICENSE field to be either a string
or list (following python syntax). Therefore:

LICENSE = "License1"

or for recipes with multiple licenses:

LICENSE = ["License1", "Lisense2"]

As this separates each license into it's own string, it becomes easier
to parse the licenses as we no longer need to define extra special
characters to separate licenses.

I do feel that creating a set of standardised strings that can be used
to differentiate between common licenses (with a common approach to
specify versions and other modifciations) makes sense, there has already
seems to have been some consensus on the list about a format for at
least the GPL. Anything that is not recognized as a standardised string
can be considered as a non-standard license (or at least one that hasn't
yet been provided with a standardised form).

I think we should proceed as follows:

* The TSC need to decide first whether a mandated structure for the
license field is to be used in the future and to specify somewhere (such
as a location on the wiki) where this mandated structure will be formulated.

* Assuming that it is decided that this is required, anyone who is
interested can add their ideas there - even if it ends up as a wiki page
with multiple competing specifications.

* The TSC should then be called upon to make the a decision in relation
to the specifications laid out, with the option for more time to be
spent working on a merged specification, etc, which can then be looked
at again at a later date.

Martyn

-- 
Martyn Welch (Principal Software Engineer)   |   Registered in England and
GE Intelligent Platforms                     |   Wales (3828642) at 100
T +44(0)127322748                            |   Barbirolli Square,
Manchester,
E martyn.welch@ge.com                        |   M2 3AB  VAT:GB 927559189