Re: public domain dedications proliferation

McCoy Smith

I’m not sure SPDX makes qualitative assessments of licenses or statements (nor should it, since practically every license does have some degree of ambiguity).

So a PD dedication that is unquestionably valid in the US but not in other countries can still get a SPDX tag, I think. It’s up to the user to determine if that statement is effective for them.

I think CC0 is probably the best attempt to come up with a truly comprehensive PD dedication, but that requires including a backstop highly permissive license attached. Whether that (or things like it) ought to be classified as a ‘license’ or a ‘PD dedication’ is moderately interesting although I tend to think of it as both. But to me, anything that recites a permission, or which has obligations – however mild – and doesn’t say “public domain” is a license.


From: Warner Losh <imp@...>
Sent: Tuesday, August 16, 2022 9:13 AM
To: McCoy Smith <mccoy@...>
Cc: J Lovejoy <opensource@...>; SPDX-legal <Spdx-legal@...>
Subject: Re: public domain dedications proliferation


I was using beerware as an example to ask the question: what separates it from PD, especially with the public domain dedications that try to work around EU law in different ways. Is it the grant of permission to copy? Is it the lack of any other terms and condition? So the PD except where can't do that where you can use any OSI license would fall on the 'needs SPDX id' and is outside of the data Jilayne was asking for, but a 'do whatever you want' would be in scope?




On Tue, Aug 16, 2022 at 10:01 AM McCoy Smith <mccoy@...> wrote:

There is an obligation in there (“as long as you retain this notice”) so it really is a license not a PD dedication (if something is PD, it comes with no obligations).

Plus, beerware is already SPDXed as a license:



From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Warner Losh
Sent: Tuesday, August 16, 2022 8:58 AM
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <Spdx-legal@...>
Subject: Re: public domain dedications proliferation


On a related question, there's several licenses that are close to the public domain. Eg:


"THE BEER-WARE LICENSE" (Revision 42):
<phk@...> wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp


which, apart from the markup issues being tied to a specific author, is very close to the public domain.... unless you desire to but phk a beer, and he wants one when you offer... but if he'd dedicated it to the public domain and I wanted to buy him a beer the end results would be identical. Likewise if I didn't want to buy him a beer in both cases. This is a current license in the SPDX list, however. And I think that's proper because the additional term "retain notice" makes it a license to use with mild conditions, rather than a repudiation of ownership.


A number of posters raise the points about EU law differing enough from US law that public domain creates difficulties, which people have worked around with additional words in different ways.


So, what separates those workarounds from the above beer-ware license, apart from the lack of the phrase 'public domain'? Is that the defining characteristic? Or is there some other touchstone to separate the vague "sure, whatever" from the "I disclaim ownership" from the "I disclaim ownership, but if I can't do that and still own the damn thing, here's the deal"? We can assume a large disparity in the care that these dedications are drafted, and as such we should expect a continuum of actual grants when all of them basically wanted people to do whatever with it.




On Mon, Aug 15, 2022 at 5:15 PM J Lovejoy <opensource@...> wrote:

Hi SPDX-legal,

I have raised this a couple times in the past few months or so, but now that it is more of a "ripe" topic, I wanted to get some input on preliminary ideas:

Fedora has now officially adopted the use of SPDX ids in packages meta data (specifically, the license field of the package spec file). Due to Fedora historically using "category" short names for groups of similar licenses, we suspect there may be a number of additions to the SPDX License List needed. 

Public domain category:
Specifically, Fedora has used "public domain" for any public domain dedication, without capturing the exact text. For Fedora package maintainers who are keen to update the license info for their packages, we have given this interim advice:
and (see section on "public domain")

SPDX approach:
The SPDX License List has always operated from the principle that an SPDX license id represents a specific, identifiable license/set of text. This is critical as part of our project goal of being both human and machine-readable.

However, if it turns out that there are a large number of slight variations of text that mean the same thing (e.g., a simply one line statement of public domain dedication), then perhaps SPDX might consider a slightly different approach?

But, in order to even consider this, we'd need data.

Idea for going forward:
As Fedora package maintainers find these texts that had been marked generically as "public domain" - what if we asked them to copy the actual text of what they found and maybe a link to where they found it (or some other such pointer) in a simply formatted file in the Fedora license-list-data repo?

This would be at least a beginning of collecting this data that SPDX-legal could then review in a more bulk fashion in order to consider the above potential approach.

If so, what other info besides the text itself should be collected and how can it be most easily formatted to enable easy consumption later?

For example, it could be something like this:

package = Foo
text = This is released into the public domain.
source = <url to file or other such pointer>

I wouldn't want to be more than a few pieces of information. There is also always the ability to search on the short name "public domain" or the interiem SPDX id of "LicenseRef-Fedora-Public-Domain", but might as well start collecting info if package maintainers are looking as well.

Thoughts? (need input ASAP :)


Join to automatically receive all group messages.