6 ms·

I 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 i

I 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 ago
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.
- cycloptic 7y ago
  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. [0] https://github.com/rudderlabs/rudder-server/blob/master/go.mod https://github.com/rudderlabs/rudder-server/blob/master/go.m...
  - soumyadeb 7y ago
    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.
    - cycloptic 7y ago
      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.

soumyadeb 7y ago

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.

cycloptic 7y ago
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. [0] https://github.com/rudderlabs/rudder-server/blob/master/go.mod https://github.com/rudderlabs/rudder-server/blob/master/go.m...
- soumyadeb 7y ago
  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.
  - cycloptic 7y ago
    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.