Stream: Miscellaneous

Topic: CC0 for software


view this post on Zulip Théo Zimmermann (Sep 27 2022 at 06:39):

Note that CC0 use for software works is discouraged by both the FSF because of its patent clause (https://www.gnu.org/licenses/license-list.en.html#CC0) and the OSI, which does not list it as an open source license (https://opensource.org/faq#cc-zero). The Unlicense is more appropriate for software and it is recognized as an open source license by the OSI (https://opensource.org/licenses/unlicense), although it is considered less mature by the FSF: https://www.gnu.org/licenses/license-list.en.html#Unlicense.

view this post on Zulip Michael Soegtrop (Sep 27 2022 at 08:24):

@Théo Zimmermann : actually the FSF does recommend CC0 over unlicense in the link you shared above (for any work). They still say you shouldn't use CC0 for software in the other link, but I am not aware that they recommend something else than CC0 if you really want to put it into public domain (which of course the FSF says you shouldn't).

I find the patent clause discussion about CC0 a bit artificial. It might be not so nice for the users, but most other licenses don't say anything about patents, and I am not sure it is much better for the user to walk in the dark. For you as publisher you might be better off with CC0 in case you unknowingly use some patent of someone else in your software. If you then silently license this patent to the users of your software, you might be in deep trouble. I find the explicitness of CC0 more appropriate than not saying anything about patents. Sure the issue that companies might lure users into patent infringement law suits via CC0 is there - but hopefully not an issue in the Coq ecosystem.

view this post on Zulip Karl Palmskog (Sep 27 2022 at 08:29):

many legal people have deliberated over whether patents should be mentioned, and both OSI and FSF seems to come on the side of: unless you are preventing patent traps, don't mention patents. Unlicense doesn't talk about patents, so it's safer in this way (and also got through the OSI gauntlet)

view this post on Zulip Karl Palmskog (Sep 27 2022 at 08:37):

FSF on CC0:

If you want to release your non-software work to the public domain, we recommend you use CC0. For works of software it is not recommended, as CC0 has a term expressly stating it does not grant you any patent licenses.

FSF on Unlicense:

If you want to release your work to the public domain, we recommend you use CC0.

Taken together, I interpret this as saying that FSF only recommends CC0 over Unlicense for non-software works. For software works, the only reasonable conclusion is that they rank Unlicense higher [due to absence of patent clause].

view this post on Zulip Michael Soegtrop (Sep 27 2022 at 10:15):

@Karl Palmskog : I wouldn't read it like this - the sentence after the one you cited is important:

If you want to release your work to the public domain, we recommend you use CC0. CC0 also provides a public domain dedication with a fallback license, and is more thorough and mature than the Unlicense.

I would read the FSF statements as:
1.) don't use public domain licenses for software
2.) if for whatever reason you don' follow advice 1 above, use CC0

The Ocaml Opam repo is CC0, btw.

view this post on Zulip Karl Palmskog (Sep 27 2022 at 10:16):

I wouldn't call the OCaml opam repo code, though. It's basically a metadata collection

view this post on Zulip Karl Palmskog (Sep 27 2022 at 10:20):

one interesting piece of evidence, apparently Fedora has deprecated CC0, quote from here, which links here:

In July 2022, the CC0 license became unsupported [by Fedora] and software to be released in the Fedora distribution must not be under CC0, due to CC0 not waiving patent rights.

view this post on Zulip Michael Soegtrop (Sep 27 2022 at 10:24):

Indeed one can discuss if opam packages are a "work" in the sense of copyright law at all.

Anyway, what I wanted to say is that as author I feel better with CC0, but I understand that CC0 can result to difficulties for users if abused.

view this post on Zulip Karl Palmskog (Sep 27 2022 at 10:32):

Many things I disagree with Bradley Kuhn about, but I think he's right in this:

