How programmers communicate through code, legally

Computer programming, especially in source code, is an expressive form of communication. As such, U.S. law recognizes that communication in the form of source code is protected as freedom of speech by the First Amendment. Recently, Judge G. Murray Snow got this only two-thirds right in a ruling in the U.S. District Court in Arizona. In the case of CDK Global v. Brnovich, his denial of a motion to dismiss reads (in part),

It is well-established that “computer code, and computer programs constructed from code can merit First Amendment protection.” Universal City Studios, Inc. v. Corley, 273 F.3d 429, 449 (2d Cir. 2001); see also United States v. Elcom Ltd., 203 F. Supp. 2d 1111, 1127 (N.D. Cal. 2002) (“[c]omputer software is. . . speech that is protected at some level by the First Amendment”). However, not all code rises to the level of protected speech under the First Amendment. Corley, 273 F.3d at 449. Rather, there are “two ways in which a programmer might be said to communicate through code: to the user of the program (not necessarily protected) and to the computer (never protected).” Id. Further, even where code communicates to the user of a program, it still may not constitute protected speech under the First Amendment if it “commands `mechanically’ and `without the intercession of the mind or the will of the recipient,'” Id. (describing the holding of Commodity Futures Trading Comm’n v. Vartuli, 228 F.3d 94 (2d Cir. 2000)).

(emphasis added)

But there is a third way that programmers communicate through code, even more important (for First Amendment protection) than those two ways; and if Judge Snow had read two more sentences in the Corley opinion that he cites, he would have found it: the “third manner in which a programmer might communicate through code: to another programmer.” Id. Specifically,

Instructions such as computer code, which are intended to be executable by a computer, will often convey information capable of comprehension and assessment by a human being. A programmer reading a program learns information about instructing a computer, and might use this information to improve personal programming skills and perhaps the craft of programming. Moreover, programmers communicating ideas to one another almost inevitably communicate in code, much as musicians use notes. Limiting First Amendment protection of programmers to descriptions of computer code (but not the code itself) would impede discourse among computer scholars, just as limiting protection for musicians to descriptions of musical scores (but not sequences of notes) would impede their exchange of ideas and expression. Instructions that communicate information comprehensible to a human qualify as speech whether the instructions are designed for execution by a computer or a human (or both).

Corley, Id., at 448.

Indeed, when I teach software engineering to undergraduates, I make this very important point: your computer programs do not only execute on a computer, they must be readable and understandable to humans. A successful program will endure, and must be maintained by people who, perforce, will need to understand it. Elements of Programming Style are just as essential in coding as the Elements of Style are in other writing.

One cannot blame Judge Snow: his ruling is a very brief Order denying a motion to dismiss. And perhaps the Plaintiffs’ brief missed this point as well. Still the law (the Corley precedent) is clear: There are at least three ways that source code communicates, and one of those ways is that people can read it and learn how it works.

Regulation of Dealer-Management Systems

Regarding the underlying case, CDK Global v. Mark Brnovich et al. and Arizona Automobile Dealers Association, it is not clear whether the First Amendment claims will outweigh the interests of the state in regulating commerce. The Court’s ruling summarizes the case,

Plaintiffs CDK Global LLC … develop, own, and operate proprietary computer systems known as dealer management systems (“DMSs”) that process vast amounts of data sourced from various parties. Automotive dealerships hold licenses to DMSs to help manage their business operations, including handling confidential consumer and proprietary data, processing transactions, and managing data communications between dealers, customers, car manufacturers, credit bureaus, and other third parties. Plaintiffs employ multiple technological measures—such as secure login credentials, CAPTCHA prompts, and comprehensive cybersecurity infrastructure, hardware, and software—to safeguard their DMS systems from unauthorized access or breach. Plaintiffs also contractually prohibit dealers from granting third parties access to their DMSs without Plaintiffs’ authorization.

In March 2019, the Arizona Legislature passed the Dealer Data Security Law (“the Dealer Law”). The Dealer Law regulates the relationship between DMS licensers like Plaintiffs and the dealerships they serve. Under the Dealer Law, DMS providers may no longer “[p]rohibit[] a third party [that has been authorized by the Dealer and] that has satisfied or is compliant with. . . current, applicable security standards published by the standards for technology in automotive retail [(STAR standards)]. . . from integrating into the dealer’s [DMS] or plac[e] an unreasonable restriction on integration. . . .” The Dealer Law also requires that DMS providers “[a]dopt and make available a standardized framework for the exchange, integration and sharing of data from [a DMS]” that is compatible with STAR standards and that they “[p]rovide access to open application programming interfaces to authorized integrators.” Finally, a DMS provider may only use data to the extent permitted in the DMS provider’s agreement with the dealer, must permit dealer termination of such agreement, and “must work to ensure a secure transition of all protected dealer data to a successor dealer data vendor or authorized integrator” upon termination. Ariz. Rev. Stat. Ann. §§ 28-4654(B)(1)-(3).

(internal citations omitted)

Plaintiffs argue that Arizona’s requirement to modify their software to permit interoperability is “compelled speech” (in the form of computer code that they must write), which is a violation of the First Amendment.

I am a bit skeptical of the Plaintiffs’ argument, because this case is not really about communication, it’s about operation. That is, in the CDK Global case, we need not analyze whether prior restraints on distribution of software would violate the First Amendment, because it’s not really about distribution of software. It’s about the execution of software by car dealers. Arizona is really saying, “if a car dealer uses DMS software in the course of selling cars, then the DMS software must interoperate in certain ways.” Operation of a computer program is not necessarily protected by the First Amendment, even if communication of a computer program to another person might be.

Gun plans as 3-d printer files.

On the other hand, there are parallels between the Corley case (which was about restrictions on the distribution of software that would defeat copy-protection) and restrictions on the distribution of 3-d-printing files that would produce gun parts. Professor Eugene Volokh has analyzed “Three ways of thinking about [restrictions on distributing software in a First-Amendment context]: 1. Software is like hardware. 2. Software is like instruction manuals. 3. Alexa, read this book and make me a gun.”

Again, in this case, if a state regulates the operation of a 3-d printer (forbidding the production of gun parts) this may not conflict with the First Amendment (although it certainly relates to the Second Amendment); but regulating the communication of 3-d-printer files for gun parts may have First-Amendment implications.

Caution: I am not a lawyer. No warrantee is implied on these legal opinions.