LAW 7688 Research Seminar: The Law of Software

James Grimmelmann

Cornell Tech

Spring 2025

Important Notice

This course is open to both law and non-law students, and to students on both the Ithaca and Cornell Tech campuses. Law students should enroll online, and non-law students should contact me to enroll.

Overview

This is a research seminar on the law of computer software. Specific topics will vary from year to year, but will typically include intellectual property protections for software, constitutional rights to create and run software, embedding legal rules in digital systems, and the regulation of complex artificial intelligence and machine learning systems. The readings will primarily consist of classic and cutting-edge legal scholarship, supplemented with materials on technical background and legal research. Over the course of the semester, participants will research and write a publishable piece of scholarship.

Credits: 3
Meetings: 60 minutes, twice per week, for 13 weeks
Grading: Student option
Satisfies the Writing Requirement: Yes

Course Outcomes

Students who complete this course will be able to:

• Understand how software works and how it is created.
• Understand the competing viewpoints on important issues on the legal treatment of software.
• Have informed and well-supported opinions on topics in software policy.
• Explain technical material clearly.
• Effectively identify the relevant scholarship on a legal issue.
• Efficiently read legal scholarship to identify the important points.
• Research, draft, and edit a work of legal or law-adjacent scholarship.

Who is This Course For?

This course is intended for students who are interested in technology law and want to improve their skills in working with legal scholarship. There are no formal prerequisites, but you should have some familiarity with software, and some familiarity with technology law.

Any of the following is sufficient background in software:

• A college-level course in computer-science.
• Programming experience.
• Significant programming-adjacent work experience (e.g., software project management or web design).
• Multiple CS-adjacent courses dealing with law and/or policy.
• TECH 5300 (may be taken simultaneously).

Any of the following is sufficient background in law:

• A law-school course in computer or Internet law.
• A law-school course in one of the topic areas of the course (e.g., the First Amendment).
• A non-law-school course in computer or Internet policy, if the readings were at least 50% primary legal sources or law-review articles.
• A research project with significant projection onto law (e.g., secure sharing of health data, ML analysis of patent documents, etc.) (may be ongoing).

This course is open to students in all graduate degree programs. Undergraduates will be admitted only in exceptional circumstances.

Policies

Please see the course policies document for information about meeting with me; inclusion; names, titles and pronouns; the history of the site where the course takes place; academic integrity and collaboration; accessibility and accommodations for disabilities; class recordings; professionalism; and health concerns.

Logistics

Contact

This syllabus is at http://james.grimmelmann.net/courses/software2025S.

Email: james.grimmelmann@cornell.edu
Huddle: Bloomberg 370
Desk: Bloomberg 3 NW, near the bookshelves

My office hours are whenever I’m free during the workday. You can sign up for a slot at https://jtlg.me/meet. When I’m on campus, we can meet in person in my huddle; when I’m not, there’s a Zoom link on Canvas. If none of the available times work for you, send me an email or DM me on the Cornell Tech Slack.

It’s also always fine just to swing by to see if I’m free. If I have headphones on, just catch my eye. If my huddle door is open, come on in. If it’s closed, it’s closed for a reason (usually a call or a meeting) – send me an email!

Required and Recommended Materials

The only required book is a legal citation manual. The nominal standard is The Bluebook, published by a consortium of four law reviews. For law students who intend to practice in the United States, the roughly $50 price tag is a reasonable investment. But for others, you can get by perfectly well with The Indigo Book, a free online reimplementation of the Bluebook’s rules. Introduction to Basic Legal Citation, by Cornell Law’s own beloved former dean Peter Martin, is a highly readable introduction to legal citation that is linked point-by-point to the Indigo Book’s rules.

Most of the remaining required readings will be articles that are accessible online through the Cornell library. A few other readings will be posted to Canvas.

Although it is not required, due primarily to the unreasonably high price, I recommend Eugene Volokh, Academic Legal Writing, a writing manual specifically targeted at law-review substance and style.

Class

