What a Software License Does to a Copyright Default

The legal default for a program is that nobody except the author may copy it. Copyright attaches when a work is fixed in a tangible medium, and source text written into a file is fixed; no registration, notice, or filing is required for the rights to arise. The Berne Convention removed formalities as a condition of protection, which is why a file created this evening is protected tomorrow morning. Registration survives in some jurisdictions, notably the United States, not as a condition of ownership but as a precondition for bringing suit and for certain statutory remedies.

That default is what the phrase “all rights reserved” describes. It is not a mechanism and not a clause anyone negotiated; it restates the position the law already takes. A license is the instrument that changes the position: it states which exclusive rights are lifted, for whom, and subject to which conditions. Whatever it does not lift stays with the author. Nearly every disagreement about what a license “obviously” permits comes from assuming a grant that the text does not contain.

The rights a software license has to negotiate

The rights themselves are enumerated rather than implied. United States law lists reproduction, preparation of derivative works, distribution of copies to the public, and public performance or display, and the same four categories appear in most national statutes because they descend from the same convention text. For software the first three do the work. Compiling a program reproduces it, modifying it prepares a derivative work, and shipping a binary or a container image distributes copies.

The derivative-work right is the least mechanical of the three and the most contested, because it is defined by copyright law rather than by anything in the license. Linking a library into a program, translating code to another language, and applying a patch all plausibly produce a derivative work; copying a file unchanged for private study plainly reproduces it. Because the definition is legal rather than technical, a license cannot settle it with a linking rule, and the licenses that need a link boundary build one out of permissions instead, as the file-scope and library-scope licenses do.

A grant can also be silent about rights outside copyright. Patents are the important case. Permissive licenses in the MIT and BSD family grant copyright permissions and say nothing about patents, so a contributor who holds a patent reading on the code has granted nothing explicit about it, and a redistributor’s safety rests on doctrines such as patent exhaustion and implied license rather than on a written promise. The Apache License 2.0 and the GNU GPL version 3 both add an express patent grant, and both add a clause that withdraws that grant from anyone who sues over the software.

A license is a condition, not a promise

The operative clauses of a software license are framed as permission. “Permission is hereby granted, free of charge, to any person obtaining a copy of this software, subject to the following conditions” is a conditional grant: the permission covers the listed acts only while the conditions hold. If a redistributor strips the copyright notice, the permission never applied to that distribution, and the liability that follows is copyright infringement rather than a broken promise.

The distinction between a condition and a covenant is not academic. A promise not to sue over some conduct leaves the conduct licensed even when the promise is broken; the remedy is a contract claim. A condition that fails leaves the conduct unlicensed; the remedy is the copyright owner’s full set of remedies, including injunctive relief and, where available, statutory damages that do not require proof of loss. The Federal Circuit made this explicit for an open-source license in Jacobsen v. Katzer, holding that the attribution requirement of the Artistic License was a condition limiting the scope of the grant, so violating it could be pursued as infringement rather than only as breach of contract. Which characterization applies to any given clause is still argued, and clauses written as conditions are the ones designed to be enforced that way.

Permissive terms attach attribution; copyleft terms attach the license

The two familiar families grant the same acts and differ in the conditions riding on redistribution. A permissive license attaches near-zero conditions: redistributed copies must carry the copyright notice and the disclaimer, and nothing is said about the terms of derivative works, which may therefore be distributed under any license, including a proprietary one. The Apache License 2.0 adds two: a NOTICE file must be propagated when one is supplied, and trademark rights are explicitly withheld, so no recipient receives the project name along with the code.

A copyleft license adds a condition about the license of the output. Works based on the original, when distributed, must be distributed under the same terms, so every recipient downstream receives the same permissions the original distributor had. The obligation is triggered by distribution of copies, not by use: modifying a program for private purposes and never passing a copy on engages no source-code duty at all. That boundary between use and conveyance is where most copyleft disputes actually live, and it is examined in how copyleft travels through derivative works.

/* A permissive header: the notice must travel with the copy, nothing more. */
/* SPDX-License-Identifier: MIT */

/* A copyleft header: the version choice is part of the grant. This file
   may be distributed under GPL v2 or any later version offered by the FSF;
   without the "or later" wording the grant is frozen at one version. */
/* SPDX-License-Identifier: GPL-2.0-or-later */

Those notices are conventions, not the grant itself. The grant is the license text in the repository, and the notice is the pointer that tells a reader which text to look for.

Where the grant lives when the repository is ambiguous

Which license applies to a file is a question about provenance. A repository usually carries one license file at its root, and file headers sometimes carry a different identifier; a README sometimes says something else again. When they disagree, the file-level grant travels with the file, so the accurate answer is per-file, and the accurate expression of it is a set of license identifiers attached to files rather than a single string in the package metadata. That representation exists and is the subject of machine-readable license expressions.

Silence is the more common failure. Code published with no license file is visible and not licensed; the default has not been lifted, and no amount of availability changes that. Public-domain dedications take the opposite approach and try to remove the default entirely, which is why instruments such as CC0 pair an unconditional waiver with a fallback permissive license: moral rights are not waivable in every jurisdiction, and the fallback grant is what makes the result usable where the waiver alone would not be. The alternative chosen by projects that dislike dedications is a permissive license with an explicit fallback, which achieves the same practical effect with a written grant.

The order in which the terms appeared

The shape of today’s licenses records the order in which the problems arrived. Academic and research institutions in the 1980s released code under short notices that permitted use and redistribution provided the copyright notice travelled with the copies, and the wording used at the Massachusetts Institute of Technology and in the Berkeley Software Distribution became the templates for the permissive family. The Berkeley notice acquired an extra clause requiring that advertising material acknowledge the use of the software, which is why the family is numbered: the two-clause and three-clause texts differ by exactly that advertising requirement and a related endorsement clause, and the ISC license is a later, shorter rewrite of the same grant.

The GNU project’s General Public License, first published in 1989 and revised in 1991, added the condition that the permissive notices had deliberately left out: the license of a derivative work. The project’s stated motive was that making software free by permission was insufficient if a recipient could redistribute an improved version under closed terms, since the improvement would then be unavailable to everyone else. The condition was the answer.

The vocabulary around the licenses changed later than the licenses themselves. The Free Software Foundation had used the term free software since the middle of the 1980s, and the alternative label open source was introduced in 1998, shortly after a major browser vendor announced that it would publish the source of its client. The definition attached to the new label was derived from the Debian Free Software Guidelines of 1997, which stated the criteria as properties of a license rather than of a development method: free redistribution, availability of source, permission for derived works, and neutrality about the technology and the field of use. That derivation is why the criteria language of the Open Source Definition reads as a list of license properties, since that is what it was written to be.

What follows from the default

Two consequences drive the rest of open-source practice. First, permissions are granted by copyright holders, so the effective terms of a distribution are determined by whoever holds rights in each part of it, which is why projects accumulate contribution agreements before they need them. Second, a grant already made cannot be unilaterally recalled from the recipients who received it, so a later decision by the same copyright holder changes future releases only. Everything that looks like policy in an open-source project, licensing, migration, contribution paperwork, and enforcement, is negotiation over that fixed structure: a reservation of rights that only its holders can lift.