In 2019, multiple open source companies changed course—is it the right move?

Free and open source software enables the world as we know it in 2019. From Web servers to kiosks to the big data algorithms mining your Facebook feed, nearly every computer system you interact with runs, at least in part, on free software. And in the larger tech industry, free software has given rise to a galaxy of startups and enabled the largest software acquisition in the history of the world.

Free software is a gift, a gift that made the world as we know it possible. And from the start, it seemed like an astounding gift to give. So astounding in fact that it initially made businesses unaccustomed to this kind of generosity uncomfortable. These companies weren't unwilling to use free software, it was simply too radical and by extension too political. It had to be renamed: "open source."

Once that happened, open source software took over the world.

Recently, though, there's been a disturbance in the open source force. Within the last year, companies like Redis Labs, MongoDB, and Confluent all changed their software licenses, moving away from open source licenses to more restrictive terms that limit what can be done with the software, making it no longer open source software.

The problem, argue Redis Labs, MongoDB and others, is a more modern tech trend: hosted software services. Also known as, "the cloud." Also known as Amazon AWS.

Amazon, for its part, came out swinging, releasing its own version of the code behind Elastic Search this spring in response to licensing changes at Elastic (the company behind Elastic Search). And besides a new trademark dispute over Amazon's naming convention, Elastic has a very different response from that of MongoDB and Redis—it hasn't said a word in protest.

Unrelated to the matter at hand: The swag game is strong at MondoDB.

Credit: MongoDB on Facebook

Cloud burst

MongoDB the company is built around the open source "NoSQL" database of the same name. MongoDB's database is useful for storing unstructured data, for example images, which it can handle just as well as it handles more traditional data types. Data is stored in JSON-like documents rather than the columns and rows of a relational database. Since there's no structured tables there's no "structured query language" for working with the data, hence the term "NoSQL."

MongoDB is not the only NoSQL database out there, but it's one of the most widely used. According to industry aggregator, DB Engines, MongoDB is the fifth most popular database, with everyone from Google to Code Academy to Foursquare using MongoDB.

MongoDB is also leading the charge to create a new kind of open source license, which CTO Eliot Horowitz believes is necessary to protect open source software businesses as computing moves into the new world of the cloud.

The cloud, argue Horowitz and others, requires the open source community to re-think and possibly update open source licenses to "deal with new challenges in a new environment." The challenges are, essentially, AWS, Google Cloud and Microsoft Azure, which are all capable of taking open source software, wrapping it up as a service, and reselling it. The problem with AWS or Azure wrapping up MongoDB and offering it as part of a software as a service (SaaS) is that it then competes with MongoDB's own cloud-based SaaS—MongoDB Atlas. What's threatened then is not MongoDB's source code, but MongoDB's own SaaS derived from that source code, and that happens to be the company's chief source of revenue.

To combat the potential threat to its bottom line, MongoDB has moved from the GNU General Public License (GPL) to what it calls the Server Side Public License, or SSPL. The SSPL says, in essence, you can do anything you want with this software, except use it to build something that competes with MongoDB Atlas.

Originally MongoDB submitted the SSPL to the Open Source Initiative (OSI), the organization that oversees and approves new open source licenses. But after seeing the writing on the wall—discussion on the OSI mailing lists, combined with the wording of the license made it unlikely the SSPL would ever be approved by the OSI—MongoDB withdrew the SSPL from consideration earlier this year. The SSPL is not an open source license and it never will be.

To understand why, it helps to realize that MongoDB is not the first open source business to run into this situation. In fact, part of this problem—companies taking software, using it as they please, and contributing nothing back to the open source community—is the entire reason open source software exists at all.

Open source licenses vary, but the gist since the 1998 founding of OSI has generally been as follows: you can take this code and do what you want with it, but you can't make the code proprietary, and if you use it in another project, then that project can't be proprietary either. These licenses were written this way to prevent companies from taking open source code, using it in their own code, and not sharing any of that work back to the original project.

But the concept of SaaS didn't exist two decades ago. And today, Horowitz argues that wrapping a piece of code in a SaaS offering is the modern equivalent of using it in an application.

It is a novel argument, but it's in defense of a very old problem that goes well beyond licensing. It's a problem that goes all the back to the beginning of free software long before the OSI—how do you make money off software if you give it away for free?

One traditional answer has been that you sell services around your open source software. But for Horowitz that's not good enough. "Monetizing open source with support contracts has never been a great business model," he tells Ars. Red Hat would likely disagree, but Horowitz believes that more protective licenses would bring more venture capital investment and spawn more software businesses based on the open model MongoDB has used. "We're unique," he says, "I want us to be less unique."

