Software Licensing

AGPLv3 is the GNU Affero General Public License version 3, published by the Free Software Foundation In 2007. It is identical to GPLv3 with one critical addition: Section 13, the “Network Interaction” clause.

Section 13 states that if you modify the program and offer users the ability to interact with it Remotely over a computer network, you must provide those users with the complete corresponding Source code of your version. This closes what is known as the “ASP loophole” (Application Service Provider loophole) present in GPLv2 and GPLv3, where hosting software as a service did not Trigger the distribution requirement because no copy was being “distributed” or “conveyed” in the Traditional copyright law sense.

What triggers AGPLv3 obligations:

• Modifying AGPLv3-licensed code and making it available over a network (e.g., deploying it as a SaaS product)
• Distributing modified copies to third parties
• Distributing a combined work that incorporates AGPLv3 code

Compliance obligations:

• Provide complete source code (including all of your modifications) to network users, via a conspicuous notice and link embedded in the user interface
• Include all license notices, copyright notices, and attribution
• Ensure downstream recipients receive the same AGPLv3 license rights
• Comply with all GPLv3 requirements: anti-Tivoization provisions (Section 6), patent provisions (Section 11), and source distribution requirements (Section 4)

Why it is the strongest copyleft in common use:

AGPLv3 combines the strong copyleft of GPLv3 with the network interaction trigger of Section 13. No Other widely-used license requires source code distribution for network-accessible services. This Means AGPLv3 reaches situations where GPLv3 and GPLv2 do not: any SaaS deployment, any internal Microservice architecture where services communicate over HTTP, any web application.

Real-world consequences:

• MongoDB was originally licensed under AGPLv3. This was deliberately chosen to prevent cloud providers from offering MongoDB-as-a-Service without contributing back. When AWS launched DocumentDB (a MongoDB-compatible service) without contributing to MongoDB, MongoDB created the SSPL and eventually moved to a proprietary license entirely.
• Mastodon uses AGPLv3 to ensure that anyone hosting a Mastodon instance and making modifications must share those modifications. This preserves the federated, community-driven nature of the Fediverse.
• Many enterprise organizations maintain explicit policies prohibiting AGPLv3 dependencies because the network interaction trigger is broad enough that even internal network services could potentially trigger compliance obligations.

Key nuance: Section 13 applies to the modified version of the program. If you deploy Unmodified AGPLv3 software as-is, you still must provide the source code to users under Section 13 (because the deployed software is still a version “based on” the Program). But the source you Provide is the upstream source, not a modified version, because there are no modifications.

GPLv3 was published in June 2007 to address specific legal and technological developments since GPLv2 (1991). It is the Free Software Foundation”s flagship copyleft license and was drafted with Input from a large committee including representatives from corporate open-source contributors (IBM, Red Hat, Novell, Google, and others).

Distribution trigger: GPLv3 obligations are triggered by “conveying” (the GPLv3 term, Defined in Section 4) — making copies available to others so that they can possess the software. Internal use does not trigger the license. Hosting as a SaaS does NOT trigger GPLv3 obligations — this is the ASP loophole that AGPLv3 was specifically designed to close.

Key differences from GPLv2:

• Patent retaliation (Section 11): If a user initiates patent litigation against any party alleging that the GPL-covered software constitutes patent infringement, that user’s patent license for the software is terminated. This acts as both an implicit patent grant (the license grants permission to use the software, which would be meaningless if contributors could sue for patent infringement of their own contributions) and a deterrent against patent aggression.
• Anti-Tivoization (Section 6): If you distribute a consumer product containing GPLv3 software, and the product includes installation information that allows the user to reinstall modified software on the device, you must provide that installation information. If the product does not include such information, you must offer it in writing. This prevents hardware manufacturers from using GPLv3 code while cryptographically locking the device to prevent user modifications — the practice that gave “Tivoization” its name (TiVo used Linux but locked down the bootloader to prevent users from running modified firmware).
• Compatibility with Apache 2.0: GPLv3 was specifically designed to be compatible with Apache 2.0, resolving a major incompatibility with GPLv2. The GPLv3 text explicitly permits the additional conditions imposed by Apache 2.0 (including its patent retaliation clause), which GPLv2 does not permit.
• Internationalization: GPLv3 was drafted with international copyright frameworks in mind (Berne Convention, WIPO Copyright Treaty), while GPLv2’s language was primarily oriented toward US copyright law.

Compatibility with GPLv2: GPLv3 is NOT compatible with “GPLv2 only” code. GPLv2 code that Carries the “or any later version” clause (e.g., “Licensed under the GNU General Public License, Version 2, or at your option any later version”) can be relicensed under GPLv3. But code licensed Strictly under “GPLv2 only” cannot be combined with GPLv3 code into a single work, because GPLv3 Adds restrictions (patent retaliation, anti-Tivoization) that GPLv2 Section 4 does not permit — you May not add additional restrictions to GPLv2.

LGPLv3 is the “weak copyleft” license. It allows proprietary software to link to LGPL-licensed Libraries without being subject to copyleft obligations for the proprietary parts, while ensuring That modifications to the LGPL-licensed code itself remain free.

The linking boundary — the critical distinction:

LGPLv3’s copyleft obligation applies to modifications of the LGPL-licensed work and, in the case of Static linking, to the combined work as a whole. The specific rules:

