One Last Push To Save The API

A group of computer experts – including me – asked a US court to think again about fair use of APIs this month.

Tomás Saraceno artworks at SF MOMA: Stillness in Motion—Cloud Cities

It was an unlucky fact that Oracle’s case against Google over Android started with patents. Their initial case fell apart almost immediately, with almost all the patent claims invalidated. The implausable backstop copyright case Oracle made against Android’s use of language-essential definitions in the Java APIs (and thus against the freedom of developers everywhere) carried on though. The initial patent case meant that the appeal when Oracle soundly lost ended up at the Court of Appeals for the Federal Circuit (CAFC) — the specialist patent appeals court in the USA — and not at a court competent to dispense copyright justice.

The result has been two reversals by CAFC of lower court outcomes that seemed correct to most of us who understand the issues involved. In the most recent reversal, CAFC even overturned a strong and apparently sound jury verdict — exceptional behaviour. In response to that reversal, a large group of experts collectively representing hundreds of years of experience of inventing, implementing and instantiating software solutions has once again put signatures to a new amicus statement to help the courts understand the technical nuances of the case, especially the fact that an API is not code.

This time the goal is to have CAFC rehear the appeal that (in our opinion) erroneously overturned the jury verdict. In summary, we believe that the most recent decision by CAFC “disregards the technical realities of software APIs and directly conflicts with Ninth Circuit law.”

To unpack that a little: since CAFC is a court with specialist expertise in patent cases, its job in a copyright case is to second-guess the decision that the correct venue — in this instance the Court of Appeals for the 9th Circuit — would make in the case if they were hearing it. The brief explains how CAFC appears to have guessed wrong this time. It also explains how CAFC has not understood the nature of APIs and thus has applied the wrong comparisons to determine if Android’s use of the essential core of Java is fair use. To me, the most telling statement is the footnote on page 5:

Throughout this brief, amici use only the term “declarations” instead of “declaring code,” which was sometimes used in the panel opinion. “Declaring code” is not a term of art, and is not used in the industry, in part because declarations are not code: they cannot be executed by a computer and their only function is to dictate how code communicates with other code.

This was the point I explained to the judge during the hearing and appears to be the crux of the misunderstanding at CAFC – they appear to think think APIs are code. Hopefully this brief will clarify things for them, get them to rehear the appeal en banc and partially mitigate the disaster Oracle is bringing on developers everywhere. I’m told the outcome of this case doesn’t create useful case law, so if this doesn’t work out, we will have to wait for the next API lawsuit to come along to set the right precedents (and hope it isn’t also subject to the same patent gaming). That could take years — this case is already nearly 8 years old — so a correction in Oracle vs Google would be preferable.

FLOSS Weekly 488: Keycloak

Simon co-hosted this week’s show, which looked at a very interesting identity management system called Keycloak that puts commercial-strength federated authentication, authorisation and identity management within the reach of every developer. It’s written in Java, backed by Red Hat and has a large and active community.

 

 

Welcoming Software Heritage

Coade Stone is a fantastic artificial rock whose creation process was lost for more than a century because it was kept secret, although it has recently been reverse engineered.

Comments delivered at the opening of Software Heritage at UNESCO:

Distinguished guests, ladies and gentlemen, it is my pleasure to bring greetings from the Open Source Initiative, the global charity promoting open source and acting as steward of the open source definition and the list of approved licenses.

Open source is 20 years old. By popularising the pre-existing concepts of free software, it has been at the heart of the connected technology revolution. Open source gives developers permission in advance to collaborate and innovate regardless of affiliation. OSI-approved open source licenses are the hidden power behind Linux, Apache, Mozilla, Android and more.

But by granting all the rights necessary to us and our fellow community members to use, study, improve and share the software powering modern systems and networks, allowing us to collaborate with many “known others”, open source also unreservedly grants permission to “unknown others” to repurpose, rehost, reuse and revolutionise.

Availability to the outsider — to society in general — is crucial to our future. When software stays locked up inside the corporation or institution, when code created by the state with public funds remains secret, it does not add to our collective knowledge and is lost when its host moves on and the innovation it embodies is lost to society. This was the original motivation for previous generations to create temporary intellectual monopolies such as copyright, as an incentive to creators to make their creations public.

As time has passed, those intellectual monopolies have themselves been regarded as property and the knowledge and culture they embody is increasingly witheld from society. Open source allows that new-found wealth to be “spent” in a new way to stimulate collaboration. Collaboration in community has gone on to amplify innovation and accelerate adoption.

Software Heritage completes the new social contract enabled by open source. It provides the ultimate historical reference for the code behind our culture and comprehensive library of innovation to provide a “mounting block” to the shoulders of the giants before us. We should strive to get all the software that matters into this new digital Library of Alexandria.

It’s especially important that software funded with public money finds its way into Software Heritage. As Lessig observed, the practical experience of the law and of society is through code and all the software that governs our lives and liberty should be public code in this new library. More than just allowing us now to guard our freedoms, future historians will need source code to fully understand our digital present.

So as President of OSI, I warmly welcome the opening of Software Heritage. Open source delivers software freedom, and the Software Heritage archive takes the result and keeps it free for all time. That’s a great contribution to the modern world – congratulations!

FLOSS Weekly 484: The Lounge

After the Pidgin show a while back, Simon stepped in at 11:59 for Randal again, hosting an interesting show about a pure community project that makes a web-hosted IRC client called The Lounge. If you need a web client where you can maintain ongoing IRC sessions, this open source, self-hosted alternative to IRCCloud and others may be the answer. It’s written in Javascript, runs in Node and there’s a ready-to-use Docker container available.

Going With The Grain

If you’re managing community or developer relationships for your employer, a crucial principle is to “go with the grain” of the community — promote and embrace the freedoms it needs and the expectations it cherishes — rather than take actions that result in easily-anticipated opposition.

More at https://devrel.net/community/going-with-the-grain

FLOSS Weekly 479: Pidgin

This week Simon co-hosted episode 479, an entertaining interview about the Pidgin project, one of the most important Open Source Free software projects. It’s a multi-platform program that allows pretty much any instant messaging system to be used from a single interface. It also includes libpurple, a library that can be used in other software to do the same thing, and Finch, a terminal-based IM app with all the same capabilities.

Amazingly, Pidgin is developed by a tiny group of part-time developers. Maybe it’s time for the Open Source community to step in and help to guarantee the future of this important, widely-used app and library? A donation might be a start but they seem to need more…