LWN: Comments on "Rug pulls, forks, and open-source feudalism"

SSPL is a free license

corbet — Fri, 12 Sep 2025 15:53:45 +0000

I see little value in continuing to go around in circles about this. The community consensus is clearly that the license is non-free. If you feel differently and want to use SSPL-licensed software, that's fine. But let's not belabor this point any more, please?

SSPL is a free license

immibis — Fri, 12 Sep 2025 15:46:48 +0000

Which doesn't prohibit using the software to run a service, any more than AGPL prohibits using the software to run a web server, or GPL prohibits distributing the software to your customers.

It may be poorly thought out, but it isn't nonfree.

SSPL is a free license

rqosa — Fri, 12 Sep 2025 14:32:45 +0000

Be aware that in this post from February 2019 to the OSI's License-review mailing list, the primary author of the OSD (and the DFSG), Bruce Perens, argued that section 13 of the SSPL does not comply with the OSD's criteria #6 ("No Discrimination Against Fields of Endeavor") and #9 ("License Must Not Restrict Other Software").

SSPL vs AGPL / Free Software / OSD / DFSG on what must be included

Wol — Wed, 10 Sep 2025 14:39:08 +0000

Then have a separate patent licence.

I agree with you that the "owning classes" as you call them are covetous and rent-seeking, but I think mixing copyright and patents is a stupid thing to do.

They're also fundamentally different in that program copyrights (outside of the US) have *always* been treated as a "written work", and it makes sense that way. They are, basically, a mathematical treatise. And written works are not patentable. Nor are mathematical proofs. And programs are also just a (not necessarily correct :-) mathematical proof. So software patents are completely different in that they are figments of miserly lawyers' imagination, not something that actually exists.

So my patent licence would simply be "By distributing this work you accept that it is not patentable material, and you therefore agree not to sue anyone using it for breach of patent. This does not bind your defence in any way shape or form if you are sued on patent grounds for using this work". But that would be *separate* from the copyright licence.

Just as trademark law is a completely separate, third branch of IP, and the GPL explicitly says nothing about it other than explicitly saying you are allowed to exercise it over GPL'd works (and you should be - trying to ban it would be a very stupid thing to do...)

Cheers,
Wol

SSPL vs AGPL / Free Software / OSD / DFSG on what must be included

arsen — Wed, 10 Sep 2025 10:30:32 +0000

> The GPL v3 (and other licences) added patent law into the mix, which I personally think was a mistake.

Why? The goal is to undermine all sorts of restrictions that are placed by the owning class on users. Patents are, in this regard, no different to copyright.

SSPL vs AGPL / Free Software / OSD / DFSG on what must be included

Wol — Mon, 08 Sep 2025 10:00:17 +0000

> > The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open source software."

> That - linking without linking - is exactly what the SSPL is meant to prevent.

Which means that the SSPL is not a *COPYRIGHT* licence. The GPLv2 set out to be a *copyright* licence, which meant that it did not talk about anything other than copying, distribution and *LINKING*, because copyright only extends as far as derivation. And derivation is a legal concept, not anything the FSF/GPL have jurisdiction over.

The GPL v3 (and other licences) added patent law into the mix, which I personally think was a mistake.

The SSPL is now trying to add other stuff - over which it has absolutely no legal jurisdiction - into the mix. This effectively results in a licence where compliance is impossible, because it is demanding actions over which it has no lawful authority, and which (as other people have pointed out) are quite likely to be illegal.

Cheers,
Wol

Corruption?

smurf — Mon, 08 Sep 2025 05:17:55 +0000

You can be corrupt, in the sense of violating the principles you're ostensibly holding up (in exchange of material or other gains), without actually going beyond the confines of your country's legal code.

That being said, I don't think OSI is. They may not always do what you and me would like them to do, their ideas about the free-ness of AI models are ample proof of that, but this by itself is neither necessary nor sufficient.

Words have definitions. Definitions matter. Guidelines matter. But wanting doesn't mean having.

jjs — Mon, 08 Sep 2025 02:40:11 +0000

