Supporting OSI

Lex Pan Law this year became a supporting partner of the Open Source Initiative. Most of you who work in the Free & Open Source Software (FOSS) field are probably familiar with the OSI, its activities, and mission. OSI maintains a list of approved open source licenses, which much of the industry relies upon in deciding what license to choose when deciding to open source a piece of software (or in some cases, other technologies). It also has a process for review and approval of new licenses, where a number of very thoughtful reviewers and commentators express their opinions upon conformance of licenses with the open source philosophy as well as legal rigor. If these topics of interest to you, you should subscribe to their mailing lists and comment on issues you feel are important.

Last year, the OSI appointed its first Executive Director, which should help the OSI focus on pressing projects and garner more industry support (financial and otherwise).

Administration of the OSI is through an elected board, with board members serving fixed-length terms and with any OSI individual member being eligible to run (and all OSI members having an equal vote). This level of transparency and receptiveness to membership feedback is one that other similar organizations should follow (even if the results of the elections don't necessarily reflect one's own personal preferences).

Reclaiming the Public Domain: Patent Edition

The potential negative impact of patents against free and open source software (FOSS) has been an expressed concern since at least the release of the GNU General Public License, version 2 (GPLv2) in 1991. The preamble of GPLv2 stated quite clearly the concern: “any free program is threatened constantly by software patents.” The potential threat of patents, particularly the use of software to hinder or stop the development or distribution of FOSS has long been the subject of vigorous discussion and debate.

Although at various times patent threats against FOSS have been promoted as imminent and dangerous, actual patent assertions against FOSS have been – in the 30 years since GPLv2 – exceedingly rare.

This historical background is the reason why the patent lawsuit filed against the GNOME Foundation in late 2019 was of significant discussion. That lawsuit seemed to be the first real manifestation of the long-raised concerns that patent holders would hold up FOSS software distribution and development by demanding royalties or other monetary compensation in return to access to their patents.

Although substantial funds were collected to mount a strong challenge to the patent asserted against the GNOME Foundation, in the end the patent challenge was resolved, resulting in a license to the patent-in-suit as well as others generated by the inventor of that patent, not only for GNOME, but for other FOSS as well. Many hailed this result as a “win” for FOSS.

Those believing the resolution of the GNOME litigation resulted in a win for FOSS, or for software in general, may not have considered at least two factors: first, the track record of various assertions of patents by the same inventor of the patent asserted against GNOME, and second, the underlying legal criteria for establishing that that patent is valid and enforceable.

On the first measure, the patent asserted against GNOME was generated by an individual, acting through a variety of different patent-holding entities, with some track record of making patent assertions found to sufficiently unfounded as to merit awarding penalties, or engaging in other litigation conduct determined to be legally sanctionable. On the second measure, the patent claims that were asserted against GNOME Foundation were arguably part of the public domain before the suit against the GNOME Foundation was ever filed. These two factors are not mere theoretical quibbles with a patent now available to all – the patent asserted against the GNOME Foundation was asserted in patent infringement lawsuits against at least 15 other entities after the assertion against GNOME, and to date, at least 3 of those suits are still pending.

There was another approach available – a direct challenge to the patent-in-suit. On behalf of its client Defease Patents, Lex Pan Law filed a challenge to that patent using the reexamination procedures available in the U.S. Patent & Trademark Office, in October, 2020. In January, in response to that filing, reexamination was ordered, and in March, 2020, all claims of that patent were rejected as unpatentable. The rejections made were notable in that they found identity of the claim asserted against the GNOME Foundation in the lawsuit with a patent uncovered and revealed to the U.S. Patent & Trademark Office by Lex Pan Law, which patent had lapsed into the public domain before that suit was ever filed. For those familiar with patent practice, all claims of the patent challenged were rejected for lack of novelty – a particularly difficult rejection to overcome without altering the patent claims, and thus triggering potential intervening rights to those who have made products before such amendments.

The reexamination process has not ended, but there should be more information in May about the status of that challenge. In the end, if the U.S. Patent & Trademark Office continues its current stance on the merit of Defease Patents’ challenge, the patent that has, and continues to be, asserted against so many will also make its way into the public domain. In the end, that result will be a victory for a more robust public domain and the freedom of all to use the features that had been previously been held exclusively for the benefit of one.

Oracle/Google

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.