3 ms·

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 sou

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.
  - ocdtrekkie 7y ago
    The ironic thing is: SSPL could actually make it possible for Amazon to choose to open source AWS. Because they could share the source without letting their competitors steal their competitive edge. I could benefit from the technology AWS developed without Azure or Google Cloud being able to similarly clone it. A business-viable open source license opens the potential to massively expand the viability of open source businesses and the practice of open sourcing code. SSPL's language probably needs a tweak or two, but that section communicates the intent of the SSPL very well: It's literally Wheaton's Law. "Take our stuff, build cool stuff with it. Don't literally copy it for the purposes of putting us out of business."
    - cycloptic 7y ago
      I don't think that's true. If the competitive edge is in the released code, then MS and Google would also be able to use that and contribute to it to if they also followed the terms. What you would really want is for all of these companies to follow the terms of the SSPL, not just one of them. But doing that would be very hard with the SSPL as it is now. It has a serious practical issue which was inserted on purpose in order to prevent adoption by those companies. I disagree that open source needs more licenses that are deemed "business-viable". Open source is a development strategy for sharing code, it has nothing to do with any business model. This is why MIT- and BSD-licensed code is the cornerstone of all these startups, those licenses don't give a crap what your business model is and it would be really bad if they did. If you want to help the community, please make it your priority to think about things that are good for everyone, not just your business. If you want to know my take on the philosophy of this, it's more like "Take our stuff, build cool stuff with it. Literally copy it if you want, it doesn't matter because our business is strong enough to withstand it." You might think I'm favoring large companies here but being strong enough to withstand it isn't about having more money, it's about having enough to differentiate yourself in the marketplace. Any company can have that, and if you're taking outside funding you probably should have that before you even talk to investors. I hate that I have to keep saying this but open source is about sharing code with everyone including your competitors. If you do it right you get to use their code too and everyone makes tons of money. Banning them from using your code entirely will not help to accomplish this goal.
soumyadeb 7y ago
To your point around the business model, yes we know its for us to figure out. The simple option is we continue to use "open-source" for promoting us and leave it to our users to make their final judgment (from experience, 99% of our users are perfectly fine with SSPL license and eventually we will pay for lawyers and create RudderLicense). This is just like with any other marketing where end-users make the final judgment. However, we believe that it is good for the overall community that someone takes a lead to figure this out. Our situation is not unique to us but being faced by every commercial open source company in the world. It is not a dispute between just two parties that we are requesting OSI to get involved with. Fair point around getting involved in the licensing discussions. Engaging with Google/Microsoft/Amazon etc is where I believe OSI needs to take a lead

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.
- ocdtrekkie 7y ago
  The ironic thing is: SSPL could actually make it possible for Amazon to choose to open source AWS. Because they could share the source without letting their competitors steal their competitive edge. I could benefit from the technology AWS developed without Azure or Google Cloud being able to similarly clone it. A business-viable open source license opens the potential to massively expand the viability of open source businesses and the practice of open sourcing code. SSPL's language probably needs a tweak or two, but that section communicates the intent of the SSPL very well: It's literally Wheaton's Law. "Take our stuff, build cool stuff with it. Don't literally copy it for the purposes of putting us out of business."
  - cycloptic 7y ago
    I don't think that's true. If the competitive edge is in the released code, then MS and Google would also be able to use that and contribute to it to if they also followed the terms. What you would really want is for all of these companies to follow the terms of the SSPL, not just one of them. But doing that would be very hard with the SSPL as it is now. It has a serious practical issue which was inserted on purpose in order to prevent adoption by those companies. I disagree that open source needs more licenses that are deemed "business-viable". Open source is a development strategy for sharing code, it has nothing to do with any business model. This is why MIT- and BSD-licensed code is the cornerstone of all these startups, those licenses don't give a crap what your business model is and it would be really bad if they did. If you want to help the community, please make it your priority to think about things that are good for everyone, not just your business. If you want to know my take on the philosophy of this, it's more like "Take our stuff, build cool stuff with it. Literally copy it if you want, it doesn't matter because our business is strong enough to withstand it." You might think I'm favoring large companies here but being strong enough to withstand it isn't about having more money, it's about having enough to differentiate yourself in the marketplace. Any company can have that, and if you're taking outside funding you probably should have that before you even talk to investors. I hate that I have to keep saying this but open source is about sharing code with everyone including your competitors. If you do it right you get to use their code too and everyone makes tons of money. Banning them from using your code entirely will not help to accomplish this goal.

soumyadeb 7y ago

To your point around the business model, yes we know its for us to figure out. The simple option is we continue to use "open-source" for promoting us and leave it to our users to make their final judgment (from experience, 99% of our users are perfectly fine with SSPL license and eventually we will pay for lawyers and create RudderLicense). This is just like with any other marketing where end-users make the final judgment. However, we believe that it is good for the overall community that someone takes a lead to figure this out. Our situation is not unique to us but being faced by every commercial open source company in the world. It is not a dispute between just two parties that we are requesting OSI to get involved with. Fair point around getting involved in the licensing discussions. Engaging with Google/Microsoft/Amazon etc is where I believe OSI needs to take a lead