dispelledCopyleft, Permissive Licenses, and the Public Domain
Software licensing begins with a baseline that is easy to overlook: software is ordinarily protected by copyright as soon as eligible expression is fixed. Subject to jurisdiction-specific rules and exceptions, the copyright holder controls copying, distribution, and preparation of derivative works. Publishing source code on a website does not itself give everyone permission to reuse it. A software license is the permission that changes that default. It tells recipients what they may do and what conditions they must meet. The familiar labels “copyleft,” “permissive,” and “public domain” describe importantly different ways of allocating those permissions.
This is an explanatory overview, not legal advice. License obligations depend on the exact text, version, jurisdiction, how code is combined and conveyed, ownership records, and other facts. A release manager should inventory components, retain notices and license files, identify the intended distribution model, and consult qualified counsel when a decision carries legal risk. Informal claims that a license is “business friendly” or “viral” are poor substitutes for reading its terms.
Copyright is the starting point
Copyright protects original expression in software, including source and object code, while not protecting ideas, algorithms, methods of operation, or facts in the same way. It does not require registration in many countries, though registration can affect enforcement. Different contributors may own copyright in their contributions unless an employment agreement, assignment, or other arrangement changes that result. A repository can therefore contain many rightsholders and licenses. A project’s top-level LICENSE file does not automatically cure a copied file whose author never granted the stated permissions.
Open-source licenses generally give recipients broad rights to use, copy, modify, and distribute code. Conditions create the main families. A permissive license usually asks downstream users to preserve a copyright notice, license text, and perhaps a disclaimer while allowing proprietary redistribution of modified versions. A copyleft license uses copyright permissions reciprocally: if someone distributes a covered modified or combined work, it requires specified source and licensing freedoms to be passed onward. “Weak copyleft” applies reciprocity more narrowly, often around a file or library boundary. The terms are useful categories, not magic answers to every integration question.
Strong and limited copyleft
The GNU General Public License (GPL) is the best-known strong-copyleft family. GPLv2 and GPLv3 permit commercial sale, private modification, copying, and redistribution. When a distributor conveys a covered work or a work based on it, the license requires corresponding source and preservation of the GPL’s freedoms and notices. A company may run a modified GPL program on its own servers without handing copies to customers; ordinary GPL obligations are principally triggered by conveying copies, not by remote use. The distinction matters for hosted services, but it does not decide every question about appliances, client software, or contracts.
GPLv2, published in 1991, and GPLv3, published in 2007, are separate texts. GPLv3 includes explicit patent provisions and requirements related to installation information for certain “User Products,” among other changes. The Linux kernel is generally described as GPL-2.0-only, a fact that should not be blurred into “GPLv3.” A work designated GPL-2.0-or-later gives recipients an option to follow a later GPL version; GPL-2.0-only does not. SPDX identifiers provide a precise, standardized way to record such declarations. Compatibility must be assessed from the actual identifiers and texts, not from both licenses having “GPL” in their names.
The GNU Lesser General Public License (LGPL) is designed to permit certain uses of a covered library by larger programs under other terms while preserving recipients’ ability to modify and replace the LGPL component. LGPLv2.1 and LGPLv3 differ. Whether static linking, dynamic linking, headers, templates, plugins, language bindings, or a particular build arrangement meets the license’s conditions can require detailed analysis; “dynamic linking is always safe” is an oversimplification. The LGPL’s purpose is not to make a library proprietary-compatible without conditions, but to impose more limited reciprocity than the GPL in defined circumstances.
The GNU Affero General Public License (AGPL) adds a network-interaction provision to GPL-style reciprocity. In broad terms, a modified AGPL program used to provide services over a network must offer users interacting with it remotely an opportunity to receive the corresponding source. It was designed to address the “application service provider” situation in which a party benefits from modified software without distributing binaries. It does not mean that every web application is automatically AGPL, nor does it dictate source access for unrelated systems. Its compatibility and deployment consequences should be evaluated before it is adopted or incorporated.
Permissive licenses
Permissive licenses trade reciprocal source-release obligations for simpler conditions. They are widely used for libraries, infrastructure, and small utilities because a downstream recipient can include the code in open or proprietary products while retaining notices. This flexibility can increase adoption, but it also means an improved version may never return to the public. That is a design choice, not a defect that can be resolved by calling every license “open source.”
The modern MIT License, often called Expat in SPDX, grants broad permission to use, copy, modify, merge, publish, distribute, sublicense, and sell copies, subject to including the copyright and permission notice in copies or substantial portions. It includes a broad warranty and liability disclaimer. Many projects use a close textual variant, so a label such as “MIT-style” should not replace checking the actual file. The license does not itself provide an express patent grant in the way Apache-2.0 does, although patent questions can involve doctrines and facts beyond a one-line comparison.
The Apache License 2.0 also permits broad use and distribution, requires preservation of copyright, license, attribution, and NOTICE information where applicable, and includes an express patent license from contributors. It includes a patent-termination provision for a recipient that institutes certain patent litigation alleging that the work or a contribution infringes a patent. Apache-2.0 is GPLv3-compatible according to the FSF, but it is not compatible with GPLv2-only code because GPLv2 lacks terms accommodating Apache 2.0’s patent provisions. This is a classic example of why “both are open source” does not establish that code can be combined and redistributed under a chosen license.
The BSD licenses: evolution, not one text
“BSD license” is not a single historical text. The original or four-clause BSD license included: retention of copyright and disclaimer; reproduction of those materials in binary distributions; an advertising clause requiring advertising materials mentioning features or use to display an acknowledgment; and a non-endorsement clause prohibiting use of the University of California’s or contributors’ names to endorse products without permission. The advertising clause caused a practical accumulation problem: a program using many components could need to display many acknowledgments.
In 1999, the University of California, Berkeley rescinded the advertising clause for BSD-licensed material, yielding the commonly called three-clause BSD license. Its three conditions concern source notice, binary notice, and non-endorsement. The even shorter two-clause BSD license, commonly called the Simplified BSD License, retains source and binary notice requirements but omits the non-endorsement condition. SPDX distinguishes BSD-4-Clause, BSD-3-Clause, and BSD-2-Clause; they should not be casually substituted. Historical BSD releases also involved a complex transition from AT&T-licensed Unix material to freely redistributable code, a story separate from merely counting clauses in a template.
The Mozilla Public License 2.0 (MPL-2.0) illustrates weak copyleft. It generally requires source for modifications to MPL-covered files when distributing executables, while allowing a “Larger Work” containing separate files under different terms. File boundaries and the definition of a modification matter. MPL 2.0 contains patent provisions and a notice mechanism, and it includes a secondary-license mechanism for certain combinations with GPL-family licenses unless a file carries the stated incompatibility notice. It is neither simply permissive nor interchangeable with the GPL: its reciprocity reaches less broadly than the GPL’s, but it remains a conditional license.
Conditions engineers actually meet
Most compliance failures are mundane: removing a license file from a binary package, losing third-party notices in a mobile application, shipping a GPL-covered executable without complete corresponding source, or assuming a package manager’s metadata is definitive. License texts commonly require retaining copyright notices and disclaimers. Apache-2.0 has specific rules for a distributed NOTICE file. GPL licenses have source and copy-of-license requirements in distribution scenarios. A release process should make those actions routine rather than leave them to a final audit.
component: example-parser
declared license: Apache-2.0
copyright notice: Copyright 2024 Example Authors
distribution action: include LICENSE and applicable NOTICE text
component: tool-x
declared license: GPL-3.0-or-later
distribution action: provide the corresponding source for the conveyed buildThis sketch is a recordkeeping aid, not a compliance determination. A Software Bill of Materials can help identify components, versions, and declared licenses, and SPDX supplies identifiers and expression syntax such as MIT OR Apache-2.0 or GPL-2.0-only WITH Classpath-exception-2.0. It cannot prove the copyright owner had authority, that generated output lacks third-party code, or that a dependency was integrated in a legally compatible way. Automated scanners find candidate texts; people must investigate exceptions, dual licensing, headers, and provenance.
Patent grants and trademarks are separate issues
Copyright permissions are not the whole intellectual-property picture. Apache-2.0 and MPL-2.0 contain express patent grants with stated limitations; GPLv3 has patent provisions. MIT and BSD texts do not offer the same express grant language. That comparison does not establish whether a product is safe from patent claims, since patent scope, ownership, exhaustion, jurisdiction, and other agreements matter. A license’s warranty disclaimer also means recipients should not assume authors promised fitness, security, or noninfringement.
Trademarks are separate again. An open-source license may permit code modification while a project’s trademark policy limits use of its name or logo for a fork. This is often what lets users distinguish an official release from an altered distribution. Copyright licenses also do not automatically convey rights to data, documentation, fonts, model weights, hosted APIs, or a project’s domain name. Accurate reuse decisions identify the asset and right at issue rather than treating “open source” as a universal permission slip.
Public domain and CC0
A work in the public domain is not protected by copyright in the relevant jurisdiction, or has been dedicated there so that anyone may use it without copyright permission. Works can enter the public domain when copyright expires, when they are ineligible for protection, or under particular statutory rules. The exact status can vary by country and by date; a United States government work may be public domain in the United States under 17 U.S.C. §105 while rights can differ elsewhere. “No copyright intended” in a README is not a reliable worldwide dedication.
Creative Commons developed CC0 as a public-domain dedication tool with a fallback license intended to operate where a complete waiver is unavailable. It attempts to waive copyright and related rights as far as possible and, if that waiver is ineffective, grants broad fallback permissions. CC0 is commonly used for datasets and small code samples, though organizations may prefer a software-specific license with clear notices, patent language, and established tooling. Creative Commons itself recommends against using its general licenses for software and points to software licenses instead. A CC0 declaration does not erase third-party rights in material the declarant did not own.
Contribution and inbound rights
Outbound licensing is only half the problem: a project must have authority to grant rights in incoming contributions. A Developer Certificate of Origin (DCO) asks contributors to certify, typically through a signed-off commit, that they have the right to submit their work under the project license. A Contributor License Agreement (CLA) is a separate agreement that may grant the project or a steward additional copyright and patent rights. Some projects require neither, relying on contribution terms and copyright law; others use one or both. None should be described as automatically good or bad without reading its terms and considering who receives the grant.
Dual licensing is another common model. A rightsholder can offer the same code under, for example, GPL terms to the community and a commercial license to customers that need different permissions. This is possible only where the licensor controls enough rights or has appropriate contributor agreements. Forks, bundled dependencies, and external contributions can complicate that control. “Open source” does not prevent paid licensing; the relevant question is which license the recipient selected and whether the licensor can offer it.
Choose and describe precisely
There is no universally correct license. Copyleft can ensure that distributed improvements remain available under comparable rights; permissive licensing can maximize reuse across proprietary and open systems; weak copyleft can protect changes to a component while permitting a larger combination; public-domain tools can minimize copyright restrictions. The choice should match maintainers’ goals, contributors’ rights, dependencies, patents, trademark plans, and expected distribution. It should also use an unmodified, recognized license text where possible, because inventing a “simple” custom clause creates ambiguity and compatibility work.
For users, the disciplined approach is similarly modest: identify the exact license and version, locate notices, determine what is being distributed, preserve required materials, and seek legal review where needed. A license label is technical metadata with real legal consequences. Precision serves both the people who want their work shared freely and the people who need to incorporate it responsibly.