The Legal Hack: Why U.S. Law Sees Open Source as “Permission,” Not a Contract

In Japan, the common view is to treat an Open Source license as a license agreement, or a contract. This is also the case in the EU. However, in the United States—the origin point for almost every aspect of Open Source—an Open Source license has long been considered not a contract, but a “unilateral permission” under copyright law. Today, informed by several court rulings, the prevailing view in the U.S. has evolved to recognize that these licenses have a dual nature, possessing aspects of both unilateral permission and contract. Despite this, within the developer community, the practical approach is often to first teach the traditional view of a license as a unilateral permission. This is likely because the “permission theory” is simpler and easier to grasp when learning the history of Open Source and the mechanisms of copyright. It may also be because, unless a situation like a license violation arises, there is no significant practical difference.

In any case, the concept of a license as a unilateral permission remains crucial for understanding Open Source today. But where did this unique feature of U.S. law originally come from?

Note: This article is an English translation of a post originally written in Japanese to explain the concept of a “license” that is often unfamiliar to a Japanese audience. While it assumes a Japanese reader, I believe it may also be useful for an English-speaking audience, especially U.S. citizens. It might help answer why the meaning of “unilateral permission” doesn’t always translate outside the U.S. and allow for a re-examination of the origins of a license concept that is naturally accepted within the United States.

The Establishment of Software Copyright and the Spontaneous Emergence of the “Unilateral Permission” for Software

This U.S.-born concept of a license as a “unilateral permission” was likely not the invention of any single person or organization. I believe it was born from the interplay of three elements: the structure of U.S. federal copyright law, the culture of early computer communities, and the case law that later affirmed it. In a sense, it is a uniquely American product.

The “Loophole” in Federal Copyright Law

The root of it all lies in the fundamental structure of the United States Copyright Act. Section 106 of the Act grants the author of a work a set of “exclusive rights,” including reproduction, modification, and distribution. This means that, by default, “no one other than the author may do anything without permission.” The traditional method for granting permission to use these exclusive rights is a “contract.” However, contracts under common law, unlike in Japanese law, come with complex requirements such as “offer and acceptance” and “consideration.” But developers around the time software copyright was being established found a kind of “hackable loophole” within this legal structure.

The U.S. Copyright Act of 1976 makes a clear distinction between a “transfer of copyright ownership” and other grants of rights:

Transfer of Copyright Ownership: As defined in Section 101, this includes exclusive licenses and, under Section 204(a), requires a written document signed by the copyright owner to be valid.
Non-Exclusive License: The same provisions explicitly state that a non-exclusive license is not included in the definition of a “transfer” of copyright.

If we interpret these legal provisions from a developer-friendly perspective, we can derive the conclusion that “a written document is not required for a non-exclusive license.” This means a non-exclusive copyright license can be established orally or even “implicitly” from the conduct of the parties. This is the crucial legal basis that allows developers to bypass the burdensome procedures of a contract and unilaterally declare that “you are free to use this software, provided you adhere to these conditions.”

The Spontaneous Emergence of the License Concept from Hacker Culture

Even if the law had such a structure, it would be meaningless without a culture to utilize it. However, in research institutions of the 1960s and 70s, represented by places like the MIT AI Lab, software was seen as “knowledge” to be shared and mutually improved. While I did not experience that era myself, various documents, including biographies of Richard Stallman and books on hacker culture, attest to the existence of this “hacker culture.”

In this environment, sharing source code was a matter of course, and a concept of “license” functioned not as a legal instrument, but more like community rules, manners, or the law of the village. As the idea of software copyright gradually took hold in the early 1980s, simple notes in README files asking users to “feel free to use this” or “please keep the author’s name” likely functioned as de facto licenses. These were not intended to be legally binding but embodied the very spirit of “unilateral permission.”

A symbolic example, for me, is the permission notice used by Richard Stallman, the future founder of GNU, for his early Emacs editor. By 1985, he had already created the “GNU Emacs Copying Permission Notice,” a document that contained ideas that would later connect to the GNU GPL, such as freedom of redistribution and encouraging the sharing of modifications. It is conceivable that such promises of reciprocal sharing became the philosophical soil for using the copyright law’s “loophole” to grant unilateral permissions.

