Sixth Circuit Reminds Us to “Filter” Software

Panning for Bad Code

Software cases are few and far between here in the Sixth U.S. Circuit, which includes Tennessee along with Kentucky, Ohio and Michigan. Other U.S. Circuits have hubs for software development—e.g, California and Washington in the Ninth, Texas in the Fifth, Utah and the Tenth, Massachusetts in the First. But the Sixth Circuit is the Motown-to-Music-City circuit. Music cases we have in abundance. Software cases, not so much. But I’m a software lawyer in Tennessee, so I have to make do. Whenever the Sixth Circuit hands down a software opinion, I have to squeeze it for all it’s worth.

This is even more important when the opinion has to do with the extremely tricky issue of copyrightability. And that’s just what we got the other day in RJ Control Consultants v. Multiject. In that case, the plaintiff is a software developer who custom-made code that controls equipment manufactured and sold by one of the defendants, Multiject.¹Also at issue, but beyond the scope of this post, are technical drawings for the equipment itself, which were also made by the plaintiff. At some point, Mulitject asked the other defendant, RSW Technologies, to help manufacture the equipment. Just before Multiject made this decision, it asked the plaintiff to give it a copy of the source code, “just in case.” Three days later, Multiject told the plaintiff that it didn’t need its services. Soon afterward, RSW had designed the new equipment and was helping Multiject with the manufacture. But what was running the new equipment? It had to be the plaintiff’s software. And, indeed, it was. RSW, for its part, testified that it didn’t know the software belonged to the plaintiff, implying that Multiject presented the source code to RSW as though it had rights to it.

Is Karen motivated by the promise of copyright protection or just the feeling a job well done? “Karen, an example of a computer programmer” by skyfaller is licensed under CC BY-SA 2.0

The Lawsuit

The plaintiff registered the software code with the U.S. Copyright Office²It waited two years after these events to do so, for unknown reasons., then sued Multiject, its owner (individually) and RSW for copyright infringement. After the case had been going on for some time, the defendants moved for summary judgment. With respect to the software, they argued that the software wasn’t eligible for copyright protection at all because it was functional. After all, its purpose is to control the equipment, so matter how the software code was written, it was ineligible for copyright protection.

Not to spoil things, but this is a bad argument. All software is functional at this level of abstraction because all software controls a machine, i.e., a computer. Even in this case, where the software controls a specific piece of equipment, it’s really just controlling (or, really, instructing) a small computing device included in the equipment, which in turn controls the equipment.

Reconsider-ception

In a very strange series of procedural steps, the district court managed to grant summary judgment to the defendants without actually addressing this argument. The software code wasn’t the only copyright at issue, as it happens. The plaintiff was also suing on some technical drawings for the equipment itself. RSW had used these drawings (again, under the mistaken belief that it had permission from Multiject) to design the new equipment. Unfortunately for the plaintiff, this copyright claim was a non-starter. RSW was absolutely permitted to use the drawings in this way. Copyright law doesn’t prohibit any “use” of a copyrighted work. It only prohibits reproducing, adapting, distributing, publicly performing or publicly displaying the copyrighted work.³There’s a sixth prohibition that we don’t have to worry about.

The district court focused exclusively on the technical drawings and granted summary judgment. The plaintiff then reminded the court about the software, in a motion to reconsider. The court bizarrely denied the motion to reconsider, then reconsidered its denial of the motion to reconsider. Instead, it asked the plaintiff to produce the source code to the court, so it could review it for copyrightability. At the hearing, the court mused about how it would probably need some expert assistance for this task. Hopes must have been high for the plaintiff at this point, but for ten months, nothing happened. Then the court denied the motion to reconsider without much explanation. Then the judge promptly retired.

The Appeal

On appeal, the Sixth Circuit had little trouble affirming the district court regarding the technical drawings. But it was nonplussed about the software. It had almost nothing to work with, after all. It remanded that issue back to the district court with instructions to consider “additional evidence” from experts about copyrightability. In doing so, it explains (to us and to the new judge) a little bit about how it’s supposed to go about determining copyrightability. The starting point is exactly where the defendants started, actually: copyright doesn’t protect functionality. The problem with software is that it’s usually functional, but it isn’t necessarily entirely functional. The court must identify the functional parts of the computer code—which might consist of almost the entire thing—and filter them out as unprotectable.

