Slashdot Mirror
Declaring Code Is Not Code, Says Larry Page (arstechnica.com)
Alphabet CEO Larry Page says his company never considered getting permission from Oracle for using the latter's Java APIs in Android. Page, who appeared in a federal court, said Java APIs are open and free, which warrants them or anyone to use it without explicit permission from Oracle. From an Ars Technica report (edited for clarity): "But you did copy the code and copy the structure, sequence, and organization of the APIs?" Oracle attorney Peter Bicks asked, raising his voice. "I don't agree with 'copy code,'" Page said. "For me, declaring code is not code," Page said. "Have you paid anything to Oracle for using that intellectual property?" Bicks asked. "When Sun established Java, they established it as an open source thing," Page said. "I believe the APIs we used were pretty open. No, we didn't pay for the free and open things." [...] "Was Google seeking a license for Java?" Google lawyer Robert Van Nest asked. "Yes, and a broader deal around other things, like branding and cooperation," Page said. "After discussions with Sun broke off, did you believe Google needed a license for APIs?" Van Nest asked. "No, I did not believe that," Page said. "It was established industry practice that the API and just the headers of those things could be taken and re-implemented. [It must be done] very carefully, not to use any existing implementation of those systems. That's been done many, many times. I think we acted responsibly and carefully around these intellectual property issues."
If APIs are copyrightable, this will be a huge problem for projects like Wine (which implements Microsoft APIs), and GNU/Linux (which implements Bell labs APIs).
Compaq reverse engineered the BIOS. It did not copy the text of some file that defined the API. I don't think that the INT operations even had fixed names - they had numbers. So a BIOS call would be documented as http://stanislavs.org/helppc/i...
INT 16,0 Wait for keystroke and read
This exact operation can be described using different words e.g.
On Int 16,0 the system will pause until a keystroke is pressed and the value will be placed in AH.
I understand the issue in Oracle v. Google to be exact copying of some number of interfere files. Such files did not exist for BIOS as far as I recall.
In general, the fact that something is a creative work or takes time to create doesn't necessarily make it copyrightable. For a creative work, any functional aspects of that design are supposed to be protected by patents, not copyright. And an insufficiently creative work isn't protected at all, no matter how much time it took to create it.
For example, the courts long ago ruled in Feist Publications, Inc., v. Rural Telephone Service Co. that the difficulty of creating something is not sufficient to make it copyrightable when they declared that a phone book is a non-creative collection of facts. One could reasonably argue that a header file collects the declarations from source code, and that the real creative work is the source code itself. After all, the sole reason for a header file is to consolidate a bunch of declarations into a form that that makes it easier for a compiler to digest. This arguably makes a header no more a creative work than the phone book. That's not arguing that an API shouldn't be copyrightable per se, so much as that a header shouldn't be unless it contains other creative works beyond the declarations.
Also, per 17 U.S.C. section 1302, anything that is "dictated solely by a utilitarian function of the article that embodies it" is not eligible for copyright. The intent of copyright law is to shift responsibility for protecting such creative works into the domain of patent law. So given that there's a strong utilitarian aspect to APIs (because any function has basically exactly one valid declaration, or else your code won't link correctly), if you want to argue that an API should be protected by copyright, you have to come up with a concrete argument of why that API's design is more than just utilitarian in nature. So any creative effort that was focused on making an API easier to use doesn't count towards the creativity requirement for copyright purposes.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Not everything that takes a lot of intellectual effort is copyrightable.
Lists of ingredients in a recipe is considered not to be covered, no matter how long the chef spent in making the ratios perfect or how many spices they tried before they came across the right combination. Likewise, a haiku I write in a tweet with little thought or time spent on it is probably covered under copyright.
Mathematical equations are not copyrightable even though it might take years of very specialized effort to prove a mathematical theorem. But in this case it's because it's considered a discovery not a creation.
My point is that effort has nothing to do with whether or not something is copyrightable.
I think for APIs there can be some grey zones, as you say about architecting APIs there can be various interpretations of the same concept, and for that I can see some argument for copyright coverage. But for some things it definitely approaches the level of mathematics. For example can I copyright the API of java.util.Math.sin, which takes a number and receives a number?
Even if we solved the copyright question and say some APIs can be covered by copyright, it seems reasonable to me that re-implementations of that API to support existing things written to that API is fair use under the concept of compatibility. At a minimum, it is existing long-established industry practice. WINE implements the API of Windows to allows Windows applications to run on Linux. Samba has reimplemented the SMB APIs for file sharing from Microsoft. Apple re-implemented various filesystems. A lot of caching servers re-implement the API provided by memcached. Countless emulators like qemu have reimplemented the instruction sets of various processors. AMD implemented Intel's x86-32 architecture and Intel re-implemented AMD's x86-64 architecture and no one got sued and the industry was better for the competition. And don't say CPU architecture isn't an API. The list of instructions supplied by a CPU are direct equivalent to a list of functions in a Java API. Each instruction says it takes a list of parameters and returns a list of results and the types of results and even the name of the instruction, which has all of the same components of a typical software API. To go back to your argument about "architectural effort" I'm sure Intel and AMD spent years perfecting their instruction sets and picking the most useful ones, but that has no bearing on their reuse. Even for the Java API case specifically we have the example of GNU Classpath which re-implemented Java APIs and preceded Google Android yet with no legal action (that I've heard of) from Sun, implicitly endorsing the re-implementation of API.
So, if all of these projects can re-implement the APIs, network interfaces, instruction sets, etc. of another system in such a way as to allow running of the same software on a different implementation, how is a re-implementation of Java any different.
There are two basic chord progressions: IV-V-I and V-IV-I; everything else is just variation.
Even counting variations, you won't get a practically infinite number of chord progressions unless you move away from the seven modes and the diatonic scale, and even then, only if you create a practically infinite number of new scales and modes could you say there you have a practically infinite number of chord progressions. And what you'd be left with is a practically infinite number of incomprehensible noise plus a bunch of chord progressions that sound pretty much like the ones we know already. Our ears are just tuned that way.
Software companies will all close shop in the U.S. and move their operations to countries where APIs are legally declared not copyrightable. ... The U.S. will be relegated to a software backwater, as most of the software made and sold in the rest of the world cannot legally be distributed in the U.S.
Something similar to this happened with encryption. The US regulated it as a weapon and banned / limited / added red tape to the export of strong encryption software. US companies also couldn't import strong encryption software, include it in their products, and resell them elsewhere. The software had to be installed outside the US by non-US companies.
The result was that commercial development and deployment of strong encryption software pretty much stopped in the US and picked up outside its boundaries for several years, and various workarounds were developed (such as "encryption with a hole" so a strong encryption module could be installed later).
This continued up to about the turn of the centur, when laws, policies, and court decisions loosened things up enough that US companies could play again.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way