• Dynamic linking: If a proprietary application dynamically links to an LGPL library at runtime, the proprietary application is generally NOT considered a derivative work of the LGPL library. The proprietary application can remain under its own license. However, you must still distribute the source code of the LGPL library (including any modifications you made to it), and you must provide the object files or a mechanism for the user to relink the proprietary application against a modified version of the LGPL library (Section 4(d)). This ensures users can replace the LGPL library with their own version.
• Static linking: If a proprietary application statically links to an LGPL library, the combination is generally considered a single work under copyright law, and the entire combined work (including the proprietary application code) must be distributed under LGPLv3. You can avoid this by providing object files for the proprietary parts and a mechanism for the user to relink (Section 4(d) allows this as a compliance mechanism).
• Modifying the library: Any modifications to the LGPL-licensed library source code must be distributed under LGPLv3, regardless of whether the application that uses the library is statically or dynamically linked.

When proprietary apps CAN use LGPL libraries: Dynamic linking is the safe path. If your Application loads the LGPL library at runtime (via dlopenShared library loading, or equivalent), Your application can remain proprietary. You must still provide the LGPL library source and allow Relinking, but your own code is not subject to copyleft.

FSF recommendation: The FSF now recommends using GPLv3 with an explicit linking exception (e.g., The GCC Runtime Library Exception) over LGPLv3 for new libraries. A linking exception is more Precise than the generalized LGPL framework because it can define exactly which linking activities Are exempt from copyleft, rather than relying on the ambiguous legal concept of what constitutes “linking” versus “derivative work.”

GPLv2 was published in June 1991 and remains one of the most significant licenses in open source, Primarily because the Linux kernel is licensed under it.

Historical context: GPLv2 replaced GPLv1 (1989). The key improvement in GPLv2 was the “Liberty Or Death” clause (Section 7): if conditions are imposed on you that require you to violate the GPLv2 (e.g., a court order or legal requirement) in order to distribute the software, you may not Distribute the software at all. If you cannot distribute the software while simultaneously Satisfying both the GPLv2 and the other conditions, you must cease distribution. This was a response To concerns that laws in some jurisdictions might restrict the freedom to redistribute.

The “or later” clause: Many GPLv2 projects include the language: “GNU General Public License as Published by the Free Software Foundation; either version 2 of the License, or (at your option) any Later version.” This allows downstream recipients to choose to receive the code under GPLv3 (or any Later GPL version). The Linux kernel notably does NOT include this clause — Linus Torvalds Explicitly chose “GPLv2 only” for the kernel, which means the kernel remains under GPLv2 and cannot Incorporate code that is available only under GPLv3.

Why GPLv2 is incompatible with GPLv3: GPLv2 Section 4 states: “You may not copy, modify, Sublicense, or distribute the Program except as expressly provided under this License. Any attempt Otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically Terminate your rights under this License.” GPLv3 adds restrictions that are not present in GPLv2 (patent retaliation, anti-Tivoization, additional source distribution requirements). Since GPLv2 Prohibits adding restrictions, and GPLv3 adds restrictions, GPLv2-only code cannot be combined with GPLv3 code into a single work.

No explicit patent grant: GPLv2 is entirely silent on patents. There is no explicit patent grant From contributors to users, and there is no patent retaliation clause. This is one of the primary Reasons the FSF created GPLv3 — to address the threat of patent litigation against open-source Projects, which became a significant concern after various patent disputes in the early 2000s (e.g., Microsoft’s claims about Linux patent infringement in 2007).

MPL 2.0 is a file-level copyleft license. Its copyleft obligation applies only to the files that are Covered by MPL 2.0, not to the entire combined work or project.

File-level copyleft in practice:

• If you modify an MPL-licensed file, the modified file must be distributed under MPL 2.0 (Section 3.3)
• If you add new files that are not derivative works of existing MPL-licensed files, those new files can be under any license whatsoever — including a proprietary license
• The copyleft does not propagate to unrelated code in the same project, repository, or binary

Why Firefox uses MPL 2.0: Firefox is a large project with contributions from many organizations, Including corporations that ship proprietary code alongside Mozilla’s code. MPL 2.0 allows Mozilla To keep its own code under copyleft while allowing third-party code in the same codebase to be under Different licenses. This is why Firefox’s codebase can contain both MPL-licensed Mozilla code and Proprietary third-party code (e.g., Google-sourced code for the default search partnership, DRM Components for Widevine).

Patent grant (Section 2.1(b)): MPL 2.0 includes an explicit patent grant: “Each Contributor Hereby grants You a world-wide, royalty-free, non-exclusive license … Under Patent Claims of such Contributor that are necessarily infringed by the Covered Software alone or by combination of the Covered Software with Your Modifications.” This is functionally similar to Apache 2.0’s patent Grant, with one notable difference: the MPL patent grant terminates only for the specific patents Involved in litigation, whereas Apache 2.0 terminates the entire patent grant if the licensee Initiates litigation.

GPL compatibility (Section 3.3): MPL 2.0 includes a mechanism for declaring compatibility with GPL. A downstream recipient may distribute Covered Software under the terms of the version of the GNU General Public License specified in the MPL header block (the “Secondary License”). The default MPL 2.0 boilerplate includes an optional “GPL Compatibility List” field. If the original contributor Enables this option (by specifying GPLv2 or later as the Secondary License), then the MPL-licensed Code can be incorporated into a GPL project. This is how Mozilla-licensed code can be used in GPL Projects.

The MIT License (also called the Expat License, after the Expat XML parser that popularized this Specific text) is the most widely used open-source license in the world. It is the default license Applied to new repositories on GitHub.

Requirements:

