Unpopular opinion: we could also allow NONE which just was enabled by the latest SPDX release. But well, that's not really what REUSE wants to procure...

My personal preference on this is to use MIT rather than either CC0-1.0 or Unlicense, since they are all on the "extremely permissive" side of the equation, and they reduce the friction altogether.

Fedora recommends against Unlicense but it does not seem to disallow it either. It does say that there's MIT variants with rights to sublicense, but does not provide an explicit link there. The MIT license at OSI does say "sublicense" though.

OSI talks about CC0 on the FAQ, and links to unlicense.org, but of course neither of them are on the OSI approved list.

I'm most definitely not a lawyer, which is why I just wanted to avoid this chaos and chose to license config files under MIT and be done with it, but YMMV.

@mxmehl I agree that that's against the stated goals of REUSE.

@Flameeyes There are three or four problems with choosing MIT here:

1. It doesn't convey intent as well as CC0-1.0 does. A public domain dedication is a very clear communication by the author that they don't care about what happens to the work. An MIT license doesn't communicate this clearly, and still comes with one string attached: To preserve the copyright statement (on an uncopyrighted work…). The 0BSD would be a better option here, which has basically zero strings, but still has its own problems.

2. The MIT license has this annoying thing where there's a copyright statement inside of the license text. See Better handle licenses that have SPDX templates/variables (e.g. MIT, BSD) #16. This still isn't really resolved, and REUSE currently makes no clear recommendation on how to deal with that.

3. The MIT license explicitly uses the word "software", which doesn't make sense for tiny configuration files and the like. Apache-2.0 and 0BSD have the same problem.

4. Potentially politics. The FSF insists on calling the MIT license the "Expat" license, and usually recommends Apache-2.0 over MIT/Expat. The FSFE the FSF isn't, but we do like to be on one line to avoid conflict.

How I wish FOSS licensing wasn't such a mess :(

To be quite honest, Google also recommends Apache-2.0 over MIT — and indeed for the stuff I released while working there I stuck to Apache-2.0 for config files as well, as nearly anything else would have required a thorough review (which I guess fits your idea of using the project's overall license).

Now if we're trying to align to FSF — FSF also appears to discourage Unlicense over CC0-1.0 but it is considered compatible. The discouragement is also less strongly worded than the WTFPL (which somehow sends people to Apache-2.0 rather than CC0-1.0, but that's a completely separate tangent).

So on a totally pragmatic view of "making the least amount of people unhappy", I would vote for Unlicense as the recommendation (fully aware that my vote is not worth anything in this context :)) — it's not recommended by any of the organizations we're talking about, it is discouraged by pretty much all of them (OSI, FSF, Fedora) but it is not banned by any of them either, whereas CC0-1.0 is banned by Google and strongly worded against by OSI.

CC0-1.0 was not approved in OSI, because there was a discussion about it because it explicitly does not cover patents. Then CC0-1.0 got pulled back from the process, so the process actually never finished.

That being said, I don’t think any public domain dedication covers patents. OSI covers this pretty well here:
https://opensource.org/faq#public-domain

That being said, I don‘t see an acute need for a change. We suggest to use CC0-1.0, we do not require people to do so. If their project/employer has a different policy, they can always just slap whatever they require it.

The goal of REUSE is to have valid and useful info in all source code, not which licenses must be used.

The goal of REUSE is to have valid and useful info in all source code, not which licenses must be used.

