3 ms·

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 pr

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.
- ocdtrekkie 7y ago
  > The way SSPL is written it doesn't differentiate between those two use cases This is untrue. SSPL very clearly differentiates. It states article 13 only takes effect if you offer the covered product as a service. The key phrase you need to pay attention to in the SSPL is: > offering a service the value of which entirely or primarily derives from the value of the Program or modified version So if AWS offers MongoDB-as-a-service with the newer licensed version, SSPL means they have to release the related service tools as open source. If Sandstorm used the new SSPL-licensed MongoDB (it currently doesn't), and AWS offered Sandstorm-as-a-service, article 13 of SSPL would not activate, because the primary purpose of the service is Sandstorm, not MongoDB. To my understanding, other products that use SSPL-licensed dependencies would not have any limitations more egregious than the GPL itself.
  - cycloptic 7y ago
    I know about that phrase. The problem is that it doesn't match with the way big companies deploy services. They set it up across the company and then expose it externally so they can recoup costs. The reason it's open source to them is because they are allowed to do this and because it's easy, if it wasn't for this they would have zero interest in participating in the community. I assume you know this full well since this seems to be what you believe the SSPL attempts to stop? The other problem I have with that section (and this is where it gets into my personal opinion) is that the forced copylefting of everything else doesn't make any sense. The GPLs are very clear that they only apply to the software covered by the license and any derived works. The SSPL leans way over that. These type of "extreme copyleft" licenses have been around before and they never stuck because it's really difficult for anyone to comply with them. People participating in the MongoDB community care about the database, they don't care about getting the source code to some unrelated components that happen to be on the same server. The whole section just reads like a bad attempt at additional activism to get Amazon to release the source code to AWS. And don't get me wrong, I'm an open source advocate, I think it would be cool if AWS was open sourced. But they aren't going to do it as a result of the license in some random database. If they ever do, it will be because their paying customers asked for it.

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.

ocdtrekkie 7y ago
> The way SSPL is written it doesn't differentiate between those two use cases This is untrue. SSPL very clearly differentiates. It states article 13 only takes effect if you offer the covered product as a service. The key phrase you need to pay attention to in the SSPL is: > offering a service the value of which entirely or primarily derives from the value of the Program or modified version So if AWS offers MongoDB-as-a-service with the newer licensed version, SSPL means they have to release the related service tools as open source. If Sandstorm used the new SSPL-licensed MongoDB (it currently doesn't), and AWS offered Sandstorm-as-a-service, article 13 of SSPL would not activate, because the primary purpose of the service is Sandstorm, not MongoDB. To my understanding, other products that use SSPL-licensed dependencies would not have any limitations more egregious than the GPL itself.
- cycloptic 7y ago
  I know about that phrase. The problem is that it doesn't match with the way big companies deploy services. They set it up across the company and then expose it externally so they can recoup costs. The reason it's open source to them is because they are allowed to do this and because it's easy, if it wasn't for this they would have zero interest in participating in the community. I assume you know this full well since this seems to be what you believe the SSPL attempts to stop? The other problem I have with that section (and this is where it gets into my personal opinion) is that the forced copylefting of everything else doesn't make any sense. The GPLs are very clear that they only apply to the software covered by the license and any derived works. The SSPL leans way over that. These type of "extreme copyleft" licenses have been around before and they never stuck because it's really difficult for anyone to comply with them. People participating in the MongoDB community care about the database, they don't care about getting the source code to some unrelated components that happen to be on the same server. The whole section just reads like a bad attempt at additional activism to get Amazon to release the source code to AWS. And don't get me wrong, I'm an open source advocate, I think it would be cool if AWS was open sourced. But they aren't going to do it as a result of the license in some random database. If they ever do, it will be because their paying customers asked for it.