• Include the copyright notice in all copies or substantial portions of the software
• Include the license text (the permission grant and warranty disclaimer) in all copies or substantial portions of the software
• The license text must be included in any binary distribution ( as a LICENSE file shipped alongside the binary)

What you CAN do:

• Use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software
• Use it in proprietary, closed-source products without any obligation to release your modifications
• Distribute it under a different license entirely (the “sublicense” right — you can take MIT code and redistribute it under Apache 2.0, GPL, or even a proprietary license)
• Use it in commercial products without payment or royalties of any kind

What you CANNOT do:

• Hold the copyright holders liable for any damages arising from the use of the software
• Remove or alter the copyright notice
• Represent that the copyright holders endorse your product (the license grants rights to the software, not to the authors’ identities or reputation)

Why it is the most popular: The MIT License is extremely short (under 200 words of substantive Text), easy to understand, and imposes minimal obligations. Its simplicity is both a strength (low Cognitive overhead, minimal compliance burden) and a weakness (no patent grant, no trademark Provisions, ambiguous attribution requirements for partial use).

Key nuance — “substantial portions”: The requirement to include the license applies to “all Copies or substantial portions of the Software.” If you use a single MIT-licensed function in a Large project, you likely do not need to include the MIT license text for the entire project — but You must still include the copyright notice for that specific code. If you copy a significant Portion (a module, a library, a substantial codebase), you must include the full license text. This Ambiguity is one reason some organizations prefer Apache 2.0, which has more explicit attribution Requirements tied to NOTICE files.

The Apache License 2.0 is the preferred license for large organizations and enterprise open-source Projects. It is more comprehensive than MIT but remains permissive.

Key provisions:

• Patent grant (Section 3): Each contributor grants “a world-wide, royalty-free, non-exclusive … Irrevocable (except as stated in this section) patent license” covering their contributions. This explicitly protects users from patent infringement claims by the contributors themselves — a protection that MIT entirely lacks.
• Patent retaliation (Section 3.3): If you initiate patent litigation against the software (asserting that the software infringes one of your patents), your patent license under Section 3 is automatically terminated. This is a defense mechanism that discourages contributors or users from filing patent suits against the project.
• Trademark protection (Section 7): The license does not grant any trademark rights whatsoever. You cannot use the names, trade names, trademarks, or service marks of any contributor to endorse or promote your product without separate written permission. MIT is silent on trademarks; Apache 2.0 explicitly addresses them.
• Attribution (Section 4): If the work includes a NOTICE file, you must include a copy of the NOTICE file in your distribution and provide attribution as specified in the NOTICE file. This creates a clear, machine-readable mechanism for tracking attribution obligations across a large dependency tree.
• State changes (Section 4(b)): If you modify files, you must include a prominent notice stating that you changed the files. This creates an audit trail that makes it clear which code is original and which is modified.
• Source distribution (Section 4(a)): You must include a copy of the license in every distributed source file. This is implemented as a file header comment containing the Apache 2.0 boilerplate.

Why large companies prefer Apache 2.0 over MIT:

• Explicit patent grant reduces legal risk from contributors asserting patents against users
• Trademark protection prevents brand dilution and endorsement misrepresentation
• NOTICE file mechanism provides a clear, auditable system for tracking attribution across large dependency trees
• State changes requirement creates a compliance trail
• Explicit source-file notice requirement eliminates the ambiguity around “substantial portions” in MIT

Compatibility note: Apache 2.0 is compatible with GPLv3 but NOT with GPLv2. The patent Retaliation clause in Apache 2.0 Section 3.3 constitutes an “additional restriction” under GPLv2’s Terms (GPLv2 Section 4 prohibits additional restrictions), which GPLv2 does not allow. GPLv3 was Specifically designed to accommodate Apache 2.0’s patent retaliation terms.

The BSD licenses are among the oldest open-source licenses in widespread use, originating at the University of California, Berkeley Computer Systems Research Group (CSRG).

BSD 2-Clause (“Simplified BSD”):

• Redistribution and use in source and binary forms, with or without modification, are permitted provided that the copyright notice and this license text are included
• The names of the copyright holders may not be used to endorse or promote products derived from the software without prior written permission

BSD 3-Clause (“New BSD” or “Modified BSD”):

• All BSD 2-Clause requirements, plus:
• Non-endorsement clause: Redistributions in binary form must reproduce the copyright notice, the license conditions, and a disclaimer in the documentation and/or other materials provided with the distribution. In practice, this means if you ship a binary that includes BSD 3-Clause code, you must list the copyright holders and license terms in your product documentation or a NOTICE file.

Historical context — the original 4-Clause BSD license:

The original BSD license had four clauses. The third clause (the “advertising clause”) required that All advertising materials for products containing the software acknowledge that the software was Developed by UC Berkeley. This became impractical as the number of BSD-licensed components grew — a Single product might need to list dozens of institutions in its advertisements. The clause was Officially removed in 1999 by William Hoskins, Director of the Office of Technology Licensing at UC Berkeley, after Richard Stallman of the FSF urged its removal on the grounds that it created an Impractical attribution burden.

BSD 3-Clause vs MIT: Functionally, BSD 3-Clause and MIT are very similar. Both grant broad Permission to use, modify, and redistribute, with attribution requirements. The primary difference Is that BSD 3-Clause explicitly prohibits using the copyright holders’ names for endorsement, while MIT handles this implicitly by not granting trademark rights. Many legal opinions consider them Effectively equivalent in practice.

