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.
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.
"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.
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.
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.
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.
> 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.
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.
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."
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.
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
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.