I don't believe we've been served well by defining the term "Open Source" to also necessarily mean "Free". This definition and the accompanying zealotry mainly serves big tech and the cloud providers. Everyone else would be better off if we as an industry also make room for software that is Open (in the sense that the code is freely available), but not Free (you must pay or obtain permission to run it yourself, re-distribute it, or run it for others).
Open is almost universally good. Open means self-hosting, auditability, ability to patch/submit patches for problems yourself, and not being up shit creek if the provider folds.
But Free? Free might not always be bad, but it has a lot of problems. Free = a race to the bottom. Free = ads. Free = selling user data. Free = no one cares enough to maintain it. Free = no one cares enough to promote it. Free = no one can afford to hire a UX designer. Free = ripped off by AWS. Free = bait and switch when the VC gets impatient.
For all these reasons, you should demand access to the code, yes, but you should also be willing to pay the people who write the crucial software you rely on. It's far more sustainable and healthier for our industry.
Stallman keeps saying Free of OSS is "Freedom of Speech" not "Free Beer". However, the "Free Beer" part is also important - there won't be any startup if every software (open-code or not) required big license fees.
Sure, the open-code part is very valuable for all the reasons you mention. However, people writing code altruistically has also been extremely valuable for getting us where we are today.
"Sure, the open-code part is very valuable for all the reasons you mention. However, people writing code altruistically has also been extremely valuable for getting us where we are today."
Yes, I agree wholeheartedly. My problem is with the many folks who automatically discount anything that is not "Free Beer". This attitude seems to be quite pervasive, unfortunately.
Fair enough. Having a "OSS-compliant" license which supports "payment to run the sofrware" would help open-source startups like us but I guess
"requiring payment" will hurt the "Freedom of Speech" part of OSS.
An analogy would be - you have "Freedom of Speech" in a democracy but it requires a 100$ payment. Maybe?
I'd say the expectation that all software should be free is more similar to expecting all books to be free, and self-righteously declaring that you will only read free books, because any author who tries to make money by writing books is clearly a sell-out who can't be trusted.
Closed source is like saying you aren't allowed to skim the book at the store before buying or share your favorite passages with a friend. That does infringe free speech. An author selling a book does not.
But just as with written media, there's plenty of room for both paid and free options that are both Open in the sense that the code is available. In a healthy ecosystem we'd have a lot of both, and no widespread bias against paid options. If anything businesses should have the opposite bias.
Depending on what you compare it to you get different answers.
We don't have patents or copyright for math. It is not that we want mathematicians to not get paid, or that we don't value math, or that there is no room for both paid and free math. It is that math is such a fundamental building stone that allowing rent seeking in that space would cause significant harm to society, including the advancement of science.
Some software is like a book. You buy it and consume it. You don't buy a book and build a better book. You do have the problem with schools in that children would be harmed if they had to pay for it, so we have libraries and school that buy the books for them so they become "free" for the children. Some nations, like Sweden, also have laws that demands that book publishers send books to libraries and the money the copyright owner is set by the state.
If we treat software as math then it should be free. If we treat software as books it should be semi-free for those that needs it and can't afford it.
> Stallman keeps saying Free of OSS is "Freedom of Speech" not "Free Beer". However, the "Free Beer" part is also important - there won't be any startup if every software (open-code or not) required big license fees.
Just wanted to point out the problem with this reasoning - "big license fees" are not necessary when the software is not Open Source (TM). One counter-example is Commons Clause which is not Open Source (TM), but still allows users normal use freedoms (self hosting, inspecting code, repairing and improving it, sharing modifications), but doesn't allow re-selling the product to 3rd parties. The irony is that it got a lot of bad press. I think Richard Stallman / FSF called it "particularly nasty"? Unfortunately, with all the good that FOSS has done, the zealotry that comes with it makes finding an optimal solution very difficult.
I'm not suggesting that Commons Clause (or BSL, or Fair License, or any other hybrid licenses for that matter) should be used everywhere, but they do solve a real problem in a user-friendly way (as a user, I would actually prefer a hybrid license to open core).
Congratulations to Sentry for choosing the BSL, I hope it serves them well!
I have trouble with startups leaching off "free as in beer" code.
The least they could do is pay an open source license with the same level of equity they pay to their employees.
Startups pop up to make money they shouldn't shy away from disruption just because there head start on product launch might cost some money.
If you want this to change, then you should not use "free" when you mean "gratis" or "freeware". Free software explicitly only cares about freedom and encourages you to charge as much as you want/can: https://www.gnu.org/philosophy/selling.en.html
There is plenty of room for what you describe. You just shouldn't call it Open Source, because Open Source has a well-established definition already. You could call it Shared Source, or Source Available, or some one suggested Business Source. Whatever you want to call it (that isn't already taken), but don't lie in your marketing efforts by calling it open source.
> I don't believe we've been served well by defining the term "Open Source" to also necessarily mean "Free".
I don't think we've done that. On the contrary, Stallman and many other free software advocates specifically distinguish between open source software and free software.
To add to the confusion, I think you're talking about free as in beer (gratis) rather than free as in freedom (libre). The latter is what most free software advocates are talking about.
I would argue that all of the problems you mention are caused by open source software that is not free (libre) even if it is free (gratis).
While this may be technically true, in practice these two types of "freedom" are almost always conflated. Anyone who posts something that is "libre" but not "gratis" will be met with lots of "why isn't it FOSS?" and "here's a FOSS alternative" comments. This is the (imo) self-defeating attitude I'm referring to.
Well, if something is libre it's hard for it not to also be gratis, because someone can just take your code and run it elsewhere. So there's understandable skepticism when something is libre but not gratis, because the suspicion is that the creator will retract the libre-ness of their code.
I see the trend you're talking about, but I also see an inverse trend: people think that if software isn't funded it won't happen. Particularly on Hacker News: there's a segment of Hacker News who either can't comprehend or refuse to acknowledge that there might exist motivations besides money. I'm not accusing you of this, at least not to that extreme, but I'm saying that some people have that attitude, and it's certainly informing what you're saying to some extent.
My perspective as someone who has written some open source software, is that I did it for fun, to solve my own problems, or out of some idealistic drive to push humanity forward. Money was a foregone conclusion, but I wrote the software anyway. I might feel differently if I had written anything significant enough that it had a wide user base of profitable companies, but it's my impression that people don't write software and make it free because they want money.
I'm not saying we shouldn't support our free software contributors. We should, it's a nice thing to do. All I'm saying is that fear about the incentive structure of open source software isn't really warranted. Free (libre) and free (gratis) software will continue to be built regardless of whether they are ever funded, by people who are well-aware that they may never receive any money for it.
> Open Source is pretty clear cut: it does not discriminate. If you get the source, you can do with it what you want (within the terms of the license) and no matter who you are (within the terms of the license). However as Open Source is defined — and also how I see it — Open Source comes with no strings attached. The moment we restrict what you can do with it — like not compete — it becomes something else.
I appreciate this distinction. I don't have anything against a company updating its licenses to remain profitable, as long as they're up-front about what they're doing.
My only complaint about licenses of this nature has been when businesses try to use them to argue that they're still Open Source in spirit, or that the restrictions are just technicalities that everyone should ignore, or that Open Source is doomed and they're here to save everyone.
Not everything needs to be Open Source, but Open Source should mean something.
In particular, I fee like the comment on copyright assignment is an insightful way of explaining why these approaches to licensing often feel inconsistent with company claims to support 'Openness':
> If an entity does not gladly bind itself by its own copyleft license (for example, by accepting third-party contributions to its codebases under that license), we should not treat that entity as a legitimate license steward, nor treat that license as a legitimate FOSS license.
> My only complaint about licenses of this nature has been when businesses try to use them to argue that they're still Open Source in spirit
If a project is still usable in 99.9% of the ways most developers would care about (ie everything except AWS hosting their own paid version), are you saying you don't like it when projects communicate that fact by saying things like, "we're almost open source, except X"?
A better way of stating that would be, "we're Source Available with permissive licenses." Aesprite handles this particularly well; it's very up-front with what its license allows.
I don't inherently have a problem with people saying, "we're almost X, but not quite." However, I disagree that licenses like SSPL are "almost" Open Source, and I disagree that paid hosting is a particularly minor restriction.
To again quote Sentry's post:
> The moment we restrict what you can do with it — like not compete — it becomes something else.
Blocking companies from offering paid hosting has implications, not just on an ideological level but also on a purely practical level. Part of the reason I trust technologies like Matrix or Postgresql is because I'm hopeful that their hosting will be somewhat commoditized. I know that when hosts compete there, they're competing purely on hosting quality, not on software licenses.
If the official hosting services go sour for a truly Open Source project I have the option of self hosting -- but I also know that other companies will likely step up and provide alternative hosting solutions as well. When you restrict the ability to compete with your service, you make that less likely. So Open Source isn't just about the code I can run on my computer, it's also about my ability to delegate to other people. If you restrict my right to delegate hosting to an open market, that's not an insignificant restriction.
And again, not everything has to be Open Source. I use proprietary SaaS services, I even use open-core services like Gitlab. But I recognize that products like Gitlab's enterprise offering comes with substantial limitations.
> I disagree that licenses like SSPL are "almost" Open Source
Again, my definition of "almost" is what 99.9% of developers are actually likely to use it for. Most aren't interested in starting a competitor.
> Blocking companies from offering paid hosting has implications, not just on an ideological level but also on a purely practical level. Part of the reason I trust technologies like Matrix or Postgresql is because I'm hopeful that their hosting will be somewhat commoditized. I know that when hosts compete there, they're competing purely on hosting quality, not on software licenses.
There's nothing stopping companies from competing; they just can't use your code/binaries directly. They're free to implement your protocols themselves, which is very commonly done when people implement OSS implementations of Google or AWS APIs. Matrix isn't code; it's a protocol. If they had released their reference server as commons clause, you would be at exactly the same level of vendor lock-in you are now, because there are already multiple independent OSS server implementations.
> I also know that other companies will likely step up and provide alternative hosting solutions as well. When you restrict the ability to compete with your service, you make that less likely
Can you name a single example of this happening? From what I've seen, even moderately successful services (like Parse) simply die (aka self-hosting only). On the flipside, we have examples like AWS offering best-in-class hosted MongoDB that the mongo guys could never compete with, no matter how hard they try.
Sorry if my response seems combative. I'm mostly trying to improve my own understanding of what I see as a tricky problem. I've released a couple services lately that I would love to open source in some fashion, but there don't seem to be any great solutions.
No worries, I don't take it as combative. To be clear, I'm not trying to shame anyone who decides that they can't Open Source something they make. There are positives and negatives to these approaches. I'm also not trying to say that there aren't reasonably ethical, proprietary, Source Available licenses out there.
I still use Aseprite, in part because its license terms are very good, even for a Source Available application. In the art world, some of the Creative Commons licenses are far more restrictive than any Open Source code license could ever be. I don't think the Creative Commons licenses are unethical.
That out of the way:
> Can you name a single example of this happening?
Your own example is quite good.
> we have examples like AWS offering best-in-class hosted MongoDB that the mongo guys could never compete with, no matter how hard they try.
There are two ways of looking at this. One of them is that by outcompeting Mongo, AWS is making it harder to maintain the core software. That's a negative. However, it doesn't mean that the alternative wouldn't also have drawbacks.
The other way of looking at it is that in a world where AWS couldn't Freely build hosting services on top of Mongo, we would be losing out on a best-in-class Mongo hosting solution that the Mongo maintainers could never provide at the same level of quality and reliability. The entire Mongo ecosystem would be worse, because (frankly) the Mongo team is not as good at SaaS as Amazon is.
Sure, Amazon could license the software under separate terms. They can license Oracle Database too. But in both cases, the core license isn't Free (Libre). We're now in a situation where companies are competing on contracts, not just on on hosting, and we're now in a situation where the Mongo maintainers can leverage prices or exclusivity to change how the market looks.
Jumping back the the example of Matrix: yes, Matrix is a protocol. But it's also an Open server implementation (Synapse) that anyone can host for commercial purposes. Having Open server implementations means that what hosts are competing on isn't "who can implement the protocol best", or "who can secure the best licensing agreement". It's just "who can provide good hosting and customer service". The organization behind Matrix does provide their own Synapse hosting, but their explicit goal is that eventually their service will be outcompeted and die.
I would contend that supporting that kind of ecosystem matters for a heck of a lot more than 0.1% of developers. 99.9% of developers are not hosting their own Mongo instance. They're taking advantage of the market. Unless you're planning on rolling your own cloud for every SaaS product you ever launch, the market matters. Every developer who uses a 3rd-party cloud to host their stuff (ie most of them) benefits from companies like Amazon being able to freely offer hosting.
This might sound like a technicality, but it's the same reason why a lot of other things matter in Open Source. I have never read the Linux kernel source code, but the fact that other people have makes me trust it more. I've never compiled a custom kernel, but the fact that other people have means I can get custom kernels for obscure hardware. I have never started a commercial Postgresql hosting service, but the fact that other people have gives me confidence that I will always be able to find a quality Postgresql service when I need hosting for my own projects.
Of course, that Open market has downsides in that there are fewer people funding the software. But those are the same downsides we see in many other core attributes of Open Source. Being able to freely compile and distribute programs has the obvious downside that in practical terms, it is very hard to sell your stuff, regardless of what Richard Stallman would claim.
My goal is not to demonize people who say, "giving up an Open competitive market is a fair tradeoff for supporting core software." My goal is not to demonize people who say, "if I release my game/tool/library as Free (Libre), I won't be able to support myself." I think those are reasonable concerns.
But at the same time, I would challenge you -- if Amazon's ability to host Mongo doesn't matter to 99.9% of developers, why is Amazon making so much money from this? Why are developers choosing AWS over Mongo's SaaS offerings? I would argue that the answer is that AWS is genuinely providing a tangible value to a huge number of programmers, and that those programmers really do care about being able to access 3rd-party hosts offering that kind of value.
This is a topic that I have been thinking a lot on recently. I've been working on a typo-tolerant instant search engine for a couple of years now called Typesense (https://github.com/typesense/typesense).
It has not been wildly popular (mostly because I've not really started marketing it) but it's loved by those who use it.
While exploring how to support its development, there were only 2 options: either to offer a hosted version or premium features which will take some features away from the open source version (essentially open core).
A hosted version is essentially ruled out since it's a lot of work and will eventually be bettered by AWS :) Open core will mean crippling the main product in some ways.
Tricky choice. Eventually I ended up with a middle-ground. Offer a premium version but price it so reasonable (in my case 500 USD / year) that it becomes a no-brainer decision. The only downside to this approach is of course you can't probably run a company off it but it certainly can support 2-3 people comfortably IF it succeeds.
I considered making it open source but couldn't see a way I could monetise it if I tried to charge for it mainly because someone could just upload a free version to the Chrome Web Store. Open sourcing a project also opens you up to taking on a lot more responsibilities as well (e.g. reviewing pull requests, on-boarding new developers, maintaining code standards) and you risk losing control of your own project if you're not careful. Helping users with support requests is already enough work when you're a solo developer too.
Generally, I guess you have to weigh up:
1) time investment from open sourcing and maintaining a community vs
2) benefits you'll get from having open source contributors vs
3) increased competition from the open source version
With some app ideas, it's very hard to reduce the impact of factor 3 which is a shame.
> Open sourcing a project also opens you up to taking on a lot more responsibilities as well (e.g. reviewing pull requests, on-boarding new developers, maintaining code standards) and you risk losing control of your own project if you're not careful
I agree with the rest of what you said, but not this quoted parts.
Open sourcing your project has nothing to do with pull requests (you don't have to accept outside changes), onboarding new developers (you don't have to provide support) or maintain code standards. You get to do exactly whatever you want, whatever that means.
Risk losing control of your own project? How would that even happen? Unless you put someone in charge of your project, and they run away with the keys (sort of), I don't see how someone can "steal" your project.
> Open sourcing your project has nothing to do with pull requests (you don't have to accept outside changes), onboarding new developers (you don't have to provide support) or maintain code standards. You get to do exactly whatever you want, whatever that means.
I meant this in the sense of open sourcing a project and encouraging a community around it so other developers would help introduce new features and fix bugs. If you don't do this, aren't you missing out on a lot of big reasons to make it open source?
> Risk losing control of your own project? How would that even happen? Unless you put someone in charge of your project, and they run away with the keys (sort of), I don't see how someone can "steal" your project.
Someone could fork the project, rebrand it and take it in a new direction, especially if you weren't dedicating enough time to it e.g. ignoring pull requests.
Going back to my list, if you aren't doing item 1, you're not going to get much of benefit 2, and item 3 is going to be a risk for little gain.
> I meant this in the sense of open sourcing a project and encouraging a community around it so other developers would help introduce new features and fix bugs.
I see. I don't want to be pedantic (but I guess I am anyway) but building a community and open sourcing code are two very different things. If you're running a business, in no way should we force them to do what we can call "community open source". The idea is that you can modify the code to your needs, and neither of the community things are absolutely needed for this. Of course it helps, but I feel like we miss out on a lot of companies open sourcing their code if we only care if they build a open source community too.
> If you don't do this, aren't you missing out on a lot of big reasons to make it open source?
Everyone have their own reasons for open sourcing something. I'm sure everyone could handle their incoming open source contributions better, but in the end it's up to the companies/organizations/projects/people themselves.
> Someone could fork the project, rebrand it and take it in a new direction, especially if you weren't dedicating enough time to it e.g. ignoring pull requests.
That sounds great to me, maybe I'm missing something. If someone makes something that is better than your thing, wouldn't the best thing (for the users) be to use that then? Or if it makes different tradeoffs, that maybe makes sense in more scenarios?
You still have to make sure you're a better product for someone to purchase, if you now so persistently want to run a company based on your open source code. You can still run a better product than your competitors.
Also, if you don't want to open source your code, that's fine too. Probably in the future (if not already), having open source code is a advantage against your competitors.
> Of course it helps, but I feel like we miss out on a lot of companies open sourcing their code if we only care if they build a open source community too.
Personally speaking, open sourcing something with no intention of responding to interested developers doesn't feel right.
> You still have to make sure you're a better product for someone to purchase, if you now so persistently want to run a company based on your open source code. You can still run a better product than your competitors.
When you open source though, aren't you making it significantly easier for people to build a product better than yours?
If it's a paid product that works without hosting, what's to stop someone just selling it cheaper or releasing it for free?
> Personally speaking, open sourcing something with no intention of responding to interested developers doesn't feel right.
Everyone is different :)
> When you open source though, aren't you making it significantly easier for people to build a product better than yours?
If the only benefit from you and a competitor is a particular feature or something else that you gain from proprietary code, you're gonna lose eventually anyway. You need something stronger if you are to survive. There needs to be something more between you and your competitors than something that can be easily copied (like most features in most products).
Some companies focuses on integrations/synergy (like Apple, easier the more stuff from them you have) while others on other things.
The idea was that developers like you could make your tools available under Parity and charge folks who want to use their code to develop closed, rather than open, software. However, several projects and companies have also used the license simply to make sure their work stays open, without selling any permission to build closed projects.
I like the idea. How would it stop someone releasing a free version of a paid development tool though? It relies on people downloading the free tool to be honest enough not to use it on commercial projects?
So for tools like https://www.checkbot.io/ specifically, where the tool gives you a list of problems to go and fix, it would be easy to use the tool on a commercial project and conceal that you did so.
I can see a license like yours working for a library you had to integrate though as I can't imagine any serious company would risk integrating a library in a way that violates the license.
I have a tremendous amount of and appreciation for Armin Ronacher and many of their fabulous Python libraries which I use regularly. However, this blog post is odd. It says that the open source sass model "has worked out very well for us", but then goes on to say "at one point someone has to make money somewhere.." in order to justify abandoning open source licensing of Sentry.
Maybe "worked out great" means that they got a ton of publicity and traction because they were open source, and now they are ready to abandon open source so they can monetize the traction they gained from being open source in the first place?
Sentry certainly doesn't have any obligation to continue being open source- the old code is still open source- but these events make me question any companies commitment when they claim to be open source. It seems that you can't take any company at their word, even when they publish multiple blog posts about how "committed" they are to open source- because in the end, many companies will do what Sentry did and will dump open source the minute they have gotten what they want from it.
And if there was any doubt about Sentry's willingness to use and abuse open source- months after this announcement, they continue to advertise being open source on their site, lying to the community and their customers. https://sentry.io/_/open-source/
Sentry doesn't have any obligation to continue to releasing new code as Open Source, but they should stop lying about being open source.
I have been aware of Sentry for years, but I've never used it and haven't followed the company closely. Reading Armin's post, and the official Sentry announcement [0], this strikes me as pretty reasonable.
Sentry is about 11 years old. The industry has changed a lot in 11 years. There are people and companies around now that can build direct competitors more quickly than they could 11 years ago. The question raised in the Sentry post is completely valid: Was the license chosen 11 years ago the best one to base a company off of? A company relicensing its software after 11 years is a lot different than a company waving the open source flag for a year and then closing off access.
I appreciate the work people are doing to find a middle ground in the open source world. Purist approaches are important in many areas, but can't work for everyone and for every project. People who are suggesting that Sentry is no longer open source have a point, but there is also a world of difference to me between a company using a BSL, and a company whose entire codebase is a black box to the outside world.
One of the key questions I ask about companies built around open source, is "Are you being honest about your business structure?" I'm fine with middle-ground open source licenses as long as the terms are clear and transparent. I have no respect for hidden small-text clauses that put legal limits in place which contradicts what a company's PR copy says.
I say all of this from the perspective of a programmer who wants to be able to sustain my own work, as a user of open source who wants to have some libraries that are fully open, and as a customer who wants to pay people for reliable software-related services.
As I said, Sentry doesn't owe new open source code to anyone. Deciding to make new releases closed is acceptable.
However, they have repeatedly made statements that they are committed to open source- some only months before this announcement. The 11 year old decision argument doesn't hold true.
They have a right to change their mind. But they shouldn't be lying to their customers and the community now that their mind has changed- https://sentry.io/_/open-source/ They continue to advertise that they are open source on their marketing website. That is a lie, and it marks Sentry as an unethical, dishonest company.
The wider debate on licensing terms and business models can move forward- it has existed since the beginning of the software industry and likely will persist for the foreseeable future. I prefer open source licenses. I think they are the best proposal for software licensing and distribution so far. If Sentry wants to do something different and use the BSL license, that is fine- but they shouldn't lie and claim to be open source.
What label would you like them to use? What is the accepted name for a middle ground license now? Should they be advertising themselves as a "business source" company rather than an "open source" company?
I don't ask this antagonistically, it's an honest question. I don't think they've shifted so much that they're just a standard company trying to make money off of proprietary software at this point.
"You can host your own service, or you can pay us to host the service, but you can't host the service and charge others for our service" is a business model I'd like to see continue.
There's a term for "proprietary projects whose source is available on GitHub", namely "source available". "Open Source" != "source available", and attempts to describe one as the other are clearly attempts to deceive
As I recall "Source Available" is a lot worse than what Sentry is proposing. It usually required signing an NDA or jumping through some other hoop in order to get the source. This is much better than that so I don't think it would be properly descriptive.
Shared Source was a term used in the past for proprietary licenses that shared the source. You suggest Business Source, and I would be fine with them using that term- as far as I know it isn't already taken.
I think you are wording that a bit strongly. They are still sharing the source just saying you can't load it up on a server and start selling that service. (you can load it internally for your own use though)
Yes, Open Source has had a very specific meaning historically and maybe we need a new term but this still feels like they are following the spirit to me.
Part of the "spirit" of open source is the freedom to use the software- including to use it to sell a service. This protects the freedom to fork the software, and pay for support or charge others for the support I provide for my forked version.
I had a very similar dilemma myself when putting together a project of mine a few months ago. However, at the end of the day, I felt that keeping the license of the solution (or core solution) as MIT was the best option irrespective, and my thoughts came from the following areas in which monetisation can be substantiated.
- Labor costs for staff, which include developers, network administrators, and support officers.
- Costs incurred for resources, server infrastructure, office resources and so fourth.
- And of course marketing and sales of the solution.
The key is to communicate this substation, therefore asking customers for donations, i feel, becomes irrelevant if you can do that effectively. So really the gist is "it's great that the software is free but someone has to run it and even more so someone has to keep supporting it".
Ideally, my opinion on monetisating comes from the business model which encapsulates the solution, therefore licensing the end product can just be focused around the tangibles that inherently make up the business side of a SaaS company.
I think the most murky part of this dilemma comes from professional services and enterprise grade solutions because this is where custom and closed treatment maybe needed for the client. Plus other issues come more from a security standpoint and trade secret standpoint than anywhere else. For instance customisation on top of a SaaS platform via APIs or integration work may require the asset (or code) to be closed source from the perspective to satisfy the clients' needs, but this has always been an issue and is not a SaaS centric problem as the argument only comes during the purchase cycle of a company and the IT manager asks the question "can our business trust open source?".
The model we are planning to use for the products at Plyint(https://plyint.com) is basically the "Free Software Product" model in a SaaS format. How this will work is we will release the code with a proprietary license, but then if you want to use it in a product or pure open source fork, then you need to go to the trouble of removing the company name and product references. Once, that is done then the license will become an AGPL license that can be used as one would normally expect and any modifications to that code would need to be released again publicly. (This way any fork is required to contribute their code back to the public domain)
I think this will introduce enough time delay that the SaaS service will establish itself. Plus, the product has to become popular enough for anyone to want to go through that level of effort. Also, any significant fork's code will be open source and we can reincorporate that into the original SaaS service as well.
> any modifications to that code would need to be released again publicly.
Technically, that is incompatible with the AGPL (and the GPL, for that matter). Private modifications without distribution are permitted by the GPL/AGPL, and if you don’t allow them, you are violating the GPL/AGPL license by adding this additional restriction.
Of course, this might not be a problem, for two reasons: Firstly, you might be the sole copyright holder, in which case you don’t need a license (it is instead you who give licenses to others), and secondly, for a SaaS product, any public use by a third party will make the AGPL kick in and require, from the third party, a release of the modified source.
> Also, any significant fork's code will be open source and we can reincorporate that into the original SaaS service as well.
Sure, but you will then no longer be the sole copyright holder, in which case you do need to adhere to the AGPL license terms, and you can’t require release of any modifications (except when the AGPL requires it; i.e. when the software is available publicly). Also, you can’t then release this code under a proprietary license, which you say is your plan.
Note: If you’re OK with the release of modifications which AGPL requires, then everything is fine. It’s only if you insist on the release of all private modifications that you could run into trouble.
> Technically, that is incompatible with the AGPL (and the GPL, for that matter). Private modifications without distribution are permitted, and if you don’t allow them, you are violating the license.
Sorry, I should have been more clear. I meant you make a modification AND offer a competing SaaS service. At that point under the AGPL that is considered distribution and would need to be open sourced.
> Sure, but you will then no longer be the sole copyright holder, in which case you do need to adhere to the AGPL license terms, and you can’t require release of any modifications. Also, you can’t then release this code under a proprietary license, like you describe.
Yes, so I was thinking about this as well. Basically what I'd like is an AGPL with a CLA that allows us to incorporate it back into the original service. I guess what would need to happen is specify in the original licensing of the product that the proprietary license converts to AGPL + CLA to Plyint.
You can’t require a CLA with AGPL. That would be an additional restriction, which AGPL does not allow. You can require a CLA for contributions to be accepted into your own distibution of the software (since you are not required to accept patches), but you can’t require anyone to sign or agree to a CLA if they recieved the software under AGPL.
It wouldn’t be fair either, I think, for you to sell the contributions of third parties as part of your software under a proprietary license. You can’t have your cake and eat it too; either you develop stuff yourself and get to sell it under whatever license you like, or you accept contributions from third parties all over the world under a free license, and you then sell the software to your customers under the AGPL, not a proprietary license.
You might be concerned about your customers then redistributing the AGPL software you sold them, but firstly, you might be able to fix this by requiring your customers to sign a contract with you (as part of the sale), where they agree not to do that, allowing you to sue them for breach of contract if they do. (I am not sure about the legal status of this scheme, however, and IIRC, the text of the GPL seems to want to at least discourage it.) Secondly, Red Hat allows CentOS to exist, and RH still makes a pretty penny selling RHE licenses. So this might not be a problem in practice.
EDIT: See also this post, linked by
jboynyc elswhere in this discussion:
> You can’t require a CLA with AGPL. That would be an additional restriction, which AGPL does not allow. You can require a CLA for contributions to be accepted into your own distibution of the software (since you are not required to accept patches), but you can’t require anyone to sign or agree to a CLA if they recieved the software under AGPL.
So, the term CLA might be too strong here. What I'm really wanting to do is add an additional term that allows for "any modification of the source code that is contributed back to an open source fork to then be reapplied to the proprietary product." This I don't believe qualifies as a "further restriction", because I'm just granting an additional right to the company to reincorporate the code into the original product and I'm not restricting the rights of the downstream user in anyway. (i.e. they can continue to offer a competing product and use it however they would like)
Section 7 of the AGPL say this at the end...
"Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.
To me what I'm asking for is a "permissive" additional term that qualifies under this section. Do you disagree?
From a principle perspective, I think as long as developers know up front (based on the licensing) that when they contribute code to and open source project that the code could be incorporated back into the original product, then they would be okay with that.
As I'm writing this, I had the thought that perhaps a simpler approach is simply to just open source it as AGPL from the beginning with the additional restriction to remove the Plyint trademarks from the code. That is fairly clearly spelled out in section 7 as a valid additional term.
> allows for "any modification of the source code that is contributed back to an open source fork to then be reapplied to the proprietary product."
That’s not an additional permission. That is granting yourself a right; i.e. a requirement imposed (on the legal author of the contribution) to give you this permission.
> Do you disagree?
Yes, I disagree. The author of a patch owns the copyright on that patch. You can’t reasonably believe that requiring this author to give you permission to do something constitutes an “additional permission” which you are giving to that author. It is obviously a restriction imposed on that author, since they would not otherwise be required to give you this permission.
A “permission” can only be something which you grant someone which 1. You are in a position to grant and 2. They would otherwise be not permitted to do. In the case of a software license like the AGPL, you the copyright holder have the sole right to copy the software. The license you give to others to copy the software under certain conditions is a thing which they would not otherwise be permitted to do under copyright law. Therefore, this “permission” that you want to give yourself, regarding copying the code authored by other people, does not qualify as such, since you are not in a position to give this permission, since you do not hold the copyright to the patch.
> From a principle perspective, I think as long as developers know up front (based on the licensing) that when they contribute code to and open source project that the code could be incorporated back into the original product, then they would be okay with that.
Maybe, but you’d have to find some legal way to accomplish this.
> As I'm writing this, I had the thought that perhaps a simpler approach is simply to just open source it as AGPL from the beginning with the additional restriction to remove the Plyint trademarks from the code. That is fairly clearly spelled out in section 7 as a valid additional term.
Oh, I agree completely. This would probably be the best for all involved.
Thanks for the cogent explanation. That actually makes a lot of sense to me.
> A “permission” can only be something which you grant someone which 1. You are in a position to grant and 2. They would otherwise be not permitted to do.
Did you pull this from somewhere? I would like to read more, if so.
Instead of CLA you may consider on requiring the contributions to be dual licensed MIT + AGPL. MIT allows you to use the code in your SAAS version. Your code, the constributions and the entire repo can be kept AGPL only (because MIT doesn't impose a condition on you to release the entire code as MIT).
Not necessarily, but that is always true, even for, e.g., GPL-only projects. I.e. a GPL-only project might recieve a patch, but if the patched code does not contain a license covering that patch, the project does not have a licence to the patch and cannot use it. The usual way this is fixed is by having clear descriptions in your developer’s documentation on how to contribute patches and what licenses must be given to recipients in order for you, the software maintainers, to accept the patch into the project.
We are in a similar position and probably survive mostly through luck despite having vendors that sell our Open Source SaaS without contributing anything meaningful back.
In our particular case I don't think the BSL would work for us, but I definitely understand and support Sentry going this route. FWIW, we have been using Sentry for almost a decade and while we started off hosting our own server we quickly saw the advantage in paying for it instead (and we were happy to do so).
It's a tough thing to balance for sure, they have been one of the players we watch to see how Open Source SaaS can work and I wish them luck.
We have been thinking about this a lot for our open-source Segment project (https://github.com/rudderlabs/rudder-server/). We launched things under mongo-SSPL (which is not a OSS approved license) but we now think AGPL is probably good enough for a product like ours. AGPL should kick in for anything (e.g. mobile app) that sends events to the our AGPL-backend so needs to be open-sourced too - that should be a strong enough deterrent for anyone to offer this as a service. Is this statement true? If yes, why did Mongo with with SSPL instead of AGPL?
At the same time, we still want businesses who don't care about OSS to use Rudder without having to open-source their code. To address that we are thinking of releasing our binary (and AMI images etc) under MIT license. Sure, someone can spin up a SaaS service on the binary but that's hard.
I think it is what a lot of my projects would aim to be. Free to use, tweak, contribute. Free to launch products using it. But not free to launch a service as SAAS or API that does more or less the same?
For my upcoming saas I wanted to do something similar...
-Paid hosted saas solution
-Freely downloadable to use and install for your own projects
...I want people to be allowed to make money with it even if they freely download it, but I just don't want them to be able to compete with my hosted saas.
I'm not quite sure that this is what the BSL is saying, so is there a license for something like that?
This is mostly the goal of MongoDB's license, the Service-Side Public License:
> A company that offers a publicly available MongoDB as a service must release the software it uses to offer such service under the terms of the SSPL, including the management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the source code made available.
I think that is what Armin was looking for as well, but couldn't find anything that quite did that so settled on the BSL instead (probably because determining what fork qualifies as competing or not seems hard). BSL seems close, but seems to disallow any commercial usage (IANAL!)?
I've looked into this in the past and couldn't find any non commercial licenses. Creative Commons has one, but it isn't suitable for software as it lacks a warranty clause. Curious if there is anything out there too.
It is kinda ironic that most people zealously arguing for the "pure" open source definition and harrassing authors here on HN or even on Github issues are the ones who work for FAANG-tier companies and making 6 figures contributing little to nothing to open source projects or getting paid for their contributions. There must be a way to protect authors and small startups from simply being ripped-off by any lazy for-profit entity. I don't think that 99.99999% of users would mind to use an application that is identical with MIT, Apache, GPL plus a clause that protects the author or company that created it.
The author has chosen an approach which makes the software available under the Apache 2.0 license after an embargo period. This is quite okay under the "pure" open source definition (at least for those "liberated" releases, if obviously not in the broadest sense), and nobody is harassing him for that. Many crowdfunding models come with this sort of time-limited "exclusivity".
but that's exactly what they do, many people here posted SHOW HN threads for github for-profit projects that use clauses in licenses or licenses like BSL, SSPL and the posts turned into harassment party because of the "hijacking" of pure open source according to them.
I have no problems seing the justification for that.
What certain people does, that makes me and others react is when they insist on their commons clause licensed applications or libraries being open source.
The problem here is programmers having a fixation on licences as some sort of template that must be followed exactly without having any real experience with how the law actually works. This is convenient for something like an OSS license used extensively because you have some common reference.
However, many contracts don't follow a template and it's normal in other contracts for items to be customized to any extent required. Template licenses are often used to intimidate people who aren't aware of their rights and what is possible. For example, employers may say that they can't modify an employment agreement because it's a standard template to make the potential employee feel like there is some legal rather than policy issue at play. Similar things happen in other places and you have to decide how much you want to fight policy, but parties almost always have the option of agreeing on custom terms.
This is hard today in the OSS ecosystem, but it'll have to evolve to support additional terms.
>I remember too many cases of people that tried to do dual licensing with code and ended up regretting it after ownership was transferred or they had a fall out with other partners.
Open is almost universally good. Open means self-hosting, auditability, ability to patch/submit patches for problems yourself, and not being up shit creek if the provider folds.
But Free? Free might not always be bad, but it has a lot of problems. Free = a race to the bottom. Free = ads. Free = selling user data. Free = no one cares enough to maintain it. Free = no one cares enough to promote it. Free = no one can afford to hire a UX designer. Free = ripped off by AWS. Free = bait and switch when the VC gets impatient.
For all these reasons, you should demand access to the code, yes, but you should also be willing to pay the people who write the crucial software you rely on. It's far more sustainable and healthier for our industry.