Some of our sessions will be devoted to careful discussion of a substantive topic (e.g., whether software as such is patentable). The readings for those session will consist of one or more law-review articles. These will be interspersed with sessions devoted to the research and writing process (e.g., how to read law-review articles efficiently), and then shift into presentations and discussion of your research.

The course will meet in a hybrid format. We will meet in person in a room t/k and by Zoom. If you are in the Cornell Tech section, you should join in person unless you are quarantining or traveling or have another good reason to join remotely and have confirmed with me in advance. I will revisit this policy after a few weeks of class and make any necessary adjustments.

Attendance in class is required. Especially in view of the other significant demands on your time, I will be understanding about conflicts and flexible in working with you to make alternative arrangements as needed. That said, consistent unexcused absences are not okay, and may lead to a reduced grade or exclusion from the course (after reasonable written warning). Please arrive promptly. I promise that we will end on time, but that means we must start on time. Bring the readings with you, either on your computer or in hard copy.

Assignments

Your work for this class will consist of the following:

First, do the assigned readings and participate in class discussions. I expect all of you to be regular and active participants in the discussions, and to support your classmates in doing so. I understand that everyone has an off day now and then, but this class can only succeed if all of us are fully engaged.

Second, you will write a research paper of at least 10,000 words on a topic of your choosing. I will approve paper proposals on a wide variety of research subjects; the only substantive requirement is that the paper must discuss an issue in which the legal treatment of software depends on the technical details of how that software works.

The paper may conform to the stylistic and scholarly conventions of any relevant academic discipline. For example, law students may write papers in the form of a law-review Note, computer-science students may write papers in the form of an ACM conference paper, and so on. You should choose the discipline and form that will be most professionally useful to you. You are not required to submit your papers for publication, but it is my goal for the course that each of you will complete a paper you are proud enough of to want to submit.

Your deliverables for the paper will be on the following schedule:

• Week 2: Preliminary topic proposal
• Week 4: Abstract and preemption check
• Week 6: Bibliography
• Week 8: Detailed outline
• Week 10: First draft
• Week 13: Final paper
• Your paper is due on Tuesday, May 6.

I will meet with you regularly to discuss your projects. I am always available to meet to provide feedback and suggestions, even on short notice.

Grading

Your grades will be determined as follows:

• Class participation: 1/3
• Research paper: 2/3

Schedule

We will usually meet Mondays and Wednesdays 2:00 to 3:15. Our first session will be on January 22, and our final session will be May 6.

The following is a the schedule of readings from spring 2023. I will post a finalized schedule for spring 2025 by the start of the semester.

1. January 23: Introduction

   • Readings: Lawrence Lessig, The Law of the Horse: What Cyberlaw Might Teach, 113 Harvard Law Review 501 (1999)
   • Notes: This is a classic of the law-review genre, even if it is a bit atypical for law-review articles. It also provides a framework for the question this course asks: how does law change when software is involved?
   • Additional References:
     • James Grimmelmann, Regulation by Software, 114 Yale L.J. 1719 (2005) (analysis of software as a Lessigian modality of regulation)
     • Jonathan Zittrain, The Future of the Internet—And How to Stop It (2008) (Lessig-inspired theory of generativity)
     • James Grimmelmann and Paul Ohm, Dr. Generative or: How I Learned to Stop Worrying and Love the iPhone, 69 Md. L. Rev. 910 (2010) (review of The Future of the Internet)

2. January 25: What Is Legal Scholarship?

   • Readings:
     • Martha Minow, Archetypal Legal Scholarship: A Field Guide, 63 Journal of Legal Education 65 (2013)
     • Paul Ohm, Computer Programming and the Law: A New Research Agenda, 54 Villanova Law Review 117 (2009)
     • Cornell Law Review, Student-Authored Note Guide (2021)
   • Additional References: James Grimmelmann, Programming Languages and Law: A Research Agenda, CSLAW (2022)

