Yes, We Do All Infringe
Yes, We Do All Infringe
Join the DZone community and get the full member experience.Join For Free
Get the Edge with a Professional Java IDE. 30-day free trial.
When we use Java
There is a lot of confusion about my We all Infringe post. So, I'm going to walk everybody (especially the lawyers) through the mechanics.
Until last week, all developers and most lawyers operated under a simple rule. APIs are not subject to copyright, but code implementating APIs is subject to copyright. It was a simple dichotomy and allowed developers to operate under a brightline set of rules.
On May 9, 2014, the Circuit Court of Appeals changed the law to include copyright coverage to include APIs. Specifically (page 5):
... we conclude that the declaring code and the structure, sequence, and organization of the API packages are entitled to copyright protection...
So, there you have it. An author can assert copyright over the way a caller invokes code in a library.
Java is dual-licensed, but many of us use OpenJDK which is licensed under the GPL 2. See also the
java.lang.String source code. The execution of Java code is covered by the classpath exception which does not cause the viral GPL to attach to code the JVM executes. But this is related to execution of code, not to the generated
As I demonstrated, the compilation of Java source code into a
.class file (or Scala code or JRuby code or Clojure code) inserts parts of the Java API into the target
.class file. This is technically necessary as the JVM needs this information at the call site of each method invocation. Granted, an individual Java
.class file does not contain the whole Java API, but the court gave little guidance as to what percentage of the API is required to rise to the level of infringing. However, there were a number of places in the opinion where the court indicates that the bar is quite low (page 34):
And, by dissecting the individual lines of declaring code at issue into short phrases, the district court further failed to recognize that an original combination of elements can be copyrightable.
So we know that the court looks poorly on dissection. We know that the court held that the Java API is copyright Oracle. So, it's conservative to assume that copyright attaches to each method declaration in the API, not simply to 95% or 57% of the collection of package/class/methods.
Further, the more complex the program and the libraries the program needs to operate (libraries that are rolled into the collective WAR file), the larger percent of the overall Java API that will be embedded in the resulting program.
javac embeds/copies parts of the Java API in our code. Everyone who installs OpenJDK on Linux (everyone who did not click through Oracle's Java license) has licensed Java under the GPL.
Because each class file contains some GPL code, each class file must itself be open as per the GPL's grant-back clause or is infringing on the API copyright.
"Fair Use" you cry. Well, Fair Use is a very squishy area of the law that requires a lot of ad hocjudicial analysis. But, let's go through a fair use case for a large ERP system written in Java:
- Purpose and Character: an ERP system is transformative of Java, but an IDE like IntelliJ is a lot more derivative
- Nature of the copied work: An ERP system is not going to be very artistic
- Amount and substantiality: I haven't run an analysis of the percentage of the Java APIs in WAR files deployed at my customer sites, but let's assume a conservative number like 25%... that's more than enough to trip the Amount test against us
- Effect upon work's value: This should work in our favor because each Java program has a positive effect on the value of the JVM via network effects, but as we've seen in the Oracle case, Oracle wants to extract more money out of Google... and given that the Oracle case tortures the Structure, Sequence, and Organization test, I have no doubt that if Oracle wants to extract money from SAP, they will shift the "window" of analysis to include the effects on Oracle's ERP systems.
Yes, in "Hello World" we have a pretty solid fair use argument. But as the program grows more complex, uses more of the target API, is more of a development tool rather than an end user application, etc., the balance becomes less and less clear.
On the other hand, the way the law was prior to May 9th, 2014, it was a nice, clear, bright line: you could reference APIs in your program and you were not infringing.
We're mostly not targets
I've spoken to a fair number of people about this issue and there's a theme running though the conversations: "you're not a target, so what are you so worried about?"
I worry about doing the right thing.
I worry about telling my kids not to steal music and it's going to be hard to do that when I know that every day, I'm violating other peoples' copyrights.
I care about the software and computing industry as a whole. I've made a comfortable life for myself by standing on the shoulders of giants. That should continue. Yes, I could have patented real time trading in spreadsheets (I was the author of the original art in Mesa in 1992, instead I joined the League for Programming Freedom. So, if I cared simply about maximizing personal enrichment, I would have structured a deal where I got a fraction of a cent for every financial trade computed through a spreadsheet. Instead, I cared and continue to care about building great things and seeing what other great things other people are building.
I care about having an industry that continues to invest time and money into making these computing tool things more and more amazing and enriching all of civilization... as the industry has through my 50 year life.
We're mostly not targets, but with a weapon of mass destruction like "our API is copyright us, you embedded parts of our API in your program and we want money/to destroy your business" pointed at each and every one of us (the embedding of APIs at the call site is an issue in C++ with name mangling, likely an issue in Go, etc.), we are all potential targets. This is a nasty, horrid tool that can be used to extract all kinds of concessions from a smaller player.
It's also something that casts a shadow on every developers, everywhere. When Apple and Google spend more on patent lawsuits than they do on R&D there's a problem.
The underlying purpose of copyright and patent and other IP law is to make sure there's investment in R&D and creativity. But we are at a place where the legal transaction costs are eclipsing the value of the transactions they are supposed to support and stimulate. That's really broken.
The Oracle case and the fact that we're all infringing and all potential targets is chilling.
In my opinion, the Oracle opinion and the legal theories put forth by Oracle's lawyers has destroyed the ability to people in software to focus on building excellent software.
If you're going to tweet at me with "classpath exception" or "Java is open, it's GPL" or other such stuff, it's pointless. If you have a legally reasoned alternative take (cite cases and cite the actual technology), I'm all for listening and engaging.
But the net-net is the Oracle decision fundamentally changed the balance of APIs vs. implementation and in doing so, can potentially destroy the industry that I love... but at least I can go be a lawyer.
Published at DZone with permission of David Pollak . See the original article here.
Opinions expressed by DZone contributors are their own.