Open Source Licensing Choices

Origin and history

The concept of open source licensing emerged from the free software movement in the late 20th century, primarily within the United States. Its philosophical and legal foundations were established in the 1980s with Richard Stallman's GNU General Public License (GPL). The formal term "open source" was coined and the Open Source Initiative (OSI) was founded in the late 1990s to promote and certify licenses. This provided a framework for collaborative software development distinct from proprietary models. The proliferation of the internet enabled global collaboration, making license choice a critical early decision for software projects. These licenses are not products but legal instruments whose terms have evolved through community and judicial interpretation over decades.

What it is for

Open source licensing choices determine the legal terms under which software source code is shared, modified, and redistributed. They are designed to enforce specific collaboration models and protect the rights of both creators and users. A license grants permissions that would otherwise be reserved under standard copyright law, such as the right to study, change, and distribute the software. The choice directly influences who can use the software, including commercial entities, and under what conditions they must contribute changes back. It serves as the foundational governance document for a project's community, dictating the rules of engagement for all contributors. Selecting a license is a strategic decision that impacts adoption, commercial viability, and long-term project sustainability.

Overview

Open source licenses are broadly categorized into two families: permissive and copyleft. Permissive licenses, like the MIT and Apache 2.0 licenses, impose minimal restrictions, allowing code to be used in proprietary software with few obligations. Copyleft licenses, such as the GNU GPL, require that derivative works remain under the same license terms, ensuring the code and its modifications stay free. There are also weak copyleft licenses, like the LGPL, which apply copyleft primarily to the library itself rather than the entire software that uses it. Licenses may include additional clauses addressing patents, attribution, and governance. The choice is a non-revocable, permanent legal declaration made at the project's inception, setting its trajectory.

What to know

Founders must understand that publishing code without an explicit license means it remains under exclusive copyright, and others have no legal right to use it. License compatibility is a critical technicality, especially when incorporating other open source libraries, as incompatible licenses can block distribution. Some licenses include explicit patent grants, like Apache 2.0, which can provide a layer of protection against patent litigation from contributors. The "or later version" clause in some GPL licenses delegates future license version approval to the Free Software Foundation, which some organizations avoid for control reasons. Choosing a license is a one-way decision for existing code; relicensing existing projects often requires unanimous consent from all copyright holders, which can be impossible. Founders should also consider license proliferation and stick to well-established, OSI-approved licenses to reduce complexity for users.

Common questions

A common question is whether a company can use open source software in its commercial products, which is generally allowed but governed by the specific license's redistribution terms. Founders often ask if they can change the license later, which is extremely difficult if external contributors hold copyright, requiring their permission. Many inquire about the difference between GPL and AGPL, with the latter extending copyleft to software accessed over a network, which is crucial for SaaS applications. Questions arise regarding dual licensing, where code is offered under both an open source and a commercial license, a model used by companies like MySQL. Founders frequently seek to understand the simplest license, which is often the MIT License, requiring only preservation of copyright and license notices. Another frequent query concerns the need for a Contributor License Agreement (CLA) to streamline copyright ownership and relicensing ability, which adds administrative overhead.

Pros and cons

A major pro of permissive licenses is maximum adoption, as they place no friction on commercial use, making the technology ubiquitous. The primary con of permissive licensing is the lack of obligation for improvements to be shared back, allowing competitors to benefit without contributing. A key pro of strong copyleft licenses is the guarantee of a reciprocal community, where all derivatives must contribute their modifications back to the commons. The significant con of strong copyleft is its "viral" nature, which can deter commercial adoption and integration, as it can restrict how the software is combined with proprietary code. A common mistake is selecting a license based purely on ideology without pragmatic consideration of the target user base and commercial ecosystem, leading to stunted growth. Founders often regret choosing an overly restrictive license like GPLv3 for a library, as it can severely limit adoption by both open source and proprietary projects.

Who it suits

Permissive licenses like MIT or Apache 2.0 suit founders who prioritize widespread adoption and integration into as many projects as possible, including proprietary ones. They are ideal for tools, libraries, and frameworks where the primary goal is ecosystem growth and standardization. Strong copyleft licenses like the GPL suit founders who are ideologically committed to ensuring all derivative works remain free and open, often for community-driven applications. Weak copyleft licenses like the LGPL are suited for software libraries where founders want to ensure improvements to the library itself are shared, but allow linking with proprietary applications. The AGPL is suited for founders of network-based services (SaaS) who want to prevent others from profiting from modified versions of their software without sharing improvements. Founders seeking a commercial open-core business model often choose a permissive license for the core and offer proprietary extensions, or use a dual-licensing strategy with a copyleft license.