Open Source, SaaS and Monetization
lucumr.pocoo.org
lucumr.pocoo.org
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.
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.
An analogy would be - you have "Freedom of Speech" in a democracy but it requires a 100$ payment. Maybe?
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.
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.
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!
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.
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).
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.
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.
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"?
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.
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.
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.
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.
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.
Whether and how to enforce the license is up to the developer.
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.
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 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.
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?
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.
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.
[https://blog.sentry.io/2019/02/14/sentry-thrives-open-source..., https://blog.sentry.io/2016/10/24/building-an-open-source-se..., https://blog.sentry.io/2015/06/30/driven-by-open-source]
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.
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.
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.
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.
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.
- 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?".
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.
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.
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:
https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
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.
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.
> 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.
Thank you! A lot of this licensing stuff actually does make sense if you just look at it the right way.
> Did you pull this from somewhere? I would like to read more, if so.
Sorry, no. Just from many years of arguing about licensing on the net. For further reading, I would suggest this:
See further this post:
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.
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.
Any feedback on this would be highly appreciated.
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?
* [1] https://www.cockroachlabs.com/blog/oss-relicensing-cockroach...
-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?
> 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.
https://www.mongodb.com/licensing/server-side-public-license...
I can like the idea of the BSL.
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.
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.
Can somebody here elaborate on this?