Re: LICENSE field format

[Martyn Welch <martyn.welch@ge.com>]

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