Copyleft Currents

After a few inquiries about this topic, I thought I would share some suggestions for best practices for SaaS vendors. Open source compliance for SaaS vendors is not difficult, but there are a few important nuances to keep in mind.

As a baseline, SaaS is not a high-risk business model for open source compliance. That is because most open source licenses do not have any conditions for SaaS server-side use. Generally, running software that powers a SaaS offering is not distribution, and most compliance conditions in open source licenses are triggered by distribution. (For more on that topic, see here.)

But that doesn’t mean SaaS vendors can simply abdicate responsibility for open source compliance processes. Here are a few reasons why SaaS vendors need to pay attention to open source compliance.

Client Side Software

While most software in a SaaS platform runs on the vendor’s servers, some software always runs on the user’s computer. This is sometimes called “client-side” software, because it runs on the client computer (the user’s computer) instead of the server computer. This software is pushed out to the client computer by the server, but it actually executes locally.

The best way to understand this is to look at the software. If you are using the Chrome Browser, for example, you can press Control-U or right click and chose “view page source.” There, you will see a lot of software code. Right now, as I am writing this in WordPress, the code for this authoring page is about 3,000 lines. But most of the software enabling me to write my blog is running on the WordPress.com server.

Client side code is particularly helpful for tasks like validating an entry in a form (such as a date or address) or executing simple logic on a web page (such as asking for more data if the user gives certain answers to questions). These small tasks need not ping the server and slow down processing.

One interesting thing about this client code is that it is almost always “high level” code or “scripting language” code delivered in source code format. Mostly, it consists of HTML (the scripting language for web pages), Javascript (a procedural language particularly useful for web pages) and CSS (a formatting language for web pages).

The great thing about scripting code is that it is already in source code form, so even if it is provided under a copyleft license like LGPL,(1) there is usually no need to offer additional source code.

The hidden issue, however, is that programmers usually strip licensing notices out of HTML/CSS/Javascript before sending it to the client device. That is done so the page will load faster.

So, the challenge is how to deliver notices for that code. Keep in mind that whenever you distribute software under a copyleft license like LGPL, you must not only make source code available, but you must also deliver a copy of the license. So the question is: where do you put those notices? That can be a head scratcher. One approach is to include, on the dashboard for your SaaS system, a page with the notices and links to the licenses.

But is that compliant? Clearly, most open source licenses were not written for client code. So it can be unclear where to place the notices in order to comply with the license terms. In fact, most open source notice provisions were written long before the advent of the web, and they assume that notices will be delivered in an installation folder — which only works for software in standard computing environments like Linux or Windows.

For example, the license notice requirement for LGPL 2.1 says you must “distribute a copy of this License along with the Library” and MIT requires that “this permission notice shall be included in all copies or substantial portions of the Software.” So, it seems at least plausible that notices on a separate web page are sufficient, but every license has its own language to describe where notices must be delivered.

One more nuance here: Programmers also often modify client side code in production environments to strip out “white space.” So, for example:

But when you right click and view the code, or when you view it in nearly any development tool, the tool automatically inserts white space for readability. So this is generally not considered a compliance problem. The user has perfectly feasible access to the software in the “the preferred form of the work for making modifications,” which is what LGPL requires. (See definition of Source Code here.)

Network Copyleft and Similar Licenses

Another potential issue for open source compliance in SaaS is network copyleft licenses. A handful of licenses still have compliance conditions in the absence of distribution. This issue applies to server-side code. The most common of these licenses is AGPL, which says:

“13. Remote Network Interaction…if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.”

AGPL Section 13, sometimes called the “Network Copyleft” provision

This means that if you use the software in such a way that a user can interact with it over a network, and you modify the software, you must make your modified source code available. In a way, this treats SaaS similar to distribution under GPL. And while there are still no source code sharing conditions if you don’t modify the software, it can be hard to keep track and trigger a new compliance review if the software is modified in the future. So most companies are extremely hesitant about using AGPL software in a SaaS platform.

