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.
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:
The oppositions are here:
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 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.
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.
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.
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:
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.
“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.
On June 8, 2020, Lynwood Investments CY Limited brought a lawsuit in the Northern District of California against various NGINX entities, various individuals, Runa Capital, E.venture Capital Partners II, LLC and F5 Networks, Inc., alleging the improper release and subsequent use of the popular open source software NGINX (pronounced “EngineX”), as part of a conspiracy to misappropriate corporate assets. All of the following is according to the complaint:
The NGINX software was developed primarily by Igor Sysoev, who is named as a defendant in the complaint, while he was employed at Rambler Internet Holdings LLC (“Rambler”), a Russian entity. (The plaintiff in the lawsuit, Lynwood, is an assignee of Rambler.) Sysoev also developed a commercial extension called NGINX Plus. This development was done in the course of employment and using Rambler resources. Rambler alleges that it owned the software by virtue of the work-made-for-hire doctrine (albeit its Russian equivalent).
Sysoev was employed by Rambler from 2000 until 2011. NGINX software was first developed in 2001, and released in 2004 under the BSD license. For the next seven years, Sysoev continued to be the primary author of NGINX code, making commits during what the complaint describes as “business hours.”
Sysoev’s supervisor was Rambler’s CTO, Maxim Konavolov. The complaint states, “Konovalov’s key senior management position at Rambler enabled him to provide Sysoev beginning in 2008 with an ecosystem within Rambler that was free from oversight or accountability.”
The complaint goes on to say, “Even though Konovalov and the rest of the Disloyal Employees were fixated on misappropriating the NGINX Enterprise, which they viewed as a highly valuable business, Konovalov uniformly gave the NGINX Software a rating of “1” on a scale of “1-5” with “1” being deemed “worthless” or “no value.” Konovalov’s designations were designed to … lull Rambler into complacency with respect to the value of the NGINX Software” and to avoid “any serious oversight by Rambler’s senior management or board of directors.”
While still employed at Rambler, Sysoev, with Konavolov and several other colleagues, formed a new company called NGINX, Inc., and obtained financing from defendants Runa Capital and E.Venture Capital (then, BV Capital). The complaint alleges that Runa Capital and E.Venture “knew … that Rambler maintained the ownership rights to the NGINX Software” but nevertheless “assisted and encouraged Sysoev and Konovalov while they were still employees at Rambler, to breach their duties to Rambler … for the benefit of the fledgling business that Sysoev and Konovalov were forming.” The complaint makes much of a trademark application filed by NGINX, Inc. on its first day of incorporation claiming first use of NGINX in commerce in commerce on March 1, 2011, a date on which the team were still employed at Rambler.
The funding of the new entity was not without its challenges. “Greycroft pulled out of the closing because its concerns over Rambler’s ownership of the NGINX Software…. In contrast, Runa Capital and BV Capital went forward and closed on the Series A financing on or about October 23, 2011 after conducting their own due diligence, with full knowledge that Rambler was the legal owner of the entire NGINX Enterprise ….”
NGINX, Inc. was sold in 2019 for $670 million to F5 Networks, Inc., also named as a defendant. The complaint alleges that as a result of due diligence, “F5 was aware prior to the consummation of the merger that the conspirators had stolen the NGINX Enterprise from Rambler…”
Rambler and Lynwood learned of the defendants’ alleged conspiracy when a whistleblower provided evidence to them.
This complaint, which alleges many claims including civil conspiracy, is long, complex, and makes for dramatic reading. It promises to be just the beginning of activity in this case. It was previously reported that Rambler was pursuing a criminal case in Russia based on the facts of this lawsuit, until Russian state lender Sberbank, which owns 46.5% of Rambler, exhorted Rambler’s board of directors to stop the pursuit. Rambler apparently dropped the criminal case in late 2019, instead pursuing “negotiations” with F5.
This complaint describes a situation that is, unfortunately, becoming more common – developers have been known to write code on company time, release it under an open source license without proper authorization, and proceed to form a competing business leveraging the code, claiming the right to use the code under the open source license. In such cases, the question of authorization of the release is often key, and points up the need for companies to have a formal open source release policy. But the level of misdoing alleged in this complaint is unusual, reaching up to the CTO level. The complaint is also interesting in that it names the venture investors and buyers of NGINX, Inc. – an unusual move that seeks to circumvent the corporate veil. That is a troubling development for companies contemplating due diligence on potential investments and acquisitions.