4 ms·

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 e

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
      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.
      - 7y ago

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
    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.
    - 7y ago