AGPL is not the only network open source license out there, only the most common. Some others, for example are:

• Server Side Public License
• Open Software License
• Non-Profit Open Source License
• Artistic 2.0
• Apple Public Source License
• RealNetworks Public Source License
• Reciprocal Public License
• Honest Public License
• Academic Free License [Note: this license is permissive. The others are copyleft.]

Most of these licenses are rarely used, and when they are, some — notably Artistic 2.0 — are dual licensed under GPL, meaning their network requirements are easy to avoid.

Most companies that have open source compliance policies “red light” these licenses and will not use them in SaaS development. So that means, at a minimum, you must still keep track of license terms and apply your compliance polices to SaaS software.

Distribution is Inevitable

Finally, an important reason to keep an eye on open source compliance, for server side code in a SaaS platform, is that SaaS code almost always gets distributed–someday. While the thrust of software sales today is toward cloud deployment, there are many reasons the deployment of software regresses to on-premises distribution. For example:

• Your company sells off the division that sells the SaaS.
• Your customer requires a local copy on its own server:
  • Due to regulatory requirements (e.g. in highly regulated businesses like finance or health)
  • Because of security concerns
  • To avoid privacy issues arising from cross-border data movement
  • Because AWS does not maintain a local hub
• Your company productizes an internal SaaS tool.

…and so forth.

Because any of these things could happen, you should ensure that you can distribute the software in a compliant manner, when you need to. So, you should avoid integrating GPL (or AGPL) and proprietary code in a way that could not be distributed in compliance with the open source license. This, in turn, means avoiding the use of GPL libraries (like MySQL)–or at least having a replacement at hand.

No Customer Risk

One question that sometimes comes up in commercial negotiations for SaaS vendors is whether a customer of a SaaS vendor can be “infected” by open source code. In short, the answer is no.

A pure end user of code cannot incur liability for violating an open source license. Open source licenses can be violated only by re-distributing software — or in the case of network licenses like AGPL, by modifying it and making it available to others as a service. In fact, GPL2 specifically says “Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted.”

In contrast, if the vendor is distributing software to a customer for the customer to provide its own SaaS to others, customary open source diligence is appropriate. But this isn’t a SaaS deal, of course. It’s a distribution deal.

So, end user customers of SaaS need not conduct diligence into open source licensing issues. If, for example, the SaaS vendor is using modified AGPL code to provide its service to the customer, then the customer may have a right to receive source code from the vendor. But that is a benefit, not a problem. In other words, the purpose of due diligence is to reduce the user’s risk, so even AGPL is not the user’s issue.

An update: take a look at Kyle Mitchell’s follow up on this post. Client side Javascript code doesn’t have a binary form, exactly, but when deployed in actual practice, it is not exactly source code, either. It can take intermediate forms that would not be considered source code, for purposes of licenses like GPL. Point your engineers to that post!

Software Freedom Conservancy filed a lawsuit in late October 2021 against Vizio, claiming violation of the GPL and LGPL with respect to its SmartCast TVs. The complaint is here. The complaint is styled first as a claim of breach of contract, and then a claim for declaratory relief.

Lawsuits to enforce GPL are still quite rare, and among them, this one is radically different in its legal structure from those that have come before. In fact, it conflicts with much of the conventional wisdom about enforcement of licenses like GPL, even principles previously enunciated by the Software Freedom Law Center and the Free Software Foundation–who have had their disagreements with Software Freedom Conservancy in the past.

Some of the novel legal arguments include:

• Breach of Contract and Specific Performance. In the past, almost all community enforcement of GPL has been pled as a claim for copyright infringement. This complaint asks for an order for Vizio to release the source code for the product, which is the main license condition of GPL and LGPL. However, compelling a defendant to comply with a license condition is not a remedy under copyright law. In contract law, any claim for relief other than money damages is a request for specific performance–which is a very rare remedy in contract law.
• Claim Brought in State Court. As a corollary, almost all claims to enforce GPL in the past have been brought in federal court, which has exclusive jurisdiction over copyright claims in the US. The complaint was filed in Orange County, California. State court lawsuits yield less predictable and consistent outcomes than federal courts–and perhaps more likely to take an unexpected view of novel legal theories.
• No Author as Plaintiff. The complaint is brought on behalf of SFC as a plaintiff, based on its purchase of Vizio TVs. This is the opposite of past enforcement actions, brought by the copyright owners (and authors) of GPL software. The complaint cites a huge list of GPL code, including the entire Linux kernel, Busybox, coreutils, BASH, and others. None of the authors of these software packages is named as a plaintiff in the suit.
• Focus on Consumer Electronics. This is no a surprise, but it is worth noting. Consumer electronics have always been the highest risk sector for GPL enforcement. The SFC press release regarding the case emphasizes consumer rights, touching upon allegations of planned obsolescence and the environmental impact of having to replace devices instead of updating them. SFC had previously announced its intention to use its new funding to focus on embedded software and IoT.
• Declaratory Relief. The request for declaratory relief asks the court, essentially, to declare that the GPL and LGPL are enforceable and have been violated by Vizio. Even if GPL were deemed a contract, it would be a contract between the licensor (i.e. code copyright owner) and the licensee, so SFC appears to be suing based on a theory that it–and everyone–is a third party beneficiary of the contract. This theory is extremely novel. Given the code authors are not parties, this is an end run around the standing requirements for copyright claims.

In sum, the complaint is an effort to re-write the rules of GPL enforcement. While many commentators are hailing it as a boon for free software, it could backfire. Most companies who have adopted GPL software for their products over the last 25 years have done so based on the comfort that enforcement is mostly done informally, and by authors–and that injunctive relief forcing the release of source code has never been ordered as a remedy. This comfort took many years to develop. During the 1990s and 2000s, many companies adopted GPL software with great hesitation, due to fears about the possibility of such remedies. At that time, these fears were mostly fueled by FUD promulgated by anti-GPL companies like Microsoft. But if this new means of enforcement is successful, the fear may re-ignite, and adopters may react by moving away from open source software.

Also, if any member of the public can enforce the GPL, there is a potential for multiple and conflicting lawsuits for each alleged violation–including trolls who do not have the interests of the community at heart, and–as in this case–organizations who do not necessarily have the support of the authors of the software.

At this early stage the result is hard to predict, but it seems unlikely that SFC will be able to succeed on such a great number of novel legal theories. Such a case could be complex, long and expensive. Also, most GPL enforcement claims do not result in substantial litigation, and are settled quickly– often just after the initial complaint. But if not, this lawsuit has the potential of making some very unprecedented law, and substantially disrupting expectations about GPL enforcement.

An update: Vizio moved on November 29, 2021 to remove the case to federal court, alleging preemption. SFC issued an outraged blog post. Neither is remotely surprising.

And I cannot help observing something about this statement from the SFC:

We believe in complete transparency of the copyleft compliance process, and so encourage everyone to read the filings. We’ve even paid the Pacer fees and used the Recap browser plugin, so that all the documents in the case are freely available via the Recap project archives.

According to my calculations, the PACER fees for that document for SFC are somewhere between zero and 80 cents. Here is more about PACER fees and how RECAP (which is very cool) works.

Recently, accusations appeared in the press that the “Truth Social” platform are violating the terms of the Affero GPL (AGPL), which applies to the Mastodon software used to run the platform. Truth Social is run by the The Trump Media and Technology Group, which recently announced a SPAC.

AGPL is a network copyleft license that requires sharing of source code, where the licensed software allows users to interact with it via a network, and the code has been modified from its upstream source.

On October 21, 2021, Mastadon’s head developer, Eugen Rochko, stated that the software used to run Truth Social is “absolutely is based on Mastodon.” The Verge later reported that “Mastodon has sent former President Donald Trump’s company a formal notification” of breach. Tech Crunch also reported that Mastodon had issued a “30-day ultimatum.” These reports were apparently based on a Mastodon Blog post that said:

