Copyright and Programmers

In the wake of Oracle vs Google, where are we as programmers now that APIs can be copyrighted? What can we do, and what can’t we do? This essay discusses these questions.

This essay talks about the way things are, not the way things should be. If it makes you angry, write to your senator: changing things is something congress should do.

tl;dr: If You Want to Use a Library, Get a License

Is the software world broken now? No, it's not.

Can we still use Java? The answer is yes, because the OpenJDK license allows you to link the Java code into your own applications (GNU Classpath exception).

Can we still use Python? Yes, because Python is distributed under the Python Software Foundation Agreement, which allows you to use Python in almost any way you like.

What about C# on Windows? The language C# can probably be used anywhere, but what about the standard class library? That’s important. Microsoft allows you to build software on it, so you’re fine.

What about Mono? Mono has two parts, the source code written by the Mono team, and the library APIs which are owned by Microsoft. Recently the whole thing was licensed by Microsoft under the MIT license, so writing code for Mono is not a problem.

If Google loses, can they still use Java on Android? Yes, they’ve already switched to OpenJDK. If you remove infringing code from your code, then you are no longer violating copyright.^[1]

“The standard of originality required for a copyright is minimal.^[2]” Even something as minimal as Lucio Fontana’s single slice in a canvas is enough for copyright protection, so it’s not surprising source code can be copyrighted.

To determine when one program has copied another, the court applies the abstraction, filtration comparison test. The source code is the main thing, the purpose of a clean room implementation is to prove that none of the literal code has been copied. The source code is not the only thing: the architecture can be copyrighted, as can data structures, or other elements. It doesn’t matter if the code is an API or an implementation of an API, the court applies the same test in both cases.

Things that are not copyrightable: algorithms, things that only can be done in one way^[3], things that are typically done (like reading command line parameters, or structuring code to run unit tests)^[4], or code that is purely functional. The last part might seem confusing, since all code has a function, but most code has a creative aspect too, in how it is organized, the names of the variables, etc. If it has no creative aspect, it’s not copyrightable.

Just because something is copyrighted, that doesn't mean you can't use it. Fair-use laws were made to allow people to reasonably use copyrighted things.

Usually it’s safer to write your own API instead of copying someone else’s, but fair-use gives you plenty of reasons to legally copy code. You can copy code while reverse engineering it. You could even make a parody of someone’s library and present it at your next standup. In determining fair-use, the courts are going to ask you, “How much did your copying hurt (or potentially hurt) the owner^[5]?”

Can header files be copied? Not necessarily. For example, in C++, the preprocessor is turing complete, so anything that can be done in regular code can be done in a header file. The same analysis that is done for normal code is also done for header files to determine copyrightability and fair-use.

The big question is interoperability. Interoperability is the most important reason anyone would want to copy an API. The short-term purpose of copyright is to make money for the copyright holder, but the ultimate goal is “to stimulate artistic creativity for the general good.” Interoperability allows programs to be written that wouldn't be possible otherwise, and it allows programs to run on platforms that wouldn't be possible otherwise.^[6] The profit aspect needs to be balanced with allowing others to create good things.

This doesn't mean that all interoperability claims are fair-use. Only use what is necessary.^[7] Even if your goal is interoperability, directly copying code is a problem. As mentioned earlier, a clean-room implementation can help you avoid that.

These examples were written to give you a feel for the steps and reasoning a court might go through to decide copyright cases. The law is fuzzy, and in an actual court case, outcomes might be different. To know your options, consult a lawyer.

Samba. Samba is an open source program written to implement the SMB protocol. Microsoft has made some additions to the protocol and kept it secret. The Samba team used the French Cafe Technique to copy those additions. Start by applying the abstraction-filtration-comparison test. The Samba team did not look at Microsoft's source code, the only things that survive that test would be the protocol structures and commands, which are used by Samba (these may not be copyrightable, but for sake of argument, let's assume they are). The four fair-use factors all favor Samba here: 1) the purpose is non-profit, 2) the structures and commands are mostly functional, 3) the amount copied was the absolute minimal necesssary, and 4) it could concievably increase Microsoft's profits, although the burden would be on Samba to prove that.

Samba would likely win a copyright defense.

Wine. Wine is a compatibility layer allowing Windows programs to run on non-Microsoft platforms. The team uses black-box testing to determine the functionality of Windows, and then implements similar functionality. This prevents the copying of any actual code. Applying the abstraction-filtration-comparison test briefly, the remaining copied aspects might be the names of the functions, and perhaps the structures of the parameters (again, let's assume for argument's sake). Applying the four fair-use factors: 1) the purpose is non-profit interoperability, 2) the structures and names are creative ("api design is art"), which weighs against fair-use, but using them is a technical necessity for reaching the legitimate goal of interoperability, 3) the amount copied was the minimal necessary to reach that goal, 4) there is no evidence that profits have been lost.

Most of these factors fall in favor of fair-use, so Wine would likely win a copyright defense.

Mono, (before being bought). Xamarin develops Mono as part of their business. Mono is a clone of the .net API, to allow .net code to be run on any platform. The Mono team followed public standards released by Microsoft, and also copied functions that only exist on Microsoft's platform. Again starting with abstraction-filtration-comparison, the remaining portions are likely the API definitions. Applying the four factors 1) Mono could be concievably viewed to be for-profit, because Xamarin uses it to draw customers. This is a strong negative factor, but Mono allows people to run .net on platforms they otherwise couldn't. 2) although it is built with profit intent, Xamarin works hard to make it compatible. The release of the public standards also strengthens the fair-use defense. 3) Xamarin strictly copied more than was necessary to implement the standard, but perhaps for compatibility with the primary .net platform. 4) There is no evidence Microsoft lost money as a result of Mono, indeed, I've heard people say, “You should use .net because of Mono,” and then go on to use Visual Studio.

Balancing all these factors, Mono doesn't have as strong a fair-use claim as Wine or Samba. However because of strict compliance with the standard released by Microsoft, they reasonably could have won a copyright defense.

In short: when you use software, get a license; when you release software, give users a reasonable license (if you like, you can renounce the copyright on your own APIs).