7 open source-related legal developments that grabbed headlines in 2016

7 notable legal developments in open source in 2016

We look at a few of the many open source-related legal developments that made headlines in 2016.

7 notable legal developments in open source in 2016
Image by : 

Internet Archive Book Images. Modified by Opensource.com. CC BY-SA 4.0

A number of interesting and notable legal developments in open source took place in 2016. These seven legal news stories stood out:

1. Victory for Google on fair use in Java API case

In 2012 the jury in the first Oracle v. Google trial found that Google's inclusion of Java core library APIs in Android infringed Oracle's copyright. The district court overturned the verdict, holding that the APIs as such were not copyrightable (either as individual method declarations or their "structure, sequence and organization" [SSO]). The Court of Appeals for the Federal Circuit, applying 9th Circuit law, reversed, holding that the "declaring code and the [SSO] of the 37 Java API packages are entitled to copyright protection." The U.S. Supreme Court declined to review the case, and in 2016 a closely watched second trial was held on Google's defense of fair use. In May 2016 the jury returned a unanimous verdict in favor of Google.

As Jeff Kaufman explains, the verdict does not change the appellate ruling concerning API copyrightability, which, however, has limited precedential significance. Fair use involves a highly fact-specific determination, and the verdict has no obvious broader legal significance. Nonetheless the result was a clear victory for Google. Oracle has filed an appeal.

Although Oracle v. Google is not a "case about open source" per se, it is notable that both sides are stewards of relevant open source platforms centered around Java development. Oracle leads the OpenJDK project, in which the APIs at issue in this case, if we regard them as copyrightable, are licensed under GPLv2 along with the Classpath Exception. The Android platform, which does not implement all Java core library APIs, is licensed mostly under the Apache License 2.0. Its Java core library API implementations were generally taken from the Apache Harmony project, which began as a pre-OpenJDK effort to develop an open source Java runtime. Late last year Google confirmed that Android Nougat would use GPL-licensed class library code from OpenJDK in place of the Apache Harmony code.

2. Censure of Patrick McHardy

Since 2014 there have been rumors of GPL enforcement lawsuits being brought against many companies in Germany by Patrick McHardy, a Linux kernel developer who was formerly the chair of the Netfilter core team. There is some discussion of the McHardy litigation in a recent Black Duck/DLA Piper slide deck.

Until 2016 there has been something of a taboo on open discussion of the McHardy lawsuits. This ended on July 18th, when the Netfilter project announced that it would "suspend" McHardy from the Netfilter core team, the first such action it had ever taken, because "severe allegations have been brought forward against the style of his license enforcement activities." Although the core team had no first-hand evidence for the allegations, which were consistent and came from "trusted sources," they noted that despite many attempts to reach McHardy he did not respond. The announcement was made in the name of the core team members, including emeritus member Harald Welte, who is well known for bringing a series of successful GPL enforcement lawsuits in Germany.

A few weeks earlier, the Netfilter core team published a statement officially endorsing the Principles of Community-Oriented GPL Enforcement, which were released by the Software Freedom Conservancy and the FSF in 2015. The core team stated that "license enforcement is a necessary tool to ensure all parties adhere to the same set of fair rules as set forth by the license," but then, presumably alluding to McHardy, declared that "any enforcement action should always be focused on compliance, never prioritize financial gain, never settle for less than compliance and consider legal action in court only as a last resort." In the July 18th announcement of McHardy's suspension, the core team said that McHardy "continues to be welcome in the project as soon as he is able to address the allegations and/or co-sign the [Conservancy/FSF Principles] in terms of any future enforcement activities."

The next day, Karen Sandler and Bradley Kuhn of the Software Freedom Conservancy published a blog post addressing the subject of McHardy. They revealed that Conservancy had engaged in largely unsuccessful attempted communications with McHardy for two years. Conservancy encouraged McHardy to co-draft the Principles with them and later invited him to endorse the Principles after they were published, but received no response from him. Sandler and Kuhn denounced McHardy for apparently refusing to endorse the Principles and failing to publicly justify his conduct of GPL enforcement.

3. Hellwig lawsuit dismissed

In 2015 Linux kernel developer Christoph Hellwig brought a copyright infringement suit against VMware in a German district court, alleging violation of the GPL in VMware's ESXi product. Hellwig's legal expenses were funded by the Software Freedom Conservancy. The Hellwig lawsuit attracted significant attention because it is apparently the first litigated GPL compliance case that centers on the scope of the GPL's copyleft requirement, sometimes thought of as the "derivative work" issue.

