Copyleft Currents

The US District Court for the Western District of Pennsylvania issued an injunction, on March 11, 2021, in PYROTECHNICS MANAGEMENT, INC. v. XFX PYROTECHNICS LLC and FIRETEK regarding the copyright protection of “command codes” in a fireworks system.

Pyrotechnics Management filed suit July 24, 2019, alleging copyright infringement, tortious interference with prospective contractual relations, and unfair competition. fireTEK filed a motion to dismiss on October 15, 2019, and the motion was denied on October 15, 2019. Then, Pyrotechnics filed for an injunction.

Pyrotechnics makes and sells digital pyrotechnics firing systems used to create complex fireworks displays, under the brand name “FireOne.” Those products incorporate the command and control protocols.

FireOne Control Panels

https://www.fireone.com/wp-content/uploads/2018/02/Control-Panels.jpg

The FireOne field modules use the protocol to communicate with a FireOne control panel. FireTEK is a competitor of Pyrotechnics in the distribution and sale of digital pyrotechnics firing systems. FireTEK admitted at the hearing that it had created its router by reverse engineering FireOne’s control panel.

FireTEK is owned by Laurian Antoci, from Romania, and had been selling firing systems successfully for some time. YouTube videos like this one are available describing its system, and they are kind of fun to watch even if you aren’t a pyrotechnics enthusiast. (Random note: This video shows how to sync a fireworks show to music with Audacity and a few other tools. Cool stuff.) The court commented that a Youtube video demonstrated a fireTEK Router
controlling a FireOne field module using the FireOne protocols. But that wasn’t at issue — fireTEK admitted copying the protocols.

The case concerned whether the command codes were copyrightable expression, and if so, whether a defense, such as fair use, merger, scene a faire would make the infringement claims unlikely to succeed. These defenses are all common in cases involving copyright claims for material at the edge of the law’s protection.

The Court’s Injunction

To win an injunction under US copyright law, Pyrotechnics had to show a likelihood of success on the substance of its copyright claim, as well as meet certain other criteria that would justify the court awarding injunctive relief.

The court stated that “an expression of alpha-numeric characters that are original with Plaintiff and that do not flow from considerations that are external to the author’s creativity” and were created “not according to hardware standards, mechanical specifications, software standards, computer design standards, industry programming practices, or market factors.”

The court said, “Moreover, Pyrotechnics created the copyrighted command codes with attention to unique expressions that were not used by others
and were not intuitively obvious choices. External factors did not dictate the design of the FireOne Protocol such that it is lacking in originality…The precise alphanumeric expression selected by Pyrotechnics—the method by which it
chose to represent a digital 1 or a digital 0 within its system—also is uncommon, original, and intentional.”

The court was not convinced by a scene-a-faire argument, such as the one that succeeded at trial in 2016 in Cisco Systems v. Arista, a case that the EFF called copyright abuse of standard software protocols. (The jury verdict was appealed, and eventually vacated pursuant after a settlement following remand by the Federal Circuit.) So in other words, the result here is even worse copyright maximalism than in that case. The court in this case relied on the 2018 Federal Circuit decision in Oracle America v. Google for the proposition that “nothing prevented the Defendants from writing their own code to achieve the same result” and therefore a merger defense did not apply. Also, based on Oracle, it rejected a a fair use defense based on interoperability.

This judgment reflects a troubling trend of recent cases undermining fair use and similar defenses. Copyright was never meant to protect things like digital command codes. We are losing, by a death of a thousand cuts, the peace of mind that Lotus v Borland and Computer Associates once afforded innovators. And this loss is, to a great extent, being throttled by the CAFC — a court whose special subject matter jurisdiction was created to address patents, not copyrights. A few years ago it was conventional wisdom that appending a patent claim to a copyright claim was a “best practice” for plaintiffs, in order to engage in forum shopping on appeal, to the CAFC. Now, it seems, it may no longer be necessary, as we see a district court is following the CAFC’s apparent view that copyright protects just about everything.

What is a Command Code?

Now, you may wonder what these highly protectable bits of expression might be, as a result of which, all of those amateur pyrotechnicians cannot use their cool FireTEK controllers. Pyrotechnics filed a copyright registration for the Protocol (TX 8-738-709), styled “FireOne Firing System Abridged Command Format Version 1.0.”

A publicly available document from the case, Document 94-14 Filed 08/24/20, describes the command codes as having the format of a 12-byte number, with certain bytes set to indicate they are on or off.