Kuhn continued, "However, if a FOSS license explicitly states that no patent license of any kind is provided, powerful patent holders can run amok — unchecked — against the commercial users of that FOSS. If that FOSS is included in Linux-based software distributions, every distribution user is at risk. My colleague Mr. Fontana has thus made a good recommendation here to the Fedora project. Other distributions may want to consider this issue as well."

view this post on Zulip Michael Soegtrop (Sep 27 2022 at 11:32):

I don't quite see how not mentioning patents at all can mend this - my law teacher at school (a judge) always said: "Don't leave anything of importance implicit in a contract". IMHO not mentioning patents just makes trials about it more expensive, but I don't think it provides protection of any kind.

view this post on Zulip Michael Soegtrop (Sep 27 2022 at 11:34):

But if CC0 is a problem, as your links suggest, we should probably change Coq Platform to something else. Originally I made it CC0 because originally I had a lot of exchange with the OCaml Opam repo, but now it is much more with the Coq opam repo (which is LGPL 2.1).

view this post on Zulip Karl Palmskog (Sep 27 2022 at 11:35):

ah, actually the Coq opam repo is as follows:

view this post on Zulip Karl Palmskog (Sep 27 2022 at 11:37):

my personal opinion is that Unlicense is an improvement over CC0. But if the only reason for change is the patent worry, then Apache-2.0 is probably the only widely used permissive license considered immune to this.

view this post on Zulip Théo Zimmermann (Sep 27 2022 at 15:40):

Michael Soegtrop said:

Théo Zimmermann : actually the FSF does recommend CC0 over unlicense in the link you shared above (for any work). They still say you shouldn't use CC0 for software in the other link, but I am not aware that they recommend something else than CC0 if you really want to put it into public domain (which of course the FSF says you shouldn't).

