4 ms·

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, sh

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.
  - cycloptic 7y ago
    The way SSPL is written it doesn't differentiate between those two use cases. It just says basically "if you deploy this on your backend you have to release source for everything else on your backend." So they would still be banned from using it in their eCommerce stack. Those other companies are facing challenges because they don't add enough value on top of any other hosted offerings. Instead of focusing on what additional value they can provide, they focus on trying to destroy value created by Amazon. This is not the way to practice open source. >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. I don't see how your choice of SSPL is supposed to protect the community from this. You have a CLA in place which still means you're reserving the right to switch license at any time. The community is absolutely not protected from this type of "cheating" at the moment. >But OSI as a community needs to do something to help projects/companies like us. It is not anyone else's responsibility to look out for your business model. That's your responsibility. To protect your company, create value that customers actually want to pay for. Participate in community licensing discussions and see what your community actually wants. Reach out to Amazon/Microsoft/Google/etc. and talk to them to see if you can come up with an open source strategy that would mutually benefit everyone. The OSI just reviews licenses submitted to them, they can't guess what it is that you need, and they definitely can't resolve some long-standing dispute you might have with other companies.

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.
- cycloptic 7y ago
  The way SSPL is written it doesn't differentiate between those two use cases. It just says basically "if you deploy this on your backend you have to release source for everything else on your backend." So they would still be banned from using it in their eCommerce stack. Those other companies are facing challenges because they don't add enough value on top of any other hosted offerings. Instead of focusing on what additional value they can provide, they focus on trying to destroy value created by Amazon. This is not the way to practice open source. >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. I don't see how your choice of SSPL is supposed to protect the community from this. You have a CLA in place which still means you're reserving the right to switch license at any time. The community is absolutely not protected from this type of "cheating" at the moment. >But OSI as a community needs to do something to help projects/companies like us. It is not anyone else's responsibility to look out for your business model. That's your responsibility. To protect your company, create value that customers actually want to pay for. Participate in community licensing discussions and see what your community actually wants. Reach out to Amazon/Microsoft/Google/etc. and talk to them to see if you can come up with an open source strategy that would mutually benefit everyone. The OSI just reviews licenses submitted to them, they can't guess what it is that you need, and they definitely can't resolve some long-standing dispute you might have with other companies.