Very right, thank you for the reminder. What about trying to make a short abstract of the different options (CC0-1.0, Unlicense, Apache-2.0/MIT, some-other-public-domainish-SPDX'ed-license) and update the FAQ entry with it, while stating that REUSE does not have a strict policy on that?

What about trying to make a short abstract of the different options (CC0-1.0, Unlicense, Apache-2.0/MIT, some-other-public-domainish-SPDX'ed-license) and update the FAQ entry with it, while stating that REUSE does not have a strict policy on that?

That is one option. If you draft one, I’m happy to review it.

The simpler/lazy option is just to say that CC0-1.0 is one option how to do it, but change that to whatever fits your project/company/personal policy.

I think there may be a super simple workaround, though. Instead of exclusively licensing "uncopyrightable" stuff under CC0-1.0, you could dual-license it, so that the recipient can choose which licence they prefer.

There are two problems with this:

1. If it's uncopyrightable, most licenses are void since the terms are explicitly for copyrightable works. For example, if an uncopyrightable work is distributed under GPL-3.0 you can just ignore that and do what you want with the work anyways (so says the FSF).

2. Including a recommendation like that furthers the misconception that dual licensing with CC0 is possible in the first place. Per the Creative Commons FAQ:

   Please note that CC0 is not a license; it is a public domain dedication. When CC0 is applied to a work, copyright no longer applies to the work in most jurisdictions around the world. Therefore, references to dual licensing arrangements like the one above are inapplicable to CC0.

Ultimately what SPDX expressions people use is up to them but REUSE should avoid recommending things that might be legally problematic.

Do note that lately the consensus between FOSS legal experts seems to have shifted from CC0-1.0 being a preferred license for “non-copyrightable stuff” to one that should best be avoided for code, since (as other CC licenses) it explicitly excludes patents.

Perhaps a better choice would be something like MIT-0, 0BSD or even Unlicense (confusing name though).

https://lists.fedoraproject.org/archives/list/[email protected]/thread/RRYM3CLYJYW64VSQIXY6IF3TCDZGS6LM/
https://www.gnu.org/licenses/license-list.html#CC0

@silverhook I was going to raise that also.

I dislike that all the possible replacement licences explicitly use the word 'software'. But I think it's just a case of picking your poison.

As I wrote two years ago I'd recommend 0BSD because it's more widely accepted in the industry.

Unlicense is explicitly disallowed in Google's opensource contribution program.

I think 0BSD and MIT-0 would probably be our best bets if we’re dealing with software, yes.

It is frustrating that there is no silver bullet, but that’s life…

It is frustrating that there is no silver bullet, but that’s life…

I have an idea. Let's create a new licence!

(+1 for 0BSD)

Following the recent Fedora policy change on CC0, I have already seen one case where a package had several (trivial) CC0-covered 'code' files in an attempt to follow REUSE recommendations. If REUSE is going to continue recommending that all files (however trivial or insignificant) bear some sort of copyright and license notice, I suggest that a license other than CC0 be used -- my recommendation would be MIT-0 (MIT No Attribution). 0BSD is OK too :)

As a data point it doesn't look like Google allows contributions to MIT-0. Maybe that'll change, but 0BSD might still a safer bet if we're going down that route.

Hmmmm, I wonder if it is the time where (at least in the FAQ) we address that different licenses are good for different types of work/content.

Given that so far from different sources I’ve heard of three different preferred licenses (0BSD, MIT-0, Unlicense) by different projects/experts and one of those mentioned as not-allowed (MIT-0, in comment above), it might also make sense to have a quick check of at least what the more important FOSS players prefer or disallow.

So far it seems to me:

• 0BSD – 1 preference
• MIT-0 – 1 preference, 1 non-allow(?) (I don’t read it as non-allow, but @Flameeyes may have had some insight I don’t)
• Unlicense – 1 preference, 1 non-allow (+ 1 “it’s not the best worded”(?))

To clarify, Google disallowed all of those except 0BSD. Which is why I have been using, and recommending, it.

See the details from https://flameeyes.blog/2020/04/16/making-it-easy-to-contribute-code/ and my difficulty indeed to find a solution that would work, both with REUSE and Google's policies.

@Flameeyes are you referring to this section and if so, has it changed?
https://opensource.google/documentation/reference/thirdparty/licenses#unencumbered

Different lists for licenses allowed to be used versus being able to be contributed to.

Personally I care about the latter, since otherwise I cut myself out from the contributions of Google employees. For that the published list of banned licenses is https://opensource.google/documentation/reference/patching#forbidden

You can see that all public domain dedications except 0BSD are banned from patching. That includes WTFPL and Unlicense.

Ah, got it.

But it has to be pointed out that while CC0-1.0 and Unlicense are public domain dedications, 0BSD and MIT-0 are not – they are just very permissive licenses, who don’t care about attribution.

(And yeah, for the record, WTFPL is fun, but please don’t license stuff under it.)

There is no need to change the recommendation about CC-0, which is currently the only license/waiver option for uncopyrightable files (as LynnKirby notes above).

Concerns about trademarks and patents are irrelevant because these are generally about projects, not files. (Or is someone worried about trademarks on .gitignore files?) To address those concerns, it's sufficient to make sure that the project as a whole has a free software license, beyond the CC-0 license used for individual uncopyrightable files. If the entire project is made exclusively of uncopyrightable files, the authors or rightsholders can come up with a copyrightable poem to add to the README and place that under MIT-0, 0BSD or whatever.

Discouraging the CC-0 altogether in software would cause problems and increase legal risk for the reusers of all those software projects which contain uncopyrightable data which might be subject to sui generis database rights.

Good point, @nemobis .

The problem remains that if we continue to recommend CC0-1.0 (or Unlicense) – even for files where it totally makes sense –, and the general consensus in the community is that CC0-1.0 (and Unlicense) is not good for certain reasons and as a consequence a lot of policies (even if wrongly) make it really difficult to use or even flat-out forbid using those licenses, that would put REUSE-compliant projects at a real disadvantage.

As written in a previous comment it is the FSF and Fedora that have recently publicly shunned CC0-1.0 and the explicitly missing patent license is something that has been a growing concern in the circles of FOSS legal experts. I see the recent moves of FSF and Fedora as more of a symptom of a greater shift that took a long long time, not as the trigger for such shift.

You can even read this in @richardfontana’s original mail to Fedora Legal mailing list:

The reason for the change: Over a long period of time a consensus has
been building in FOSS that licenses that preclude any form of patent
licensing or patent forbearance cannot be considered FOSS. CC0 has a
clause that says: "No trademark or patent rights held by Affirmer are
waived, abandoned, surrendered, licensed or otherwise affected by this
document." (The trademark side of that clause is nonproblematic from a
FOSS licensing norms standpoint.) The regular Creative Commons
licenses have similar clauses.