On Oct 26, we sent a formal letter to Truth Social’s chief legal officer, requesting the source code to be made publicly available in compliance with the license. According to AGPLv3, after being notified by the copyright holder, Truth Social has 30 days to comply or the license may be permanently revoked.

https://blog.joinmastodon.org/2021/10/trumps-new-social-media-platform-found-using-mastodon-code/

The terms of use for Truth Social state that its source code is proprietary “unless otherwise indicated,” and apparently the site does not provide proper AGPL license notices.

No formal legal action has yet been filed, but that is not surprising. Unlike GPL2, AGPL3 has a cure provision, so after receiving a notice of violation, a licensee has 30 days to comply, or risk losing its license permanently, after which a formal enforcement action could be filed.

The controversial nature of the Truth Social platform has generated a lot of press already. This points up the risk of violating open source licenses in a manner that conflicts with the political beliefs of the software’s author, who may be more likely to formally enforce the license against those with which the author does not agree.

Mastodon is a German non-profit. Germany has long been known as a plaintiff-favorable jurisdiction for software copyright claims, and a jurisdiction of choice for enforcing open source licenses.

An update: See PC Mag’s follow up from December 2, 2021. The Trump platform published the Mastodon code, but it’s not clear that is the code they are actually using. (In fact, there is no obligation to provide unmodified server-side code under AGPL.) The article says:

Trump’s “Truth Social” site now features a dedicated section labeled “open source,” which contains a Zip archive to Mastodon’s source code. “Our goal is to support the open source community no matter what your political beliefs are. That’s why the first place we go to find amazing software is the community and not ‘Big Tech,’” the site adds. …However, it appears the uploaded Zip archive is simply a barebones version of the existing Mastodon source code you can already find on GitHub.

So, it looks like the platform got some of the open source rhetoric right, but not the actual compliance.

This article appeared years ago in the OuterCurve blog, but the link to it is broken, now, so on request I have reproduced it — or at least an early draft of it — here. This was a companion piece to a conference at Santa Clara law school, but that link is broken, too! I am happy anyone cares to read one of my articles after so many years. I hope someone can use this information to go squish some patent trolls.

When Richard Stallman wrote in GPL2 “any free program is threatened constantly by software patents” he crystallized the ideological battle between open source software and the software patent business. In 1991 when GPL2 was released, that battle was in its nascent stages.  Today each of open source licensing and software patenting has come to its fullest flower, though their growth generally proceeds on orthogonal axes; most open source software is never accused of patent infringement and most software patent infringement suits don’t accuse open source software. In fact, they so seldom interact directly that the lawyers who practice in these areas do not overlap much. This means those defending patent infringement suits may not be thinking about the tactics open source patent licensing offers to patent defendants.

In patent litigation defense, every little bit helps. Today, patent defendants should be paying attention to open source licensing and its possible effect on patent infringement claims. When you are sued for patent infringement, by anyone other than a pure non-practicing entity (aka patent troll), one of your first lines of internal investigation should be the open source position of the plaintiff, and, if you are considering retaliatory patent claims, your own open source position as well.

When Open Source and Patents Mix

Patent lawyers may be surprised to know that while today, most companies today use open source software, most of them struggle greatly with implementing the internal controls to coordinate their use of open source software with their patent portfolio management. This means it is quite possible that a company is seeking patent protection, or seeking to enforce patents, that read on open source software the company is using or developing — a combination of activities that would often not be considered economically rational.

There have been at least two cases where defendants have successfully used open source license enforcement as a defensive tactic in a patent lawsuit. The first case is the one most often cited to support the enforceability of open source licenses; most people forget that the case started as a patent claim. In Jacobsen v. Katzer, both parties developed and distributed software for controlling model railroads — Jacobsen making his JMRI software available under an open source license free of charge, and Katzer (via his company Kamind Associates) selling commercial products under proprietary licenses. Jacobsen received a letter inviting him to license patents owned by Kamind, suggesting the patents were infringed by the JMRI software. Jacobsen filed a declaratory judgment action asking the court to rule that the patent was invalid due to prior art (or failure to disclose prior art including that of Jacobsen himself) or not infringed. As the patent case progressed, however, Jacobsen discovered that Katzer had copied some of Jacobsen’s open source software and used it in Katzer’s proprietary product, without the proper attributions and license notices. Jacobsen v. Katzer was finally settled in 2010, but only after becoming the seminal US case on open source licensing — not patent infringement — and resulting in a settlement payment by Katzer for violation of the open source license.