In July 2016, as Scott Peterson has reported, the court dismissed the case, concluding that Hellwig had failed to identify in the VMware product the specific lines of code in which he owned copyright. The court discussed the GPL issue, but it did not address the merits. The ruling has no precedential significance for other cases. In a brief statement, Hellwig announced that he would appeal the ruling.

4. U.S. government announces Federal Source Code Policy

In August the U.S. government's Office of Management and Budget announced the Federal Source Code Policy. The policy is aimed at reducing the problem of duplicative acquisition of substantially similar code by agencies and ensuring that new custom-developed federal source code be made broadly available for reuse across the federal government. Mark Bohannon has written an article on the policy.

The Federal Source Code Policy establishes a three-year pilot program that requires agencies (with some exclusions) to release at least 20% of new custom-developed software as open source each year. The policy recognizes open source as a means of enabling continual improvement resulting from improvements to the software by the broader community. The policy also announced the launch of code.gov, a "discoverability portal" for custom-developed code, including code released as open source under the policy.

The Federal Source Code Policy is notable for placing emphasis on adhering to proper standards for open development as well as open source licensing. Agencies releasing open source code are directed to do so in a manner that encourages engagement with existing communities, fosters growth of new communities, and facilitates contribution both by the community to the federal code and by federal employees and contractors to upstream projects. Agencies must also ensure that their open source repositories include enough information to enable reuse and participation by third parties, including details on licensing.

5. Moglen steps down as FSF general counsel

The Free Software Foundation announced in October 2016 that Eben Moglen had "stepped down" as general counsel to the FSF. Moglen, who is president of the Software Freedom Law Center and a law professor at Columbia, has been one of the most influential lawyers in free software. His career in free software has been closely associated in the public mind with the FSF, for which he provided pro bono legal representation for 23 years. I expect both Moglen and the FSF to remain as engaged as ever in matters of free software legal policy, but likely with more instances of public disagreement or conflicting opinions.

6. Debian and Ubuntu ship ZFS

In the mid-2000s Sun Microsystems released its ZFS filesystem as part of OpenSolaris, licensed under the weak copyleft CDDL. Efforts to port ZFS to Linux were inhibited for many years by legal concerns, including concerns about license conflicts between GPLv2 and CDDL. In recent years the "ZFS on Linux" project has encouraged Linux distributions to package its ZFS kernel module.

Although packaging of ZFS in Debian was held up for some time by licensing concerns, in 2015 Debian Project Leader Lucas Nussbaum revealed that Debian had received legal advice from the Software Freedom Law Center concerning inclusion of ZFS in Debian, which he said "should unblock the situation ... and enable us to ship [ZFS] in Debian soon." In January 2016, Nussbaum's successor, Neil McGovern, said that ZFS would be included in Debian as a DKMS package in source code form only, and would be segregated in the "contrib" archive, which contains packages that are not considered to be official Debian.

Ubuntu had included a source-only DKMS ZFS package for some time before Debian began doing so. In a blog post in February, Canonical's Dustin Kirkland announced that Ubuntu would begin shipping a binary ZFS kernel module. Following a flurry of debate over the GPL/CDDL issue, Kirkland said in another blog post that Canonical had discussed the legal issues with Eben Moglen (president of SFLC) and had concluded that distribution of the binary kernel module would be compliant with both GPLv2 and CDDL. Kirkland stressed that the ZFS module was "self contained" and was not a derivative work of the kernel, and the kernel was not a derivative work of ZFS. Kirkland also argued that "[e]quivalent exceptions have existed for many years, for various other stand-alone, self-contained, non-GPL kernel modules."