3. January 30: Software Copyright?: Final Report of the Commission on New Technological Uses of Copyrighted Works (1978); Eben Moglen, Anarchism Triumphant: Free Software and the Death of Copyright, First Monday (Aug. 1999)

4. February 1: Legal Citation: Peter W. Martin, Introduction to Basic Legal Citation: read the What and Why section and the How to Cite section. The Indigo Book: An Open and Compatible Implementation of A Uniform System of Citation: read the Foreword, Introduction, and Background Rules sections.

5. February 6: Software Copyright:

   • Readings: Pamela Samuelson, Functionality and Expression in Computer Programs: Refining the Tests for Software Copyright Infringement, 31 Berkeley Technology Law Journal 1215 (2016)
   • Additional Resources:
     • Pamela Samuelson, Randall Davis, Mitchell D. Kapor, and J.H. Reichman, A Manifesto Concerning the Legal Protection of Computer Programs, 94 Columbia Law Review 2308 (1994)
     • Mark A. Lemley and Pamela Samuelson, Interfaces and Interoperability after Google v. Oracle, 100 Texas Law Review 1 (2021)

6. February 8: Legal Research: live in-class exercise

7. February 13: AI and Authorship:

   • Readings:
     • Jane Ginsburg and Luke Ali Budiarjo, Authors and Machines, 34 Berkeley Technology Law Journal 343 (2019)
     • Dan L. Burk, Thirty-Six Views of Copyright Authorship, by Jackson Pollock, 58 Houston Law Review 263 (2020)
   • Additional References:
     • James Grimmelmann, There’s No Such Thing as a Computer-Authored Work – And It’s a Good Thing, Too, 39 Columbia Journal of Law and the Arts 403 (2016)
     • Bruce Boyden, Emergent Works, 39 Columbia Journal of Law and the Arts 377 (2016)

8. February 15: Initial Discussion of research-paper topics

9. February 20: Software Patents: Mark A. Lemley, Software Patents and the Return of Functional Claiming, 2013 Wisconsin Law Review 905 (2012); Athul K. Acharya, Abstraction in Software Patents (and How to Fix It), 18 John Marshall Review of Intellectual Property Law 364 (2019)

10. February 22: First Amendment:

    • Readings: Andrea Matwyshyn, Hacking Speech: Informational Speech and the First Amendment, 107 Northwestern Law Review 795 (2013)
    • Additional References: Derek Bambauer, Copyright = Speech, 65 Emory Law Journal 199 (2015); Robert Post, Encryption Source Code and the First Amendment, 15 Berkeley Technology Law Journal 713 (2000)
11. March 1: AI and Speech: Tim Wu, Machine Speech, 161 University of Pennsylvania Law Review 1495 (2013); Toni M. Massaro and Helen Norton, Siri-ously? Free Speech Rights and Artificial Intelligence, 110 Northwestern University Law Review 1169 (2016); James Grimmelmann, Speech In, Speech Out, in Ronald K.L. Collins & David M. Skover, Robotica: Speech Rights and Artificial Intelligence 85 (2018)

12. March 6: Fifth Amendment

    • Readings: Orin S. Kerr, Compelled Decryption and the Privilege Against Self-Incrimination, 97 Texas Law Review 767 (2019)
    • Notes: I have three goals for reading Kerr’s piece:
      1. It’s a nice window for talking about encryption. I think it gives us a concrete way to talk about what users, companies, and governments can do to use computers to hide or access data without getting dragged into the full encryption-wars debate.
      2. Is Kerr’s doctrinal argument in Parts I and II clever, or too clever by half? Discuss.
      3. Regardless of whether you agree with Kerr’s conclusions or not, this is a beautifully written and argued article. So I plan to take a little time to look at how he puts the pieces of his argument together.
    • Additional References:
      • Orin S. Kerr and Bruce Schneier, Encryption Workarounds, 106 Georgetown Law Journal 989 (2018)
      • Aloni Cohen, Sarah Scheffler, and Mayank Varia, Can the Government Compel Decryption? Don’t Trust — Verify?
      • Orin S. Kerr, An Equilibrium-Adjustment Theory of the Fourth Amendment, 125 Harvard Law Review 476 (2011)

