Overbloated Writing in Science: Acronyms, Jargon, Wordy Text: When More Fluff is More than Enough

Nature Index tells us that

"Science is getting harder to read : From obscure acronyms to unnecessary jargon, research papers are increasingly impenetrable – even for scientists."

Post-Oral-Argument : U.S. Supreme Court October 7 Google v. Oracle America, No. 18-956 : Android Java Software Interface Copyrights Fair Use Juries

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.

Google LLC vs. Oracle America Inc. : Android Java Software Interface Copyrights Fair Use Juries : U.S. Supreme Court Oral Argument October 7

Please Note: We have edited our original October 6 posting on October 7, but prior to oral argument.
__________

At the United States Supreme Court, oral argument is scheduled for October 7, 2020, in the landmark case of Google LLC v. Oracle America Inc. which, as noted at SCOTUSblog and elsewhere, raises the following issues:

#1 -- Whether copyright protection extends to a software interface;
and
#2 -- Whether, as the jury found, the petitioner’s use of a software interface [API] in the context of creating a new computer program constitutes fair use. [emphasis added by LawPundit]

Kris Kemp of Kemp IT Law writes in Google v Oracle: the Copyright Case of the Decade:

"It will be interesting to see if the US Supreme Court is influenced by the view of the Court of Justice of the European Union that “copyright in a computer program does not protect either the programming language in which it is written or its interfaces (specifically, its data file formats) or its functionality from being copied.”^{9 [LawPundit includes here the actual footnote 9: Per SAS Institute Inc v World Programming Limited [2013] EWHC 69 (Ch), following C-406/10 SAS Institute Inc v World Programming Limited, ECLI:EU:C:2012:259)]"}

Years ago, already, we posted at length at LawPundit about this case at: 

Android and the Oracle Java API Copyright Scam Against Google
and
Jury Finds in Favor of Google Against Oracle in Android v. Java Fair Use Copyright Case

We thought that the case had been decided once and for all in favor of Google, but the Federal Circuit has once again upset the apple cart in now finding in favor of Oracle and negating and nullifying the jury verdict, so that the case has gone via the grant of writ of certiorari to the United States Supreme Court, in a case upon which the future of software -- at least in the USA -- hangs in the balance, as written by Tom Krazit at Protocol.com in Google and Oracle are headed to the Supreme Court. The future of software hangs in the balance.

"A generation of software built around shared assumptions for interoperability faces an uncertain future depending on the outcome of a yearslong legal fight between Google and Oracle."

Ronald Mann has a shorter detailed analysis at SCOTUSblog titled Case preview: Justices to weigh in on landmark copyright battle between Google and Oracle. See Ronald Mann, Case preview: Justices to weigh in on landmark copyright battle between Google and Oracle, SCOTUSblog (Oct. 5, 2020, 3:03 PM), https://www.scotusblog.com/2020/10/case-preview-justices-to-weigh-in-on-landmark-copyright-battle-between-google-and-oracle/

What is to be made of this case, which is so critical for the entire digital industry?

The legal issue of the copyrightability of software interfaces is so old that Jonathan Band has written extensively about it since 1995, most recently at Interfaces on Trial 3.0: Oracle America v. Google and Beyond, 148 Pages Posted: 5 Dec 2016 Last revised: 22 Jun 2018 -- the link to the pdf online is https://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID3197233_code1754101.pdf?abstractid=2876853&mirid=1&type=2.

Initially, as one can read there, software interfaces were correctly viewed as non-copyrightable, but, alas, weak judges and weak legislators in the USA and internationally have steadily eroded the inescapable conclusion that software interfaces were necessary for interoperability and were thus not "creative expression" in terms of copyright law. Rather such interfaces were solely functional and not within the ambit of the creative expression that the Founders intended to protect by establishing the Constitutional basis for copyright law.

Jonathan Band writes, to start out his most recent 2018 revision, Interfaces on Trial 3.0: Oracle America v. Google and Beyond, as follows:

"Here We Go Again.... [emphasis added by LawPundit]

In 1995, I coauthored the first volume, INTERFACES ON TRIAL: INTELLECTUAL PROPERTY AND INTEROPERABILITY ON THE GLOBAL SOFTWARE INDUSTRY (“INTERFACES ON TRIAL 1.0”), with Masanobu Katoh. At the time we published INTERFACES ON TRIAL 1.0, we thought that the interoperability debate was largely over. In the United States, several appellate decisions established that copyright did not protect interfaces specifications, the information necessary to achieve interoperability, nor did it prevent the reverse engineering necessary to determine the interface specifications. The European Union adopted a software directive that required member states to enact exceptions permitting reverse engineering for the purpose of achieving interoperability. 

