Whoa, very biased article (especially for LWN). Only cites media coverage; no links supporting that Amazon, MSFT, Google, etc. were in fact EEE’ing (or at best, behaving unethically) with each of these projects.
It even suggests cloud providers did contribute, and uses bad data (git commits “by employer” w/o dataset) that basically contradicts their argument.
I may be biased, as I saw Amazon doing exactly what this article claims “maybe they weren’t”. But statements like this seem intentionally misleading, and easily disproven:
“Distributing a source-available version of MongoDB could be seen as a loss-leader strategy to reach developers that the company wagered did not care about open-source.”
MongoDB is still “source-available”, and on the same GitHub repo I’ve used since 2010. The SSPL only impacts cloud-providers, and has exceptions for cloud providers who release their source code.
The OSI doesn’t get to define open-source. Neither do I, but at least I was part of the community for ~20 years…
It impacts all people who manages mongodb for somebody else, which is a lot of hosting providers (many of which probably do not care about the licence and are too small to get caught)
I think “including, without limitation, […]” applies to the breadth of components, not depth, right? I mean, I’m not a lawyer, but that seems to be what syntactic context and logic indicate… no?
If you disagree, could you indicate the relevant text?
Er, I could be wrong, but I think you’re missing the scope set in the first sentence:
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the… SNIP …programs that you use to make the Program or modified version available as a service…
I’m eliding for clarity, but the NAS doesn’t make the program available as a service. The code that accesses the file system on the NAS to offer your service? Probably need to release code that calls fread/fwrite/NtFileX in your infrastructure code.
I get that it sounds vague and everything, but the FAQ also clarifies none of this applies unless you’re competing and targeting third parties. If you’re one of the few companies who want to do that, your legal team can formalize the line of demarcation.
Apologies, I hate defending the SSPL, but I can’t think of any better way to stop the monopolistic and EEE practices against open source projects. If anyone has a better solution to protect the freedoms of open-source developers, please, please publish it!
No, full list is in the license, but it’s only those components that they provide MongoDB as a service to end users. Doesn’t penetrate OS abstractions AFAICT, but I’d check the license and/or consult an expert if starting a relevant business!
FWIW, just realized it doesn’t even apply if deployed internally (within an organization and/or subsidiaries)…
Er, why can’t you run a MongoDB replica set on your M1?
I mean, I wouldn’t recommend running a ReplicaSet on the same host on any production host (it defeats the purpose), but for testing, I’ve run a sharded cluster w/ 3 replicas per shard…
No, the term “open source” was in use before long before the OSI, and it was in popular/hacker culture in the 1980s. UNIVAC used it in for a major system in the 1950s. [1] I used it in 1993 (I wrote a small BBS).
The OSI looks and sounds like an authority on open source software, but their entire strategy is legal, political and quasi-philosophical. I get how easy it is to be mislead by them though — they’re good at spinning things and rewriting history.
There are 3 "competing" Open Source and Free Software definitions - from OSI, Free Software Foundation and Debian. MongoDB does not match any of them and most importantly does not match the spirit of Open Source Software Movement.
I could name more, but let me clarify something. I’m not a fan of the SSPL, but I get why it was necessary.
It was rough seeing huge cloud providers profit off open source projects without giving anything back. When they offered competing hosting services with no value added (well, past “integrated billing”), no contributions or innovation, and drove their new customers to the documentation and libraries of the companies backing these projects, they crossed a huge line.
And it’s not just MongoDB. Or Elastic. Just look at all the “services” AWS offers, and note how many AWS actually invented or even contributed to…
Monopolistic practices forced a lot of companies to either shut down, or find a way to survive. I’m glad MongoDB decided to use the SSPL instead of shut down like so many others. I’m glad they’ve continued to thrive.
Changing to the SSPL isn’t ideal, but it only impacts people who want to sell hosted versions of the software (not users, self-hosted or otherwise). For those infinitesimal few selling hosted versions of the software, it doesn’t even stop them from doing what they want — it just stopped the monopolies from destroying something a lot of people dedicated a lot of effort to... That seems like a pretty amazing feat to me, given the reality...
I wish the OSI wasn’t so successful painting users of the SSPL as somehow betraying the open source community. And I wish the SSPL wasn’t necessary. But until there a better option, I’m ok with the SSPL…
Again, I say this with all due respect, and this is just my opinion. Corrections and new perspectives welcome!
Well, In my opinion this is exactly how Open Source is suppose to work - you get benefit of collaboration on writing the code and promoting your software by broad community, you give more value to your customers because they have a choice of vendors rather than single vendor lockin but also as you give up on having monopoly it is well possible someone else will be making more money than you on your product.
You mention Elastic - do not forget it was built on top of Lucene, capturing most of the value in that project.
It DOES very much impact users because users increasingly want DBaaS experience and if the only one you can get is through MongoDB or MongoDB authorized partnershp it is really no different than proprietary software.
In any case I agree for certain users SSPL is just a good as Open Source, same however can be said about Proprietary Software - some who just "buy subscription" do not care.
Please state in what way they don’t? This is what I’m confused about. Apgl is open source but a sspl isn’t? They seem to be aimed at solving the same thing, which is cloud/server based code modifications.
SSPL goes way beyond AGPL as it contains an additional clause called "Offering the Program as a Service". It is not defined at all what constitutes providing MongoDB as a service. How many layers are needed to abstract MongoDB in a way that it doesn't trigger this clause? There are no answers for that in the SSPL. It comes with an enormous amount of risk compared to AGPL. There is a good article from Dor Laor at ScyllaDB which explains this in detail [1].
Moreover, cloud providers are not limited to AWS, Azure and GCP. Smaller providers whom we talked to are not able to negotiate licensing terms with MongoDB the same way as how AWS could. For this reason, these providers are not able to provide MongoDB as a service. Yes, it's great for MongoDB that they were stopped from providing MongoDB for free, but now they can't provide the service at all. This limits competition and choices, and that is never in the favor of users.
AGPL is basically the same thing, except far more reaching. AGPL, to my understanding, makes it a requirement if you allow people to use the software via network levels. “Program as a Service” seems a lot more limited in scope.
All new licenses come with risk since the decisions can only be made via court decisions.
> AGPL, to my understanding, makes it a requirement if you allow people to use the software via network levels.
AGPL requirements do not trigger if you don't modify the source code. The relevant text is in section 13:
> […] if you modify the Program, your modified version must prominently offer all users […]
See also [1], [2], [3].
> “Program as a Service” seems a lot more limited in scope.
AGPL scope:
> The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work.
Basically, the software itself and build scripts.
SSPL scope:
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
As noted in another thread, that's not only beyond the scope of the software itself – it is beyond the scope you _can_ relicense and arguably beyond the scope of the copyright terms themselves.
> As noted in another thread, that's not only beyond the scope of the software itself – it is beyond the scope you _can_ relicense and arguably beyond the scope of the copyright terms themselves.
This is not true. People who are saying this would have said this about GPL when it first came out.
Because the nature of software development and usage has changed massively since GPL was created. If GPL was created today it would most likely be like SSPL. The fact, GPL states "derivative work" must be released under a similar license shows to me that their intent was if you build anything where this is the core you must share that.
Well, AGPL did no allow to create Monopoly in practice - Compose.io, ObjectRocket and others could offer alternatives to MongoDB Atlas without any permission.
This was benefit for users but obviously not something classical corporaton would enjoy
It was a benefit for classical corporations not users. These companies can still create alternatives. It’s just they’re forced to share how they did it. It’s that forcing of sharing which is at the heart of GPL.
MongoDB’s source code is still freely available. It’s still actively developed in the open on GitHub. Unless you’re offering MongoDB as a service, it’s just as “open source” as ever.
If you want to offer MongoDB as a service, you can still do so free of charge, as long as the service infrastructure is also made openly available, right? And if you don’t want to make the source available, you can purchase a license and do so, right?
Furthermore, if you’re using MongoDB, be it self-hosted, with a vendor, or even some proprietary database that implements the wire protocol for compatibility, you’re likely using MongoDB-developed clients/drivers, which are Apache 2.0 (“OSI-approved open source”).
So it seems like the only way to be locked into a vendor is if you’re using MongoDB drivers to connect with a 3rd party database that doesn’t fully implement all functionality of MongoDB in a compatible way… Right?
I could be wrong, but as someone who contributed to MongoDB as an open source project, and was later hired by MongoDB based on said contributions, it kinda hurts to see the OSI’s “MongoDB isn’t open source anymore” campaign work so well.
That said, I sincerely wish the team behind this project all the best!
My complaints aren’t against anyone in the open source communities I’ve known and loved. Just this self-important legal organization that acts like it controls (and even gets to define) open source software.
P.S. I left MongoDB in 2015 due to a neurological disability, but it was one of the highlights of my career, with so many kind and brilliant people. But it’s also been a while, and my brain doesn’t work so well these days, so please correct me if I got anything wrong!
> If you want to offer MongoDB as a service, you can still do so free of charge, as long as the service infrastructure is also made openly available, right?
The license text is worded as such that it is basically impossible to comply with.
> OSI’s “MongoDB isn’t open source anymore” campaign work so well.
It is hardly OSIs campaign. Pretty much all major organizations involved in FOSS licensing have rejected sspl. For example this is Fedoras stance:
> Fedora considers the Server Side Public License (v1) to be a Non-Free license. It is the belief of Fedora that the SSPL is intentionally crafted to be aggressively discriminatory towards a specific class of users. Additionally, it seems clear that the intent of the license author is to cause Fear, Uncertainty, and Doubt towards commercial users of software under that license. To consider the SSPL to be "Free" or "Open Source" causes that shadow to be cast across all other licenses in the FOSS ecosystem, even though none of them carry that risk.
> "Unless you’re offering MongoDB as a service, it’s just as “open source” as ever."
It's not. It's source available, and that's still proprietary.
The reason why the SSPL is not Open Source is pretty simple: it doesn't convey the four essential freedoms of free software [1]. That's it, there is essentially no more to it: it imposes usage restrictions, and that's orthogonality against the spirit.
Whether it is "except this or that" or "AGPLv3 but with this additional clause" is irrelevant: even the tiniest change can cause significant differences, and this is the case: it removes the freedom to run the program as you want, as it imposes restrictions to some use cases. And these restrictions go beyond the realm of the software itself.
In contrast, Open Source copyleft software, like AGPLv3, never go beyond the software itself. It provides guarantees that modified versions of it also remain available for users of modified software (forward carrying guarantees) but do not add a requirement to also provide under the same license other unrelated software (which is essentially a nice way of saying "simply don't do this", turning de facto into a usage restriction).
"You can do so as soon as you open source infrastructure" is impractical and misleading. It is very likely part of infrastructure will be commercially licensed so even if one would want to open source it, it would not be possible.
MongoDB Specifically switches from Open Source License to SSPL to create monopoly in DBaaS Space. IT is business decision so lets not pretend here.
If you look at Real Open Source software it is created for cooperation and innovation together, not monopoly.
Er, if you develop the infrastructure to host MongoDB, you should absolutely be able to open-source that infrastructure. I mean, before MongoDB, I wrote a cluster management system for virtualized software security and hypervisor research, and all of it was either open source or something I wrote…
Also, if you bought something closed-source to sell MongoDB as a service, why isn’t it realistic to buy a license?
Your suggestion of a monopoly in the DBaaS space seems to preclude the existence of other databases… Or am I misunderstanding?
I’m not sure what you mean by “IT is a business decision” — could you elaborate?
-edit-
P.S. I’m trying to be supportive here; not trying to take anything away from what you’ve built with FerretDB! Honestly, there’s room for so room for innovation in this domain, and it’s nice to see new projects…
The cloud provider wouldn’t have to, if you are the one running your infra. The SSPL restrictions only apply to businesses that offer MongoDB as a service.
In fact, you can build a similar service and offer it within your organization (and subsidiaries), and you still don’t have to release anything. The license only applies to companies like Amazon if they offer MongoDB as their own service (DocumentDB).
I know that’s a bit tangential, but hope that helps a bit?
My perspective as an openly gay male with 20+ years of experience in software security, systems programming and distributed databases: Tech companies tend to be extremely supportive and welcoming of talent from diverse backgrounds. My proudest technical accomplishments have always been with a diverse group of peers, including straight white males who champion diversity. These people are heroes to me, but it’s not like they’re the type to gloat…
I’m not the best person to ask about movies, but most example of protagonist “hackers” that comes to mind include white males. Counter examples that come to mind are “The Web” (female), and Sens8 (transgender lead, helped by straight white male)…
That said, I may have misunderstood your point, but happy to correct it elaborate if I’m off base!
Yes, you're way off base :D But it's a welcome miss, because I found your experience interesting anyway, and relevant.
My first point was that if it were true that "technical and social leadership" indeed was compatible and even "well-aligned", then why is it we don't see that in people in leadership positions? Where are they?
Then I pre-empted the tired argument that we don't see them because they've been oppressed for so long. I suggested that culture has been so "progressive" in recent years, that there are no longer any positive male role models (the over-compensating pendulum swing, in place of actual progress), so now that that's done, let's see what effect it has had on future society in 20 years, because we won't be able to blame "the patriarchy" or whatever any more.
Now having said all that, I'm super happy to hear that you've had a positive experience in diverse workplaces :) I'm old, and remember when being openly gay wasn't fun.
Ah, interesting… I think the discrepancy is where we’re looking. FWIW, I started my career at AOL-Time Warner in Florida in the late ‘90s. Management was all “good ol’ boys”. Definitely no role models anywhere. (I was closeted at the time).
I’ve been fortunate in some ways, but nothing came easy to me. I didn’t come from money, didn’t graduate college, didn’t know anyone… I moved to LA just to escape that toxic environment, and found a good job developing embedded systems in 2 weeks. I’m an autodidact, so my only qualifications were a portfolio of projects, including an old TI DSP project and a pre-Wi-Fi embedded wireless device. Over the next ~15 years, I kept moving up in rank and salary, changed jobs a few times, received patents, contributed to papers, and was lucky enough to be mentored by some truly amazing people…
I’ve always felt success is a combination of hard work and luck, even for those “born into it”. If true, that likely means for everyone like me, there are a dozen or so who didn’t make it, or never took a chance.
And yeah, being gay still isn’t fun. Maybe it made it easier to take a chance moving 2600 miles from home though — I figured I’d be dead within a year if I stayed where I was…
Hope that doesn’t sound like some kind of humble brag; I’ve obviously had my share of failures and loss.. That said, given how lucky I feel at this point (I’m in my 40s), I couldn’t understand how you’ve never met a positive role model… But I do now, and it was naive of me to extrapolate my experience into the general population… And I’m not suggesting I worked harder or did anything to deserve my good fortune… FWIW, I’m really sorry you (and likely most people) haven’t known the same men and women I’ve been lucky enough to know…
Really hope that doesn’t sound like some arrogant humblebrag, or diminish your hard work!
> I’ve always felt success is a combination of hard work and luck, even for those “born into it”.
Defo, but I'd tweak that a little and say they come hand in hand. The luck comes from hard work, or at least just going for it, it doesn't just magically land in your lap.
I have a similar background; grew up poor in a rough area, low expectations from my teachers due to my ethnicity, and thanks to my parents, worked through all that to become what most would call successful. The breaks came from opportunities, which came from putting myself out there.
It's a mistake to think people are lucky, because it implies things just happen to you. Nobody has it easy. Even those who are apparently patently lucky in that they have rich parents, are not lucky. The only thing worse than not having anything, is having everything.
IMHO, this just seems to be another polarizing piece of clickbait, rehashing the pointless “RMS vs. ESR” diatribes.
The author frequently posts in support of the OSI (applied for a seat, endorses their “we get to define open source” nonsense, etc.). A March 2022 post rants against Elastic and others because of a non-OSI “open source” license change, while glossing over Amazon’s and the OSI’s roles leading to that change. It also makes a strange argument about bias, which almost comically contradicts itself at the end.
IMHO, the OSI, FSF, RMS and ESR have all done more harm than good to the open source community. I’m not saying they’re all equal, or even always bad, but I’m not a fan of bringing one-sided political or philosophical arguments into the hobby and career I’ve truly enjoyed for over 20 years. And no, my contributions don’t somehow mean I get to define what “open source” means for everyone.
Projects that change from Apache or GPL-like licenses to SSPL are still open source. This doesn’t mean you have to release your source code if you use these projects — only if you start selling a hosted platform that offers the software as a service. Every company I’ve seen do this was been backed into a corner by Amazon, who almost never contributes to these projects. This is nothing more than Amazon trying to kill these projects by causing fragmentation.
*Yes, I’ve read the OSI link AWS-fans always refer to.
Have you read SSPL? It's literally apply restriction to SaaS that impossible to comply with.
Also it's not some "everyone, but Amazon license". Terms they use are very fuzzy and can easily apply to more than just SaaS companies.
If Elastic wanted to stay open source they would use BSL: proprietary for N years and then code became GPL / APLv2.
Anti-SaaS clause of SSPL is here:
> The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
> The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
It even suggests cloud providers did contribute, and uses bad data (git commits “by employer” w/o dataset) that basically contradicts their argument.
I may be biased, as I saw Amazon doing exactly what this article claims “maybe they weren’t”. But statements like this seem intentionally misleading, and easily disproven:
“Distributing a source-available version of MongoDB could be seen as a loss-leader strategy to reach developers that the company wagered did not care about open-source.”
MongoDB is still “source-available”, and on the same GitHub repo I’ve used since 2010. The SSPL only impacts cloud-providers, and has exceptions for cloud providers who release their source code.
The OSI doesn’t get to define open-source. Neither do I, but at least I was part of the community for ~20 years…