Personally I think differentiation between "open source" and "source available" is good.
Open source, is, essentially software that I expect to be able to use commercially and tweak if required - but I'm own my own, and I pay for support.
Source available means I can basically help debug issues I have...but I expect that a paid licence is required and will have a selection of limitations (number of nodes, etc).
Most source-available licenses that I've encountered have no paid license requirements for users. They only require a paid license if you want to sell the product commercially. Normally, you're still allowed to use the software as a piece of a larger commercial product, as long as it does not compete with the original author, or "substantially reproduce the functionality" of the source-available bits, depending on the exact language.
While it's true that this the kind of "source available" license the article is talking about, other examples exist.
For instance, the source code to Epic's Unreal Engine[1] is hosted in a private GitHub repo, accessible by anyone who agrees to a clickthrough license, and free for personal, educational, and commercial use up to $1 million gross revenue, at which point royalty payments are required.
> Personally I think differentiation between "open source" and "source available" is good
Maybe, but I think that "source available" isn't detailed enough and can mean many many different things.
> Source available means I can basically help debug issues I have...but I expect that a paid licence is required and will have a selection of limitations (number of nodes, etc).
Point in case. For me there is one group, under something like BSL or FSL or SSPL which mostly restricts you from competing with the project's creators (e.g. making your own SaaS out of it), but everything else is fair use, you can use it in prod to make money at any size, etc. And a separate, more restrictive one, which has size, or production restrictions (you can't run the software if you're a commercial entity).
Source available sounds like a good description for the second one, because it's just available, little more. But for the first one where you can do whatever you want with one single exception that doesn't impact 99.9999% of potential users, it's not a good and clear enough description.
People run with OSI initiative as it is and consider it the golden rule when I agree with your 99.9999% of potential users line.
I think that *one blunder?) is that OSI cant really consider SSPL or similar open source because it restricts access to one party so it breaches an freedom 0 or some freedom of open source which is fair but at the same time literally only impacting people competing against (in my opinion the funding of the project and its growth itself) if someone like amazon had created a redis service competing against redis itself lets say
I think its all kinda nuanced and we kinda need more discussion with source available.
I agree with you the "source available" is overstretched. It's hard to come up with a good new label for the first group. Maybe "Open Use" or "Fair Source".
"Source Available" means that it can become "Source Unavailable" overnight.
See the "Our Machinery" fiasco.
Yes, Open Source isn't a complete defense against this (especially when there are copyright assignments). However, it sure makes it both a lot harder to pull off and a lot less useful to even try.
"Open Source" can also become "Source Available" overnight. See Redis, Terraform, etc. In the same vein, "Open Source" can also become "Closed Source" overnight.
In neither case does the change apply retroactively. It only applies to new contributions after the license change.
that's not what source available means to me -- it just means you can look at the source code -- what you can actually do with that code, or whether or not you need a paid license, whether you can use the code in a non-commercial case only but not commercial, all of those are nuances that would be specified in the license. There are many different options from highly restrictive to highly permissive -- the only thing they have in common is that you can see the source code.
"open source" can have restrictions too. GPL is highly restrictive because it requires any code linked with the GPL code to be GPL too.
> Open source, is, essentially software that I expect to be able to use commercially and tweak if required - but I'm own my own, and I pay for support.
AND it also means with copyleft-licenses that you are required to make the source code for those tweaks public too.
I always wonder why people bother with providing source under a source available license. It makes outside contributions a lot less likely. Your active community of people working on the code base effectively becomes your employees.
There's little to no benefit to outside users. Any work they do on the code is effectively free work they do for you that entitles them to nothing. Including free usage and distribution of the work they did. It's not likely to be helpful.
My attitude to source available products is the same as to proprietary products. I tend to limit my dependency on those. Companies have short life spans. Many OSS projects I use have a history of surviving the implosion of companies that once actively contributed to them. Developer communities are much more resilient than companies. Source unavailable effectively becomes source unavailable when companies fail. Especially VC funded companies are kind of engineered (by VCs) to fail fast. So, it's just not a great basis for making a long term commitment.
If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license. Somebody could take over the project or fork it or even create a new company around it. Some of the original developers would probably show up. A project like that is resilient against that. And projects like that have active contributors outside of the corporate context that provide lots of contributions. Because of the license. You don't get that without a good OSS license. I judge software projects by the quality of their development communities. It needs to have diversity, a good mix of people that know what they are doing, and a broad enough user community that the project is likely to be supported in perpetuity.
Shared source provides only the illusion of that. Depending on them is risky. And that risk is rarely offset by quality. Of course people use proprietary software for some things. And that's fine. I'm no different. But most of the stuff I care about is OSS.
Counterpoint: I’ve often wished the proprietary software I use was source-available so that I could fix bugs for myself.
The idea of doing free work for a company does feel weird. But when some bug is really getting on my nerves, being able to fix it and not have to deal with it anymore is a huge benefit!
Or understand what it's doing internally. I used to dislike Oracle User Group presentations because it seemed as if most people were just guessing what the database was doing under the covers. MySQL presentations on the other hand (a) showed code and (b) were often given by the authors.
This; there are a couple 'freeware' style apps I use where the developer sticks a source tarball on a website alongside the download. Having access to that means I can tweak something for a weird scenario, or fix a bug on a new OS release, and if I want, I can send the patch back to the developer.
The BUSL license requires shifting to an open-source license no later than 4 years after publication. I'd be happy to contribute to a BUSL-licensed project knowing my contributions will shift to an MIT license within 4 years.
And the original authors don't have to worry as much about Amazon eating their lunch.
While that is certainly better, the original point still stands. If the company goes bust the latest source code will only be open source after 4 years. By that time other software has likely taken over the need in the first place, because not having that need fulfilled for 4 years is mostly not reasonable. And older versions often don't have compatibility with new versions either.
Good for you; you seem like a trusting person. I'd recommend against spending your time on that. Or at least try to get paid for it.
I tend walk away from anything with a shared source license. I don't invest my time in it. I don't finish reading the README. It's an instant red flag.
As others said, being able to audit software and point out bugs is thousand times better than hunting in the dark if there's no Open or Free alternative is available. Compiling it yourself and comparing with the binary you have (reproducible building) is billion times better.
I personally choose Free Software first and Open Source Software second. However, if I have to choose between two proprietary options, I'd choose the source available one. I might not be able to patch/touch it, but at least I can see and verify.
> I personally choose Free Software first and Open Source Software second.
Given that functionally these terms are pretty much equivalent, how do you decide which project is Free Software and which is Open Source? By how it calls itself?
> I always wonder why people bother with providing source under a source available license. [..] There's little to no benefit to outside users. Any work they do on the code is effectively free work they do for you that entitles them to nothing.
Don't need to make PRs to benefit from the source being available. Running software whose source code has been under public eyeballs, and that I have compiled myself (or that a trusted third-party has compiled) is far more secure than running a binary blob that may or may not do what the developer's marketing page promises.
> If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license.
Closed-source apps have had source-code escrow clauses for a long time, exactly to avoid that problem. "If my company shuts down, you get all the source code and can do whatever you want with it."
Such clauses can, and should, be brought over to source-available licenses, where they would also be trivial since you don't even need a physical escrow.
20 years ago, I used to consult with Fortune 500 companies that run Oracle and IBM products (web servers and Java frameworks).
These are distributed as enterprise binaries. It's common to face _at least_ one or two weird errors in production. Then you have to raise a ticket to support.
Would you like to know how it is discussing a binary-obfuscated error with Customer support? And then after few weeks being assigned to a newly joined fresher? And so on and on, where every person or layer every week says "you're doing it wrong" and you have to restart your proofing and explanation process from scratch?
Hint: After few weeks/months of this (or after 4 times of restarting your proofing process), you start questioning your sanity and life choices.
In those days, all I wished for is just "source-available", so that I can just debug myself what is going on and provide a concise bug report, instead of talking to support.
The weird part is, I'm pretty sure, on the other side, Oracle/IBM also LOST money in that same process. They had to hire an army of people. It was lose-lose on both sides.
Source-available means customers of that software can perform debugging themselves and file pretty good support tickets.
If you are an enterprise today, you would absolutely consider make it source-available to save on your own costs.
That's a great reason I steer clear of products like that. Oracle is not a DB I've used since 2005. There's no need. The market for closed sourced databases imploded to basically legacy products that predate when open source databases became a sane default choice. I guess some banks/insurers still might talk themselves into believing it's a sane choice for new projects.
I guess source available is better than source unavailable + hand wavy support from a company that's out to milk you for revenue for as long as they can get away with it.
But it's a weak substitute for proper open source that you can just fork and fix if you need to without having to beg some indifferent company to pretty please fix their legacy shit and offering to do free work for them. If it's open source, chances are that there are still some others around also using the same software and sharing your pain that can support you or benefit from your fixes.
I don't see the value of most shared source projects. Usually there are very decent OSS alternatives. And the lack of those usually just means one will pop up shortly and displace whatever it is you are using. Any benefit to these projects tends to be short lived. OSS developers like to copy what is good and add it to their own projects.
E.g. most nosql databases ended up having postgresql absorb whatever it was that made these things interesting. Several shared source things (mongodb) are at this point looking a bit dated and backwards. That's also exactly what happened to MS SQL, Oracle, DB2, and all those other long forgotten databases that people used to use last century. There's very little technical reason to use any of those at this point.
Maybe that's the whole point. Entities which rely on the product enough to propose contributions are more likely to be paying customers who really need to have a given feature available?
People seem to complain that they are burnt out by open source quite often so not sure that there are that many contributions apart from a couple projects.
It may also protect a project against business vultures. If you are trying to monetize your project but someone richer than you forks it and offer it for free, what can you do?
Yet, by being source available, the code is still auditable. It is easier for people to understand how the software works. And nowadays you can fine tune an LLM over it I guess...
Seems that is might also be a valid perspective?
You can probably have a kind of bus clause so that source code does not become abandoned?
As a sysadmin I have sometimes wished I had source available for certain things as it would help in debugging what is going on with a certain error/behaviour. strings(1) only gets you so far.
> I always wonder why people bother with providing source under a source available license.
I treat it as "business plus", not "FOSS minus". And of course, some source-available licenses convert to FOSS over time.
> Any work they do on the code is effectively free work they do for you that entitles them to nothing.
Funny, that's the same complaint FOSS companies have about AWS free-riding off their hard work and then competing. They switch to source-available licenses because a FOSS license allows flush FAANGs to exploit them.
> They switch to source-available licenses because a FOSS license allows flush FAANGs to exploit them.
And then they die because they cut themselves off from the OSS community.
Most shared source companies don't actually fare that well. There's a history of these companies spawning new OSS competitors based on forks. Or just not gaining any traction at all.
The "boohoo amazon killed my business" thing isn't as widely spread as you think. They only offer a few hundred services. Several of those are based on open source things. If I were an investor, I'd be reluctant to invest in shared source companies. Unlikely to have long term stamina, extremely likely to be outpaced by some OSS thingy, likely to see users jump ship as soon as they can. I think a few investors probably learned that lesson the hard way.
Shared source from day 1 just means you probably end up running a niche business and are by definition not very investable. Usually these things if they get funded at all are doomed for some acquihire scenario where they end up in the hands of professional revenue milkers like IBM or Oracle. Nothing good happens to users of those projects when that happens. Developers leave in disgust and start new projects. It becomes abandon-ware.
A second argument here is that if Amazon thinks you are worth hosting in managed form, that means they see a multi billion $ market. This doesn't happen until after you are successful typically. And there are plenty of people who don't use Amazon who might still like to use the same stuff. It's a great validation that you have a valuable project and that there is a huge market for it. You just don't get to be the monopolist in that market.
There are millions of open source projects out there that are just fine. Most of those don't require VC funding, or IPOs, or other cash grab mechanisms to sustain themselves for a long time. Most of the really successful projects actually see active contributions from those FAANGs as well. E.g. MS is one of the most active contributors to the Linux kernel. Google as well. OSS actively used by FAANGs represents the most solid open source code out there. Guaranteed to be well supported for ages. Loads of active contributors; many of them paid for by those companies.
Most open source never gets outside contribution either.
The point of sharing the code is to benefit the user. Or to benefit yourself because of the marketing that comes from users wanting this. Not to get free labour.
In the case of Fizzy, the app that 37signals has made “source available”, the real motivation for publishing is form of advertising for Ruby on Rails.
DHH is on a mission to show that you can write great software with way less bullshit than is in vogue.
This code base is sparkling in its design. No build frontend, server side rendered templates, minimal js used primarily to drive interactivity, extremely simple models, jobs, and controllers.
It has < 3000 lines of js with incredibly rich interaction design, when was the last time you saw that?
Looking at its license[0], it more open-source that source-available. It has a non-compete restriction as a commercial hosted service, but otherwise you can do what you want with it.
I love open source, but I'd welcome less of it and more "source available" projects.
I think several large coorporations are pushing the boundaries of what "open source" can actually mean in good faith. Especially several recent big name cases where profit models weren't thought out during start up and then licenses for projects aee suddenly changes.
The term has erroded a lot recently, I'd be happy to see less, but more meaningful "open source" out there.
I certainly don't have all the answers here but the entire $300B+ SaaS industry (and a bunch of other stuff that behaves like SaaS) was built in great part on a loophole in the GPL. More precisely, many of the people who licensed their code under GPL were eventually dismayed when they realized you could sell access to whatever you like built on top of that code, over a network, and you wouldn't have to distribute the source. The AGPL was devised to close this loophole.
There are really two dynamics at play, one is that there are people who want to give a gift to the world and promote a culture of sharing, in fact they want to REQUIRE you to pay it forward if you use their stuff. That's the ethos behind GPL and AGPL. It has proven to be way more effective than the bean counters expected!
The other dynamic is the more conventional profit making and taking which has perceived a loophole and used it to make some extra bucks on the backs of the nice sharing guys.
I don't have anything against profits, I like money and I own a business where we choose to keep some code totally closed source because money. But you can't deny that this division exists. And I think this dynamic is what most of the dilemmas in the OSS world really arise from, there is a strain of altruism since the early days of the movement which has been betrayed, for many it feels awful if you've released GPL'ed code and then watched Big Tech promptly pile a bunch of proprietary code on top of it and use the resulting machine to strangle the freedoms of the human race over the Internet. You don't automatically get to squeeze profits from a thing just because it's out there and it's shiny and nice. That may not be why the author built it. It may be a betrayal of their intent if you do.
I share your sentiment and would love to expand how I feel as if even AGPL isn't enough for cloud providers like Amazon, Google etc. which can just technically run it on their servers without too much modifications or release the modifications and still compete against the original AGPL party
Personally I get worried that even AGPL might not be enough for me if I create a service which faces the public because if it gets large enough then companies technically can still call dibs on me and use their infrastructure to compete against me and I could do nothing...
It was an interesting thought experiment and made me blur the lines between (Fully open source good, source available bad) to well... it depends. And I think everyone should have such nuance since I don't think we live in a world of black and white but its interesting to hear everyone's opinion on it as this topic gets raised every once in a while.
To explain where I'm coming from a bit more, my thinking is something like:
"open source" where crucial parts of making a system work, or where the project scoops up eager contributors and them schisms the community once it's finished using their work, tends to have a negative effect.
If those projects were more explicitly either "closed source"/"source accessible" etc, then the open source community could focus their efforts on projects that actually embraced genuine openness and hackability.
Of course - I'd rather there was more actual open source. But what I really want is for "open source" to be some marker saying "this is a project that's open and built by/for the community".
> What principles and values of the open source movement are protected by staunchly refusing to allow "source available" to call itself open source?
The part where the license says "Don't run this on your server and charge people money for it, or we will sue you"?
I know that everyone thinks of Big Tech absorbing your project into their SaaS when they do this, but there are other ways (say AGPL) to combat that. O'SaaSy seems to me to be essentially a "give us your code for free, and you can self host it, but don't dare to charge $$ for it or else!" license.
Now you're bringing lawyers into the picture for anyone who's hosting your software on their servers. It's very reasonable for a SaaS company that wants to defend its moat, but it's not Open Source.
(Talking of, I'm actually curious if anyone has seen actual self-hosted Fizzy instances in the wild.)
I didn't ask which part of the license violates OSS values, I asked what those principles and values are. I will infer that "anybody can do whatever they want with the code" is the principle you are referring to.
I kind of thought that it was more about stuff like sharing and personal development and edification and the ability to see inside and understand things. But let's get really divisive over the money stuff.
> The part where the license says "Don't run this on your server and charge people money for it, or we will sue you"?
A bit offtopic but could re-generation of the project with LLM (with for example prompt "rewrite the <repo> changing every line of code") help protecting from being sued? If yes, then the OS licensing is doomed to fail.
This is a good technical point. But this seems to kind of argue that one of the principles of open source is that businesses should be able to pull it into their proprietary projects to make money without hesitation. Is that accurate? I thought that was kind of more of a bonus.
I feel like it's participating in the spirit of open source and should be welcomed, if someone wants to make their code available but just wants to try and restrict anything-goes usage. But I can see the purity argument.
These terms are designed to trick people exactly like you. "Source available" means you can sue anyone that shares a modification of your code for any reason you want to make up.
I'm going to respond here assuming you are being genuine and not facetious or sarcastic (even though I am hoping you were).
"Source available" doesn't in any way mean "you can sue anyone that uses your code for any reason...". The irony of highlighting the trickery of these terms then you yourself perpetuating wrong definitions is... amusing.
"Source available" is by definition ill-defined, in the sense that "open source" is defined. There is no trademark, stewarding body, or legal entity behind "Source available". It only exists in relation to OSI defined "open source".
Which is to say, it is defined as code that does not fit the "Open Source Definition (OSD)" yet its source code is viewable. Maybe its modifiable, maybe its free to use, but maybe its neither. Thats all anyone can factually attribute to the definition of "Source available". Nothing about "suing ... for any reason".
Again, hoping you were making your comment in good fun, otherwise it doesn't look too good for you.
I think it comes to analogies, with open source you have a public park you are free to use. With source available it is public park you are free to look at behind a fence... So not actually public park. Still a fine thing to exist.
As user as well. Difference between I can use this for free and I have to pay to use this. Even if I can see parts inside is significant.
It might not be real principle, but at least it is real difference.
Wouldn't it be more along the lines of "source available" being a public park that you're free to access but can't monetize by e.g. selling tickets to - while "open source" would let you do whatever you want with the park.
Ironically I think the analogy explains why many people find "source available" to align with their moral compass more than "open source" necessarily does.
They’re not at all on the same team. “Open source” is given away for free, to do what you want with it. Source available is not. Fundamentally they have nothing in common other than the fact that you are allowed to read the source code.
I'm somewhat sympathetic to licenses that will be open source in X years, but the open source ethos is that, with proper attribution, we can do whatever with the code, the only restriction being that for some projects a derivative work needs to also be open source (while others don't care even about that)
If we were to welcome non-open source projects into a larger community, we should probably begin with licenses that forbid the usage of the software in military and things like that. Which fails to be open source for the same reason: it puts limits in how you can use the code
Some people have internalized the words "open" "source" to mean more than the words, even going so far as to eschew the benefit (which was at the heart of the Stallman problem) because it doesn't fit the desired ethos and license. It's counterproductive, indeed.
People use the term to refer to a proprietary definition from the OSI, which is an OK convention. I just wish they would capitalize it, and leave the normal interpretation of the words also available.
Not the same team. Open source isn't really about the license, and it's also not even really about the source; open source is a philosophy centering open development and collaboration. Sharing the source is necessary, but not sufficient. Too often, "source available" means you get to see the source, but you are not invited to participate in development, and certainly you're not going to be participating in collaboration.
"Source available" projects want the benefits of being associated with that egalitarian philosophy because it's popular amongst technologists, who are their initial customers. But they don't want to actually practice the philosophy because their core interest is protecting their IP to turn a profit, not open collaboration and development. Outside contributions are considered a liability in many source available projects [1].
This is important because source available projects have in the past resulted in a "rug pull", when the project gets enough airspeed, so they start putting more work into the closed source to placate their investors. Once the technologists are not the primary users, the entire source available charade is done. The available source becomes deprecated, features are moved to the closed source branch, and eventually the available source rots.
One final point: if we call source available "open source", then what are we going to call open source to differentiate it from source available. Because they're actually different things.
Edit: (this is to the response below me, as I'm rate limited now and I'm going to bed so I'll forget to post this tomorrow)
If anyone tried to do this then the project would be forked immediately. An open source project can go closed source, but as an OSS project, everyone should already have everything the need to keep it going despite that, and that all remains open. That's why we love open source.
Also, it'd be really hard to pull off if they've accepted a lot of outside contributions -- when you submit code to an open source project, you retain the copyright. This is not a problem as long as the project is licensed under the agreement under which they submitted the commit, which only grants rights to redistribute under that license. At least that's how it works with Apache 2.0 (I believe, IANAL). So to go closed source, they'd need agreements from all of their contributors to do so.
Now, it can happen. MongoDB is an example. But as far as I can tell, you'd have a hard time of it if you accepted contributions from people and they.
> Open source isn't really about the license, and it's also not even really about the source; open source is a philosophy centering open development and collaboration.
Not really. A project under an open source license which doesn't accept contributions is still open source.
It is totally about the license and the source code availability.
There are interesting things to say about the various development models, and those common in the open source world, but the open source aspect and the development model aspect should not be mixed.
Haven't open source projects done the rug pull too? Can't they relicense new code going forward?
I guess I would have thought of source available as existing under the open source umbrella. I get that there is an important distinction but from an adoption and evangelism standpoint it seems like an unnecessary crusade to push them away.
Do those projects have a strong track record of behaving badly? Do you think DHH has those types of intentions? (I don't know much about him really)
Some source available licenses are literally just modified open source with the addition of some clauses (mostly cloud related)
To me source available is: we are open source but if you are an cloud provider with billions of dollars, ask us for a license/fund us.
Technically linux gets funded enough and rightfully so but I remember how netbsd's fundings were so meagre and low which really saddened me.
To be honest, I thought about it and lets assume Linux uses a busl like license which open sources after 4 years
Most likely what would've happened is that someone will take that 4 year old code and then fork it to create the linux we all kinda love.
But overall I think linux is the bedrock of any vps/cloud provider which can be small enough too to be unable to buy their source available license so its kind of an mixed bag I guess and for linux, not worth it because it already gets a lot of funding.
It would be interesting if the same funding that linux kernel gets was shared at a similar level to the distros because I saw cachyos and talked to its creator on discord and I am not kidding but the fundings are very small for a project so big.
Also I think most people use source available license to make money or funding, basically the question which I want to ask you is: how to make enough money in open source?
For a lot of developers, the current biggest failure of open source is the AWS/Azure/GCP problem. BigCloud has a tendency to just take well liked open source products, provide a hosted version of them and as a result they absolutely annihilate the market share of the entity that originally made the product (which usually made money by offering supported and hosted versions of the software). Effectively, for networked software (which is the overwhelming majority of software products these days) you might as well use something like BSD/MIT rather than any of the GPLs[0] because they practically have the same guarantees; it's just that the BSD/MIT licenses don't contain language that makes you think it does stuff it actually doesn't do. Non-networked software like kernels, drivers and most desktop software don't have this issue, so it doesn't apply.
Open source for that sort of product (which most of the big switches away from open source have been about) only further entrenches BigCloud's dominance over the ecosystem. It absolutely breaks the notion that you can run a profitable business on open source. BigCloud basically always wins that race even if they aren't cheaper because the company is using BigCloud already, so using their hosted version means cutting less yellow tape internally since the difficulty of getting people to agree on BigCloud is much lower compared to adding a new third party you have to work with.
The general response to this issue from the open source side tends to just be to accuse the original developers of being greedy/only wanting to use the ecosystem to springboard their own popularity.
---
I should also note that this generally doesn't apply to the fight between DHH and Mullenweg that's described in the OP. DHH just wants to kick a hornets nest and get attention now that Omarchy isn't the topic du jour anymore - no BigCloud (or for this case, shared hosting provider is probably more likely) is going to copy a random kanban tool written in Ruby on Rails. They're copying the actual high profile stuff like Redis, Terraform and whatever other examples you can recently think of that got screwed by BigClouds offering their services in that way (shared providers pretty much universally still use the classic AMP stack, which doesn't support a Ruby project, immunizing DHHs tool from that particular issue as well). Mullenweg by contrast does have to deal with Automattic not having a stranglehold on being a WordPress provider since the terms of his license weren't his to make to begin with; b3/cafelog was also under GPL and WordPress inherited that. He's been burned by FOSS, but it's also hard to say he was surprised by it, since WP is modified from another software product.
[0]: Including the AGPL, it doesn't actually do what you think it does.
As a lay person, I still don't get what is AGPL missing that makes vendors "invent" so many new licenses and spawn so much debate? Why not just use AGPL, and if it's insufficient, invest in an AGPLv2 initiative?
Iirc the issue with SSPL was that releasing the entire stack under SSPL would basically be impossible, since you wouldn't have the rights to release, for example, the Linux kernel, under it.
MinIO made their source AGPL, but then cloud providers hosted the service "as is" and make money off it, with MinIO team getting zip. That still complies with AGPL but is not monetarily beneficial to the MinIO team.
At least that's my understanding. They closed source completely, but a source-available license wouldn't have run into this issue.
It is not possible to create a license that would satisfy the Free Software Foundation's "four freedoms" while also solving the issues many of those vendors have with the AGPL. At the same time, the "source available" mindset doesn't have a steward organization like the FSF or OSI.
The major concern regarding the AGPL is that it only fosters code share when a code change is involved. The license has nothing to do with someone building a competitive service around your project.
If a Big Tech company happened to build a cloud service (SaaS) around your project without any code change, and that service is more competitive than the one you provide, there is not much you can do about it with the AGPL.
The AGPL is published by the FSF, with mainly community-led projects in mind. The profit and sustainability of a corporation is not their primary concern. (A minor correction: The most recent version is v3; any newer version would be v4, not v2.)
Source available isn't a license, it is the lack of a license. It's the legal default state for all art. It can include whatever made-up rules the author wants you to follow but your just as well off if you don't read them and just treat it as copyrighted.
I think that people looks at n8n success and say why not use source available?... However, I believe they are wrong to believe that this would work for any project...
Readit News
Open source, is, essentially software that I expect to be able to use commercially and tweak if required - but I'm own my own, and I pay for support.
Source available means I can basically help debug issues I have...but I expect that a paid licence is required and will have a selection of limitations (number of nodes, etc).
For instance, the source code to Epic's Unreal Engine[1] is hosted in a private GitHub repo, accessible by anyone who agrees to a clickthrough license, and free for personal, educational, and commercial use up to $1 million gross revenue, at which point royalty payments are required.
[1] https://www.unrealengine.com/
Maybe, but I think that "source available" isn't detailed enough and can mean many many different things.
> Source available means I can basically help debug issues I have...but I expect that a paid licence is required and will have a selection of limitations (number of nodes, etc).
Point in case. For me there is one group, under something like BSL or FSL or SSPL which mostly restricts you from competing with the project's creators (e.g. making your own SaaS out of it), but everything else is fair use, you can use it in prod to make money at any size, etc. And a separate, more restrictive one, which has size, or production restrictions (you can't run the software if you're a commercial entity).
Source available sounds like a good description for the second one, because it's just available, little more. But for the first one where you can do whatever you want with one single exception that doesn't impact 99.9999% of potential users, it's not a good and clear enough description.
I think that *one blunder?) is that OSI cant really consider SSPL or similar open source because it restricts access to one party so it breaches an freedom 0 or some freedom of open source which is fair but at the same time literally only impacting people competing against (in my opinion the funding of the project and its growth itself) if someone like amazon had created a redis service competing against redis itself lets say
I think its all kinda nuanced and we kinda need more discussion with source available.
See the "Our Machinery" fiasco.
Yes, Open Source isn't a complete defense against this (especially when there are copyright assignments). However, it sure makes it both a lot harder to pull off and a lot less useful to even try.
In neither case does the change apply retroactively. It only applies to new contributions after the license change.
"open source" can have restrictions too. GPL is highly restrictive because it requires any code linked with the GPL code to be GPL too.
AND it also means with copyleft-licenses that you are required to make the source code for those tweaks public too.
There's little to no benefit to outside users. Any work they do on the code is effectively free work they do for you that entitles them to nothing. Including free usage and distribution of the work they did. It's not likely to be helpful.
My attitude to source available products is the same as to proprietary products. I tend to limit my dependency on those. Companies have short life spans. Many OSS projects I use have a history of surviving the implosion of companies that once actively contributed to them. Developer communities are much more resilient than companies. Source unavailable effectively becomes source unavailable when companies fail. Especially VC funded companies are kind of engineered (by VCs) to fail fast. So, it's just not a great basis for making a long term commitment.
If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license. Somebody could take over the project or fork it or even create a new company around it. Some of the original developers would probably show up. A project like that is resilient against that. And projects like that have active contributors outside of the corporate context that provide lots of contributions. Because of the license. You don't get that without a good OSS license. I judge software projects by the quality of their development communities. It needs to have diversity, a good mix of people that know what they are doing, and a broad enough user community that the project is likely to be supported in perpetuity.
Shared source provides only the illusion of that. Depending on them is risky. And that risk is rarely offset by quality. Of course people use proprietary software for some things. And that's fine. I'm no different. But most of the stuff I care about is OSS.
The idea of doing free work for a company does feel weird. But when some bug is really getting on my nerves, being able to fix it and not have to deal with it anymore is a huge benefit!
And the original authors don't have to worry as much about Amazon eating their lunch.
I tend walk away from anything with a shared source license. I don't invest my time in it. I don't finish reading the README. It's an instant red flag.
I personally choose Free Software first and Open Source Software second. However, if I have to choose between two proprietary options, I'd choose the source available one. I might not be able to patch/touch it, but at least I can see and verify.
Given that functionally these terms are pretty much equivalent, how do you decide which project is Free Software and which is Open Source? By how it calls itself?
Don't need to make PRs to benefit from the source being available. Running software whose source code has been under public eyeballs, and that I have compiled myself (or that a trusted third-party has compiled) is far more secure than running a binary blob that may or may not do what the developer's marketing page promises.
> If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license.
Closed-source apps have had source-code escrow clauses for a long time, exactly to avoid that problem. "If my company shuts down, you get all the source code and can do whatever you want with it."
Such clauses can, and should, be brought over to source-available licenses, where they would also be trivial since you don't even need a physical escrow.
These are distributed as enterprise binaries. It's common to face _at least_ one or two weird errors in production. Then you have to raise a ticket to support.
Would you like to know how it is discussing a binary-obfuscated error with Customer support? And then after few weeks being assigned to a newly joined fresher? And so on and on, where every person or layer every week says "you're doing it wrong" and you have to restart your proofing and explanation process from scratch?
Hint: After few weeks/months of this (or after 4 times of restarting your proofing process), you start questioning your sanity and life choices.
In those days, all I wished for is just "source-available", so that I can just debug myself what is going on and provide a concise bug report, instead of talking to support.
The weird part is, I'm pretty sure, on the other side, Oracle/IBM also LOST money in that same process. They had to hire an army of people. It was lose-lose on both sides.
Source-available means customers of that software can perform debugging themselves and file pretty good support tickets.
If you are an enterprise today, you would absolutely consider make it source-available to save on your own costs.
I guess source available is better than source unavailable + hand wavy support from a company that's out to milk you for revenue for as long as they can get away with it.
But it's a weak substitute for proper open source that you can just fork and fix if you need to without having to beg some indifferent company to pretty please fix their legacy shit and offering to do free work for them. If it's open source, chances are that there are still some others around also using the same software and sharing your pain that can support you or benefit from your fixes.
I don't see the value of most shared source projects. Usually there are very decent OSS alternatives. And the lack of those usually just means one will pop up shortly and displace whatever it is you are using. Any benefit to these projects tends to be short lived. OSS developers like to copy what is good and add it to their own projects.
E.g. most nosql databases ended up having postgresql absorb whatever it was that made these things interesting. Several shared source things (mongodb) are at this point looking a bit dated and backwards. That's also exactly what happened to MS SQL, Oracle, DB2, and all those other long forgotten databases that people used to use last century. There's very little technical reason to use any of those at this point.
People seem to complain that they are burnt out by open source quite often so not sure that there are that many contributions apart from a couple projects.
It may also protect a project against business vultures. If you are trying to monetize your project but someone richer than you forks it and offer it for free, what can you do?
Yet, by being source available, the code is still auditable. It is easier for people to understand how the software works. And nowadays you can fine tune an LLM over it I guess...
Seems that is might also be a valid perspective? You can probably have a kind of bus clause so that source code does not become abandoned?
As a sysadmin I have sometimes wished I had source available for certain things as it would help in debugging what is going on with a certain error/behaviour. strings(1) only gets you so far.
I treat it as "business plus", not "FOSS minus". And of course, some source-available licenses convert to FOSS over time.
> Any work they do on the code is effectively free work they do for you that entitles them to nothing.
Funny, that's the same complaint FOSS companies have about AWS free-riding off their hard work and then competing. They switch to source-available licenses because a FOSS license allows flush FAANGs to exploit them.
And then they die because they cut themselves off from the OSS community.
Most shared source companies don't actually fare that well. There's a history of these companies spawning new OSS competitors based on forks. Or just not gaining any traction at all.
The "boohoo amazon killed my business" thing isn't as widely spread as you think. They only offer a few hundred services. Several of those are based on open source things. If I were an investor, I'd be reluctant to invest in shared source companies. Unlikely to have long term stamina, extremely likely to be outpaced by some OSS thingy, likely to see users jump ship as soon as they can. I think a few investors probably learned that lesson the hard way.
Shared source from day 1 just means you probably end up running a niche business and are by definition not very investable. Usually these things if they get funded at all are doomed for some acquihire scenario where they end up in the hands of professional revenue milkers like IBM or Oracle. Nothing good happens to users of those projects when that happens. Developers leave in disgust and start new projects. It becomes abandon-ware.
A second argument here is that if Amazon thinks you are worth hosting in managed form, that means they see a multi billion $ market. This doesn't happen until after you are successful typically. And there are plenty of people who don't use Amazon who might still like to use the same stuff. It's a great validation that you have a valuable project and that there is a huge market for it. You just don't get to be the monopolist in that market.
There are millions of open source projects out there that are just fine. Most of those don't require VC funding, or IPOs, or other cash grab mechanisms to sustain themselves for a long time. Most of the really successful projects actually see active contributions from those FAANGs as well. E.g. MS is one of the most active contributors to the Linux kernel. Google as well. OSS actively used by FAANGs represents the most solid open source code out there. Guaranteed to be well supported for ages. Loads of active contributors; many of them paid for by those companies.
The point of sharing the code is to benefit the user. Or to benefit yourself because of the marketing that comes from users wanting this. Not to get free labour.
DHH is on a mission to show that you can write great software with way less bullshit than is in vogue.
This code base is sparkling in its design. No build frontend, server side rendered templates, minimal js used primarily to drive interactivity, extremely simple models, jobs, and controllers.
It has < 3000 lines of js with incredibly rich interaction design, when was the last time you saw that?
Damn weirdos. Next you're going to tell me that you can deploy it without k8s or even a container?! /s
[0] https://github.com/basecamp/fizzy?tab=License-1-ov-file#read...
It does however make it unlikely for me to pick and use the project in the first place.
And definitely not a fan of living through the "era" of open source term washing, post truth, tech influencers and their echo chambers.
DHH says Y, now dozens of impressionable Xs will start parroting the same thing.
Dead Comment
I think several large coorporations are pushing the boundaries of what "open source" can actually mean in good faith. Especially several recent big name cases where profit models weren't thought out during start up and then licenses for projects aee suddenly changes.
The term has erroded a lot recently, I'd be happy to see less, but more meaningful "open source" out there.
There are really two dynamics at play, one is that there are people who want to give a gift to the world and promote a culture of sharing, in fact they want to REQUIRE you to pay it forward if you use their stuff. That's the ethos behind GPL and AGPL. It has proven to be way more effective than the bean counters expected!
The other dynamic is the more conventional profit making and taking which has perceived a loophole and used it to make some extra bucks on the backs of the nice sharing guys.
I don't have anything against profits, I like money and I own a business where we choose to keep some code totally closed source because money. But you can't deny that this division exists. And I think this dynamic is what most of the dilemmas in the OSS world really arise from, there is a strain of altruism since the early days of the movement which has been betrayed, for many it feels awful if you've released GPL'ed code and then watched Big Tech promptly pile a bunch of proprietary code on top of it and use the resulting machine to strangle the freedoms of the human race over the Internet. You don't automatically get to squeeze profits from a thing just because it's out there and it's shiny and nice. That may not be why the author built it. It may be a betrayal of their intent if you do.
Personally I get worried that even AGPL might not be enough for me if I create a service which faces the public because if it gets large enough then companies technically can still call dibs on me and use their infrastructure to compete against me and I could do nothing...
It was an interesting thought experiment and made me blur the lines between (Fully open source good, source available bad) to well... it depends. And I think everyone should have such nuance since I don't think we live in a world of black and white but its interesting to hear everyone's opinion on it as this topic gets raised every once in a while.
"open source" where crucial parts of making a system work, or where the project scoops up eager contributors and them schisms the community once it's finished using their work, tends to have a negative effect.
If those projects were more explicitly either "closed source"/"source accessible" etc, then the open source community could focus their efforts on projects that actually embraced genuine openness and hackability.
Of course - I'd rather there was more actual open source. But what I really want is for "open source" to be some marker saying "this is a project that's open and built by/for the community".
You cannot meaningfully consent to running software on your devices, or running your life on software, when that software's source is unavailable.
To an outsider it looks like counterproductive bickering between people on the same team.
The part where the license says "Don't run this on your server and charge people money for it, or we will sue you"?
I know that everyone thinks of Big Tech absorbing your project into their SaaS when they do this, but there are other ways (say AGPL) to combat that. O'SaaSy seems to me to be essentially a "give us your code for free, and you can self host it, but don't dare to charge $$ for it or else!" license.
Now you're bringing lawyers into the picture for anyone who's hosting your software on their servers. It's very reasonable for a SaaS company that wants to defend its moat, but it's not Open Source.
(Talking of, I'm actually curious if anyone has seen actual self-hosted Fizzy instances in the wild.)
I kind of thought that it was more about stuff like sharing and personal development and edification and the ability to see inside and understand things. But let's get really divisive over the money stuff.
A bit offtopic but could re-generation of the project with LLM (with for example prompt "rewrite the <repo> changing every line of code") help protecting from being sued? If yes, then the OS licensing is doomed to fail.
The moment you change a single line of that license I now have to pay extremely close attention to those details again.
This isn't a naive idealism thing - there are very solid, boring, selfish reasons for caring about this.
I feel like it's participating in the spirit of open source and should be welcomed, if someone wants to make their code available but just wants to try and restrict anything-goes usage. But I can see the purity argument.
"Source available" doesn't in any way mean "you can sue anyone that uses your code for any reason...". The irony of highlighting the trickery of these terms then you yourself perpetuating wrong definitions is... amusing.
"Source available" is by definition ill-defined, in the sense that "open source" is defined. There is no trademark, stewarding body, or legal entity behind "Source available". It only exists in relation to OSI defined "open source".
Which is to say, it is defined as code that does not fit the "Open Source Definition (OSD)" yet its source code is viewable. Maybe its modifiable, maybe its free to use, but maybe its neither. Thats all anyone can factually attribute to the definition of "Source available". Nothing about "suing ... for any reason".
Again, hoping you were making your comment in good fun, otherwise it doesn't look too good for you.
As user as well. Difference between I can use this for free and I have to pay to use this. Even if I can see parts inside is significant.
It might not be real principle, but at least it is real difference.
Ironically I think the analogy explains why many people find "source available" to align with their moral compass more than "open source" necessarily does.
Its literally against the first of the four essential freedoms of Free and Open Source Software
> The freedom to run the program as you wish, for any purpose (freedom 0).
If you’re not planning to be a dick, they’re functionally identical.
It’s an improvement.
Uh.. are they?
I'm somewhat sympathetic to licenses that will be open source in X years, but the open source ethos is that, with proper attribution, we can do whatever with the code, the only restriction being that for some projects a derivative work needs to also be open source (while others don't care even about that)
If we were to welcome non-open source projects into a larger community, we should probably begin with licenses that forbid the usage of the software in military and things like that. Which fails to be open source for the same reason: it puts limits in how you can use the code
Deleted Comment
"Source available" projects want the benefits of being associated with that egalitarian philosophy because it's popular amongst technologists, who are their initial customers. But they don't want to actually practice the philosophy because their core interest is protecting their IP to turn a profit, not open collaboration and development. Outside contributions are considered a liability in many source available projects [1].
This is important because source available projects have in the past resulted in a "rug pull", when the project gets enough airspeed, so they start putting more work into the closed source to placate their investors. Once the technologists are not the primary users, the entire source available charade is done. The available source becomes deprecated, features are moved to the closed source branch, and eventually the available source rots.
One final point: if we call source available "open source", then what are we going to call open source to differentiate it from source available. Because they're actually different things.
[1]: For example, many projects won't even allow outside contributions, but when they do, you'll have to sign some sort of contributor agreement: https://www.scylladb.com/open-source-nosql-database/contribu...
Edit: (this is to the response below me, as I'm rate limited now and I'm going to bed so I'll forget to post this tomorrow)
If anyone tried to do this then the project would be forked immediately. An open source project can go closed source, but as an OSS project, everyone should already have everything the need to keep it going despite that, and that all remains open. That's why we love open source.
Also, it'd be really hard to pull off if they've accepted a lot of outside contributions -- when you submit code to an open source project, you retain the copyright. This is not a problem as long as the project is licensed under the agreement under which they submitted the commit, which only grants rights to redistribute under that license. At least that's how it works with Apache 2.0 (I believe, IANAL). So to go closed source, they'd need agreements from all of their contributors to do so.
Now, it can happen. MongoDB is an example. But as far as I can tell, you'd have a hard time of it if you accepted contributions from people and they.
Not really. A project under an open source license which doesn't accept contributions is still open source.
It is totally about the license and the source code availability.
There are interesting things to say about the various development models, and those common in the open source world, but the open source aspect and the development model aspect should not be mixed.
I guess I would have thought of source available as existing under the open source umbrella. I get that there is an important distinction but from an adoption and evangelism standpoint it seems like an unnecessary crusade to push them away.
Do those projects have a strong track record of behaving badly? Do you think DHH has those types of intentions? (I don't know much about him really)
To me source available is: we are open source but if you are an cloud provider with billions of dollars, ask us for a license/fund us.
Technically linux gets funded enough and rightfully so but I remember how netbsd's fundings were so meagre and low which really saddened me.
To be honest, I thought about it and lets assume Linux uses a busl like license which open sources after 4 years
Most likely what would've happened is that someone will take that 4 year old code and then fork it to create the linux we all kinda love.
But overall I think linux is the bedrock of any vps/cloud provider which can be small enough too to be unable to buy their source available license so its kind of an mixed bag I guess and for linux, not worth it because it already gets a lot of funding.
It would be interesting if the same funding that linux kernel gets was shared at a similar level to the distros because I saw cachyos and talked to its creator on discord and I am not kidding but the fundings are very small for a project so big.
Also I think most people use source available license to make money or funding, basically the question which I want to ask you is: how to make enough money in open source?
Open source for that sort of product (which most of the big switches away from open source have been about) only further entrenches BigCloud's dominance over the ecosystem. It absolutely breaks the notion that you can run a profitable business on open source. BigCloud basically always wins that race even if they aren't cheaper because the company is using BigCloud already, so using their hosted version means cutting less yellow tape internally since the difficulty of getting people to agree on BigCloud is much lower compared to adding a new third party you have to work with.
The general response to this issue from the open source side tends to just be to accuse the original developers of being greedy/only wanting to use the ecosystem to springboard their own popularity.
---
I should also note that this generally doesn't apply to the fight between DHH and Mullenweg that's described in the OP. DHH just wants to kick a hornets nest and get attention now that Omarchy isn't the topic du jour anymore - no BigCloud (or for this case, shared hosting provider is probably more likely) is going to copy a random kanban tool written in Ruby on Rails. They're copying the actual high profile stuff like Redis, Terraform and whatever other examples you can recently think of that got screwed by BigClouds offering their services in that way (shared providers pretty much universally still use the classic AMP stack, which doesn't support a Ruby project, immunizing DHHs tool from that particular issue as well). Mullenweg by contrast does have to deal with Automattic not having a stranglehold on being a WordPress provider since the terms of his license weren't his to make to begin with; b3/cafelog was also under GPL and WordPress inherited that. He's been burned by FOSS, but it's also hard to say he was surprised by it, since WP is modified from another software product.
[0]: Including the AGPL, it doesn't actually do what you think it does.
MongoDB invested sufficient resources in drafting an update to the AGPL. That license is called the Server Side Public License. Controversy ensued.
At least that's my understanding. They closed source completely, but a source-available license wouldn't have run into this issue.
If a Big Tech company happened to build a cloud service (SaaS) around your project without any code change, and that service is more competitive than the one you provide, there is not much you can do about it with the AGPL.
The AGPL is published by the FSF, with mainly community-led projects in mind. The profit and sustainability of a corporation is not their primary concern. (A minor correction: The most recent version is v3; any newer version would be v4, not v2.)
- Kan (AGPL): https://github.com/kanbn/kan (my own project)
- WeKan (MIT): https://github.com/wekan/wekan
- Taiga (AGPL): https://github.com/taigaio/