Do I understand it right, that whatever a project I build using MongoDB (i.e. any website/app that uses a MongoDB instance as a backend to store data directly or via a middleware layer or has a feature of connecting to MongoDB) I must open-source it completely? This feels a way too radical if so.
I believe that is what prompted the Server Side Public License (SSPL) creation, but as written could be interpreted to cover more than just offering MongoDB as a service.
From the SSPL:
13. Offering the Program as a Service.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version
“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.
Herein lies the problem. Notice you said "I believe that... but could be interpreted".
I've worked with some copyright lawyers that basically said "it's impossible to know, and we'd rather just avoid the question to begin with", and forbade us from using AGPL in any of our deployments.
So the key takeway is that you not only have to opensource your serverside component, but also have to allow self hosting? I haven't had my morning coffee yet so I may be wrong here, but that seems extreme.
> The only substantive change is an explicit condition that any organization attempting to exploit MongoDB as a service must open source the software that it uses to offer such service
If you're building for example an ecommerce that uses MongoDB as database, you're not selling MongoDB as a service, so you don't need to license your software with this new SSPL.
If you're building an ecommerce as a service with a MongoDB database, again you're not selling MongoDB as a service, so you're safe again.
I would like to make it explicit that only flesh and blood individuals should have access to freedom 0. These licenses are a step in a direction closer to what I would like to see, but aren't quite there yet.
If you as a person want to run software xyz and try to make money off of it, go ahead. As soon as you open a limited company to reduce your exposure you should be hit with paying license fees.
I don't get the hate for the licenses that try to remove freedom 0 for corporations. At work I suggest horrible propitiatory software solutions all the time because it doesn't matter how locked down the stack is.
So long as it has a ROI of >3% over the fixed and running costs it's a good solution.
No one is harmed by human first open source software, other than a legal fictions bottom line.
> I would like to make it explicit that only flesh and blood individuals should have access to freedom 0.
So basically, turn freedom 0 into not freedom 0.
For reference, GNU freedom 0 is “the freedom to run the program as you wish, for any purpose”.
What you are saying seems to go against the principles of freedom 0, and I don’t get your motivation either, because at the same time you don’t seem to mind proprietary software.
My main issue with what you are saying is that it’s not clear what you mean by “removing freedom 0 for corporations”. Do you mean specifically when they are offering software written by someone else as a direct service to customers? What about using it in the backend? What about employees using FOSS?
There is a lot more to be said and discussed about this.
>For reference, GNU freedom 0 is “the freedom to run the program as you wish, for any purpose”.
That depends on what your definition of "you" and "you wish" is.
If your boss tells you to run X then you are not the one wanting to run it, the company is. And, American jurisprudence not notwithstanding, I don't consider corporations to be a form of "you".
If a sole proprietor with full legal liability for their actions wanted to do the same, more power to them. No matter how many people they hire to do the work for them.
This would mean that corporations will have no incentive to use or contribute to free software -- 80% of contributions to the Linux kernel are people working for corporations.
I also don't see why limitation of liability is the point where right to use free software should be curtailed -- there already is no liability in software (see the no warranty clause in literally every software license). Why not put the line at making a profit at all? (Because it's obvious that disallowing users to make any money at all with a free software license would clearly be an issue.)
It is sort of similar but includes worker-owned coops. So basically either an individual person or a worker-ownder coop can use a Copyfarleft work for profit.
No, I want a non-commercial license for non-human entities.
I don't care if someone is using my software in their family bakery. If anything I'd be super happy about that.
What I do mind is someone using my software in their multinational baking conglomerate without me ever seeing a cent for the work, while at the same time keeping other developers from ever being paid for developing the software in house.
> keeping other developers from ever being paid for developing the software in house
Sorry if miss-logicing in these quotes. Please do correct if you thing they're taken out-of-place.
A bakery is commercial. They software they use is baked into the oven and POS. 'family bakery' - do you mind a family member in the store, do you mind them logging it with your name? Do you mind them using a camera to recognise when you come in? Do you mind a staff member recognising you when you come in? Is tallying today's weather vs sandwiches sales OK? Credit card promotion? Different level of Personally Identifiable Identification.
> What I do mind is someone using my software in their multinational baking conglomerate without me ever seeing a cent for the work
Why not? What's the license? Assume in Github. Ask for comments. The people in these companies are hackers too and not cold-blooded fuck-the-customer. If you're got good code for baking, contribute.
The reason we use open source is for the freedom of it, we can use a library of a permissive license, redistribute and reuse the code elsewhere in the organization without worry. Without contacting the vendor.
We’re not shooting future us in the foot.
It’s far more about function and redistribution than ROI. It’s about peace of mind. It’s about not having to worry about a vendor revoking a license down the road.
I think you are entirely missing the point and values of “Free Software” vs open source.
The change in licence terms sounds too stringent — far beyond just the scope of derived works which is typically the case. Especially “requiring a relicensing of the Linux kernel if a MongoDB service runs on Linux”?
MongoDB can very well stop calling itself an open source software then when to use it in any significant manner, one needs to get into a proprietary license agreement. Wish the license doesn’t get approved as a valid open-source license.
I wasn't aware Mongo had the kind of market-share that would allow them to pull this off. While some people might pay, it's just going to remove trust. Who's going to recommend Mongo after this? Good chance it won't even be considered Free Software anymore.
The AGPL is a great license for free software development. It is also great to be coupled with a proprietary license, something that does no often make sense with other licenses.
I have found AGPLv3 useful, everything I do is under AGPLv3, if people want to use it under other terms, they can pay me for a branch under a mutually acceptable license. I will not maintain the alternatively licensed branch unless paid, and these branches after a few months are generally missing significant features.
Its a fine revenue stream for me, and in the context of what I am building and the companies that are using it, there is absolutely no reason to not use the AGPLv3 licensed master branch or releases, as I know they will never extend my software. Yet some people have an axe to grind with AGPLv3, to which I get to respond "Pay me money or fuck off". Seeing as none of them understand how to write software, they tend to pay me :P
Worst case someone extends one of my AGPLv3 projects, adding features and improving it. I'll accept a pull request with no CLA so long as the code is of decent quality.
I'll accept a pull request with no CLA so long as the code is of decent quality.
If you accept contributions without a CLA, you are not the sole owner of the copyrights anymore and you cannot offer a proprietary paid branch, unless all contributors give you permission to relicense their AGPL code as proprietary.
Yep, and I'm perfectly fine with this. If someone wants a non-copyleft branch, they can pay me to rewrite the features I didn't author, otherwise I will exclude the added code from said pull request.
Its a definite edge case, but if I can get active contributors, I am not about to ask them to sign a CLA.
Keeping track of and excluding commits authored by others seems a lot of work. I am curious if you use any kind of tooling or process to make it easier.
MongoDB was AGPL, but according to MongoDB, Inc. that didn't stop cloud providers to sell it as service, without also publishing their management tools and everything else used to provision MongoDB under a license AGPL accepts. Hence MongoDB, Inc. came up with their license additions.
IANAL, but depending on who you ask, AGPL is deemed unenforcable or even misusing copyright legislation. In any case, AGPL hasn't, to the best of my knowledge, been tested before a (US or EU) court. If it had, I'd expect an excessive discussion as to which scope AGPL can have, and a fundamental legal discussion of whether copyright laws can even limit use of third-party software.
Anyway, AGPL doesn't directly address commercial licensing; it rather extends GPL's "distribution" to the case of "provisioning over a network", with the understanding that a commercial license also offered from the publishers doesn't require you to publish your source code to your end users. As it stands, AGPL might not be a good tool to express/enforce "free for personal use". It also depends on whether you actually want to win contributors, or merely have a licensing badge for your project. The AGPL itself basically implies that you want contributions (code) from your commercial users, rather than money.
The key difference is I do not care if companies use AGPLv3 software I have written. MongoDB predicated their business model on getting companies to license their code rather than use the AGPLv3 version of the codebase.
> IANAL, but depending on who you ask, AGPL is deemed unenforcable or even misusing copyright legislation.
No clue wrt AGPL (an old, crusty license), but GPLv3 was written with heavy involvement of the Software Freedom Law Center. The Affero paragraph (which is the only difference between AGPLv3 and GPLv3) was written by this same team at the same time.
As a non-lawyer, I would presume the lawyers that were tasked with reviewing the various forms of the third revision of GPL licenses did their job.
> Worst case someone extends one of my AGPLv3 projects, adding features and improving it. I'll accept a pull request with no CLA so long as the code is of decent quality.
Notice that it is perfectly fine to be "open source" without being "open development". Many free software projects do not actually accept pull requests as a matter of principle.
I've run into projects run like this, but I would love to get some driveby pull requests. Sadly the segment I work in has very few software developers, but lots of people who are (needlessly) scared of the licensing bogeyman.
1. Has a rational interest in maximizing their returns
2. Owns all the rights to their products (barring existing IP restrictions)
And if they choose to open source their code:
3. it is of their own prerogative
4. without any obligation to do so.
Given 1, and 2, if they open source their code, they're an awesome person because they're revealing some portion of their secret business logic to the public. With that, they are entitled to whatever conditions they put on their code. That includes CLA's regardless of how much potential contributors will protest.
It doesn't matter how "against the spirit of open source" a CLA, or an overly radical copy-left license is. The creator of the product will always have an obligation to their own interests first, and since they're already sacrificing trade secrets by revealing their software source (something they were never obligated to), they can honestly do whatever they'd like.
And this includes ensuring that everyone using their software open-sources all forks of their software. Heck, even open-sources everything they use in support of their software.
Let's face it, if their software just weren't that good, no one would use it.
If the outside world wants more open source code, I don't see why they'd giving MongoDB any flak for this. All this license will do is result in more open-source code. After all, isn't that the point all along?
Or are zealous demands for open-source code only valid while it's all about a single popular product by a big company (MongoDB), and not when smaller software components by smaller companies (billing, hosting scripts by SaaS providers)?
Edited for grammar and other things my brain missed
The reaction you speak of is called “bitter zeal” in classical spiritual direction. One gets upset because someone else does good but “not as I understand it or not within my group.”
I don't think that will happen. I think they will just sell more commercial licenses, which seems to be the entire (valid imo) point of this license change.
I agree that they might have a legal right to do this, but it doesn't mean this is aligned with the interests of the general free software / open source community and thus it is entirely their right to shun, criticise and disapprove of this move and this licence. Particularly so because they are (arguably) violating an implicit social contract it had with its contributors in the past.
This might be a good thing in the end because it exposes a new downside to CLAs and might make people think twice before signing them in the future.
> If the outside world wants more open source code, I don't see why they'd giving MongoDB any flak for this. All this license will do is result in more open-source code. After all, isn't that the point all along?
It would be a good thing if we could reasonably expect the effect to be that companies might release more open source code as a result. Yet the licence is so vague and broad that the much more likely intention (and effect) is that other companies will be forced to buy the proprietary licence to avoid the impracticability of using code under SSPL. I also don't think this kind of overreach in what is required to be open sourced just because you're using a component X is acceptable.
That's kind of the point though. BSD is truly free, and that means there are a lot of proprietary products which benefit massively from it and create worthwhile products with clear monetization strategies and thrive. Sure, they might not contribute back, but the point of the open source was often to share code to improve the state of the art and provide useful code for people so they don't have to start from scratch. Apple took BSD licensed code to make macOS, and it helped them, they contribute some OS code to Darwin, but there are probably lots of happy mac users who benefit immensely from that BSD code. There are lots of people who do BSD code and improve it, just as there are GPL people. Popularity is not always [i.e. almost never] a measure of correctness, principle, or goodness. I like BSD, because any code I release, I hope it helps someone somewhere to do something useful for the world [even when proprietary], and if it does, then great.
Apple isn't the best example. They generally do publish the modified source code to FOSS projects they do, and sometimes they don't add their own license clause, so the changes can get merged back.
It is a good example, because that’s exactly how the BSD license works - it doesn’t force you to give your changes back, but there are other incentives to do so, such as not having to maintain your diffs forever.
"Truly free" is in the eye of the beholder: is a country with laws against slavery more or less free than one without them?
I release my code as open-source because I don't want my end users to ever end up unable to fix bugs in the code they're using. I don't want my code used in something like macOS where users are stuck using what they're given; it might help those users in the short term, but I believe it leaves them worse off in the long term.
Yes, this is the sense of "truly free" that leads to people in the U.S. being able to marry children, not having healthcare taken care of etc. That's a true 'freedom' to go bankrupt, but am not sure that's a 'freedom' many actually want.
I think most of the commenters on my post misunderstood me very much. I think people should be free to license under GPL, AGPL, SSPL, VXMPL, or whatever the heck they want. I like BSD personally, and it meets my requirements, but someone who has a different need can do what they want. I think GPL has worked well for Linux, and I'm glad they did it the way they did; I think it is less free than BSD, but in a good way for their project and purposes. I think having both a GPL licensed OS and a BSD licensed OS is great. We have diversity of licenses for different purposes and different ideologies, and it enriches the market in a lot of ways. I think forcing everyone to use the same copyleft licenses for everything based on a radical ideology is a dangerous and useless endeavour; and that sort of ideology is completely _not_ free in every sense of the word. Do what you want, set your rules for your project as you wish, we are all better for it.
I don't think you were misunderstood. But, I think the way you think of freedom is that one has an absolute freedom do do whatever, including infringing on other freedoms whereas others disagree.
By analogy; if one is free to rob someone, they're more free in absolute terms than they're free if they can't do that, but then the person who is about to get robbed isn't free to feel secure. So in other words, the robber is more free, but at the expense of the robbed.
In that sense, the BSD license is more absolutely/selfishly free for the individual, whereas the GPL is more freedom-perusing for the entire community.
> the point of the open source was often to share code to improve the state of the art and provide useful code for people so they don't have to start from scratch
Was that the point of free software? I thought that the point was freedom: that users be permitted to use, modify & redistribute the software they use. Inclusion of BSD-licensed code in proprietary software fails at that: a macOS user is unable to use macOS without paying for it; unable to legally modify it; and even if he did modify unable to legally distribute those modifications.
BSD-licensed code is awesome for vendors of proprietary software who want a head start; it's not so great for users.
You're forgetting that those businesses that depend on your software are your users.
The first step of making useful software is by having users. If nobody uses your software because of licensing reasons nobody will ever contribute to it and it might as well not exist. On the other hand if there are users then there is a chance that a subset of the users will contribute back voluntarily.
Not true - if you compare various cases of GPL vs BSD, the theory of GPL helping the project just doesn’t hold. See MySQL vs Postgres, or GCC vs LLVM, or various MTAs.
That is exactly the point, with GCC the community would have enjoyed those improvements.
With LLVM, Sony gets to cut down their compiler research budget, and the community sees whatever Sony feels like giving back, minor improvements without the juicy optimizer sauce that actually matters.
Personally I don't care, given I use mostly commercial stuff nowadays, but I do see the return of shareware long term.
Then MIT/BSD license advocates can consider how much those licenses are actually worth to the overall community.
No - with GCC those improvements never got written, because the license used by GCC prevented it from happening in the first place. The decision whether to share the code usually happens before choosing the codebase to build upon, not the other way around.
In this specific case, Sony would have been forced to actually spend money doing a compiler from the ground up instead of cutting costs down costs while giving a few crumbs back to keep the plebe happy.
What I find ironic with the current anti-GPL trend is the eventual return of the shareware model, then lets see how well the MIT/BSD folks will appreciate it.
Only if you assume the only choices were 1. using GCC or 2. writing from scratch. Thing is, this assumption obviously doesn't match reality. Absurd assumptions -> absurd conclusions.
And no, BSD has nothing to do with shareware. Shareware was never about sharing sources; meanwhile, BSD-licensed projects are fine with respect to sharing - just take a look at Postgres, LLVM, FreeBSD, X11, or Python. GPL is an attempt to protect from a threat which was never real, and by doing so it makes life harder for everyone.
I have plenty of crufty shareware CDs and most likely unreadable floppies with source code on those .zip and .arj files.
FreeBSD vs what Linux has achieved, LLVM still lacking many of the hardware targets supported by GCC don't seem to be doing that great in company contributions. The others I don't know well enough to comment on.
Lets check again in about 10 years to see how far they managed to develop themselves.
How so? You mean the microkernel thingy? It somehow didn't hurt adoption of the most successful desktop Unix out there. The main thing that plays a role in adoption is whether something actually works.
> And that is why BSDs will never be as big as Linux, companies don't like to give free beer back to the tap
BSDs will (perhaps) never be as big as Linux because Linux had first mover advantage in the FOSS operating system world, and hasn't (yet) fumbled it badly enough to be displaced.
OTOH, Postgres and SQLite do quite well (with plenty of contributions from big downstream users and sellers), despite being permissively-licensed, and (in Postgres case) despite having a GPL competitor that used to be much further ahead of it in acceptance.
> MySQL is not a competitor to Postgres when one cares about real SQL support.
Which almost no one does, at least not as the sole decision factor. Even while being recognized as better on that dimension, Postgres was far behind MySQL for a number of reasons and caught up because of much stronger contribution from downstream users.
I think you've missed the point of most of the uproar. I haven't seen anybody claiming MongoDB doesn't have the right to use whatever license they like. I have however seen lots of people claim that it's a bad decision to use this latest license.
And people are free to criticize decisions all they want. It's really no different from the usual claims of bad technical decisions by MongoDB. Now people are just saying they're making bad business decisions too.
The rights discussion is largely irrelevant at this point.
This won't lead to more open source code. Reading the actual clause lists a myriad of potentially implicated kinds of software, all of which must be open source licensed, and not just that but also under SSPL.
Let's forget about the potential concept that GPLed software like the Linux kernel could very well be implicated, as LWN points out. Regardless, this clause is a literal legal minefield, and I would bet my life savings companies are going to buy commercial licenses rather than open their internal code under SSPL.
I'd rather bet my life savings that at least some such companies are going to reject both these options (SSPL or commercial licence) and just keep using the last MongoDB version that was released under GPL, possibly maintaining a fork of that version just as MariaDB has done.
That wouldn't really be the worst outcome, either. Well, it would be for MongoDB themselves, but to the rest of the open source community, it would mean a much less restrictive version of MongoDB would be available and maintained, which to me seems like a win.
They're allowed to license Mongo on whatever terms they see fit, but we're also allowed to judge them on the licence terms they choose.
If they had a source-provided, not-for-commercial-use hobbyist/educational licence and a proprietary licence, nobody would bat an eyelid. What they seem to be doing instead (this might or might not be correct, but is definitely the point the article is making) is burdening their "open source" licence with enough gotchas that it becomes quite unclear as to whether it's allowable in a commercial production environment (while still getting to claim it's Open Source Software), thus pushing people towards the proprietary licence without outright demanding it — which might be 100% legal, but is also profoundly dishonest.
I think that it is interesting that this is enabled by a CLA. If the project would have used a Developer Certificate of Origin (DCO) this relicensing would not have been possible. When Debian started to use GitLab they asked us to replace our CLA for the open source code to a DCO. They saw the risk of relicensing and addressed it.
Relicensing is still very much possible with DCO. You just put contributions under the license they were originally submitted and use whatever license you want for owned code. Essentially providing a separate license(s) for contributions.
The creator certainly has all those rights. On the other hand, it's definitely a goal here to have people use the software - that is, after all, a somewhat necessary precondition to making money off it. Given the difficulties with legally complying here, I'm not sure anyone who comes across this whole thing will want to touch MongoDB with 30ft pole, let alone make it a core component of their project.
From a company perspective, the current legal answer to "What happens if I use this under SSPL for <insert side project website here>?" appears to be "the entire site might have to be under SSPL - we don't know". So much for that, I'll use something else.
From an OSS perspective - it's generally considered that to maximise OSS, you want to allow supporting software (compilers, DBs, etc) to be used in commercial/proprietary systems. This can't be, not with a license like this.
"One could see this change as being just another company trying to go proprietary without actually looking proprietary." -- I think this is the key, they have a right to do what they want and monetize as they want (and I think it is good to monetize), but it somewhat of a misnomer to call them "open source" in the sense of code-sharing freely according to some philosophies.
You're going to get flak for this because you're factually incorrect. The SSPL is not an open source license. It might as well contain a clause that says "Thou shall not compete with MongoDB." As far as I can tell it was submitted to the OSI in bad faith.
Be that as it may, my opinion is informed. Like the Commons Clause before it the SSPL is an effort at undermining open source. It violates the Open Source Definition in letter and in spirit.
The OSI isn't going to approve it and Mongo damn well knew this when they submitted it.
It seems like it is to me, it's just extremely protective of the source code owner's rights.
> "Thou shall not compete with MongoDB."
Sounds to me like, "thou shall not offer MongoDB, and your own custom tooling, in your cloud without talking to us about licensing fees or making your cloud tech open source."
> It seems like it is to me, it's just extremely protective of the source code owner's rights.
It is effectively impossible to follow the conditions of the license -- according to the interpretation by Bradley Kuhn and others this would require you to provide the source code for Linux under this license if you run MongoDB on Linux. Linux is GPLv2 and has thousands of copyright owners -- it is not possible for any individual to relicense it to any other license.
If you have an "open source" license (which violates the one of the entries in the OSI definition -- "License Must Not Restrict Other Software") which cannot be followed by anyone then it's obviously not an FOSS software. It doesn't matter that in theory it would be FOSS, what matters is whether it is FOSS in practice.
Individuals interpretations of this are unlikely to matter much until such a clause is tested in court. The interpretation that the license is as broad as Mr Kuhn claims may be true, but it may not be.
Personally I think that both Mongo and Redis doing this is great as it shows the danger posed when a company can just relicense a project at will, which IMHO is the greater issue here. If Mongo felt the need they could amend their license again if it was tested in court and the court ruled against them. Individuals and companies should be aware that with some of these license agreements they could change at any time.
Ultimately governance of a project matters. We have seen somewhat of a split in the Cassandra community between Apache Cassandra and DataStax. That may ultimately prove to be beneficial as a new set of organizations has started to contribute. Having an organization like Apache to provide oversight and help draw a firm distinction between an open source project and a vendors proprietary offering was crucial there.
"Redis doing this" -> Redis is BSD licensed, but Redis Labs modules that were never part of Redis itself changed license. Note btw that when something is BSD can be relicensed by everybody, both the original copyright owners or anyone else.
I have never used Redis so I cannot comment on what is in Redis vs whatever Redis Labs modules are. I did observe that when the license was changed there was much gnashing of teeth about the license change so clearly at least a subset of potential users were surprised or upset about the license change.
I do think much of conversation about license changes is missing what I think the main risk of taking a dependency on an open source project where the license can be changed by the primary contributors with little to no oversight from anyone. And indeed Oracle has demonstrated that this is an issue for software that while proprietary has been free.
It may still be the right thing to do to use Redis or MongoDB or the Oracle JVM. Users may be fine with the new licensing terms. Maybe things fork and go their own way. Maybe people wake up to the risk they actually run when signing a contributor agreement (depending on what it contains). I just think there is too little real analysis of the true risks that exist when taking a dependency on a component which might not be supported under the expected licensing terms in the future.
> when something is BSD can be relicensed by everybody
Relicensing is not something that the BSD license permits. The license family is permissive, but a user doesn't have the right to strip out the copyright notice and call it a day.
I think they meant sublicense, which is something that the BSD license permits (though not as explicitly as MIT) because otherwise you wouldn't be able to use BSD code in GPL projects.
> Individuals interpretations of this are unlikely to matter much until such a clause is tested in court.
If the interpretation is reasonably plausible and untenable for a user, they just won't use the SSPL licensed version of the software.
So, yes, they will matter substantially.
For a big-money cloud provider, it's probably less risky to fork and maintain their own version from the GPL version (and share it to get code from the community).
> It seems like it is to me, it's just extremely protective of the source code owner's rights.
And you'd be mistaken. It isn't open source because (among other reasons) it discriminates based on your purpose for using the software. This tickles freedom zero of the free software definition and point six of the open source definition.
It directs licensing of software that is not a derived work of, or part of a combined work with, the software offered under the license, in violation of criterion 9 of the OSD.
(OTOH, it might be Free Software under the FSF Free Software Definition.)
> 1. MongoDB has the right to do whatever they like
Well, no, obviously not. They have to stay within legal bounds. But of course they can have any obscure license that is legal if they want.
The thing they get flak for is trying to deceive the public.
> 2. This License Means More Open Source Code
This license is only open source in a very obscure interpretation of the word. It's basically doing a lot of legal gymnastics to say "we don't want Google+Amazon to sell services based on our database, but we still want to call it Open Source". These two goals are fundamentally incompatible.
> This license is only open source in a very obscure interpretation of the word.
It's "open source" in the dead-obvious meaning "the source code is open for inspection". I'd argue it's all of the extra baggage that the OSI have read into the words "open" and "source" that are considerably more obscure. Neither the word "open" nor "source" implies "free for commercial exploitation to all and sundry"
The phrase "Open Source" is not necessarily just the summation of the constituent words "open" and "source". "Open Source" is a unique concept with a unique meaning... and the de-facto definition of that concept, is the OSD[1].
Similarly, there are are de-facto terms for the "the source code is open for inspection" (but not otherwise Open Source) models: things like "Source Available"[2] and "Shared Source"[3].
People trying to muddy the waters are generally being intentionally disingenuous because they want the general goodwill and positive buzz associated with being Open Source, without actually, ya know, being Open Source.
> The phrase "Open Source" is not necessarily just the summation of the constituent words "open" and "source". "Open Source" is a unique concept with a unique meaning... and the de-facto definition of that concept, is the OSD[1].
The use of the phrase "Open Source" predates the very _existence_ of the OSD by years[1], so it's somewhat laughable to claim that people are "trying to muddy the waters and being intentionally disingenuous" for simply not complying with the OSI's attempt to retroactively redefine the phrase to mean something other than the conventional and obvious meaning.
[1] The OSI was formed in February of 1998. The OSD had been drafted 9 months prior, in mid 1997. If, as claimed, the meaning of the phrase "Open Source" sprung forth from the ether with the OSD, then why, pray tell, is it dead easy to find uses prior to 1997 in which people are obviously referring to the ability to see the source-code and obviously _not_ referring to the ability to exploit it commercially?
> If a developer wants money for shareware,
paying the fee should automatically grant the user a copy of the source
code for their personal use. Restrictions could prohibit modifying and
redistributing binaries, but should allow distribution of "deltas" for
bug fixes, etc.
> Anyone else into "Source Code for NT"? The tools and stuff I'm writing
for NT will be released with source. If there are "proprietary" tricks
that MS wants to hide, the only way to subvert their hoarding is to post
source that illuminates (and I don't mean disclosing stuff obtained by
a non-disclosure agreement). Open Source is best for everyone in the
long run.
> Caldera believes an open source code model benefits the industry in many ways.
> ...
> Individuals can use OpenDOS source for personal use at no cost.
Individuals and organizations desiring to commercially redistribute
Caldera OpenDOS must acquire a license with an associated small fee.
I guess somebody should travel back in time and tell them they're "muddying the waters and being intentionally disingenuous"?
Or maybe, just maybe, it's the OSI that muddied the waters by trying to redefine a term to add their own ideological baggage to it.
Just because OSI wasn't formed as a legal entity until 1998 doesn't mean that the people involved weren't around and involved in those earlier discussions of "open source". All OSI did was formalize what was in common usage. And sure, you can cherry pick a few exceptions where individuals used the term in different ways. That has little or nothing to do with contemporary usage.
And in today's vernacular (dating back to at least 2000 or so) the de-facto definition is the OSI definition. A few lone-wolf dissenters don't change that.
Languages don't work like that. You don't just come up with a definition and try to force everyone to use it. People learn definitions from how they are used and mentioned in the things they encounter.
In reality almost no one is aware that OSI definition exists and those who do can't even remember what it is exactly. So, no, de-facto definition of open source is definitely not an OSI definition, but mostly literal meaning of open source software with most people presuming freely usable software as well to some degree. Take SQLite for example, it's open source, but not OSI open source and everyone is ok with that. Because this is where common meaning is. And trying to claim authority over it just invites bad PR for OSI. I guess OSI is already that irrelevant and it's pretty much consequence free to use a proper common meaning of open source.
You don't just come up with a definition and try to force everyone to use it.
Right, and nobody did that.
In reality almost no one is aware that OSI definition exists and those who do can't even remember what it is exactly.
I haven't found that to be the case. At least not for people who are actually involved in the open source community to any serious level. Maybe for casual bystanders.
Yes, we need an organization that governs over such a definition and over compliance, because otherwise the term becomes meaningless, due to being sexy for marketing purposes. Back in the day companies like Microsoft actually tried to hijack it via restrictive "shared source" licenses. And those cute little projects on GitHub without a license? Those are a legal minefield ;-)
Developers are not lawyers, we don't read the fine print. That's why we have to rely on certain freedoms when hearing the term Open Source. And one of those freedoms has been the freedom to run the program without restrictions. And another freedom has been the freedom to distribute the program along with other programs, without imposing restrictions on those other programs.
AGPL has been in my opinion restrictive enough that I don't think it is Open Source to begin with — smarter people than myself disagree, but this new SSPL is a farce because it extends those restrictions far beyond derived works. So I hope SSPL doesn't get approved by either OSI or FSF.
The GitHub repository lists 350 contributors.
Many of those are third-party I'm sure. So how many of them are happy with MongoDB's bait and switch? For that matter, how many people that advocated for MongoDB over the years would have done so in the knowledge that MongoDB is not Open Source?
> MongoDB has the right to do whatever they like
Sure, but that's not an argument. We also have the right to complain about it, to campaign against it and to stop using it.
The truth is the company behind MongoDB tries to eat their cake and have it too. Well, that's not how things work. Either you're developing Open Source and are thus happy with other companies profiting from your work, or you stop developing Open Source, but when you do, don't be hypocritical about it.
So, you don't like for the term "open source" to include anti lock-in conditions to protect users freedoms and only ok with it if the license permits lock-in exploitation of users via hosted services? That's the kind of open source definition I strongly disagree with.
Companies don't open source their products, especially their core business products, because they are awesome and want to contribute to the community (at least the majority of for-profit ones).
They do it because:
* The users demand it (you can be sure that MongoDB wouldn't be even remotely as popular if it started life closed-source)
* Because it generates free marketing and helps build a community
* Because it allows paying developers less or attract stronger talent
* Because it allows leveraging the community's talents to make the code better (I.E. getting outside contributors)
When you change the license, you break the unspoken contract between your users and contributors and the company, which is just a form of bait and switch.
You're forgetting to mention that open source != free software.
I have no problem with the license itself, because it maintains the four freedoms. So from a free software perspective it's fine, and that's the spirit of GPL. However, if I was a business owner, I would never run software under that license because it may create unforeseeable license conflicts. As far as I can see (correct me if I'm wrong), any software running on the SaS stack would have to be compatible with GPL, and there are plenty of open source licenses that you might want to or need to use that are incompatible with GPL. For example, it seems that strictly speaking only fully FSF approved GNU/Linux distributions are compatible with that license.[1]
Or maybe I'm misinterpreting the license requirements? (IANAL)
I'm pretty sure that the new license does not "maintain the four freedoms".
I don't know if the FSF will approve of this new license, however by the Free Software definition it should be even more damning, first of all because it violates Freedom 0. The corresponding rule in OSI's definition is less strict ;-)
The "spirit of the GPL" has nothing to do with this license. The GPL is just a "copyright license", meaning that it's concerned only with distribution and with derived works, where distribution and "derived works" are defined by the copyright law.
The GPL is in fact very business friendly and that was by design.
The article seems to suggest it can't be used with even Linux b/c Linux isn't under the SSPL. So the license seems to in effect make the software effectively unusable
Which in a way isn't their fault.. there is a weird license lock-in that seems to happen with licenses and it really forces your hand to use a particular license for practical reasons
I know for instance Clojure is all under the EPL - so it makes it a weird licensing issue to use it with GPL code (The way I understand it is that you can, if you basically treat it all like GPL code.. maybe?)
Because MongoDB is no longer open source. It is a sham license that says it is open source, but isn't, forcing pretty much everyone to use the proprietary license.
They of course have the legal right to do this and given that they require contributors to hand over copyright, they have no legal right to complain about this either. As the only copyright holder, Mongo gets to license their contributions anyway they want.
Of course the latter practice is very common with this style of licenses and doing a bait and switch like this on the license is always a bit controversial, no matter what the intentions. AGPL style licenses without copyright transfer agreements are very uncommon as re-licensing becomes near impossible without full agreement of all copyright holders. This means none of them are able to use the software they worked on other than under the strict terms of the license, which typically precludes many potentially interesting ways of using the software. AGPL as a license is only interesting if you can opt out from it. This is only possible if you own the copyright.
Probably true, non-open source code provokes multiple open source compeitors when successful, so this non-open (per OSD criterion 9) license will, when used, probably provoke more open source code to be written.
This is just typical "people are saying" weasel words. The GPL and similar licenses still definitely have a role to play in the current state of software.
LWN isn't anti-GPL. I don't know what made you think this -- the title is obviously a reference to people thinking the GPL is "scary" and that the SSPL takes the GPL and actually makes it scary.
This has the potential to backfire spectacularly. If anyone is able to abide by this license and offer mongodb as a service, they will dramatically lower the barrier to entry for mongodb hosting.
Mongo is betting that their service is uncommodifiable.
Perhaps they want to get out of the hosting game altogether, make their money consulting. In that case they’d have made a very competitive hosting market to drive down prices and spur adoption.
I think if they change the license back, the damage would already have been done. Competitors would have access to a competitive mongodb service stack.
>Like Redis Labs before it, MongoDB has concluded that this license allows a bit too much. In particular, cloud providers are offering access to MongoDB instances without cutting the company in on the resulting revenue stream, and that doesn't feel right. In response, MongoDB has just announced an immediate shift to its brand-new Server Side Public License (SSPL).
This paragraph conflates Redis' application of the Commons Clause [1] to its add-ons with the switch of the license for MongoDB from AGPL to its own license called SSPL[2].
This are in my eyes two very different things.
The Commons Clause is a commercial restriction and its creators are very clear about the fact that it is not an Open Source license.
The SSPL, on the other hand is, in my opinion, an adaption of the GPL to new distribution channels that goes even further than the AGPL. I see this as very much in line with the original spirit of the GPL, regardless whether MogoDB's motivation might be primarily commercial or not. These are just my 2 ct from a curious glance and I'd be very much interested how RMS sees this, I hope we will get a statement from him or the GNU project.
>There is a lesson here for contributors as well. The request for license approval notes that: "As of this writing, the MongoDB GITHUB repository shows over 43,000 commits, 680 releases, and over 350 contributors." To become one of those contributors, a developer must first sign MongoDB's contributor agreement, which assigns copyright ownership to MongoDB. Those contributors all gave MongoDB the right to relicense their code in this manner [...]
CLAs are pretty common nowadays and they can be a problem for potential contributors but pointing at MongoDB, for just doing what many other large OpenSource projects do, isn't fair.
> I see this as very much in line with the original spirit of the GPL, regardless whether MogoDB's motivation might be primarily commercial or not.
I disagree. GPL was never about relicensing other people's software. The SSPL basically requires this if you read Section 13.
> CLAs are pretty common nowadays and they can be a problem for potential contributors but pointing at MongoDB, for just doing what many other large OpenSource projects do, isn't fair.
Just because many projects do this doesn't mean it's a good thing to do -- the FSF CLA is the only CLA I would find acceptable because it's purpose is to ensure they can relicense to later GPL versions as well as have litigation rights in the US. Several other "CLAs" (like Apache's) are actually just beefed up versions of the DCO.
But unconditional and asymmetric CLAs are the reason that OpenSolaris could become proprietary under Oracle, as well as many other horror stories in the history of free software. Many people use them, but that doesn't justify it.
Wouldn't it be possible for an entity such as Amazon to establish a separate legal entity and thus circumvent MongoDB's Server Side Public License ?
The separate entity would provide the "raw" service (where there wouldn't be much to open source) to Amazon, possibly running MongoDB directly on their infrastructure, then Amazon would turn it into a full-fledged SaaS offer.
> "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.
How could one even practically conform to this license? Unless you are a 100% pure open source house, every company uses proprietary software in some form. Be it the OS/Apps on your developers/operations (management software) laptops (macOS/Windows) or firmware/tooling (ILO, DRAC, etc) of your server stack.
I understand they want us to buy a proprietary mongo license, but I don't see how it would even be possible to run mongo as a service without.
It should also be noted that they require the "Service Source Code" to be provided under the terms of their license. So it's not possible for anyone to follow these restrictions even on a fully free software stack if any part of that stack is copyleft (for instance, Linux).
That was what first caught my eye as well, which would make it impossible.
> The affected code must not only be released, it must be made available under the SSPL.
But I think it should be interpreted that if you modify the code (mongodb) under SSPL it should be distributed under the same license, like is normal for other open source licenses.
No, while they don't have the AGPL section, the wording in section 13 is pretty clear:
> you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.
Now, this only applies if you've modified the source code. But being barred from the effective right (due to the requirement mentioned above) to use modified versions of software makes it obviously proprietary.
SSPLV2: If you want to use my software freely, you must open source every piece of software you've ever touched or been in contact with,
even if you don't own it, or I get to sue you.
Open source (~= free software) is aimed to protect the freedom of the user, not the freedom of the (proprietary) software developer.
By forcing developers to disclose their changes to MongoDB essentially makes the end-users more free, since they can then replicate more parts of the program they are using.
------------------------------
Proprietary software developers use copyright to take away the users' freedom; we use copyright to guarantee their freedom.
Don't know from where you pulled that off, probably inspired by the communist manifesto, but such software developers are also users and the distinction is entirely superficial in order to advance an agenda.
Down with the bourgeoisie, heh?
> By forcing developers to disclose their changes to MongoDB essentially makes the end-users more free, since they can then replicate more parts of the program they are using.
So wait, "end users" are empowered developers now?
Weird thought, but I think that with this license MongoDB has managed to attack the OSI without attacking the FSF. To me, this is perfectly acceptable Free Software but so strict that it basically reads "do not use this software commercially, it requires you to open every piece of software that any of your employees have ever seen or heard of, including software you do not own. Purchase a license from us." In other words, commercial usage is allowed in the post-revolution Free world that Free Software hopes to bring about, where people have access to the contents of the computers that they interact with, and the freedom to mess with the ones they own.
The Open Source concept, however, is not philosophically based; its primary goal is to allow businesses to collaborate on building blocks, but not to prevent them from taking one of those blocks and carving it into something that they're not willing to share. Since their primary goal is to help business, they can't help but disapprove; since they don't explicitly state this goal, they have no nominal basis to reject it without rejecting Free Software in general.
I predict some eventual announcement that the license is "effectively closed source" and instead of accompanying that announcement with a specific supporting argument, they'll accompany it with a questionable written history of the OSI. They'll disapprove, or approve with asterisk.
> Since their primary goal is to help business, they can't help but disapprove; since they don't explicitly state this goal, they have no nominal basis to reject it without rejecting Free Software in general.
Without engaging with your characterization of OSI motives, the OSI has a clear basis to reject it without rejecting Free Software in general; unlike all other existing Free Software licenses, SSPL (which might be Free Software) violates criterion 9 of the Open Source definition by restricting licensing of other software not derivative of, or part of a shared work with, the software originally distributed under the SSPL.
I've been a Free Software supporter for my entire carrier.
Let's get one thing clear ... this change by MongoDB Inc wasn't done for preserving user freedom, but for preserving their bottom line. Spinning it into anything else is dishonest.
And this is not Free Software in my book because it violates Freedom 0. And I hope the FSF never approves it, or if it does, it just goes to show that the FSF is corrupted.
Could you explain how the term does not apply? Its meaning seems to be: "to impose upon another's generosity or hospitality without sharing in the cost or responsibility involved".
Free software users are voluntarily given use of the software with only specified conditional responsibilities; them using the software and not taking on additional responsibilities is not an imposition of any kind, and not freeloading.
Isn't that the same as when someone offers me a couch to surf and a kitchen to use? Sure, it's unconditional and I'm not violating any agreement, but if I use their stuff and don't give anything back, am I not a freeloader?
But in that case, you are taking up space on their couch and eating their food - their resources are diminished by your use of them. That's not the case here.
I think "free-rider" is probably a better choice of term.
I wonder why the RPL isn't more popular for this. It's an OSI-approved license that is meant to fix the "SAAS loophole":
PREAMBLE
The Reciprocal Public License (RPL) is based on the concept of reciprocity or, if you prefer, fairness.
In short, this license grew out of a desire to close loopholes in previous open source licenses, loopholes that allowed parties to acquire open source software and derive financial benefit from it without having to release their improvements or derivatives to the community which enabled them. This occurred any time an entity did not release their application to a "third party".
While there is a certain freedom in this model of licensing, it struck the authors of the RPL as being unfair to the open source community at large and to the original authors of the works in particular. After all, bug fixes, extensions, and meaningful and valuable derivatives were not consistently finding their way back into the community where they could fuel further, and faster, growth and expansion of the overall open source software base.
While you should clearly read and understand the entire license, the essence of the RPL is found in two definitions: "Deploy" and "Required Components".
Regarding deployment, under the RPL your changes, bug fixes, extensions, etc. must be made available to the open source community at large when you Deploy in any form -- either internally or to an outside party. Once you start running the software you have to start sharing the software.
Further, under the RPL all components you author including schemas, scripts, source code, etc. -- regardless of whether they're compiled into a single binary or used as two halves of client/server application -- must be shared. You have to share the whole pie, not an isolated slice of it.
In addition to these goals, the RPL was authored to meet the requirements of the Open Source Definition as maintained by the Open Source Initiative (OSI).
Interesting. I guess the RPL however is as toothless as the AGPL when it comes to extend its scope to the provisioning software cloud providers use to run your AGPL-licensed software for their customers, which is the problem I believe MongoDB, Inc. wants to target.
IANAL, but I guess this comes down to the interpretation of "Required Components".
1.12 "Required Components" means any text, programs, scripts, schema, interface definitions, control files, or other works created by You which are required by a third party of average skill to successfully install and run Licensed Software containing Your Modifications, or to install and run Your Derivative Works.
You have to make the source of the required components available under the RPL (section 6.0-6.1).
Would provisioning software to operationalize a database within a cloud environment be considered a "required component"? Maybe. If the cloud provider made modifications to the db source to get it to run well inside of their cloud environment, and did it in a way that made it impossible to run the modified db outside of their cloud environment, without using their custom provisioning scripts, then I would argue that those provisioning scripts would be considered "required components" under the definition in 1.12. But if they are able to run the db without making modifications to it, so that it is the same as upstream, and a third party developer does not need the provisioning scripts to run the modified db, then the provisioning scripts would not be considered required components.
So, the RPL is perhaps stronger than the AGPL, but not strong enough for MongoDB or Redis Labs.
I don't know about RPL, but GPL has been tested a lot. For example, in the early 2000s, Linksys was forced to release the source code of their router firmware. This project was forked and is now maintained in the OpenWrt embedded linux distribution.
150 comments
[ 3.1 ms ] story [ 178 ms ] threadFrom the SSPL:
13. Offering the Program as a Service.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version
“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.
I've worked with some copyright lawyers that basically said "it's impossible to know, and we'd rather just avoid the question to begin with", and forbade us from using AGPL in any of our deployments.
If you're building for example an ecommerce that uses MongoDB as database, you're not selling MongoDB as a service, so you don't need to license your software with this new SSPL.
If you're building an ecommerce as a service with a MongoDB database, again you're not selling MongoDB as a service, so you're safe again.
IANAL + usual disclaimers.
If you as a person want to run software xyz and try to make money off of it, go ahead. As soon as you open a limited company to reduce your exposure you should be hit with paying license fees.
I don't get the hate for the licenses that try to remove freedom 0 for corporations. At work I suggest horrible propitiatory software solutions all the time because it doesn't matter how locked down the stack is.
So long as it has a ROI of >3% over the fixed and running costs it's a good solution.
No one is harmed by human first open source software, other than a legal fictions bottom line.
So basically, turn freedom 0 into not freedom 0.
For reference, GNU freedom 0 is “the freedom to run the program as you wish, for any purpose”.
What you are saying seems to go against the principles of freedom 0, and I don’t get your motivation either, because at the same time you don’t seem to mind proprietary software.
My main issue with what you are saying is that it’s not clear what you mean by “removing freedom 0 for corporations”. Do you mean specifically when they are offering software written by someone else as a direct service to customers? What about using it in the backend? What about employees using FOSS?
There is a lot more to be said and discussed about this.
In other words, if I use your website, I should also be able to stand up my own version that uses my own data.
That depends on what your definition of "you" and "you wish" is.
If your boss tells you to run X then you are not the one wanting to run it, the company is. And, American jurisprudence not notwithstanding, I don't consider corporations to be a form of "you".
If a sole proprietor with full legal liability for their actions wanted to do the same, more power to them. No matter how many people they hire to do the work for them.
I also don't see why limitation of liability is the point where right to use free software should be curtailed -- there already is no liability in software (see the no warranty clause in literally every software license). Why not put the line at making a profit at all? (Because it's obvious that disallowing users to make any money at all with a free software license would clearly be an issue.)
http://www.networkcultures.org/_uploads/%233notebook_telekom...
It is sort of similar but includes worker-owned coops. So basically either an individual person or a worker-ownder coop can use a Copyfarleft work for profit.
calling it open source is harming actual open source projects by making people fear adopting them.
I don't care if someone is using my software in their family bakery. If anything I'd be super happy about that.
What I do mind is someone using my software in their multinational baking conglomerate without me ever seeing a cent for the work, while at the same time keeping other developers from ever being paid for developing the software in house.
> multinational baking conglomerate
> keeping other developers from ever being paid for developing the software in house
Sorry if miss-logicing in these quotes. Please do correct if you thing they're taken out-of-place.
A bakery is commercial. They software they use is baked into the oven and POS. 'family bakery' - do you mind a family member in the store, do you mind them logging it with your name? Do you mind them using a camera to recognise when you come in? Do you mind a staff member recognising you when you come in? Is tallying today's weather vs sandwiches sales OK? Credit card promotion? Different level of Personally Identifiable Identification.
> What I do mind is someone using my software in their multinational baking conglomerate without me ever seeing a cent for the work
Why not? What's the license? Assume in Github. Ask for comments. The people in these companies are hackers too and not cold-blooded fuck-the-customer. If you're got good code for baking, contribute.
We’re not shooting future us in the foot.
It’s far more about function and redistribution than ROI. It’s about peace of mind. It’s about not having to worry about a vendor revoking a license down the road.
I think you are entirely missing the point and values of “Free Software” vs open source.
MongoDB can very well stop calling itself an open source software then when to use it in any significant manner, one needs to get into a proprietary license agreement. Wish the license doesn’t get approved as a valid open-source license.
Its a fine revenue stream for me, and in the context of what I am building and the companies that are using it, there is absolutely no reason to not use the AGPLv3 licensed master branch or releases, as I know they will never extend my software. Yet some people have an axe to grind with AGPLv3, to which I get to respond "Pay me money or fuck off". Seeing as none of them understand how to write software, they tend to pay me :P
Worst case someone extends one of my AGPLv3 projects, adding features and improving it. I'll accept a pull request with no CLA so long as the code is of decent quality.
If you accept contributions without a CLA, you are not the sole owner of the copyrights anymore and you cannot offer a proprietary paid branch, unless all contributors give you permission to relicense their AGPL code as proprietary.
Its a definite edge case, but if I can get active contributors, I am not about to ask them to sign a CLA.
IANAL, but depending on who you ask, AGPL is deemed unenforcable or even misusing copyright legislation. In any case, AGPL hasn't, to the best of my knowledge, been tested before a (US or EU) court. If it had, I'd expect an excessive discussion as to which scope AGPL can have, and a fundamental legal discussion of whether copyright laws can even limit use of third-party software.
Anyway, AGPL doesn't directly address commercial licensing; it rather extends GPL's "distribution" to the case of "provisioning over a network", with the understanding that a commercial license also offered from the publishers doesn't require you to publish your source code to your end users. As it stands, AGPL might not be a good tool to express/enforce "free for personal use". It also depends on whether you actually want to win contributors, or merely have a licensing badge for your project. The AGPL itself basically implies that you want contributions (code) from your commercial users, rather than money.
> IANAL, but depending on who you ask, AGPL is deemed unenforcable or even misusing copyright legislation.
No clue wrt AGPL (an old, crusty license), but GPLv3 was written with heavy involvement of the Software Freedom Law Center. The Affero paragraph (which is the only difference between AGPLv3 and GPLv3) was written by this same team at the same time.
As a non-lawyer, I would presume the lawyers that were tasked with reviewing the various forms of the third revision of GPL licenses did their job.
Notice that it is perfectly fine to be "open source" without being "open development". Many free software projects do not actually accept pull requests as a matter of principle.
In that case, you canmake a driveby issue. This will be preferable for them and easier for you.
1. MongoDB has the right to do whatever they like
------------------------------------------------------
The creator of a product:
1. Has a rational interest in maximizing their returns
2. Owns all the rights to their products (barring existing IP restrictions)
And if they choose to open source their code:
3. it is of their own prerogative
4. without any obligation to do so.
Given 1, and 2, if they open source their code, they're an awesome person because they're revealing some portion of their secret business logic to the public. With that, they are entitled to whatever conditions they put on their code. That includes CLA's regardless of how much potential contributors will protest.
It doesn't matter how "against the spirit of open source" a CLA, or an overly radical copy-left license is. The creator of the product will always have an obligation to their own interests first, and since they're already sacrificing trade secrets by revealing their software source (something they were never obligated to), they can honestly do whatever they'd like.
And this includes ensuring that everyone using their software open-sources all forks of their software. Heck, even open-sources everything they use in support of their software.
Let's face it, if their software just weren't that good, no one would use it.
2. This License Means More Open Source Code
----------------------------------------------------
If the outside world wants more open source code, I don't see why they'd giving MongoDB any flak for this. All this license will do is result in more open-source code. After all, isn't that the point all along?
Or are zealous demands for open-source code only valid while it's all about a single popular product by a big company (MongoDB), and not when smaller software components by smaller companies (billing, hosting scripts by SaaS providers)?
Edited for grammar and other things my brain missed
Nothing new under the sun.
I don't think that will happen. I think they will just sell more commercial licenses, which seems to be the entire (valid imo) point of this license change.
This might be a good thing in the end because it exposes a new downside to CLAs and might make people think twice before signing them in the future.
> If the outside world wants more open source code, I don't see why they'd giving MongoDB any flak for this. All this license will do is result in more open-source code. After all, isn't that the point all along?
It would be a good thing if we could reasonably expect the effect to be that companies might release more open source code as a result. Yet the licence is so vague and broad that the much more likely intention (and effect) is that other companies will be forced to buy the proprietary licence to avoid the impracticability of using code under SSPL. I also don't think this kind of overreach in what is required to be open sourced just because you're using a component X is acceptable.
That's why I prefer BSD-style licenses - when they write "free", they mean "free".
Also why all new open source OSes done companies are all based on BSD/MIT licenses like Zephyr, RTOS, Fuchsia, ...
When we get back to PD, Shareware world, don't start complaining companies don't contribute back.
I release my code as open-source because I don't want my end users to ever end up unable to fix bugs in the code they're using. I don't want my code used in something like macOS where users are stuck using what they're given; it might help those users in the short term, but I believe it leaves them worse off in the long term.
By analogy; if one is free to rob someone, they're more free in absolute terms than they're free if they can't do that, but then the person who is about to get robbed isn't free to feel secure. So in other words, the robber is more free, but at the expense of the robbed.
In that sense, the BSD license is more absolutely/selfishly free for the individual, whereas the GPL is more freedom-perusing for the entire community.
Was that the point of free software? I thought that the point was freedom: that users be permitted to use, modify & redistribute the software they use. Inclusion of BSD-licensed code in proprietary software fails at that: a macOS user is unable to use macOS without paying for it; unable to legally modify it; and even if he did modify unable to legally distribute those modifications.
BSD-licensed code is awesome for vendors of proprietary software who want a head start; it's not so great for users.
The first step of making useful software is by having users. If nobody uses your software because of licensing reasons nobody will ever contribute to it and it might as well not exist. On the other hand if there are users then there is a chance that a subset of the users will contribute back voluntarily.
With LLVM, Sony gets to cut down their compiler research budget, and the community sees whatever Sony feels like giving back, minor improvements without the juicy optimizer sauce that actually matters.
Personally I don't care, given I use mostly commercial stuff nowadays, but I do see the return of shareware long term.
Then MIT/BSD license advocates can consider how much those licenses are actually worth to the overall community.
What I find ironic with the current anti-GPL trend is the eventual return of the shareware model, then lets see how well the MIT/BSD folks will appreciate it.
And no, BSD has nothing to do with shareware. Shareware was never about sharing sources; meanwhile, BSD-licensed projects are fine with respect to sharing - just take a look at Postgres, LLVM, FreeBSD, X11, or Python. GPL is an attempt to protect from a threat which was never real, and by doing so it makes life harder for everyone.
FreeBSD vs what Linux has achieved, LLVM still lacking many of the hardware targets supported by GCC don't seem to be doing that great in company contributions. The others I don't know well enough to comment on.
Lets check again in about 10 years to see how far they managed to develop themselves.
Maybe I will be wrong, maybe not.
BSDs will (perhaps) never be as big as Linux because Linux had first mover advantage in the FOSS operating system world, and hasn't (yet) fumbled it badly enough to be displaced.
OTOH, Postgres and SQLite do quite well (with plenty of contributions from big downstream users and sellers), despite being permissively-licensed, and (in Postgres case) despite having a GPL competitor that used to be much further ahead of it in acceptance.
A suit that was settled in about 2 years, and Linux also had its own set of suits.
Most companies that use BSD seldom give anything back thanks to the license.
MySQL is not a competitor to Postgres when one cares about real SQL support.
Which almost no one does, at least not as the sole decision factor. Even while being recognized as better on that dimension, Postgres was far behind MySQL for a number of reasons and caught up because of much stronger contribution from downstream users.
And people are free to criticize decisions all they want. It's really no different from the usual claims of bad technical decisions by MongoDB. Now people are just saying they're making bad business decisions too.
The rights discussion is largely irrelevant at this point.
Let's forget about the potential concept that GPLed software like the Linux kernel could very well be implicated, as LWN points out. Regardless, this clause is a literal legal minefield, and I would bet my life savings companies are going to buy commercial licenses rather than open their internal code under SSPL.
If they had a source-provided, not-for-commercial-use hobbyist/educational licence and a proprietary licence, nobody would bat an eyelid. What they seem to be doing instead (this might or might not be correct, but is definitely the point the article is making) is burdening their "open source" licence with enough gotchas that it becomes quite unclear as to whether it's allowable in a commercial production environment (while still getting to claim it's Open Source Software), thus pushing people towards the proprietary licence without outright demanding it — which might be 100% legal, but is also profoundly dishonest.
From a company perspective, the current legal answer to "What happens if I use this under SSPL for <insert side project website here>?" appears to be "the entire site might have to be under SSPL - we don't know". So much for that, I'll use something else.
From an OSS perspective - it's generally considered that to maximise OSS, you want to allow supporting software (compilers, DBs, etc) to be used in commercial/proprietary systems. This can't be, not with a license like this.
You're going to get flak for this because you're factually incorrect. The SSPL is not an open source license. It might as well contain a clause that says "Thou shall not compete with MongoDB." As far as I can tell it was submitted to the OSI in bad faith.
So far this is just your opinion. If the OSI will approve it has yet to be seen...
The OSI isn't going to approve it and Mongo damn well knew this when they submitted it.
It seems like it is to me, it's just extremely protective of the source code owner's rights.
> "Thou shall not compete with MongoDB."
Sounds to me like, "thou shall not offer MongoDB, and your own custom tooling, in your cloud without talking to us about licensing fees or making your cloud tech open source."
It is effectively impossible to follow the conditions of the license -- according to the interpretation by Bradley Kuhn and others this would require you to provide the source code for Linux under this license if you run MongoDB on Linux. Linux is GPLv2 and has thousands of copyright owners -- it is not possible for any individual to relicense it to any other license.
If you have an "open source" license (which violates the one of the entries in the OSI definition -- "License Must Not Restrict Other Software") which cannot be followed by anyone then it's obviously not an FOSS software. It doesn't matter that in theory it would be FOSS, what matters is whether it is FOSS in practice.
Personally I think that both Mongo and Redis doing this is great as it shows the danger posed when a company can just relicense a project at will, which IMHO is the greater issue here. If Mongo felt the need they could amend their license again if it was tested in court and the court ruled against them. Individuals and companies should be aware that with some of these license agreements they could change at any time.
Ultimately governance of a project matters. We have seen somewhat of a split in the Cassandra community between Apache Cassandra and DataStax. That may ultimately prove to be beneficial as a new set of organizations has started to contribute. Having an organization like Apache to provide oversight and help draw a firm distinction between an open source project and a vendors proprietary offering was crucial there.
I do think much of conversation about license changes is missing what I think the main risk of taking a dependency on an open source project where the license can be changed by the primary contributors with little to no oversight from anyone. And indeed Oracle has demonstrated that this is an issue for software that while proprietary has been free.
It may still be the right thing to do to use Redis or MongoDB or the Oracle JVM. Users may be fine with the new licensing terms. Maybe things fork and go their own way. Maybe people wake up to the risk they actually run when signing a contributor agreement (depending on what it contains). I just think there is too little real analysis of the true risks that exist when taking a dependency on a component which might not be supported under the expected licensing terms in the future.
Relicensing is not something that the BSD license permits. The license family is permissive, but a user doesn't have the right to strip out the copyright notice and call it a day.
If the interpretation is reasonably plausible and untenable for a user, they just won't use the SSPL licensed version of the software.
So, yes, they will matter substantially.
For a big-money cloud provider, it's probably less risky to fork and maintain their own version from the GPL version (and share it to get code from the community).
And you'd be mistaken. It isn't open source because (among other reasons) it discriminates based on your purpose for using the software. This tickles freedom zero of the free software definition and point six of the open source definition.
It directs licensing of software that is not a derived work of, or part of a combined work with, the software offered under the license, in violation of criterion 9 of the OSD.
(OTOH, it might be Free Software under the FSF Free Software Definition.)
Well, no, obviously not. They have to stay within legal bounds. But of course they can have any obscure license that is legal if they want.
The thing they get flak for is trying to deceive the public.
> 2. This License Means More Open Source Code
This license is only open source in a very obscure interpretation of the word. It's basically doing a lot of legal gymnastics to say "we don't want Google+Amazon to sell services based on our database, but we still want to call it Open Source". These two goals are fundamentally incompatible.
It's "open source" in the dead-obvious meaning "the source code is open for inspection". I'd argue it's all of the extra baggage that the OSI have read into the words "open" and "source" that are considerably more obscure. Neither the word "open" nor "source" implies "free for commercial exploitation to all and sundry"
Being able to compile and run the software for whatever propose you want isn't obscure.
Similarly, there are are de-facto terms for the "the source code is open for inspection" (but not otherwise Open Source) models: things like "Source Available"[2] and "Shared Source"[3].
People trying to muddy the waters are generally being intentionally disingenuous because they want the general goodwill and positive buzz associated with being Open Source, without actually, ya know, being Open Source.
[1]: https://opensource.org/osd-annotated
[2]: https://en.wikipedia.org/wiki/Source-available_software
[3]: https://en.wikipedia.org/wiki/Shared_Source_Initiative
The use of the phrase "Open Source" predates the very _existence_ of the OSD by years[1], so it's somewhat laughable to claim that people are "trying to muddy the waters and being intentionally disingenuous" for simply not complying with the OSI's attempt to retroactively redefine the phrase to mean something other than the conventional and obvious meaning.
[1] The OSI was formed in February of 1998. The OSD had been drafted 9 months prior, in mid 1997. If, as claimed, the meaning of the phrase "Open Source" sprung forth from the ether with the OSD, then why, pray tell, is it dead easy to find uses prior to 1997 in which people are obviously referring to the ability to see the source-code and obviously _not_ referring to the ability to exploit it commercially?
For instance, here's a post from 1993 on comp.os.ms-windows.programmer.win32 (https://groups.google.com/forum/#!msg/comp.os.ms-windows.pro...):
> If a developer wants money for shareware, paying the fee should automatically grant the user a copy of the source code for their personal use. Restrictions could prohibit modifying and redistributing binaries, but should allow distribution of "deltas" for bug fixes, etc.
> Anyone else into "Source Code for NT"? The tools and stuff I'm writing for NT will be released with source. If there are "proprietary" tricks that MS wants to hide, the only way to subvert their hoarding is to post source that illuminates (and I don't mean disclosing stuff obtained by a non-disclosure agreement). Open Source is best for everyone in the long run.
Or this email from 1996 (http://www.xent.com/FoRK-archive/fall96/0269.html):
> Caldera Announces Open Source for DOS.
> ...
> Caldera believes an open source code model benefits the industry in many ways.
> ...
> Individuals can use OpenDOS source for personal use at no cost. Individuals and organizations desiring to commercially redistribute Caldera OpenDOS must acquire a license with an associated small fee.
I guess somebody should travel back in time and tell them they're "muddying the waters and being intentionally disingenuous"?
Or maybe, just maybe, it's the OSI that muddied the waters by trying to redefine a term to add their own ideological baggage to it.
And in today's vernacular (dating back to at least 2000 or so) the de-facto definition is the OSI definition. A few lone-wolf dissenters don't change that.
In reality almost no one is aware that OSI definition exists and those who do can't even remember what it is exactly. So, no, de-facto definition of open source is definitely not an OSI definition, but mostly literal meaning of open source software with most people presuming freely usable software as well to some degree. Take SQLite for example, it's open source, but not OSI open source and everyone is ok with that. Because this is where common meaning is. And trying to claim authority over it just invites bad PR for OSI. I guess OSI is already that irrelevant and it's pretty much consequence free to use a proper common meaning of open source.
Right, and nobody did that.
In reality almost no one is aware that OSI definition exists and those who do can't even remember what it is exactly.
I haven't found that to be the case. At least not for people who are actually involved in the open source community to any serious level. Maybe for casual bystanders.
They are very much compatible. Even more so, than permissive licenses that don't protect users of services from lock in.
Yes, we need an organization that governs over such a definition and over compliance, because otherwise the term becomes meaningless, due to being sexy for marketing purposes. Back in the day companies like Microsoft actually tried to hijack it via restrictive "shared source" licenses. And those cute little projects on GitHub without a license? Those are a legal minefield ;-)
Developers are not lawyers, we don't read the fine print. That's why we have to rely on certain freedoms when hearing the term Open Source. And one of those freedoms has been the freedom to run the program without restrictions. And another freedom has been the freedom to distribute the program along with other programs, without imposing restrictions on those other programs.
AGPL has been in my opinion restrictive enough that I don't think it is Open Source to begin with — smarter people than myself disagree, but this new SSPL is a farce because it extends those restrictions far beyond derived works. So I hope SSPL doesn't get approved by either OSI or FSF.
The GitHub repository lists 350 contributors.
Many of those are third-party I'm sure. So how many of them are happy with MongoDB's bait and switch? For that matter, how many people that advocated for MongoDB over the years would have done so in the knowledge that MongoDB is not Open Source?
> MongoDB has the right to do whatever they like
Sure, but that's not an argument. We also have the right to complain about it, to campaign against it and to stop using it.
The truth is the company behind MongoDB tries to eat their cake and have it too. Well, that's not how things work. Either you're developing Open Source and are thus happy with other companies profiting from your work, or you stop developing Open Source, but when you do, don't be hypocritical about it.
They do it because:
* The users demand it (you can be sure that MongoDB wouldn't be even remotely as popular if it started life closed-source)
* Because it generates free marketing and helps build a community
* Because it allows paying developers less or attract stronger talent
* Because it allows leveraging the community's talents to make the code better (I.E. getting outside contributors)
When you change the license, you break the unspoken contract between your users and contributors and the company, which is just a form of bait and switch.
I have no problem with the license itself, because it maintains the four freedoms. So from a free software perspective it's fine, and that's the spirit of GPL. However, if I was a business owner, I would never run software under that license because it may create unforeseeable license conflicts. As far as I can see (correct me if I'm wrong), any software running on the SaS stack would have to be compatible with GPL, and there are plenty of open source licenses that you might want to or need to use that are incompatible with GPL. For example, it seems that strictly speaking only fully FSF approved GNU/Linux distributions are compatible with that license.[1]
Or maybe I'm misinterpreting the license requirements? (IANAL)
[1] https://www.gnu.org/distros/free-distros.en.html
I don't know if the FSF will approve of this new license, however by the Free Software definition it should be even more damning, first of all because it violates Freedom 0. The corresponding rule in OSI's definition is less strict ;-)
The "spirit of the GPL" has nothing to do with this license. The GPL is just a "copyright license", meaning that it's concerned only with distribution and with derived works, where distribution and "derived works" are defined by the copyright law.
The GPL is in fact very business friendly and that was by design.
Which in a way isn't their fault.. there is a weird license lock-in that seems to happen with licenses and it really forces your hand to use a particular license for practical reasons
I know for instance Clojure is all under the EPL - so it makes it a weird licensing issue to use it with GPL code (The way I understand it is that you can, if you basically treat it all like GPL code.. maybe?)
Of course the latter practice is very common with this style of licenses and doing a bait and switch like this on the license is always a bit controversial, no matter what the intentions. AGPL style licenses without copyright transfer agreements are very uncommon as re-licensing becomes near impossible without full agreement of all copyright holders. This means none of them are able to use the software they worked on other than under the strict terms of the license, which typically precludes many potentially interesting ways of using the software. AGPL as a license is only interesting if you can opt out from it. This is only possible if you own the copyright.
The producer will usually favor its own interests. Not always. You could have used SQLite. No one forced you to use Mongo.
Probably true, non-open source code provokes multiple open source compeitors when successful, so this non-open (per OSD criterion 9) license will, when used, probably provoke more open source code to be written.
http://www.networkcultures.org/_uploads/%233notebook_telekom...
Mongo is betting that their service is uncommodifiable.
Perhaps they want to get out of the hosting game altogether, make their money consulting. In that case they’d have made a very competitive hosting market to drive down prices and spur adoption.
This paragraph conflates Redis' application of the Commons Clause [1] to its add-ons with the switch of the license for MongoDB from AGPL to its own license called SSPL[2]. This are in my eyes two very different things.
The Commons Clause is a commercial restriction and its creators are very clear about the fact that it is not an Open Source license.
The SSPL, on the other hand is, in my opinion, an adaption of the GPL to new distribution channels that goes even further than the AGPL. I see this as very much in line with the original spirit of the GPL, regardless whether MogoDB's motivation might be primarily commercial or not. These are just my 2 ct from a curious glance and I'd be very much interested how RMS sees this, I hope we will get a statement from him or the GNU project.
>There is a lesson here for contributors as well. The request for license approval notes that: "As of this writing, the MongoDB GITHUB repository shows over 43,000 commits, 680 releases, and over 350 contributors." To become one of those contributors, a developer must first sign MongoDB's contributor agreement, which assigns copyright ownership to MongoDB. Those contributors all gave MongoDB the right to relicense their code in this manner [...]
CLAs are pretty common nowadays and they can be a problem for potential contributors but pointing at MongoDB, for just doing what many other large OpenSource projects do, isn't fair.
[1] https://commonsclause.com/
[2] https://www.mongodb.com/licensing/server-side-public-license
I disagree. GPL was never about relicensing other people's software. The SSPL basically requires this if you read Section 13.
> CLAs are pretty common nowadays and they can be a problem for potential contributors but pointing at MongoDB, for just doing what many other large OpenSource projects do, isn't fair.
Just because many projects do this doesn't mean it's a good thing to do -- the FSF CLA is the only CLA I would find acceptable because it's purpose is to ensure they can relicense to later GPL versions as well as have litigation rights in the US. Several other "CLAs" (like Apache's) are actually just beefed up versions of the DCO.
But unconditional and asymmetric CLAs are the reason that OpenSolaris could become proprietary under Oracle, as well as many other horror stories in the history of free software. Many people use them, but that doesn't justify it.
The separate entity would provide the "raw" service (where there wouldn't be much to open source) to Amazon, possibly running MongoDB directly on their infrastructure, then Amazon would turn it into a full-fledged SaaS offer.
How could one even practically conform to this license? Unless you are a 100% pure open source house, every company uses proprietary software in some form. Be it the OS/Apps on your developers/operations (management software) laptops (macOS/Windows) or firmware/tooling (ILO, DRAC, etc) of your server stack.
I understand they want us to buy a proprietary mongo license, but I don't see how it would even be possible to run mongo as a service without.
> The affected code must not only be released, it must be made available under the SSPL.
But I think it should be interpreted that if you modify the code (mongodb) under SSPL it should be distributed under the same license, like is normal for other open source licenses.
> you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.
Now, this only applies if you've modified the source code. But being barred from the effective right (due to the requirement mentioned above) to use modified versions of software makes it obviously proprietary.
I think that's the point...
QED
By forcing developers to disclose their changes to MongoDB essentially makes the end-users more free, since they can then replicate more parts of the program they are using.
------------------------------
Proprietary software developers use copyright to take away the users' freedom; we use copyright to guarantee their freedom.
------------------------------
https://www.gnu.org/licenses/copyleft.html
Don't know from where you pulled that off, probably inspired by the communist manifesto, but such software developers are also users and the distinction is entirely superficial in order to advance an agenda.
Down with the bourgeoisie, heh?
> By forcing developers to disclose their changes to MongoDB essentially makes the end-users more free, since they can then replicate more parts of the program they are using.
So wait, "end users" are empowered developers now?
Oh, is this a good guys versus bad guys thing?
The Open Source concept, however, is not philosophically based; its primary goal is to allow businesses to collaborate on building blocks, but not to prevent them from taking one of those blocks and carving it into something that they're not willing to share. Since their primary goal is to help business, they can't help but disapprove; since they don't explicitly state this goal, they have no nominal basis to reject it without rejecting Free Software in general.
I predict some eventual announcement that the license is "effectively closed source" and instead of accompanying that announcement with a specific supporting argument, they'll accompany it with a questionable written history of the OSI. They'll disapprove, or approve with asterisk.
edit: and, of course, what kemitchell said.
Without engaging with your characterization of OSI motives, the OSI has a clear basis to reject it without rejecting Free Software in general; unlike all other existing Free Software licenses, SSPL (which might be Free Software) violates criterion 9 of the Open Source definition by restricting licensing of other software not derivative of, or part of a shared work with, the software originally distributed under the SSPL.
Let's get one thing clear ... this change by MongoDB Inc wasn't done for preserving user freedom, but for preserving their bottom line. Spinning it into anything else is dishonest.
And this is not Free Software in my book because it violates Freedom 0. And I hope the FSF never approves it, or if it does, it just goes to show that the FSF is corrupted.
I think "free-rider" is probably a better choice of term.
PREAMBLE
The Reciprocal Public License (RPL) is based on the concept of reciprocity or, if you prefer, fairness.
In short, this license grew out of a desire to close loopholes in previous open source licenses, loopholes that allowed parties to acquire open source software and derive financial benefit from it without having to release their improvements or derivatives to the community which enabled them. This occurred any time an entity did not release their application to a "third party".
While there is a certain freedom in this model of licensing, it struck the authors of the RPL as being unfair to the open source community at large and to the original authors of the works in particular. After all, bug fixes, extensions, and meaningful and valuable derivatives were not consistently finding their way back into the community where they could fuel further, and faster, growth and expansion of the overall open source software base.
While you should clearly read and understand the entire license, the essence of the RPL is found in two definitions: "Deploy" and "Required Components".
Regarding deployment, under the RPL your changes, bug fixes, extensions, etc. must be made available to the open source community at large when you Deploy in any form -- either internally or to an outside party. Once you start running the software you have to start sharing the software.
Further, under the RPL all components you author including schemas, scripts, source code, etc. -- regardless of whether they're compiled into a single binary or used as two halves of client/server application -- must be shared. You have to share the whole pie, not an isolated slice of it.
In addition to these goals, the RPL was authored to meet the requirements of the Open Source Definition as maintained by the Open Source Initiative (OSI).
https://opensource.org/licenses/RPL-1.5
1.12 "Required Components" means any text, programs, scripts, schema, interface definitions, control files, or other works created by You which are required by a third party of average skill to successfully install and run Licensed Software containing Your Modifications, or to install and run Your Derivative Works.
You have to make the source of the required components available under the RPL (section 6.0-6.1).
Would provisioning software to operationalize a database within a cloud environment be considered a "required component"? Maybe. If the cloud provider made modifications to the db source to get it to run well inside of their cloud environment, and did it in a way that made it impossible to run the modified db outside of their cloud environment, without using their custom provisioning scripts, then I would argue that those provisioning scripts would be considered "required components" under the definition in 1.12. But if they are able to run the db without making modifications to it, so that it is the same as upstream, and a third party developer does not need the provisioning scripts to run the modified db, then the provisioning scripts would not be considered required components.
So, the RPL is perhaps stronger than the AGPL, but not strong enough for MongoDB or Redis Labs.
For example, based on that could I release a web server and then sue anybody who wouldn't provide source code to their browser to me?
https://en.wikipedia.org/wiki/OpenWrt
Here is a list of GPL enforcement cases from the Free Software Foundation:
https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases