Software Integrity Blog

 

Top 10 FOSS legal developments in 2019

2019 saw developments in many free and open source software legal issues, including new models, ethical restrictions, blockchain, and data and cryptography.

Top 10 open source legal issues and developments in 2019

By Mark Radcliffe, Victoria Lee and Chris Stevenson

The year 2019 continued to see the expansion of the open source software (OSS) business model. A recent Gartner survey found that 90% of enterprises used open source, which was similar to a Synopsys report from earlier this year that found that 96% of codebases included some open source software. Gartner’s survey noted that less than 50% of companies had formal open source management programs and predicted that by 2024 half of all software users would demand a complete software bill of materials. Many issues have continued over from 2018 (some issues are even older).

As open source becomes more ubiquitous, it is also affected by larger societal issues, such as #MeToo, trade wars and political issues. The validity of the open source model was demonstrated when IBM closed its purchase of Red Hat, Inc., for $34 billion. Continuing our tradition of looking back over the top 10 legal developments in free and open source software (FOSS), our selection for 2019 is as follows:

1. McHardy, the Linux system copyright troll in Germany, adopts a new strategy

Patrick McHardy, an early contributor to Linux, has been using the threat of litigation in Germany to obtain monetary settlements, essentially acting like a copyright troll. He has been active for seven and half years and is believed to have approached over 80 companies. This number is difficult to estimate because many companies have settled without a court action and, in any cases, German court proceedings are confidential. The judges of the appellate court in the Geniatech case suggested that they had significant concerns with his standing to bring the copyright claims for violation of GPLv2, and McHardy withdraw the case.

McHardy has avoided further court cases but has continued to assert compliance violations of GPLv2. Early in 2019, he shifted from his prior strategy of “settling” cases with an agreement with a contractual penalty (and then enforcing that penalty) to a new strategy of only seeking reimbursement of his time for analysis (but charging a premium for his time). Under the prior strategy, these contractual penalties could be quite significant. More recently, he has started, once again, to demand contractual penalties.

2. Richard Stallman leaves GNU, MIT and the Free Software Foundation due to statements about Jeffrey Epstein victims

Richard Stallman resigned as president and board member of the Free Software Foundation. The free software (and open source) movement owe much to Richard Stallman for his vision and persistence. However, over the years, he has made a number of comments about matters outside the FOSS movement that have made him increasingly controversial. His statements this year about Jeffrey Epstein’s victims resulted in pressure for his resignation from the Free Software Foundation.

He also resigned from MIT, and the maintainers of the GNU operating system ejected him. After praising his contributions, they noted: “Yet, we must also acknowledge that Stallman’s behavior over the years has undermined a core value of the GNU project: the empowerment of all computer users. GNU is not fulfilling its mission when the behavior of its leader alienates a large part of those we want to reach out to.” It is not clear who will take over his leadership role of the free software movement.

3. The trade war comes to OSS

In May of this year, the Department of Commerce, Bureau of Industry and Security (BIS), placed Huawei Technologies Co., Ltd., and 68 non-U.S. affiliates on the Entity List. In August 2019, BIS added 46 additional non-U.S. Huawei affiliates to the Entity List. Companies may not export, re-export or transfer any items subject to Export Administration Regulations (the “EAR”) to Huawei except in the four areas (reduced to three in August 2019) in which BIS has issued a Temporary General License, or if BIS grants a specific license.

Google immediately cut off access to its Android operating system (but was able to provide some updates under an exception from BIS) as well as Google services, such as Google Play Store. Huawei had to revert to the use of the Android Open Source Project. BIS has extended the Temporary General License several times. Huawei announced that it had been working on an alternative version of Android and would ship it with the next version of its phones. Since it seems likely that this suspension of Huawei’s access to Google’s Android operating system will be permanent, it is possible that the Android ecosystem will split into two ecosystems: one based in the U.S. and the other based in China.

4. Ethical restrictions in OSS licenses

OSS has been subject to several attempts to condition use of OSS for ethical reasons. This year, we had a number of examples of “ethical licenses.” For example, Seth Vargo, a developer, pulled his open source library project, Chef Sugar, from its repository, which made it unavailable to Chef licensees. He pulled Chef Sugar because it was being used as part of a Chef contract with U.S. Immigration and Customs Enforcement (the ICE contract was initially signed in 2014).

Initially, Chef claimed that it owned the copyright in the Chef Sugar project, but that issue was not resolved. Although the Chef CEO responded that the company would continue providing services to ICE, four days later the CEO announced that Chef would not renew the license with ICE and would donate the revenues from the ICE contracts to charities dealing with family separation.