13. March 8: Layering:

    • Readings: Lawrence B. Solum and Minn Chung, The Layers Principle: Internet Achitecture and the Law, 79 Notre Dame Law Review 815 (2004)

    • Notes: This article is absurdly long, and I do not expect you to read every part of it closely (or necessarily at all). Instead, the article is interesting because it is an attempt to make a technical principle normative. Solum and Chung argue that the architecture of the Internet as it currently exists (as of 2004, when they were writing, that is) is layered. They then claim that laws should respect that architecture: lawmakers should not write laws that cross between layers, or that undermine the layering itself. This is an interesting kind of argument! Remember that Lessig said law can change architecture – Solum and Chung are saying that architecture should drive law.

      In class, I want to unpack their argument to see whether “law should rexpect existing software architecture” is a useful type of argument, here and in general. So I plan to walk us through several pieces of the argument:

      1. What is “layering”? Is it something that we only see on the Internet, or can other systems also be layered?
      2. Was the Internet actually layered in 2004 when they wrote? Is it layered now in 2023?
      3. Just because the Internet is layered now, does it follow that it it should be layered? (What do Solum and Chung say? Are there counterarguments? Better arguments that they fail to make?)
      4. What makes a law “layer-crossing”? Is this a coherent category, or a catch-all term for bad Internet laws?
      5. Does the layers principle imply network neutrality?
      6. Have you seen this type of attempt to make technical principles normative anywhere else? Are those other attempts persuasive?
    • Additional References:
      • The Cursed Computer Iceberg Meme
      • James Grimmelmann, Planet Telex, The Laboratorium (July 24, 2011)

14. March 13: Protocols

    • Readings: Eric J. Feigin, Architecture of Consent: Internet Protocols and Their Legal Implications, 56 Stanford Law Review 901 (2004)

    • Notes: This is another paper on the legal consequences of technical principles, published in the same year as The Layers Principle. But where Solum and Chung focus on the consequences for regulators of the fact that the Internet is designed in a particular way, Feigin focuses on the consequences for private parties and judges. Given how Internet protocols work, Feigin argues, people who use those protocols in particular ways should be treated as having consented (or not) to particular conduct. This is also an interesting kind of argument, but be clear that it is a different kind of argument than we discussed last time. Some questions we will discuss:

      1. What is a protocol?
      2. Was Feigin’s description of Internet protocols accurate in 2004? Is it accurate now in 2023?
      3. Is Feigin right that use of an Internet protocol is a kind of consent? If so, is it the kind of consent that can be withdrawn by an explicit statement to the contrary?
      4. What kind of technical information do you need about a protocol to attribute legal consequences to its use? What else do you need to know?
      5. Could someone define a new protocol that is like IP or TCP or HTTP but which does not have these consent-granting features?
    • Additional References:
      • Joshua A.T. Fairfield, “Do Not Track” as Contract, 14 Vanderbilt Journal of Entertainment and Technology Law 545 (2012)
      • James Grimmelmann, Consenting to Computer Use, 84 George Washington Law Review 1500 (2016)

15. March 15: Workshop on writing a clear abstract and introduction

    • Readings: Randall Munroe, Up Goer Five, XKCD
    • Additional References:
      • Randall Munroe, Thing Explainer: Complicated Stuff in Simple Words (2015)
      • Theo Sanderson, The Up-Goer Five Text Editor
      • Guy L. Steele, Growing a Language (1998)
      • Patrick Winston, How to Speak (2018)