Shortly after Kirkland's second blog post, the Software Freedom Conservancy and SFLC published conflicting analyses of the legality of Canonical's distribution. (For those who don't know: SFLC and Conservancy are independent organizations.) They agreed, however, on two basic points: (1) Debian's distribution of a source-only module in contrib was license compliant, and (2) loadable kernel modules generally fall within the scope of the GPL copyleft on the kernel.

Conservancy claimed to be speaking on its own behalf as a Linux kernel copyright assignee as well as on behalf of kernel copyright holders participating in its GPL Compliance Project for Linux Developers. In Conservancy's view, Canonical's distribution of the binary kernel module violates GPLv2 and thus infringes copyright on the kernel. Conservancy believes that derivative works involving GPL license incompatibilities with other free software licenses should be subjected to the same legal analysis as GPL/proprietary combinations.

According to SFLC, Canonical's binary ZFS module must be regarded as licensed under GPLv2, since CDDL allows binaries to be under any license and any other interpretation would assume that Canonical was noncompliant with the GPL. Therefore, distribution of the ZFS binary module itself would not violate GPLv2; however, Canonical's otherwise compliant distribution of corresponding source code for the ZFS kernel module and the Ubuntu kernel would "literally" violate GPLv2, because Canonical would be providing the ZFS filesystem source code under CDDL. There are good reasons for a community of copyright holders of a GPL project not to object to this literal GPLv2 violation, because the conduct falls within the spirit or the "equity" of the license.

In SFLC's view, given the tension between the literal and equitable interpretations of GPLv2, "the consensus of the kernel copyright holders' intention … determines which mode of interpretation is to be employed." Here, there was no conclusive or convincing evidence of what type of interpretation the kernel copyright holders intend. SFLC argued that for as long as the kernel copyright holders choose not to object to Canonical's distribution, it should be assumed that the consensus of the kernel licensors is to support the equitable interpretation. SFLC also pointed out that Canonical's potential liability exposure was negligible.

Neil McGovern discussed his experience of the ZFS topic as Debian Project Leader in a talk at DebConf. Other noteworthy statements on the ZFS issue were made by Richard Stallman and by Linux kernel developer James Bottomley. Little has been said about the issue in recent months.

7. Apache Software Foundation bans JSON license

For some of us involved in open source legal matters, Douglas Crockford's JSON license keeps turning up like a bad penny. The JSON license famously modifies the MIT license by adding a sentence before the warranty disclaimer: "The Software shall be used for Good, not Evil." It is not clear whether Crockford intended the license purely as a joke, or as an oblique political statement, or both. Many who care about having a principled basis for classifying licenses as free, or open source, see the "Good, not Evil" clause as conflicting with basic definitional norms that disallow field of use restrictions and discrimination based on field of endeavor. Some have argued that the clause is not enforceable and thus should not be taken seriously; however, the FSF, which classifies the JSON license as non-free, argues that it cannot be presumed that the restriction is unenforceable. Another objection to the license is that "Good" and "Evil" are undefined and thus the scope of conduct that is allowed and prohibited is highly uncertain.

The reason the JSON license is not a matter of complete obscurity is that Crockford has applied it to software that happens to have been widely adopted, including the tools JSLint and JSMin and the JSON Java library ("JSON-java"). Over the years Crockford has refused many requests from developers to change the license, although he has boasted of having granted special permission to IBM and "its customers, partners, and minions, to use JSLint for evil."

For many years the Apache Software Foundation, known for strict rules on licensing under which, for example, the GPL and LGPL are relegated to a forbidden "Category X," treated JSON-java as though it were in its most favored "Category A" (which contains noncopyleft licenses, such as the Apache License 2.0 itself). Today several ASF projects have dependencies under the JSON license. In October 2016, in a posting to the ASF's legal-discuss mailing list, Ted Dunning called on the ASF to revisit its decision, noting that the JSON license was "substantially hindering downstream adoption." After discussion, Jim Jagielski, VP of Legal Affairs for the ASF, declared that "the license is NOT CatA and is NOT approved," placing the JSON license in Category X. Jagielski later clarified that no new use of the JSON license by an ASF project would be allowed, but some projects already using code under the license would have a grace period of several months to transition to a replacement. The issue was covered in a November 2016 LWN.net article.

Because so many ASF projects have been widely adopted, the JSON license prohibition seems likely to have a significant community impact in encouraging use of open source alternatives to JSON-licensed software.



Great recap. I'm wondering what the community's take is on BSL [1] While not new (2013) I think there is a worthwhile pending debate on post-modern licensing given the increased attention put in the last year or so on funding/business models for open source as covered by Eghbal, Okoli/Nguyen and others. It's probably accepted without proof that well-established open source licenses will persist in the next decade as they have survived the cycle, yet might be under additional stress in the upcoming stage.

[1] http://monty-says.blogspot.com/2016/08/applying-business-source-licensin...

Vote up!
Vote down!
anonymous coward

Mr Crockford considers this license to be funny [1] and a political statement [2]. He is aware that software under this license is non-free [2,3].

1: https://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=...
2: https://plus.google.com/118095276221607585885/posts/13shsS2bAEY
3: https://lists.debian.org/debian-legal/2010/03/msg00065.html

Vote up!
Vote down!
Ted Dunning

One key to getting rid of the JSON license is having a viable alternative.

That's why I updated the Android clean-room re-implementation of JSON-java to provide a cleanly licensed alternative clone library in Maven central.

See https://github.com/tdunning/open-json for more info.

Vote up!
Vote down!

Comment now