He may be correct. A more protective license could induce more venture capital investment because there's (arguably) a greater likelihood of return on their investment. But if that capital did come, it wouldn't be investing in open source because that kind of restriction on the software means it no longer fits the definition of open source.

The counter argument

Quite a few open source advocates have already made the counter argument to what MongoDB's Horowitz believes. The current set of licenses are fine, others say, it's the business models that need work.

Bruce Perens, co-author of the original open source definition, says the SSPL is incompatible with the OSI's open source definition number nine, which says that the "license must not restrict other software." Since the SSPL forces any SaaS software that is aggregated with the covered software, but not a derivative of it, to nevertheless be open source, it fails this test. "I wrote number nine into the OSD to prohibit exactly this sort of conduct," says Perens. "The text is really clear."

MongoDB is far from the only one complaining that the cloud is raining on its profits. Redis Labs, another data storage company, was the first to sound the alarm about cloud providers threatening its business, and Redis Labs may have the better solution in the end. Redis Labs initially changed its license to include something called the Common Clause sub-license, which forbids anyone from selling any software it covers. Software licensed with the Common Clause is not, by anyone's definition, open source, which Redis Labs acknowledged. It has never described those portions of its software as open source.

But this spring, Redis Labs made yet another licensing change—in essence dropping all pretense of being open source software and adopting a homegrown proprietary license for some of its modules. To be clear, most of Redis is governed by the three-clause BSD license, but some modules are not, namely RedisJSON, RedisSearch, RedisGraph, RedisML and RedisBloom.

The license Redis Labs applies to these modules says that while users can view and modify the code or use it in their applications, it restricts which types of applications they can build. With Redis Labs' new license, you are not free to build anything you want. You cannot build database products, a caching engine, a processing engine, a search engine, an indexing engine or any kinds of ML or AI derived serving engine. You cannot in other words use Redis Labs' code to compete with Redis Labs. This violates one of the core tenets of open source licensing—that there be no restrictions on derivative software.

Unfortunately for both Redis Labs and MongoDB, it doesn't make sense to simultaneously say that you are open source and that only you should profit from your open source software. There is a business model where that does make sense: proprietary software.

That's a path that Elastic.co has hewed for some time. While part of the problem here is that there is no playbook set in stone yet, some companies have managed to prosper with both open source and proprietary code. Elastic is one such example; it has faced the exact competition from AWS and soldiered on.

