From: Denys Dmytriyenko <denis@denix.org>
To: openembedded-devel@lists.openembedded.org
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/2] recipes: fix LICENSE fields
Date: Thu, 12 May 2011 16:32:36 -0400 [thread overview]
Message-ID: <20110512203236.GE21678@denix.org> (raw)
In-Reply-To: <20110512182158.GA3162@jama.jama.net>
On Thu, May 12, 2011 at 08:21:58PM +0200, Martin Jansa wrote:
> On Thu, May 12, 2011 at 12:39:19PM -0400, Denys Dmytriyenko wrote:
> > On Tue, May 10, 2011 at 11:36:16AM +0200, Martin Jansa wrote:
> > > On Tue, May 10, 2011 at 10:28:15AM +0100, Phil Blundell wrote:
> > > > On Tue, 2011-05-10 at 09:39 +0200, Martin Jansa wrote:
> > > > > | /OE/tmpdir-shr/work/armv4t-oe-linux-gnueabi/pixman-0.22.0-r5.0/temp/run.SRC_DISTRIBUTECOMMAND.17340: line 95: /pixman: No such file or directory
> > > >
> > > > If '&' in ${LICENSE} is breaking SRC_DISTRIBUTECOMMAND then that
> > > > suggests there is a bug in that code (probably some sort of missing
> > > > quotes). Removing the &s might be a fine thing to do anyway, but it
> > > > would also be a good idea to track down and fix the underlying bug.
> > >
> > > it calls cd tmp/deploy/sources/$license/pixman
> > > where with $license == '&' (because LICENSE field is splitted by ' ' and
> > > then '|'), it ends doing cd on background and then complaing about /pixman
> > >
> > > Directory named & even when created with right backslash
> > > is still hard to use, so I think it would be better to have QA check
> > > that LICENSE field has sane value, even better when we have list of
> > > possible values etc.
> >
> > I would agree with Phil that fixing distribute_sources is required, but I'd go
> > even further as to say that the current implementation of distribute_sources
> > is quite bad. It splits the LICENSE field into tokens based on the wrong
> > assumptions that all the whitespaces are used to separate multiple licenses.
> > In other words, "Public Domain" is a valid license and shouldn't be replaced
> > with "PD". What are you going to do with "GPLv2+ w/ GCC RLE"? Which stands for
> > "GPL version 2 (or later) with GCC Runtime Library Exception" and is a valid
>
> > license with an exception... Sorry, but "GPL+libraryexception" is just bogus
> > (and it's not a personal remark - I do understand your constrains, see below).
>
> Agreed, but do you find
> LICENSE = "GPL + library exception"
LICENSE = "GPL w/ library exception"
> better?
>
> > I understand that distribute_sources is quite important and useful. So, maybe
> > the correct way is to adopt a proper and stricter syntax for the LICENSE
> > field, which uses some other characters to separate multiple licenses. Say,
> > something like ":" or "|" should work. Using "," would be even better, but I'm
>
> '|' is alredy used for split in distribute_sources, but I'm not sure if
> my interpretation that it means logical OR in LICENSE context is right
> (and space as logical AND).
Yes, I had already previously suggested using Debian's syntax for the license
field, which allows complex combinations, such as OR/AND:
http://thread.gmane.org/gmane.comp.handhelds.openembedded/38585/focus=38590
> > afraid it can easily be used inside the license name on its own... Basically,
> > something along the lines of "GPL:MIT:Public Domain:Texas A&M Proprietary" etc.
> >
> > Any comments or objections?
>
> oe-core does more with LICENSEs (like LIC_FILES_CHKSUMs and keeping
> common licenses in
> /OE/shr-core/openembedded-core/meta/files/common-licenses which could be
> used for QA check on LICENSE field) so I think it should be discussed on
> oe-core ML first and then use the same syntax in oe.dev or just switch
> to oe-core..
Yes, I'm quite aware of Yocto/oe-core handling of licenses and checksum
verification mechanism for them, but unfortunately we don't have that in
mainline classic OE... We could try backporting it from oe-core to classic OE
or just wait until with switch to oe-core completely. In that case I'd suggest
avoid mangling license fields just to satisfy broken distribute_sources...
--
Denys
next prev parent reply other threads:[~2011-05-12 20:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-10 7:39 [PATCH 1/2] recipes: fix LICENSE fields Martin Jansa
2011-05-10 7:39 ` [PATCH 2/2] recipes: drop '+' from " Martin Jansa
2011-05-10 8:01 ` Koen Kooi
2011-05-10 8:00 ` [PATCH 1/2] recipes: fix " Koen Kooi
2011-05-10 9:28 ` Phil Blundell
2011-05-10 9:36 ` Martin Jansa
2011-05-10 9:40 ` Phil Blundell
2011-05-12 16:39 ` Denys Dmytriyenko
2011-05-12 18:21 ` Martin Jansa
2011-05-12 20:32 ` Denys Dmytriyenko [this message]
2011-05-12 20:36 ` [OE-core] " Martin Jansa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110512203236.GE21678@denix.org \
--to=denis@denix.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox