7 ms·
Founder of RudderStack (https://github.com/rudderlabs/rudder-server https://github.com/rudderlabs/rudder-server - open-source alternative to Segment) here. We a
by soumyadeb 7y ago
Founder of RudderStack (https://github.com/rudderlabs/rudder-server https://github.com/rudderlabs/rudder-server - open-source alternative to Segment) here. We are SSPL and this is the feedback we get all the time.
I totally appreciate the sentiment around SSPL being not open-source but honestly, we don't know what is an alternative.
We want to build an open-source product but also build a commercial entity around it – which means we want to stop the cloud providers from offering this as a service.
We explored a couple of alternatives. AGPL does provide a similar level of protection against cloud providers – any app talking to RudderStack over an API to send events would be forced to open-source the app and hence it is almost not possible to build a SaaS service on top. But for this exact same reason, our users don’t like AGPL. AGPL is considered an absolute NO in lot of enterprises. To get around this, we have also thought of releasing our binary (and AMI images, docker images) under MIT license so that people can still run it but then but that was getting too complicated for a licensing model plus this doesn't stop AWS from offering it as a service. As you pointed out, Apache with Common Clause, CockroachDB license are all alternatives but none are true open-source.
We are just hoping that one of the big OSS guys (with the budget to pay the attorneys) will figure this shit out once for all and we can just follow.
- ocdtrekkie 7y agoThe SSPL seems like the ideal solution, and very in the spirit of copyleft. I find it unfortunate that the OSI is treated as the only determiner of “what open source is” and that they have failed to accept SSPL.
- soumyadeb 7y agoI agree but looking at the downvotes to my response, doesn't seem like the HN community agrees. SSPL may have drawbacks and there may be a better license than SSPL but someone needs to invest time and effort for that - hopefully the big OSS guys will take a lead.
- cycloptic 7y agoTrying to pressure the OSI into accepting a license is not the way to go. There are valid reasons that they rejected it. This isn't exactly some cabal of lawyers trying to make you miserable, the SSPL was also independently banned by Debian and Fedora for not meeting their own guidelines on open source licenses. The review process for all of these organizations was lengthy and public and still available if you want to find it.
- ocdtrekkie 7y agoI've read much of the review processes, and the OSI's position as I understand it, is pretty shameful. They seem happy to just decide they don't need to solve this problem. They seem perfectly happy to let open source businesses die while they hold a position solely beneficial to Amazon, Microsoft, and Google. I have no particular attachment to the SSPL or it's exact terms, but if the OSI was worthy of the high position they've been granted, they would actually gather up the lawyers behind SSPL, Commons Clause, BSL, etc. and hammer out a solution that was agreeable to all parties. Open source as a movement will live or die on whether or not either the OSI addresses this issue, or we unseat our caring for the OSI's position.
- cycloptic 7y ago>They seem perfectly happy to let open source businesses die while they hold a position solely beneficial to Amazon, Microsoft, and Google. Approving discriminatory licenses is not a solution and would put even more power in the hands of those large companies. I guarantee your company would be pretty damn unhappy if Amazon, Microsoft, and Google said something you wanted was open source and then it turned out it was SSPL/Commons Clause/BSL. >they would actually gather up the lawyers behind SSPL, Commons Clause, BSL, etc. The OSI does not gather up lawyers. They are a charity. You submit them a license and then they review it and decide whether to endorse it or not. That's what they do. Funding a large group of lawyers to make a new license is out of scope for them. I actually agree with you that something like this should happen in the long-term, and the OSI should be involved, but they are not the ones you need to lean on to kick-start the process. >Open source as a movement will live or die on whether or not either the OSI addresses this issue, or we unseat our caring for the OSI's position. There is nothing to address. MongoDB didn't address any of the community's concerns and then pulled out of the license review process instead of fixing the license. Like I said, pressuring the OSI is not the way to go and these threats (?) are misdirected and totally irrelevant on HN anyway -- Official OSI discussion doesn't happen here, and trying to dilute the term "open source" for marketing reasons benefits nobody, not even when it's your company. If you have concerns about the process, you should bring it up with MongoDB. The ball apparently is in their court.
- cycloptic 7y agoI don't understand your logic. You're complaining that your customers don't like AGPL, so instead you're using the SSPL? The license that was rejected because it was seen as being an even more restrictive version of the AGPL? What does it matter anyway since your goal is to get people off the open source version and paying for the enterprise version? > we want to stop the cloud providers from offering this as a service Stop thinking about this. You can't stop cloud providers from offering it as a service and still call it open source. The only thing you can do is force them to also open source their cloud offering. If you want to call yourself open source, this is the sphere you need to operate in. You can't just try to cut them off because the company is too big. What you should be looking for is a license that makes it easier to convert them into paying customers. Maybe that's AGPL, maybe it's something else, I don't know. Or you can just stop calling yourself open source. I personally think the SSPL sort of goes in the right direction as an "enhanced AGPL" license, but misses the mark in some key areas. Please participate in community licensing discussions if this is what you're interested in. It's possible to make a better license that will work, but it will only happen after lots of feedback from interested users. This isn't just about the big guys, if you don't participate in these discussions then don't be surprised when your company's needs aren't met.
- soumyadeb 7y agoThanks for the feedback around participating - makes total sense. Our goal is to get people off the open-source version because they need something extra (mostly support right now but eventually more enterprise features). The balance of what is open-source vs what is enterprise is 99%-1% now and will probably shift to 80-20% over time and our goal is to make money from enterprises who care about that 20%. Why can't there be a license which is "open-source" but stops anyone from building a "directly competiting commercial offering" out of the 80%. I guess there is complexity around how to define "directly competiting" but that should be solvable. My understanding is that SSPL kind of does that. It is based out of GPLv3 so who are just using Rudder (or Mongo) over API are happy. And it specifically restricts commercially offering this as SaaS.
- cycloptic 7y ago
- zzo38computer 7y agoThen perhaps multilicense, using both SSPL and AGPL (so that users can use whichever license they need, or can keep both if they want to)? That would seem to fit your requirements as far as I can understand them.