Google’s concern seems to be about dedications to public domain in general, which can be tricky and have been abused before. But that is not something REUSE needs to concern itself about. The only reason Google’s policy popped up here is that if we’re replacing CC0-1.0 for a different license/public domain dedication, then it’s best to chose one that doesn’t put REUSE-compliant projects in a disadvantage from getting contributions from different individuals and legal entities and we started gathering known policies to see which of the options (0BSD, CC0-1.0, MIT-0, Unlicense, …) is the most widely acceptable.

One thing I wondered is whether Fedora's policy change applies only to packages where CC0-1.0 is the primary license of the package as a whole, or also to packages under some other license—say, Apache-2.0—that have specific files licensed CC0-1.0. From @richardfontana's comment:

Following the recent Fedora policy change on CC0, I have already seen one case where a package had several (trivial) CC0-covered 'code' files in an attempt to follow REUSE recommendations. If REUSE is going to continue recommending that all files (however trivial or insignificant) bear some sort of copyright and license notice, I suggest that a license other than CC0 be used -- my recommendation would be MIT-0 (MIT No Attribution). 0BSD is OK too :)

it sounds like the later. I'm not a lawyer, but the "submission of contributions" clause in Apache-2.0 makes it an especially interesting case. Some projects use that clause to specify that all inbound contributions are e.g. Apache-2.0 AND MIT—i.e. all contributors agree to the patent grant—but the outbound license is Apache-2.0 OR MIT, giving downstream users especially broad compatibility. Would CC0-1.0 OR Apache-2.0 in such a scheme satisfy Fedora's policy?

Moving away from the Fedora specifics, @richardfontana's observation that REUSE recommends "that all files (however trivial or insignificant) bear some sort of copyright and license notice" gets to why I find CC0-1.0 especially relevant for REUSE.

I contribute to a number of projects that don't follow the REUSE recommendations and don't have per-file license headers, but just an overall statement of what license the project is under. If I contribute a file to such a project that I believe is too trivial to be copyrightable, it doesn't bother me to leave that implicit: if I'm right that my contribution really is not copyrightable, people can use it accordingly whether I say so or not.

If I follow the REUSE recommendations, though, I can't leave anything implicit: I must specify the license even for .gitignore files and other things I do not believe are copyrightable. Using CC0-1.0 communicates that view, while also protecting recipients against the possibility that some judge might disagree with me (since I am not a lawyer). I think that's also why Creative Commons recommends, as I understand it, that you use CC0-1.0 rather than the Public Domain Mark for your own work that you believe not to be copyrightable.

If I wrote # SPDX-License-Identifier: GPL-3.0-or-later at the top of my .gitignore files, or even some more permissive license, I would seem to be asserting something I do not believe to be true: I do not believe I have any rights under copyright over .gitignore files that I could license. Moreover, I argue that I ought not to have any rights over .gitignore files, nor over many Makefiles and other files that could be considered code.

One possibility would be to use Jason Self’s Worldwide Public Domain Dedication once its finished. The current draft is a fork of CC0-1.0 that tries to waive both copyright and patent rights. It also removes the part of CC0 that says that trademarks aren’t affected.

As far as I know, the patent thing is the only reason why people, projects and organizations have been discouraging CC0. Are there any other criticisms of CC0 that we would need to consider?

Sounds like a nice idea, but I’d really prefer to suggest a more well-established license instead.