Why don't we have a permanent OSS license?

6 Jul 2025, written by Mathew Pregasen

Developers are losing faith in commercial OSS

In recent years, we’ve seen some massive OSS-founded projects ditch OSS in favor of a proprietary source-available license. Some of the big ones include Elastic in 2021, MongoDB in 2018, and HashiCorp last year. There are two motivating factors behind these license swaps: targeting cloud providers from selling managed solutions as first-party products and hampering startups that fork the source code and build a niche offering.

The public’s reaction, evidenced nicely by this Reddit thread, isn’t enthusiastic. While many developers understand the business reasons behind this switch, there’s a bad taste to OSS being used to build public trust, only to be ditched post-success. And while the public could fork the final OSS commit and develop independently, there’s little practical faith in that happening. The good example is OpenSearch, a fork off of Elasticsearch that’s maintained by AWS that has decent adoption but is paltry compared to the flagship product.

Because of the frequent abandonment of OSS, there’s growing public distrust of the intentions behind commercial OSS software. The OSS label is feeling more like performative marketing than actual community altruism. To be clear, commercial OSS projects always had business intent, but there’s a difference between monetizing managed OSS over using OSS as a bait-and-switch.

This all said, there’s still evidence that commercial OSS at scale can work. Kubernetes, Docker, GitLab, Infisical, PostHog, and Wordpress are great examples. Notably, Elastic returned back to OSS in 2024, announced with a Kendrick Lamar themed blog post. What’s missing is faith that the OSS license will remain appended to future commits.

An idea: Permanent OSS (POSS)

This prompts an idea: what if companies could legally commit to publishing code as Permanent Open Source Software (POSS)? This might sound impossible—after all, one of the tenets of OSS is you can build commercial, proprietary software from the license. But there’s a middle ground approach: separating ownership and development.

The Universal Entity

For a POSS license to work, there needs to be a trusted public entity (TPE). It might be owned by the Open Source Initiative or a similar public institute. The role of the TPE is to own the copyright to every POSS project. Accordingly, when a new startup or existing company wants to start a new POSS project, they will:

Assign ownership of the project’s trademark, repository, and documentation to the TPE
The TPE will sign a Contributor License Agreement with the original developers, delegating them as the managers of the project

Accordingly, the TPE owns the material associations of the project, but delegates development to the project developers. Those developers could still launch a paid, managed offering or premium features—after all, it’s open-source. But splitting ownership and development creates permanence.

What if the company wants to ditch OSS?

A POSS arrangement doesn’t prevent a company from ditching development of the OSS project. They are within their rights to fork the POSS repository and continue development under a new license. The difference is that they’re operating at a similar playing field as anyone else: they’ll have to shed the previous branding and convince users to migrate from one repository to another. This introduces ample friction that’ll force businesses to only commit to a switch if it’s a dire situation—something the community will likely back.

Comparison to foundations behind Apache, Linux, etc

There are existing software foundations and champions of open source, such as the Apache Software Foundation, Linux Foundation, Eclipse Foundation, and Software Freedom Conservancy. These organizations have similar agreements with one another to protect open-source projects. The difference is a POSS license would be designed to service commercial OSS projects that are making a strong commitment to OSS, but retaining the otherwise commercial aspects of their business.

What about strong copyleft?

There’s an argument that the benefits of a POSS already exists in the form of a strong copyleft license. Because strong copyleft requires for derivative works to fall under the same license, there’s an argument that it solves the problem. But many OSS projects don’t use a strong copyleft license because it stifles the business use case of the software. Proprietary features are somewhat essential to make commercial OSS tenable—the revenue needs to come from somewhere. Instead, the goal of a POSS is to target businesses that see the merits of an MIT license and want to commit to maintaining that.

Is this actually possible?

Truth is, I don’t know. Perhaps businesses would be too spooked by the permanence to commit to building under a POSS arrangement. But I’ve met founders that have no intention of ditching OSS ever. Their business model doesn’t mandate them to do so. So my gut says yes—if the system was in place, businesses would commit to a POSS arrangement to strongly signal to developers that they’re building a community product. Notably, if POSS becomes popular, it’s possible that other businesses that would’ve otherwise been closed-source would opt for OSS licenses because of the appearance of that being the new middle-ground.

I’d love to hear your opinions on this. I’m not a legal scholar or even a licensing expert. I’m just a technical writer that’s worked with many open-source projects, and I hear the frustration from both OSS users and OSS developers of the current state of OSS. The concept of a POSS is the first solution that came to mind.