[oe] [RFC] LICENSE fields and packages

Koen Kooi k.kooi at student.utwente.nl
Tue Nov 25 21:57:27 UTC 2008


On 25-11-08 22:42, Marcin Juszkiewicz wrote:
> Tuesday 25 of November 2008 22:02:00 Koen Kooi napisał(a):
>
>> How would a non-OE user know that http://openembedded.org/dl/ICA2.txt
>> is the license? Shipping the license itself in the packages would be
>> better, but that will need a lot of thought,
>
>> since we can't have a 1000 packages shipping
>> /usr/share/licenses/GPLv2, and *all* packages from a recipe need a
>> license, even -doc, -dev -and -dbg.
>
> /usr/share/common-licenses/ is part of base-files-doc now and consists
> GPL, LGPL, BSD, Artistic and few other licenses. We can extend this list
> and create 'common-licenses' package which would be installed in each
> image.
>
>> The concrete problem I have is that I have a bunch of licenses that
>> don't have a name (not even inside the company that wrote them), so
>> my recipes have things like
>>
>> LICENSE = "proprietary binary"
>> LICENSE = "evil binary"
>
> So add license.txt into /usr/share/doc/${PN}/ with content of that
> package license. I have done few such packages during last year as some
> copyright holders gave permissions to distribute their stuff *ONLY* with
> attached license. This kind of stuff does not even need nothing new - it
> is just another file in SRC_URI.

I like that idea very much, but the license file will have to be in 
every entry in PACKAGES, so ${PN} won't work. Do you have a suggestion 
on how to handle that?

>> So as short term solution I'd like to be able to point to a url for
>> the 'licenses without a proper name'

> Yeah.. especially when license contents is available only in restricted
> area for which simple person can not get access (for example Marvell
> extranet). If there are packages which have own license then such
> license should be inside of package.

So you agree that in those situations we can point to an URL, but in 
other cases either use the name or include it in the package?

regards,

Koen





More information about the Openembedded-devel mailing list