The Formalization of Custom by the MIT License and Others

The custom of “unilateral permission” that emerged spontaneously was likely first formalized into a reusable legal document with the original MIT License used for the PC/IP distribution in 1984.

As software spread beyond specific research labs and as software copyright became established, verbal promises or simple memos created ambiguity about “how much freedom is allowed” or “what about liability,” potentially leading to legal trouble. On the other hand, hiring a lawyer to draft a license agreement just for software one wished to share was not a cost-effective option. The MIT License can be seen as a solution to this problem, translating the spirit of hacker culture directly into a legal text.

The MIT License declares that “Permission is hereby granted, free of charge, to any person obtaining a copy… to deal in the Software without restriction… subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies… The software is provided ‘as is’, without warranty of any kind…” This was the result of formalizing the community’s unwritten rules into a legally clear text. The appearance of this simple legal template made it easy for any developer to share their work with legal stability. Following this lead, the BSD license and the GNU GPL later emerged, and the concept and legal mechanism of “unilateral permission” were inherited and evolved in many subsequent licenses.

Reinforcement by Case Law

This custom of unilateral permission, born from the “loophole” in federal copyright law and hacker culture, was eventually tested in court, and the philosophy was powerfully reinforced by case law. First, the establishment of the “implied license” concept through cases like Effects v. Cohen (1990) was significant. This precedent established that a license could be granted based on the conduct of the parties, even without a written document. As a leading case establishing the principle that actions can create permission, it opened the door wide for recognizing the existence of a license based on actual circumstances, even without a formal contract, thereby providing legal backing for the reality of “unilateral permission.”

The decisive moment came with Jacobsen v. Katzer (2008), a landmark ruling in the field of Open Source compliance. In this case, the U.S. Court of Appeals for the Federal Circuit determined that a violation of an Open Source license is not merely a breach of contract but copyright infringement itself. It concluded that the obligations written in the license are conditions precedent for the license to be valid, and to violate them is to engage in unauthorized use beyond the scope of the permission. This ruling proved that the declaration of a “unilateral permission” could be enforced under federal copyright law.

It should be noted that while this lawsuit solidified the “permission theory” of licenses, it also became the starting point for the rise of the “contract theory.” But I will save the discussion of the contract theory for another time.

The Difference with Japanese Law

In Japan, this concept of unilateral permission is not a common legal interpretation. The fundamental reason lies in the different design philosophies of the common law adopted by the U.S. and the civil law adopted by Japan and the EU. As mentioned earlier, “consideration” is a key element for the formation of a contract in common law, which can create issues when viewing a gratuitous license as a contract. On the other hand, under the civil law that Japan relies on, “consideration” is not a mandatory requirement for a contract. If there is a meeting of the minds between the parties—an agreement to “use under these conditions”—a valid “contract” is formed, even if it is gratuitous.

Therefore, when Japanese legal professionals look at an Open Source license, they don’t need to bring in a special concept like “unilateral permission.” They can smoothly understand it as a type of contract between the developer and the user within the existing framework of the Civil Code.

However, as I wrote at the beginning, it’s worth understanding that within the developer community, it is often easier to recognize a license as a unilateral permission to grasp the historical context. As such, people in our position often adopt the U.S. terminology and state that Open Source is a “permission” under copyright.

Conclusion

The U.S. concept of a license as a “unilateral permission” is a product of the interaction between technology and law, born from a trinity of a structural “loophole” in copyright law, a “hacker culture” that made sharing a rule, and “case law” that legally affirmed this custom. This flexible legal mechanism became the foundation for a wide variety of Open Source licenses, from minimalist ones like the MIT License to ideologically powerful ones like the GNU GPL. Knowing this historical background is a vital key to understanding the deep meaning behind the clauses of the Open Source licenses we use every day.

Open Source Guy