On Wed, May 13, 2020 at 09:53:12AM -0400, Robert P. J. Day wrote:
[...]

it gets weirder ... the project i'm working with is based on morty
so that variable *would* still be relevant, but even adding
"Unlicense" to that variable didn't stop the offending recipe
from still generating a warning. so i thought, "i wonder if there are
any other recipes in the layers i'm working with that have
'Unlicense," and sure enough, there's one: pyelftools (created
in-house).

so i added pyelftools to the image i'm building, but *that* recipe
*didn't* generate a warning, so now i'm thoroughly baffled. and,
finally, i decided to check the current state of pyelftools to see
what its licensing is, and in meta-python, we have the recipe
python3-pyelftools_0.25.bb, wherein we read:

LICENSE = "PD"

argh ... and if one checks OE/meta/files/common-licenses, there is
indeed a license file named "PD" whose contents are simply:

This is a placeholder for the Public Domain License

so now i'm not sure if a "Unlicense" license file is redundant or
what.

If Unlicense and Public Domain (PD) were actual synonyms we could put
them into the SPDXLICENSEMAP in
openembedded-core/meta/conf/licenses.conf, but according to
https://unlicense.org/ lists there should be a difference between both.

It looks like it's decently used though as GitHub reported that 2% of
the projects they host are Unlicense-licensed[1] which is more than
BSD-2 or [AL]GPLv3!

[1] https://github.blog/2015-03-09-open-source-license-usage-on-github-com/

i'm confused.

Since we have [AL]GPLv3 "support", I'd say Unlicense has its place as
well.

Quentin