16. March 20: Smart Contracts:

    • Readings: Shaanan Cohney and David A. Hoffman, Transactional Scripts in Contract Stacks, 105 Minnesota Law Review 319 (2020)
    • Notes: This is our first of two classes on blockchains and smart contracts. In my mind, at least, Cohney and Hoffman’s Transactional Scripts builds on our discussion of Solum/Chung and Feigin, because this is yet another paper about how technical facts produce legal effects. My plan of attack:
      1. What is a smart contract? (Do you agree with Cohney and Hoffman’s attempt to replace it with “transactional script”?)
      2. Was Cohney and Hoffman’s description of smart contracts accurate in 2020? Is it accurate now in 2023?
      3. Critique the following argument: “People who use a smart contract intend to have it enforce their transaction rather than have the legal system do it. Therefore, the legal system should always defer to the smart contract and should never, under any circumstances interfere with it.”
      4. Critique the following argument: “People who use a smart contract intend to enter into an enforceable agreement. Therefore, a smart contract is also a legal contract. A court should enforce the legal contract and ignore whatever the smart contract does.”
      5. What should happen when a smart contract has a bug?
      6. What should happen if A convinces B to enter into a smart contract by lying about what the smart contract does?
    • Additional References:
      • J.G. Allen, Wrapped and Stacked: ‘Smart Contracts’ and the Interaction of Natural and Formal Languages, 14 European Review of Contract Law 307 (2018)
      • Gregory Klass, How to Interpret a Vending Machine, 7 Georgetown Law Technology Review 69 (2023)
      • James Grimmelmann, All Smart Contracts Are Ambiguous, 2 Journal of Law and Innovation 1 (2019)
      • Karen E. C. Levy, Book-Smart, Not Street-Smart: Blockchain-Based Smart Contracts and The Social Workings of Law, 3 Engaging Science, Technology, and Society 1 (2017)
17. March 22: Smart Contracts:
    • Readings: Juliet M. Moringiello and Christopher K. Odinet, The Property Law of Tokens, 74 Florida Law Review 607 (2022)
    • Notes: It is fine to omit Parts II.B (NFTs and art), II.C (property theory), and III.B (policy implications). Instead, I want to focus on Moringiello and Odinet’s analysis of tethering. In a sense, tethering is the opposite problem from the previous class’s paper. One view of a smart contract is that it an attempt to use technology that is completely disconnected from the legal system. But tethering is intended to be connected to the legal system, so that the person who controls the token (as a technical matter) is the owner of an asset (as a legal matter). Thus:
      1. What is an NFT?
      2. Who owns an NFT?
      3. Was Moringiello and Odinet’s description of NFTs accurate in 2022? Is it accurate now in 2023?
      4. What is tethering?
      5. Are Moringiello and Odinet right that NFTs do not succeed at tethering?
      6. “All my apes gone”. Discuss.
    • Additional References:
      • Design Choices for Central Bank Digital Currency (Brookings Institution 2020) part 10
      • Eric D. Chason, How Bitcoin Functions As Property Law, 49 Seton Hall Law Review 129 (2019)
      • James Grimmelmann, Crystals and Mud on the Blockchain

18. March 27: Software Liability:

    • Readings: Bryan H. Choi, Software as a Profession, 33 Harvard Journal of Law and Technology 557 (2020)
    • Notes: Choi argues that software development is a profession, and that software developers should be treated as professionals for liability purposes. Professional status is a double-edged sword: in some ways the law is harder on professionals (stronger duties to their clients, higher standards of competence), and in some ways it is more forgiving (deference to the customary standards in the profession).
      1. How does the way that software is developed affect the quality of the resulting software?
      2. Was Choi’s description of software development accurate in 2020? Is it accurate now in 2023?
      3. Does the legal category of “professionals” track the everyday usage of the term?
      4. What are the reasons for treating professionals differently than others when it comes to tort liability?
      5. Is software development a profession in this sense? How does it compare to other legally recognized professions, like medicine, law, engineering, and plumbing?
      6. If developers really are professionals, are there other consequences – e.g., could the practice of software development require a license, the same way that the practice of medicine does?
    • Additional References: Michael D. Scott, Tort Liability for Vendors of Insecure Software: Has the Time Finally Come?, 67 Maryland Law Review 425 (2008). An earlier doctrinal piece that is still a good overview of the state of the law.