However, contrary to our expectations, the interoperability debate continued. This continuation of the debate between 1995 and 2010 is chronicled in our second volume, INTERFACES ON TRIAL 2.0. That volume focused on two new threats to interoperability that emerged in the United States. First, several courts enforced contractual restrictions on reverse engineering, even when the vendors placed the restrictions in “shrinkwrap” or “click-on” licenses for widely distributed consumer software. Second, the World Intellectual Property Organization Copyright Treaty, adopted in December 1996, required signatories to take adequate measures to prevent the circumvention of copy protection technologies for purposes of infringement. As Congress was implementing this requirement, interoperable developers recognized that the broad prohibition Congress was considering would allow dominant firms to frustrate interoperability by placing “locks” on their software. Accordingly, the interoperable developers lobbied for and secured an interoperability exception in the Digital Millennium Copyright Act (“DMCA”).

INTERFACES ON TRIAL 2.0 also examined the interoperability debate in the Pacific Rim after 1995. Dominant U.S. companies, with the assistance of the U.S. Trade Representative, vigorously opposed the adoption of reverse-engineering exceptions based on the EU Software Directive in Australia, Hong Kong, and Korea.

When we submitted the book for publication in 2010, we once again assumed that the interoperability debate was over. We believed that there was a global consensus that copyright should not interfere with interoperability. And once again, we were wrong. In May 2014, the U.S. Court of Appeals for the Federal Circuit (“CAFC”) issued a decision in Oracle American v. Google that ignored the evolution of software copyright law over the past thirty years. In reaching its conclusion that copyright protects the elements necessary to achieve interoperability, the CAFC relied on a long-discredited Third Circuit decision, Apple Computer v. Franklin Computer, 714 F.2d 1240, 1253 (3d Cir. 1983), which stated that compatibility is “a commercial and competitive objective which does not enter into the somewhat metaphysical issue of whether particular ideas and
expression have merged.”
 
In addition to the CAFC’s disruptive decision, there have been developments relating to interoperability in the context of the DMCA’s prohibition on the circumvention of technological protection measures. Furthermore, the Court of Justice of the European Union (“CJEU”) in its 2012 decision in SAS Institute v. World Programming interpreted the European Union Software Directive in a manner consistent with U.S. law prior to the CAFC’s decision in Oracle America. These various developments have prompted me to write this third volume, this time without my friend and coauthor Masanobu Katoh."

Have the Federal Circuit judges read Band's work? We sincerely doubt it.

In the last 15 years we have never been wrong in pointing to decisions of the Federal Circuit that we thought would be overturned by the U.S. Supreme Court, and we hope that our streak does not end here in this very important case, as we again predict that the Supremes will find it an error that the jury decision was negated and nullified and replaced by the Federal Circuit's decision -- made only for the second jury trial and not for the first (!) -- that Google's actions were not fair use "as a matter of law" (the Federal Circuit opinion wrote that "we conclude that Google's use of the Java API packages was not fair as a matter of law").

In other words, we think the Supremes will formally skip the controversial copyright issue (#1 above) as such, and decide via the jury issue (#2 above), though there may be opinion dictum viz. dicta on the copyrightability of software interfaces, such interfaces being essential for software interoperability and which -- by their very strictly limited functional nature -- do not fall in any way under the creative "expression" required for a claim of copyright protection. Software interface code is not a book novel written for publication -- expressing an author's creative ideas -- rather, it is functional text, regardless of how it is written.

Historically, the Supreme Court has been very skeptical of the broad brush with which the Federal Circuit Court too often paints its decisions, and a court finding that certain challenged actions by Google -- contrary to the jury finding -- did not constitute fair use as a matter of law thus squarely puts the Federal Circuit at odds with the increasingly recognizable legal sanity found in modern Supreme Court decisions on intellectual property law, a common sense approach which recognizes that "fair use" -- "as a matter of law" -- is not such an easy thing to identify nor could one easily draw a "standard" from the Federal Circuit Court's decision here that could be applied to other cases.

Indeed, if the decision in favor of Oracle were upheld, it would lead to mass confusion everywhere in the world software industry -- especially if it is different from EU law -- as to what is protected and what is not protected by copyright law, not even mentioning the totally undeserved windfall profit that Oracle is trying to achieve via Java in this case, a result which was never intended by the Founders or the drafters of the U.S. Constitution. Obviously, American law and the U.S. Constitution prevail unequivocally, but one should also be aware of the rest of the world and be concerned about prevailing rules, especially in IP law.

Speaking of "the matter of law", American law has a four-factor test-- as a matter of law -- for fair use, and the jury found that fair use had not been violated. Mann, in his article cited above, in our opinion correctly identifies the standard to be applied: "Because the jury found that the use was fair, all agree that the verdict should be upheld if the evidence would have permitted a reasonable jury to reach that conclusion on any understanding of the factors."

It is obvious, we would think, that it is not the job of Federal Circuit Court judges to substitute their -- in our view -- oft errant opinions for those of "reasonable" juries. And we, for one, find the jury finding here to be eminently reasonable.

Case closed (or so we hope) -- for it all now depends on the opinions and decision of the Justices of the Supreme Court.

The upcoming oral argument will tell us more.