As open source software grows more popular, and important, developers face an existential question: How to make money from something you give away for free?
The Open Source Initiative standards body says an open source license must allow users to view the underlying source code, modify it, and share it as they see fit. Independent developers and large companies alike now routinely release software under these licenses. Many coders believe open collaboration results in better software. Some companies open their code for marketing purposes. Open source software now underpins much technology, from smartphone operating systems to government websites.
“The entire world runs on open source software and we have no idea how to sustain that without destroying people” by essentially asking them to work for free, says John Anderson, vice president of technology at consulting firm Infinity Interactive.
Companies that release software under open source licenses generate revenue in different ways. Some sell support, including Red Hat, which IBM acquired for $34 billion earlier this month. Others, like cloud automation company HashiCorp, sell proprietary software based on the open source components. But with the rise of cloud computing, developers see their open source code being bundled into services and sold by other companies. Amazon, for example, sells a cloud-hosted service based on the popular open source database Redis, which competes with a similar cloud-hosted service offered by Redis Labs, the sponsor of the open source project.
To protect against such scenarios, companies behind popular open source projects are restricting how others can use their software. Redis Labs started the trend last year when it relicensed several add-ons for its core product under terms that essentially prohibit offering those add-ons as part of a commercial cloud computing service. That way, Amazon and other cloud providers can’t use those add-ons in their competing Redis services. Companies that want the functionality provided by those add-ons need to develop those features themselves, or get permission from Redis Labs.
“We felt that if we continue to license all this innovation under liberal open source licenses, then the cloud providers could start hosting it as a service, without contributing anything back to the community, and extract a lot of economic value out of the ecosystem,” Redis Labs chief marketing officer Howard Ting says. “Then we wouldn’t be able to fund this investment and give back to the community.”
Analytics company Confluent and database maker CockroachDB added similar terms to their licenses, preventing cloud computing companies from using some or all of their code to build competing services. Taking a slightly different tack, MongoDB relicensed its flagship database product last year under a new “Server Side Public License” (SSPL) that requires companies that sell the database system as a cloud service also release the source code of any additional software they include. Alternatively, customers can buy a commercial license from MongoDB.
Offering the same software under two different licenses, known as “dual licensing,” is controversial in the open source community. The Open Source Initiative doesn’t consider the SSPL, or any of these other newly adopted licenses, to be open source licenses.
Ting, of Redis Labs, says the new approaches are working. For example, earlier this year Google announced revenue sharing partnerships with several open source companies, including Redis Labs, Confluent, and MongoDB. But the new licenses haven’t stopped Amazon from selling its own services based on open source projects commercialized by the three companies. For example, Amazon in January launched DocumentDB, a database service compatible with an earlier version of MongoDB that included more permissive license terms.
Amazon says it is a friend, not a foe, of open source software. In a talk at the Oscon open source conference in Portland, Oregon, earlier this month, Amazon Web Services technologist Arun Gupta touted the company’s contributions to open source, such as the virtual-machine management system Firecracker Amazon released last November. Gupta also pointed out that Amazon has contributed code to outside projects, including some encryption software for Redis that it released last year.
At the same conference, Amazon vice president of cloud architecture strategy Adrian Cockcroft made the case that the company’s cloud services actually help open source projects, through revenue sharing arrangements, including one with open source cloud management company Chef, or by simply lending credibility to products by offering them as a service.
Ting counters that Amazon only has revenue sharing deals with a small number of companies and downplays Amazon’s contributions to Redis. He says Amazon’s sole contribution was the encryption code that he expects to be included in a forthcoming version of Redis’ database software.
Some open source advocates decry the trend toward more restrictive licenses. They see the squabbles over the re-use of open source code as disputes between small companies and big companies, with little regard to open source principles or individual developers. Companies employing restrictive licenses want to redefine open source as meaning only that the code is available, not necessarily that others can use it how they want, says Bradley M. Kuhn, president of the nonprofit Software Freedom Conservancy. “There’s a concerted effort to pick away at the Open Source Initiative definitions,” he says.
Such efforts aren’t new, notes Danese Cooper, who has run open source initiatives at Sun Microsystems, PayPal, and Irish technology consulting firm NearForm. Sun Microsystems released the Java programming platform under a license that restricted how the platform could be modified by others, which led to the protracted legal conflict between Oracle, which acquired Sun in 2010, and Google, which created its own Java platform for the Android operating system. Eventually these sorts of not-quite-open-source licenses fell out of favor because they limited the usefulness of the software released under them and who could contribute to a project. “The new generation is making the same mistakes the old generation did,” Cooper says.
“The moral outrage [of the smaller companies] is bullshit,” Adam Jacob, cofounder and former CTO of Chef, said during an Oscon keynote. Companies like MongoDB might be small compared with Amazon, he said, but they’re still well funded. MongoDB reported revenue of $267 million in the fiscal year ended January 31, and has a market cap of around $8 billion.
Jacob says open source companies can generate revenue without adopting more restrictive licenses. Long before Amazon worked out a revenue sharing deal with Chef, Amazon offered a service based on Chef’s open source software. But, he says, Amazon’s service didn’t meet expectations for many Chef users. So, responding to its own customers’ demands, Amazon worked with Chef to create a better service—one that actually makes money for Chef.
Others say the debate obscures the needs of smaller projects that can’t pay developers to develop or maintain software. A lack of funding for open source projects can lead to real consequences. Most famously, in 2014 security researchers revealed serious security vulnerabilities in OpenSSL and Bash, which are part of several major operating systems, potentially leaving many users exposed. Both OpenSSL and Bash were run by volunteers who couldn’t afford to hire security auditors.
There are efforts aimed at funding smaller projects, including nonprofits like the Software Freedom Conservancy, which raises funds to pay developers, and startups like Tidelift, which aims to sell support for bundles of open source projects that might not be able to commercialize their work on their own.
Jacob says there’s often tension between the business models of open source companies and the communities that grow around those projects. Developers may want a piece of open source software to be as good as it possibly can be. But a company that hopes to make money by selling proprietary extensions to that software may want to make the software just good enough—to drive customers to the company’s proprietary offerings. If the open source version is too good, customers won’t need to pay for add-ons.
He says there’s nothing wrong with a company wanting to make money off its open source software and trying to prevent others from doing so. But he thinks those expectations should be established early on, so developers know what to expect. To that end, Jacob created a web resource called the Sustainable Free and Open Source Community that catalogs different business models for open source projects, and principles to guide sustainable open source communities. In true open source spirit, the site’s content is open source and others are contributing. Eventually, Jacob hopes, it could be a home to different “social contracts” that open source projects can adopt, just like today they can adopt different standard licenses and even codes of conduct.