[RFC] LICENSE fields and packages

[RFC] LICENSE fields and packages

[Koen Kooi]

Hi,

Jason Kridner pointed out that we don't actually put the license in the 
resulting packages, making it hard for finding the license if you only 
have a bunch or packages.

http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=e35d1ffad1553f259b084578992f15d10f590f98

Now the RFC part:

Allow URLs in the LICENSE field for lesser know licenses and/or 
click-through licenses.

Related to that: a class that would take a text file and generate a 
preinsts that shows the textfile and prompts to accept it (or not) would 
be awesome as well.

Back to the point: what do you think of allowing URLs in the LICENSE field?

regards,

Koen

Re: [RFC] LICENSE fields and packages

[Richard Purdie]

Hi,

On Tue, 2008-11-25 at 20:26 +0100, Koen Kooi wrote:
> Jason Kridner pointed out that we don't actually put the license in the 
> resulting packages, making it hard for finding the license if you only 
> have a bunch or packages.
> 
> http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=e35d1ffad1553f259b084578992f15d10f590f98
> 
> Now the RFC part:
> 
> Allow URLs in the LICENSE field for lesser know licenses and/or 
> click-through licenses.
> 
> Related to that: a class that would take a text file and generate a 
> preinsts that shows the textfile and prompts to accept it (or not) would 
> be awesome as well.
> 
> Back to the point: what do you think of allowing URLs in the LICENSE field?

I don't like the idea of urls in the field itself. I would however love
to see a class file with a list of valid field entries and corresponding
urls to the appropriate licence along with other information like
distributability. In due course I'd like to see that being mandatory for
new .bb files.

Cheers,

Richard

Re: [RFC] LICENSE fields and packages

[Koen Kooi]

On 25-11-08 20:54, Richard Purdie wrote:
> Hi,
>
> On Tue, 2008-11-25 at 20:26 +0100, Koen Kooi wrote:
>> Jason Kridner pointed out that we don't actually put the license in the
>> resulting packages, making it hard for finding the license if you only
>> have a bunch or packages.
>>
>> http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=e35d1ffad1553f259b084578992f15d10f590f98
>>
>> Now the RFC part:
>>
>> Allow URLs in the LICENSE field for lesser know licenses and/or
>> click-through licenses.
>>
>> Related to that: a class that would take a text file and generate a
>> preinsts that shows the textfile and prompts to accept it (or not) would
>> be awesome as well.
>>
>> Back to the point: what do you think of allowing URLs in the LICENSE field?
>
> I don't like the idea of urls in the field itself. I would however love
> to see a class file with a list of valid field entries and corresponding
> urls to the appropriate licence along with other information like
> distributability. In due course I'd like to see that being mandatory for
> new .bb files.

We can start by having insane.bbclass disallowing "Unknown" as license, 
which seems to be the default license in OE.

regards,

Koen

Re: [RFC] LICENSE fields and packages

[Marcin Juszkiewicz]

Tuesday 25 of November 2008 20:26:24 Koen Kooi napisał(a):

> Jason Kridner pointed out that we don't actually put the license in
> the resulting packages, making it hard for finding the license if you
> only have a bunch or packages.

Ugly we are.

> Now the RFC part:
>
> Allow URLs in the LICENSE field for lesser know licenses and/or
> click-through licenses.

> Related to that: a class that would take a text file and generate a
> preinsts that shows the textfile and prompts to accept it (or not)
> would be awesome as well.

Only if there will be a place on storage where informations which 
licenses user accepted would be kept - I do not like to click "Yes, I 
accept this license" 6 times on each system update.

You also have to think about graphical package managers here.

> Back to the point: what do you think of allowing URLs in the LICENSE
> field?

Show me code which will make use of it first? Why not add license to 
SRC_URI?

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://blog.haerwu.biz/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: [RFC] LICENSE fields and packages

[Koen Kooi]

On 25-11-08 21:13, Marcin Juszkiewicz wrote:
> Tuesday 25 of November 2008 20:26:24 Koen Kooi napisał(a):

>> Back to the point: what do you think of allowing URLs in the LICENSE
>> field?
>
> Show me code which will make use of it first? Why not add license to
> SRC_URI?

At this point it's not about code, it's about being able to show a legal 
department that the license is referenced in the package.

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.

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 as short term solution I'd like to be able to point to a url for the 
'licenses without a proper name' and for the long term have a proper, 
package format independant solution.

