Thanks 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.
>Why can't there be a license which is "open-source" but stops anyone from building a "directly competiting commercial offering"
Because it is not an "open-source" license if it restricts how people can use the code. There is no "except for direct competitors" loophole.
The SSPL is a "source-available" license, not an "open-source" one.
I certainly sympathize with your outlook; everyone needs to make a living. But I could also understand people complaining if you're advertising your SSPL code as open-source, because...it isn't.
I am not hiding that we are SSPL (I am trying to defend it here :)) But to understand your concern, you are saying someone owns the (copyright or whatever legal structure is) term "open-source" and us using is a violation of that.
It's not so much a legal thing as an ideological one. "Open-source" is a manifestation of the idea that knowledge should be free. It's based on the belief that societies grow when people are not restricted in how they build upon our collective accomplishments.
We have plenty of ways to reward innovation: patents, closed IP, commercial licensing, etc. But open source is about giving freely to the people around you, not rewards.
Selective commercial licensing is fine, and it's still nice that you let people see how things work so that they can learn and suggest improvements. But it isn't open source, and it feels deceptive when people misuse the term. Open-source code is a gift, and gifts don't come with demands.
Gift without demand is an interesting analogy. But if you think about it, licenses like GPLv3 and AGPL do have very strong restrictions on how to use the software. Fair enough that they are not to "reward back to you" but around "how to use the gift".
SSPL is essentially GPL + a small restriction on certain usage (which practically only impacts the large cloud providers). To say, this is just "source available" is not entirely fair. This is different from Oracle saying you can see DB source to do your security scan but that's all.
But I get your overall point. Need to think more on how to position this so people don't feel "deceived" but at the same time appreciate the "free/open-ness" part of it. SSPL may not be the answer but there has to be a solution.
Yes, but I also dislike copyleft for the same reasons. Personally, I draw a distinction between "open-source" software and the more restrictive and viral "Free Software" which Stallman argued for, but that's been argued ad nauseum.
My opinion is obviously far to one side of this debate, but you said that you had users who didn't like your license. People who feel that open source is important might see extra restrictions as extra liabilities.
Hey, did you ever hear about that time when IBM's lawyers had to ask for an exemption to a license which required that the software be "used for Good, not Evil"? :)
The term predates its use in software, but as used in the software industry it typically refers to the Open Source Definition: https://opensource.org/osd
Deviating from that isn’t illegal (they don’t own the term), but claiming your software is open source if it doesn’t meet that definition will generally earn you some blowback.
SSPL is a copyleft license, and it's definitely open source. It doesn't prohibit competitive commercial offerings. It just requires them to share their source, just like a GPL.
What you're describing is essentially the commons clause and it's not considered open source because it discriminates against commercial activity. The point of open source is to give everyone a shared technology base to work from, including both you and your competitors. If they're contributing then you can take their code and use it to improve your product too. You can also use your open source offering to upsell them on those additional services. This is how it's always worked. I try to illustrate this with an example: can you imagine how inconvenient it would be for your product if all those open source libraries [0] you depended on had such a condition?
The reality is that the open source projects that are big today did not get big by refusing contributions from companies that were deemed to be too big or thought to be competitors. The projects got big by finding a productive way to work with those companies.
Fair enough but I would still try to draw a line with "direct competition". I am not directly competing with any of these libraries. In the same vein, if some eCommerce company uses RudderStack and builds their Analytics stack around it, I would be super happy. I just don't want someone else to take this code and offer Rudder as a service. There must be a way to differentiate between these two scenarios.
You wouldn't know if you were competing against the parent companies of those libraries unless you checked and did the legal legwork.
>There must be a way to differentiate between these two scenarios.
That is covered rather succinctly by the commons clause, but it's not open source and will give you similar concerns from companies. If you want to skip that and go with an actual open source license, you'll have to find a way to differentiate your service offering. Don't compete on price. The AGPL approach also does move towards the same goal and is still considered open source, but as you've seen, you have to do more work to implement it and please your downstream users.
There are generally no shortcuts here: the popular open source licenses are used because they are widely understood and don't have much in the way of legal risks. Any company including yours can just pick it up and go. When you start trying to discriminate against certain customers, that's when you stop being able to just get into any given company without going through legal. So pick your poison.
Competing on price is actually hard because people who are price sensitive will go with the open-source version. We want to compete on the flexibility aspect of open-source - the fact that you can change the code however you want as per your needs, the fact that you can deploy it however you want (and hence have complete access to your data)
Your arguments in this thread seem to be coming from a single point of disagreement: the point and definition of "Open Source".
> We want to compete on the flexibility aspect of open-source - the fact that you can change the code however you want as per your needs, the fact that you can deploy it however you want (and hence have complete access to your data)
This does not cover the point of Open Source. The point of Open Source is _open collaboration_[1]. Putting a restriction on use discourages open collaboration.
Take your chosen license, for example. If I wanted to improve your code, licensed by you to me under the SSPL, I'd add my own code to it. Sure, the code I added would need to be released by me under the SSPL too, but I would still retain copyright on my code. Now, if you liked what my code did and wanted to use it, _you_ would be subject to the SSPL too. Would _you_ be willing to comply with the SSPL, for my code, especially when the SSPL cannot be legally complied with[2]?
Now, the creators of the SSPL can get away with it because they aren't subject to it themselves, because the retain all the copyrights of all the code they release, and do not accept any code from anyone without also demanding a copyright transfer to them. This is complete ownership, not collaboration.
There's a reason open source distributions, who have no intention of competing with MongoDB Inc.'s business, stopped distributing MongoDB in their repositories. I will just leave Fedora's opinion on the matter as supporting evidence[3].
The copyright argument on code contribution is orthogonal to the license. You are free to fork the repo and make whatever modifications on top and own the copyright on the addition but if you want to contribute code back, pretty much all popular open-source projects would want them to assign copyright back to them.
Licensing will govern what you can and cannot do with the repo you clone or fork. SSPL is GPL except for this additional hosting clause for service providers. So, the argument on whether it violates open_source ethos or not has to be around that clause.
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.