MongoDB switches up its open source license
techcrunch.com
techcrunch.com
I'm sure people will get riled up about this, but it makes sense. Building a business on an OSS database in a world of behemoth cloud providers is really hard. It's clear Google and Amazon (and maybe even Azure) are comfy taking OSS work, doing a ton of proprietary development on it, and leaving the companies who did all the groundwork flailing in the wind.
These things are going to keep happening as long as mega tech companies (a) use OSS to commoditize other companies' products and (b) exploit permissive licenses to the max.
I don't want to live in a world where the only infrastructure software we have access to is what the big companies deign to open source. Life is better when small groups of devs can build and sustain critical infrastructure software. We need more haproxies and redises and binds and (fill in blank).
That said, MongoDB has never figured out how to work with their ecosystem in a way that's good for everyone. They've gone from trying to extort money from smaller companies to undercutting them to this. And it's likely not gonna change much this time, the world of "run a database as a service" is changing I think, and being replaced with more generic tools that just so happen to manage complex persistence well.
_Also_ I bet some random licensing folks are crapping their pants at IBM right now. I'm ashamed at how funny that is.
Have you seen the degree of investment Microsoft has made lately in Open Source? It's an upside-down world where Microsoft if a bigger champion -- and funder -- of open source than a company like Google which was built on Open Source software.
Google has released roughly every meaningful patch it has made to the open source software it was built on[1].
As for funding, that's definitely not true by the numbers last i looked (and definitely was not true in the past).
Without concrete disagreements, this is just handwaving. So if you make some, i'm happy to argue with real data.
[1] The only cases i can think of that this isn't true is when the Googler who worked on it left before they got a chance to do that (and nobody has picked it up since)
Chrome or Android seem like good counterexamples, where the software that most people use (Chrome, or Android + Google Experience) is specifically kept in two separate buckets, open source and closed source, so that Google can strategically keep some parts open and some parts closed.
The original complaint was about taking other people's open source (mongodb) without contributing back. Not "failing to release stuff it made itself". That's a completely different thing.
Even there, what i said is still true: Google has released every meaningful patch to the open source software it used in making Chrome/Android.
Like any sane kernel team, google tries to minimize it's difference with upstream since it has huge maintenance cost.
Microsoft gets all the news because it's a drastic change from normal behaviour.
Amazon, Google, Oracle et all just keep steadily contributing stuff. A lot of the work is also deadly boring and not headline capturing stuff.
Few simple queries to show the work they're doing just on the kernel:
Amazon: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Google: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Microsoft: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Oracle: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
I feel like many people deciding to use an open source license for their project never consider the consequences of such choice. They use OSS because it's "cool" or they hope to get some free work done for them. If you pick an open source license and someone uses your code to build something else within the license boundaries, that is not a Bad Thing(tm).
I have released many open source projects under MIT and GPL licenses and I have no problem with anyone repackaging it however they please, as long as they respect the license terms.
On the other hand, when I pick an OSS software to build upon, I pick it exactly because of the license and plan to use the license to the extent it is allowed. If the license doesn't look like a good fit, I use something else or write my own code.
I don't feel like Google/Amazon/etc. owe anything to anyone just because they made it and now have a lot of money.
I just wanted to point out that from an Economic perspective this:
> I don't feel like Google/Amazon/etc. owe anything to anyone just because they made it and now have a lot of money.
And the ability to utilize that war chest to cannibalize the best of open source to create private differentiators raises the barrier of entry for competition. This market would naturally drift towards an oligopoly-like market equilibrium.
Like I said, I agree with your perspective on licenses. I would just also like OSS to be the great equalizer that instills innovation and disruption in the greater tech market place. But so long as tech giants can take any good new OSS, pay top dollar to recruit great engineers, and then throw them at OSS then I don't think this ideal vision will come to fruition.
I might say instead that the norms of open source software development -- attribution, collaboration, good faith -- are so baked in to small, high-trust communities that they might seem as though they'll be obvious to everyone. And then your software makes it way to the public and you realize that those were just assumptions and not written into the letter of agreement at any point.
I'm speaking as an outside observer on this.
And I say this as someone who has released all of his software within the past decade using either GPLv3 or APGL, for exactly this reason.
When they fail to give back by dodging taxes, paying minimum wages, spying on people, cornering markets, competing against FLOSS project/orgs they are breaking good faith relations (and the spirit of law)
Open source db software is suitable for these dual licenses - using it is free, but if you are going to sell products and services that are repackaged versions of the tool, you should pay the creator (like mysql).
This is simply not true in any meaningful way. Please cite real data. It's very hard to disagree with handwaving like this.
Both Google's official policy (which is super clear about this: https://opensource.google.com/docs/), and practice (releasing and working on tens of thousands of open source projects) say otherwise.
I would love to see the data that goes with this claim.
AGPL was a roundabout way of hinting that cloud providers should kick back some revenue and now that it didn't work the truth can come out.
How does AGPL force kicking back of revenue? The only way I can think of is if the cloud-provider choose to relicense the software (for a fee), because they can always fulfill the terms of the AGPL by publishing all their changes without paying a dime.
This is false. Seriously - i'm not sure why people on HN like to offer things as facts that they simply aren't ever going to know about.
Google in fact does pay companies that developed open source software that Google relies upon.
What you're saying is (I think): Google contributes code + projects back to the OSS community and sponsors OSS organizations.
I think if we could see the actual numbers — if it were possible to see Google's cloud revenue with associated OSS contributions — we'd see that what they're actually giving "back" is tiny, and it's the equivalent of donating to charities.
Since we don't know how many people actually work on OSS at Google, we can maybe use this estimate: https://twitter.com/mjasay/status/960563592683667456
Assuming Google pays ~$250k salaries to all of those folks to work full time on other peoples' projects, they're spending about $500mm/year on OSS while making ~$2bn/yr on just Google cloud. And that's horribly optimistic, I doubt much of that money is going to projects Google doesn't control.
Google's original OSS projects are different, I tend to like them. But given Google's market power the actual effect is to commoditize all the things Google doesn't expect to make money on. Kubernetes is great. Mesosphere is increasingly irrelevant because of it. OSS projects from megacorps tend to have the same effect as price dumping. They can afford to spend more money making something an non-viable business than most companies can spend at all.
Well, that's one way to put it I guess. I personally am OK with anyone taking my work and doing a ton of proprietary development on it. I wouldn't put it out there that way if I wasn't (and don't w/ my proprietary stuff).
We need to stop demonizing restrictionless development. Same with commercial/copy-left development of course, but I'm seeing too much copy-left righteousness these days. To each their own. Also, we need to stop being so prideful in our work that we consider some uses of it an affront. Sometimes when you make things available to the world at large sans restrictions you have misusers. That's ok. But hating the proverbial man tends to only negatively affect downstream users at large. MongoDB can do what it wants, and should commercialize where it wants, but all this corporate hatred coupled with openness righteousness should stop being used as justification.
> _Also_ I bet some random licensing folks are crapping their pants at IBM right now. I'm ashamed at how funny that is.
So are their customers and all users who lost some freedoms today because of perceived self-righteousness. Ashamed is a fair word for grinning after pivots like these, but I definitely don't see a problem with the pivot itself. Again, to each their own.
I'm not sure what planet you live on, but the GPL and other various copy-left licenses have been on the slow decline for years in part due to things like SaaS negating the use of everything but the Affero GPL and the social 'implications' of using the GPL ("poisonous", "viral"), while the use of extremely liberally-licensed, "corporate-friendly" permissive licenses has skyrocketed.
You don't have to look far (I've seen it more than once) to find people submitting issues on places like GitHub to completely relicense a project, just because it was GPL. Even here, every time a piece of code with a GPL license is attached and posted, you can be certain of someone pointing this out.
There are technical factors involved (like what's the deal with JavaScript licensing), but ultimately less projects choose the GPL -- or any other "demanding" copy-left license -- than ever before, so I have no idea what you're talking about, other than a perceived persecution complex where you think people are trying to "stop you" from using their code?
Of course, the funny thing is you say we need to stop "demonizing" restrictionless development, and of all copyleft licenses, the Affero GPL actually has risen in usage. But that's not because there's a big mean group of copy-leftists making people do it through blackmail. It's because it's risen in usage in corporate-sponsored, open-core projects, precisely to disincentivize systems like large, already-rich SaaS companies sucking the money out of their core customers by requiring them to share the source code for their changes (which they are often unable to do, making it effective). Corporations that sell open source software exactly understand how this game works -- they don't want other companies directly eating away the bulk of their revenue streams by just slapping a stupid UX and some user management patches on top, and so they license their software in an appropriate manner to try to cover all bases (source available, but without already-geared-up companies eating away their direct lifelines).
You'll also notice most of the companies doing this strategy aren't already highly-powerful, highly-monied SaaS companies. They're often much smaller and starting off, trying to get their software in the hands of users, while retaining revenue leads. Highly powerful companies like Google can afford to just release everything under non-copyleft licenses like Apache or MIT. They can subsidize the development of the software through established business.
But I imagine most people on this website wouldn't see these companies as being "copy-left righteous", only "protecting their investment". Unsurprisingly, this kind of understanding doesn't seem to extend to individual developers who license their code under a copyleft licenses (who are "righteous", and have no reason to care about anything other than the most people possible using their software).
Maybe the "copy-left" righteousness you're seeing isn't a massive proliferation of copy-left licensing, but actually a result of people getting wise to the way this conversation plays out. After all, if I'm going to be accused of being righteous, I might as well use the GPL, since apparently anything less than a free-for-all isn't acceptable to a lot of people.
The planet that recognizes that proclaimed righteousness (what I wrote about) has nothing to do with adoption (what you wrote about). If anything it makes the righteousness stick out because it goes against what people are choosing. I rarely see GPL devs demonized for how they choose to give their code away, or blog posts and evangelists espousing anti-GPL, or the straggling person "eventually coming out and calling it poisonous", or justifications on non-GPL changes as claiming corporate harm.
I have no statement on license prevalence and it is unrelated to my comment. My statement is about justification used and being overly prideful of their work. Change and be done. One way is not necessarily better than another, and companies are not all bad, and that's not only who you are hurting with these changes, etc. But when I hear complaints about the company using up all their hard work like it's some zero-sum coffer being depleted, I don't pity them. I know the intent is guilt and I don't think it's a good look.
I'm not! I love permissive OSS licenses, I think they're great until they get abused.
What I'm demonizing is overly powerful megacorps owning an unreasonable amount of the available "tech" revenue.
This license from MongoDB is an unfortunate side effect of that. I don't think anyone there wanted a weirdly restrictive license, but I do think they want to build a healthy business on top of their work. And that's something I want them to be able to do as well.
There's a big, big difference between companies in an oligopoly position and normal companies. Permissive OSS grew up in a world that wasn't a weird oligopoly for good reasons, but a lot has changed in the last 10 years and it's downright dangerous to license things permissively and try to build a business at the same time.
Example: we built an Edge Runtime, it's under a permissive license, if we're successful I expect we'll run into the same problem DB companies have and then have to navigate around that: https://github.com/superfly/fly
I think they're great even when they get "abused" (for that definition of "abuse" which I don't agree with).
> What I'm demonizing is overly powerful megacorps owning an unreasonable amount of the available "tech" revenue.
Whether or not that is a problem is a different discussion, but suffice to say the license change will not solve or change that. It is naive to think so.
> it's downright dangerous to license things permissively and try to build a business at the same time
Well, if you attempt to build a business on the permissively licensed thing, of course. I'm not sure I concede that building a business on permissively licensed thing, thereby changing its license, is required. Building a business around it? Developing it with funds acquired on other business? Remaining small and not growing it beyond its original development? All of these are sustainable development models too. Before being so quick to blame these "megacorps" like they did something wrong, consider whether the changes to correct this "wrong" even accomplish the goal and whether that goal has any value of being accomplished. The intent of the license change has less value than its practical effect, and the idealistic way we'd like open source to sustain itself and be profitable is not always the pragmatic one. Calling them "megacorps", saying they are the problem, saying you have no choice but to change your license, etc all of this is what I mean about the ill-perceived righteousness of license restrictions.
> Calling them "megacorps", saying they are the problem, saying you have no choice but to change your license, etc all of this is what I mean about the ill-perceived righteousness of license restrictions.
They _are_ megacorps. It's ok to be fine with megacorps, but it's a little silly to pretend they're not.
They are a problem (you can disagree with this). We'd be better off with 20 smaller companies than one large Google. More innovation, less barriers to competing, etc, etc. It's not really righteousness, righteousness is more a moral stance than an "oh shit this is a bad state we're in".
Until communities refuse to sign CLA that let projects bait-and-switch to another license once they have a large community and want to now take buckets of VC money.
It's totally rational to create a license model that prevents hosting to third parties, but still allows end users to adopt the technology without paying. As has been pointed out elsewhere, that may not be right for all OS projects, but it should be an option.
Aren't you glad it isn't you! ;-)
Any other company (like Compose) can do the same thing and there are several hundred vendors offering various options. MongoDB Atlas is entirely this, and seems to be doing well by leveraging their own expertise and moving faster than the others.
If MongoDB now wants to change the license then they're free to do so, but they'll face the consequences of becoming more proprietary with their offering. It may help or it may hurt, but there's not some big universal argument to be made. If you don't want to make and give away free stuff, then don't. The rest of the world will still manage just fine.
Obviously the service is managed and that has value, regardless of the backend and your opinions on how they run it. Perhaps your issue is with all the customers who want and pay for this rather than providers meeting a need.
Why does this debate consyantly flare up again and again? No one is exploiting licenses, if you release something as open source then it’s open source, amongst other things you give up any claim to the money others might make using your software. That is your choice, any no one is exploiting you or your work by using the software within the license you granted them.
People need to stop this attempt at having “financially closed” open source. If you want you software to be propriataty and have limitations on usage just do that. Don’t release it as open source and cry fowl when other treat it like that instead of treating it like you had a proprietary license on it.
But, it feels like yet another fallacy. What really is an open source project then?
Say some developer X contributes to a project like MongoDB his/her open source code so that they can one day run MongoDB as a service and make money. At that time, he/she believe that status is true and submits their code. But, later, after the project is mature, the major contributor easily changes license at will, and the open source contributors walk away with nothing?
I'm not saying that MongoDB Inc, does not have the majority stake here. Just wondering about whether it is a "bait & switch"esque move?
Imagine if all projects did the same... Say Docker? later on chooses to say that you can use Docker for free but if you distribute your software through repositories supported by the daemon, then you need to pay up.. Wouldnt that be a loss for the contributors that are not working for the company?
Amazon can afford to fork the project and poach top talent from your company. I think these moves are extremely short-sighted.
Changing license models only causes instability in the overall ecosystem.
Amazon employee here. Amazon offers two different types of service. For a service like Amazon RDS then yes it is the standard open source project hosted and managed by AWS. The value add is that you don't have to administrate and back it up, etc.
For something like Amazon Aurora its a different story. Aurora is API compatible with MySQL and Postgres but it is designed internally to work quite differently, really designed for the cloud first. And the result is its up to 5x faster than the standard open source software and just better than the open source version in many ways.
Both as a former customer of AWS and now as an engineer at AWS I have always preferred the from scratch implementations by AWS over the hosted open source versions. I'd rather not use a forked version of open source. I'd rather use something built by AWS engineers from the ground up
It's also noticably slower than plain PG in other cases.
For the record: I'm not a big fan of Mongo (the DB) but I think MongoDB, Inc. raises a valid point wrt. developers doing all the hard work including community building and a million other things, while "cloud providers" get all the money. This isn't sustainable, and we need a license which more clearly says "if you make money with it, you need to give us some", rather than using the bare AGPL license without further qualifications in the hope AGPL's "freedom" aspirations have the indirect effect of forcing commercial users and/or resellers to pay.
The projects you mention: Linux+git development has good financial standing from companies who could be seen as going (or having gone) aggressively against commercial Unix from a business PoV. gcc thrived on freedom enthusiasm but has seen many, many patches from commercial vendors wanting their OS, CPU or whatever supported.
How much AWS shares its profits with GCC, qemu, etc? Not at all besides the bare minimum that benefits them.
(And don't misunderstand me, I don't see Mongo as some kind of underdog here, but making big money from software is hard, even if - or exactly because - valuations - and funding - are in the sky.
And AWS is fundamentally a different kind of business than what open source usually is. It has a compounded networks effects / economies of scale effects. And on top of that it has a closed source management layer, but that is largely irrelevant, except for Mongo in this case.)
Linux, gcc, git OSS projects are less concerned about capturing value from the economic activities enabled by them, which is why they were all set up as not-for-profit enterprises; the expectation is that donations will help cover their operating costs.
MongoDB on the other hand is a for-profit enterprise that took VC funding in the hope that they'd be able to cover their operating costs in the long term without donations.
The only way to do this is to capture some of the value offered by the NOSQL paradigm, but it appears that the cloud providers are beating them at that game, which is why they needed to change tactics, to guarantee their survival as a self-sustaining entity.
I think MongoDB is free loading off the the community and developers. The developers don't get to use the software to make a profit without kicking some money upstream to mongo either. Is Mongo going to start offering money for bug reports and patches or do they get to freeload off of their community?
[1] https://azure.microsoft.com/en-us/blog/azure-cosmos-db-micro...
IMO, Azure remains a garbage fire of half-finished features in almost every offering. We replaced Cosmos with a Bitnami-authored canned VMs pre-configured for a simple Mongo cluster (which make up a significant portion of "features" they offer), which failed to restart after the Meltdown cloud reboot because the Bitnami management software corrupted the disks. Now we just run our own VMs with our own Mongo instances and curse the day we were obligated to move to Azure.
[0] https://feedback.azure.com/forums/263030-azure-cosmos-db/sug...
Of course that would be pointless as anyone who forked before the license change could continue re-distributing under AGPLv3.
_minified_ shell scripts
I'm not sure how these ideas tie together.
This is self evident from the licences themselves but also clearly reasonable if you consider the proportions of contributions made. Why should a contributor get rights to all future work on a project made primarily by others solely by making a contribution?
> ...and the open source contributors walk away with nothing?
Nope. As others have pointed out, they walk away with the Free Software licensed version of the code to which they contributed, together with their contributions. This code base does exactly what it did at the time of their contributions.
Wait just one second here. Is docker still open source or is Moby the new open source docker?
https://blog.docker.com/2017/04/introducing-the-moby-project...
My understanding is that recent versions of docker is indeed not open source but moby is? Is that correct according to the OSI?
Doesn't AGPLv3 already require open sourcing server side implementations?
Thanks in advance
“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.”
^ not the same.
It's going to backfire hard when distros start removing Mongo from their main repos.
(Thanks for the explanation, "DFSG" passed over me the first time I read this. "Debian Free Software Guidelines".)
Since the new Mongo license violates rule 9 of the DFSG, it is considered proprietary software by Debian's definition, and that means Debian's FOSS policy will require Mongo to be moved out of the core repos and into the non-free repo. Fedora and Ubuntu have their own policies which will have the same effect.
Last week I was debating whether MongoDB is now completely obsoleted by PostgreSQL’s JSON datatype. As of now, I consider that no longer a debate.
No, I think the real goal here is to make it effectively impossible to use this in a business setting without buying a commercial license. I'm glad Linus and RMS didn't see it that way.
===
However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.
===
Not that this makes the issue any more clear or enforceable...
There was no abuse, there was only mongo not being able to make money in all cases they wanted to. That's what they see as abuse. It isn't.
While they complain of bad actors, bad actors always act bad. This will not disincentivize them (they are also often in a lot of interesting jurisdictions that would make it hard anyway).
Instead, this is really about making it completely unpalatable for normal actors to not pay mongo in every single case.
Otherwise, one has to believe that mongo is going to go off and sue a bunch of people now, which would be a horribly stupid business model.
Abuse is often legal.
This feels a lot like when i hear about "GPL" abuse when it was specifically not designed for what people think is abuse (and that's not my view but stallman's).
Similarly, AGPL was not designed to require every piece of software around a piece of AGPL software to be open sourced.
Deliberately so. Not doing so is not "abuse".
You may have different goals, and that's actually fine! But it doesn't make following the license and what it was meant for abuse.
I'll also point out: In the history of my work on open source, by far the largest legal abusers of open source are startups. By many orders of magnitude. This is real abuse in the sense of clear license non-compliance. I worked on M&A at a variety of companies that acquired all sorts of different kind/stages of startups.
They rarely are compliant with even simple notice licenses (IE don't bother to post notices), let alone any of the more restrictive licenses.
Large corps often have legal departments that try to understand and consider and figure out what to do, even if they do it wrong.
So to me, every time i hear "large company open source abusers" i kind of laugh, because IMHO getting the startups to stop abusing open source would have a much more significant difference on OSS than getting 2 or 3 large companies to stop "abusing" it.
It's situational, but if you define abuse as "breaking a contract or law" we're not going to agree on anything about this.
MongoDB has _always_ wanted to make money when other people make money reselling their work. The AGPL doesn't really do what they needed, but their intent has been clear since day one.
Give me concrete examples.
I explicitly pointed out to you a social norm, not a violation of contract. I did not define it as breaking a contract or law. I defined it in terms of the social norm that was set by the creator of the license, or the "spirit" of the license.
I want to understand what you see as "violation of that spirit", not the legal definition. As mentioned, most definitions i've seen here are explicitly not what the creator of the license intended (again, not what they wrote down, but what they intended). It's hard to see something that doesn't violate the spirit of the license as abuse.
For example, i often hear about "not contributing back" to GPL projects. RMS explicitly was okay with "not contributing back" in the broader sense, as long as they released their source code. He had no expectation he would get anything other than a pile of source that he would have to deal with. He just wanted to be able to hack it, so as long as it had the right stuff, he didn't expect others to care. He thought it would be nice for sure, but it's not "abuse".
(A great concrete example of abuse is usually binary kernel blobs that have deliberate shim interfaces. This clearly violates the spirit of the license even if the license says it may be okay.)
So far i haven't seen what you have defined as abuse especially by "large companies".
Additionally, I pointed out to you the notion that large corporations are the ones doing the abusing is wrong under almost all definitions of abuse, spirit, legal, aspirational, you name it.
Companies like Google, MS, Amazon are not violating norms but complying with them. When companies like MongoDB abandon these licenses its because they're incompatible with their business model.
Open Source is fine for them while they're making a market and developing a programmer user base, becoming popular with people who will not bother with a new proprietary database, mind you, but once they're 'popular' and need to increase revenue, the license gets replaced with a familiar , proprietary, one.
This is a bad analogy for software, since software is not a finite resource. Anyone can make a near infinite number of copies.
Don't blame 3rd parties when you realized that an open source license is the wrong license for your product.
I don't think this takes away from MongoDB picking the wrong license and business model.
Using your analogy, MongoDB is taking all of the free community that is around open source and changing the license after they have a community so they can extract/shakedown money from people. If anyone is abusive, it's people like MongoDB changing the license after they got lots of free contributors adding to mongodb.
The AGPL is just generally a ridiculously badly written license.
Some companies are illegally running a modified version of MongoDB while keeping their changes closed source.
As I understand, the new licence will allow them to do that if they pay a commercial licence (contributing to the project by financing instead of coding).
In the matter of allowing commercial licensing by the copyright-holder, the AGPL and this new license do not differ.
Yes this is not going to stop the Asian cloud providers they talk about. It is truly aimed at AWS et al. If they came out and said that it would not sound as nice. Mongo just made a big move in the cloud space by buying mLab. They are looking to contain the competition.
The cloud competitors MongoDB professes concern about have sophisticated software license counsel. They're very good at reading licenses. That is part of the claimed problem: They were good enough to see and exploit loopholes in a dense, oddly drafted license like AGPLv3, which most others read as "free for free software only", rather than as written. They also have deep pockets, US legal nexus, and significant ongoing commercial use to enjoin. The latter make a wide target. But the former makes them too strong to sue on anything but firm ground.
I don't know what you mean by normal actors, but if there are a lot of them, and they're relatively small, and also potential Mongo customers, suing them en mass to make examples, RIAA/MPAA-style, isn't nearly as appealing as cutting big cloud providers offering MongoDB off from updates with a license change. Everything about these changes and the materials accompanying points to the latter.
I don't see Mongo announcing any litigation campaign for going beyond AGPLv3 permission. I do see Mongo drawing a new line in the sand, via a new license for new releases, that will be easier to defend against the specific competitors they see pushing the limits of the old line.
Or they might just release their entire stack, which is probably 90% open source stuff with 10% glue code anyway.
There’s more to running a business than just cloning a software stack. Any idiot can fire up an OpenStack based ‘cloud’, but that won’t make them the next AWS.
They struck the portion of section 13 that allowed for such combinations.
(You can see it in the redline they published here:https://webassets.mongodb.com/_com_assets/legal/SSPL-compare...)
Can someone enlighten me on the significance of this piece of text? Does it mean you're not allowed to edit the license and publish it under the same name, or does it effectively copyright the entire license text? I'm gravitating towards the former since this is a case where the text was edited but renamed, but I'd still like some clarity.
As an aside, is it even possible to copyright a license? There's a copyright notice so isn't this technically plagiarism?
1. You’re still helping education, nonprofits, and individuals benefit from your work.
2. It’s still open source, so people will still be able to contribute and use your work in their own projects.
3. Companies that want to use your code to make money can do so, but only if they also help out the other “worthy” causes by contributing changes back.
In fact, I'm consider something more radical like a YUMMY license (you make money, I make money) - which has all the same benefits of being open source and helping worthy causes, except at least you get to make money when someone uses your work to do something that you might not even want, like selling ads.
Small developers and companies without layers of lawyers will read the licence, see that it says "do what the ---- you want", and use your code accordingly.
Big companies with layers of lawyers will read the licence, blanch in terror, and either refuse to use the software, or contact you for alternative terms.
Case in point: Google forbids use of the WTFPL. https://opensource.google.com/docs/thirdparty/licenses/#wtfp...
We go over it in new googler training (and our reasoning is on the Google open source policy site we publish: https://opensource.google.com/docs/thirdparty/licenses/#wtfp...)
You are welcome to not (but if you go and look, it's completely consistent with my viewpoints and history in OSS so ...).
I would love to live in a world where WTFPL is a good license, but we don't live in that world, and wanting it to be so will not change that.
I can also tell you stories of companies we've acquired who had bad experiences, FWIW.
So the "small companies" you think are being served, aren't.
You clearly didn't read the link i said which says our issue with WTFPL is with the lack of warranty disclaimer and with the rights grant (which is not likely to be valid in a number of countries).
You will find nothing, nor have i stated anything about the ability for google to use the code for "monetization" reasons. It doesn't even enter the equation
It is very hard to take your comment in good faith as a result.
Our policy pages are clear on why we ban licenses, even things like AGPL. You'll note they are not economic concerns (IE google won't be able to monetize), but compliance ones.
(Of course, you should view these in good faith, they were originally written for an internal audience)
I can definitively state I have never banned a license at Google due to Google's ability to "monetize" the code, or even indirect versions of that (IE that if it became popular, it would hurt google's ability to do that). All concerns are compliance ones.
Additionally, the pages i linked you to very clearly encourage people to contribute back as much as they can.
AGPL compliance wouldn't be that difficult if you remove making money from the equation. So indirectly your compliance concerns are based on economic concerns.
This is simply false (on both points), and you haven't given any reason it would be true past "i feel this way". Even with direct support from our build system, AGPL compliance is incredibly difficult relative to GPL and other licenses[1]
This argument also amounts to "I know more about your job than you do", which, if you do, awesome!, please feel free to do it :) I'm actually happy to go do something else.
But i don't see evidence that this is true.
[1] For starters, we have to distinguish between what things , what are user facing, what kinds of users have access to them (IE internal services accessible only to FTE googlers are different from those accessible to TVC for AGPL purposes) , etc. This is an incredibly difficult set of problems on the technical side.
That is always true, even for non-open source licenses.
You could take MIT code and comply not just by publishing a notice but by publishing all of it. I don't think that is a meaningful argument against the annoyance of having to collate and publish notices.
Imagine if you have a commercial license that requires you be able to allow them to look through your books to verify software licensing, that often has high cost. Your suggestion is basically "why not just make your books public" (IE more than the contract requires). I don't think that's a meaningful argument against the cost of compliance, because that's not about compliance with this license, but instead one that requires more.
The whole point of contracts/licenses is that they are a deal. What you are suggesting is a very different deal, and we'd deal with it a very different way.
Please do, to the extent their experiences relate to informal licenses.
The lack of a warranty disclaimer isn't an issue in practice; my readme just says "WTFPL, no warranty". The vague rights grant isn't something I've seen as an issue in analogous situations in case law.
More important, to me, is what WTFPL says about my code: I'm not precious about it, I give it to you, I trust you to go do amazing things with it. It is a very humble licence. It says life is too short to get precious about licence wankery. Plus there's the side-effect that small companies and artisan developers can use it, while behemoths like Google won't. These, in my view, are all to the good.
I don't expect you to share that view, but for these reasons, WTFPL is a "good licence" for me. OpenStreetMap thrived for years with a WTFPL-licensed editor (I wrote/maintained it). No-one died, no-one got sued, and OSM became one of only four worldwide geodatabases. The main reason the current editing software isn't WTFPL (I started it but handed over to more talented developers pretty quickly) is that Intel wanted to use it, went "WTF WTFPL", and asked the new maintainer to change it. He did, but tagged the next release idiot-intel-lawyers. I laughed.
(IANAL, though I have spent way too much time over the past 15 years studying licenses and their applicability across different jurisdictions, again principally in connection with OSM and with its - very successful - licence change.)
There have in fact been developers sued (and they lost!) over this very issue in analogous situations, so i'm not sure why you say this.
"my readme just says "WTFPL, no warranty". The vague rights grant isn't something I've seen as an issue in analogous situations in case law."
I'm not sure where you looked. Judges have varied wildly in what they have done in analogous situations.
We are nothing if not data driven. If we didn't have very good data that suggests it is an issue, we wouldn't care.
> I'm consider something more radical like a YUMMY license (you make money, I make money)
There are some projects to create such a license like License Zero
https://licensezero.com/licenses
and there is some discussion on the P2P Foundation:
https://wiki.p2pfoundation.net/Copyfarleft
> It is exactly the same as (CC) non-commercial, except that commons-based commercial use //is// allowed.
Minor pet peeve, I understand that different people use open source differently -- but I would classify the license you're describing as source available. A FOSS compatible license can't carry restrictions on usage.
I'm assuming you already knew that and were just using the looser, more generic definition. Which is not a problem, I just have seen enough people get confused later on when somebody says, "well, technically, this isn't strictly Open Source", so I like to point it out for anyone else who's reading.
Disclaimer: My company Storj is building a distributed Amazon S3 competitor and we are actually partnered with MongoDB. We share revenue with MongoDB for any customers they bring us.
The author or company building the software requires money in exchange for using their software. The revenue acquired through the license is then use to pay for additional development.
Revenue sharing seems to imply some kindness / goodwill agreement.
Paying for a license won’t get you customers but paying for referrals will
Kubernetes was donated to CNCF and there are a lot of Google SWEs working on "removing Google" from the actual project to make it more cloud native.
I really have a hard time picturing the success of CNCF/etc without the big names.
so google should give everything away AND also need to pay to every open source project, besides that smaller player don't?
sorry the world does not work like that. open source means giving and taking, not only taking. google might not be an angel, however restricting them to pay - OPEN SOURCE, non restrictive work - is just silly.
I’d hazard a guess that even the most prolific open source individual contributors use more open source software written by others than they contribute to.
Nobody individually, could really ‘pull their weight’ with respect to contributing back to the community. I doubt most corporations could feasibly contribute back more software than they use, even if they tried.
They do help in some respects: I don't think Kubernetes would be as successful were it not for the big conferences put on by the CNCF. And, of course, lots of companies actually are contributing code back to Kubernetes particularly (and Linux, and some other projects). But there are also a lot of popular open source projects which are used by lots of big companies but don't get either code or money from them.
https://blog.mlab.com/2018/10/mlab-is-becoming-a-part-of-mon...
Making announcement and having all MongoDB Community Software change license the same day for all current major versions (not just new major releases) is not very friendly to users of such software
Many companies which are serious about their software licenses will need to evaluate whenever they can use SSPL, in the meanwhile being left without access to security updates... not a good place to be.
Though I suspect MongoDB would just like such companies to use Commercially Licensed Enterprise Version and not deal with all these Open Source (or not) license change
Advance Submission to OSI and validating it as Open Source License would reduce the concerns of companies looking to use MongoDB Community as they could rely on OSI's legal analyses rather than perform their own
SSPL explicitly states that anybody who wants to offer MongoDB as a service — or really any other software that uses this license — needs to either get a commercial license or open source the service to give back the community.
Looks like a pretty straightforward extension of GPL principles, by replacing the linking of licensed code to remotely calling the licensed code.
It can have a lot of implications for service providers and commercial developers alike, depending on the way commercial licenses will work. (Some DB licenses have pretty stifling clauses, like Oracle's or MS SQL's.)
It was like LGPL in the local case: you alter the library and make it available through the software you link with it, so you have to share the changes you've made to the library, but not the rest of the linked code.
With SSPL, it's like the full GPL in the local case: if you take the licensed software, and link it (via rpc / network) to your other software, you must share not only any changes you've made to the licensed part, but the whole thing that uses it.
Another tricky question is where the border line is. If I write a wrapper that interfaces with MongoDB and repackages its data, then makes them remotely available to the rest of my service, do I only need to share the wrapper? If not, and any network connection that substantially uses an SSPL piece counts, then do I have to share my internal monitoring system? Am I even allowed to connect closed-source data analysis tools to an SSPL database? Etc.
Slight modification makes this accurate to the SSPL: if you take the licensed software, and link it (via rpc / network) to your other software which you use to offer the SSPL licensed software as a service, you must share...
> Another tricky question is where the border line is.
Ultimately the trigger of the SSPL is whether what you offer publicly is the SSPL-licensed software as a service. It doesn't trigger the SSPL if you make MongoDB available as a service to your application internals as long as what you're making available publicly is not "a service the value of which entirely or primarily derives from the value of the Program or modified version..."
As we notice, all that SSPL would require to share is shared in this case.
Then a wholly-owned subsidiary could build various value-added services on top of that MongoDB-compatible thing without a commercial license. This of course would fail if the wrapper would need to be licensed under SSPL, too.
If you offer a service based on the licensed software, and the value of the service being publicly provided entirely or primarily derives from the licensed software, every bit of code -- the clean-room driver, the compatible interface, the admin scripts, UI for management, etc. -- used to offer that service must be made available under the SSPL.
MongoDB submitted this new license for approval by OSI at the same time that they announced that they'd relicensed all of their code. We wish they'd started the process prior to the announcement, but what's done is done. The result, however, is that at this moment, MongoDB is under a non-approved license and therefore IS NOT OPEN SOURCE.
As the license review process only started this morning, there's no way to estimate how long the process will take. There also is no guarantee that the license will be found to obey the Open Source Definition, and therefore no guarantee that it will be approved.
Hopefully this will all be resolved soon, but there are far too many question marks around this license (and therefore also around any software using it) right now. It's probably best to limit your legal risk by not upgrading to an SSPL-licensed MongoDB at this point. The previous AGPL-licensed version should always be available.
On a more practical level: who do you consider be the authority? If the answer is 'nobody' (except yourself) then that makes the term essentially meaningless because there is no standardization, which means that one should stop using that term.
That's just euphemism for "MongoDB is not (certified) Open source". It either is, or isn't; and presently it isn't, for reasons that were entirely under MongoDB's control.
Well, that presupposes that the OSD is the One True Definition of the term "Open Source"; although the OSD is widely accepted and respected, that's a rather bold claim over an English phrase.
> it's NOT OPEN SOURCE anymore
That claim doesn't seem justified at this point. It would be more accurate to say that it is not currently CERTIFIED BY THE OSI as being Open Source -- because the OSI has not yet reviewed the new license. Maybe it will turn out that it is Open Source (as per the OSD), maybe not. Until the license is properly reviewed, we simply don't know.
THAT is the definition of the term "Open Source" for all intents and purposes. Anyone else's is just a subjective opinion.
This definition seems suitable: https://www.merriam-webster.com/dictionary/open-source
Fortunately, most modern dictionaries recognize that languages evolve, using a descriptive approach, updating definitions when needed to reflect how words are actually used.
https://en.wikipedia.org/wiki/Dictionary#Prescriptive_vs._de...
That would be Richard Matthew Stallman, the proverbial OG in this entire field.
Christine Peterson of the Foresight Institute is the "OG" for the term "open source" as applied to software.
1.https://www.gnu.org/philosophy/open-source-misses-the-point....
Going back and saying "Well, RMS might have MEANT open source, so it's actually the original open source" is very subjective and not historically accurate.
I know, you COMPLETELY misunderstood my comment.
> Going back and saying "Well, RMS might have MEANT open source, so it's actually the original open source"
I don't think he meant open-source and I am not saying he did, as free software defines greater freedoms. I am not a big fan of open-source myself, much prefer free software.
What I am actually trying to say, is that "free-software" was the original way to share code and work on it collaboratively for the commons, ie the thing open-source got inspired by.
What I am saying, is that in certain sense, you could say that Ken Thompson has a grandfatherly hand in Linux, despite him technically not. It's a spiritual hand, if you will.
This doesn't work for businesses that need to profit from what they do. Keeping things proprietary, while benefiting from source-available software is impossible if a company has to release their source. Competition goes out the window.
So while RMS has a nice ideal, it doesn't generally apply.
That's a tragedy of the commons, not something any company is entitled to (BSD-style licenses excepted). Enjoying the benefits of an ecosystem while not contributing to it is not a thing to laud.
> So while RMS has a nice ideal, it doesn't generally apply.
...and here we are, with a MongoDB pulling a bait-and-switch on licensing because they want to have their cake and eat it. You shouldn't expect to only get the kudos (and higher adoption rate) that result from your open-source license and not run the risk of someone (possibly a competitor) forking your code. That is the price of admission into the open-source world.
It might not work with certain business models, but that's alright, others would fill their place.
[1] https://en.wikipedia.org/wiki/The_Open_Source_Definition
See https://opensource.org/osd which is what DEFINES open source. The term has been around for 20 years. Your lack of understanding the history doesn't make you any kind of an expert.
No, OSI doesn't own the definition and doesn't get to define open source. Some people agree with that definition, some don't. Nobody has to though. You can't really own what other people think, you can only try to agree on some definition during interaction. No need to pretend there is some universal truth that they just don't know about. It's an agreement, not truth.
And OSI might become irrelevant anyway if it doesn't change in light of recently emerged licenses with more restrictions and doesn't certify them in some way. People will just stick to a handful of popular known licenses and call them open source.
So when it comes to who owns the definition, the definitive answer is the OSI. Anything else is just subjective opinions.
You must not work. Because businesses that do REAL BUSINESS and use Open Source are happy that there is the OSD and approved OSI licenses. That way, we can make real, LEGAL decisions. For individual developers, they might have a different idea of what the definition is, but the actual reference to what defines it is at: https://opensource.org/osd
Reading that will clarify what open source is and isn't. Anything else is just "free software" and should hunt down the FSF for licenses and such. RMS has a very different opinion on software that DOES NOT WORK for large corporations.
I agree, in the legal context of business decisions, OSI has a very specific claim to the term 'open source' and declaring that mongoDB "IS NOT OPEN SOURCE" is a warning directed towards people making business judgements around legal risk.
To everyone else, we use the term 'open source' because we heard someone else say it, and when we write software we say 'oh it will be open source' without getting into the nitty gritty of what license it will use and whether that's OSI approved.
But it doesn't. In the legal context of business decisions conformance to an OSI definition of "Open Source" means exactly nothing and OSI-certified "Open Source" even less than nothing. It doesn't help you with anything and doesn't protect you from anything.
However, what really matters here is whether, if they choose to do that, developers would still be willing to freely contribute to Mongo's code base, and whether companies who use open source software will continue to use their product. Because _that's_ the reason Mongo cares about being "open source". If most developers and organizations recognize the OSI, with their license approval process, as the arbiters of what constitutes an open source license, then that's the reason the OSI's opinion here really counts. Not because they have some divine right to that term, but simply because if they say "after review, we don't consider this project to be open source by our definition of open source", developers and organizations may hesitate to contribute to, or use, this project.
The entire approval process is documented on our website: https://opensource.org/approval
Sorry, who said anything about a "legal" right?
Maybe you're reading too much into the OP's comment.
Mongo submitted an application at OSI, and OSI is saying that currently, they don't consider Mongo open-source, based on their own definition.
Perhaps you're just confused?
Best I can tell, the process page was prepared by a former board member pushing to reform the process and make it transparent. It was and remains aspirational. But those aspirations aren't shared by remaining participants with sway.
The most straightforward summary of the process I received was that discussion proceeds on the mailing list until it reaches consensus, and then it's entirely within the board's discretion what it does or does not do. It was also written repeatedly that the board may not approve professionally drafted, novel, OSD-conformant licenses, for unspecified policy reasons.
As for apps, there's no approval process for an application - only the license applied. And if you use one of the 83 OSI-approved licenses, you can be guaranteed that your software falls under the Open Source Definition, stewarded by the OSI.
So that's how the OSI fits in.
While OSI may have coined the term "open source" as a reaction to the word "free software" in the past, it did not invent the idea of free software. Rather, the term open source was a reaction to the desire for commerical enterprises to avoid saying software was free.
Now it rejects the same argument from developers of software to make a profit, which I find ironic relative to the founding mission.
Previously, Commons Clause was called out in aggressive terms in twitter, rather than seeking to understand the underlying rationale.
Some of my thoughts:
https://medium.com/@michaeldehaan/why-open-source-needs-new-...
I am left to believe OSI views this as a useful political time to self-market, or otherwise sees licenses like this - which intend to fairly compensate software developers - as something that does not promote the interests of those that primarily fund it.
I'm sorry, but we don't need a gatekeeper anymore.
I'm not saying that MongoDB is in the wrong here. The new license is perhaps misguided in that it seems functionally equivalent to the AGPL, but after I read it I think it meets the OSD. However, MongoDB should have spoken to the OSI before switching their license to be sure.
OSI was specifically created to subvert freedoms that the Free Software Foundation protects, so this statement is quite ironic.
In what way is the FSF any more political than the OSI, beyond trying to protect the defined freedoms of free software?
By inserting itself as the only legitimate body to define what "open-source" is, it is by definition engaging in politics, no less than the FSF.
> The OSI is a respected organization that defends basic and non-controversial rights in open source
It is rather assuming that the OSI is "respected" or that it defends "non-controversial rights in open source".
The right to take my code, profit from it and not share back is essentially what the OSI stands for and is thus not respected by me.
The OSI only concerns itself with defining open source and publishing a list of open source licenses. The FSF unquestionably concerns itself with much more.
>The right to take my code, profit from it and not share back is essentially what the OSI stands for and is thus not respected by me.
No, this is what open source stands for. If you don't want to write open source software, then don't. That's your choice. But the right to do exactly this is protected by both the OSI and the FSF, and I doubt you can find another authority which disagrees.
The FSF concerns itself with defining/defending free software, same as OSI does for open-source. If FSF "concerns itself with much more", I assume you would not have a problem listing some of these things.
> No, this is what open source stands for. If you don't want to write open source software, then don't. That's your choice. But the right to do exactly this is protected by both the OSI and the FSF, and I doubt you can find another authority which disagrees.
The difference here is that the OSI was historically created as a response to FSF for this exact purpose, whereas the FSF was primarily created to defend copyleft, later adopting some non-copyleft licenses as well, so the exact reverse of what OSI did.
YOU have asserted that the FSF has "wide-reaching political ambitions", therefore it is upon you to provide evidence for this.
> has wide-reaching political ambitions
I am asking what "political" ambitions does it have, beyond protecting free software.
> Don't just take my word for it
The thing is, you didn't provide any evidence of the "political ambitions" you speak of and so you're quite right, I don't take you word for it, unless you list at least some of these ambitions.
It's not really different in function from https://opensource.org/AdvocateCircle and squarely fails within achieving the goals of free software.
The FSF wants free software to be adopted as widely as possible. The OSI supposedly wants open-source to be as widely adopted as possible, doesn't it?
All of these restrict your freedoms, so that someone else is in control of the program and not the user. This is very much what free software stands for. So in reality, you're disagreeing with the principles of free software themselves.
> surveillance
Directly interferes with you being in control of the program, if it spies on you, violating the principle of free software that the user should be in control of the program and not the other way around.
> upgrade from Windows
So the Free Software Foundation advocating for the adoption of Free Software. Isn't that what it should be doing?
> DRM
DRM, by its very definition, restricts the freedom of the user to run the software in any way they wish, thus violating the free software principles.
None of these imply a "wide-reaching" political agenda.
Nope. You are so very wrong here. The OSI defines open source so that licenses comply with the terms... that's all. They don't have any other agenda, period. Stating so shows a complete lack of understanding OSS and the OSI.
It ignores by who the OSI was co-founded and promoted by, (ESR, O'Reilly etc.) and why, (as a response to FSF to make free software more appealing to corporations for the exact purpose I outlined in my original post).
This is one of those spots where knowledgeable people can disagree, because they're working with a different set of values.
To someone who prefers the Free Software model, OSI was created to subvert freedoms that the FSF wants to preserve. To someone who prefers the Open Source model, OSI preserves freedoms that the FSF is trying to restrict.
To the other 99% of humanity, this particular debate probably sounds a whole lot like the Judean People's Front vs. the People's Front of Judea.
(Edit: s/intelligent/knowledgeable/ -- better choice of words.)
The ability to do so is enshrined in Item 6 of the Open Source Definition: https://opensource.org/osd-annotated
The Open Source Definition provides a single point of reference for what it means for a project to be "open source."
Licenses are submitted for approval by those who wish to prove that the license provides the benefits and freedoms assured by the Open Source Definition and therefore by open source.
Licenses that do not provide each benefit and freedom in that definition are not not approved and are not—literally by definition—open source.
MongoDB recognises the value that a consistent worldwide definition of open source provides to the entire software development ecosystem and is seeking approval for their license to show their support and respect for the definition.
1. "Licences that conform to the OSD are open source". Agreed.
2. "Licences that do not conform to the OSD are not open source". Ok, let's run with that for now.
That is not what you said upthread. You said "MongoDB is under a non-approved license and therefore IS NOT OPEN SOURCE". Nope. Even for those who accept the OSD as the sole definition of open source, you haven't yet established whether MongoDB's new licence is 1 or 2. You cannot categorically (capitally!) say "IS NOT OPEN SOURCE" until you establish that.
Open Source is for corporations to benefit from FOSS without the need to spend exorbitant amounts to acquire such functionality. But corporations are bound by a set of rules to operate, and as such, so should OSS licenses.
If open source were to revert to the old-style, write your own license if you want to, corporations will have a much more difficult time accepting the new software. OSS will probably die a nasty death, and we will go back to tons of proprietary software running the biggest apps.
The OSI is non-political and for you to argue such is silly. The organization has one goal: to make open source easier for business. What political nature can you see in there? Do they ever restrict anyone from making money off their creations? (The answer has always been NO)
So some developers want to make money on the more advanced features of their open source project. Well, if it happens after software has been around a long time (ala Redis) then people are going to complain. It sucks to have to go from a free model to a for-pay model, but I understand the motivations. I don't think any developer should be kept from making money for their work, but if they want to make money off of something AND control the source, DON'T call it open source, call it proprietary because that's what it is. The source is provided, yes, but that doesn't make it open source. To truly be open source it has to abide by the OSD and Commons Clause definitely does not.
So, is it time for new open source licenses? Maybe, but they should be governed by some committee and the OSI exists so why not them? You're arguing that we should move into an anarchist style of releasing open source... The time has come to make money!! Well, again, that's basically what proprietary software is all about.
For me it's actually the definition of open source, having the sources in the open. After you can have more or less restrictive licenses.
If I give you some source code, with the license that you cannot run the software, modify the code or copy or use the code in any way, it follows your definition and is still useless.
But that's not actually the most commonly accepted definition of open source. It means something else, as widely understood by the software community.
> The “open source” label was created at a strategy session held on February 3rd, 1998 in Palo Alto, California. That same month, the OSI was founded.
Microsoft was also aware of the accepted meaning, which is why they introduced their "Shared Source Initiative" back in the old days (note how deviously careful they were about the naming).
Having observed this area for 18 years now, I'll say that gatekeeper (a party which has unwaveringly observed and stuck to delivering the principles of software freedom) is the Free Software Foundation. This is the only reason why users gravitate to "open source" - not its sexy name, but the freedoms such software provides when a user wants to use/apply it.
Back in the day, the founding president of OSI justified VA Linux making the "alexandria" project closed source (the software that ran Sourceforge.net back in the day - back when sourceforge.net was a good citizen). The remains of "alexandria" was forked to form other projects such as GNU savannah, and there was a later fork named GForge IIRC.
https://www.linuxtoday.com/infrastructure/2001082501120prbzc...
There is only one organization that has unwaveringly sought freedoms for users of software. I've firsthand heard it being accused of promoting communism, and sometimes have wondered if it went too far. At least, they haven't wandered in their principles.
The reason I believe in open source software is that it empowers the communities and users behind the software, despite (and sometimes, in spite of) the leadership, nobody controls open source software. If the linux kernel went in a direction I didn't like, either with how they approve code change requests, or by adding in code that I don't like, I can subvert their control over the codebase with my own fork, with blackjack and hookers, and compete, because they ultimentally have no control over their codebase, it belongs to the community.
This should apply to licenses as well, there should be no authority, no gatekeeper, just the community.
Of course, this does kind of require that the people working with license experimentation know enough about law to provably know what they're doing. So perhaps the community might not be as large as might be hoped, as there are limits to what a self-taught not-lawyer can do when it comes to having legal standing.
2. All "open source" really means is that the source code is available in some way/shape/form, with no implication whatsoever made about the license of said code. "Free and open source" on the other hand implies a permissive license.
3. I don't know anything about the MongoDB license before or after these changes, I just despise the tone of this message.
So to recap. OSI is just some random organization with no bearing on what society decides open source is or isn't, and therefore what they say DOES NOT MATTER.
The fact that you've never heard of OSI means we've been doing our job well enough that you've never needed to know about it.
The fact that you've never heard of OSI does NOT mean that it's not legitimate, and frankly, that kind of rhetoric is just silly.
The OSI can claim/define what is wishes to but in practice it has lost authorship of the 'open source' definition.
Just like Google/Xerox/Kleenex/Taser/Bubble Wrap/Dumpster/Escalator/thermos/Chapstick/Frisbee/Photoshop et al.
I agree with this statement but not in the way that you meant it.
Open source is an agreed upon definition for software provided under an OSI or FSF approved license. To state anything else shows that you DON'T understand what open source is.
You see, for corporations to operate they follow a set of rules. Rules designed to keep them on the right side of the law. As such, without the OSD we wouldn't have any rules to understand what open source is. Do you understand that?
Open source isn't just for hobbyist programmers, it's used to run the worlds biggest software platforms.
> but it's not open source unless you know the OSI's definition. > Open source is an agreed upon definition for software provided under an OSI or FSF approved license.
Open source software (by today's standards) existed before the OSI or even the term "Open Source" existed - the creators of BSD *nix, X11 and TeX all chose a liberal, open source license before a cabal around Eric S. Raymond would decide on a definition of Open Source and the term itself. The idea came after the actual thing existed, and the definition after the idea. So it would be weird to call something Open Source that doesn't fit the Open Source Definition (because the latter was conceived together with the term), but it would absolutely be possible for a software/license to be Open Source without knowing about the Open Source Definition, as is the case with BSD, X11, TeX and many Free Software programs.
Next, there is the idea of the Open Source Initiative approving Open Source licenses, which is a good thing because people can trust any OSI-approved license to be an Open Source license. However, not every Open Source license is OSI-approved, because OSI applies additional criteria (e.g. being reusable).
So, yes, it's possible for a license to be Open Source but not OSI approved, when it fits the Open Source Definition but hasn't been submitted, not reviewed, or doesn't meet the additional criteria set forth by the OSI.
The fact that your employer's legal department will mistrust your personal judgement of software fitting the Open Source Definition (for perfectly sensible reasons) doesn't make software not Open Source (any more than a US State can decide to make Pi a rational number or to make dolphins be fish).
So no, it's not some universally-agreed on definition and trying to hawk it as such is dishonest.
Did the FSF & OSI help establish the framework that's allowing us to have this conversation? Yes. Do they get to dictate that conversation in 2018? Nope.
Instead we have created this environment where if you aren't willing to "go all the way" and give people the right to modify/redistribute your code in some permissive way, you are basically pressured to not release your code at all. As a community we would have access to more code bases if this wasn't true. I totally agree that companies should embrace permissive open source licenses, but when that doesn't make sense, I totally think they should embrace non-permissive open source licenses. This is a minority opinion, however.
No.
I think that, in practice, there are very few people who have been around the block a few times, and still see things that way.
As a concrete example, consider the Microsoft Shared Source Initiative. That particular (arguable) boodoggle is the closest I can think of to a real test of whether there's a broad consensus on what "open source" really means. My impression is that most everyone who's looked into it agrees that a couple of the SSI family of licenses are "open source", and the rest are not, and that they generally agree on exactly which ones are and are not.
Code that is available because someone leaked it is also available in some way/shape/form, yet probably doesn't count as "open source".
Not every situation in which second or third party outsiders have access to source code is "open".
We don't have to accept OSI's exact definition with all its quirks (WTF is "technology-neutral"), but the salient features of OSI's definition jive with the widespread understanding that open source allows basically allows free redistribution and use of a program in source code form, with or without modifications.
It might still be open source. It's accurate to say it's not under an OSI approved open source licence, but that's not exactly the same thing.
Open Source is a term coined by the OSI.
No, it's not:
http://www.catb.org/~esr/open-source.html
And even if it was, popular terms reach beyond the persons/organizations that coined them.
Unless it's trademarked, it's just a term all kinds of people use, many of which don't know/care about OSI.
In fact:
https://opensource.org/pressreleases/certified-open-source.p...
But it was done coincidentally with the discussions that ultimately led to the OSI and the OSD.
>> Bruce Perens has applied to register "open source" as a trademark and hold it through Software in the Public Interest. The trademark conditions will be known as the ``Open Source Definition'', essentially the same as the Debian Free Software Guidelines.
Your own reference contains this text, btw.
I think that basically puts to rest the question of who "owns" Open Source.
OSI has "OSI Certified" as a registered trademark (a certification mark).
No it's not. It's some random group of people that usurped the term and tried to take control of the marketing of a larger movement that was already underway and would have happened with or without them.
Hey, that's not true - neither yourself nor OSI or anyone else gets to decide that. If the nice folks at MongoDB continue to release their source code, then it's open source. End of story.
No, it's source available / shared source. “Open” doesn't mean merely visible in the phrase “open source”.
Perhaps you meant to say "is not OSI Certified", because the OSI don't appear to have a right to restrict use of the phrase "open source". See what's on your own website: https://opensource.org/pressreleases/certified-open-source.p...
On the other comments in this thread, even though MongoDB have "submitted" to having the OSI review their license, OSI still aren't capable of restricting anyone's rights on the use of the phrase "open source" including MongoDB's.
I can see your organization tries to make sure that there is an approved set of principles that identify libre/free software which is good. The phrase "open source" has been used in myriad ways since its early days, and not just for software.
I'm a programmer who has written open source since 2000. I would defend you when it comes to the benefits of libre software, but you can't restrict others over using something that you don't legally own.
It's like someone claiming certain software doesn't scale. There is no need to clarify that the author doesn't own the word "scalability".
Op is speaking for the OSI's opinion on whether it's open source or not.
You are really hung up on this. Where did they say they were restricting the use of the phrase? If they said: "MongoDB is not good software" would you be saying they aren't allowed to restrict MongoDB from saying they are good software?
As someone just above said open source for many simply means the source code is open (can be viewed).
Edit: Realizing now that "open source" may be a genericized trademark held by one of their board and we may need to ignore their assertions in this thread.
Therefore, it's not genericized and nobody holds it.
I don't agree, the modified section 13 appears (at least to me) to violate the spirit, if not the letter, of section 9 of the OSD:
> 9. License Must Not Restrict Other Software. [...] For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
The new SSPL requires that all of your server configuration and tools be distributed under the terms of the SSPL. This is so badly worded that it could include your operating system kernel (which, on Linux, would not be possible since GPLv2 is incompatible with this new license).
Also, the scope of "providing a service" isn't limited to network services (which is what you'd think). No, it applies to any service "includ[ing], without limitation [...] 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 Software or modified version.".
I'm sure you can easily come up with some examples whether this concept of "providing a service" will run into strange consequences when your accountant is giving you a download link for MongoDB as well as all of Windows.
Except that, as a non-lawyer developer who generally agrees with the Open Source Definition, "under an OSI-approved license" is my working definition of "open source". I believe the same is true for many others. And, under that definition, if Ms. Brasseur doesn't consider it to be open source (yet), I'm happy to fall in line with that.
She went on to say the magic words that mean so much more to me on this front than any debate about who gets to own the term: "It's probably best to limit your legal risk," and, "at this point." OSI's recommendations are a key part of how I limit my legal risk, and they're working on vetting it as we speak. My best course of action is to sit on my hands and wait for their advice.
Not whether OSI gives it some arbitrary stamp of approval.
What you are describing is "source available", not "open source". And that's a huge difference in practice. https://en.wikipedia.org/wiki/Source-available_software
By which I mean, it's probably fine to think of things that way when you're working in an amateur capacity. If you're working in a non-amateur capacity, thinking about things that way could result in unwittingly exposing yourself to more legal risk than you want.
Seems pretty amateur not to do this.
Oracle or Microsoft or any other copyright holder that didn’t release that is going to be ticked off at you.
There has to be some element of the author wants you to have it.
I know this sounds silly and pedantic. I think there have been organizations that ignored copyright and released stuff they didn’t control the rights to.
You might want to tack on something about the authors want me to have access to this.
Part of why I originally used the term "non-amateur" instead of "professional" when I described people who shouldn't work under that definition is that, while students and maintainers of open source projects might not be getting paid for what they're doing, they still have compelling reasons to be more careful about licensing.
One worst-case scenario for a student might be that some software licensing snafu threatens their academic work, and, by extension, their whole career. And open source project maintainers have an ethical responsibility not to get users of their work into legal hot water.
For those people, falling in line with OSI offers a huge advantage: You can't avoid crossing the software licensing legal tightrope. But, by sticking to working with OSI-approved licenses, you can at least ensure that you're working with a net.
Take for example the NPOSL-3.0:
A variant of the Open Software License 3.0, this license requires that the organization using it is a non-profit and that no revenue is generated from sale of the software, support or services.
https://tldrlegal.com/license/non-profit-open-software-licen...
The source is open, but you can't use it outside of non-profit orgs. It's "Open Source™", it's approved by OSI, and it can still get you in legal trouble.
Personally I never liked the OSI's definition of "open source", and the FSF definition of free software has always felt (for me) to be far more fundamental.
About the discrimination of fields of endeavour, please read the sibling comment to yours. I think you and the grandparent have both misunderstood the license.
Looks like I was wrong. Regarding the DFSG, I think it was necessary (according to Bruce Parens it was the DFSG which convinced Stallman to distribute his four freedoms definition more widely). I think the DFSG is a decent set of guidelines that help avoid legal trouble for Debian by having clear requirements, but I don't think it's a good definition for a movement's primary purpose. In many ways the DFSG and OSD can be seen as re-statements of the four freedoms but without any strong justification for why these particular conditions are necessary for a license to be good -- the four freedoms can be explained by explaining how each freedom is necessary to ensure that users have control over their computers.
For an example of why having strong fundamentals is important, the OSD doesn't really have a stance on DRM -- while the free software definition clearly does (even though it predates any modern concepts of DRM).
DFSG and the OSD are essentially the same thing, having been written both of them by Bruce Perens. Main difference is that Debian doesn't certify licenses: they ship software, so they look at the whole packages, so to speak. OSI only certify licenses, they don't ship software.
As to what the DFSG and OSD do that the FSF four principles don't, I think they are more detailed set of rules one can apply when trying to figure out whether some software is free or not. IMHO, the FSF principles are less operationally useful, despite describing categorically the same set of software.
Right, and I knew this is what you were getting at. I guess my main point is that having a working guideline for acceptable licenses for a distribution makes complete sense (after all of the moral viewpoints have been debated to death you have to ship some code eventually), but using those guidelines as the basis of a movement doesn't really (at least not as much as basing a movement on an a set of ethical axioms). So I would say I favour the DFSG over the OSD purely because of what it is used for and represents, rather than because of the (almost non-existent) differences between the two texts.
But of course, I'm biased since I'm far more in the "free software" camp than I am in the "open source" camp -- purely because I think bringing it back to discussions of ethics is quite important (perhaps more than ever).
Nowhere does the license say that you can't use the code outside non-profit orgs. In fact 17.d says very clearly that if you're not a non-profit, you are allowed to distribute your modified works, but under the original OSL license, not the NPOSL. So you can use, modify it and distribute it, only with a complication in the licensing.
The other amendment the NPOSL adds is where the original OSL gives a grant of patents and a warranty of provenance, and the NPOSL explicitly doesn't, because it's designed for non-profit companies, which have no money, so it's intended to reduce legal exposure.
It's a Free Software license in my opinion, and I bet you a drink that Stallman and the FSF would consider one too, even if they would not recommend using it.
Also note that the license's author is Laurence Rosen, who was General Counsel of the OSI, knows more about software licensing than most people, and who explains the details and rationale of the NPOSL in [1]
[1] https://rosenlaw.com/OSL3.0-explained.htm
If you have any other license that's OSI-certified and you think is non-free according to the principles of the FSF, I'm interested in learning about it.
One thing to take into account, though, is that the OSI is a certification body, and the FSF isn't.
Thhis means that the list of Open Source (according to the OSI) licenses is closed and published on their site. The FSF gives a set of principles and also publishes a list of licenses with some analysis, but the FSF's list is non-exhaustive, nor does it pretend to be. There are infinite potential free licenses that the FSF will not list, because its doesn't count license certification as one of its goals.
That's a seriously polarizing statement that you've made.
While I understand that your argumentation is from points of law, I think you need to realize that the term open source, was pushed by us, the developer community and so I feel that it is us amateurs that have the right to maintain the heart of the law. So, revisiting the heart of the matter:
"We had identified free software as a promising approach to improving software security and reliability and were looking for ways to promote it. Interest in free software was starting to grow outside the programming community, and it was increasingly clear that an opportunity was coming to change the world. However, just how to do this was unclear, and we were groping for strategies." [0]
So, what MongoDB has done is in fact increased (imho) the open source aspect of their offering by attempting to curtail corporate abuse. You should be thanking them.
[0] https://opensource.com/article/18/2/coining-term-open-source...
Do you mean legally? If not, Windows 2000 is open source. If so, then that's what the OSI tries to ensure.
[0]: https://news.microsoft.com/2004/02/12/statement-from-microso...
[1]: https://torrentfreak.com/microsoft-takes-pirated-windows-nt-...
[2]: https://github.com/pustladi/Windows-2000/blob/master/LICENSE
How about I create a license called the ABA (anyone but amazon) license. If you're not Amazon/AWS/a subsidiary, it's just the MIT license. If you are, then you have no rights to use the software. Would you call that an open source license? I wouldn't. An important point (I thought) of open source was that the rules are the same for all, whether you're using it for personal projects or the biggest business on earth, whether you charge money for it or do it for free.
Would you consider Microsoft's Shared Source licenses as being "open source"?
https://en.wikipedia.org/wiki/Shared_Source_Initiative#Restr...
From a licensing compliance/verification perspective, being OSI approved is a good help to guide developers and reduce the effort of processing the applicable terms. For the auditor itself, the OSI stamp is OK but not something critical.
Looking better, we simply don't even use the terms Open Source nor FOSS on our procedures to be inclusive of the commercial/closed 3rd party products.
I appreciate what OSI does, and do value an OSI review and endorsement, but you're seriously reaching here and trying to double-down on it.
Edit:
To be clear, I think the OSD captures what open source is, but OP tried to say "We haven't reviewed it, so it's not open source," not "We haven't reviewed it, so WE don't know it's still open source." Whether or not and when OSI gets around to reviewing something has zero bearing on whether something meets the OSD, even if we are going to assume that's the de facto definition.
I find the idea the VP thinks we need to wait on them to deliver their judgment from on high to be, frankly, offensive. OSI didn't successfully get the trademark on "open source" for a reason, and I can read a license myself.
That bullshit.
If that wasn't the case then Microsoft's Shared Source licenses could also be considered "open source", licenses which completely restricted commercial usage. Thankfully the world did not fall in that trap.
Without a working legal definition, the term "open source" becomes (1) meaningless and (2) a legal minefield.
Basically you've been spoiled by OSI approved licensing because our industry rejected anything else. We could've had a different industry and yes, all those bullshit projects on GitHub without a license are a legal minefield.
The OSI doesn't define what Free/Libre software is, the Free Software Foundation does. The OSI is in charge of the common definition of "Open Source" software, which is accepted outside of non-software or idiosyncratic usages (such as "open source is when I show my references" or "open source is when I derive my conclusion from publicly available information" which is becoming the common definition in the intelligence field.)
It's good when we have a common definition, and discuss that definition rather than the label; it's a waste of time to argue "of course it's organic; it's carbon based!"
One thing that we can both agree on is that more people are familiar with the OSI's definition of "open source" than are familiar with your personal definition, so it's probably more productive to talk about the one more people are familiar with.
MIT is an approved license, so yes.
> is a legal requirement?
No.
You can find the list of approved licenses, along with information about the review and approval process, over at https://opensource.org/licenses
Note, however, if this language starts making its way into contracts, and you're calling something "open source" that isn't actually open source by any standard meanings of the term, then you could be in trouble. But releasing something under a common open source license is prima facie open source, so no problems there.
You don't own the term "open source", and nobody requires your approval for its usage.
"May not carry the OSI trademark or logo" is not the same thing as "is not open source".
This shouldn't be surprising -- it blatantly violates the spirit of section 9 (if not the actual wording). I would be quite shocked if the OSI decides the new license is "open source".
> 9. License Must Not Restrict Other Software. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
I wonder what RMS / the FSF have to say about it...
Please edit your comment to be more accurate.
If you later approve the license, then under your company's own definition of "open source" that means it was always open source, even now, so saying they are not open source when you admit you have not reviewed the license fully yet, is inaccurate, and could very well lead your company into legal liability if your statement turns out to be untrue and mongodb sues for slander.
furthermore: If you later deny the license, that may mean it was always not open source. May.
Your board is not the gatekeeper to the open source community, you are not the controller, authority, or president of the open source community, and the open source community as a whole is the only body that can decide what is "Open Source"
Reading the replies to this thread is like watching hippies fight over the definition of free love.
Open source doesn’t mean anything unless we all agree on one definition, and while idealistic developers might reject the idea of central authorities to uphold the meaning of things now, they forget that it was idealistic developers just like them that realised an agreed definition was required and established the OSI 20 years ago to uphold it.
The OSI is not the man telling you what you can and can’t do - a shared and agreed definition of what open source is clearly benefits all of us, and if you just invent your own definition through ignorance or sheer bloody mindedness then you’re not legally in the wrong, but you could find yourself embarassed, exploited, or otherwise screwed through not understanding what the consensus definition is.
The answer is no, it does not, hence why OSI's statement is inaccurate.
That doesn't mean OSD was bunk or busted. It means we've preserved it for historical relevance, not operative function. Else we'd've revised a great deal more in 20 years.
Instead, in discussion of new license submissions, we routinely see readings of OSD criteria that would exclude the very set of contemporaneous, popular licenses the original Debian Free Software Definition was meant to generalize. For example, that criterion 6 prohibits discrimination against proprietary development as a field of endeavor. OSD isn't a consensus, exactly because it invites so many such readings. There's consensus only insofar as interest groups agree to disagree in OSD terms, as a framework. Some don't. Notably FSF, with its own "definition".
The trouble with open source is that it's a movement, a community idea, not an entry in any formal lexicon, not a fixed point. License terms are only incidental to that movement, that community idea. A zeitgeist and a name. And there's nothing particularly legal about OSD criteria, apart from the expectation they'll be implemented in the legal medium of public license terms. Legal's no magic font of rigor here.
As I'm led to believe, "Free Love" never suffered such discipline as OSI claims now. Free Love was something people were into, stood for, practiced. There was never any organization proffering a definition of Free Love as definitive, official in some sense, and telling folks their particular love didn't count, wasn't free enough. "Free Love" meant something because of how it was used and understood, variously, not how it was defined. It was always contested, and contestable.
Pretending that the OSD, or more accurately OSI approval, represents consensus for new proposals clearly benefits only those who like the particular status quo that a select subset wish to preserve by clout right now. Circa 2002, OSI was approving plenty of licenses in the vein of Mongo's new terms, to welcome smaller businesses challenging more powerful incumbents on behalf of the open approach. Notably RPL and QFPL and Watcom. The permissive-industrial complex hastens to elide or deprecate those approvals now. Even though today very arguably wasn't reachable without accepting strong reciprocal licenses for dual licensors, as a waystation.
From MongoDB, Inc's POV, its fine to run MongoDB in-house for the purposes of supporting some user-facing application. Coinbase would be a good example, they make a consumer product that uses MongoDB as the storage backend.
What is definitely not allowed is selling fully hosted MongoDB instances. E.g. (https://cloud.yandex.ru/docs/mdb/). To do this you will need to open-source all the supporting infra/automation code which will be a deal breaker in many cases.
The real grey area is a service like Parse or Firebase that is built on Mongo but offers a Mongo-like DBaaS. Is it against the SSPL to build a service like that? Or is MongoDB, Inc trying to force everyone to use its MongoDB Stitch service [0]?
it isn't actually I guess google runs their RDS on kubernetes anyway.
I want to issue "View and Internal Use License" for my work. Anyone can view the source code, modify, and use the software for their own benefit as they see fit. Under no circumstances can anyone sell/re-distribute/host the paid version of software or any derivative thereof. Why can't OSI create such a license?
I understand the spirit of OSI is to foster more usage of open source software. I admire it. But probably a LOT of open source software is not getting built in the world because it's not possible for everyone to spend few months/years of their prime without any financial outcome (not even a possibility of it).
I'm a developer who spent 3 FULL days reading up licenses for my indie project [1] that I aim to make some money with. Not even a single license was adequate to protect me from large teams/companies if the software were to become popular. I resorted to only open sourcing a required critical library [2].
The "world" won't let you call your license open source for good reason: it's not open source.
What is that good reason?
Is prohibiting commercialisation of my work not in the spirit of open source? How is my "View and Internal Use License" bad for the open source ecosystem?
Exactly, it's not.
> How is my "View and Internal Use License" bad for the open source ecosystem?
Whether it's bad is a value judgment I can't answer; it's not open source because it forbids redistribution of the source.
> it's not open source because it forbids redistribution of the source.
This can be solved easily. The "View and Internal Use License" can allow redistribution under the same license (verbatim).
Open source is mostly about user rights (making things more confusing, a user is sometimes also a developer!). By restricting the users' right to resell or redistribute the source code of your software, you are effectively making it not open source. If you think an open source license is not in your best interest because of these rights, it'd be totally understandable if you decide not to use one.
> This can be solved easily. The "View and Internal Use License" can allow redistribution under the same license (verbatim).
I think you'll find once you add all the necessary provisions for adding users rights, you'll end up with an open source license :) I'd be wary of saying "this can be solved easily": if you follow any kind of debate about software licenses, proprietary or otherwise, you'll see there's nothing easy about them. Any license that is more complex than "do whatever you want with this" is probably not easy.
Then the discussion Open Source ecosystem needs to have is whether "protecting users' right to resell" is net positive or net negative for the ecosystem. And answer could go either ways but that dialogue needs to happen.
Last major update amongst any of the popular OSS license was in 2007 to AGPL. It's been 11 years and SaaS/Cloud world has changed a lot in this time. Maybe, just maybe, it's time to review and see if we need an additional license that's net positive for the ecosystem.
Just accepting current textbook definitions of Open Source and abiding by it all our life seems too pedantic.
> Then the discussion Open Source ecosystem needs to have is whether "protecting users' right to resell" is net positive
Well, reselling is not the most important aspect; it's a side-effect of unrestricted users' rights. If you restrict users' rights (e.g. you forbid reselling), open source becomes less appealing and not particularly different to Microsoft's Shared Source and similar proprietary-but-you-can-see-the-source licenses.
By the way, "net positive" is a tricky concept. Open source is in my opinion a "net positive", but it involves some trade-offs. Proprietary licenses like the one you seem to favor also have trade-offs.
> it's time to review and see if we need an additional license that's net positive for the ecosystem.
Which ecosystem is that?
To be honest, it seems to me you don't want an open source license. And that's fine. Not sure why you want open source to change its meaning to what you propose (which isn't new either), instead of simply accepting the license you want/need is not open source.
> Is prohibiting commercialisation of my work not in the spirit of open source?
Roughly (IMNHO) there's Stallman/gnu style Free software, which is about user freedoms (freedom to run the software being freedom zero). And the Raymond/cathedral vs bazaar "open source", which is about developer freedom - the freedom to learn from and build (in also a business sense) on other software (mit/bsd/apache etc).
The distinction isn't absolute, a gnu "user" is certainly a developer too - but "open source" isn't as concerned with user freedom - especially freedom zero.
With drm, signed bootloaders and trusted computing - it's easy to see a world where even access to source code and compiler tool chain doesn't guarantee the freedom to run a) binary software from a vendor, nor b) software binaries you make yourself.
So gnu/free software isn't primarily about preventing commercialization (see eg: walnut creek software and their CD rom/floppy shipping business) - it's about maintaining user freedom.
And many believe the only real way to legally protect end user freedoms is through means like gpl/AGPL.
In a sense gnu is pessimistic free software (what if I can't (legally) access a c compiler and kernel header files - how can I even build a new printer driver then?) - open source is more libertarian/free market optimistic: go ahead build a firewall appliance from this distribution and lock your customers out - there's plenty other folk that will keep sharing and caring. And if you develop a cool, high performance userspace network stack we'd love for you to share - but do as you please)
Neither is about preventing commercialization - both are about securing access and openness. Now, they do work against certain types of legal mechanisms that are associated with commercialization, like patents and copyright.
Lastly,in a world with copyright, "source available" can be very dangerous to developers (this include text books with unclear licenses for code examples). What happens when I copy your btree implementation? You did show it to me. Was I supposed to forget about it?).
Instead of switching the license, they should have gone after companies that were abusing the terms of GNU AGPLv3 license.
There is literally no reason I’d use MongoDB anymore over any of its better FOSS competitors.
I've no idea if this is easy or not but it could be used as a negotiation tactic (I'm guessing here) to negotiate a license deal.
> "Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate."
I don't see how to reconcile this with the new section 13, which seems to say exactly the opposite. What does this section mean, now that section 13 was completely changed?
> it has now submitted the SSPL for approval from the Open Source Initiative
IANAL but I don't see how it satisfies part 9 of the OSI Definition, or the DFSG. As DannyBee already mentioned, it's also incompatible with other existing open-source licenses. Why do they want to continue calling it "open source"? It sounds like they really just want to be a proprietary database.
> For virtually all regular users who are currently using the community server, nothing changes because the changes to the license don’t apply to them.
Really? It's written in a way that sounds like it captures all users under the same umbrella as resellers. If I wrote a data analysis web app that happened to use MongoDB (as one of my previous employers did), isn't that a case of adding "user interfaces" (and "storage software and hosting software") for it, meaning I'd need to provide source code for "all such that a user could run an instance of the service using the Service Source Code you make available"?
I can't find any license pricing info on the MongoDB webpage, but some googling turned up a whitepaper that puts MongoDB licensing at around $11,000 per server per year. That basically means MongoDB's own "cloud" services are the only game in town. ("No, Mr Bond, I expect you to die.")
That means there's a single provider of this API, and you can't afford to run your own server, so it's essentially cloud-only, and it might not be legally compatible with other open-source software you want to use anyway. That's a whole lot of risk you're asking me to take on. Is MongoDB so much better than any free database, for any new users, that it's worth this risk?
They want to charge money and have control as a proprietary database. But they want to keep a label "open source" purely for marketing purposes.
---
To the article: It sounds like the SSPL will eventually be OSI-OSS, but I wonder if they couldn't have worked with GNU to create a new version of the AGPL. Granted, GNU might take exception to the idea of "oka you don't have to share the code, you just have to pay us" portion.
Does that mean that MongoDB is now infringing on FSF copyright of the license text itself?
BTW, check out the "What specifically is different between the GPL and this new license and what will it be called?" section of the FAQ:
https://www.mongodb.com/licensing/server-side-public-license...
I don't see how the distinction makes a difference here, both have the same clause about changing not being allowed.
Still, I wonder where MongoDB actually wants the boundary drawn. Anyone that tries to offer the MongoDB protocol as a service using the official code? Or is it if I provide a database interface to a MongoDB instance? Or is it only if the actual MongoDB interface from the MongoDB server is provided? I haven't read their new license but I have a strong feeling that it won't be 100% clear yet.
I believe there is also case law that supports the legality of reverse engineering for interoperabilility as well. I wonder if that has implications on this.
Not simply "if you write a new query parser and link it into our db, any SaaS customers must get the modifications so the can continue running the service for themselves if you go under.", but more "if manage to extract value by hosting this software, you must give us a cut or all your code".
I guess there'll be a fork, like with matiadb/mysql?
actual license: https://www.mongodb.com/licensing/server-side-public-license
Typically, TC didn’t bother to even link to either. :/
I even didn't know it was AGPL until now (I'm not MongoDB user). Because so many people seem to use it as if it is Apache License or something free of charge. I haven't see any warnings on AGPL and its implications in MongoDB tutorials on the internet.
Well, that isn't true any more. If you start selling MongoDB functionality as a service, you now have obligations, even if you didn't modify it.
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 Software 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.
As for what they're trying to accomplish... it sounds like a slightly different version of the AGPL (in spirit), and while I'm not the biggest fan of the AGPL and similar licenses, it's not the abomination that the Common Clause stuff was. This seems to just be saying "if you want to offer a MDaaS (MongoDb as a Service), you have to release the source code to the entire service". It's probably not a license I'd choose, but it's not exactly unreasonable.
Disclaimer: I haven't read the entire license yet, so my comments above are based on other people's summaries / the text of the article linked above. My opinion is subject to change once I've had time to digest this fully.
I also think that SSPL can be very helpful if you want to open source your SaaS. Most of the startups that I consult with are not interested in open sourcing their actual SaaS software since they fear being ripped off.
So, what happens is that they end up not taking the benefit of open source. With SSPL these SaaS companies will be able to open source their SaaS is software to manage SaaS — without the fear of being misused by competition.
If the competition just takes their free software and makes money with SaaS that hurts them instead of helping them since you can't make sure that other SaaS players will actually contribute back to the software.
With SSPL, we get a safety net — companies either won't use it as a SaaS, will pay to use it as a SaaS i.e. they'll help pay for open source software support which is a very good business model and if not that, then they'll have to open source their SaaS as well.
As a non-lawyer developer, it feels like GPL. GPL code that you fork should remain GPL. Similarly, if SSPL code you use as a SaaS then you should keep your SaaS as SSPL and open source it as well.
Peace! ️
I assume that an online game that uses Mongo to store player data clearly does not derive its value mostly from the database, but is the value of a PaaS built on Mongo, with an elaborate UI and management services derived primarily from the value of Mongo or not? Is the value of an online recipe management service? In both cases I can see compelling arguments in either direction.
One could argue that if the value derived primarily from the DB, then very little software would need to be added and open sourcing it would not be an issue. That vendors don't open source their software shows that they believe its value does not come primarily from Mongo, and so they would be able to continue using it under the new license, defeating Mongo's purpose.
I was curious if exceptions were allowed under licenses like these. For example, if a company releases a GPL licensed product, (or SSPL etc) and wishes to create another product/service that they don't wish to open source, but it's based on the GPL/SSPL codebase. Could they make exceptions or separate license agreements to go around their own license choice? Would it be different if it were a third party they would like to give this exception to?
In similar regard, would MongoDB have to prove that they are paying full licenses/Enterprise agreements to themselves to be able to run Atlas (their own cloud offering) and not open source Atlas? Or is there a self exclusion allowed etc? Or would they just sell themselves the licenses for $0.01 cent to get around the requirement?
Truly interested in this question.
Edit - and to clarify, not if the exception is stated directly in the license like a new modified MIT etc, but inherent to the existing popular OSS licenses.
The key is where you say "wishes to create another product/service that they don't wish to open source, but it's based on the GPL/SSPL codebase". You're not creating it based on the GPL codebase, you're creating it on the codebase you own. The fact you've previously licensed it under X, Y or Z licenses is irrelevant; you can always release it again, in whole or in part, with whatever license you like. (But of course, whatever you released under the GPL is still out there, under the GPL; there's no take backs!) And you can also, of course, use it yourself however you like.
The key is ownership. If you own the copyright on the code, you're fine. If you don't, you must adhere strictly to the license which the actual owners granted you. To the extent that MongoDB (the company) owns the copyright on all the code, they're free to use it how they like, and release it as often as they like under whatever licenses they like.
The piece in the puzzle that allows MongoDB Inc. to act like that is the Contributor Agreement [1] which makes any contributor assign copyright of contributions to MongoDB Inc. This way MongoDB Inc. is has all rights on the source code and can licence it to anyone under any licence.
AGPL style licenses impose restrictions on usage, thus violating freedom 0 in the Free Software’s definition or Open Source’s rule 6.
AGPL should have never been allowed, precisely because it opens the door for commercial entities to eat their cake and have it too, being the kind of license that can be effectively used to disallow commercial products built on top.
In my opinion your own modifications that are never distributed (by the copyright definition) represents mere usage. And we’re software developers after all, personally I patch most of the libraries I end up using and some patches I may contribute back, but I’m definitely not required by any license.
“Open Source” and “Free Software” have great sex appeal, I get it, but if you can’t deal with competitors benefiting from your work, which is the whole point of such an endeavor, then don’t do FOSS.
Go proprietary and be honest about it.
No, not in the commonly understood sense of "usage" as "field of endeavor". I understand what you're getting at but anybody can use AGPL'd software for anything. They just need to publish any modifications they make to said AGPL'd software. It's a restriction, but not on "usage". Such a restriction would be something like "you can't use this in the nuclear industry" or "you can't sell this".
Writing a script that interacts with said software to enhance or modify its behavior is as easy as clicking an UI button and I don't see a difference.
Also the "understood sense" is irrelevant. Usage is whatever you do with it that's not distribution in the sense defined by the copyright law.
The genius of the GPL licenses has been that they are just copyright licenses handling distribution, but that don't impose any restriction on usage. This was by design. Here's Richard Stallman's own take on "freedom 0": https://www.gnu.org/philosophy/programs-must-not-limit-freed...
> "They just need to publish any modifications they make to said AGPL'd software"
N.B. that's in fact a huge restriction, being a matter of costs too, because "publishing any modifications" costs both time and money.
> Usage is whatever you do with it that's not distribution in the sense defined by the copyright law.
That is the tricky part. A video streaming site is considered distribution by many copyright laws. There was a time where simply using a website was not considered distribution, but then scope of copyright was extended and concepts like "public performance" and "making available to the public" was applied to works provided through web services.
GPLv3 however gives an additional permission that allow "interaction with a user through a computer network", even if copyright law would forbid it.
Personally I agree with copyleft licenses for as long as they are just restricting distribution as defined by copyright law. This because IMO there needs to be a clear, lawful boundary for what FOSS licenses can and cannot restrict.
Will look more into it.
Google revealed one relevant article:
According to C|net their vice president of marketing said in 2002: "There were people misusing the GPL, using our server tightly coupled with their applications, claiming the GPL didn't apply because the client libraries weren't under the GPL, they were under the LGPL," [1]
According to the article, MySQL decided to sort out this issue by changing the license of the client libraries from LGPL to GPL.
[1] https://www.cnet.com/news/mysql-addresses-open-source-licens...
No need to thank me but I pressed the fork button again just to make your prediction come true.
- Atlas to deploy - Stitch to run serverless - Chart for BI
So they basically want to protected their leverage, which make sense to me.
> 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
Would greatly appreciate it if someone could give an example of a MongoDB service company and what parts of their proprietary code they would have to release if they opted not to buy a commercial license .
It's as broad as it can be to make it essentially impossible to comply with and force you to use the commercial license. You can't release the Linux source under SSPL, but the OS would almost certainly qualify under this clause (but IANAL). In the definitions it seems to exclude the kernel and "System Libraries" but only if unmodified, it's still a but of a minefield.
Probably the big public cloud providers in China (Alibaba etc) as well.
That's how open source works. Isn't it?
(this btw, should not be interpreted as bad mouthing them; I'm merely pointing out a communication problem between two cultures).
Alibaba & Tencent have been offering managed MongoDB offerings for a while but MongoDB, Inc. has historically not made any major investment in its own managed offering (Atlas) for that market.
This license shift is aimed squarely at AWS, who is rumored to be ready to announce/release their own MongoDB-compatible service at AWS re:Invent next month.
If I want to use MongoDB in my ecommerce app no worries. If I want to simply use MongoDB offer some minimal improvement or added functionality, call it ZongoDB and sell subscriptions... not so fine?
No, because such a license would - by definition - not be an Open Source license. That's basically what the Common Clause says, but a license with that clause attached isn't OSS.
If your web app uses MongoDB (or any SSPL licensed software) to provide a value that is not substantially MongoDB itself, you are not making the software available as a service. If your code facilitates making MongoDB's features available to other users, you are providing MongoDB as a service and are obligated to make all that code available under the SSPL.
No. Open Source always implies freedom to use for any purpose. There might strings attached such as the need to open-source modifications as well, but if usage itself isn't free, it's not Open Source.
Hopefully this spurs some movement in supporting open database communities better. PostgreSQL and RethinkDB being two that come to the front of my mind.
Would this apply to independent implementations compatible with MongoDB?
I don't get why any business would want to scare their new users with a license like the AGPL that I would argue is explicitly designed to create legal uncertainty like that and popular with companies like Mongo primarily for that reason (as opposed to some strong freedom related moral arguments). Inventing your own license because the AGPL is giving your users to much freedom sounds rather desperate (not to mention misguided).
Changing the license to Apache 2.0 might actually make them much more attractive as an acquisition target for any of the big tech companies out there looking to add something like mongo to their portfolio. I'd argue AGPL is actually an obstacle for most of the bigger companies out there that have existing business relations with their customers based on more business friendly licenses.
It would also enable lots of people to experiment with using mongo without legal worries and thus enable them to refocus their company around actually creating value for their paying customers without alienating the vast majority of non paying users with complicated licensing options.
Companies like Elastic (which recently did their IPO) are having plenty of success with using the Apache 2.0 license without compromising on commercial success. Their developer ecosystem includes lots of outsiders in the apache community, the academic community, and users. The reason they are doing pretty OK is that they have a decent monetization strategy that involves delivering actual value to their customers: stuff their users want and are willing to pay for. Stuff like proprietary add-ons (e.g. machine learning) on top of what they ship for free, good support, training, cloud based hosting, consulting, etc. We use their hosted Elastic cloud and I'd argue it is pretty good value.
This is just another highlight of the cloud vendors making it very difficult to build a business based on open source infrastructure software. Either you pick an infectious license (like AGPL) or you go open core. Otherwise, if your project gets popular, the cloud providers will offer it as a service, which will eat into your revenue.
One irritating feature of Mongo (and I suppose other db's too; orientdb does this) is that once it grabs disk space, it never lets it go. It'll reuse that space, but the OS will never see it again. (EG: If I store 10GB of stuff, and delete 9GB of it, the OS still sees all 10GB of disk used).
Does rethink do this as well?
The correct term is forked. They forked the agpl and made modifications.
Is that the same as modify and/or improve?
TL;DR: while vmbrasseur of OSI does say "what's done is done" in comments here, I think the OSI shouldn't accept the proposal as submitted, and should demand that licenses submitted them to have gone through a prior public drafting process. This is particularly important for licenses whose stated goal is to make fundamental changes to how copyleft works. GPLv3 and (even better) copyleft-next made this the standard of how new license drafts are done, and we should follow that standard.
Now that the license has been submitted, folks can now analyse and discuss it, openly. Any decision on the license will spring from those discussions and the related actions (should any be needed) that MongoDB takes based on the feedback they receive.
The proper place for that feedback is on the discussion thread on the review mailing list. Statements on blogs and comments on Hacker News are good for helping to frame that feedback, but aren't well placed to be included in a cohesive conversation.
The risk being that if someone does a better job than MongoDB at creating features for mongoDB they might loose their product as well playing that card.