One of the elements the court pointed to as expressive was that the Mark was used as a one and the Space as a zero. Which is basically…a binary code? So essentially, these so-called copyrightable elements are 12 bytes of data, with the bytes set as on or off in order to control the function of the firing system. That this would be a copyrightable work is dubious. It’s a little hard to believe that such a thing was ever registered by the Copyright Office, and one suspects that the material registered by the copyright office was not the firing codes, but the documentation describing them.

Then the World Changed

Most infringement claims that result in an injunction do not go to trial, because at that point, the defendant is unlikely to avoid a judgment as to the infringement claim, or the disruption to its business is already so severe that the claim is not worth fighting. So, it is common for cases to end or settle in the plaintiff’s favor after an injunction issues. In other words, even though the merits of the infringement claim have not yet been fully heard by the court, the case is probably over.

But as you may have read, the Supreme Court issued an opinion this week in Oracle America v. Google — just after the Pyrotechnics case was published, about the boundaries of copyright protection for the structure and sequence of APIs. It’s unclear at this point whether the Pyrotechnics court’s reliance on the now overturned Oracle decision by the CAFC will result in further process, such as an appeal. At least it represents a re-balancing of the relative merits of the case.

I recently prepared this white paper on the Elastic license change. Check it out on COSS Media!

Update: This paper was translated into Korean by Haksung Jang available here.

An interesting case was handed down by the Federal Circuit on February 25, 2021, discussing some software licensing issues seldom mentioned in case law. Bitmanagement Software GMBH v. United States was a dispute that involved the use of certain proprietary software, BS Contract Geo, a 3D visualization product.

The facts surrounding the license of the software are complex, but laid out in detail in the opinion. The owner of the software, Bitmanagement, and the user of the software, the US Navy, never entered into a direct or express software license. The contracting process, which took place via a reseller called Planet 9, stalled, when it was determined that the Navy’s system needs were incompatible with Bitmanagement’s software management keys. In the end, the Navy paid for some copies, but engaged in “massive free copying” (see concurring opinion, p.27) of the software with no express license to do so.

Central to the court’s finding, the parties had agreed that as a condition to the license, the Navy would use Flexera’s license-tracking software FlexWrap to monitor the number of simultaneous users of the software. It noted that the Claims Court found that Bitmanagement agreed to the licensing scheme “because Flexera would limit the number of simultaneous users of BS Contact Geo, regardless of how many copies were installed on Navy computers.” (p. 20) But the Navy did not use the FlexWrap tool as agreed. The court held that use of this management software was a condition of the license, even though the license was not in writing. The court said, “This is one of those rare circumstances where the record as a whole reflects that the only feasible explanation for Bitmanagement allowing mass copying of its software, free of charge, was the use of Flexera at the time of copying.” (p.21)

The case contains interesting statements about implied licenses to software. Implied patent licenses are a big unsettled issue in open source licensing, but the court’s statements on implied licensing in this case are not readily transferable to that context, which typically involves an express copyright license with no express patent license (such as in the BSD license or GPLv2).

