Hi,

On Sat, Aug 31, 2024, at 5:33 PM, Daphne Preston-Kendal wrote:
>
> Another, non-technical reason implementations might not want to bundle
> a library is licensing. I don’t know if this has ever happened to a
> SRFI, at least since the MIT licence became standard here.
> But the existing library is public domain, and therefore I feel my code
> will have a disadvantage if it is more encumbered than what I hope it
> will supplant.
>
> I am just trying to take a systematic approach to removing all possible
> obstacles to adoption, within the context that I am writing this
> particular code, and I feel the licence in this case might be one of
> them.
>

Unfortunately, in 2022, Fedora policy changed [1] to no longer allow the CC0-1.0 license for code because of clause 4(a), which says, "No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document." Similarly, Creative Commons withdrew CC0-1.0 from consideration by the OSI due to concerns that, while many OSI-approved open source licenses do not mention patents at all, they might implicitly grant patent licenses, whereas the language explicitly saying that CC0-1.0 does not affect patents might "weaken equitable estoppel defenses against patents or ... heighten risk by putting someone 'on notice' about patent risks in the associated code" [2].

So, sadly, CC0-1.0 can itself be a "possible obstacle[] to adoption" in some contexts.

I like and use CC0-1.0 myself, and I share your sentiment that even a permissive license isn't really a substitute for a dedication to the public domain. Some projects have combined CC0-1.0 with an additional patent grant, and I wish Creative Commons would publish standard language for doing that, but that quickly gets out of scope for this list.

In the SRFI context, I think Richard Fontana's suggestion down-thread from [1] of the MIT No Attribution (MIT-0) license, which is simply the MIT license without the attribution requirement. Here is the full text [3]:

> Permission is hereby granted, free of charge, to any person
> obtaining a copy of this software and associated documentation files
> (the "Software"), to deal in the Software without restriction,
> including without limitation the rights to use, copy, modify, merge,
> publish, distribute, sublicense, and/or sell copies of the Software,
> and to permit persons to whom the Software is furnished to do so.
>
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> SOFTWARE.
>

In particular, the MIT-0 license doesn't use the word "copyright" or even assert that permission is *needed*: it simply says that "permission is hereby granted".

I think it could be reasonable to dual-license with CC0-1.0 by writing:

;; SPDX-License-Identifier: (CC0-1.0 OR MIT-0)
;; SPDX-FileCopyrightText: 2024 Alyssa P. Hacker <xxxxxx@example.com>

The second line satisfies REUSE without making possibly-contradictory statements about whether Alyssa P. Hacker retains copyright or not. Since this is free-form text, you could even write "Alyssa P. Hacker, dedicated to the public domain" or something similar.

Philip

[1]: https://lists.fedoraproject.org/archives/list/xxxxxx@lists.fedoraproject.org/thread/RRYM3CLYJYW64VSQIXY6IF3TCDZGS6LM/
[2]: https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2012-February/001565.html
[3]: https://spdx.org/licenses/MIT-0.html