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.
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 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.
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.
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.
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.
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.
- 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.
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...
Can somebody here elaborate on this?
