https://github.blog/2021-03-18-whats-up-with-these-new-not-open-source-licenses/ Back to GitHub.com The GitHub Blog * Changelog * Community + Education + Events + Insights + Open source * Company * Engineering * Enterprise * Product + Client apps + Features + Security Search by Keyword [ ] Search Primary Menu * Changelog * Community + Education + Events + Insights + Open source * Company * Engineering * Enterprise * Product + Client apps + Features + Security Search by Keyword [ ] Search [policy-social-1] March 18, 2021 Policy What's up with these new not-open source licenses? Image of Justin Colannino Justin Colannino 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. How we got here 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. What this means for developers 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. Share * Twitter Share on Twitter * Facebook Share on Facebook * LinkedIn Share on LinkedIn Related posts March 15, 2021 Policy FUD chills: GitHub stands with security researchers on DMCA Section 1201 Security research makes us all safer, but too often developers face ambiguous rules and possible criminal liability when they do quality assurance work to find security holes in their stack. Current DMCA Section 1201 rules Image of Justin Colannino Justin Colannino February 25, 2021 Policy 2020 Transparency Report At GitHub, we put developers first, and we work hard to provide a safe, open, and inclusive platform for code collaboration. This means we are committed to minimizing the disruption of software projects, protecting developer Image of Abby Vollmer Abby Vollmer February 23, 2021 Open source Open source in the 5G stack Developers know the value of openness, and increasingly policymakers are taking note. Open source and open standards approaches offer promising solutions to mounting policy problems related to digital sovereignty. One such area where open approaches Image of Peter Cihon Peter Cihon Product * Features * Security * Enterprise * Customer stories * Pricing * Resources Platform * Developer API * Partners * Atom * Electron * GitHub Desktop Support * Docs * Community Forum * Training * Status * Contact Company * About * Blog * Careers * Press * Shop * Github Twitter link * Github Facebook link * Github Youtube link * Github LinkedIn link * Github link * (c) 2021 GitHub, Inc. * Terms * Privacy