For those who weren't paying attention (and it seems like almost anyone working in tech law was), oral arguments were held today in the U.S. Supreme Court in the long-standing litigation between Oracle and Google over the copyrightability and infringement of certain parts of Java (developed by SUN, now owned by Oracle) in Android. Transcripts from that argument, as well as the audio, should be posted on the Supreme Court website, probably later today.

A few general impressions, potentially apropos of nothing -- since predicting appellate outcomes based on oral arguments is a bit of a fool's errand:

  1. The argument illustrates how technology lawyers often need to resort to non-technical analogies in order to make points about technical issues as they relate to the law. There's even a Twitter thread outlining all the analogies that were used just during this one oral argument. Analogies of this sort can be a bit of a mixed bag -- sometimes they help clarify a point for a judge (or Justice) with little background or training in technology, sometimes they muddle that point or omit nuance, and sometimes they are completely ineffective. I recall arguing a Markman hearing (this is a form of hearing that happens in patent cases to allow the judge to make a ruling on the scope of a litigated patent) where I analogized concepts in a patent to planetary motion in our solar system. It didn't seem to help the judge's understanding at all. The Supreme Court here seemed to be grasping for analogies to help them better refine their thinking on issues around Java classing/subclassing and declarations, but I'm not so sure any of the analogies used hit the mark. Only Justice Sotomayor seemed to want to skip the analogies and speak directly to how Java actually works (Justice Sotomayor may have the most copyright related experience on the Court now that Justice Ginsberg is gone; she even wrote an opinion on copyright infringement and fair use in a case filed by the creators of Seinfeld -- and Seinfeld was raised as one of the analogies during oral argument).

  2. Although the Court had requested additional, later, briefing on the issue of respect for the original jury verdicts by the intermediate appeals court (the Federal Circuit), not a lot of the oral argument revolved around that issue. Most of the time was spent on the issue that many people have urged the court to decide -- how does one determine what types of code that is used in some way to interface either: a) should be copyrightable at all, or b) ought to be able to be used by others without fear of a copyright infringement claim, under the doctrine of "fair use" (called "fair dealing" in other common law jurisdictions, although that concept is not completely analogous)? At the time the additional briefing was requested, it seemed that the Supreme Court might be looking to dispose of the case under the Seventh Amendment (in essence preserving the jury's decisions), which was the angle that the Software Freedom Law Center had pursued in their amicus brief. This issue may still be the dispositive one (in which case, the litigation probably gets kicked back to the Federal Circuit to reinstate the jury verdict), but there seems to be a greater chance that the Supreme Court actually renders an opinion on issues around copyrightability and fair use.

  3. On a couple of different occasions, the spectre was raised that a ruling in this case would "swallow up all computer software" into non-copyrightability. Given there's a pretty lengthy history of case law on the copyrightability of software, including several different tests for sifting between the copyrightable and non-copyrightable parts, that argument seems rather alarmist. But that questions like that are being raised might show that there is at least some discomfort with the lines that are asking to be drawn around non-copyrightability of APIs.

  4. One of the more interesting aspects of the lower appeals court decision, and one which was not remarked upon during oral argument at the Supreme Court, was this statement by the Federal Circuit: "On remand, the parties stipulated that only 170 lines of code were necessary to write in the Java language. It is undisputed, however, that Google copied 11,500 lines of code—11,330 more lines than necessary to write in Java. That Google copied more than necessary weighs against fair use." This would seem to be an important factor that might be of relevance to whether or not the jury's decision on fair use ought to be maintained. One could imagine a decision that says that the replication of the 170 lines of code were fair use, but the remainder was not. The extent to which that distinction is important to the decision will remain to be seen in the written opinion.

  5. There was also not much discussion during oral argument of the fact that there are a number of different decisions, applying similar but not exactly consistent, tests for determining whether and what kind of software code is and isn't copyrightable and may or may not be copied without fear of a copyright infringement claim. Justice Kagan referenced one of those decisions -- Altai, out of the 2nd Circuit, which gave the "abstraction, filtration, comparison" test -- but there are several others (mostly out of the 9th Circuit). Having clear and consistent tests for these issues, applicable across all courts in the U.S., would be of some help for those trying to negotiate these thorny issues, and based on oral argument there is at least some potential for that to happen.

  6. The case was heard by an 8-member Court. The last time a significant software copyright decision made it up to the Supreme Court, the result was an even 4-4 split, so no significant decision was made. It would be a real shame to have that happen yet again in this case.

The written decision probably does not come out until next year, although there is also the chance of reargument if and when there is again a 9-member Court. The outcome is certainly to be closely watch, and will likely result in a lot of debate about how it might change how software copyrights work, and how programming is done, in the future.

During the drafting process of GPLv3, one of the additional requirements added over GPLv2 was the "Installation Information" requirement (often referred to as "anti-TiVOization" for reasons that will escape those not familiar with copyleft controversies of the mid-'00s).

It's a rather complex requirement, which admits of numerous exceptions and limitations, but users of GPLv3 code need to pay attention to it, particularly if they want to include features in devices using such code that they wish to lock-down or otherwise impede changes by end users.

I've posted below a copy of a presentation that Andy Wilson & I originally made at the Free Software Foundation Europe's workshop in Amsterdam in 2008 (if I remember the year correctly), slightly revised. As far as I know, this is one of the few examples of a detailed analysis of this provision and how product companies ought to work though compliance; Bradley Kuhn has also written/presented on this as well, more recently, in the context of the automotive industry -- one of the industries that, at least in the past, has had concerns about compliance with this provision.

At some point, I hope to write a more comprehensive summary of this provision, updated with more recent data about usage and compliance data, but for now, this may be of use for those of you who haven't really studied this provision in detail.

GPLv3 and Installation Information
Download PDF • 86KB

Updated: Aug 21

At Copyleft Conf 2019, I did a presentation under the provocative title "Extreme Copyleft, Boon or Bane?"

The main point of the presentation was to look at current hot issues in license drafting, that were roiling around the FOSS world both inside and outside the OSI's license approval process. As a thought experiment, I posited an "Extreme Copyleft Public License" (ECPL), representing the potential end state of copyleft licenses (no, APGLv3 isn't the end state). In summary, a license that says "all your code are belong to us" (to the extent that is possible under any intellectual property regime under which the license is exercised).

It was an interesting thought experiment (and pointed out that the *GPL family of licenses have plenty of carve-outs that, if one were so inclined, could be plugged), although at least one person in the audience (I think Harald Welte) pointed out a drafting error in my proposal (it didn't obligate you to reuse the license -- oops).

Well, Extreme Copyleft seems to still be a matter of interest; there's a presentation at State of the Source* next month on the topic. Perhaps a call for the ECPL to be submitted to the OSI and for all to adopt it? [That's sarcasm; when I posited the license, I said it was a thought experiment and I doubt anyone would want to use it or code licensed under it.]

There was some ancillary discussion in the presentation, and in the questions afterward, about license experimentation and license proliferation; on the former, I was pro (even pro failed experiments), on the latter, neutral to anti, depending on my client. These topics are also becoming a bit hot (at least in the Twitterverse, which doesn't really represent reality), particularly given some of the recently-proposed ethical licenses, the most recent example being the Anti-Capitalist Software License (ACPL?).

It's nice to see people still talking about things I talked about almost 2 years ago (not everything I say is just ephemera!). For those who weren't at my presentation in 2019, I've posted my slides. Note that they are a bit messy, as I had a full-scale laptop brick event on the plane ride over to Brussels, so reconstructing my beautifully constructed and presented pre-flight slides to absolute fidelity was not possible; they may also not be fully self-explanatory (that's what the spoken presentation was for!) but readers may be able to get the drift.

*Lex Pan Law is a watch party sponsor of State of the Source, but had no involvement in the proposing or approving of this session. I was just a fortunate happenstance.

Extreme Copyleft from CopyleftConf 2019
Download • 144KB

Extreme Copyleft from CopyleftConf 2019
Download • 465KB

Extreme Copyleft from CopyleftConf 2019
Download • 465KB