Add support for Public Domain (non-)license

[AMDmi3]

Summary

One of most used custom licenses in portstree is public domain. Add
framework support for it, saving ports from redefining name/text/perms
for it.

[mat]

It comes up every semester, but, hey...
It is not a license, software that are in the public domain have no license, the rights have either expired or been forfeited. (well, in our case, forfeited is most common.)
I would agree with something along the lines of a NONE license group, something like:

_LICENSE_NAME_NONE= No license (public domain or such)
_LICENSE_GROUPS_NONE= whatever is appropriate.

[danfe]

games/naev-data/Makefile

27 ↗

(On Diff #10160)

Regarding that talks on "PD vs. CC0", shall we retain the above link (and this) somewhere for reference? It might be useful if we ever start making the whole framework more legally clean.

[AMDmi3]

It is not a license, software that are in the public domain have no license, the rights have either expired or been forfeited. (well, in our case, forfeited is most common.)

No one really cares it's not a license. Arch, Gentoo, Fedora, even Debian (which is quite picky about copyright stuff) all list public domain as license. You could say we're listing any kind of conditions on which ports may be distributed. "Licenses" for short.

I would agree with something along the lines of a NONE license group, something like:
_LICENSE_NAME_NONE= No license (public domain or such)

This is utterly incorrect, as no license and public domain are essentially opposite things. No license actually means you cannot distribute (use, modify, ...) the package at all as author has not explicitly allowed you to. Public domain explicitly means you can do whatever you want with it.

[AMDmi3]

games/naev-data/Makefile

27 ↗

(On Diff #10160)

As far as I remember, standard licenses say something like "license is well known, please read on web", and this message falls under this statement well enough. If we further improve the framework, we may define links for each license, and http://www.teachingcopyright.org/handout/public-domain-faq could be a candidate link for PD.

[AMDmi3]

Just checked, even FOSSology treats PD as a license.

grep Public-domain install/db/licenseref.sql
INSERT INTO license_ref (rf_pk, rf_shortname, rf_text, rf_url, rf_add_date, rf_copyleft, "rf_OSIapproved", rf_fullname, "rf_FSFfree", "rf_GPLv2compatible", "rf_GPLv3compatible", rf_notes, "rf_Fedora", marydone, rf_active, rf_text_updatable, rf_md5, rf_detector_type) VALUES (512, 'Public-domain', 'Public domain software is software that is not copyrighted. If the source code is ...

[bdrewery]

I agree with this. The author put the license of "public domain" on their code, WHATEVER THAT MEANS, it is not up to us to decide if that is a "real license". It's a per-government legal thing, just like timezones. We should just pass along the license the author placed on it and let other people care about the impact on their systems. We're already distributing packages and distfiles for these, so there's no reason to not continue to do so. Adding a boilerplate PD license lets us remove excess logic and lets users actually find which ports/packages they have installed that are in this ambiguous "public domain" versus the current situation of not having a consistent "license" for it.

As a side note, I would prefer a more clear PUBLIC_DOMAIN name rather than the obscure PD.

[AMDmi3]

In D4149#87182, @bdrewery wrote:

As a side note, I would prefer a more clear PUBLIC_DOMAIN name rather than the obscure PD.

PD is a well-known acronym and most licenses are short acronyms anyway, so I don't see a good reason for it. But may do if you insist.

[bdrewery]

Also, step back and consider what the purpose of the license framework even is. Not advertising to the user what the author considered the license to be defeats the purpose of the framework.

[mat]

In D4149#87190, @bdrewery wrote:

Also, step back and consider what the purpose of the license framework even is. Not advertising to the user what the author considered the license to be defeats the purpose of the framework.

The only thing it is somewhat used for is restrict distribution of binary packages and maybe distfiles, other than that, I have no idea.

[bdrewery]

In D4149#87191, @mat wrote:

In D4149#87190, @bdrewery wrote:

Also, step back and consider what the purpose of the license framework even is. Not advertising to the user what the author considered the license to be defeats the purpose of the framework.

The only thing it is somewhat used for is restrict distribution of binary packages and maybe distfiles, other than that, I have no idea.

As a vendor, I used it to make a matrix of all licensed packages we had in the system (both in ports and base). The lack of a valid LICENSE on most ports we had (which are all old and likely predate a lot of the framework anyway) meant a lot of manual 'make extract' and grepping on my part. It was tedious. Having the package state what known license is on it helps a lot. I know the word 'license' is loaded and when taken absolutely/literally may not work with "public domain", but it still conveys what the author's wishes with the code are. "Public domain" to many people means "not likely to be sued for using it" vs "no license" meaning "we may get sued for this".

[bapt]

I think we should accept it as is, the GROUP cannot be used to define it as a non license given it is used to express compatiblity and for instance the FSF clearly state Public domain work while not being under a real license is compatible.

Note that this license should not be used for the "unlicense" license or the CC0

[AMDmi3]

In D4149#103396, @bapt wrote:

Note that this license should not be used for the "unlicense" license or the CC0

Sure, the next step planned was to add a bunch of CC licenses including CC0, as they are used widely and may impose restrictions (CCbyNC & friends)