Things just got serious in open source land. Despite the occasional Commons Clause or Fair Source licensing attempt to change the meaning of the words "open source" to include "the right for a private company to make money from its open source efforts," we've stuck to the Open Source Definition, and it has served us well. Open source communities have become the center of the innovation universe, giving us exceptional code like Linux, Kubernetes, Apache Kafka, and more.
Yet, there's a growing unease that the grand bargain of open source—share and contribute—is being supplanted in the cloud. This is the same unease that prompted the Free Software Foundation to update the GPL in 2007 to close the so-called "ASP loophole." Resulting in the awkwardly named Affero GPL (or AGPL), the license drafters hoped to secure the promise of free software; namely, that those who modify and distribute AGPL'd software would, in turn, contribute back their changes, thereby benefiting all.
It hasn't worked.
So Tuesday MongoDB announced that it is seeking to work with the Open Source Initiative to make its new Server Side Public License an official OSI-approved license, one that fills out the pantheon of open source licenses, one that will finally make open source function in a cloud context.
It's an open question, however, whether it will work.
A question of code or money?
To be clear, this isn't just about code. It should be, but it's not. MongoDB's press release is riddled with mentions of money: The $300 million it has invested in developing the code. The ability to buy one's way out of open source obligations to contribute back. And, of course, the ability of rapacious "cloud vendors who have not developed the software to capture all of the value while contributing little back to the community," the release mentioned.
SEE: Open source vs. proprietary software: A look at the pros and cons (Tech Pro Research)
To the extent this move is about a single company's earnest efforts to make riches from its repositories, it's not very interesting. Yes, I've worked for a variety of open source companies for nearly 20 years (including MongoDB) and, yes, I've been in the shoes of wanting desperately to make more money from code that people loved but wouldn't pay for. But this is actually a really terrible reason for effectively making open source proprietary, as Redis Labs and others have with non-free licenses.
I'm much more interested in MongoDB CTO and co-founder Eliot Horowitz's argument that the company is "in a unique position to lead on an issue impacting many organizations." Take away the "organizations" part, and MongoDB is in a position to use its impressive heft to reshape open source in the cloud era.
Now that is worth doing, though only if this gains the imprimatur of the OSI. If it's not officially open source, it has no chance of becoming a true industry project, and should die. Quickly.
But would it work?
There is, of course, the very real question, as posed by Gordon Haff, of whether it will do anything to fix the "(real) business model issues associated with open source," or how it fits into the "general trend toward permissive licensing." That trend toward Apache-style licensing, and away from GPL-style licensing, is very real and has been underway for a decade.
There is the additional risk, also called out by Haff, that tightening the screws on AGPL with SSPL will continue to make it a "big barrier to adoption." Developers favor the restriction-free Apache-style licensing and have (Linux excepted) tended to eschew GPL-style licensing. Haff's concerns are spot on.
SEE: Software licensing policy (Tech Pro Research)
And yet...I like the idea of greater collaboration around the infrastructure necessary to pull off a great cloud service. Again, if we think about community beyond any particular company for a minute, wouldn't it be fantastic to have GE and Amazon and MongoDB and IBM and Safeway and [name your company] collectively innovating around that infrastructure?
The SSPL modifies the AGPL by stipulating: "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." That is, if you offer MySQL or some other project licensed under the SSPL as an RDS-like service, you agree to open source the infrastructure code used to deliver that service.
Does it apply to someone using MongoDB (or other code under the SSPL) to deliver an online grocery delivery service? No. Does it apply to someone creating a hosted analytics service? Nope. It simply refers to someone offering an open source product as a standalone service, whether that open source software is primarily developed by a company or a community.
The next Linux?
As much as we may want to cast this as a corporate profit-hoarding, I think it has the opportunity to be more. For common infrastructure like Linux, we benefit by working together on that code. As interesting as a particular database might be, the next generation of cloud innovation is really about how to run like a web giant. Things like Kubernetes have kickstarted that revolution, but imagine how much more dramatically we could accelerate if companies as diverse as Amazon Web Services, Apple, and Target worked together on the infrastructure used to deliver cloud services.
This might not work. It's very possible that cloud providers and other corporations would simply steer clear of building cloud services for open source projects, and that would be a net loss for the industry. But if the next Linux emerged from something as simple as the SSPL, well, that would be a very good thing.
- 20 quick tips to make Linux networking easier (free PDF) (TechRepublic)
- Microsoft PowerShell now available on Linux as an Ubuntu snap (ZDNet)
- GitHub: A cheat sheet (TechRepublic)
- One million Linux and open-source software classes taken (ZDNet)
- Happy birthday open source: A look back at the software that's pushing tech forward (TechRepublic)
Matt is currently head of the developer ecosystem at Adobe. The views expressed are his own, not those of his employer.
Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.