Skip to content

002: License Selection

  • Type: Strategy
  • Status: Planned
  • Date: YYYY-MM-DD
  • Author(s) / Deciders: Repository owners and legal/project stakeholders
  • Question: Under what license terms will this project's source code, documentation, and assets be distributed?

Context

A software project without a license defaults to exclusive copyright, preventing others from legally using, modifying, or redistributing the work. Selecting an explicit license clarifies permissions, patent grants, and attribution requirements.

Requirements and Restrictions

  • Commercial & Derivative Use: Determine whether proprietary derivatives are allowed or if modifications must remain open-source (copyleft).
  • Patent Protection: Determine whether an explicit patent grant and retaliation clause are required.
  • Dependency Compatibility: Ensure compatibility with the licenses of third-party libraries used by the project.

Alternatives

  • MIT / BSD-2-Clause (Permissive): Minimal restrictions, high adoption, no explicit patent grant clause.
  • Apache-2.0 (Permissive + Patent Grant): Permissive use with an explicit patent license and retaliation clause.
  • MPL-2.0 (Weak Copyleft): File-level copyleft allowing combination with proprietary files in larger works.
  • GPL-3.0-or-later / AGPL-3.0-or-later (Strong Copyleft): Requires derivative works (and network deployments for AGPL) to be distributed under the same license.
  • Proprietary / All Rights Reserved: Closed-source distribution restricted to authorized parties.

Decision

Specify the chosen SPDX license identifier (for example, MIT, Apache-2.0, or GPL-3.0-only) for code and, if different, for documentation and media assets (such as CC-BY-4.0).

Consequences

Positives

  • Contributors and downstream users have unambiguous legal terms for adoption and contribution.

Negatives

  • Changing a license later requires consent from all copyright holders or a Contributor License Agreement (CLA).