UC Berkeley / CSRG history: The BSD licenses originated from the CSRG at UC Berkeley, which Developed BSD Unix. The settlement of the 1992 USL v. BSDi lawsuit (Unix System Laboratories, a Subsidiary of AT&T, vs. Berkeley Software Design, Inc.) was a pivotal moment in open-source history: The settlement established that BSD-derived code could be freely distributed without AT&T license Fees, paving the way for the free BSD derivatives (FreeBSD, OpenBSD, NetBSD) and ultimately Influencing the licensing landscape for all open-source software.

The ISC License was created by the Internet Systems Consortium (ISC) for its software projects, Including BIND (the DNS server software), DHCP, and Kea. It is functionally equivalent to the MIT License.

Why it exists: The MIT License’s original wording includes a clause stating that the license is Governed by the laws of the Commonwealth of Massachusetts (where MIT is located). The ISC License Was created to provide a simpler, jurisdiction-neutral alternative. In practice, this distinction is Largely irrelevant — both licenses are interpreted the same way in all jurisdictions, and modern MIT License texts often omit the jurisdiction clause.

Text: The ISC License is extremely short (under 80 words of substantive text beyond the Copyright notice) and is considered the simplest permissive license in common use that includes a Warranty disclaimer.

Adoption: OpenBSD uses the ISC License extensively for its base system code. Many Go standard Library packages are licensed under ISC. It is approved by both the Open Source Initiative and the Free Software Foundation as a GPL-compatible permissive license.

0BSD is a minimal permissive license that is essentially a public domain dedication with a one-line Fallback license. It was created by Rob Landley as a response to the legal ambiguity of public Domain dedications in jurisdictions that do not recognize them.

Text: The entire substantive content is: “Permission to use, copy, modify, and/or distribute This software for any purpose with or without fee is hereby granted. THERE IS NO WARRANTY.”

Key characteristics:

• No copyright notice requirement (hence “0BSD” — zero substantive clauses beyond the bare permission grant)
• No requirement to include the license text in distributions
• No warranty disclaimer beyond the single “THERE IS NO WARRANTY” statement
• Functionally equivalent to placing the work in the public domain, with a fallback license for jurisdictions that do not recognize public domain dedication

Adoption: Some Go projects and utilities use 0BSD, particularly for trivial contributions. It is OSI-approved. Its minimalism makes it suitable for very small code snippets where any non-trivial License obligations would be disproportionate to the contribution.

CC0 is the Creative Commons public domain dedication tool. It is not technically a license — it is a Legal instrument that attempts to waive all copyright and related rights to the fullest extent Permitted by law.

Legal standing varies by jurisdiction:

• In jurisdictions that recognize public domain dedication (most common law countries, including the US), CC0 effectively places the work in the public domain — the author retains no copyright
• In jurisdictions that do not allow copyright waiver (some civil law countries in continental Europe, where authors’ rights are considered inalienable), CC0 falls back to a broad, permissive license that grants all rights without requiring attribution or imposing any conditions
• CC0 explicitly disclaims all copyright and neighboring rights worldwide to the extent possible

Limitations:

• CC0 does NOT include a patent grant — it waives copyright only, not patent rights
• CC0 does NOT include a trademark license — you cannot use the author’s trademarks
• CC0 is NOT OSI-approved — the OSI requires that open-source licenses include copyright notice and license text redistribution requirements, which CC0 explicitly does not impose
• CC0 is not formally GPL-compatible — the FSF considers public domain works to have “no license,” which can create theoretical problems in GPL compliance (in practice, public domain code can be included in GPL projects because there are no copyright restrictions to conflict with)

Use case: CC0 is most commonly used for data sets, documentation, images, and other creative Works where the author genuinely wants no restrictions whatsoever. It is less common for software, Where the lack of a patent grant and the lack of a license text (which can complicate compliance Tooling) are significant drawbacks.

The Unlicense is a public domain dedication with a fallback license, created by Arto Bendiken.

Mechanism:

1. The author dedicates the work to the public domain using explicit, unambiguous legal language
2. If the public domain dedication is not legally effective in a given jurisdiction, a fallback all-permissive license grants the same rights (use, copy, modify, merge, publish, distribute, sublicense, and sell)

Ambiguity in some jurisdictions:

• Like CC0, the Unlicense faces the challenge that some jurisdictions do not recognize public domain dedication as a valid legal act
• The fallback license is less comprehensive than Apache 2.0 or MIT — it lacks explicit patent provisions and trademark provisions
• The Unlicense is NOT OSI-approved

Practical note: The Unlicense is more commonly used for small utilities and scripts than for Substantial software projects. Its lack of an explicit patent grant makes it riskier than Apache 2.0 For use in jurisdictions with active software patent litigation (notably the US).

WTFPL is a public domain dedication written in deliberately informal language. It was created by Sam Hocevar and is essentially a novelty license.

Legal status:

• Despite its informal language, WTFPL has been reviewed by legal scholars and is generally considered to grant the same practical rights as MIT or BSD
• However, its informal phrasing (“DO WHAT THE FUCK YOU WANT TO”) may not be recognized as a valid legal instrument in all jurisdictions, particularly in courts that expect formal legal language in license documents
• It includes NO patent grant, NO trademark provisions, and NO warranty disclaimer beyond a brief statement

Do not use for serious projects. While technically functional, WTFPL’s informal language creates Unnecessary legal ambiguity with no corresponding benefit. If you want a minimal permissive license, Use MIT, ISC, or 0BSD. If you want a public domain dedication, use CC0 or Unlicense. WTFPL is a Novelty, not a serious licensing choice for production software.