The activist Coraline Ada Ehmke has created the Hippocratic License; she states that the license “add[s] ethics to open source projects.” The Hippocratic License adds the following provision to the MIT License: “The software may not be used by anyone for systems or activities that actively and knowingly endanger, harm, or otherwise threaten the physical, mental, economic, or general well-being of other individuals or groups, in violation of the United Nations Universal Declaration of Human Rights.” The OSI quickly noted that the Hippocratic License is not an “open source” license. Unfortunately, the additional provision makes it quite difficult to interpret the license.

5. FOSS strategy in blockchain projects

As we noted last year, many blockchain projects are licensed under FOSS licenses. The blockchain community have made some complex and unusual choices for infrastructure technologies. This year the Algorand blockchain project, a new blockchain, announced that SDKs, example applications and helper libraries were licensed under the MIT License. However, the Algorand node software is licensed under AGPLv3. Many companies’ legal or compliance departments restrict them from using software under the AGPLv3 because of the difficulty of ensuring compliance, which may jeopardize the adoption of the Algorand project by enterprises.

6. Oracle v. Google redux yet again

The Court of Appeals for the Federal Circuit (CAFC) published its second decision in the ongoing case of Oracle against Google, ruling that Google’s unauthorized use of 37 packages of Oracle’s Java application programming interface (API) in its Android operating system infringed Oracle’s copyrights. The CAFC overturned the first district court decision to find that the APIs were copyrightable and returned the case to the district court for a decision upon the fair use defense. Once again the district court found against Oracle on the basis that Google’s use of the APIs was fair use. Oracle appealed. The CAFC, once again, overturned the district court decision, finding that Google’s use of the APIs was not fair use as a matter of law. The Supreme Court granted certiorari. This case will be very important in determining the scope of copyright protection for computer software.

7. Hellwig/VMware case in Germany is terminated

In March 2015, Christoph Hellwig, a key Linux kernel developer, sued VMware in the district court of Hamburg, Germany. Hellwig asserted that VMware had violated the terms of the GPLv2 by (1) combining VMware’s proprietary code, called “vmkernel,” with Linux in a manner that created a derivative work and (2) not providing the complete corresponding source code of vmkernel under GPLv2. The vmkernel, the “kernel” of VMware’s ESXi operating system, manages the hardware and software resources of the physical server.

VMware has responded that vmkernel is not a derivative work of Linux but only interacts with Linux through the VMK API. VMware also noted that drivers working with vmkernel do not need to be Linux drivers, but according to VMware it offers a “compatibility alternative through a loadable kernel module called ‘vmklinux,’ which in association with any Linux drivers, is loaded by the vmkernel and interfaces with the vmkernel through VMK API.” The facts relating to the dispute cannot be confirmed because the complaint and other court documents are confidential under the rules of German courts.

The Hamburg court dismissed Hellwig’s complaint on the basis that Hellwig had failed to prove which components of the Linux system he had developed and whether VMware had used such components. The Hamburg Higher Regional Court dismissed the appeal against the first-instance decision and Hellwig decided not to appeal that decision. Both courts did not deal with the substantive matter of the complaint but made the decision based on insufficient proof of the right ownership or the copyright protection capability of the components taken over from Linux.

In responding to the decision, VMware announced: “With that in mind, we are pleased to share that, for reasons unrelated to the litigation, VMware has been actively working on a multi-year project with the goal of removing vmklinux from vSphere, and hopes to accomplish this in an upcoming major release.”

8. OSS business models and licenses

Many commercial FOSS companies express concern that the traditional OSS licenses permit the use of their programs by cloud service providers without providing any payments to the FOSS company. In June of this year, CockroachDB adopted the Business Source License (BSL), which was initially developed by Bruce Perens for MariaDB, one of the founders of the open source movement. The CEO of CockroachDB stated: “Today, we’re adopting an extremely permissive version of the Business Source License (BSL). CockroachDB users can scale CockroachDB to any number of nodes. They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license.

In November, Sentry also adopted the BSL. The new licenses adopted in 2018 also saw some new developments: In 2018, Redis Labs changed the license for Redis modules developed by Redis Labs from AGPL to Apache v2.0 modified with Commons Clause (these Redis modules are add-ons on top of Redis core). It introduced the Common Clause (which it added to its Apache Software License version 2) to limit the use of its product by cloud service providers. The introduction of this hybrid license was quite controversial, and Redis abandoned the Commons Clause and adopted the Redis Source Available License in March 2019 for RediSearch, RedisGraph, RedisJSON, Redis-ML and RedisBloom. Other companies have also adopted similar licenses.

