The Case That’s More “Oracle v. Google” Than Oracle v. Google
While we wait for the Supreme Court to hand down its decision in Oracle v. Google, we can have some fun with a case that might be exactly what folks are afraid Oracle v. Google is: use of copyright law to inhibit competition unrelated (or barely related) to the copyrighted work.
The case is Pyrotechnics Mgmt., inc. v. XFX Pyrotechnics LLC, and, yes, it involves fireworks. The decision, alas, is on a motion for preliminary injunction, so it’s hard to tell if we’re really getting the whole story here. But here’s how I understand it.
It takes a lot of technology to make a good fireworks show! Photo 16925686 © Carlosphotos – Dreamstime.com
Shooting Fireworks
At issue are “digital pyrotechnics firing systems,” which I take to be computerized equipment that controls the firing of fireworks. I’m guessing this greatly facilitates the process of firing complicated patterns at just the right time.
It seems there are at least two hardware components to the system: field modules, which I guess house and shoot the actual fireworks, and a control panel. It is the control panel that the (human) operator uses to program and communicate with the field modules—at a safe distance.
One of the defendants, fireTEK, wanted to sell wireless control panels compatible with the plaintiff’s system. (It seems the plaintiff’s system is also wireless, but the opinion doesn’t emphasize that.) To do that, fireTEK had to use the same “protocol” used and developed by plaintiff.
Protocol Droid
As near as I can tell, this “protocol” is just a code for commands that tell the field modules what to do. When developing the protocol, plaintiff wanted to avoid normal English expressions that might be ambiguous. You don’t want to accidentally fire pyrotechnics when you don’t mean to.
Reading between the lines somewhat, I think there may be another reason for the protocol’s avoidance of plain English. Plaintiff’s system was developed in the early 1990’s. Memory was at a premium then, and every additional alphanumeric character took up valuable memory.
Astoundingly, the court’s opinion provides no examples of the protocol, so we’ll just have to take its word for it that it’s “creative.” Again, the record isn’t very developed right now.
The Preliminary Injunction
After fireTEK bragged about how its control panels could work with plaintiff’s system, plaintiff got ahold of one and gave it to an expert for analysis. The expert concluded fireTEK’s product “contain[ed] an exact copy of [plaintiff’s] copyrighted Protocol.” Because the record is undeveloped, I’m honestly not sure what that means. Does it mean every command found in the protocol has been loaded into the device’s hardware? Does the order of the commands matter? (It does for copyright purposes.)
The plaintiff sued and asked the court for a preliminary injunction against sale or distribution of fireTEK’s compatible control panels. The court granted that relief.1The injunction reads: “Defendants … are hereby enjoined from importing, distributing, or selling any products that infringe upon Plaintiff’s copyrighted command/control protocols as registered under Registration Number TX 8-738-709, including but not limited to the fireTK routers that incorporate or transmit those command/control protocols.”
Controlling the Strategic Ground
How is this like Oracle v. Google? In that case, Google wanted to modify Java for use as a mobile operating system. The copyright to Java’s code belonged to Oracle (Sun’s successor in interest). Java was available for license—gratis—under the General Public License, but that would require Google to make available to the public—and competitors!—its source code for its modified version of Java. Oracle offered licensing terms that would preserved the secrecy of Google’s code, but apparently those terms were too rich for Google. Instead, Google developed its own versions of the APIs without reference to Oracle’s versions (which was hard but Google had the resources). This meant the API programs themselves—or at least the “implementing” or instructional portions—were “clean” because they were independently developed.
But that wasn’t good enough because Google kept the way the APIs were organized, which is reflected in “declaring code” of each API.2Each API starts with “declaring code,” which just encodes the module’s location in the organization of the API library. The rest of the API is the exciting part that tells the computer what to do. Google did this because the number of APIs, and the relationships between them, is very complex and extensive. Google could have come up with its own organization, but that would’ve discouraged Java programmers from using the new operating system. They wouldn’t immediately know which API was called what, where it could be found in the library, or what related APIs were called.3In retrospect, it sure looks as though Google could’ve gotten away with a complete re-organization—Android was that popular. But it must have looked very different at the time.
Oracle, the owner of the copyright of everything copyright-able in Java, owned the copyright in the way the APIs were organized. And Google was definitely using that organization. Oracle, thus, was able to control Google’s use of the entire Java system by controlling a small but crucial piece of it.
Competition Bias
Generally, the U.S. legal system is biased toward encouraging competition. Competition is supposed to keep prices low, increase quality and lead to innovation.
Now, fireTEK hardly sold any of its control panels in the U.S., but there’s a good chance that they would be either (a) cheaper or (b) better than the plaintiff’s. Otherwise, they’d just fail in the marketplace, regardless of court intervention. If your control panel broke, it might be nice to have a choice of replacements. Or maybe fireTEK’s controllers could do things plaintiff’s could not.
At the same time, almost all manufacturers want to control the “after market”: replacement parts for, repairs to, upgrades of, etc., the product. It’s not just extra money, but it’s a reliable cash flow that smooths out the balance sheets. And manufacturers aren’t shy about using (and stretching) “intellectual property” law to do so.
Here, the plaintiff is able to use the copyright in 25-year-old special-purpose quasi-computer language to prevent the sale of a replacement part.
This case is, thus, even more Oracle v. Google than Oracle v. Google. Google chose to re-use the organization of Java’s API library because it was convenient. Well, very, very, very, very convenient. But it was at least possible to organize the API library in a different way.
But, here, fireTEK didn’t really have a choice. You can’t make any replacement product for plaintiff’s system without using the protocol.
Fair Use?
As you know, the question of fair use in Oracle v. Google is pending before the Supreme Court. But, at a minimum, we know that at least 12 neutral observers—i.e., jurors—think Google’s use of the way the Java API library is organized was fair.
You can make a fairly similar case for fair use here, stronger in some points and weaker in others. FireTEK is seeking to make money from its reproduction and distribution of the protocol. And it’s not transforming the protocol in any way—perhaps because the protocol has such a specific purpose that it can’t be used in any other way. The protocol is about as uncreative as you can be and still be covered by copyright. The entirety of the protocol is (apparently) being used.4This isn’t 100% clear because plaintiff so far has gotten to define the scope of the work as just the “protocol,” but what if the protocol is part of a larger system? There is zero market for the protocol by itself.
That’s kind of a close call. My own view (expressed elsewhere) is that “transformative use” is a meaningless concept when applied to software, and I would tend to stress the other factors, which would tip this case toward fair use. This is particularly so if you think interoperability is a social good that has a role in fair use analyses for software.
Methods of Operation
The doomsday scenario for software developers observing Oracle v. Google is that the Supreme Court decides the organization of the Java API library is just a “method of operation” under § 102(b). As I’ve pointed out before, § 102(b) is just the inverse of what copyright will protect, so it doesn’t add anything to the party—except in connection with software. We have, hitherto, chosen to treat software like any other “literary work,” despite their obvious differences, and this has served us pretty OK so far.
The problem occurs when we consider things like this “Protocol” or the organization of the Java API library. They are creative methods of operation. Creative (if very dull) choices were involved in their development, but thereafter, they’re just methods of operation. So far, we’ve tended to say the “creative” takes precedence over the “method of operation.” The dichotomy has always been “creative” vs. “non-creative.”
But the Supreme Court could change all that, with respect to software. It could read Congressional intent as: “actual processes or methods embodied in the [computer] program are not within the scope of the copyright law,” and that “expression” is anything but that. In other words, “method of operation” controls over creativity, not the other way around, for software.5Why is this limited to software? Because Congress made clear it intended § 102(b) to change nothing about copyright law, except for computer programs, which were a new category of protectable work at the time.
So, just as we copyright lawyers cast an excited eye toward the Supreme Court in Oracle v. Google, spare a thought for a manufacturer of digital pyrotechnics control systems in Pennsylvania.
Thanks for reading!
Footnotes
| ↑1 | The injunction reads: “Defendants … are hereby enjoined from importing, distributing, or selling any products that infringe upon Plaintiff’s copyrighted command/control protocols as registered under Registration Number TX 8-738-709, including but not limited to the fireTK routers that incorporate or transmit those command/control protocols.” |
|---|---|
| ↑2 | Each API starts with “declaring code,” which just encodes the module’s location in the organization of the API library. The rest of the API is the exciting part that tells the computer what to do. |
| ↑3 | In retrospect, it sure looks as though Google could’ve gotten away with a complete re-organization—Android was that popular. But it must have looked very different at the time. |
| ↑4 | This isn’t 100% clear because plaintiff so far has gotten to define the scope of the work as just the “protocol,” but what if the protocol is part of a larger system? |
| ↑5 | Why is this limited to software? Because Congress made clear it intended § 102(b) to change nothing about copyright law, except for computer programs, which were a new category of protectable work at the time. |