In Twin Peaks Software Inc. v. Red Hat, Inc., Twin Peaks Software (TPS), which made proprietary network backup software, sued Red Hat and Red Hat’s recently-acquired subsidiary Gluster. TPS claimed that the GlusterFS software — a network file system that aggregated multiple storage shares into a single volume — violated TPS’s patent covering TPS’s “Mirror File System” (MFS). Red Hat initially responded to the patent infringement suit denying the infringement and asserting that the patent was invalid, but later brought a counterclaim alleging the TPS products incorporated open source software from Red Hat’s product, without complying with GPL. Red Hat sought an injunction against the TPS products . The case ended soon in a settlement, suggesting that TPS thought better of pursuing its patent claims in light of the facts. 

In both these cases, the patent plaintiff was using open source software of the defendant, and the patent defendant discovered a violation of the applicable open source license that it used to turn the tables on the plaintiff. In this way, open source license enforcement can be a substitute for a more traditional retaliatory patent claim. In each case, the plaintiff and defendant were in similar product markets — a very common context for patent litigation — which made the use of the defendant’s open source code by the plaintiff likely. The moral of this story, for a patent plaintiff, is that one should have a robust open source compliance program in place before asserting a patent in a related space. 

Defensive Termination

There are other more subtle tactics as well. Open source licenses — particularly those written in the last 20 years — contain two kinds of provisions that bear upon patent litigation strategy. The first, and more straightforward, is the patent license. See for instance the license in Apache 2.0, which says:

 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. 

This license only applies to contributors, so a mere re-user or re-distributor of the software does not grant any rights. However, if a company has contributed to the software, under an open source license or under a similar contribution license, that company may have granted a license that can be used a defense to an infringement claim. 

For example, suppose company P (patent plaintiff) sues company D (defendant) for patent infringement. However, Company P has contributed software embodying the claims of the asserted patent to a project covered by this license The Apache 2.0 license is a permissive license, so it may be easy for D to claim it is using software under this license. Raising this as a license defense can avoid liability — or at least, create an unexpected defense that will add significant cost to prosecuting the suit.

Now consider the defensive termination provision of Apache 2.0:

If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

This means that by filing the lawsuit, P may have given up any patent licenses it has received from any contributors to the software — which may include D or third parties who may be aligned with D. This provision applies to all licensees, not just contributors. Even if D is not a contributor with patent claims to bring, bringing the claim exposes P to potential liability. Pointing this out may shift the balance in favor of the defense. 

It’s important to understand that patent defensive termination provisions in different open source licenses have different terms. Some, like Apache 2.0, are triggered by defensive claims, but some are not. Some, like MPL, (or the corresponding “liberty or death” provision in GPL3) also trigger a termination of the copyright license, making them an even more powerful defense tool. 

Open Source Due Diligence — In Patent Litigation

So, the next time you are sued for patent infringement, you have not done your homework until you know:

• Is the plaintiff using any open source software of yours (related to the patent or not) in violation of the license?
• Does the asserted claim read on any open source software you are using? If so, would the complaint trigger a defensive termination provision that might apply to the plaintiff?
• Did the plaintiff contribute to any open source project any code under terms that would include a patent license? If so, do you have a defense under that license?  

Investigating the last question can be an informational challenge, but it may not be as difficult as you think. Records regarding contributions may be available publicly, or open source projects may be willing to cooperate if it helps them defeat patent claims accusing their code. 