By writing "actually the FSF does recommend...", you seem to imply that you are contradicting me, but you will notice that I never wrote anywhere that the FSF recommends the Unlicense over CC0. On the contrary, I said that they write that it is less mature than CC0. When I say, "the Unlicense is more appropriate for software", I am stating my own opinion, based on:

  1. the fact that it is a recognized open source license (in the sense of OSI) whereas CC0 isn't.
  2. that CC0 is anyway not recommended for software by the FSF (nor by the OSI).
  3. that it is recommended by GitHub as a public domain dedication (at least, that's how I interpret that this is the license that they have chosen to include in https://choosealicense.com/licenses/).

For the record, I consider that the FSF notes seem a bit inconsistent (it is not clear reading them what the FSF recommends to use as a public domain dedication for software) and that's why I wrote the following email to licensing@fsf.org back in February:

Hello,

I'm writing about what seems to me as an inconsistency in the page Various Licenses and Comments about Them (https://www.gnu.org/licenses/license-list.en.html).

The comment about the Unlicense says:

If you want to release your work to the public domain, we recommend you use CC0. CC0 also provides a public domain dedication with a fallback license, and is more thorough and mature than the Unlicense.

Therefore, for a long time, I have thought that CC0 was the right choice when wanting to put a work in the public domain.

However, since then I've read the comment about CC0 at https://opensource.org/faq#cc-zero regarding the explicit absence of patent grant, making this license inappropriate for software.

It turns out that looking more closely at the GNU list, it seems that the FSF agrees with this comment since it says:

For works of software it is not recommended, as CC0 has a term expressly stating it does not grant you any patent licenses. Because of this lack of patent grant, we encourage you to be careful about using software under this license.

The Unlicense is approved both by the FSF and the OSI and does not have this patent-related issue, so this might explain why it is one of the licenses listed at https://choosealicense.com/licenses/ to cover the full spectrum of free software licenses.

Therefore, my question is twofold:
- What is the public dedication license recommended by the FSF for software?
- Shouldn't the comment about the Unlicense be updated to recommend to rather use the CC0 license for non-software works only?

Thanks in advance,
Théo Zimmermann

Unfortunately, they haven't replied. If someone would like to write an email to follow up on this question, the reference to include in the subject line is [gnu.org #1806598].

view this post on Zulip Théo Zimmermann (Sep 27 2022 at 15:55):

Michael Soegtrop said:

I find the patent clause discussion about CC0 a bit artificial. It might be not so nice for the users, but most other licenses don't say anything about patents, and I am not sure it is much better for the user to walk in the dark. For you as publisher you might be better off with CC0 in case you unknowingly use some patent of someone else in your software. If you then silently license this patent to the users of your software, you might be in deep trouble. I find the explicitness of CC0 more appropriate than not saying anything about patents. Sure the issue that companies might lure users into patent infringement law suits via CC0 is there - but hopefully not an issue in the Coq ecosystem.

As Karl already expressed differently, open source legal specialists seem to believe that no patent clause is better than a patent clause that explicitly doesn't grant any patent because (IIUC) there is the possibility that no patent clause will be interpreted as an implicit patent license in at least some jurisdictions. This is why for instance there was such a fuss around the former React patent clause by Facebook (even though this one actually granted a patent license).

And to react to some other part of your paragraph, no open source license will ever put you at risk of infringing on someone else's patents as a publisher. Because these open source licenses (when they contain a patent clause) only deal with patents owned by the publisher and say nothing about other patents (except, in some cases, by saying that if a user attacks another user for patent infringement, then they lose the benefit of the open source license).

view this post on Zulip Karl Palmskog (Sep 27 2022 at 20:02):

one alternative to tap some additional expertise to understand the tradeoffs is to ask "what is the recommended public domain license for software" on https://opensource.stackexchange.com/

view this post on Zulip Michael Soegtrop (Sep 28 2022 at 07:15):

Théo Zimmermann said:

no open source license will ever put you at risk of infringing on someone else's patents as a publisher. Because these open source licenses (when they contain a patent clause) only deal with patents owned by the publisher and say nothing about other patents.

As I said, I don't see how saying nothing at all about patents can have such an implied meaning in all jurisdictions in the world. So your argument only applies to licenses which handle patents. For licenses which don't mention patents it is left to judges, possibly in a large number of countries following a lot of jurisdictions, to conclude on the implied meaning regarding patents of the license. This point makes me feel a bit uncomfortable.

view this post on Zulip Théo Zimmermann (Sep 28 2022 at 07:39):

I am going to stop arguing because this goes well beyond anything that I am able to evaluate myself as I am not an expert at all on this. My point is only that there seems to be a consensus among experts.

view this post on Zulip Karl Palmskog (Sep 28 2022 at 08:29):

again would be best to ask in some other forum, but my layman understanding of patent clauses is that anything explicit that you can point to in a court makes things easier for patent trolls to extract money from companies.

For example, if you own patent X, and some company was using a software license that explicitly disavowed patents such as CC0, then you as patent owner say, aha, they willfully violated my patent, they know [from reading the license text] that their license didn't grant them the right to use the patent.

If there was no mention of patent, you don't have such a clear case anymore, there are many more defenses a software user can make.

view this post on Zulip Michael Soegtrop (Sep 28 2022 at 08:36):

@Karl Palmskog : yes makes sense - law is not logic in the end.

@Théo Zimmermann : I think a question we should discuss is if Coq Platform should be CC0 or something else. As I said historically I decided for CC0 because the OCaml opam repo is CC0 and originally there was a lot of copying of files hence and forth between the OCaml opam repo and Coq platform local opam patch repo. But this is not the case any more.

view this post on Zulip Karl Palmskog (Sep 28 2022 at 08:40):

@Michael Soegtrop I think we agree 100% that the database part of the Platform (e.g., opam package definitions) should be CC0, so as easily copy stuff back and forth with OCaml opam repo. Where your opinion and mine diverge is w.r.t. the scripts (which are not likely to be used upstream). I think Unlicense would be better there, for the reasons discussed above. But maybe you want to open a Platform issue about it [or is there one?], and we accumulate pros and cons and eventually make a decision there.

view this post on Zulip Théo Zimmermann (Sep 28 2022 at 09:35):

IMHO if we change the license of the scripts only, then I would even recommend switching to MIT. Having two different public domain dedications in a single repositories would raise more questions than it would help I think.

view this post on Zulip Théo Zimmermann (Sep 28 2022 at 09:37):

Another solution is to use the Unlicense for everything because CC0 and Unlicense anyway allow you to copy-paste stuff without tracing where it comes from and thus there is no problem with the back and forth copying between the two repositories as long as both are dedicated to the public domain.

view this post on Zulip Karl Palmskog (Sep 28 2022 at 09:38):

OK, if we know switching back-and-forth between CC0 and Unlicense works, then that's fine with me to make the whole repo Unlicense. Also fine with MIT for everything.

view this post on Zulip Théo Zimmermann (Sep 28 2022 at 09:40):

MIT for everything would be problematic though.

view this post on Zulip Théo Zimmermann (Sep 28 2022 at 09:40):

I only recommended MIT as an option for the scripts part since there are no back and forth copying for them.

view this post on Zulip walker (Sep 28 2022 at 11:02):

Reading this thread is very funny (no disrespect intended) but If you sample any random opensource project though out the history of computers .... the probability of it running into patent issue is almost Zero.

view this post on Zulip Karl Palmskog (Sep 28 2022 at 11:05):

Coq is not really "any open source project" at this point, it has popularity on GitHub similar to Standard ML, and is being used in industry. So it's not really about probability of patent issues but signaling that they won't arise in the future.

view this post on Zulip Karl Palmskog (Sep 28 2022 at 11:06):

as seen with Debian, licensing/patents can prevent packaging too

view this post on Zulip walker (Sep 28 2022 at 11:07):

True, but unless I misunderstood the context, the question was about software that uses coq, not Coq itself.

view this post on Zulip walker (Sep 28 2022 at 11:07):

Karl Palmskog said:

as seen with Debian, licensing/patents can prevent packaging too

I didn't know that before, good to know xD

view this post on Zulip Théo Zimmermann (Sep 28 2022 at 11:26):

walker said:

True, but unless I misunderstood the context, the question was about software that uses coq, not Coq itself.

Indeed. And in fact, Coq itself is licensed under LGPL-2.1, a license that does not mention patents (because it was drafted before software patents started to become a problem).

view this post on Zulip Gaëtan Gilbert (Sep 28 2022 at 11:27):

our LICENSE file certainly mentions patents

view this post on Zulip Théo Zimmermann (Sep 28 2022 at 11:29):

Oh, so it looks the problem was not completely unknown at the time, but it doesn't have the patent clauses that are found in (L)GPL 3.0.

view this post on Zulip abab9579 (Sep 28 2022 at 11:36):

Were there lawsuits related with Coq?

view this post on Zulip Notification Bot (Sep 28 2022 at 12:44):

A message was moved from this topic to #Coq Platform devs & users > Platform licensing by Théo Zimmermann.

view this post on Zulip Paolo Giarrusso (Sep 28 2022 at 16:21):

Even without lawsuits, companies and distributors review licenses when evaluating what to use/distribute

view this post on Zulip Paolo Giarrusso (Sep 28 2022 at 16:22):

I'm not aware of licensing lawsuits, but there have been many cases where e.g. Debian refused to ship a Coq package because they messed up licensing.

view this post on Zulip Paolo Giarrusso (Sep 28 2022 at 16:24):

And there could be companies refusing to use libraries because they messed up their own licensing (say, they forgot to) or because their licenses have unfavorable conditions.

view this post on Zulip Paolo Giarrusso (Sep 28 2022 at 16:25):

Not only because of lawsuits; startups need to keep their affairs in order, lest potential buyers stop acquisitions during due diligence.

view this post on Zulip Paolo Giarrusso (Sep 28 2022 at 16:26):

TLDR worry about lawsuit avoidance, not just lawsuits


Last updated: Jan 29 2023 at 19:02 UTC