Software as Princess Torte

The best analogy I can come up with right now is a recipe. Recipes are extremely functional. They just tell you how much of what you need, and what exactly do do with all that stuff. Most recipes place a premium on brevity, too. Usually (or, at least, traditionally) publisher wants as many recipes in the book as possible, and there usually isn’t much reason for flourishes. Thus, recipes are usually denied copyright protection.

The analogy breaks down, however, when you consider how long most computer programs are. Recipes are denied copyright protection because there isn’t room for creativity beyond what’s necessary to instruct you. But imagine if the recipe was extraordinarily long, even longer than the notorious “Prinsesstarta” from the Great British Bake-Off/Baking Show. Imagine the recipe when on for about 20 pages and was so complex that, every once in a while, you had to stop and explain to the reader what’s going on. At some point, we assume there’s some isolated chunks of creativity above and beyond what’s necessary to instruct the reader, even if you’re trying your hardest to be efficient.

An exception that helps prove the rule is the Toner Loading Program in Lexmark v. Static Control Components.That program was tiny, executing only eight discrete commands. It was a lot like an ordinary recipe. The Sixth Circuit in that case held such a program probably wasn’t protectable by copyright.⁴The court ultimately concluded the program wasn’t protectable for a slightly different reason, thus avoiding remand on that issue. Most computer programs, however, are much, much longer and, thus, much more likely to be protected. In the court’s colorful language, the Toner Loading Program was to an operating system what a lamppost is to the Sears Tower.

That’s a … Choice

The problem with the defendants’ argument, then, was that it wasn’t granular at all. The software as a whole might be functional, but its code might contain isolated nuggets that go above and beyond what’s necessary to instruct the computer. The analysis, the Sixth Circuit suggests, is almost line by line (which seems too fine to me). And the test is whether the lines of computer code are “intertwined” with the functionality. Creativity, in copyright law, is often measured in terms of “choice.” The more choices available to the author, the more creative the work.

But it’s not that simple with software. With computer code, efficiency is valued. Efficient code is easier for others to understand, the computer doesn’t have to work as hard, and the code is easier to debug and improve upon. Such efficient code isn’t protected, but not because there aren’t other ways to write it. Indeed, there is almost certainly many other ways to write the code, but they’ll all be much less efficient. Such efficient code isn’t protected because there aren’t any other efficient ways to write it. It’s weird, but bad code is easier to protect than good code. It’s almost like panning for gold but in reverse. It’s almost all gold, and you’re looking for nuggets of dirt.

Software as Tragedy or Comedy

The Sixth Circuit also held that “scènes à faire” must be filtered out as non-protectable. The term derives from play writing. Certain characters were “stock”—e.g., the boastful soldier—and thus in common to all playwrights. In copyright law, the term has been expanded to include anything that’s in the authors’ “toolbox.” You can think of a stock character as a “tool” in a playwright’s “toolbox,” for example.

In the context of software, the term has come to include external considerations that dictate how the software must be developed and written. For example, an application developer will need to tailor the software to work with a certain operating system. In addition, there will be conventions that software developers will use because (1) that’s what they were taught, and (2) that’s what other developers will expect. Again, you normally want your code to be easily understandable by others, so it can be debugged and improved.

Getting into the Weeds (Bring a Machete)

Normally, we don’t have to get into the weeds of computer code in software cases. The vast majority of copyright claims involving software involve the wholesale copying of a substantial program. If the copyright in the computer program is valid, then the court can safely assume 1) there is at least one chunk of creative code, and 2) the defendant copied it. The only time we have to get into the weeds is when the copying was partial. If the defendant took only parts of the program, then we must examine those parts to see if they have creative elements. If not, then there’s no infringement.

The Sixth Circuit assumes that we need to get into the weeds. But it’s actually unclear whether RSW copied the computer code wholesale or only partially. All we know is that the defendants “used” the software in the “assembly and wiring of the new control systems.” Perhaps RSW just used the plaintiff’s code as a kind of starting point for its own code. Or perhaps it just made a few improvements to it.

