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 [email protected] | M2 3AB VAT:GB 927559189 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