And is one of the reasons it fails - it contaminates unrelated software (guideline 9 of the OSD and guideline 9 of the Debian Free Software Guidelines - https://www.debian.org/social_contract#guidelines). As pointed out by someone else, since it specifically includes "hosting software" and if you host it on Microsoft Windows, you would be mandated to release the source code for MS Windows, which you don't own. Same with a backup program - suddenly I have to include my commercial backup software that I purchased from a commercial vendor under a commercial, non-free license.

"linking without linking" - Repeat that phrase a few times - "Doing A without doing A".

Linking in software has specific meaning. From CMU (https://csapp.cs.cmu.edu/2e/ch7-preview.pdf) "Linking is the process of collecting and combining various pieces of code and data into a single file that can
be loaded (copied) into memory and executed. Linking can be performed at compile time, when the source
code is translated into machine code, at load time, when the program is loaded into memory and executed
by the loader, and even at run time, by application programs."

How does a commercial backup software "link" to the software? If so, it does so with every piece of software on every system it backs up. How does a commercial monitoring software that uses defined APIs "link" to the software? How does running the software in a container on Microsoft Windows cause Windows to "Link" to the software? Per Section 13 of the SSPL, they all need to be distributed with the SSPL code. Define how each of them links, per the definition from CMU, to the software.

If I wrote the monitoring software BEFORE I encountered the SSPL software, made no changes to it, or even purchased it, I cannot redistributed the SSPL software (even unchanged) on a disk without including my monitoring software (which I have may not have the right to redistribute, because I didn't write it and control the license). Even though many programs may do the exact same thing. Even if I include some other program that does the exact same thing but is Open Source, I can't distribute because that software is not what I'm using. F/LOSS software does not contaminate other, unrelated software. SSPL does.

Short answer as to how they "link" (per the CMU definition above) - they don't.

Don't get me wrong. MongoDB owns the software. They can license it however they want. But that a) doesn't mean anyone else has to use that license, and b) that just because they want it to be considered an Open Source License that it is one.

BTW - still awaiting answer to:
"But they are a corrupt institution." (referring to OSI).

That's a serious allegation - feel free to provide verifiable evidence of that (and no, the fact that they have corporate sponsors doesn't make them corrupt. If it did, every non-profit in the world would be considered corrupt).

From Wex (https://www.law.cornell.edu/wex/corruption): "Corruption is the dishonest, fraudulent, or criminal use of entrusted authority or power for personal gain or other unlawful or unethical benefits. "

From the law dictionary of corruption (https://thelawdictionary.org/corruption/): "Illegality; a vicious and fraudulent intention to evade the prohibitions of the law. The act of an official or fiduciary person who unlawfully and wrongfully uses his station or character to procure some benefit for himself or for another person, contrary to duty and the rights of others."

I'd be very interested in seeing the verifiable evidence you have that they have committed such acts. I imagine legal authorities would be interested as well.

SSPL is not a free license

tialaramex — Mon, 08 Sep 2025 00:29:52 +0000

I would summarize the expressed opinion in the Debian link rather as "This is clearly not Free Software".

I appreciate that this is in direct opposition to your view, but when everybody else says that's a dog and you're still sure it's a cat, it's time to re-consider, isn't it in fact possible that you're just wrong and it is a dog after all ?

SSPL is a free license

linuxrocks123 — Sun, 07 Sep 2025 20:49:11 +0000

You: This power supply is UL-listed!
Me: No, it doesn't appear on their list of certified devices.
You: Absence of evidence is not evidence of absence!

SSPL is a free license

immibis — Sun, 07 Sep 2025 17:26:46 +0000

Absence of evidence is not evidence of absence - you've quoted Debian basically saying "we don't want to have to deal with this" and if you look up the FSF's position, it's basically the same thing.

SSPL vs AGPL / Free Software / OSD / DFSG on what must be included

immibis — Sun, 07 Sep 2025 17:25:27 +0000

> But, with AGPL, I can bundle a monitoring tool that interacts with my software only through defined APIs with my software

That - linking without linking - is exactly what the SSPL is meant to prevent.

Make assumptions about the ecosystem explicit

k3ninho — Sun, 07 Sep 2025 08:16:11 +0000

> The problem often comes down to the simple fact that companies have to answer to their investors, and that often leads to pressure to relicense the software they have created in order to increase revenue.

There's an assumption hiding here that drives the whole fork and/or rugpull situation: action by the company won't affect the surrounding ecosystem, that's to say actions to raise revenue won't deter free-at-point-of-use customers from contributing fixes or features and will definitely convert them to paying licensees.

Companies have to answer to shareholders but they have to do this within the scope of the customers and cashflow of their business -- and these rugpulls and forking events alter the ecosystem around a company in ways the investors won't expect. The systems-thinking view or a power analysis would raise these as risks not to mess around with. There's always room for "destroying customer relationships or harming base resources that your business relies on -- those are things which will cause your business to fail, even if your investors insist you do them."

K3n.

SSPL is not a free license

smurf — Sun, 07 Sep 2025 06:56:47 +0000

Yeah, it's the same principle, much like jumping the bottom three steps on your way down some stairs involves the same motion as jumping off a cliff. That doesn't make the results equivalent in any way, shape or form.

The SSPL doesn't limit its scope; heck it even says so, quite unequivocally. You have the source code to your UEFI bootloader, and the network card's firmware, and your backup software, and all the other stuff the license mentions and/or implies? No? Surprise: (almost) nobody has. Thus de facto nobody can provide networked services using SSPL'd software, thus the license limits what the software may be used for, thus SSPL'd code is not free by, well, basically every definition of Open Source out there.

SSPL is a free license

linuxrocks123 — Sun, 07 Sep 2025 00:54:04 +0000

No. You're wrong. Give this up.

OSI has rejected it as an open source license. Debian has rejected it as DFSG-compatible. FSF does not list it as a license for free software.

https://opensource.org/blog/the-sspl-is-not-an-open-sourc...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915537
https://www.gnu.org/licenses/license-list.html

None of the three organizations in our community that are respected for the purpose of classifying licenses as sufficiently free for use by the community has stated that the SSPL is free. The SSPL is therefore not a free license.

You want to say it's an immibis-compatible license, go ahead. You want to say all three of our license-approval organizations suck, go ahead. But it's not open source, it's not DFSG-compatible, and it's not Free. Those decisions are not yours to make, and those decisions have been made.

SSPL is a free license

NYKevin — Sat, 06 Sep 2025 22:11:38 +0000

That's much more vague and more likely to be interpreted in a limited fashion (contra proferentem). But when the license actually says "all programs that you use to make the Program or modified version available as a service," there's only so much room for interpretation.

SSPL is a free license

bgilbert — Sat, 06 Sep 2025 20:44:13 +0000

The old Sun RPC license required that this legend is included on all tape media and as a part of the software program in whole or part.

Probably they meant all tape media with Sun RPC on it, but you never know.

SSPL is a free license

NYKevin — Sat, 06 Sep 2025 20:05:38 +0000

But there is no limiting principle. The phrase "all programs that you use to make the Program or modified version available as a service," if taken seriously, could plausibly implicate all sorts of things:

* You run the service on Linux, so you need to provide the Linux kernel under the SSPL.
* You run the service on a virtual machine that somebody else (e.g. AWS or GCP) hosts, so you have to provide the source code for their hypervisor (and possibly other components, further down the stack, that you don't even know about).
* Your engineers use laptops or workstations to develop the service, so you need to provide whatever IDE they are running under the SSPL.
* Oops, one of your engineers installed Vim or Emacs without telling you, now you need to provide Vim or Emacs under the SSPL.
* Your engineers use iPhones and/or Android devices to receive urgent notifications ("pages") when your service fails in production. This is necessary to make the service work reliably, so you need to provide iOS and/or Android under the SSPL.

You will probably say this is a nonsensical overreading. I agree it is nonsensical, but there is nothing in the license which actually *says* as much. That's a problem.

SSPL vs AGPL / Free Software / OSD / DFSG on what must be included

jjs — Sat, 06 Sep 2025 18:38:13 +0000

If I have a system tool that I use to monitor my SSPL licensed software, If I bundle my software into a distribution disk, all of it has to be Open Source, per the SSPL. Therefore, that tool needs to be released as Open Source, per the SSPL.

But, with AGPL, I can bundle a monitoring tool that interacts with my software only through defined APIs with my software, because, in accordance to the OSD, I don't need to have everything on the distribution Open Source. Only my "Corresponding Source Code" for my project.

OSD (https://opensource.org/osd) Clause 9:
"
9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open source software."

AGPL (https://www.gnu.org/licenses/agpl-3.0.en.html) Clause 5:
"A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate."

Again, note here that I'm using the monitoring tool that connects via an API, that I am using to make the software service work for me to provide service to you. AGPL specifically excludes things that interact through an defined API (see clause 13 in the link above).

Check out clause 13 under https://webassets.mongodb.com/_com_assets/legal/SSPL-comp... where you can see the changes MongoDB made to the AGPL. My monitoring tool is specifically included in their license. So under the AGPL, I can use a commercial monitoring tool with my software and not have to provide it if I provide my program. Under SSPL, I have to provide it under an Open Source License. As a company, this puts restrictions on them that Free Software (OSD/Debian Free Software Guidelines/OSD) specifically forbid from being included.

SSPL is not a free license - Per Open Source Definition

pbonzini — Sat, 06 Sep 2025 15:52:16 +0000

"Interacts with" is not included in the license. Backup or monitoring software does not interact with the database, it's only used in the same system.

The discrimination against fields of endeavor is also at least plausible. The AGPL instead only extends the circumstances under which you shall provide the sources.

SSPL is not a free license - Per Open Source Definition

immibis — Sat, 06 Sep 2025 15:09:59 +0000

"interacts with" is completely different from "is distributed with"

SSPL is a free license

immibis — Sat, 06 Sep 2025 15:09:21 +0000

It's exactly the same principle as not being allowed to link AGPL software to proprietary libraries; they just updated it because software is now typically "linked" by looser mechanisms.

SSPL is a free license

smurf — Sat, 06 Sep 2025 14:15:30 +0000

To quote the SSPL:

"Service Source Code" means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

Oops, you now cannot use a commercial backup system for which you don't have the source code in conjunction with the SSPL-licensed service you're offering. Also does "storage software" incorporate the firmware of your disk drive or not? far from clear just by reading this license, that "without limitation" clause does raise a red flag or three, doesn't it?

Sorry to be blunt, but that kind of overbearing restrictive language is the antithesis of OSS. My conclusion is that anybody who proclaims the SSPL to be "free" either didn't read it or has an agenda. Or both.

SSPL is not a free license - Per Open Source Definition

jjs — Sat, 06 Sep 2025 14:15:06 +0000

SSPL violates guideline 9 of the Open Source Definition (https://opensource.org/osd):

"9. License Must Not Restrict Other Software

By the terms of the SSPL, all other software that interacts with the SSPL'd software must be Open Source (https://webassets.mongodb.com/_com_assets/legal/SSPL-comp... - see Section 13). Violation of OSD #9 (which is derived from the Debian Social Contract Guidelines - https://www.debian.org/social_contract#guidelines).

"But they are a corrupt institution."

SSPL is not a free license

DemiMarie — Sat, 06 Sep 2025 13:39:36 +0000

The SSPL could be viewed as requiring the Linux kernel and firmware to be released under SSPL. A Raptor Computing Systems box using a BSD could comply but that’s the only case that I know could (and even then only if the firmware license is permissive).

SSPL is a free license

claudex — Sat, 06 Sep 2025 13:15:42 +0000

> You can also check the license text itself and verify that it doesn't "discriminate against a field of endeavour". I recommend finding the plain text version, and diffing it against the AGPLv3. They differ only in the name of the license, and one short section.

Yeah, that's the section that is considered the issue to be able to use the software to provide the service. As it requires to publish all code that interact with the software, like monitoring, backup and storage code. That's a big difference with AGPL.

> "Service Source Code" means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

SSPL is a free license

immibis — Sat, 06 Sep 2025 12:24:04 +0000

There's a mistake in this post: SSPL is actually a free software license.

The confusion comes about because the OSI declared it to not be open source. But they are a corrupt institution. Their explanation[1] makes no reference to the license text whatsoever, only vague handwavey excuses that apply equally well to AGPL, and the members/sponsors of the OSI are primarily companies that sell cloud stuff and have a strong interest in preventing more software from using the SSPL.

You can also check the license text itself and verify that it doesn't "discriminate against a field of endeavour". I recommend finding the plain text version, and diffing it against the AGPLv3. They differ only in the name of the license, and one short section.

[1] https://opensource.org/blog/the-sspl-is-not-an-open-sourc...

[2] https://opensource.org/sponsors

[3] https://spdx.org/licenses/SSPL-1.0.html