I know I am tooting Sentry's own horn a bit here, and since I was involved it is close to my heart. We struggled at one point with how to build a large company on top of an open source project, and we never liked the idea of simply carving out parts of the codebase and marking them as closed source (open core). At the same time, there was always the latent risk that even if you put 95% of the energy into the product, you were still not fully in control and someone else exploits the economic value without investing.
Our way of dealing with this was delayed open source publication. That led to the FSL [1], and later to bootstrapping the Fair Source initiative [2] to establish an umbrella term that does not conflict with Open Source. What I have found interesting in the years since is that many companies are wrestling with the same problem, but feel that the two year head start the FSL gives is too aggressive.
I actually still find that surprising. I would like to know whether this is a legitimate concern that two years is not enough, or mostly a perceived one. To me, moving to an Apache 2 or MIT license after a relatively short period is a much stronger statement than a license that risks the project effectively ending if the commercial entity is unwilling to relicense it more openly at the end of its life such as the O'saasy license.
Isn’t the “solution” for Sentry that deploying it is such a pain in the ass that no one bothers to really do this? I haven’t checked in years but that always seemed like the real competitive blocker?
If you need less scale/features go for glitchtip. If you’re not going for k8s, the self-hosted docker-compose version of sentry works fine including proper releases and support by the sentry team etc. Just experimental newly introduced features can be a bit wonky.
They are doing much more than just throwing code over the fence. Also phone home telemetry is optional and there’s a switch for just errors mode. IMHO this really builds trust.
With regards to deployment complexity: well it’s built for handling high volumes of events. I’d reckon this is more a consequence of scaling the project rather than a coordinated plan to push people to their cloud offering.
If you do go for k8s or choose to deploy the stack yourself, you even get access to the full scale solution. But if you’re at that scale, you probably have someone hanging around who knows how to run your clickhouse setup. You still get the full sentry software and SDKs for free in that case. I think this is as fair as it gets with regards to the open source SaaS model.
This may very well be caused by my incompetence, but Sentry's docker-compose setup has never survived for more than a few months under my control. Something always destroys itself without an obvious reason sooner or later, and either refuses to start, or starts and doesn't really work. I tried updating it regularly, tried never updating it, getting the same treatment either way.
I did not intend to be critical of their work. They're doing OSS as best as they can and good for them. I am just saying that it's a different beast if Sentry is OSS vs a much simpler to operate OSS product. Licensing matters less when the operational cost acts as an inhibitor to adoption of your OSS offering.
True, opportunity cost is a factor, sorry if my reply sounded a bit brash. IMHO they are one of the few orgs who got this model right compared to lots of others who went the open core or support/consulting contract required OSS route.
Agreed. It was easier for me to rebuild parts of it for my own use than to self-host it. At my scale, a single DB works well as a datastore instead of Clickhouse/etc.
But then again I think this only prevents small players from "competing" by self-hosting, so the revenue loss there would be minimal either way. Large enterprises are too incompetent to even self-host a single self-contained binary, so for those the availability of source code and ease of hosting would make no difference, they would still use the SaaS.
I'm personally on the fence how much of it is intentional... from the_mitsuhiko's side it probably isn't, but "the purpose of a system is what it does" and all.
Don't believe the salesmen, self hosting Sentry has been the most liberating feeling in a long while. Buy a cheap dedicated server with 64 gigs of RAM from Hetzner, run their install script and it's literally up and running. I'm processing volumes that would bankrupt me on their managed service without breaking a sweat.
> Isn’t the “solution” for Sentry that deploying it is such a pain in the ass that no one bothers to really do this?
That Sentry is a pain to deploy is not really intentional, it just happened over the years. However because it's a pain to deploy it also opens up a market for people that create managed deployments so I would say, that if anything, it made it worse. For self deployed Sentry you do not need to pay cent, the license explicitly allows it.
The end of life problem can be solved by source code escrow, with a clause putting the code under an open source license and published in case of the demise of the owning cpmpany.
This is the entire point of Fair Source undergoing delayed Open Source publication -- to codify the forward-path into the license itself, without the need for external source code escrow services.
With O'Sassy specifically, the end of life problem solves itself. If the original vendor stops offering the software, a third party offering the software is not competing with the original vendor. Thus, the third party can offer paid hosting for the software if the original vendor does not.
Why not just release the software after your set threshold of time versus opening it up with such a license? To get eyes on it before-hand?
Also how does this work with contributor contributions? Does the owning SaaS get the benefit of contributor work instantly while everyone else has to wait 2 years? What about the contributers themselves?
presumably because a) it still allows the source code to be available and used for the 'permitted purposes' (i.e. anything that's not directly competing), and b) it represents a concrete commitment to open up, not just a pinkie promise (even if they were to have a license or contract which promised it, it would not be as easy to rely on as actually having the source code published. Companies have reneged on such promises before).
And yeah, by my reading essentially people can contribute code or publish patches (with just a plain MIT license in principle), just the original and derivatives still can't be used for non-permitted purposes until the timer is up.
You may want to allow certain uses (self-hosting, etc) even before it transitions to a fully open-source license. Having access to the source code can also help SaaS users debug certain situations.
> you were still not fully in control and someone else exploits the economic value without investing
O'Sassy came up recently in one of the forums I lurk in [0], and as discussed there, I tend to agree with Adam Jacob (SystemInit) and others that FSL is definitely one way out but doesn't totally solve the commercialization aspect, because the code & all that IP is still readily available.
Adam, in this talk [1], argues that like RedHat (and unlike Canonical), Open Source businesses must learn to separate source license from distribution license and if they do so, the money is there to be made (in a b2b setting, at least).
> What I have found interesting in the years since is that many companies are wrestling with the same problem, but feel that the two year head start the FSL gives is too aggressive.
... if the companies conflate Open Source and business models, rather it being merely a Go-To-Market (like open core).
Especially true for dev/infra upstarts competing with incumbents (PostHog v Amplitude; GitLab v GitHub [2]), and lately for AI labs (DeepSeek/Qwen/Llama v GPT/Gemini/Claude). In a role reversal, BigTech also uses Open Source to commodotize its competition's advantages (Android v iOS; k8s v Swarm; Firefox/Chrome v IE) [3].
> So people can argue it doesn’t work, but so far we only have evidence to the contrary and Sentry is quite successful
So, RedHat has also been successful?
GP says that some companies don't find FSL aggressive enough, despite it having worked nicely for Sentry. And that's similar to the point Adam makes: That Open Source (per OSI not FSF) is a development model not a business model. Companies that don't want/need to prioritize collaboration tend to use FSL / BUSL / etc; but those licenses aren't really going to significantly change their development or business (other than prevent competition from using it as-is, but now the code is out there anyway [0][1]), and so they might as well go close source (and Lockdown the code, too).
> issue is these are mostly academic points of view
Both, commodotizing competition (through OSS) and using OSS as Go-To-Market aren't academic PoVs, I don't think.
I'm not talking about RedHat, I'm talking about the perspective that "FSL / BUSL aren't effective enough". They solve the problem. O'saasy is just freeware at the end of the day, FSL creates more open source, and BUSL often has (though unfortunately the license doesnt require it).
The idea that FSL ~= Closed Source is entirely wrong and misunderstands the value that an open distribution gives. We have 10s of thousands of customers that run Sentry self-hosted. We regularly get contributations back to our core service - both in code and (what we prefer) other artifacts like feedback.
We were "Single Origin Open Source", which is extremely common whether people like to believe it or not. Its the entire premise of the sustainability issue in the industry. Thats not just an issue for commercial entities, its also most of the big open source software people rely on. In our case though we have a great business model that makes it entirely sustainable, and now have built a solid licensing mechanism around it that protects that, while ensuring our community is still successful.
These same issues around single origin open source are why we started the no-strings-attached funding mechanism via Open Source Pledge (https://opensourcepledge.com), why we push Fair Source (https://fair.io).
Maybe others will find defensible models, but I'm skeptical. I also respect Adam, but last I understood it the model they were going after sounded pretty similar to trademark protection (which doesnt work).
It is not open source, it is not free. It’s a term tacked on to the MIT license.
It’s also vague as, what if I run a VPS provider and someone can upload images to a marketplace like thing, does that count as SaaS? How about if someone’s only use of my services is to run that image?
Steer clear unless you want to open yourself up to the copyright owners opinion changing. (See for example the pine email client and the copyright discussions there.)
> It’s also vague as, what if I run a VPS provider and someone can upload images to a marketplace like thing, does that count as SaaS? How about if someone’s only use of my services is to run that image?
This strikes me as somewhat contrived. Like yeah, if you're gonna do some weird button-pushing thing, it's not worth it, steer clear, keep this product off your platform, easy. Is a piece of software really only of value to the open source community if any kind of unscrupulous use of it is allowed?
There's a million ways to get value out of source code that don't involve pushing the envelope. I've accepted every EULA ever without reading and never once worried I would get in trouble with any of them, it's generally pretty easy if you're not trying to invent ways to do so.
> Is a piece of software really only of value to the open source community if any kind of unscrupulous use of it is allowed?
It's not even open source in the first place if any kind of unscrupulous use of it is disallowed, as that would be discriminating on use case. It ultimately doesn't matter much to the open source community, as it effectively can't be used in otherwise open source projects, as the result wouldn't be open source and it is going to be license-incompatible with many projects anyways.
That said, I find it preposterous to accept this notion even ignoring that point. You shouldn't have to take it on faith that what you're doing is allowed by the copyright license—the whole point of the license is to make that clear. Everybody always shrugs off the risk of a malicious owner until Oracle acquires their dependencies.
I understand that it's not open source. I just see it as like, a spot where a company that would normally make a closed source product wanted to make it more open and hackable and did actually put the code up and take contributions, which should be a kind of good thing, but it's automatically assumed to be the worst, a rugpull, etc. What if I operated in an ethical gray area right around this pretty reasonably worded term?
I was trying to make the point that "unfree" software is not really useful at all to the "open source" community, and not because of terminology nitpicking but because of the consequences that has.
But anyway, my problem with a license like this is indeed the existence of gray areas. Open source licenses are in some ways clever attempts to make a social contract into a legal obligation. It isn't perfect, but the side effect is that you don't have to take it on faith that people will follow it: people can be sued for violating it, and depending on how that Vizio case goes, it's not just the copyright holders who are eligible.
But that's a two way street. In return, I shouldn't have to take in on faith that my use case is legal according to the copyright license: it should be clear as day with no room for interpretation. If it's not, then my best hope is to simply never get sued. That is not good. Hope is not a strategy here, not for individuals and not for corporate users.
Business/"fair" licenses seem to offer a good compromise, but it's a mirage: the software still has to be treated a bit like toxic waste in Linux packaging, won't be compatible with strong copyleft licenses, and ultimately, presents an uneven playing field for contributors.
There isn't much to be excited about from a hacking PoV.
With projects like these, you're probably already going to be submitting your code under an unconditional CLA, which essentially forfeits your rights as a contributor, then if it's this license, you also are giving the original copyright owner more rights to use your contribution than you even have.
I don't think this is a good or healthy status quo at all.
The only upside of this is that it protects someone's business model from competition. Well good for them.
But making the license look like MIT is just a bit of cosplay, yet another attempt to try to push something as being open source when it's not. This cognitive dissonance can't go unnoticed; it really does trick people if they don't fully think through the consequences. You're better off going with a license that makes no attempt to pass itself off as open source.
Before this O'Saasy situation, I hadn't fully understood how much ideological purity was baked into the the term "open source," which to be fair is not really implied by such a general term.
I still feel like it would be a happier world if open source was more of an umbrella advocacy organization containing free software and source available, but now I understand that that's not going to happen.
I'm not the one dismissing anything. I'm arguing for tolerance, goodwill, and cooperation. There are lots of practical concerns in life, there are tradeoffs, there is balance.
A few days ago you said "the impression the different groups have different ideals is correct." You've spoken mostly in mystical aphorisms so it's been hard to glean much.
> I'm arguing for tolerance, goodwill, and cooperation.
These qualities are not absent because people differentiate source available and open source. And you continued today to argue these qualities should be expressed by changing the meaning of open source.
> A few days ago you said "the impression the different groups have different ideals is correct."
Your point was what? You thought a group had ideals meant a group's only motivation was ideological purity?
> You've spoken mostly in mystical aphorisms so it's been hard to glean much.
No. And several other people communicated similar ideas.
The only major ideological component of this matter is that both the free software movement and the open source movement are concerned with the rights of end users, not the sustainability of businesses. That's really it. Open source has always been much less focused on ideology and more on practicality; I reckon that's part of why it is the more prevalent movement in the first place.
But just because it's not about ideological purity, that doesn't mean it can just be a lawless free for all, because it would essentially destroy the utility of open source in the first place. Please read this sentence carefully and understand the implications, it is extremely important: The AGPL is a less permissive license than O'Saasy, yet it is an actual true open source license. This is not because of ideology. This is because open source doesn't practically work without the constraints in the definition.
I already listed some serious practical concerns, along with the problem that it disturbs the balance between contributors that makes open source work on a social level. However, I honestly feel like it's just scratching the surface. If you keep itching at the practical implications, it only gets worse from there.
For example, let's say there are two MIT licensed projects. One of them wants to adopt code from the other. No problem at all: just copy it in and make sure to have the correct copyright notices attached. Done.
Now, let's say you have two projects with the O'Saasy license. Uh oh: this doesn't "just work" anymore, because there are two "original Licensors" and this clause conflicts with itself in the two different invocations.
If you can't even share code between projects with the same damn license, I really feel like your argument for how this still totally counts as open source is just weak as all hell.
Now I get that some people take issue with the fact that there even is a socially-held definition of what "open source" means, but if there wasn't, and it was a total free-for-all, the communal nature of open source simply wouldn't work. And the irony of all of this is that part of the reason why so many SaaS companies want to release their projects as open source is because of how amazing it is for their PR and early adoption. And that has happened because of the careful coordination of the open source definition, to try to gatekeep the movement. Not for ideological reasons, but literally to ensure that the utility of the concept is able to be fully realized.
It isn't a huge deal if shared source, source available, "fair source" or whatever else people want to exist exists. In fact, it's much better if we don't dilute the meaning of open source with stuff that is so practically different anyways. And if the concept of shared source projects is really so enticing, it should be able to gain relevance the same way open source did.
Of course, in reality, if we stop pretending and playing devil's advocates for five whole minutes, we can all admit to ourselves that companies that would use these licenses usually have very good reason to worry about their business model and the odds are very good that the software will either be unavailable or significantly more closed off down the road.
Some will argue that this isn't a rug pull. After all, it's free and you're entitled to nothing. And I do actually agree with that "you're entitled to nothing" part, but the trouble is when you start trying to take the valuable brand of a movement like open source as a marketing tool only to pull the rug later. And yes, it is a rug pull. Whether it's legal or perhaps even fair, it's still a rug pull. Like if I pull a homeless guy off the street and offer him a bed to sleep in and food, then cut it off abruptly 6 months later, most people would definitely see how it is totally reasonable for me to not have to indefinitely bear the burden of trying to support this person. The trouble isn't that they deserve my financial support, it's that I offered it and then simply abruptly cut it off. That's a rug pull. That's what MinIO did: they gave us an option under the same pretenses we've enjoyed software like Linux or PostgreSQL under, then decided to just simply discontinue it. No warning, it was just gone. Either pay for AIstor or your production infrastructure is now running unsupported code that will not be patched. Hope you didn't use it anywhere important. ("If you used it somewhere important, why not pay?" Sure. Now tell that to e.g. non-profits with shoestring budgets that chose open source because they couldn't afford anything else.)
And, I honestly believe that these unfair CLAs that allow this behavior have done immense damage to the "brand" of open source. It isn't just a niche thing: almost every startup does it now. Very few organizations use more reasonable CLAs that answer practical concerns while still ensuring that contributors are not taken advantage of. Even fewer organizations stick to just DCOs that fulfill the minimal legal obligations. Most of them are doing the same thing, for the same reason. And I'm sure that the founders may genuinely believe that they have no intention of hitting the big red button unless they need to, but I think it's fair to say that ignorance is not a good excuse here. We've seen this game play out too many times.
The "open source but not" license is just another extension of this awful practice, and it only serves to muddy the waters. We should celebrate rather than mourn the fact that open source has gatekeepers trying to ensure that the term doesn't wind up fucking meaningless in a pursuit to burn as much VC money as fast as possible so already well-off dudes can get richer. Ideological purity is mostly not of interest to me, other than my belief that open source should be about the rights of users. Other than that, the problems here are purely practical, and the practical problems are quite severe.
So what should SaaS companies do, then?
- If they really want to be truly open source, they should release code under the AGPL. The major cloud providers are immune to even touching AGPL code anyways, but even if they decide to stop pushing dumb FUD, for all it's faults, AGPL would ensure that they can't just run with it; they have to contribute their changes upstream.
- If they actually just like the practical utility offered by developers having source code access, they can release the software not under an open source license. Since the code isn't of use to the open source community, it doesn't matter much if it's a "shared source" license or not; a traditional EULA is just as fine, and doesn't feel like it is masquerading as if it's part of the open source ecosystem.
(Edit: though there are some clever other options, like the time-release licenses that go open source after a period of time. I honestly see far less problem with this sort of license, though to avoid ambiguity it would also be good to explicitly release old code under a pure open source license, just to avoid the question of whether or not the time-release concept would work properly in court. I have seen this done already. This seems like a neat workaround at least.)
- Or just simply don't even release the source. There is plenty of closed source software in the world and I really don't think most open source advocates are even bothered by this.
- If you use a CLA with your "truly" open source project, choose one that has a legally-binding guarantee that the code remains "open". That way, you use a CLA for all of its practical uses while being able to reassure contributors that they're not being manipulated.
(P.S.: I realize that the focus on contributors also is bothersome to some, considering how few external contributors many projects wind up with. However, contributions, IMO, are a major part of what makes open source tick, and the value of contributions is not weighed in the number of lines of code they diff. I really think creating an environment where contributors feel like they've been duped would do serious harm to the open source ecosystem. Or rather, already has.)
This is all very difficult for people to grasp because there are many who simply haven't managed to understand how serious the implications really are, or perhaps they have a vested interest in not seeing it. But I promise you, the "ideological purity" bit here is a red herring. I sincerely do not believe open source would work if there were such vastly different concepts under the same label. From a literal standpoint, it's easy to see "MIT with just one clause added" and not see how that's not "open source", but it's entirely about what the clause practically means that makes it such a huge problem for us.
Very cute but I am pessimistic about the battle tested nature of the second clause. Licenses are like mythical swords in fantasy stories: the famous ones are famous because they are not only objectively well made, but also because they survived in battle. Imagine some blacksmith presenting King X with GoblinsbaneY touting it as the greatest sword ever yet having only a blank face when asked what battles it has won. He’d be laughed out of court.
Or maybe an analogy closer to home (Anduril notwithstanding) would be cryptography code. New ideas are cheap compared to code that has been to hell and back in the wild and remained unbroken.
(I assume this license is novel and untested. I’ve not heard of it before. Happy to hear otherwise, of course.)
I wrote about this recently. If we adopt SAS at the cost of OSS, its gonna make it even more harder to fight against corps which are against users and communities. We need to rally for OSS more than ever IMO.
I used the MIT license for https://github.com/SaynaAI/sayna mainly because the challenge is usually in product velocity and direct sales/distribution. Blocking from SaaS is explicitly entirely redundant.
Making software is getting cheaper, so this kind of license would not protect against someone reverse-engineering the SaaS tool in a week. It is better to be abstracted away from those type of things IMHO
Given oligopoly cloud corps are the biggest exploiters of OSS (to everyone elses detriment), I'd prefer an OSS license that was simply OSS for everyone under < $1B ARR.
> Given oligopoly cloud corps are the biggest exploiters of OSS
Not exploiters unless they are breaching OSS licenses. Why do you think Cursor exists? The forked and made VS code their own. Why is it exploiting when Amazon or MS is doing the same? Am nowhere close a fan of these corps but we need to be very clear when throwing words around like exploiters.
All the LLMs are probably breaching the OSS license though. We don't care about that cos we need it. How can we complain about something we use daily eh?
What are they exploiting? Are they violating the terms of the license? The point of OSS is that there aren't arbitrary restrictions to its use; you can do what you like with it and the open source maintainer has absolutely zero obligations to continue supporting the software, or implement any of your requests.
This is not a "real" (i.e. GAAP or accounting standards) metric, so that would seem like a bad idea.
The trouble is that lots of even the accounting metrics are gameable, but a comptent auditor(s) probably won't let the metric divulge too much from "reality" (i.e. conformance with accounting standards).
People want to call their software open source, because it attracts customers. They don’t believe in software freedoms or open source, otherwise they’d never try or want to restrict Freedom 0.
If your SaaS can’t compete on the service part, the software part ain’t gonna make or break you.
No the problem is that it cant compete on the hardware part sometimes
Lets face it even if it something is open source, chances are that the most contributions/time are still spent by the person making it or the saas provider in this industry.
Imagine that someone goes ahead and launches a cheaper version of their saas and people go use that, since that person isnt having his time invested in the software as much as the original person and thus is willing to undercut him because his investment/returns expectations are very minimal whereas for the original saas it can be very high (writing good quality software which costs some developers real time and even real money)
Well this actually proves my point even further because the end users just care about price sometimes and since other competition with less investment can drive the company who created the software in the first place by undercutting them
This shows that, Companies shouldn't create open source software itself if people have such mindset since creating open source software/software in general takes sometime and it sucks if I create something, then someone grabs it and undercuts me.
This is the reason why people create source available licenses/use them. Time to create software isnt free in my opinion and we shouldnt treat it as such
Plus, what I am saying is that these licenses dont allow you to not self host, they allow you to self host, they are basically like MIT except with one clause that doesnt allow the vps providers/datacenters/other companies to compete directly against you.
Its the best of both worlds in a way.
You get money which can allow you to work full time on the project
Most people can audit the code/still run it locally/on their own VPS
People who want to rent your open source software basically by having infrastructure/undercutting you etc. actively harming you and both the community etc. are unable to bypass the intricacies of licenses.
> If your SaaS can’t compete on the service part, the software part ain’t gonna make or break you.
Oh, your bootstrapped team can’t simultaneously develop from scratch and support the new open source software project AND outcompete a multi-billion dollar business who decided to offer your service as a below-cost addon to their offering used by millions of people on day one? Tough luck, greedy bastard, you should have stayed in your cubicle.
It's not entitlement, it's the entire purpose of OSS. You are free to modify, distribute, and profit from other people's code. If you can't do any of these things, then the project is NOT OSS. Simple as that.
Entitlement is when you expect that OSS contributors must provide you with a warranty or a certain feature you need for your business activity. They are not.
The page summarises the license as “Basically… the MIT do-whatever-you-want license”. The MIT license is of course one of the most popular permissive open source licenses.
This is an incredibly misleading comparison. The subsequent clause is a complete contradiction, not a subtle clarification.
The descriptor is correct. The source is available to you, free of charge, and you can do anything with it as long as you extend the same rights to your users.
Yes, I agree that "source available" is an accurate description. Unlike "Open Source" licenses, which have no restrictions, "O'saasy" does not allow you to do "anything" you want. Adding a clause like "but you can't compete with us" makes it incompatible with OSS licenses.
I am fine with licensing your code as you wish, but I will always oppose attempts to redefine the widely understood and established meaning of "open source" that has been in place for over 30 years. You don't get to change its definition.
The “established” meaning has in fact been deliberately created by megacarporations like Microsoft so they can exploit free labor by volunteers to make money without lifting a finger. Look at who is sponsoring the OSI.
I think that open source licenses for complete software (such as SaaS components) for commercial entities have a one major purpose:
A marketing tactic. If I am open, it is easy to discuss it everywhere without paying for it.
I think that if you are short on cash, open source is the way to go to get adoption faster. If you have endless money, then there is really no reason to open source it (except edge cases, like shared protocols, libraries, etc...)
Even though it may seem harsh to apache 2.0 the code, no one will steal it since you are maintaing it, essentially paying to keep it on your turf. Reasons for not stealing:
1) Security CVEs and patches. No serious company will use it without these.
2) Bugs, if I take it I will have to fix it.
3) Merging changes. If the source is branched, I will have to get people to move to my project. Otherwise, I will have to employ people just to merge the changes all day.
4) Authority. I would argue that if you do not control the narrative of the project it is essentially similar to abandonware of the project. What would a customer/client prefer more? to use the original product or some copy of it? If you are the Authority that inspire people, they will not go to the competition.
I remember in the past the open source were thought of as communists. I think that we are far from that, and big capitalist companies knows how to profit from open source (even Apache 2.0 and MIT).
To be fair, when people worry about "stealing" their FOSS work, they don't mean someone forking their project, they mean someone outcompeting them on offering commercial infrastructure for their own project, typically launching a competing SaaS service.
Of course, this is explicitly permitted and even encouraged by FOSS licenses, so calling it "stealing" is quite absurd. But it is also a real problem for a company trying to make money by selling its FOSS software.
Essentially, it's pretty clear that you can't make a successful company out of selling free software. You either create a consulting company and push yourself as the expert on some free software that people want to use (what RedHat did, and to a much lesser degree of success, MySQL) or the free software has to be some enabler for your real business (like Linux is to Amazon, Google, Microsoft, and all of these other cloud companies and most of the internet, or like Java was to Sun).
> Essentially, it's pretty clear that you can't make a successful company out of selling free software
If that is so the case, what about source available licenses similar to O'saasy.
Do they work?
Because personally, although I love foss, its a compromise and I am willing to make it for some of my projects if it means that I can get enough funding to work on it full time basically.
I don't think we know yet if these work, at least for more than 5-10 years. Mongo and Elastic are still kicking, so perhaps they do. But it's very unclear if they would have gotten where they are had they started with the current licenses.
Yes obviously big tech knows how to profit from open source
they (AWS) profitted so hard from redis and elasticsearch that they had to literally change their licenses similar to O'sassy's
and even then people forked redis to create valkey and AWS engineers started working on it
Both redis and elasticsearch got so much backlash because "not open source" when in reality, they were trying to make ends meet but also since it allowed external contributions, people who contributed felt rug pulled
In the end, both of these had to revert switching to AGPL licenses.
Technically I am sure that people are still competing against these servers even with AGPL because it does have freedom 0 but I think that they kind of realized that backlash was very high
My opinion on the matter personally is, I value source code because I can work around it, I can see the code and audit it/ have a peace of mind.
But even now, open source is severely underfunded and I think we should do something about it. We cant really expect developers to write code in any license that you want, its their code and their wish (originally) and I think these are just means where someone wants to open source but he also wants to profit from his creation just enough so that he/she can maybe work full time on it/have more employees working on it and just have it grow better which for the end users does feel better.
I believe AGPL3 with CLA is the worst in 2025. Code can be recreated fast in 2025 especially with genAI getting better and better. The problem you'll have is the ownership of the code from day one. Today, people have concerns signing a CLA, so I am not sure redis is repeatable in that regard (though we have n8n). With Apache 2.0, if you are redis, you could have closed source the code in a few months and bury the competition. Why? because you need upgrades, you need CVE fixes, features, documentation, HA, etc... If you don't have a CLA you cannot close source AGPL3.0.
Of course I am taking the stance of the company not the users here :)
The table have turned, I believe in 2025 the users should insist on using AGPL3 without signing CLA. But again, with enough cash, the code can be recreated with genAI, it is just a matter of resources.
I personally find it questionable when people argue that the GPL/AGPL is less free because of the code sharing requirement.
On the Rust subreddit you can see people make arguments that can essentially be paraphrased as "Get a real job".
Somehow the people selling primary energy, food and raw materials are allowed to make money, the hardware manufacturers to run the code on are allowed to make money, cloud providers to run code on are allowed to make money, people using your software in their business are allowed to make money and even people who have been hired at a company to submit patches and pull requests to contribute to your project are allowed to make money but you, the original maintainer/developer who kick-started the project and paid the initial investment? Suddenly you're no longer allowed to make money. You're expected to work a "real job" (see list above). You're supposed to spend time not working on the project to earn enough money so you can donate your time and money to work on the project to people who most likely couldn't care less about you and your sacrifice and since it is just plain business sense to minimize costs, you should do the same and stop working on the project.
The strangest part by far is that if you'd you made your code proprietary from the get go, there wouldn't be any complaints about your GPL code not being free enough. It's a surprisingly pro proprietary code stance.
I don't think it's strange at all - the "pure freedom" licenses intentionally don't have safeguards against exploitation of the system, which attracts those who want to take but not give back, which lines up well with proprietary software.
Look at the caveat. If you cannot control the nerrative, you are done. Code is nothing in 2025, when a few 100$ can recreate a code base. AWS could have just recreated the code if they wanted, they just didn't have to. And, with their money, they could have bought redis labs if it was too difficult. I think people are looking at it the wrong way. The license wasn't the thing holding them back, they have the cash.
I know I am tooting Sentry's own horn a bit here, and since I was involved it is close to my heart. We struggled at one point with how to build a large company on top of an open source project, and we never liked the idea of simply carving out parts of the codebase and marking them as closed source (open core). At the same time, there was always the latent risk that even if you put 95% of the energy into the product, you were still not fully in control and someone else exploits the economic value without investing.
Our way of dealing with this was delayed open source publication. That led to the FSL [1], and later to bootstrapping the Fair Source initiative [2] to establish an umbrella term that does not conflict with Open Source. What I have found interesting in the years since is that many companies are wrestling with the same problem, but feel that the two year head start the FSL gives is too aggressive.
I actually still find that surprising. I would like to know whether this is a legitimate concern that two years is not enough, or mostly a perceived one. To me, moving to an Apache 2 or MIT license after a relatively short period is a much stronger statement than a license that risks the project effectively ending if the commercial entity is unwilling to relicense it more openly at the end of its life such as the O'saasy license.
[1]: https://fsl.software/
[2]: https://fair.io/
Isn’t the “solution” for Sentry that deploying it is such a pain in the ass that no one bothers to really do this? I haven’t checked in years but that always seemed like the real competitive blocker?
If you need less scale/features go for glitchtip. If you’re not going for k8s, the self-hosted docker-compose version of sentry works fine including proper releases and support by the sentry team etc. Just experimental newly introduced features can be a bit wonky. They are doing much more than just throwing code over the fence. Also phone home telemetry is optional and there’s a switch for just errors mode. IMHO this really builds trust. With regards to deployment complexity: well it’s built for handling high volumes of events. I’d reckon this is more a consequence of scaling the project rather than a coordinated plan to push people to their cloud offering. If you do go for k8s or choose to deploy the stack yourself, you even get access to the full scale solution. But if you’re at that scale, you probably have someone hanging around who knows how to run your clickhouse setup. You still get the full sentry software and SDKs for free in that case. I think this is as fair as it gets with regards to the open source SaaS model.
This may very well be caused by my incompetence, but Sentry's docker-compose setup has never survived for more than a few months under my control. Something always destroys itself without an obvious reason sooner or later, and either refuses to start, or starts and doesn't really work. I tried updating it regularly, tried never updating it, getting the same treatment either way.
I did not intend to be critical of their work. They're doing OSS as best as they can and good for them. I am just saying that it's a different beast if Sentry is OSS vs a much simpler to operate OSS product. Licensing matters less when the operational cost acts as an inhibitor to adoption of your OSS offering.
True, opportunity cost is a factor, sorry if my reply sounded a bit brash. IMHO they are one of the few orgs who got this model right compared to lots of others who went the open core or support/consulting contract required OSS route.
Agreed. It was easier for me to rebuild parts of it for my own use than to self-host it. At my scale, a single DB works well as a datastore instead of Clickhouse/etc.
But then again I think this only prevents small players from "competing" by self-hosting, so the revenue loss there would be minimal either way. Large enterprises are too incompetent to even self-host a single self-contained binary, so for those the availability of source code and ease of hosting would make no difference, they would still use the SaaS.
Earlier discussion on Hacker News: https://news.ycombinator.com/item?id=43725815
I'm personally on the fence how much of it is intentional... from the_mitsuhiko's side it probably isn't, but "the purpose of a system is what it does" and all.
Don't believe the salesmen, self hosting Sentry has been the most liberating feeling in a long while. Buy a cheap dedicated server with 64 gigs of RAM from Hetzner, run their install script and it's literally up and running. I'm processing volumes that would bankrupt me on their managed service without breaking a sweat.
I had no idea an error/APM monitoring requires this much of RAM. Could you provide a ballpark number on your processing volume?
> Isn’t the “solution” for Sentry that deploying it is such a pain in the ass that no one bothers to really do this?
That Sentry is a pain to deploy is not really intentional, it just happened over the years. However because it's a pain to deploy it also opens up a market for people that create managed deployments so I would say, that if anything, it made it worse. For self deployed Sentry you do not need to pay cent, the license explicitly allows it.
The end of life problem can be solved by source code escrow, with a clause putting the code under an open source license and published in case of the demise of the owning cpmpany.
This is the entire point of Fair Source undergoing delayed Open Source publication -- to codify the forward-path into the license itself, without the need for external source code escrow services.
With O'Sassy specifically, the end of life problem solves itself. If the original vendor stops offering the software, a third party offering the software is not competing with the original vendor. Thus, the third party can offer paid hosting for the software if the original vendor does not.
Or am I reading it wrong? I am not a lawyer.
If the company is sold for its assets is the code released to the public? Or removed from escrow and kept private?
That's the gritty stuff which must be spelled out in the terms.
Why not just release the software after your set threshold of time versus opening it up with such a license? To get eyes on it before-hand?
Also how does this work with contributor contributions? Does the owning SaaS get the benefit of contributor work instantly while everyone else has to wait 2 years? What about the contributers themselves?
> Why not just release the software after your set threshold of time versus opening it up with such a license?
That requires trust that the company will do this. The FSL is irrevocable and comes with a future promise.
> Also how does this work with contributor contributions?
The same way as any other thing with a CLA works. If you don't have a CLA, then you have a bit of a mess.
presumably because a) it still allows the source code to be available and used for the 'permitted purposes' (i.e. anything that's not directly competing), and b) it represents a concrete commitment to open up, not just a pinkie promise (even if they were to have a license or contract which promised it, it would not be as easy to rely on as actually having the source code published. Companies have reneged on such promises before).
And yeah, by my reading essentially people can contribute code or publish patches (with just a plain MIT license in principle), just the original and derivatives still can't be used for non-permitted purposes until the timer is up.
> Why not just release the software
You may want to allow certain uses (self-hosting, etc) even before it transitions to a fully open-source license. Having access to the source code can also help SaaS users debug certain situations.
> you were still not fully in control and someone else exploits the economic value without investing
O'Sassy came up recently in one of the forums I lurk in [0], and as discussed there, I tend to agree with Adam Jacob (SystemInit) and others that FSL is definitely one way out but doesn't totally solve the commercialization aspect, because the code & all that IP is still readily available.
Adam, in this talk [1], argues that like RedHat (and unlike Canonical), Open Source businesses must learn to separate source license from distribution license and if they do so, the money is there to be made (in a b2b setting, at least).
> What I have found interesting in the years since is that many companies are wrestling with the same problem, but feel that the two year head start the FSL gives is too aggressive.
... if the companies conflate Open Source and business models, rather it being merely a Go-To-Market (like open core).
Especially true for dev/infra upstarts competing with incumbents (PostHog v Amplitude; GitLab v GitHub [2]), and lately for AI labs (DeepSeek/Qwen/Llama v GPT/Gemini/Claude). In a role reversal, BigTech also uses Open Source to commodotize its competition's advantages (Android v iOS; k8s v Swarm; Firefox/Chrome v IE) [3].
[0] https://forum.fossunited.org/t/6878
[1] https://www.youtube-nocookie.com/embed/watch?v=rmhYHzJpkuo / Summary: https://gemini.google.com/share/e21cd1bacff6 (mirror: https://archive.vn/Jzhk3)
[2] https://www.heavybit.com/library/video/commercial-open-sourc... / https://archive.vn/jQh27
[3] https://gwern.net/complement / https://archive.vn/QITxC
The issue is these are mostly academic points of view. Sentry’s model on the FSL (and previously the BUSL) has shown to be working just fine at scale.
Whereas, for example, trademark protections have shown to fail easily.
So people can argue it doesn’t work, but so far we only have evidence to the contrary and Sentry is quite successful.
> So people can argue it doesn’t work, but so far we only have evidence to the contrary and Sentry is quite successful
So, RedHat has also been successful?
GP says that some companies don't find FSL aggressive enough, despite it having worked nicely for Sentry. And that's similar to the point Adam makes: That Open Source (per OSI not FSF) is a development model not a business model. Companies that don't want/need to prioritize collaboration tend to use FSL / BUSL / etc; but those licenses aren't really going to significantly change their development or business (other than prevent competition from using it as-is, but now the code is out there anyway [0][1]), and so they might as well go close source (and Lockdown the code, too).
> issue is these are mostly academic points of view
Both, commodotizing competition (through OSS) and using OSS as Go-To-Market aren't academic PoVs, I don't think.
[0] And trained on by LLMs, which makes cloning probably that much faster? https://x.com/paultoo/status/1999245292294803914 / https://archive.vn/kTiyZ
[1] Companies will deep pockets and technical expertise can/will anyway clone it: https://bcantrill.dtrace.org/2018/12/14/open-source-confront...
I'm not talking about RedHat, I'm talking about the perspective that "FSL / BUSL aren't effective enough". They solve the problem. O'saasy is just freeware at the end of the day, FSL creates more open source, and BUSL often has (though unfortunately the license doesnt require it).
The idea that FSL ~= Closed Source is entirely wrong and misunderstands the value that an open distribution gives. We have 10s of thousands of customers that run Sentry self-hosted. We regularly get contributations back to our core service - both in code and (what we prefer) other artifacts like feedback.
We were "Single Origin Open Source", which is extremely common whether people like to believe it or not. Its the entire premise of the sustainability issue in the industry. Thats not just an issue for commercial entities, its also most of the big open source software people rely on. In our case though we have a great business model that makes it entirely sustainable, and now have built a solid licensing mechanism around it that protects that, while ensuring our community is still successful.
Ive written about a lot of these kinds of things:
https://cra.mr/open-source-is-not-a-business-model https://cra.mr/open-source-and-a-healthy-dose-of-capitalism https://cra.mr/the-busl-factor
These same issues around single origin open source are why we started the no-strings-attached funding mechanism via Open Source Pledge (https://opensourcepledge.com), why we push Fair Source (https://fair.io).
Maybe others will find defensible models, but I'm skeptical. I also respect Adam, but last I understood it the model they were going after sounded pretty similar to trademark protection (which doesnt work).
It is not open source, it is not free. It’s a term tacked on to the MIT license.
It’s also vague as, what if I run a VPS provider and someone can upload images to a marketplace like thing, does that count as SaaS? How about if someone’s only use of my services is to run that image?
Steer clear unless you want to open yourself up to the copyright owners opinion changing. (See for example the pine email client and the copyright discussions there.)
correct. free software doesn't place any restriction on the USE of software. The rights go to the user.
The restriction is on the redistribution of the software - the same rights must be passed on when redistributing it.
this license places (complicated) restrictions on how the software is used.
> It’s also vague as, what if I run a VPS provider and someone can upload images to a marketplace like thing, does that count as SaaS? How about if someone’s only use of my services is to run that image?
This strikes me as somewhat contrived. Like yeah, if you're gonna do some weird button-pushing thing, it's not worth it, steer clear, keep this product off your platform, easy. Is a piece of software really only of value to the open source community if any kind of unscrupulous use of it is allowed?
There's a million ways to get value out of source code that don't involve pushing the envelope. I've accepted every EULA ever without reading and never once worried I would get in trouble with any of them, it's generally pretty easy if you're not trying to invent ways to do so.
> Is a piece of software really only of value to the open source community if any kind of unscrupulous use of it is allowed?
It's not even open source in the first place if any kind of unscrupulous use of it is disallowed, as that would be discriminating on use case. It ultimately doesn't matter much to the open source community, as it effectively can't be used in otherwise open source projects, as the result wouldn't be open source and it is going to be license-incompatible with many projects anyways.
That said, I find it preposterous to accept this notion even ignoring that point. You shouldn't have to take it on faith that what you're doing is allowed by the copyright license—the whole point of the license is to make that clear. Everybody always shrugs off the risk of a malicious owner until Oracle acquires their dependencies.
I understand that it's not open source. I just see it as like, a spot where a company that would normally make a closed source product wanted to make it more open and hackable and did actually put the code up and take contributions, which should be a kind of good thing, but it's automatically assumed to be the worst, a rugpull, etc. What if I operated in an ethical gray area right around this pretty reasonably worded term?
I was trying to make the point that "unfree" software is not really useful at all to the "open source" community, and not because of terminology nitpicking but because of the consequences that has.
But anyway, my problem with a license like this is indeed the existence of gray areas. Open source licenses are in some ways clever attempts to make a social contract into a legal obligation. It isn't perfect, but the side effect is that you don't have to take it on faith that people will follow it: people can be sued for violating it, and depending on how that Vizio case goes, it's not just the copyright holders who are eligible.
But that's a two way street. In return, I shouldn't have to take in on faith that my use case is legal according to the copyright license: it should be clear as day with no room for interpretation. If it's not, then my best hope is to simply never get sued. That is not good. Hope is not a strategy here, not for individuals and not for corporate users.
Business/"fair" licenses seem to offer a good compromise, but it's a mirage: the software still has to be treated a bit like toxic waste in Linux packaging, won't be compatible with strong copyleft licenses, and ultimately, presents an uneven playing field for contributors.
There isn't much to be excited about from a hacking PoV.
With projects like these, you're probably already going to be submitting your code under an unconditional CLA, which essentially forfeits your rights as a contributor, then if it's this license, you also are giving the original copyright owner more rights to use your contribution than you even have.
I don't think this is a good or healthy status quo at all.
The only upside of this is that it protects someone's business model from competition. Well good for them.
But making the license look like MIT is just a bit of cosplay, yet another attempt to try to push something as being open source when it's not. This cognitive dissonance can't go unnoticed; it really does trick people if they don't fully think through the consequences. You're better off going with a license that makes no attempt to pass itself off as open source.
Before this O'Saasy situation, I hadn't fully understood how much ideological purity was baked into the the term "open source," which to be fair is not really implied by such a general term.
I still feel like it would be a happier world if open source was more of an umbrella advocacy organization containing free software and source available, but now I understand that that's not going to happen.
Some day you may understand you dismissing a practical concern does not make it ideological.
I'm not the one dismissing anything. I'm arguing for tolerance, goodwill, and cooperation. There are lots of practical concerns in life, there are tradeoffs, there is balance.
A few days ago you said "the impression the different groups have different ideals is correct." You've spoken mostly in mystical aphorisms so it's been hard to glean much.
> I'm not the one dismissing anything.
This statement was false.
> I'm arguing for tolerance, goodwill, and cooperation.
These qualities are not absent because people differentiate source available and open source. And you continued today to argue these qualities should be expressed by changing the meaning of open source.
> A few days ago you said "the impression the different groups have different ideals is correct."
Your point was what? You thought a group had ideals meant a group's only motivation was ideological purity?
> You've spoken mostly in mystical aphorisms so it's been hard to glean much.
No. And several other people communicated similar ideas.
The only major ideological component of this matter is that both the free software movement and the open source movement are concerned with the rights of end users, not the sustainability of businesses. That's really it. Open source has always been much less focused on ideology and more on practicality; I reckon that's part of why it is the more prevalent movement in the first place.
But just because it's not about ideological purity, that doesn't mean it can just be a lawless free for all, because it would essentially destroy the utility of open source in the first place. Please read this sentence carefully and understand the implications, it is extremely important: The AGPL is a less permissive license than O'Saasy, yet it is an actual true open source license. This is not because of ideology. This is because open source doesn't practically work without the constraints in the definition.
I already listed some serious practical concerns, along with the problem that it disturbs the balance between contributors that makes open source work on a social level. However, I honestly feel like it's just scratching the surface. If you keep itching at the practical implications, it only gets worse from there.
For example, let's say there are two MIT licensed projects. One of them wants to adopt code from the other. No problem at all: just copy it in and make sure to have the correct copyright notices attached. Done.
Now, let's say you have two projects with the O'Saasy license. Uh oh: this doesn't "just work" anymore, because there are two "original Licensors" and this clause conflicts with itself in the two different invocations.
If you can't even share code between projects with the same damn license, I really feel like your argument for how this still totally counts as open source is just weak as all hell.
Now I get that some people take issue with the fact that there even is a socially-held definition of what "open source" means, but if there wasn't, and it was a total free-for-all, the communal nature of open source simply wouldn't work. And the irony of all of this is that part of the reason why so many SaaS companies want to release their projects as open source is because of how amazing it is for their PR and early adoption. And that has happened because of the careful coordination of the open source definition, to try to gatekeep the movement. Not for ideological reasons, but literally to ensure that the utility of the concept is able to be fully realized.
It isn't a huge deal if shared source, source available, "fair source" or whatever else people want to exist exists. In fact, it's much better if we don't dilute the meaning of open source with stuff that is so practically different anyways. And if the concept of shared source projects is really so enticing, it should be able to gain relevance the same way open source did.
Of course, in reality, if we stop pretending and playing devil's advocates for five whole minutes, we can all admit to ourselves that companies that would use these licenses usually have very good reason to worry about their business model and the odds are very good that the software will either be unavailable or significantly more closed off down the road.
Some will argue that this isn't a rug pull. After all, it's free and you're entitled to nothing. And I do actually agree with that "you're entitled to nothing" part, but the trouble is when you start trying to take the valuable brand of a movement like open source as a marketing tool only to pull the rug later. And yes, it is a rug pull. Whether it's legal or perhaps even fair, it's still a rug pull. Like if I pull a homeless guy off the street and offer him a bed to sleep in and food, then cut it off abruptly 6 months later, most people would definitely see how it is totally reasonable for me to not have to indefinitely bear the burden of trying to support this person. The trouble isn't that they deserve my financial support, it's that I offered it and then simply abruptly cut it off. That's a rug pull. That's what MinIO did: they gave us an option under the same pretenses we've enjoyed software like Linux or PostgreSQL under, then decided to just simply discontinue it. No warning, it was just gone. Either pay for AIstor or your production infrastructure is now running unsupported code that will not be patched. Hope you didn't use it anywhere important. ("If you used it somewhere important, why not pay?" Sure. Now tell that to e.g. non-profits with shoestring budgets that chose open source because they couldn't afford anything else.)
And, I honestly believe that these unfair CLAs that allow this behavior have done immense damage to the "brand" of open source. It isn't just a niche thing: almost every startup does it now. Very few organizations use more reasonable CLAs that answer practical concerns while still ensuring that contributors are not taken advantage of. Even fewer organizations stick to just DCOs that fulfill the minimal legal obligations. Most of them are doing the same thing, for the same reason. And I'm sure that the founders may genuinely believe that they have no intention of hitting the big red button unless they need to, but I think it's fair to say that ignorance is not a good excuse here. We've seen this game play out too many times.
The "open source but not" license is just another extension of this awful practice, and it only serves to muddy the waters. We should celebrate rather than mourn the fact that open source has gatekeepers trying to ensure that the term doesn't wind up fucking meaningless in a pursuit to burn as much VC money as fast as possible so already well-off dudes can get richer. Ideological purity is mostly not of interest to me, other than my belief that open source should be about the rights of users. Other than that, the problems here are purely practical, and the practical problems are quite severe.
So what should SaaS companies do, then?
- If they really want to be truly open source, they should release code under the AGPL. The major cloud providers are immune to even touching AGPL code anyways, but even if they decide to stop pushing dumb FUD, for all it's faults, AGPL would ensure that they can't just run with it; they have to contribute their changes upstream.
- If they actually just like the practical utility offered by developers having source code access, they can release the software not under an open source license. Since the code isn't of use to the open source community, it doesn't matter much if it's a "shared source" license or not; a traditional EULA is just as fine, and doesn't feel like it is masquerading as if it's part of the open source ecosystem.
(Edit: though there are some clever other options, like the time-release licenses that go open source after a period of time. I honestly see far less problem with this sort of license, though to avoid ambiguity it would also be good to explicitly release old code under a pure open source license, just to avoid the question of whether or not the time-release concept would work properly in court. I have seen this done already. This seems like a neat workaround at least.)
- Or just simply don't even release the source. There is plenty of closed source software in the world and I really don't think most open source advocates are even bothered by this.
- If you use a CLA with your "truly" open source project, choose one that has a legally-binding guarantee that the code remains "open". That way, you use a CLA for all of its practical uses while being able to reassure contributors that they're not being manipulated.
(P.S.: I realize that the focus on contributors also is bothersome to some, considering how few external contributors many projects wind up with. However, contributions, IMO, are a major part of what makes open source tick, and the value of contributions is not weighed in the number of lines of code they diff. I really think creating an environment where contributors feel like they've been duped would do serious harm to the open source ecosystem. Or rather, already has.)
This is all very difficult for people to grasp because there are many who simply haven't managed to understand how serious the implications really are, or perhaps they have a vested interest in not seeing it. But I promise you, the "ideological purity" bit here is a red herring. I sincerely do not believe open source would work if there were such vastly different concepts under the same label. From a literal standpoint, it's easy to see "MIT with just one clause added" and not see how that's not "open source", but it's entirely about what the clause practically means that makes it such a huge problem for us.
Very cute but I am pessimistic about the battle tested nature of the second clause. Licenses are like mythical swords in fantasy stories: the famous ones are famous because they are not only objectively well made, but also because they survived in battle. Imagine some blacksmith presenting King X with GoblinsbaneY touting it as the greatest sword ever yet having only a blank face when asked what battles it has won. He’d be laughed out of court.
Or maybe an analogy closer to home (Anduril notwithstanding) would be cryptography code. New ideas are cheap compared to code that has been to hell and back in the wild and remained unbroken.
(I assume this license is novel and untested. I’ve not heard of it before. Happy to hear otherwise, of course.)
I wrote about this recently. If we adopt SAS at the cost of OSS, its gonna make it even more harder to fight against corps which are against users and communities. We need to rally for OSS more than ever IMO.
https://www.unsungnovelty.org/posts/10/2025/oss-and-sas/
I used the MIT license for https://github.com/SaynaAI/sayna mainly because the challenge is usually in product velocity and direct sales/distribution. Blocking from SaaS is explicitly entirely redundant.
Making software is getting cheaper, so this kind of license would not protect against someone reverse-engineering the SaaS tool in a week. It is better to be abstracted away from those type of things IMHO
Given oligopoly cloud corps are the biggest exploiters of OSS (to everyone elses detriment), I'd prefer an OSS license that was simply OSS for everyone under < $1B ARR.
> Given oligopoly cloud corps are the biggest exploiters of OSS
Not exploiters unless they are breaching OSS licenses. Why do you think Cursor exists? The forked and made VS code their own. Why is it exploiting when Amazon or MS is doing the same? Am nowhere close a fan of these corps but we need to be very clear when throwing words around like exploiters.
All the LLMs are probably breaching the OSS license though. We don't care about that cos we need it. How can we complain about something we use daily eh?
What are they exploiting? Are they violating the terms of the license? The point of OSS is that there aren't arbitrary restrictions to its use; you can do what you like with it and the open source maintainer has absolutely zero obligations to continue supporting the software, or implement any of your requests.
> ARR
This is not a "real" (i.e. GAAP or accounting standards) metric, so that would seem like a bad idea.
The trouble is that lots of even the accounting metrics are gameable, but a comptent auditor(s) probably won't let the metric divulge too much from "reality" (i.e. conformance with accounting standards).
> I'd prefer an OSS license that was simply OSS for everyone under < $1B ARR.
They will find a way of gaming the metric.
For example, they run the software through a subsidiary that makes $900m ARR.
So basically Big Time Public License. https://bigtimelicense.com/versions/2.0.2
Too complicated, should be simple like O'sassy, i.e. modified MIT with a clause where it doesn't extend to oligopoly cloud corps.
This is a very compelling SaaS license.
People want to call their software open source, because it attracts customers. They don’t believe in software freedoms or open source, otherwise they’d never try or want to restrict Freedom 0.
If your SaaS can’t compete on the service part, the software part ain’t gonna make or break you.
> If your SaaS can’t compete on the service part
No the problem is that it cant compete on the hardware part sometimes
Lets face it even if it something is open source, chances are that the most contributions/time are still spent by the person making it or the saas provider in this industry.
Imagine that someone goes ahead and launches a cheaper version of their saas and people go use that, since that person isnt having his time invested in the software as much as the original person and thus is willing to undercut him because his investment/returns expectations are very minimal whereas for the original saas it can be very high (writing good quality software which costs some developers real time and even real money)
Okay, I've imagined that. Am I supposed to sympathise with the end users in this scenario or?..
Well this actually proves my point even further because the end users just care about price sometimes and since other competition with less investment can drive the company who created the software in the first place by undercutting them
This shows that, Companies shouldn't create open source software itself if people have such mindset since creating open source software/software in general takes sometime and it sucks if I create something, then someone grabs it and undercuts me.
This is the reason why people create source available licenses/use them. Time to create software isnt free in my opinion and we shouldnt treat it as such
Plus, what I am saying is that these licenses dont allow you to not self host, they allow you to self host, they are basically like MIT except with one clause that doesnt allow the vps providers/datacenters/other companies to compete directly against you.
Its the best of both worlds in a way.
You get money which can allow you to work full time on the project
Most people can audit the code/still run it locally/on their own VPS
People who want to rent your open source software basically by having infrastructure/undercutting you etc. actively harming you and both the community etc. are unable to bypass the intricacies of licenses.
> If your SaaS can’t compete on the service part, the software part ain’t gonna make or break you.
Oh, your bootstrapped team can’t simultaneously develop from scratch and support the new open source software project AND outcompete a multi-billion dollar business who decided to offer your service as a below-cost addon to their offering used by millions of people on day one? Tough luck, greedy bastard, you should have stayed in your cubicle.
Why do people feel entitled to profitting off the work of others?
It's not entitlement, it's the entire purpose of OSS. You are free to modify, distribute, and profit from other people's code. If you can't do any of these things, then the project is NOT OSS. Simple as that.
Entitlement is when you expect that OSS contributors must provide you with a warranty or a certain feature you need for your business activity. They are not.
Nowhere in the license does it claim that it’s an Open Source™ license.
The page summarises the license as “Basically… the MIT do-whatever-you-want license”. The MIT license is of course one of the most popular permissive open source licenses.
This is an incredibly misleading comparison. The subsequent clause is a complete contradiction, not a subtle clarification.
People who use it claim it's Open Source
They are using “open source” as a generic descriptor, not as the unregistered trademark of the OSI.
Yes, and that is the problem. That "descriptor" is not correct. The correct descriptor is "source available".
The descriptor is correct. The source is available to you, free of charge, and you can do anything with it as long as you extend the same rights to your users.
Yes, I agree that "source available" is an accurate description. Unlike "Open Source" licenses, which have no restrictions, "O'saasy" does not allow you to do "anything" you want. Adding a clause like "but you can't compete with us" makes it incompatible with OSS licenses.
I am fine with licensing your code as you wish, but I will always oppose attempts to redefine the widely understood and established meaning of "open source" that has been in place for over 30 years. You don't get to change its definition.
The “established” meaning has in fact been deliberately created by megacarporations like Microsoft so they can exploit free labor by volunteers to make money without lifting a finger. Look at who is sponsoring the OSI.
I think that open source licenses for complete software (such as SaaS components) for commercial entities have a one major purpose: A marketing tactic. If I am open, it is easy to discuss it everywhere without paying for it.
I think that if you are short on cash, open source is the way to go to get adoption faster. If you have endless money, then there is really no reason to open source it (except edge cases, like shared protocols, libraries, etc...)
Even though it may seem harsh to apache 2.0 the code, no one will steal it since you are maintaing it, essentially paying to keep it on your turf. Reasons for not stealing: 1) Security CVEs and patches. No serious company will use it without these. 2) Bugs, if I take it I will have to fix it. 3) Merging changes. If the source is branched, I will have to get people to move to my project. Otherwise, I will have to employ people just to merge the changes all day. 4) Authority. I would argue that if you do not control the narrative of the project it is essentially similar to abandonware of the project. What would a customer/client prefer more? to use the original product or some copy of it? If you are the Authority that inspire people, they will not go to the competition.
I remember in the past the open source were thought of as communists. I think that we are far from that, and big capitalist companies knows how to profit from open source (even Apache 2.0 and MIT).
To be fair, when people worry about "stealing" their FOSS work, they don't mean someone forking their project, they mean someone outcompeting them on offering commercial infrastructure for their own project, typically launching a competing SaaS service.
Of course, this is explicitly permitted and even encouraged by FOSS licenses, so calling it "stealing" is quite absurd. But it is also a real problem for a company trying to make money by selling its FOSS software.
Essentially, it's pretty clear that you can't make a successful company out of selling free software. You either create a consulting company and push yourself as the expert on some free software that people want to use (what RedHat did, and to a much lesser degree of success, MySQL) or the free software has to be some enabler for your real business (like Linux is to Amazon, Google, Microsoft, and all of these other cloud companies and most of the internet, or like Java was to Sun).
> Essentially, it's pretty clear that you can't make a successful company out of selling free software
If that is so the case, what about source available licenses similar to O'saasy.
Do they work?
Because personally, although I love foss, its a compromise and I am willing to make it for some of my projects if it means that I can get enough funding to work on it full time basically.
I don't think we know yet if these work, at least for more than 5-10 years. Mongo and Elastic are still kicking, so perhaps they do. But it's very unclear if they would have gotten where they are had they started with the current licenses.
Yes obviously big tech knows how to profit from open source
they (AWS) profitted so hard from redis and elasticsearch that they had to literally change their licenses similar to O'sassy's
and even then people forked redis to create valkey and AWS engineers started working on it
Both redis and elasticsearch got so much backlash because "not open source" when in reality, they were trying to make ends meet but also since it allowed external contributions, people who contributed felt rug pulled
In the end, both of these had to revert switching to AGPL licenses.
Technically I am sure that people are still competing against these servers even with AGPL because it does have freedom 0 but I think that they kind of realized that backlash was very high
My opinion on the matter personally is, I value source code because I can work around it, I can see the code and audit it/ have a peace of mind.
But even now, open source is severely underfunded and I think we should do something about it. We cant really expect developers to write code in any license that you want, its their code and their wish (originally) and I think these are just means where someone wants to open source but he also wants to profit from his creation just enough so that he/she can maybe work full time on it/have more employees working on it and just have it grow better which for the end users does feel better.
> In the end, both of these had to revert switching to AGPL licenses.
AGPL seems like the most battle tested solution here, though.
You'd need a CLA from day 1, but if you have that then you can sell commercial licenses to people who won't meet the criteria for the real license.
So I think it's important to differentiate between open source and free software, here.
I believe AGPL3 with CLA is the worst in 2025. Code can be recreated fast in 2025 especially with genAI getting better and better. The problem you'll have is the ownership of the code from day one. Today, people have concerns signing a CLA, so I am not sure redis is repeatable in that regard (though we have n8n). With Apache 2.0, if you are redis, you could have closed source the code in a few months and bury the competition. Why? because you need upgrades, you need CVE fixes, features, documentation, HA, etc... If you don't have a CLA you cannot close source AGPL3.0.
Of course I am taking the stance of the company not the users here :) The table have turned, I believe in 2025 the users should insist on using AGPL3 without signing CLA. But again, with enough cash, the code can be recreated with genAI, it is just a matter of resources.
> the code can be recreated with genAI, it is just a matter of resources.
Can it though? Most interesting things (for my values of interesting at least), cannot be re-created with generative AI.
Every time I try to do anything a little bit out of distribution, they fall apart (and they're not great at in-distribution stuff either).
> I believe AGPL3 with CLA is the worst in 2025
I think that you mean best, as with both of these one can sell commercial licenses while remaining open.
Again, from the company's point of view you get both nerd-cred and a viable business (this is what MySQL did, I believe).
You don't get that with BSD/MIT.
I personally find it questionable when people argue that the GPL/AGPL is less free because of the code sharing requirement.
On the Rust subreddit you can see people make arguments that can essentially be paraphrased as "Get a real job".
Somehow the people selling primary energy, food and raw materials are allowed to make money, the hardware manufacturers to run the code on are allowed to make money, cloud providers to run code on are allowed to make money, people using your software in their business are allowed to make money and even people who have been hired at a company to submit patches and pull requests to contribute to your project are allowed to make money but you, the original maintainer/developer who kick-started the project and paid the initial investment? Suddenly you're no longer allowed to make money. You're expected to work a "real job" (see list above). You're supposed to spend time not working on the project to earn enough money so you can donate your time and money to work on the project to people who most likely couldn't care less about you and your sacrifice and since it is just plain business sense to minimize costs, you should do the same and stop working on the project.
The strangest part by far is that if you'd you made your code proprietary from the get go, there wouldn't be any complaints about your GPL code not being free enough. It's a surprisingly pro proprietary code stance.
I don't think it's strange at all - the "pure freedom" licenses intentionally don't have safeguards against exploitation of the system, which attracts those who want to take but not give back, which lines up well with proprietary software.
> Even though it may seem harsh to apache 2.0 the code, no one will steal it since you are maintaing it
But that's evidently not true. Amazon has co-opted plenty of open source projects and put the squeeze on the original maintainer's SaaS offering.
Look at the caveat. If you cannot control the nerrative, you are done. Code is nothing in 2025, when a few 100$ can recreate a code base. AWS could have just recreated the code if they wanted, they just didn't have to. And, with their money, they could have bought redis labs if it was too difficult. I think people are looking at it the wrong way. The license wasn't the thing holding them back, they have the cash.