Re: [RFC] LICENSE fields and packages

[Koen Kooi <k.kooi@student.utwente.nl>]

On 26-11-08 10:11, Marcin Juszkiewicz wrote:
> Tuesday 25 of November 2008 22:57:27 Koen Kooi napisał(a):
>> On 25-11-08 22:42, Marcin Juszkiewicz wrote:
>>> Tuesday 25 of November 2008 22:02:00 Koen Kooi napisał(a):
>
>>>> 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?
>
> ${PN}-license package on which all entries from PACKAGES will RDEPEND?

That doesn't put the license in the packages itself, so if I give you 
evil-binary_1.0_armv7a.ipk you still don't know what the license is.

What about a bbclass that iterates over every entry in PACKAGES and puts 
the license in ${datadir}/<pkgname>/LICENSE.txt?

regards,

Koen


>>>> 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?
>
> No, I mean that if license is not one of popular ones covered by
> base-files-doc or common-licenses package it should be added into OE
> metadata. Ok, it can be a bit of overkill adding all those 'povray',
> 'openssl' etc licenses but when we will end then it will be clear how
> each recipe is licensed.
>
> Regards,