On Tue, Mar 23, 2021 at 3:13 AM Robert P. J. Day <rpjday@...> wrote:

once again into the code base i'm poring over, and this time, it's
about defining proprietary licenses for internal recipes.

The typical approach for recipes which build proprietary code is to
set LICENSE to "CLOSED" (and not define LIC_FILES_CHKSUM).

I'm not sure what the advantages are of creating a license text for a
proprietary license (since presumably you won't be sharing the source
or license text with anyone). However, if you do need to do that for
some reason, be sure to double check COPYLEFT_LICENSE_EXCLUDE (e.g.
append your proprietary license to it from your layer.conf) in avoid
someone enabling the archiver class and accidentally including your
proprietary code in a release of the open source code used in a
project.

turns out the meta-boundary layer has a nice example of what i'm
sure is the right way to do this (i've rarely had to do this myself),
wherein the layer's "layer.conf" file defines where to go get some
extra licenses:

LICENSE_PATH += "${LAYERDIR}/licenses"

or possibly some variant like (for ubiquitous acme corp.):

LICENSE_PATH += "${LAYERDIR}/files/acme-licenses"

to pair up with OE's .../files/common-licenses, you get the idea.

so i was puzzled when i saw all these clearly proprietary recipes
that did not define LICENSE or LIC_FILES_CHKSUM values but, instead,
inherited "acme-license.bbclass", whereupon ... well ...

acme-license.bbclass
====================

HOMEPAGE = "https://acme.com"
LICENSE = "Acme-Corp-License"
LIC_FILES_CHKSUM =
"file://${THISDIR}/../../files/acme-licenses/${LICENSE};
md5=deadbeef..."

*sigh* ... while this might save a couple lines per recipe file, i
can't believe this is a reasonable approach. has anyone else seen this
strategy?

Doesn't seem too unreasonable (aside from the comments above about
setting LICENSE to "CLOSED" for proprietary recipes).

in any event, i'm adding this to my current list of "stuff you might
want to avoid doing when using openembedded."

rday