Not only has Amazon for years offered Elasticsearch on AWS (ostensibly competing with Elastic's own offerings), Amazon recently packaged up its own version of the Elasticsearch codebase, extending it to offer for free several of the services Elastic hasn't released as open source. Elastic's response has been little more than the corporate equivalent of a shrug.

Redis Labs' change of course didn't prevent the company from recently reaching a user milestone.

Credit: Redis Labs on Facebook

Lessons from history

Why does MongoDB want to be open source at all? After all, there is no shortage of very successful proprietary software. Why not embrace that path and move on?

Horowitz told Ars he believes "that open source results in better systems software, especially databases," going on to cite security and community as advantages of remaining open source. He's right about both of those—more eyes on the software means fewer bugs, better security.

But looking at the open source definition again, it's clear that Horowitz is missing one key component that's built into to every open source license—generosity.

Open source does not limit what you can do with the software ever. Full stop. This may well be the chief reason for the concept's success; it's certainly what made it palatable to large businesses in the first place.

Generosity of this kind is how you grow a community, the cornerstone on which any successful open source project is built. By allowing the widest possible range of users to use your software, you get the biggest possible community. More eyes on bugs, more people fixing them. That community is what turns into momentum. That momentum becomes market share. Sometimes market share becomes profit, but that's not ultimately a promise of open source.

As Perens puts it, "we have to draw a line between 'open source' and the right to make money with open source. The open source definition allows, but does not support, your right to make money. We're not going to change the rules because you can make money better that way."

To its credit, Horowitz and MongoDB seem to have come around to this point for view, or at least accepted the inevitability of it when they withdrew the SSPL from consideration as an OSI-approved license. Just because you build it and they come, does not mean massive profit.

In fact, if you build it and they come and then you take it away, it might be worse than if you'd never built it.

Redis Labs' move away from open source comes after it reaped all the benefits of open source—community support, wide adoption, and code contributions from a widespread sources chief among those benefits. To put it bluntly, Redis Labs angered the community.

When free software developers get mad, they get forking, and there is indeed a fork of Redis, GoodFORM. GoodFORM takes the re-licensed Redis modules as they were prior to the license change, and this project will maintain them for Debian, Fedora, and other Linux distros that cannot ship proprietary software.

The unintended consequence of Redis Labs' new license is that anyone wanting to use a full and open source version of Redis will have to use GoodFORM, not Redis.

Individual developers might not much care, but large companies looking to use open source software aren't so cavalier. For them, it usually comes down to a choice—either use clearly open source software with an OSI approved license, or call the lawyers. And no one ever wants to call the lawyers just to install a piece of software.

Perens tells Ars that this was one of the key motivations behind the initial open source definition (originally written for the Debian project). "The open source definition means that you shouldn't need a lawyer just to be a user," says Perns. "And one of the ways we do that is minimizing the legal load."

Redis Labs' new license puts companies in the position of needing a lawyer, so GoodFORM becomes the more logical choice. This also may hint at why MongoDB wanted to remain open source in the end.

Historically, other open source projects which have changed to closed source licenses have not fared well. The Xfree86 project was the defacto standard for running X Windows for most of the 1990s, up through the early 2000s. In 2004, Xfree86 began shipping code that the Free Software Foundation felt was counter to the GPL. The downstream operating systems using Xfree86 decided that was unacceptable and a fork, X.org, was born. Today, X.org occupies the place Xfree86 once did and Xfree86 is abandoned.

Other examples are easy to find: LibreOffice forked from OpenOffice, MariaDB came out of license changes in MySQL, Wireshark came out of Ethereal, and the list goes on. The key thing to note in all these situations is not just that the forks happened, but that the new projects took with them the developers, the community, and the momentum that sustains open source software over the long haul. Lose the goodwill of the open source community, and it can be vicious in exacting its revenge. It's also efficient in doing so: Xfree86 was effectively dead six months after X.org began; OpenOffice disappeared into irrelevancy similarly quickly.

The overwhelming lesson of open source history is that once you are open source, it's very unlikely you will change course and survive.

What makes open source work: Generosity

If open source history teaches that there is no going back, it's worth considering why.

Beanbooks, a little project spun out of Linux computer manufacturer System76, is a perfect example of what Perens sees as an ideal open source software scenario. In The emerging economic paradigm of Open Source, Perens argues that a company's non-differentiating software is its best scenario for open source software. That is, open source provides the infrastructure of the business, not the core.

To put it another way, Beanbooks was not System76's profit center, but it is an enabling technology for System76's profit center—which remains building Linux-based computers.

However, despite being a perfect candidate for an open source license, Beanbooks is not open source. Why?

System76 sells a hosted version of Beanbooks, a SaaS, and at the time the company was worried that a larger company would come along, take the GPL code, essentially clone Beanbooks, and get all the profit from System76's investment. So System76 founder Carl Richell says he can empathize with companies like MongoDB and Redis Labs, but he has already been down the worry-about-someone-stealing-your-code-for-competing-SaaS road and regrets it.

"Our concern was that someone would wrap up the software and we would lose all our investment," Richell told Ars. He says System76 wanted something like patent protection for a few years, but that "ended up hurting us, hurting the platform, and we shouldn't have had those concerns."

While the SaaS version of Beanbooks looks to be fine, the available code does not get updates and is, from a free software perspective, fairly useless. The Github page is a ghost town. There's no development, no community. Beanbooks the service carries on, but it does so without a community contributing ideas, code, and everything else vibrant open source projects have. Richell thinks Beanbooks might have avoided its fate if it had a GPL or similar license from the beginning.

"If it was good enough that someone wanted it, that's great," says Richell. The key to success for Ritchell isn't the open source software, it's the innovation. "Differentiation is not what you've done today, but how rapidly you can advance," he said. As the software developer you have a head start, and, hopefully, a vision of where you are going. Those are your differentiators to use Perens' terms.

"The only way to be successful is to stay ahead," Richell added. "I don't think the license has anything to do with it."

The Chef project, makers of various software automation and deployment tools, seems to agree. This initiative offers an alternative course to that of MongoDB and Redis. In the spring, Chef announced it would change its license to be completely open source (under the Apache 2.0 license). "We welcome anyone to use and extend our software for any purpose in alignment with the four essential freedoms of Free Software," wrote Chef CEO Barry Crist. While Crist didn't mention any other companies, it's hard to see the specific language of "the four essential freedoms" as anything but a response to Redis and MongoDB.