looking for a bit more info on licensing certain recipe files

looking for a bit more info on licensing certain recipe files

[Robert P. J. Day]

  for the first time, i'm digging around in the docs for how to
properly license various types of recipes, so a couple simple
questions to start with, at least so i can make a first pass of
cleaning up some content in front of me.

  as we established recently, packagegroup files need no licensing,
the obvious observation being that they represent the collection of
licenses that comprise them. however, i notice that the
packagegroup.bbclass file does indeed define a default license:

  LICENSE ?= "MIT"

so not only does a packagegroup have a default (MIT) license, but it's
conditional suggesting one could give it a different license. what
other licenses would make sense for a packagegroup? I'm sticking with
the default that packagegroup recipe files need no LICENSE assignment,
but now i'm curious as to what other options there are (or perhaps
that that default assignment in packagegroup.bbclass is obsolete).

  the same sort of question can be asked about image files, including
the generic OE core-image*.bb recipe files. of all those current
core-image files:

  core-image-base.bb
  core-image-minimal.bb
  core-image-minimal-dev.bb
  core-image-minimal-initramfs.bb
  core-image-minimal-mtdutils.bb
  core-image-tiny-initramfs.bb

fail into two camps.

  the first sets a license, then inherits core-image:

    LICENSE = "MIT"
    inherit core-image

the second type simply "require"s one of the other recipe files so it
has no need to set its own license, as in core-image-minimal-dev.bb:

    require core-image-minimal.bb

similar to packagegroups, does a core-image recipe really need a
separate LICENSE setting, or could that be added to core-image.bbclass
to centralize it (if it's even needed at all)?

  finally, WRT .bbappend files, the original recipes will have their
own licenses and if the .bbappend file is doing nothing but adding
some configuration (you know, PACKAGECONFIG, EXTRA_OEMAKE, that sort
of thing), then there should be no need for licensing in the bbappend
file. does all this sound reasonable so far?

rday

Re: [yocto] looking for a bit more info on licensing certain recipe files

[Quentin Schulz]

Hi Robert,

On Tue, Apr 27, 2021 at 08:41:25AM -0400, Robert P. J. Day wrote:
> 
>   for the first time, i'm digging around in the docs for how to
> properly license various types of recipes, so a couple simple
> questions to start with, at least so i can make a first pass of
> cleaning up some content in front of me.
> 
>   as we established recently, packagegroup files need no licensing,
> the obvious observation being that they represent the collection of
> licenses that comprise them. however, i notice that the
> packagegroup.bbclass file does indeed define a default license:
> 
>   LICENSE ?= "MIT"
> 
> so not only does a packagegroup have a default (MIT) license, but it's
> conditional suggesting one could give it a different license. what
> other licenses would make sense for a packagegroup? I'm sticking with
> the default that packagegroup recipe files need no LICENSE assignment,
> but now i'm curious as to what other options there are (or perhaps
> that that default assignment in packagegroup.bbclass is obsolete).
> 

Wild guess: all packages need a license. MIT is quite permissive so safe
as a default?