If wholesale, the case should be effectively over, with a victory for the plaintiff. This is because the plaintiff registered the computer code within five years of “publishing” it. One of the benefits of timely copyright registration is a presumption of validity that attaches to the copyright.⁵The code was registered in time for the presumption of validity, but not in time to be eligible for statutory damages. And part of copyright validity is that the work, as a whole, is sufficiently “original,” i.e., has a modicum of creativity. All this discussion about filtering out functional elements and scènes à faires is really to get at the “original” elements of the code.

Like all presumptions, the presumption of validity can be rebutted. But it’s up to the defendant to rebut it by putting forth evidence that at least calls into question whether the software code really has any original elements. In this case, there doesn’t appear to be any evidence from the Multiject or RSW that the plaintiff’s code wholly lacked originality.

Feeling Abstracted

It’s a little disappointing that the Sixth Circuit didn’t give us more guidance about how to conduct the “filtering.” Several circuits have adopted the Second Circuit’s “abstraction-filtration-comparison” method from Computer Associates v. Altai. This method acknowledges that computer code can be protected not only at the level of lines of code, but at higher levels of abstraction, such as how a large, complex program is organized. (This is analogous to how copyright protects not only words on the page of a novel, but also the novel’s story, if sufficiently detailed.)

You start at the highest level of abstraction that you think can support copyright protection, filter out the non-protectable elements at that level, the compare what’s left with the accused code and see if there are any matches. Then you go to the next level of abstraction down and repeat the process until you’ve run out of levels of abstraction.

The alternative view is found in Whelan Associates v. Jaslow Dental Laboratory. There, the Third Circuit instructed us to determine the computer program’s “purpose,” then filter out anything necessary to achieve that purpose. What’s left is protectable expression. Though still good law in the Third Circuit, Whelan hasn’t proved popular because it assumes that, so long as there are multiple ways to achieve the program’s purpose, that part of the program is expressive. This problem is compounded by taking far too broad a view of a computer program’s purpose. In Whelan, the purpose was the “efficient organization of a dental laboratory,” which is so broad that there will always be multiple ways to achieve it.

Alas, this case (like the Lexmark case) wasn’t a good vehicle for this. The record was just too undeveloped. The district court did no filtering whatsoever, so the question of whether it had done the filtering correctly never came up. However, I think we can safely say that both RJ Control and Lexmark are inconsistent with Whelan. But that doesn’t automatically mean Computer Associates‘ abstraction-filtration-comparison method has been adopted here in the Sixth Circuit.

Obligatory Mini-Rant

Software is protected by a hodgepodge of laws (mostly, but not exclusively, federal). There’s a lot of overlap, and a lot of gaps in protection. Copyright is preeminent, though. It’s a lot cheaper (and more certain) than getting a patent, and it only requires originality, not novelty. Trade secret law requires you to prove not only secrecy (which isn’t always possible), but also competitive advantage of the trade secret’s secrecy⁶Note: not the trade secret’s subject matter, but the fact that it’s secret., which in turn might require proof that the putative trade secrets go above and beyond what every software engineer knows how to do. Trade secret law also requires you to identify the specific trade secrets, which can also be tricky.

But copyright law is full of its own problems, some of which have already been explained above. Copyright law is counter-intuitive under the best of circumstances, but with software, it’s especially counter-intuitive. If you ask software developers to explain what’s creative about coding, they’d usually speak in terms of elegance or efficiency. But contrary to what the Sixth Circuit said (in dicta) in Lexmark, elegance is less protectable than “idiosyncratic” code, thanks to the merger doctrine. Copyright law simply doesn’t encourage good coding, just lots of it.

So, I’d argue that software needs its own sui generis form protection. Then again, despite what a mess software law is (and it has been my entire career), it’s not as though the production of computer code (good and bad) has been slowed down by the difficulty of protection. Perhaps the veneer of protection afforded by copyright law has been enough, after all.

Thanks for reading!

Rick Sanders

Rick is currently General Counsel for Software Freedom Conservancy. Previously, he has been practicing law as an intellectual-property litigator since 2000.