This is the post-oral-argument update to our pre-oral-argument posting titled U.S. Supreme Court Oral Argument October 7: Google LLC vs. Oracle America Inc. : Android Java Software Interface Copyrights Fair Use Juries.
We found oral argument in this case to be marked by highs and lows, the unexpected high being the continued, surprising participation of Justice Thomas, who seems to be thriving in the highly structured, telephonic, teleconferenced proceedings, where Justices are currently asked to speak in the order of their Court seniority.
The low point was marked by perhaps unavoidable gobbledygook arising from rapid question and answer discourse about a subject where no sitting member of the U.S. Supreme Court, nor the lawyers for the parties, can claim sovereign expertise, namely, computer software interface programming.
The present author, yours truly, many years ago -- for purposes of learning computer programming -- single-handedly wrote a compiled 10 MB computer game, Infinity One, quite a bit in those days, requiring multiple floppy disks. We wrote the code for one operating system in one computer language (STOS for Atari), and then ported that game to the Microsoft Windows platform in another language (Visual Basic for Windows), even sending the entire program code to Microsoft for testing to obtain a Windows compatibility badge, which was issued. One learned quickly in the course of those software projects that code commands were highly structured by the programming language being used, and had to be abided by, if one wanted to obtain a desired functional result. We never entertained the idea that our written code itself was a type of creative expression.
Understanding this whole case might be simpler than the oral argument indicates.
Programming languages are just that: written LANGUAGES, used for a purpose, specifically, these languages are used to write COMMANDS for hardware, i.e. for machines, viz. robots. They are not written for execution by people. People can not "execute" software commands. Only machines can. All software commands, regardless of copyright law, are purely functional texts COPIED by machines before they are executed by those same machines. Constitutional copyrights were never intended to apply to them.
Programming languages such as JAVA are written so that certain code segments kick certain other code segments into action, and that is the crux of the dispute between Google and Oracle. Oracle claims monopoly rights on operative segments, insofar as they appear in APIs ("application programming interfaces"), using copyright law as their whipping boy for a purpose never intended by Constitutional Founders. We do not understand why versed judges would condone that view, to the detriment of interoperability and software practice that spans back at least 30 years. The Courts here are in error to defer to Congressional lawmaking. The Constitution is the measuring stick, not the politics in Congress.
Copyright protection was intended by the Founders for "people"-text, not for "machine" code copied by machines. Machines do not copy software code because of any reason of creative expression -- their job is purely functional. Rather, machines want to be told what to do, and their options are greatly limited by the tasks that are to be commanded by the software code as written.
Just imagine if automobile manufacturers could not construct gasoline tanks and the filler tube inlets to match the dimensions of gasoline pump nozzles according to the written specifications existing for gasoline (petrol) station pump nozzles. APIs are interfaces in the same way that there must be agreement between car gasoline tank filler inlet openings and the diameter size of gasoline station pumps.
There is no issue of "creative expression" in software programming as in a book novel, where the author can theoretically write anything that the author wants in his "creative" writing role. Programming language is SEVERELY limited by its tasked purposes. "Creative expression" is not one of its purposes.
We might command a printing machine as follows by software code: "print A", or "PRINT A", or "print a", or "PRINT a", or "please print A", or "pretty please print A", etc. Regardless of the length of such a programmed phrase, the above principle prevails for ALL program code. Copyright-protecting e.g. the variant "pretty please do print A" as a suddenly "more creative expression" would be absurd. That principle of course also applies to larger segments of API code. Accordingly, we strongly oppose the use of copyright law to apply to software protection. The law of patents covers that, and that is enough.
Software interfaces can be likened to plugs for electrical sockets, and the Java program in question can be likened to the electrical power system that is being accessed when a plug is put into a "Java" program socket. At stake for all consumers is the question of interoperability, which, e.g. is a disaster for electrical plugs, as every international traveler knows. God forbid if something similar happens to the interoperability of the software industry.
Just as in the case of "APIs", a plug can be designed in many shapes, sizes and colors, etc., but it MUST conform in its essence to the specification of what the socket wants to have plugged into it, or it will not work.
That is why we are faced with having to have various electrical plug adapters when we travel overseas to different countries that use different sockets.
For all practical purposes, the actual "functional" leeway for a plug designer is thus virtually nothing, because he is tied to prongs viz. pins that are required.
That is also the same problem that arises as concerns software interfaces. To copyright an API is like giving monopoly protection to the plug "prongs" viz. "pins" that go into a socket
Copyrighting APIs in the USA (which APIs can not be copyrighted in the European Union) will lead without question long-term to the same consumer-unfriendly situation that exists for electrical plugs worldwide, exemplified by this Wikipedia map of the Types of power plugs and sockets used by country. Maps such as these just reflect human stupidity in action. Rather than cooperating peacefully and arriving at a common standard, everyone wants to be the king in his own realm, and, in the Google vs. Oracle case, to make a lot of money for virtually nothing ... a criticism which could be said to be directed, rightly or wrongly, to both parties:
Compiled computer code can also be likened to a compressed dictionary.
As a former dictionary author for the then world's largest dictionary maker, we understand dictionaries. We have written more than a few dictionary entries.
Dictionary definitions are similar to lines of software code in that they are functional in nature. They have an explanatory function and are not written for purposes of creative expression. You can copyright a dictionary as a separate work, but not the individual definitions, which allow too little leeway in formulation to claim any copyright protection as copyrightable expression -- in and of themselves. If a word is defined correctly in a dictionary, then it must by its very nature be similar with comparable entries in all other dictionaries that are or could be written, or else the definition is faulty.
But can an API be regarded as a "separate copyrightable work" just because it contains multiple lines of single line text viz. code? "Code" is nothing more than machine-understood text in command form, REGARDLESS of the number of lines.
Below we have constructed an example of software programming "goto" (go to) lines of hypothetical code. Lines 1 to 6 represent material that is not (should not be) copyrightable, and which is comparable to the code of an API, just simpler, whereas line 7 represents creative expression that is (should be) copyrightable, but comparable to virtually nothing in computer command programming -- the text difference could not be more clear -- indeed, it almost always IS quite clear:
1 a=1 goto 2
2 If a=1 goto 3
3 p=4 goto 4
4 If a+p=5 goto 5
5 i=7 goto 6
6 If a+p+i=12 goto 7
7 Print: Twelve the months in every year, copyrights forever near, every text is not a stave, worth the law's protective save. Catch the cresting barrel wave, ride the pocket, share the rave. Cast aside this legal knave, in the land, of the brave!
With kudos to the famed BurmaShave road signs!
In any case, it remains likely in our estimation, that the manner in which the jury verdict was handled by the Federal Circuit, will lead to the case going back to the Federal Circuit, because it is the easiest way out for a Court looking not to make a catastrophic mistake on the software interface copyright issue.... where they all need to read up on this matter a bit, to make the right decision down the road.
We shall see.