Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
Understanding the movement of ‘single source’ companies from ‘open source’ to ‘source available’ licenses In the last nine months since joining GitHub’s policy team, I’ve been asked repeatedly about a…
Understanding the movement of ‘single source’ companies from ‘open source’ to ‘source available’ licenses
In the last nine months since joining GitHub’s policy team, I’ve been asked repeatedly about a two-year trend in the open source ecosystem: ‘single source’ open source companies scrapping their Open Source Initiative-approved open source license for a ‘source available’ license. This trend is unfolding as cloud infrastructure changes the way developers interact with the dependencies in their stack.
A ‘single source’ open source project is where a single, for-profit, company dominates the project roadmap and maintainer status as its main revenue generator for ‘open-core’ or ‘dual-licensing’ revenue streams. In open-core, a vendor sells add-ons or services around a free and open source software (FOSS) project under a commercial license. In dual-licensing, a vendor releases software under a FOSS license with obligations that are difficult for some businesses to meet and also offers that same software under a commercial license. Both models use open source for exponential growth. The developer that grabs the free and open product today is (or works for) tomorrow’s paying customer.
As the cloud grows, both models face challenges. The shift from server rooms to data centers enables cloud vendors to use the open source license to stand up offerings based on the open-core or dual-licensed project, often under pressure from customers who want to buy all their computing services from a single company. This puts the open-core or dual license business at risk: the cloud vendors suddenly have the initial relationship with users, making it more difficult for the open-core or dual-license vendor to develop relationships that convert to sales.
In response to this pressure, many open-core or dual-license companies, including Confluent, MongoDB, Cockroach Labs, Redis Labs, Timescale, and Graylog moved away from OSI-approved licenses to licenses that are not ‘open source.’ These new ‘source available’ licenses contain restrictions to prevent cloud infrastructure providers from building a service out of their code. Early efforts like the commons clause limited ‘commercial use’ broadly and users found that the license language ‘created some confusion and uncertainty.’ Recent efforts by Elastic and others are more surgical. They simply attempt to restrict users from standing up the software alone as a service. The goal of these new licenses is to continue to capitalize on the widespread availability of the software and its source code to gain future customers while shutting out competing SaaS services based on the same code.
So what’s the lesson for developers choosing their stack? Understand that project ownership and diversity in the contributor base matter. Open source-licensed projects with a non-profit home, neutral trademark ownership, and multiple significant contributors are less likely to face pressures to relicense. Projects that are the main revenue generator for a ‘single source’ for-profit company have different dynamics. Any for-profit company needs to make a profit. If you take a dependency on such projects, you may face the for-profit company relicensing to protect its business.
Follow GitHub Policy on Twitter for updates about the laws and regulations that impact developers.
