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