Open Source: The Last Patent Defense?

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.

FSF Drops Assignment Requirement for GCC

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.

Muse Takes the Baton on the Audacity Project

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.

More Fireworks in the Copyright World

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.

Conditions and Implied Licenses: Bitmanagement v. United States

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.