Making the GPL more scary
lwn.net
lwn.net
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
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)
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.
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.
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...
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.
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.
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).
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:
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?
Oh, is this a good guys versus bad guys thing?
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.
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 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.
QED
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.
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.
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.
I think "free-rider" is probably a better choice of term.