6 ms·

Let's come up with another term then. Maybe, Non-OSI-Approved open-source? 99% of our users love us and appreciate the fact that they have an alternative to Se

Let's come up with another term then. Maybe, Non-OSI-Approved open-source? 99% of our users love us and appreciate the fact that they have an alternative to Segment which lets them host it however way they want and keep complete ownership of their data AND to modify the code to suit their needs and don't have to pay gazillions of dollars. Stopping projects like us from reaching out to them will not serve the OSS in the long run. Look, we are a small project and no-body cares about us now - neither the OSI community nor the cloud service providers. The reason we picked SSPL was that it is much easier to go from SSPL to a less restrictive license if required than the other way around when we become big.

cycloptic 7y ago
You can just say "source available" or "freeware with source", either one of those work. I don't understand this obsession with trying to co-opt the term "open source". It has a specific meaning, trying to use it for marketing purposes when your project doesn't fit that meaning is misleading to your users. You don't win any points for using it when they later find out that it's not true.
- soumyadeb 7y ago
  From WikiPedia "Any software is source available software as long its source code is distributed along with it, even if the user has no legal rights to use, share, modify or even compile it." If you are telling me that we are closer to a source-available license (e.g. which doesn't even allow its users to compile the code) than an open-source license, that is being unfair. Yes, that preserves the "sanctity of open-source" but does it help the community in the long run? The world will only have vendor locked in SaaS like Segment and volunteer-run open-source products (which no doubt has produced great products but at a much much smaller scale). We are not trying to mislead our users. We make our license very clear and that's why I am trying to defend it on this thread too. I could have not replied on the top thread and stayed silent - would have saved some karma points from all the downvotes :) We are engineers, not a licensing expert nor do we have the money to pay for attorneys so whatever we are saying is self-learnt. SSPL may not be the right license but we need to find a solution. But just kicking us out saying we are not open-source by the book will not help the movement.
  - cycloptic 7y ago
    I'm not talking about helping a movement. I'm talking about what best helps your users/customers. With the SSPL, certain users do not have legal rights to use, share, modify or even compile it, as they can't reasonably comply with section 13. It can hardly be called open source because it discriminates against them. Think about this from the perspective of another engineer in your community. Say that engineer loves your product, contributes pull requests regularly, deploys it at every company they go to work for. Some of the companies convert and buy your service offering. Everything is well, business is good, that engineer is considered a valuable member of your community. Now at some point in their career the engineer goes to work for Amazon, or their company gets bought by Google or something. All of a sudden they can't deploy it at work and they're not allowed to participate anymore? It doesn't make any sense. I'm not really going by the strict word of the SSPL here either, this sounded like it was your intent a few posts ago. Edit: If you do end up in that situation, the only thing you can really do as a startup to correct it is to hire the person before they get snatched up by BigCo. But if your company is still in early growth stages then you are probably not going to have the resources to make this happen with every community member. So I can't see how the SSPL is helping here.
    - soumyadeb 7y ago
      Fair enough though I will add a small caveat - I have no problem if Amazon uses Rudder in their eCommerce stack (that would be awesome!!), just don't want to provide Rudder as a service in AWS marketplace. Ignoring that, look at the other alternative. If we don't solve this, no-one will invest in us (given the challenges larger companies like Confluent, Mongo etc are facing from AWS). We can continue to develop this as a volunteer project but coming with a realistic alternative to Segment is a tall ask. You know, what is the easier solution for us? Switch to an open-source license (AWS doesn't care about us anyway), grow with the community's help and once we become big switch to a different license. THAT IS cheating the community and the users. That's why we are upfront about it in spite of all the blowback. But OSI as a community needs to do something to help projects/companies like us.
      - 7y ago

cycloptic 7y ago

You can just say "source available" or "freeware with source", either one of those work. I don't understand this obsession with trying to co-opt the term "open source". It has a specific meaning, trying to use it for marketing purposes when your project doesn't fit that meaning is misleading to your users. You don't win any points for using it when they later find out that it's not true.

soumyadeb 7y ago
From WikiPedia "Any software is source available software as long its source code is distributed along with it, even if the user has no legal rights to use, share, modify or even compile it." If you are telling me that we are closer to a source-available license (e.g. which doesn't even allow its users to compile the code) than an open-source license, that is being unfair. Yes, that preserves the "sanctity of open-source" but does it help the community in the long run? The world will only have vendor locked in SaaS like Segment and volunteer-run open-source products (which no doubt has produced great products but at a much much smaller scale). We are not trying to mislead our users. We make our license very clear and that's why I am trying to defend it on this thread too. I could have not replied on the top thread and stayed silent - would have saved some karma points from all the downvotes :) We are engineers, not a licensing expert nor do we have the money to pay for attorneys so whatever we are saying is self-learnt. SSPL may not be the right license but we need to find a solution. But just kicking us out saying we are not open-source by the book will not help the movement.
- cycloptic 7y ago
  I'm not talking about helping a movement. I'm talking about what best helps your users/customers. With the SSPL, certain users do not have legal rights to use, share, modify or even compile it, as they can't reasonably comply with section 13. It can hardly be called open source because it discriminates against them. Think about this from the perspective of another engineer in your community. Say that engineer loves your product, contributes pull requests regularly, deploys it at every company they go to work for. Some of the companies convert and buy your service offering. Everything is well, business is good, that engineer is considered a valuable member of your community. Now at some point in their career the engineer goes to work for Amazon, or their company gets bought by Google or something. All of a sudden they can't deploy it at work and they're not allowed to participate anymore? It doesn't make any sense. I'm not really going by the strict word of the SSPL here either, this sounded like it was your intent a few posts ago. Edit: If you do end up in that situation, the only thing you can really do as a startup to correct it is to hire the person before they get snatched up by BigCo. But if your company is still in early growth stages then you are probably not going to have the resources to make this happen with every community member. So I can't see how the SSPL is helping here.
  - soumyadeb 7y ago
    Fair enough though I will add a small caveat - I have no problem if Amazon uses Rudder in their eCommerce stack (that would be awesome!!), just don't want to provide Rudder as a service in AWS marketplace. Ignoring that, look at the other alternative. If we don't solve this, no-one will invest in us (given the challenges larger companies like Confluent, Mongo etc are facing from AWS). We can continue to develop this as a volunteer project but coming with a realistic alternative to Segment is a tall ask. You know, what is the easier solution for us? Switch to an open-source license (AWS doesn't care about us anyway), grow with the community's help and once we become big switch to a different license. THAT IS cheating the community and the users. That's why we are upfront about it in spite of all the blowback. But OSI as a community needs to do something to help projects/companies like us.
    - 7y ago