regards,

Koen

Re: [RFC] LICENSE fields and packages

[Marcin Juszkiewicz]

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.

> 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.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://blog.haerwu.biz/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: [RFC] LICENSE fields and packages

[Koen Kooi]

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

Re: [RFC] LICENSE fields and packages

[Marcin Juszkiewicz]

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?

> >> 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, 
-- 
JID:      hrw@jabber.org
Website:  http://blog.haerwu.biz/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: [RFC] LICENSE fields and packages

[Koen Kooi]

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,

Re: [RFC] LICENSE fields and packages

[Koen Kooi]

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?

Any objections to doing it this way till we have a proper bbclass?

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,

Re: [RFC] LICENSE fields and packages

[Phil Blundell]

On Wed, 2008-11-26 at 12:21 +0100, Koen Kooi wrote:
> > ${PN}-license package on which all entries from PACKAGES will RDEPEND?
> 
> Any objections to doing it this way till we have a proper bbclass?

I think this is a fine idea.  It should be a DISTRO opt-in choice, of
course, but I can't see any reason not to provide the facility.

p.

Re: [RFC] LICENSE fields and packages

[Koen Kooi]

On 26-11-08 12:31, Phil Blundell wrote:
> On Wed, 2008-11-26 at 12:21 +0100, Koen Kooi wrote:
>>> ${PN}-license package on which all entries from PACKAGES will RDEPEND?
>> Any objections to doing it this way till we have a proper bbclass?
>
> I think this is a fine idea.  It should be a DISTRO opt-in choice, of
> course, but I can't see any reason not to provide the facility.

My idea was to make it opt-in on a per package basis since DISTROs can 
include base-files-doc for the most commit licenses (GPL, MIT, BSD, etc).

regards,

Koen

Re: [RFC] LICENSE fields and packages

[Phil Blundell]

On Wed, 2008-11-26 at 13:27 +0100, Koen Kooi wrote:
> On 26-11-08 12:31, Phil Blundell wrote:
> > On Wed, 2008-11-26 at 12:21 +0100, Koen Kooi wrote:
> >>> ${PN}-license package on which all entries from PACKAGES will RDEPEND?
> >> Any objections to doing it this way till we have a proper bbclass?
> >
> > I think this is a fine idea.  It should be a DISTRO opt-in choice, of
> > course, but I can't see any reason not to provide the facility.
> 
> My idea was to make it opt-in on a per package basis since DISTROs can 
> include base-files-doc for the most commit licenses (GPL, MIT, BSD, etc).

Hm, right.  I guess the selection should be both per-package and
per-DISTRO.

How about allowing the DISTRO to specify a regexp for the licences that
it "knows about"; any package for which ${LICENSE} doesn't match the
regexp will get the ${PN}-license thing.  The default regexp would be
set to ".*" in bitbake.conf, in order to preserve the current behaviour
of not emitting any ${PN}-license; DISTROs that want to make use of the
new feature can set it to whatever they like.

p.

Re: [RFC] LICENSE fields and packages

[Koen Kooi]

On 26-11-08 14:57, Phil Blundell wrote:
> On Wed, 2008-11-26 at 13:27 +0100, Koen Kooi wrote:
>> On 26-11-08 12:31, Phil Blundell wrote:
>>> On Wed, 2008-11-26 at 12:21 +0100, Koen Kooi wrote:
>>>>> ${PN}-license package on which all entries from PACKAGES will RDEPEND?
>>>> Any objections to doing it this way till we have a proper bbclass?
>>> I think this is a fine idea.  It should be a DISTRO opt-in choice, of
>>> course, but I can't see any reason not to provide the facility.
>> My idea was to make it opt-in on a per package basis since DISTROs can
>> include base-files-doc for the most commit licenses (GPL, MIT, BSD, etc).
>
> Hm, right.  I guess the selection should be both per-package and
> per-DISTRO.
>
> How about allowing the DISTRO to specify a regexp for the licences that
> it "knows about"; any package for which ${LICENSE} doesn't match the
> regexp will get the ${PN}-license thing.  The default regexp would be
> set to ".*" in bitbake.conf, in order to preserve the current behaviour
> of not emitting any ${PN}-license; DISTROs that want to make use of the
> new feature can set it to whatever they like.

Sounds great.

regards,

Koen