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


Robert P. J. Day
 

colleague added a new recipe to a build, got a warning "The license
listed Unlicense was not in the licenses collected for recipe
python-filelock" and, sure enough, that source was released under the
"Unlicense" which i had never heard of:

https://github.com/benediktschmitt/py-filelock/blob/master/LICENSE

what is the standard strategy for dealing with that? should i just
whitelist that license? has anyone else run into this "Unlicense"
license?

rday


Quentin Schulz
 

Hi Robert,

On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:

colleague added a new recipe to a build, got a warning "The license
listed Unlicense was not in the licenses collected for recipe
python-filelock" and, sure enough, that source was released under the
"Unlicense" which i had never heard of:

https://github.com/benediktschmitt/py-filelock/blob/master/LICENSE

what is the standard strategy for dealing with that? should i just
whitelist that license? has anyone else run into this "Unlicense"
license?
You can add a license to your layer by doing the following in
conf/layer.conf:
LICENSE_PATH += "${LAYERDIR}/licenses"

and in there you put the Unlicense file named exactly the same with the
correct content. That's one way.

The other is to use NO_GENERIC_LICENSE[Unlicense] = "/path/to/Unlicense"
in the recipe.

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?

Quentin


Richard Leitner
 

On Wed, May 13, 2020 at 12:39:44PM +0200, Quentin Schulz wrote:
On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:
...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?
+1 for adding Unlicense to openembedded-core's common-licenses

regards;rl


Quentin


Robert P. J. Day
 

On Wed, 13 May 2020, Quentin Schulz wrote:

... snip ...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need
any of the suggested ways?
that was one of the first things that came to mind ... if there are
enough packages with this license, why not just make it official? i
just did a quick search, and this is the only layer i see that makes
reference to it:

busybox/networking/tls_aes.c

/*
* Copyright (C) 2017 Denys Vlasenko
*
* Licensed under GPLv2, see file LICENSE in this source tree.
*/

/* This AES implementation is derived from tiny-AES128-C code,
* which was put by its author into public domain:
*
* tiny-AES128-C/unlicense.txt, Dec 8, 2014
* """
* This is free and unencumbered software released into the public domain.

more info on that license:

https://choosealicense.com/licenses/unlicense/

open to suggestions.

rday


Robert P. J. Day
 

On Wed, 13 May 2020, Richard Leitner wrote:

On Wed, May 13, 2020 at 12:39:44PM +0200, Quentin Schulz wrote:
On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:
...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?
+1 for adding Unlicense to openembedded-core's common-licenses
as long as this requires only adding an Unlicense file to that
directory, i can do that shortly.

rday


Quentin Schulz
 

Hi Robert,

On Wed, May 13, 2020 at 07:19:59AM -0400, Robert P. J. Day wrote:
On Wed, 13 May 2020, Richard Leitner wrote:

On Wed, May 13, 2020 at 12:39:44PM +0200, Quentin Schulz wrote:
On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:
...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?
+1 for adding Unlicense to openembedded-core's common-licenses
as long as this requires only adding an Unlicense file to that
directory, i can do that shortly.
I'm not sure, but there might be a need to add it to SRC_DISTRIBUTE_LICENSES
in openembedded-core/meta/conf/licenses.conf.

Quentin


Robert P. J. Day
 

On Wed, 13 May 2020, Quentin Schulz wrote:

Hi Robert,

On Wed, May 13, 2020 at 07:19:59AM -0400, Robert P. J. Day wrote:
On Wed, 13 May 2020, Richard Leitner wrote:

On Wed, May 13, 2020 at 12:39:44PM +0200, Quentin Schulz wrote:
On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:
...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?
+1 for adding Unlicense to openembedded-core's common-licenses
as long as this requires only adding an Unlicense file to that
directory, i can do that shortly.
I'm not sure, but there might be a need to add it to
SRC_DISTRIBUTE_LICENSES in
openembedded-core/meta/conf/licenses.conf.
that variable is gone:

commit 64daaf29e2c12c8b587bafdebf9409433187ddf7
Author: Peter Kjellerstedt <peter.kjellerstedt@...>
Date: Wed Dec 11 17:48:14 2019 +0100

licenses.conf: Remove the SRC_DISTRIBUTE_LICENSES variable

The SRC_DISTRIBUTE_LICENSES variable and its static list of licenses
has been replaced by AVAILABLE_LICENSES, which automatically contains
all available licenses.



rday


Quentin Schulz
 

On Wed, May 13, 2020 at 08:40:28AM -0400, Robert P. J. Day wrote:
On Wed, 13 May 2020, Quentin Schulz wrote:

Hi Robert,

On Wed, May 13, 2020 at 07:19:59AM -0400, Robert P. J. Day wrote:
On Wed, 13 May 2020, Richard Leitner wrote:

On Wed, May 13, 2020 at 12:39:44PM +0200, Quentin Schulz wrote:
On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:
...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?
+1 for adding Unlicense to openembedded-core's common-licenses
as long as this requires only adding an Unlicense file to that
directory, i can do that shortly.
I'm not sure, but there might be a need to add it to
SRC_DISTRIBUTE_LICENSES in
openembedded-core/meta/conf/licenses.conf.
that variable is gone:

commit 64daaf29e2c12c8b587bafdebf9409433187ddf7
Author: Peter Kjellerstedt <peter.kjellerstedt@...>
Date: Wed Dec 11 17:48:14 2019 +0100

licenses.conf: Remove the SRC_DISTRIBUTE_LICENSES variable

The SRC_DISTRIBUTE_LICENSES variable and its static list of licenses
has been replaced by AVAILABLE_LICENSES, which automatically contains
all available licenses.

That'll teach me to check in master instead of my release of Yocto :)

Quentin


Robert P. J. Day
 

On Wed, 13 May 2020, Quentin Schulz wrote:

On Wed, May 13, 2020 at 08:40:28AM -0400, Robert P. J. Day wrote:
On Wed, 13 May 2020, Quentin Schulz wrote:

Hi Robert,

On Wed, May 13, 2020 at 07:19:59AM -0400, Robert P. J. Day wrote:
On Wed, 13 May 2020, Richard Leitner wrote:

On Wed, May 13, 2020 at 12:39:44PM +0200, Quentin Schulz wrote:
On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:
...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?
+1 for adding Unlicense to openembedded-core's common-licenses
as long as this requires only adding an Unlicense file to that
directory, i can do that shortly.
I'm not sure, but there might be a need to add it to
SRC_DISTRIBUTE_LICENSES in
openembedded-core/meta/conf/licenses.conf.
that variable is gone:

commit 64daaf29e2c12c8b587bafdebf9409433187ddf7
Author: Peter Kjellerstedt <peter.kjellerstedt@...>
Date: Wed Dec 11 17:48:14 2019 +0100

licenses.conf: Remove the SRC_DISTRIBUTE_LICENSES variable

The SRC_DISTRIBUTE_LICENSES variable and its static list of licenses
has been replaced by AVAILABLE_LICENSES, which automatically contains
all available licenses.

That'll teach me to check in master instead of my release of Yocto :)
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.

i'm confused.

rday


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


Robert P. J. Day
 

On Wed, 13 May 2020, Richard Leitner wrote:

On Wed, May 13, 2020 at 12:39:44PM +0200, Quentin Schulz wrote:
On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:
...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?
+1 for adding Unlicense to openembedded-core's common-licenses
i submitted a patch yesterday.

rday