The drafters of open source licenses intended to use the terms of those licenses to win a war against software patents, and whether they can do that remains to be seen, but in the meantime, don’t pass up the opportunity to use the principles of open source licensing to win your battles as well.

Here is a short article on Intel’s recent run-in with a company accusing one of Intel’s open source projects — and its downstream users — of patent infringement.

The Free Software Foundation announced on June 1, 2021 that it would no longer require and assignment of rights from contributors to GCC (GNU C Compiler) project. Instead, it will require a DCO (Developer Certificate of Origin), following the practice lead by the Linux Foundation for the kernel.

This move brings the GCC project into line with community practice, and it’s a welcome development. Over the years, various contributors had refused to agree to the FSF’s contribution assignment agreement, a document that is unusual in both substance and form. As to substance, while assignments for contributions were more common a couple of decades ago, today they are quite rare; most open source projects today either use license in=out (with or without a DCO), or a CLA with a non-exclusive license grant. As to form, the FSF’s assignment contains some truly unique language about patents* that patent licensing lawyers find perplexing, causing companies to balk at making contributions to FSF projects simply because they can’t parse the terms.

Given the widespread rejection by open source communities of CLAs, the FSF’s outlier stance on its contribution terms over the years has been surprising. Its premise that “Our ability to enforce the license on packages like GCC or GNU Emacs begins with a copyright assignment” was never exactly correct. It’s the kind of statement that looks good on paper, but doesn’t make so much sense in practice. It is true that only a copyright owner or exclusive licensee can enforce a copyright. See HyperQuest, Inc. v. N’Site Sols., Inc., 632 F.3d 377, 382 (7th Cir. 2011). But that’s because a court does not want to be asked by a plaintiff to enforce a copyright, when other parties, who are not before the court, have the right to grant licenses to the defendant and inoculate the defendant from the claim.

The FSF’s assignment document, like most (of the few) that are still used in open source contributions, grants a broad license back to the assignor. (“Thus, we grant back to contributors a license to use their work as they see fit. This means they are free to modify, share, and sublicense their own work under terms of their choice.”) So, the assignment does not solve the court’s problem. In effect, an assignment with a broad license back is less like an assignment, and more like a non-exclusive license (or like joint ownership, a structure universally detested by practicing IP lawyers, because it will often cause a court to refuse to hear the infringement claim).

In practice, owning most of the code is enough to bring a claim. Most open source enforcement takes place notwithstanding that one entity does not own every line of code in the code base. Assignments in CLAs, therefore, are not a best practice, because they are both discouraging to contributors, and not necessary to engage in enforcement.

This move should pave the way for more contributors to feel comfortable contributing to GCC.

*Note: The exact text of the FSF assignment document is not readily available online, though I have seen it before in my practice. If I find it, I will update this post and quote the odd patent language.

Congratulations to the Audacity development team and Muse Group. In two significant developments, Audacity version 3 was released in March 2021 – its first major update in many years – and Muse Group announced that it has acquired the Audacity project and will take it forward as a free and open source project.

Audacity is a free and open source digital audio editing and recording application. Started by Dominic Mazzoni and Roger Dannenberg, it has clocked over 200 million downloads during its lifetime, and has been translated into dozens of languages. Eric Raymond once wrote of Audacity: “The central virtue of this program is that it has a superbly transparent and natural user interface, one that erects as few barriers between the user and the sound file as possible.” High praise, indeed.

Muse Group already runs the popular open source MuseScore notation software project and distributes the Tonebridge guitar effects app, as well as offering the Ultimate Guitar Tabs service – tools known to working musicians everywhere.

Here is more about the announcement from the Audacity site.

On a personal note, I had the pleasure to assist the Audacity team in this matter. Audacity has long been one of my open source favorite projects, one with an impressive technical quality and community. I am glad to see it get the resources and support it needs to continue to thrive and grow.

Here is Part I of a companion article to my upcoming PLI talk on the special risks and rewards of open source and standards in IoT. It was published on PLI PLUS, the online research database of PLI.

Here is Part II.

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.