I totally appreciate the sentiment around SSPL being not open-source but honestly, we don't know what is an alternative.
We want to build an open-source product but also build a commercial entity around it – which means we want to stop the cloud providers from offering this as a service.
We explored a couple of alternatives. AGPL does provide a similar level of protection against cloud providers – any app talking to RudderStack over an API to send events would be forced to open-source the app and hence it is almost not possible to build a SaaS service on top. But for this exact same reason, our users don’t like AGPL. AGPL is considered an absolute NO in lot of enterprises. To get around this, we have also thought of releasing our binary (and AMI images, docker images) under MIT license so that people can still run it but then but that was getting too complicated for a licensing model plus this doesn't stop AWS from offering it as a service. As you pointed out, Apache with Common Clause, CockroachDB license are all alternatives but none are true open-source.
We are just hoping that one of the big OSS guys (with the budget to pay the attorneys) will figure this shit out once for all and we can just follow.
> we want to stop the cloud providers from offering this as a service
Stop thinking about this. You can't stop cloud providers from offering it as a service and still call it open source. The only thing you can do is force them to also open source their cloud offering. If you want to call yourself open source, this is the sphere you need to operate in. You can't just try to cut them off because the company is too big. What you should be looking for is a license that makes it easier to convert them into paying customers. Maybe that's AGPL, maybe it's something else, I don't know. Or you can just stop calling yourself open source.
I personally think the SSPL sort of goes in the right direction as an "enhanced AGPL" license, but misses the mark in some key areas. Please participate in community licensing discussions if this is what you're interested in. It's possible to make a better license that will work, but it will only happen after lots of feedback from interested users. This isn't just about the big guys, if you don't participate in these discussions then don't be surprised when your company's needs aren't met.
Our goal is to get people off the open-source version because they need something extra (mostly support right now but eventually more enterprise features). The balance of what is open-source vs what is enterprise is 99%-1% now and will probably shift to 80-20% over time and our goal is to make money from enterprises who care about that 20%.
Why can't there be a license which is "open-source" but stops anyone from building a "directly competiting commercial offering" out of the 80%. I guess there is complexity around how to define "directly competiting" but that should be solvable.
My understanding is that SSPL kind of does that. It is based out of GPLv3 so who are just using Rudder (or Mongo) over API are happy. And it specifically restricts commercially offering this as SaaS.
Because it is not an "open-source" license if it restricts how people can use the code. There is no "except for direct competitors" loophole.
The SSPL is a "source-available" license, not an "open-source" one.
I certainly sympathize with your outlook; everyone needs to make a living. But I could also understand people complaining if you're advertising your SSPL code as open-source, because...it isn't.
We have plenty of ways to reward innovation: patents, closed IP, commercial licensing, etc. But open source is about giving freely to the people around you, not rewards.
Selective commercial licensing is fine, and it's still nice that you let people see how things work so that they can learn and suggest improvements. But it isn't open source, and it feels deceptive when people misuse the term. Open-source code is a gift, and gifts don't come with demands.
SSPL is essentially GPL + a small restriction on certain usage (which practically only impacts the large cloud providers). To say, this is just "source available" is not entirely fair. This is different from Oracle saying you can see DB source to do your security scan but that's all.
But I get your overall point. Need to think more on how to position this so people don't feel "deceived" but at the same time appreciate the "free/open-ness" part of it. SSPL may not be the answer but there has to be a solution.
My opinion is obviously far to one side of this debate, but you said that you had users who didn't like your license. People who feel that open source is important might see extra restrictions as extra liabilities.
Hey, did you ever hear about that time when IBM's lawyers had to ask for an exemption to a license which required that the software be "used for Good, not Evil"? :)
Deviating from that isn’t illegal (they don’t own the term), but claiming your software is open source if it doesn’t meet that definition will generally earn you some blowback.
Not according to what open source currently means, no.
The reality is that the open source projects that are big today did not get big by refusing contributions from companies that were deemed to be too big or thought to be competitors. The projects got big by finding a productive way to work with those companies.
>There must be a way to differentiate between these two scenarios.
That is covered rather succinctly by the commons clause, but it's not open source and will give you similar concerns from companies. If you want to skip that and go with an actual open source license, you'll have to find a way to differentiate your service offering. Don't compete on price. The AGPL approach also does move towards the same goal and is still considered open source, but as you've seen, you have to do more work to implement it and please your downstream users.
There are generally no shortcuts here: the popular open source licenses are used because they are widely understood and don't have much in the way of legal risks. Any company including yours can just pick it up and go. When you start trying to discriminate against certain customers, that's when you stop being able to just get into any given company without going through legal. So pick your poison.
But I get your point. Need to do more work here.
> We want to compete on the flexibility aspect of open-source - the fact that you can change the code however you want as per your needs, the fact that you can deploy it however you want (and hence have complete access to your data)
This does not cover the point of Open Source. The point of Open Source is _open collaboration_. Putting a restriction on use discourages open collaboration.
Take your chosen license, for example. If I wanted to improve your code, licensed by you to me under the SSPL, I'd add my own code to it. Sure, the code I added would need to be released by me under the SSPL too, but I would still retain copyright on my code. Now, if you liked what my code did and wanted to use it, _you_ would be subject to the SSPL too. Would _you_ be willing to comply with the SSPL, for my code, especially when the SSPL cannot be legally complied with?
Now, the creators of the SSPL can get away with it because they aren't subject to it themselves, because the retain all the copyrights of all the code they release, and do not accept any code from anyone without also demanding a copyright transfer to them. This is complete ownership, not collaboration.
There's a reason open source distributions, who have no intention of competing with MongoDB Inc.'s business, stopped distributing MongoDB in their repositories. I will just leave Fedora's opinion on the matter as supporting evidence.
Licensing will govern what you can and cannot do with the repo you clone or fork. SSPL is GPL except for this additional hosting clause for service providers. So, the argument on whether it violates open_source ethos or not has to be around that clause.
This is not the case.
> Licensing will govern what you can and cannot do with the repo you clone or fork.
And this is _precisely_ where you and the open source ethos differ.
> the argument on whether it violates open_source ethos or not has to be around that clause.
The argument has been settled. Over and over again. Restrictions on use = not Open Source.
The OSI seems more focused on the OSD 9, which depend on the interpretation of Services as derived works. This a different discussion and a very large grey zone. The review request did however get withdrawn we won't get a definitive answer.
I have no particular attachment to the SSPL or it's exact terms, but if the OSI was worthy of the high position they've been granted, they would actually gather up the lawyers behind SSPL, Commons Clause, BSL, etc. and hammer out a solution that was agreeable to all parties.
Open source as a movement will live or die on whether or not either the OSI addresses this issue, or we unseat our caring for the OSI's position.
Approving discriminatory licenses is not a solution and would put even more power in the hands of those large companies. I guarantee your company would be pretty damn unhappy if Amazon, Microsoft, and Google said something you wanted was open source and then it turned out it was SSPL/Commons Clause/BSL.
>they would actually gather up the lawyers behind SSPL, Commons Clause, BSL, etc.
The OSI does not gather up lawyers. They are a charity. You submit them a license and then they review it and decide whether to endorse it or not. That's what they do. Funding a large group of lawyers to make a new license is out of scope for them. I actually agree with you that something like this should happen in the long-term, and the OSI should be involved, but they are not the ones you need to lean on to kick-start the process.
>Open source as a movement will live or die on whether or not either the OSI addresses this issue, or we unseat our caring for the OSI's position.
There is nothing to address. MongoDB didn't address any of the community's concerns and then pulled out of the license review process instead of fixing the license. Like I said, pressuring the OSI is not the way to go and these threats (?) are misdirected and totally irrelevant on HN anyway -- Official OSI discussion doesn't happen here, and trying to dilute the term "open source" for marketing reasons benefits nobody, not even when it's your company. If you have concerns about the process, you should bring it up with MongoDB. The ball apparently is in their court.
Would I mind though? An open source project I work on uses an older version of MongoDB. The question about SSPL has, of course, come up. And to our knowledge, it'd be functionally impossible for SSPL to be an issue for our project, it's users (commercial or not), and any forks that could come from our project (commercial or not). The terms of SSPL are so specific that they're harmless to anyone but AWS. Heck, even AWS could use our project with a newer version of MongoDB, and still not run afoul of SSPL!
Nonetheless, people are concerned that depending on something a non-OSI-approved license would turn people off to the project. Not for any actual term in the SSPL, just the OSI's gatekeeping. That's a failure of the OSI and the trust we've placed in them.
> The OSI does not gather up lawyers.
Sounds like the OSI isn't capable of doing the job they've been granted then. They absolutely can have a chat with people and try to find a way to make an OSI approvable license that meets business needs for open source businesses. You are stuck on the process they currently have decided is theirs, and ignoring the fact that that process is not working, and open source projects and companies are hurting because of their inaction.
Now, their position seems to be "we don't have to, because it's not our problem if open source businesses are non-viable". And that's remarkably short-sighted, and a complete travesty for the community.
Not sure why you'd call my opinion a "threat", or even "pressure", beyond me communicating my displeasure that the OSI is entrusted to a role I don't think they've achieving. This is a discussion forum, and I'm hoping I can convince you to rethink your position, or at least recognize that the OSI has some room for improvement in this area.
That's an accurate concern. The whole purpose of the SSPL is to turn certain people off the project. A fair open source community accepts contributions from everyone, including Amazon employees. If it's working correctly, you get to share in their code as much as they can share in yours. I do hear your concern and I think it's valid but banning them completely from participating is not a solution. You aren't an open source business anymore if you're singling out certain companies and giving them unfair terms.
>You are stuck on the process they currently have decided is theirs, and ignoring the fact that that process is not working, and open source projects and companies are hurting because of their inaction. [...] I'm hoping I can convince you to rethink your position, or at least recognize that the OSI has some room for improvement in this area.
You are trying to put political pressure on me to criticize the OSI for your own gain and I will not do this. Don't bother. It's not because I don't like you. (I actually really like Sandstorm!) The OSI is an extremely small non-profit with 1 employee and everything else being volunteer-driven. They don't really have the resources to care if you snub them. Participate in open source? You are part of that community, and the discussion is open to you. There is no gatekeeping here. If your needs are not being met, you need to speak up in the relevant places. No amount of of trying to "convince" me is going to make it so I can help you with this. I can't speak for you and it's pointless for us to complain about decisions that were already made and definitely won't change as a result of some HN comments. Find a more constructive way to approach this.
As for the OSI’s resources, I am sure the companies trying to do this like MongoDB would happily cover expenses if it meant resolving this.
I have no idea how you think discussing this equates to me “putting political pressure on you”.
>I am sure the companies trying to do this like MongoDB would happily cover expenses if it meant resolving this.
I said this before, but if you believe that's true then you should contact them. The last statement I saw from them, they gave up and pulled out of the license review process  and were instead seeking to conduct conversations outside the OSI.
>I have no idea how you think discussing this equates to me “putting political pressure on you”.
This is my response any time someone tries to convince me to criticize (or praise) an organization in a space where no representatives of the organization are present and none of them can hear our concerns or act on them in any meaningful way. The only meaningful action that could ever occur as a result of the conversation is that one of the participants could "switch sides". But as we know from any political discussions, it's unlikely for someone to change their views solely as a result of an off-hand conversation. If I'm reading this wrong and there is something else here other than that, please tell me. FWIW, I don't really have a "side" to be on in this matter anyway. I just try to stick to the facts.
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.
"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.
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.
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.
>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.
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.
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.
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 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.
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
SSPL may have drawbacks and there may be a better license than SSPL but someone needs to invest time and effort for that - hopefully the big OSS guys will take a lead.
Your link, YouTube, is a good example. NewPipe is a great open-source alternative to the YouTube as an app (it's a YT client), while PeerTube is an alternative to YouTube as a website (it's a video-hosting platform). Yet they're listed together.
.. with nature abhorring a vacuum and all, what you get instead is lock-in monthly fee structures and massive feudal-style companies controlling those.. while the chances to earn a living independently get slimmer and slimmer.. at least here in the USA, it is very much happening..
Software freedom -- YES; absence of citizen commerce, NO
Edit: Also, Sentry is no longer Open Source and it is still listed as Apache licensed- https://blog.sentry.io/2019/11/06/relicensing-sentry FOr an open source alternative/fork, see GlitchTip (https://glitchtip.com/)
Either way, great job! And cool idea to use GitHub issues as a request form :)
I got the idea to use Github Issues from this repo:
They use Github issues for comments so I thought I’d give it a shot as a request form.
The one I was thinking of, but the other two I've only maybe heard of one.
And I say that as someone who dismissed it as complete trash when it still was owncloud, a few years back.
It’s really gotten noticeably better, and (for me at least) syncs much faster than Dropbox ever did.
I’m populating new clients at 500mbps (which is my line cap). I really can’t complain.
When learning a new language, you're almost always better off picking a simple problem so you can focus on the ergonomics of the language. Trying to learn a problem domain and a programming language at the same time is really hard, and is a common reason why startups picking niche programming languages run into trouble