EPL 2.0 is a weak-copyleft license maintained by the Eclipse Foundation. It is the primary license for The Eclipse IDE, Jakarta EE, and a large portion of the Java enterprise ecosystem. It occupies a Middle ground between permissive licenses (MIT, Apache 2.0) and strong copyleft licenses (GPL).

Key characteristics:

• File-level copyleft: Like MPL 2.0, EPL’s copyleft obligation applies only to files that contain EPL-licensed code or are derivative works of EPL-licensed files. You can combine EPL-licensed modules with proprietary code in the same project as long as they remain in separate files and modules.
• Patent grant with retaliation: EPL 2.0 includes an explicit patent grant from contributors (Section 1(b)) and a patent retaliation clause (Section 10) that terminates the patent grant if a recipient brings a patent infringement claim against the software. This is similar in effect to Apache 2.0’s patent retaliation provisions.
• No copyleft compatibility with GPLv2: EPL 2.0 is compatible with GPLv3 (you can combine EPL and GPLv3 code) but NOT with GPLv2. The incompatibility with GPLv2 arises from EPL’s additional conditions (patent retaliation, indemnification) that GPLv2 Section 4 does not permit.
• Explicit compatibility with GPLv3: Section 4.1 of EPL 2.0 states that a work distributed under both EPL 2.0 and GPLv3 may be distributed under GPLv3 alone, making the combination straightforward.

EPL 2.0 vs MPL 2.0:

• Both are file-level copyleft licenses with patent grants and retaliation clauses
• EPL is more commonly used in the Java ecosystem; MPL is more common in the C++/Firefox/Rust ecosystem
• EPL has broader compatibility with GPLv3 by explicit provision; MPL 2.0 can be combined with GPLv2+ if the MPL 2.0’s GPL compatibility option is used (Section 3.3)
• EPL includes a “secondary license” mechanism (Section 4.1) allowing the copyright holder to designate a secondary license ( GPLv3) under which the code may also be distributed

When you encounter EPL 2.0:

• Common in enterprise Java projects: Eclipse IDE, Jakarta EE, JGit, Eclipse Vert.x, JFace, SWT
• If you are building a proprietary application that uses EPL-licensed libraries, you can do so as long as your modifications to the EPL-licensed code are made available under EPL 2.0
• If you are distributing a combined work that includes both EPL and proprietary code, the EPL-licensed portions must remain under EPL 2.0, but your proprietary portions can remain under their own license

The Boost Software License is a permissive license used by the Boost C++ libraries, one of the most Influential and widely-used C++ library collections in the world. Many components of Boost have been Incorporated into the C++ standard library itself.

Key characteristics:

• Permissive with a mandatory attribution notice: The license requires including a copy of the license text in all copies of the software. The required notice includes the copyright holder’s name, the license text, and a disclaimer — similar to MIT/BSD in this regard.
• No patent grant: Unlike Apache 2.0 and EPL 2.0, BSL 1.0 does not include an explicit patent grant. This means that contributors grant copyright licenses but do not grant patent licenses. This is a significant difference from Apache 2.0, which explicitly grants patent rights.
• Broad redistribution rights: You may use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software under any license of your choice, including proprietary licenses.
• GPL compatible: BSL 1.0 is compatible with all versions of the GPL because it imposes no additional restrictions beyond attribution.

Why Boost matters even if you don’t use C++:

• Many C++ standard library features originated in Boost (smart pointers, std::optional std::variantRegular expressions, filesystem, threading)
• Understanding BSL 1.0 is relevant for any organization that uses C++ in production, because Boost libraries are a near-universal dependency in serious C++ projects
• The license text is short and clear, making it a reasonable choice for projects that want permissive terms without the overhead of Apache 2.0’s longer text

BSL 1.0 vs BSL 1.1 (Business Source License): Do not confuse the Boost Software License with the Business Source License (BSL 1.1). They are entirely different licenses. The Boost Software License is A simple, permissive, OSI-approved open-source license. The Business Source License is a source-available License that restricts production use until a change date, after which it converts to an open-source License ( GPL). The naming collision is unfortunate but well-established.

The Business Source License was created by MariaDB Corporation (now MariaDB plc) in 2018. It is NOT open source and is NOT OSI-approved.

Mechanism: BSL is a time-limited proprietary license with an automatic conversion to open Source. The software is distributed under a license that grants broad usage rights (use, modify, Distribute) but imposes restrictions on competitive use — , you may not use the software to Offer a competing product or service to the licensor’s commercial offering. After a specified date (the “Change Date”), the license automatically converts to an approved open-source license ( GPLv2 or Apache 2.0).

Structure:

• Grants use, modification, and distribution rights, subject to specific restrictions
• Restrictions prohibit using the software as a competitor to the licensor’s commercial product or service
• After the Change Date (e.g., 3-5 years from publication), the software converts to the specified open-source license
• The licensor controls the Change Date, the fallback open-source license, and the specific use restrictions

Why companies use it:

• Sentry uses BSL for its core product, with a Change Date that converts to Apache 2.0
• CockroachDB adopted BSL (with an “Enterprise” use restriction to limit competitive cloud deployment), later moved to a custom BSL variant
• HashiCorp adopted BSL for Terraform, Consul, Vault, and other products in 2023, precipitating the creation of OpenTofu (a fork of the last MPL 2.0-licensed Terraform)