The court in this case cited the settled rule that “the existence of an express contract precludes the existence of an implied-in-fact contract dealing with the same subject matter,” (citing Seh Ahn Lee v. United States, 895 F.3d 1363, 1370 (Fed. Cir. 2018) (quoting Bank of Guam v. United States, 578 F.3d 1318, 1329 (Fed. Cir. 2009)) but said that in this case, there was no express license between the copyright owner and the user, due to the license having been negotiated via a reseller. It cited Peter v. United States, 6 Cl. Ct. 768, 780 (1984) for this proposition: (“The rule that the existence of an express contract preempts an implied contract has full effect only when the parties to both contracts are the same.”).

The case also underscores that a copyright owner’s claim for use that exceeds the scope of a license and violates its conditions can be a copyright claim rather than a contract claim. The court said “the Navy’s failure to comply with the Flexera condition of the license renders the Navy’s copying outside the scope of that license. Such unauthorized copying is copyright infringement.” Interestingly, the court cited the seminal US case on open source licensing, Jacobsen v. Katzer, 535 F.3d 1373, 1380 (Fed. Cir. 2008), to support this conclusion.

The procedural posture of this case were unusual; it was an appeal of a case in the Court of Federal Claims, a specialty court for lawsuits regarding, among other things, federal procurement disputes — whereas most software license disputes come from state or federal trial courts, and are therefore less likely to be appealed to the Federal Circuit. And its facts are unusual; most software licenses are written rather than merely implied, and where they are not written, their conditions would typically be very difficult to distinguish from their covenants. But it is always good to see a well-reasoned case about these issues.

I appeared recently on a podcast by Flagsmith, an open source feature flag and remote config solution, and hosted by Ben Rometsch. We discussed the licensing and business models emerging today for commercial open source developers.

Recently, Kevin Wang and I did a webinar on open source licenses and automation, for FOSSA. Here is the companion blog.

In June 2019, the US House of Representatives Committee on the Judiciary initiated a bipartisan investigation into competition in digital markets, spearheaded by the Subcommittee on Antitrust, Commercial and Administrative Law. In its investigation, the Subcommittee examined the business practices of Amazon, Apple, Facebook, and Google. After over a year of investigation, subcommittee issued a report last week criticizing various business practices, and noting that “each platform now serves as a gatekeeper over a key channel of distribution.”

Among many other details, the report mentions issues surrounding the dominant market position of Amazon Web Services (starting on page 315). It observed, “The COVID-19 pandemic has underscored the centrality of cloud computing to the functioning of an increasing swath of businesses—highlighting how cloud services have come to resemble critical infrastructure.” (page 321).

Notably, on page 327, the report mentions the recent tension between commercial open source businesses and AWS. “Amazon’s practice of offering managed service versions of open-source software has prompted open-source software companies to make defensive changes, such as closing off advanced features and changing their open-source license to be less permissive…. Amazon’s conduct has also reduced the availability of features in open-source software. Confluent, Redis Labs, and CochroachDB, along with several other open-source software vendors, have made similar license and business model changes, reducing the level of access to their software.”

The NGINX dispute took another turn recently, as Lynwood Investments petitioned the U.S. Trademark Trial and Appeal Board (“TTAB”) to cancel six US federal trademark registrations of F5 Networks for the NGINX web server software. F5 acquired NGINX in an M&A transaction in 2019. Lynwood had previously filed notices of opposition to three pending NGINX federal trademark applications being pursued by F5.

This move appears to be the next step in Lynwood’s lawsuit against F5 and others alleging that former employees of Rambler engaged in a skunkworks project to create and later monetize NGINX, before selling it to F5.

Echoing statements in its prior lawsuit, Lynwood alleges that F5 “conducted extensive due diligence” before the acquisition, and therefore knew that the trademark registrations were fraudulent.

F5 will likely file its responses to Lynwood’s TTAB proceedings in the coming weeks.

The petitions for cancellation are here:

• 5978630 NGINX Unit
• 5973515 NGINX Controller
• 4837175 NGINX Plus
• 5973527 NGINX
• 4200791 NGINX (logo)
• 4196757NGINX

The oppositions are here:

• 88721611
• 88778862
• 88778858

Open Research Institute (ORI), a non-profit organization dedicated to scientific research for the public good, received a favorable final determination letter from the DoD regarding ORI’s worldwide microwave satellite network, which is designed to help ham radio operators support disaster communications.

In the United States, export of technology is regulated by two agencies: the Department of Defense and the Department of Commerce. The regulations for each of these agencies limit certain kinds of exports of technology, including software.

ORI has received a determination letter from the Department of Defense, stating that ORI’s international collaboration on the satellite network is not within the scope of DOD’s regulations, the International Traffic in Arms Regulations (ITAR). ORI now faces the much easier hurdle of clearance under the Export Administration Regulations (EAR), the parallel regulations of the Department of Commerce. The EAR contains certain exceptions that allow export of most open source software.

ORI’s description of the the project says that ORI’s phase 4 ground satellite network project will provide “an open source implementation of DVB-S2 and DVB-S2X for both satellite and terrestrial amateur radio use.”

In January 2020, Mycroft AI, a Missouri-based developer of an open source voice assistant, was sued for patent infringement by Voice Tech Corp., a non-practicing entity, in the Eastern District of Texas. (The suit was then dismissed and refiled in the Western District of Missouri.)

The patents at issue are both entitled “Using voice commands from a mobile device to remotely access and control a computer.” They are here and here.

The Prior Art Landscape

The claims of the patents are broad. For example, the first claim of the ‘679 patent is:

A method of accessing and controlling a computer from a mobile device, comprising: receiving audio data from the mobile device, at the computer, at an audio command interface; the audio command interface decodes the audio data into a command; the audio command interface selects, from at least one operating system and at least one application, one operating system or one application, wherein the audio command interface decides is the appropriate operating system or application to execute at least one process in response to the command; executing with the selected operating system or application the at least one process in response to the command; generating output data in response to the selected operating system or application executing the at least one process; and transmitting the output data to the mobile advice.

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&d=PALL&s1=10491679.PN.

Mycroft commented about possible prior art:

Voice technologies like the one that Mycroft is building can be traced back more than 50 years. In fact, Mycroft is named after a voice assistant that appeared in Robert Heinlein’s 1963 Hugo Award winning novel “The Moon is a Harsh Mistress”. All of the underlying technologies are described in the novel and they have been broken out time and again over the past half-century in popular science fiction. “Hal” from 2001 a Space Odyssey, Star Trek’s “Computer”, Knight Rider’s “Kitt” – all of these are examples of how voice technology might work in the real world. They’ve also been disclosed in real-world tech like Honda’s Asimo and more than 3 decades of automotive technologies from Nuance.

Troll Hunter – Mycroft’s Position on Patent Trolls, dated February 5, 2020

Using science fiction as prior art is not unheard of, but the most famous example is probably in the Apple v. Samsung case over tablet design, which involved a design patent rather than a utility patent. Inventions in science fiction suffer from the impediment of being “non-enabling” (which is legal-speak for fictional). But while we’re at it, we could throw in Halo’s Cortana.

The lawsuit was initially a set piece in NPE patent enforcement, though one wonders why patent assertion entities ever make the decision to go after open source projects. It is almost as if they are not doing their homework. Open source projects make tragically bad targets for patent lawsuits. A case in point was the patent suit against GNOME, which ended badly for the plaintiff. Open source projects — even those created within commercial enterprises — tend to have shallow pockets, but also lots of friends who hate software patents and love to help invalidate them. That is not a good combination in a defendant profile, particularly when asserting patents that seem so susceptible to prior art challenges.

The Discussion Turns Ugly

However, in this case, the war of words has tipped into a different kind of trolling on on the defendant’s side.

The tone of Mycroft’s public blog post cited above is not surprising for an open source project. It states publicly that it will not settle the lawsuit and intends to fight it out. It calls Voice Tech a bully and a troll, ending with: “Patent trolls get paid because…it is usually cheaper in the short run to pay a troll than it is to litigate. It is also cheaper to give a schoolyard bully your lunch money than it is to visit a doctor. The thing is, once you pay the bully, he’ll just come back again and again and again.” The blog pictures Montgomery “armored up” as the “troll hunter” for the metaphorical battle.

But if you look at the archived version of the blog post, it is more aggressive. The blog engaged in what were probably intended as colorful metaphors, saying, “In my experience, it’s better to be aggressive and ‘stab, shoot and hang’ them, then dissolve them in acid.” This was actually a quotation of an article about an unrelated municipal broadband ban, linked in the blog. The archived version also says, “in the long run the best way to deal with a bully is to punch him square in the face.”

Unfortunately, the archived version also reproduced email correspondence from the plaintiff’s attorney — correspondence marked as “highly confidential,” though the basis for that designation is unclear. This correspondence contained the attorney’s return email address. The resulting community “support” allegedly resulting from the blog post may have been more extreme that Mycroft expected.

In April, Voice Tech filed a motion for “Relief to Require Decorous and Civil Conduct.” That motion reproduces an email received by Voice Tech’s attorney. The email is publicly available as an attachment to the motion filed by Voice Tech. (Case 4:20-cv-00111-RK Document 1-4 Filed 02/18/20 Page 2 of 2). Though I have cited it here for transparency, I have not linked to it, because I don’t want to dignify it with any unnecessary attention. I don’t recommend reading it, but in sum, it is vulgar, threatening, and deranged, uses a wide variety of hate speech. In fact, it almost seems like a general purpose spewing of hatred, without any particular relevance to the case. And while clearly such a horrific rant would not be “decorous” conduct by a litigant, the relationship of the email to Mycroft or the blog post is not entirely clear. Voice Tech implies that Mycroft exhorted this behavior in its blog post, a practice sometimes referred to as doxing. Voice Tech asked the court to order Mycroft to “remov[e] comments that have been published on Mycroft’s website threatening, suggesting, and/or inciting violence and death to Voice Tech’s counsel.”

According to Tech Dirt, the court was sympathetic to Voice Tech’s concerns. The court ordered Mycroft to delete a portion of its post that allegedly resulted in the threats: “I’d like for everyone in our community who believes that patent trolls are bad for open source to repost, link, tweet, and share this post. Please help us to get the word out by sharing this post on Facebook, LinkedIn, Twitter, or email.” But according to Tech Dirt, “The story had gone viral on Reddit, and…some immature Reddit users did some immature things, sending … some angry emails….There was no reason to believe they were coming from Montgomery himself.” The Tech Dirt article commented, “A company should certainly have the right to notify its community that it is in the middle of a costly legal battle (one that it believes is frivolous)…” The characterization of the email attached to Voice Tech’s motion as “immature” is accurate, but woefully insufficient.

More conventionally, Mycroft has publicly stated its intention to file an inter-partes review (IPR) to seek invalidation of the patents. Such actions are expensive, but Mycroft apparently has the support of some pro bono legal help from EFF and OIN.

Special thanks to Alero Egbe of O’Melveny for help with this post.

Update written as of December 17, 2020: Unified Patents, a member-based anti-trolling initiative, has instituted a PTAB action to seek invalidation of the patent asserted in this case. The PTAB has instituted trial on all challenged claims of the patent.

Update written March 25, 2022: The US Court of Appeals for the Eighth Circuit vacated an injunction restraining Mycroft from engaging in allegedly harassing conduct because there was no evidence tying the defendants to the alleged misconduct and reassigned the case to a new district judge. Tumey v. Mycroft AI, Inc., Case No. 21-1975 (8th Cir. Mar. 4, 2022) (Erickson, J.)

Scott Peterson’s recent article, Making Compliance Scalable in a Container World, is a good explanation of some challenges and opportunities in open source compliance for software is delivered via containers. The article advocates the use of container registries to store and deliver portable compliance information. Also, it reminds us that container continue to be a challenge for open source compliance.

Today, much software is delivered via containers. A container is a standalone, executable package of software that includes everything needed to run an application: the application software, libraries for the operating system or language platforms, system tools, and configuration settings. Containerization is the “plug-and-play” way of running software, without complicated or time-consuming installation.

Most computer users are familiar with installing applications on a desktop or laptop computer. It takes a while to install them, and for an application to work, the computer must already have a variety of standard software that the application needs in order to run on the computer platform. If installing an application is like making a recipe, creating a container is opening a takeout box.

A container registry is a service that facilitates delivery of container images. It helps developers build and manage containers, and decide who can access them. So, a registry can be used to deliver containers and track information about them.

Show Me the Code

A lot of open source compliance is about managing information. Complying with open source licenses requires you to know what open source software is in your product (its bill of materials), and what licenses cover all of it.

The average software application installation on your desktop or laptop copies software into local directories, and once installed they are relatively easy to examine. In these old-style installations, it is not too difficult to figure out which binaries correspond to the source code that generated them. So, if you needed to know what open source software was included, you might be able to figure that out from an installed software directory.

But containers are opaque; once they are created, it is nearly impossible to “unpack” them to determine their bill of materials. And it turns out that associating binaries with source code is one of the keys to open source compliance.

Delivering source code upfront, where feasible, is always the best way to comply with open source license notice requirements. That is because the license notices are “baked in” to the source code. In contrast, delivering object code only, without the source code, is more work – requiring distributors to pick out the license notice files and pass them along.

Many companies struggle with providing notices for containerized software, in part because the notice requirements of the major licenses are outdated. For example:

• GPL2 requires that redistributors “give any other recipients of the Program a copy of this License along with the Program.”
• BSD requires notices to be “in the documentation and/or other materials provided with the distribution”
• MIT requires a copy of the license “in all copies or substantial portions of the Software”

These notice requirements were all written before the web came into common use, much less containers, so they presume a means of delivering software that is about 25 years out of date.

The question of how to deliver the notices “along with” or “provided with” or “in all copies” of a container can be complicated. Every year, notice delivery gets harder to accomplish, given the increasing number of open source components, and the way software is deployed in the real world – often with no user interface and with containers being spun up and down on demand. There seems little appetite for revising the licenses to include more workable notice requirements, so many users are left in a quandary about how to do the right thing.

Using Containers as a Force for Good

“We should build a container ecosystem with compliance that is portable across registries.”

Scott K Peterson (Red Hat)

Mr. Peterson’s article goes into some detailed suggestions about how to use container registries and automated tooling to help with compliance by preserving the information that associates containerized code with its source code. However, any solution using container registries needs to ensure that the means of delivery will actually fulfill the notice requirements for the licenses, and that may be a difficult problem to solve with tooling.

Fortunately, most community open source enforcers do not pursue foot foul violations when the source code has been made freely available in an effective manner, such as posting it on a publicly available web page – or, presumably, delivering information via a container registry. Such notices may or may not be in the copy or along with the software, exactly, but they help users get access to the source code nonetheless. That fulfills the spirit of the open source license, if not necessarily its exact conditions.

Is there a way to bring best practices in lines with literal license requirements by leveraging container registries? Not exactly, or at least not yet. But more information is always better than less, and more automation is the only realistic way to pursue open source compliance properly. Tooling developments in this area are worth tracking.