4 ms·

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

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
    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) But I get your point. Need to do more work here.
    - pritambaral 7y ago
      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]. ---- 1: https://en.wikipedia.org/wiki/Open-source_model https://en.wikipedia.org/wiki/Open-source_model 2: https://news.ycombinator.com/item?id=18301116 https://news.ycombinator.com/item?id=18301116 3: https://fedoraproject.org/wiki/Licensing/SSPL https://fedoraproject.org/wiki/Licensing/SSPL
      - soumyadeb 7y ago

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
  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) But I get your point. Need to do more work here.
  - pritambaral 7y ago
    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]. ---- 1: https://en.wikipedia.org/wiki/Open-source_model https://en.wikipedia.org/wiki/Open-source_model 2: https://news.ycombinator.com/item?id=18301116 https://news.ycombinator.com/item?id=18301116 3: https://fedoraproject.org/wiki/Licensing/SSPL https://fedoraproject.org/wiki/Licensing/SSPL
    - soumyadeb 7y ago