[oe] LICENSE field format
Martyn Welch
martyn.welch at ge.com
Thu Oct 21 09:30:34 UTC 2010
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 at ge.com | M2 3AB VAT:GB 927559189
More information about the Openembedded-devel
mailing list