page contents Verification: 9ffcbb9dc8386bf9 In 2019, multiple open source companies changed course—is it the right move? – News Vire
Home / Tech News / In 2019, multiple open source companies changed course—is it the right move?

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

Stock photos continue to be a gift to the world. Maybe it's sometimes on par with open-source software.
Enlarge / Stock photos continue to be a gift to the world. Maybe it’s sometimes on par with open-source software.

cnythzl / Getty Images

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.
Enlarge / Unrelated to the matter at hand: The swag game is strong at MondoDB.

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 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 Apache 2.0 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 tenants 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.

Listing image by photovibes / Getty Images

Leave a Reply

Your email address will not be published. Required fields are marked *