Re: what is the proper treatment of the "Unlicense" license?

Quentin Schulz

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

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, wherein we read:


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


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


Join to automatically receive all group messages.