Copywrong.
The legal basis of software licensing, the reader is no doubt aware, is copyright law. But copyright law, originally designed to protect artistic and literary works, was not crafted with software in mind. Software, after all, is a functional tool, a set of instructions designed to perform tasks, not a creative work in the traditional sense. Yet, due to historical circumstances and the lobbying of powerful interests, software has been shoehorned into this framework, leading to a range of philosophical and practical problems that continue to affect the industry today.
So how did we get here? Software began to be recognized as an important commercial product in its own right in the early 1970s. Companies naturally wanted to protect their investments in development, and pushed for a legal framework under which they could control the distribution and use of their software. As a result, in 1974, the U.S. Commission on New Technological Uses of Copyrighted Works (CONTU) was established to address how copyright law should apply. By 1980, the United States Congress had adopted CONTU’s recommendations, amending the Copyright Act to explicitly cover software.
Why copyright law, then? I doubt many developers I know consider their work literary or artistic in nature. As Pamela Samuelson has argued, software is more akin to a patentable invention than to a copyrightable literary work. The developers I know would agree that “software engineering” befits the discipline much more than “software authorship.” Unfortunately for most of us, the powerful interests pushing for legal protection of software weren’t keen on the inconvenience of demonstrating its novelty and non-obviousness, as required for a patent. Copyright law was simply a faster path, and evidently someone was able to convince someone that machine code constitutes a literary work, so why not?
To illustrate the absurdity of the situation, consider the development of an integrated circuit. Design it using CAD software (or, if it hasn’t been invented yet, manual drafting), produce a circuit diagram and a silicon die layout, and you have yourself an invention potentially eligible for patent. Nobody, to my knowledge, argued in the 1970s that chip designs ought to be considered literary works. Create the same design using VHDL or Verilog, however, and suddenly you are in copyright territory. It’s a shame these languages didn’t exist yet to force lawmakers to address this counterargument. (On the other hand, software patents are bad enough as it is, so maybe we dodged a bullet.)
The obviously poor philosophical fit isn’t the only problem with shoehorning software under the protection of copyright law. It’s also a terrible practical fit with the way software is actually developed. Legal scholars associated with the open source movement, such as Lawrence Lessig and Eben Moglen, have made great arguments about how copyright protection can thwart interoperability and generally hinder progress. I would point to an even more basic phenomenon: how many developers do you know who don’t spend half their day gathering code snippets for this and that from API docs and GitHub and StackOverflow (to say nothing of ChatGPT)?
This brings up another major issue. Copyright law traditionally protects the expression of ideas, not the ideas themselves. How does this work for software, where the expression (the code) is so directly tied to the idea (its function)? James Boyle has discussed how the traditional copyright framework struggles to accommodate this. Again, the ill fit arises from the functional nature of software. An ingenious mechanical mechanism needs to be patented, not copyrighted, because the expression worth protecting is the functional idea. Software is only treated differently because of a superficial resemblance of its “mechanism” to textual works.
Are there examples of textual works, then, to which copyright law does not apply? In fact, there is a very good one. In Baker v. Selden (1879) , the U.S. Supreme Court determined that blank forms used for accounting were not copyrightable because their purpose was functional, not expressive. The forms were tools for performing a task rather than creative expressions. This is the basis for the merger doctrine in copyright law, which holds that when an idea and its expression are closely intertwined, the expression is not eligible for protection. Clearly, software too is functional rather than expressive. Code is expressed as text, but the text is a means to a (functional) end, not an end in itself.
Unfortunately, the courts disagree. In 1983, Apple sued Franklin Computer for distributing the Apple II operating system with its own products. Franklin made precisely this argument. The court rejected it, finding that the operating system, while functional, is also expressive because it involves creative choices in its design and implementation. Other cases have since established that some aspects of software are not copyrightable, but have generally upheld the broad concept of software copyright. Most recently, Google successfully defended its copying of Oracle’s Java API declarations in creating Android, but the court sidestepped the question of functional vs. expressive, instead ruling fair use.
Copyright law has been perverted enough from its origins, with works now typically protected for a century or more, and the vast majority of the benefit going to large publishing and entertainment corporations, with the creativity it was meant to foster instead stifled by it. Applying it to software, an obvious ill fit both philosophically and practically, has been a half-century-long naked grab for power and profit by the largest technology corporations, and makes the whole concept that much less appealing to me.
Thankfully, open source software is winning. I could have written this blog post 25 years ago, less eloquently to be sure, but also with less hope for the future. Back then, the dominance of proprietary software seemed unassailable, and the idea that freely shared code could compete on a global scale was still in its infancy (who remembers XBill?). Today, however, open source has not only proven its viability but has become a cornerstone of modern software development. It represents a shift away from the restrictive and ill-fitting framework of copyright law, offering a model that better aligns with the collaborative and iterative nature of software creation. The future, it seems, belongs not to those who seek to lock down code, but to those who are willing to share it.
Comments