Criticism: BSL violates the Open Source Definition on multiple grounds. OSD 5 (No Discrimination Against Persons or Groups) and OSD 6 (No Discrimination Against Fields of Endeavor) prohibit Licenses that restrict use based on the user’s identity or field of use. BSL explicitly restricts Competitive use, which is discrimination based on the user’s business activity. The OSI has Repeatedly declined to approve BSL.

SSPL was created by MongoDB in 2018 as a direct response to cloud providers — specifically AWS — Offering MongoDB-compatible managed database services without contributing code or revenue back to The MongoDB project.

Mechanism: SSPL is a modified version of AGPLv3. The critical change is in Section 13: instead Of merely requiring source code distribution for network users (as AGPLv3 does), SSPL requires that If you “offer the functionality of the Program to users as a service,” you must also provide the Source code of all programs you use to make that service available — including management tools, Monitoring systems, user interfaces, backup systems, and any other software that is part of the Service infrastructure.

The practical effect: SSPL effectively requires anyone offering the software as a managed cloud Service to open-source their entire operational infrastructure. This goes far beyond AGPLv3’s Requirement to provide the source of the modified software — it reaches into the service provider’s Deployment tooling, monitoring stack, and operational code. No company could comply with SSPL while Maintaining a competitive cloud service, which is precisely the intent.

AWS reaction and downstream effects:

• When MongoDB adopted SSPL, AWS responded by forking the last AGPLv3-licensed version of MongoDB and creating Amazon DocumentDB (a MongoDB-compatible API layer backed by a different storage engine)
• Red Hat removed MongoDB from its package repositories because SSPL is not an open-source license and therefore cannot be shipped as part of a distribution committed to open-source licensing
• Debian, Fedora, and several other Linux distributions followed suit
• The Linux kernel’s COPYING file explicitly states that SSPL is not compatible with GPL

OSI rejection: The OSI has not approved SSPL and has stated that it does not meet the Open Source Definition. The requirement to provide source code for all service-related software extends The copyleft obligation far beyond the scope of the covered software, imposing conditions on Unrelated programs — which violates OSD 9 (License Must Not Restrict Other Software).

This distinction is one of the most important and frequently misunderstood concepts in modern Software licensing.

Open source (OSI definition) means the software is licensed under a license that meets all ten Criteria of the Open Source Definition:

1. Free redistribution
2. Source code must be included or accessible
3. Derived works must be allowed
4. Integrity of the author’s source code must be preserved (no restrictions on modification)
5. No discrimination against persons or groups
6. No discrimination against fields of endeavor
7. Distribution of license (license must apply to all who receive the software)
8. License must not be specific to a product
9. License must not restrict other software
10. License must be technology-neutral

If a license fails even one criterion, it is not open source by the OSI definition.

Source-available means the source code is published and readable, but the license does not meet All ten criteria. Source-available licenses may restrict who can use the software, what they can use It for, how they can distribute it, or what obligations they have regarding their own code. The code Is available for inspection, but the license does not grant the full set of freedoms that open Source requires.

Why Redis and HashiCorp moved to source-available:

• Redis moved from BSD 3-Clause to RSALv2 (Redis Source Available License 2.0) and SSPL in March 2024, citing cloud providers — particularly AWS with ElastiCache — offering Redis-compatible managed services without contributing to the Redis project
• HashiCorp moved Terraform from MPL 2.0 to BSL in August 2023, and subsequently moved Consul, Vault, and other products to BSL, citing the same concern about cloud providers (AWS, Google Cloud, Microsoft Azure) offering managed versions of HashiCorp products without contributing commensurately

The economic argument: The core tension is between the open-source community’s expectation of Unrestricted freedom and the economic reality that large cloud providers can monetize open-source Projects at massive scale without contributing code, bug fixes, or revenue back to the projects they Depend on. Source-available licenses are an attempt to preserve the open-source development model (public repositories, community contributions, transparency) while restricting the specific use case That the licensors consider exploitative.

Whether source-available licenses are a legitimate defense of open-source sustainability or a Betrayal of open-source principles depends on your position in the debate. The OSI’s position is Clear: source-available is not open source, and using the term “open source” for source-available Licenses is misleading. The licensors’ position is that the OSI definition is outdated and does not Account for the economic dynamics of cloud computing.

Practical implications: Source-available software is NOT open source. You cannot use it in a Context that requires OSI-approved licenses (e.g., some government procurement contracts, some Corporate open-source policies). You must comply with the specific restrictions of the Source-available license, which may include restrictions on competitive use, field of use, or Distribution.

“Distribution” (called “conveying” in GPLv3) is the act of making a copy of a work available to a Third party. Under US copyright law, distribution is one of the exclusive rights of the copyright Holder (17 U.S.C. § 106(3)). Key forms of distribution:

• Physical distribution: Shipping software on media (USB drives, optical discs)
• Electronic distribution: Making software available for download from a server or file share
• Transferring a copy: Giving a copy to another party on any medium
• Container distribution: Shipping a Docker image or other container that contains the software — a container image is a distributable artifact that embeds copies of the software
• Application store distribution: Publishing software through an app store, package repository, or similar distribution channel

Internal use is NOT distribution. Running software on your own servers, even if accessed by Employees or contractors, does not constitute distribution. The copyleft obligations of GPL and LGPL Are not triggered by internal use alone. This is why you can run GPL-licensed software internally Without being required to provide source code to your employees.

Important caveat — AGPLv3 Section 13: AGPLv3 creates a separate trigger (network interaction) That operates independently of distribution. Even if no copy is distributed, AGPLv3 obligations can Be triggered by making the software available over a network to external users.