19. March 29: Software Liability

    • Readings: Deirdre K. Mulligan and Aaron K. Perzanowski, The Magnificence of the Disaster: Reconstructing the Sony BMG Rootkit Incident, 22 Berkeley Technology Law Journal 1157 (2007)
    • Notes: This is a post-mortem of a famous case of allegedly harmful software. We’ll ask what made it so bad, and what the law can do about it.
      1. What is DRM?
      2. What is a rootkit? Is it appropriate to describe the Sony BMG DRM this way?
      3. Why did Sony BMG put this software on CDs it sold in 2005?
      4. Was Mulligan and Perzanowski’s description of the Sony BMG DRM software accurate in 2007? Is it accurate now in 2023, or is that question now irrelevant?
      5. What kind of process should companies follow when deciding whether or not to add “features” like this to consumer software?
      6. Critique the following argument: “People can install whatever software they want on their computers. They chose to install this software. It is not the government’s place to intervene.”
      7. Critique the following argument: “Sony BMG’s software was badly coded, but there is nothing wrong with the general idea of DRM. But Mulligan and Perzanowski want a world in which DRM is unworkable because computer owners can always use their own software to crack the DRM.”
    • Additional References:
      • James Grimmelmann, Spyware v. Spyware: Software Conflicts and User Autonomy, 16 Ohio State Technology Law Journal 25 (2020)
      • Jonathan Mayer, Government Hacking, 127 Yale Law Journal 570 (2018)

20. April 10: Software as Law?:

    • Readings: James Grimmelmann, The Structure and Legal Interpretation of Computer Programs, Journal of Cross-Disciplinary Research in Computational Law (forthcoming) (on Canvas)
    • Notes: Many topics this semester are ones I’ve written on and have thoughts about, but I think it is important to show you a variety of perspectives and writing styles. Today, we explicitly consider my own take. For one thing, you can see where I’ve been coming from all semester. For another, my ideas ought to be subject to the same close critiques we’ve subjected everyone else to. This paper is a concise statement of my views about why it is necessary to “interpret” software in the same way that judges interpret laws.
      1. Is software really the kind of thing that can have a meaning at all?
      2. What is functional meaning? How should a judge ascertain it?
      3. Is my description of programming-language semantics accurate?
      4. Does it make sense to subdivide functional meaning into naive, literal, and ordinary functional meaning?
      5. Are there other kinds of meaning that software can have?
      6. Does this interpretation-based approach tell us anything useful about software copyright, the First Amendment, encryption, protocols, AI, smart contracts, or defective software?
    • Additional References: Lawrence B. Solum, Artificial Meaning, 89 Washington Law Review. 69 (2014)

21. April 12: Reidentification

    • Readings: Paul Ohm, Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization, 57 UCLA Law Review 1701 (2010)
    • Notes: This paper is a classic in the genre of arbitraging technical scholarship into law-review scholarship. We’ll ask whether it deserves that celebrated status, and if so, what Ohm does right.
      1. Why does privacy law treat “personally identifiable data” (PII) differently than other kinds of data?
      2. What defines whether data is PII?
      3. What is reidentification, and how big a problem is it?
      4. What should privacy law do, in light of the reidentification techniques Ohm discusses?
      5. How does Ohm present and summarize the technical material?
      6. How does Ohm organize the legal material?
      7. How does Ohm relate the technical material to the legal material?
    • Additional References:
      • Paul Ohm, The Rise and Fall of Invasive ISP Surveillance, 2009 University of Illinois Law Review 1417. An earlier Ohm piece in the same genre.

22. April 17: The Law-Review Submission Process: Brian D. Galle, The Law Review Submission Process: A Guide for (and by) the Perplexed (2016)

23. April 19: No class
24. April 24: Paper Presentations
25. April 26: Paper Presentations
26. May 1: Paper Presentations
27. May 3: Paper Presentations
28. May 8: Paper Presentations