>   the same sort of question can be asked about image files, including
> the generic OE core-image*.bb recipe files. of all those current
> core-image files:
> 
>   core-image-base.bb
>   core-image-minimal.bb
>   core-image-minimal-dev.bb
>   core-image-minimal-initramfs.bb
>   core-image-minimal-mtdutils.bb
>   core-image-tiny-initramfs.bb
> 
> fail into two camps.
> 
>   the first sets a license, then inherits core-image:
> 
>     LICENSE = "MIT"
>     inherit core-image
> 
> the second type simply "require"s one of the other recipe files so it
> has no need to set its own license, as in core-image-minimal-dev.bb:
> 
>     require core-image-minimal.bb
> 
> similar to packagegroups, does a core-image recipe really need a
> separate LICENSE setting, or could that be added to core-image.bbclass
> to centralize it (if it's even needed at all)?
> 

Don't know about this one but I guess it's some rest of the original
implementation where I guess everything needed a LICENSE?

I can only guess, but maybe this'll start a discussion :)

>   finally, WRT .bbappend files, the original recipes will have their
> own licenses and if the .bbappend file is doing nothing but adding
> some configuration (you know, PACKAGECONFIG, EXTRA_OEMAKE, that sort
> of thing), then there should be no need for licensing in the bbappend
> file. does all this sound reasonable so far?
> 

I wouldn't expect any bbappend to modify a package/recipe license
without changing the sources (version bump). But not much experience
with that, so might be a valid use case?

Cheers,
Quentin

Re: [yocto] looking for a bit more info on licensing certain recipe files

[Robert P. J. Day]

On Tue, 4 May 2021, Quentin Schulz wrote:

> Hi Robert,
>
> On Tue, Apr 27, 2021 at 08:41:25AM -0400, Robert P. J. Day wrote:
> >
> >   for the first time, i'm digging around in the docs for how to
> > properly license various types of recipes, so a couple simple
> > questions to start with, at least so i can make a first pass of
> > cleaning up some content in front of me.
> >
> >   as we established recently, packagegroup files need no
> > licensing, the obvious observation being that they represent the
> > collection of licenses that comprise them. however, i notice that
> > the packagegroup.bbclass file does indeed define a default
> > license:
> >
> >   LICENSE ?= "MIT"
> >
> > so not only does a packagegroup have a default (MIT) license, but
> > it's conditional suggesting one could give it a different license.
> > what other licenses would make sense for a packagegroup? I'm
> > sticking with the default that packagegroup recipe files need no
> > LICENSE assignment, but now i'm curious as to what other options
> > there are (or perhaps that that default assignment in
> > packagegroup.bbclass is obsolete).
>
> Wild guess: all packages need a license. MIT is quite permissive so
> safe as a default?

  superficially makes sense, except that a packagegroup does not
really define a "package". perhaps all *recipe* files need a license
but, again, it's not clear how a packagegroup license should percolate
down to the packages it contains. or how things would percolate up.

  suddenly, i want some coffee.

> >   the same sort of question can be asked about image files,
> > including the generic OE core-image*.bb recipe files. of all those
> > current core-image files:
> >
> >   core-image-base.bb
> >   core-image-minimal.bb
> >   core-image-minimal-dev.bb
> >   core-image-minimal-initramfs.bb
> >   core-image-minimal-mtdutils.bb
> >   core-image-tiny-initramfs.bb
> >
> > fail into two camps.
> >
> >   the first sets a license, then inherits core-image:
> >
> >     LICENSE = "MIT"
> >     inherit core-image
> >
> > the second type simply "require"s one of the other recipe files so it
> > has no need to set its own license, as in core-image-minimal-dev.bb:
> >
> >     require core-image-minimal.bb
> >
> > similar to packagegroups, does a core-image recipe really need a
> > separate LICENSE setting, or could that be added to core-image.bbclass
> > to centralize it (if it's even needed at all)?
> >
>
> Don't know about this one but I guess it's some rest of the original
> implementation where I guess everything needed a LICENSE?
>
> I can only guess, but maybe this'll start a discussion :)
>
> >   finally, WRT .bbappend files, the original recipes will have
> > their own licenses and if the .bbappend file is doing nothing but
> > adding some configuration (you know, PACKAGECONFIG, EXTRA_OEMAKE,
> > that sort of thing), then there should be no need for licensing in
> > the bbappend file. does all this sound reasonable so far?
>
> I wouldn't expect any bbappend to modify a package/recipe license
> without changing the sources (version bump). But not much experience
> with that, so might be a valid use case?

  i'm not *trying* to be overly pedantic (well, yeah, i am :-), but
given the importance of licensing these days, i want to understand how
they work far more than i do at the moment, especially since my new
co-workers are asking me about them.

rday

Re: [yocto] looking for a bit more info on licensing certain recipe files

[Quentin Schulz]

On Tue, May 04, 2021 at 06:00:10AM -0400, Robert P. J. Day wrote:
> On Tue, 4 May 2021, Quentin Schulz wrote:
> 
> > Hi Robert,
> >
> > On Tue, Apr 27, 2021 at 08:41:25AM -0400, Robert P. J. Day wrote:
> > >
> > >   for the first time, i'm digging around in the docs for how to
> > > properly license various types of recipes, so a couple simple
> > > questions to start with, at least so i can make a first pass of
> > > cleaning up some content in front of me.
> > >
> > >   as we established recently, packagegroup files need no
> > > licensing, the obvious observation being that they represent the
> > > collection of licenses that comprise them. however, i notice that
> > > the packagegroup.bbclass file does indeed define a default
> > > license:
> > >
> > >   LICENSE ?= "MIT"
> > >
> > > so not only does a packagegroup have a default (MIT) license, but
> > > it's conditional suggesting one could give it a different license.
> > > what other licenses would make sense for a packagegroup? I'm
> > > sticking with the default that packagegroup recipe files need no
> > > LICENSE assignment, but now i'm curious as to what other options
> > > there are (or perhaps that that default assignment in
> > > packagegroup.bbclass is obsolete).
> >
> > Wild guess: all packages need a license. MIT is quite permissive so
> > safe as a default?
> 
>   superficially makes sense, except that a packagegroup does not
> really define a "package". perhaps all *recipe* files need a license

They do define packages. Empty packages, but still packages. Look into
deploy/ipk and search for *packagegroup*, you'll see some.

It's probably a requirement/feature of package managers, so that you
install one package which has a dependency on many others, and the
latter are just pulled in by the package manager directly.

> but, again, it's not clear how a packagegroup license should percolate
> down to the packages it contains. or how things would percolate up.
> 

It does not apply to packages it RDEPENDS on, it applies to the packages
created by the packagegroup recipe, each of them then RDEPENDS on other
packages (with potentially (and often) licensed differently).

Cheers,
Quentin

Re: [yocto] looking for a bit more info on licensing certain recipe files

[Robert P. J. Day]

On Tue, 4 May 2021, Quentin Schulz wrote:

> On Tue, May 04, 2021 at 06:00:10AM -0400, Robert P. J. Day wrote:
> > On Tue, 4 May 2021, Quentin Schulz wrote:
> >
> > > Hi Robert,
> > >
> > > On Tue, Apr 27, 2021 at 08:41:25AM -0400, Robert P. J. Day wrote:
> > > >
> > > >   for the first time, i'm digging around in the docs for how to
> > > > properly license various types of recipes, so a couple simple
> > > > questions to start with, at least so i can make a first pass of
> > > > cleaning up some content in front of me.
> > > >
> > > >   as we established recently, packagegroup files need no
> > > > licensing, the obvious observation being that they represent the
> > > > collection of licenses that comprise them. however, i notice that
> > > > the packagegroup.bbclass file does indeed define a default
> > > > license:
> > > >
> > > >   LICENSE ?= "MIT"
> > > >
> > > > so not only does a packagegroup have a default (MIT) license, but
> > > > it's conditional suggesting one could give it a different license.
> > > > what other licenses would make sense for a packagegroup? I'm
> > > > sticking with the default that packagegroup recipe files need no
> > > > LICENSE assignment, but now i'm curious as to what other options
> > > > there are (or perhaps that that default assignment in
> > > > packagegroup.bbclass is obsolete).
> > >
> > > Wild guess: all packages need a license. MIT is quite permissive so
> > > safe as a default?
> >
> >   superficially makes sense, except that a packagegroup does not
> > really define a "package". perhaps all *recipe* files need a license
>
> They do define packages. Empty packages, but still packages. Look into
> deploy/ipk and search for *packagegroup*, you'll see some.
>
> It's probably a requirement/feature of package managers, so that you
> install one package which has a dependency on many others, and the
> latter are just pulled in by the package manager directly.
>
> > but, again, it's not clear how a packagegroup license should percolate
> > down to the packages it contains. or how things would percolate up.
> >
>
> It does not apply to packages it RDEPENDS on, it applies to the packages
> created by the packagegroup recipe, each of them then RDEPENDS on other
> packages (with potentially (and often) licensed differently).

  ah, now it makes sense, thanks.

rday