A few of these are, unfortunately, not Open Source, on account of being licensed under the SSPL or Commons Clause. In the latter's case, in particular, the very prescient complaint against the original "marketing" holds true: that people mistake it for Apache 2.
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.
I don't understand your logic. You're complaining that your customers don't like AGPL, so instead you're using the SSPL? The license that was rejected because it was seen as being an even more restrictive version of the AGPL? What does it matter anyway since your goal is to get people off the open source version and paying for the enterprise version?
> 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.
Thanks for the feedback around participating - makes total sense.
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.
>Why can't there be a license which is "open-source" but stops anyone from building a "directly competiting commercial offering"
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.
I am not hiding that we are SSPL (I am trying to defend it here :)) But to understand your concern, you are saying someone owns the (copyright or whatever legal structure is) term "open-source" and us using is a violation of that.
It's not so much a legal thing as an ideological one. "Open-source" is a manifestation of the idea that knowledge should be free. It's based on the belief that societies grow when people are not restricted in how they build upon our collective accomplishments.
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.
Gift without demand is an interesting analogy. But if you think about it, licenses like GPLv3 and AGPL do have very strong restrictions on how to use the software. Fair enough that they are not to "reward back to you" but around "how to use the gift".
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.
Yes, but I also dislike copyleft for the same reasons. Personally, I draw a distinction between "open-source" software and the more restrictive and viral "Free Software" which Stallman argued for, but that's been argued ad nauseum.
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"? :)
The term predates its use in software, but as used in the software industry it typically refers to the Open Source Definition: https://opensource.org/osd
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.
SSPL is a copyleft license, and it's definitely open source. It doesn't prohibit competitive commercial offerings. It just requires them to share their source, just like a GPL.
What you're describing is essentially the commons clause and it's not considered open source because it discriminates against commercial activity. The point of open source is to give everyone a shared technology base to work from, including both you and your competitors. If they're contributing then you can take their code and use it to improve your product too. You can also use your open source offering to upsell them on those additional services. This is how it's always worked. I try to illustrate this with an example: can you imagine how inconvenient it would be for your product if all those open source libraries [0] you depended on had such a condition?
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.
Fair enough but I would still try to draw a line with "direct competition". I am not directly competing with any of these libraries. In the same vein, if some eCommerce company uses RudderStack and builds their Analytics stack around it, I would be super happy. I just don't want someone else to take this code and offer Rudder as a service. There must be a way to differentiate between these two scenarios.
You wouldn't know if you were competing against the parent companies of those libraries unless you checked and did the legal legwork.
>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.
Competing on price is actually hard because people who are price sensitive will go with the open-source version. 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)
Your arguments in this thread seem to be coming from a single point of disagreement: the point and definition of "Open Source".
> 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_[1]. 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[2]?
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[3].
The copyright argument on code contribution is orthogonal to the license. You are free to fork the repo and make whatever modifications on top and own the copyright on the addition but if you want to contribute code back, pretty much all popular open-source projects would want them to assign copyright back to them.
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.
Then perhaps multilicense, using both SSPL and AGPL (so that users can use whichever license they need, or can keep both if they want to)? That would seem to fit your requirements as far as I can understand them.
The SSPL seems like the ideal solution, and very in the spirit of copyleft. I find it unfortunate that the OSI is treated as the only determiner of “what open source is” and that they have failed to accept SSPL.
Trying to pressure the OSI into accepting a license is not the way to go. There are valid reasons that they rejected it. This isn't exactly some cabal of lawyers trying to make you miserable, the SSPL was also independently banned by Debian and Fedora for not meeting their own guidelines on open source licenses. The review process for all of these organizations was lengthy and public and still available if you want to find it.
From reading that review process, the main reason Debian banned it seems to be that in their view you can not use Debian together with SSPL licensed software and be compliant with the conditions of SSPL. The guideline (DFSG) does not specify what to do in this situation, which is acknowledged in the discussion, so the reason for banning the license comes down the fact that inclusion would not benefit the goal of the project.
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.
To me that illustrates the point further which is that it's not just about some random definition of the term "open source", there were very real practical concerns that prevented its adoption and were not addressed.
I've read much of the review processes, and the OSI's position as I understand it, is pretty shameful. They seem happy to just decide they don't need to solve this problem. They seem perfectly happy to let open source businesses die while they hold a position solely beneficial to Amazon, Microsoft, and Google.
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.
>They seem perfectly happy to let open source businesses die while they hold a position solely beneficial to Amazon, Microsoft, and Google.
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.
>Nonetheless, people are concerned that depending on something a non-OSI-approved license would turn people off to the project.
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.
Nothing about SSPL bans them from contributing. But like the GPL, it requires contributing back. The idea that GPL is open source and SSPL is not seems logically incompatible.
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”.
The SSPL is very clearly out of compliance with section 9 of the OSD which states "The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software." This condition is there because such requirements make it very difficult for companies with a lot of other infrastructure to to adopt the software. This isn't exactly a new thing either, it was known to be a problem decades ago when the OSD was written. I don't even know why this is disputed, the admitted goal of the SSPL is to make it difficult for Amazon to adopt the software.
>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 [0] 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.
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
I agree but looking at the downvotes to my response, doesn't seem like the HN community agrees.
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.
The one issue I have with AlternativeTo is it sometimes conflates a website and an app.
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.
The key difference is that "AlternativeTo" has voting from users, whereas "Opensource.builders" has voting (stars) from developers... not sure which is better, probably a combination of both
as an American struggling with some business attitudes here (versus EU mainly) .. I find a "rush to FOSS" to be troublesome.. There is an unfortunate overlap of "Free-as-in-Beer" and "Free-as-in-Freedom" which is not just disappearing! If you want to make enemies quickly, you can reinforce that notion that "software is free (beer)" towards Newspapers, freelance tech writers, independent medical professionals, clerks or any other of dozens of business types that are failing and going out of business in the Internet age.
.. 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
I would add Zulip to the Slack alternatives, and Mattermost is AGPL, not MIT licensed. And as others have pointed out, there are several non-open source projects listed that shouldn't be.
Nice UI - I noticed that there are a lot of web apps, but not as many 'offline' projects. D'you see this as a mostly web-based platform, or could you also see entries for programs like Photoshop and commercial IDEs?
Either way, great job! And cool idea to use GitHub issues as a request form :)
Sure, some open-source can be commercial and run their own hosted versions like Gitlab and Sentry. They can be self-hosted by anyone on their own servers too.
I'd find a place interesting that would list the opposite. Commercial or more obscure solutions that don't currently have any open source equivalent because when I'm looking for projects to learn a new language or I'm just bored that'd be a great starting place.
Those are almost assuredly awful projects when you are interested in learning a new language. Obscure software likely is laden with domain-specific knowledge that you don't have (otherwise you'd likely know about the commercial software). Known commercial applications with no open source equivalent are likely that way because it is difficult to build a replacement.
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
