logo
CHEATSHEETSTOOLSABOUT中文

Software Licenses and Governance Models

Software licensing models represent legal frameworks that govern how source code, intellectual property, and community contributions propagate through the tech industry.

Understanding the distinction between Permissive and Copyleft licensing is essential for evaluating dependencies, protecting proprietary IP, and designing open-source projects.

The Spectrum: Permissive vs. Copyleft

The core philosophical divide in open-source licensing centers on what downstream distributors are allowed to do with modified versions of the code:

Permissive (Do whatever you want; keep copyright notice)
[ MIT / BSD / Apache 2.0 ]
       │
       ▼
Weak Copyleft (File-level copyleft; link freely)
[ LGPL / MPL ]
       │
       ▼
Strong Copyleft (Derivative works must share same license)
[ GPLv2 / GPLv3 / AGPLv3 ]

1. Permissive Licenses

  • MIT License: Radical simplicity. You can do anything with the code (modify, commercialize, sub-license, make proprietary) as long as you retain the original copyright notice and disclaim liability. (Used by React, Node.js, Vue).
  • BSD (2-Clause / 3-Clause): Similar to MIT. The 3-clause version explicitly prohibits using the author's name to endorse derivative products without specific written permission. (Used by Go, FreeBSD).
  • Apache 2.0: A comprehensive permissive license that includes an explicit patent grant from contributors to downstream users, plus a patent termination clause if a user sues over patent infringement. (Used by Kubernetes, Android, Swift, Kotlin, Apache Spark).

2. Copyleft ("Share-Alike") Licenses

Copyleft uses copyright law to enforce ongoing freedom: any distributed derivative work must be licensed under the exact same copyleft terms.

  • GPLv2 (GNU General Public License v2): The license of the Linux kernel and Git. If you distribute binary versions of a modified program, you must make the source code available under GPLv2. Linus Torvalds famously chose GPLv2 over GPLv3 because GPLv2 focused on code sharing rather than hardware lockouts.
  • GPLv3: Introduced anti-Tivoization clauses (preventing companies from locking down consumer hardware so modified GPL code cannot boot) and automated patent licenses.
  • LGPL (Lesser GPL): Commonly used for libraries (like glibc). Allows proprietary applications to dynamically link against the library without forcing the main application to become open source.
  • AGPLv3 (Affero GPL): Closes the "SaaS loophole". Under standard GPL, running code on a remote cloud server is not considered "distribution." AGPL requires any web service running modified AGPL code over a network to make the complete source code downloadable to network users. (Used by early MongoDB, Grafana).

Real-World Case Study: Why Apple Avoids GPLv3

Notice how Apple treats open-source software in macOS and iOS:

  • macOS migrated its default login shell from Bash (GPLv3 in newer releases) to Zsh (MIT-like permissive license).
  • Apple replaced GCC (GPLv3) across its toolchain by heavily funding Clang/LLVM (Apache 2.0 with LLVM Exception).

Why?

  1. Anti-Tivoization Clauses: GPLv3 requires that users must be able to install and execute modified versions of the software on the physical device. Because iOS and macOS rely heavily on cryptographic hardware code-signing (Secure Enclave, T2 chips, Gatekeeper), distributing GPLv3 system utilities could legally compel Apple to allow unsigned code execution.
  2. Patent Exposure: GPLv3 contains aggressive, automatic patent cross-licensing clauses that commercial hardware giants avoid.

Creative Commons (For Non-Code Content)

Creative Commons (CC) licenses are designed for prose, documentation, diagrams, audio, and visual assets (not source code):

  • CC0: Public domain dedication (no rights reserved).
  • CC BY: Attribution required.
  • CC BY-SA: Attribution + ShareAlike.
  • CC BY-NC: Attribution + Non-Commercial only.
Loading...