9. Conflict about RAND patent licenses between projects using FOSS governance and standard setting organization governance

As FOSS has become widely prevalent as a development methodology, standard setting organizations (SSO) have been working to integrate FOSS approaches into their own processes. However, the methodologies of FOSS projects and SSOs are quite different: FOSS projects run on a more decentralized basis with very different assumptions. One particular source of friction is the common approach in SSOs that provides for members to license their patents on a royalty-bearing basis (under fair, reasonable and nondiscriminatory, or FRAND, terms). This friction was demonstrated in dueling articles (here and here) on patent licensing in open source licenses.

David Kappos, the former Commissioner of Patent and Trademarks, noted: “Instead, we found significant support for the opposite conclusion: that OSD-compliant licenses should not be assumed to grant patent licenses unless there is express language that states so. In short, an OSS licensor can choose to grant a patent license or, like MIT and Berkeley, choose not to do so, and preserve the ability for OSS and SEPs to work in tandem in advancing innovation.”

Van Lindberg, on the other hand, responded: “This is why open source and FRAND are complementary, not compatible: they rely on different intellectual property policies to generate innovation. These two development models can learn from each other, and compete with each other, but they are based upon fundamentally different underlying principles.

“It is understandable why standard-setting organizations want to incorporate OSS: open source is inexpensive, interoperable, and innovative. Standard-setting organizations have the ability to change to become interoperable with OSS: simply adopt a royalty-free IPR [intellectual property rights] policy, as many organizations have done. But those standard-setting organizations that wish to charge FRAND royalties ultimately have the same option that commercial enterprises have when dealing with open source: respect the licenses and rules that govern the usage of OSS, or take the time to create a commercial version that doesn’t have the same licensing cost.”

This difference in approach to royalty payments for patents is creating tension between the FOSS and SSO communities. And some SSO communities have claimed that they should be able to define what is “open source.” This issue is unlikely to be resolved in the near term.

10. Open source licenses extend to data and cryptographic issues

Data has been called the “new oil.” Open source concepts have been applied to data licenses (see the Linux Foundation’s Community Data License Agreement from 2017). However, this year they were applied to data and cybersecurity. For example, the Cryptographic Autonomy License (CAL) was developed by Van Lindberg, a well-known open source attorney, for Holochain. Holochain describes the licenses as follows: “For distributed apps, cryptographic keys fall into a strange middle zone between code and user data. Code is functional and provides the processes for routing and transforming user data as inputs or outputs in a computing system. User data is typically more like passive content, which may be processed, and stored by the code. Cryptographic Keys are both user data AND functional. In Holochain they orchestrate proof of authorship of data, where data is stored, who controls data, who validates the data, security and encryption of communications and storage, operation of chain structures for progressive hashing and signing which establishes its sequence and integrity, etc.”

CAL provides the following obligations for relating to user data: “Throughout any period in which You exercise any of the permissions granted to You under this License, You must also provide to any Recipient to whom you provide services via the Work, a no-charge copy, provided in a commonly used electronic form, of the Recipient’s User Data in your possession, to the extent that such User Data is available to You for use in conjunction with the Work.”

The license also permits a delay in providing source code if it deals with security flaws, which is a new and welcome approach: “You may delay providing the Source Code corresponding to a particular modification of the Work for up to ninety (90) days (the ‘Embargo Period’) if: a) the modification is intended to address a newly-identified vulnerability or a security flaw in the Work, b) disclosure of the vulnerability or security flaw before the end of the Embargo Period would put the data, identity, or autonomy of one or more Recipients of the Work at significant risk, c) You are participating in a coordinated disclosure of the vulnerability or security flaw with one or more additional Licensees, and d) Access to the Source Code pertaining to the modification is provided to all Recipients at the end of the Embargo Period.”

The Linux Foundation also continued to work on open data issues through its Joint Development Foundation (JDF): JDF worked with AWS, Genesys and Salesforce to create the Cloud Information Model, an open source data model that standardizes data interoperability across cloud applications.


Webinar: The 2019 Open Source Year in Review

Gain insights into important legal developments from leading open source legal experts Mark Radcliffe, partner at DLA Piper; Tony Decicco, shareholder at GTC Law Group & Affiliates; and Phil Odence, GM at Synopsys. Available on demand.

Watch now

 

More by this author