This is one of the most contentious and practically important areas in open-source licensing. The Legal question is: does linking to a library create a “derivative work” of that library?

Static linking: The library code is compiled directly into the executable. The resulting binary Is a single combined work that incorporates the library’s object code. Under both GPL and LGPL, Static linking is broadly accepted as creating a derivative work of the library, which triggers Copyleft obligations:

• Under GPL: the entire combined work must be distributed under GPL
• Under LGPL: the entire combined work must be distributed under LGPL, OR you must provide object files for the non-LGPL portions and a mechanism for the user to re-link

Dynamic linking: The library code is loaded at runtime from a separate shared object (.so .dll``.dylib). The executable and the library remain separate files. The legal status is Debated:

• FSF position (for GPL): Dynamic linking to a GPL library creates a derivative work, triggering copyleft obligations for the entire application. This is the FSF’s interpretation, but it has never been tested in court in the US.
• LGPL exception: LGPL explicitly allows dynamic linking to proprietary applications without triggering copyleft for the proprietary application. The proprietary application can remain under its own license, but the LGPL library must be distributed with source and the user must be able to re-link the proprietary application against modified versions of the library.
• Industry practice: Most conservative legal advice treats dynamic linking to GPL libraries as creating a derivative work. Many organizations avoid dynamically linking to GPL libraries in proprietary applications for this reason. For LGPL libraries, dynamic linking is widely accepted as safe.

Linux kernel syscall exception: The Linux kernel’s COPYING file includes an explicit NOTE that User-space programs calling kernel system calls (the syscall interface) are NOT considered Derivative works of the kernel. This is a specific, limited exception for the kernel’s syscall Interface only — it does not apply to dynamically linking to other GPL libraries.

Shipping a Docker image that bundles software raises important licensing questions that are Increasingly relevant as containerization becomes the standard deployment model.

Does shipping a container count as distributing the software inside it?

Yes, in essentially all interpretations. A Docker image is a distributable artifact — when you push An image to a registry (Docker Hub, ECR, GCR, etc.) and another party pulls it, you have distributed Copies of every piece of software in that image. This means:

• If the container includes GPL-licensed code, the copyleft obligations apply to the entire container image as a combined work
• If the container includes LGPL-licensed code, the dynamic linking analysis applies — but in practice, container images often bundle statically linked binaries (via multi-stage builds), which means static linking rules apply
• License notices must be included in the container image ( as files in the image filesystem)
• For AGPLv3-licensed code in the container, network users must have access to the source code

Practical guidance:

• Audit the licenses of all packages (direct and transitive dependencies) in your Docker image
• Include LICENSE files for all dependencies in your container, either in a dedicated directory or alongside the relevant packages
• If your container includes AGPLv3 code, provide a mechanism for users to obtain the complete source (e.g., a link in the application UI, a SOURCE label on the image, or a LICENSES directory)
• Consider using permissively-licensed alternatives for any containerized service that will be distributed to third parties

AGPLv3 Section 13 is the only common open-source license that explicitly addresses SaaS deployments. The relevant text:

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network […] an opportunity to receive the Corresponding Source of your version […]

What this means in practice:

• If you deploy an AGPLv3 application (modified or unmodified) and external users interact with it over a network, you must provide the complete source code to those users
• “Interacting remotely” is broadly interpreted — any HTTP request, API call, WebSocket connection, or similar network communication likely qualifies
• The source must be provided “prominently” — a deeply buried link in a privacy policy footer would not satisfy this requirement; a conspicuous notice in the application’s UI is expected
• You must provide the source of your version, including all modifications you have made

Why companies fear AGPLv3:

1. The network interaction trigger is broader than distribution. Any network-accessible service triggers it, regardless of whether a copy is conveyed
2. The source code must be prominently offered to ALL users, not just those who explicitly request it
3. Compliance is operationally complex. You need to maintain a source distribution mechanism for every AGPLv3 service you deploy
4. The definition of “interaction” is broad enough that internal microservices calling each other could theoretically trigger the obligation, though most legal interpretations focus on user-facing interactions

Common corporate policy: Many organizations categorize AGPLv3 as “do not use” or “require legal Review.” If your organization has an approved license list, AGPLv3 is almost certainly on the Restricted tier.

Dependency license auditing is an essential operational practice for any organization that Distributes software. The goal is to maintain a complete, accurate inventory of every license in Your dependency tree and to identify compliance risks before they become legal problems.

Automated tools:

• licensee — GitHub’s own tool for detecting the license of a repository. It analyzes the LICENSE file and provides the SPDX identifier.
• license-checker (npm) / pip-licenses (Python) / go-licenses (Go) — language-specific tools that scan your dependency tree and report the license of each package.
• licenserc — a tool that checks that all dependencies in a project comply with a configured allowlist. It can be run in CI/CD to prevent introduction of disallowed licenses.
• SPDX (Software Package Data Exchange) — a standard format (ISO/IEC 5962:2021) for communicating software bill of materials (SBOM) and license information. The SPDX License List at spdx.org/licenses/ provides canonical, standardized identifiers for every known license. These identifiers can be used in package.json``Cargo.toml``pyproject.tomlAnd other package manifests.
• FOSSA, Snyk, Black Duck — commercial dependency scanning tools that provide license compliance reports, vulnerability scanning, and SBOM generation.

Manual approaches:

• Check the LICENSE file in each dependency’s source repository
• Review package manifest files for license metadata (license field in package.json``license field in Cargo.toml``license field in go.mod)
• Cross-reference with the SPDX License List to ensure the declared license matches the actual license text

Best practices:

• Maintain an organization-wide approved license list with defined tiers (e.g., permitted, restricted, prohibited)
• Run automated license checks in CI/CD pipelines so that new dependencies are checked before they are merged
• Document the license of every direct and transitive dependency in a machine-readable format (SPDX SBOM)
• Review license changes when updating dependencies — a project CAN change its license between versions, and this can introduce compliance risk
• Treat license compliance as a continuous process, not a one-time audit

If your dependency audit reveals a license conflict (e.g., a GPLv3 dependency in a proprietary Project, or an incompatible license combination), you have several options, in order of preference:

1. Replace the dependency with a permissively-licensed alternative. This is the preferred solution — it eliminates the compliance risk entirely. Check alternatives on GitHub, alternativeTo, or language-specific package registries.
2. Isolate the dependency so that it does not form a combined work with your proprietary code. For LGPL-licensed libraries, this means using dynamic linking and providing the library source separately. For GPL-licensed code, isolation is far more difficult because the FSF takes the position that any linking creates a derivative work.
3. Relicense your project to be compatible with the dependency. This is only viable if you own the copyright to all code in your project or if all contributors have agreed to a license change (e.g., via a CLA that grants relicensing rights).
4. Obtain a commercial license from the copyright holders. Some projects offer dual licensing (e.g., MySQL is available under GPL from the community or under a commercial license from Oracle). This is common for companies that want to use GPL software in proprietary products.
5. Remove the dependency if the functionality it provides is not essential.

Assuming MIT means “do whatever you want.” MIT is permissive, not public domain. You still must Include the copyright notice and license text in all copies or substantial portions of the software. Removing the copyright notice is copyright infringement regardless of what MIT allows. The license Grants specific rights under specific conditions; it does not waive the copyright holder’s rights Entirely. You cannot claim the MIT-licensed code as your own, and you must preserve the attribution.

Thinking LGPL allows static linking into proprietary software. Under the FSF’s interpretation of LGPLv3 and the prevailing legal consensus, static linking creates a derivative work, and the Combined work must be distributed under LGPLv3. To use an LGPL library in a proprietary application, You should dynamically link it. Some organizations interpret LGPL as allowing static linking if Object files are provided for the proprietary portions (Section 4(d)), but this is a gray area — Consult legal counsel before relying on this interpretation.

Using GPL libraries in a web service without understanding AGPL implications. If you are Building a web service and want to use a GPL-licensed library, you may think you are safe because You are not “distributing” the software (you are hosting it internally). This is correct for GPLv2 And GPLv3 — hosting as a service does not trigger their copyleft obligations. However, if the Library is AGPLv3 (not GPLv3), network interaction triggers the copyleft obligation under Section 13, and you must provide source code to your users. Always check the exact license version, not just “GPL.”

Mixing GPL and Apache 2.0 code. Apache 2.0’s patent retaliation clause (Section 3.3) adds Restrictions that are incompatible with GPLv2. GPLv3 was specifically designed to accommodate Apache 2.0’s terms, so GPLv3 + Apache 2.0 is fine. But GPLv2 + Apache 2.0 is not. The Apache 2.0 patent Retaliation terms are “additional restrictions” that GPLv2 Section 4 prohibits. If you are working On a GPLv2-only project (like the Linux kernel), you cannot incorporate Apache 2.0-licensed code.

Not including license notices in binary distributions. Most permissive licenses (MIT, BSD, Apache 2.0) require including the license text in binary distributions. This is not optional — it is A condition of the license grant. Failing to include license notices in your shipped binaries means Your downstream recipients do not have a valid license to use the software, and you are committing Copyright infringement. In practice, your binary distribution must include a LICENSE file, a NOTICE file (for Apache 2.0), or equivalent documentation containing all applicable license texts And copyright notices. Automate this — tools like licensee``go-licensesAnd pip-licenses can Generate license notice bundles for your distribution.

• Choose a License — straightforward guide to selecting a license for your project, maintained by GitHub
• SPDX License List — canonical reference for standardized license identifiers and full license text
• tl;drLegal — plain-English summaries of common software licenses with key provisions highlighted
• GNU License Recommendations — the Free Software Foundation’s guidance on choosing a license
• OSI Approved Licenses — the definitive list of OSI-approved open-source licenses and the Open Source Definition

This topic covers the core concepts of software licensing, including underlying theory, practical implementation, and key applications.

Key concepts include:

• the software development lifecycle
• agile vs waterfall methodologies
• testing strategies (unit, integration, system)
• version control
• documentation and maintenance

Understanding these concepts thoroughly is essential for both examinations and practical programming, and requires both theoretical knowledge and hands-on practice.

Worked examples demonstrating the application of key concepts are covered in the detailed sub-pages linked above.

Software licensing is like choosing how to share a recipe. Permissive licenses are like posting your recipe online with a note “use this however you want, just mention my name.” Copyleft licenses are like saying “you can use my recipe, but any new dishes you create from it must be shared with the same rules.” AGPL is like “even if you serve the dish in a restaurant (SaaS), you must share the recipe.” The key insight is that licenses create a social contract - they define what kind of community forms around your software. MIT creates a free-for-all; GPL creates a sharing community; AGPL creates a sharing community that includes service providers.

• Introduction to Licensing - Conceptual foundations and the licensing spectrum