Hell.
Hand Cart.
The Obama administration is backing Oracle in its long-running legal battle against Google over the Chocolate Factory's alleged infringement of Java copyrights. Oracle brought the case against Google in 2012, claiming it had breached copyright in its Java software when creating its Android mobile operating system. Google …
A ruling that copyright applies to API's would not only bork Android, but most other software development as well when a perfectly legal operation of reverse engineering will become verboten due to copyright infringement. I don't know what the White House is thinking, but then, they probably aren't thinking through the ramifications of this ill-considered stance.
Languages running on the JVM are not an issue, as they are **using** the API and implementation as provided by the - licensed - JVM implementer (for example Oracle itself, or IBM). As such they are not in breach of copyright.
Google on the other hand **copied** the API and made an unlicensed implementation. That is the issue at stake here.
In other words your post is FUD.
No.
Google implemented their own libraries that presented the same calls in order to create a compatible development environment. They did so with entirely their own code. Reverse engineered from scratch.
An API is a list of functions. Just a list. As a result it is supposed to be considered a strictly functional thing that should not be protected by copyright.
Years ago I was writing a piece of software, it used an Library/API from a 3rd party. Our code relied heavily on calls to the 3rd party software. The 3rd party then with a later, needed release (due to compatibility issues) put up the price significantly and attached other commercially unacceptable restrictions. Option (A) was to rewrite large parts of our software to use a different API, option (B) was to implement either our own library that mimicked the existing API or option (C) was to bring in a new 3rd party API and create some bridging software mimicking the API.
Option (C) is often the preferred one given time constraints.
This ruling is saying that both (B) and (C) are wrong. They are copyright violations. They are actionable. What they actually are is software development.
Your post is the FUD.
Just the idea of an unlicensed implementation is bull and exactly the sort of garbage put out by Oracles press office. Please stop parroting it.
How dare you or anyone say I'm not allowed to implement a set of functions using my "own code".
Who is going to decide what library APIs are complex enough to allow copyright to stick?
Who is going to decide who many matching function calls are necessary to make it a copyright violation?
If I created an API compatible with another API but based entirely on my own implementation, what % of the functions have to be the same in order to make it naughty? All or them or one of them? Or what?
This is bad... It may not be bad for Google right now, the original case with it's IT knowledgeable judge threw out the case because he said APIs were purely functional and not expressive and as a result did not qualify for copyright protection.
A variety of other issues were as a result not ruled on. For example an official blog post by the President of Sun (despite Oracles denials that it was official it was listed in Suns SEC filings) saying how delighted they were with Android/Google and how everything was marvelous.
This ain't over yet for Google/Oracle but regardless if this ruling stands things could get pretty grim for developers.
I think maybe they are by pointing out fair use provisions.
That's how I interpret Verrilli's opinion too. IANAL, but he seems to be saying, "look, USC 17 sec 102(b) doesn't appear to do what you (Google) want. Try USC 17 sec 107". In other words, it appears to him that APIs are covered - for good or ill - by the existing language of the part of copyright law that explains what constitutes a creative work; so without getting the law changed Google's best option is to ask a court to rule that even though copyrighted, APIs can be copied under fair-use provisions.
That is ostensibly his job: to express the Executive Branch's interpretation of the law as it stands. Not as he personally would like it to be.
I certainly believe that giving APIs copyright protection is dumb and an impediment to innovation. But I'm not going to slander Verrilli because he believes the existing law doesn't exclude them.
(On the other hand, no one's surprised when the Reg readership adopts "an ill-considered stance". We're experts at that around these parts.)
It can only cause issues if copyright holders choose to restrict the use of their copyrighted works.
But APIs certainly should be protected by copyright as they meet the necessary requirements. Just because you don't like it doesn't mean they are any less subject to copyright. Creating a large API such as Java is a huge amount of work, how can it be right that someone just comes along and copies your years of work without any recompense?
I have absolutely no interest in whether <big company 1> or <big company 2> is in the right on this. If they want to waste millions of dollars on lawyers and court actions on this then they are free to do so.
However the idea that Java is now over because of this court verdict, and everyone's going to migrate to languages and platforms that you don't even know are any good or not is ridiculous.
So, billions of investment in Java based systems all over the world in the past 15 years is just going to be thrown away because of this spat? I would kindly suggest that it is not.
So if your company had to start paying for API license fees for APIs they created then they would just accept it any carry on?
This isn't just about Big Business 1 Vs 2, this is about those billions in investment for vast amounts of APIs suddenly requiring a license to be legally used.
Hardly a spat when it unexpectedly costs you money.
this is about those billions in investment for vast amounts of APIs suddenly requiring a license to be legally used
I realize many around here are hard of thinking, so I'll try to explain this in simple terms.
Copyright protection for APIs applies to copying them. Not calling them.
Yes and no.
It's about replicating functionality.
So if company A has a programme with inputs 1, 2, 3 to go through a process to produce output O and company B have a differently engineered solution for the same inputs and outputs then they would be in breach of copyright.
We've seen how vague and hotly contested patents are.
That little ditty you did as a workaround suddenly becomes a possible licensing offence. Expand that to all of the small workarounds and patches that are not only inherited in your company but everyone else's software kits and sites that you're using.
This IS about copyright, not patents. I boils down to the fact that software is covered by copyright, so the question is are APIs software? I've always believed that ideas are not copyrightable, but implementations are. APIs are slap-bang in the middle, straddling both sides. I guess you could say that they define the idea and are the first step towards implementation. We all know that enforcing copyright on APIs is a bad idea, but as someone who has written APIs I understand why they are covered by current copyright laws. It's the law that needs to be brought up to date.
A software API is like a novel's plot.
It is the implementation of the API that makes the novel, but the plot is intrinsic. However how many unique plots are there in stories? I'd argue a plot that included some of the implementation (character names, places, detailed plot breakdowns) would be copyrightable as it would uniquely identify the novel.
APIs have names, class names, interface names, etc. For example it might include an enum of Http Statuses by name. But they don't include the detail of the method of implementing getHttpStatus() on a HttpResponse object (or how that response object is created). Package names might be analogous to 'places' if you were high on opiates.
The interoperability argument does seem like a very strong path for Google to take. You can't change API names and places because that would break interoperability. Much like you can't rename Mordor and where it is between the LOTR books and the LOTR films - two different implementations of the same (detailed) plot. Argh.
Sorry, rambling insanity is now prevailing and the above analogy is full of (plot) holes. And it doesn't come out on one side or the other. I think the real issue is that the concept of someone copyrighting AND enforcing that copyright to the API to a programming language's core libraries in this day and age is pretty ludicrous.
A software API is like a novel's plot.
I don't think that's a very apt or useful analogy (as indeed your subsequent discussion, which produces rather more smoke than light, demonstrates). But regardless it has no bearing on the question before the court, because USC 17 doesn't protect "plots" per se. It protects creative works, without attempting to decompose them into functional areas, except in expressing certain limitations - for example, in permitting alterations to recording caused by technical restrictions during processing.
I've written APIs too.
The API is a list of function calls.
They are 99% functional and anyone who thinks the naming of the functions or parameters is expressive enough to require copyright protection thinks too highly of themselves.
As they are not expressive they should not be copyrightable. As copyright is to protect expression.
Most people felt the law on that was quite specific. Unfortunately it wasn't.
This is a barrier to market issue. Lets say you come up with a brilliant innovative way of doing some mathematical analysis.
You release a library with an API. The API has 20 or so function calls for doing the mathematics.
It's a huge success everyone doing X starts to use your library/API. You make a fortune. Life is good.
5 years later I come up with another way of doing it. Maybe it's as brilliant, maybe more, maybe less, maybe it's almost as good, maybe I'm selling it cheap. Regardless I want to compete with your product.
This ruling means my API has to be entirely different, this creates a massive barrier to competition. As anyone who is currently using your API has to either (A) rewrite their code or (B) perform their own copyright violation by writing an abstraction layer.
This is a bad thing. Especially for the small to medium developers.
@Indolent Wretch - Your argument is mainly just wishful thinking. You don't want APIs to be copyrightable, on which point most people would agree. That doesn't necessarily make it so, though.
I don't find the idea that API design isn't a creative process entirely convincing. I don't know about you but I reckon I can tell a badly designed API from a good one.
I[t] boils down to the fact that software is covered by copyright, so the question is are APIs software?
No. USC 17 does not create a special category of creative work for software, so the question of whether APIs "are software" (whatever that might mean) is irrelevant. The question is whether an API constitutes part of the protected part of a creative work.
Consider analogous questions:
- If you write a novel, is the name of a character in that novel protected by copyright? (Probably not. Trademark protection might be sought for a distinctive name.)
- If that character recites a short poem you composed, is that protected by copyright? (Almost certainly.)
- If that character uses a "catch phrase" several times in the novel, is that phrase protected by copyright? (Probably not.)
Where's the line between, say, the second and third cases? It's not clear in the actual definitions expressed in USC 17 chapter 1. Various court cases have debated the question of whether a given fragment of a creative work is sufficiently distinctive to be protected.
Software (as "computer programs") falls under USC 17 as a form of "literary work", by the way. See House Report 94-1476:
The term “literary works” does not connote any criterion of literary merit or qualitative value: it includes catalogs, directories, and similar factual, reference, or instructional works and compilations of data. It also includes computer data bases, and computer programs to the extent that they incorporate authorship in the programmer’s expression of original ideas, as distinguished from the ideas themselves. ...Some concern has been expressed lest copyright in computer programs should extend protection to the methodology or processes adopted by the programmer, rather than merely to the “writing” expressing his ideas. Section 102 (b) is intended, among other things, to make clear that the expression adopted by the programmer is the copyrightable element in a computer program, and that the actual processes or methods embodied in the program are not within the scope of the copyright law.
Yeah, but all of the recent figures I've seen indicate that the google is spending much more money on lobbying than Oracle is. Ellison is only JV evil now?
On the other hand, the google's lobbying may be more spread out than Oracle's? At this point it seems the google has something of a diffuse focus...
Google has the better case of course
There's no "of course" about it. Google are (this time) on the side of the angels - most people who aren't Oracle seem to agree about that - but whether what they're asking the court to decide is actually the most plausible interpretation of USC 17 is rather in doubt.
Anyone who thinks APIs aren't covered by copyright under US law is welcome to cite language in USC 17, or learned commentary thereon, to support that position. I provided the link above, for those who don't know how to use search engines. I admit, again, that I'm not a lawyer; but it does not seem at all clear to me either way whether APIs are excluded from the protection offered "computer programs" as a type of "literary work" by USC 17 Ch 1.
Now, Judge Alsup did make what I think is a good argument against including the API in copyright protection:
When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.
There are two essential points: The identifier names used in APIs are like other names, which generally aren't protected by copyright; and the material aspects of APIs (which would be things like what parameters a method takes) are often "the only way to express an idea or function".
The first point is pretty strong, but apparently not strong enough for the Federal Circuit. The second one I think is weaker, because generally an API represents not the only way to express a function, but simply the sensible way, or even just one choice among several. It's secondary considerations like existing practice that give value to the particular form of an API.
I'd very much like to see APIs excluded from protection, but I won't be at all surprised if it takes Congress amending USC 17 Ch 1 to do that. As Verrilli suggested, the best argument under existing law looks to be fair use.
Originally, Judge William Alsup of the US District Court of Northern California ruled that APIs are not copyrightable.
However, in May 2014 the US Appeals Court of the Federal Circuit in Washington DC overturned Judge Alsup's ruling, saying it had no choice but to uphold software copyrights"until either the Supreme Court or Congress tells us otherwise".
I don't think anybody is arguing that software shouldn't be subject to copyright law. They're arguing that an API doesn't contain any material that is coyright-able. Same argument was made in IBM vs SCO, I think.
MS and Sun fought over Java language (MS had J++), which resulted in C#, but not over the VM, as MS had their own VM.
This is actually quite complicated and is partly due to Oracle intransigence. The Desktop Java licence is essentially free. The Mobile Java isn't, and was for an era of very limited CPU and RAM, so is a more limited product.
Google actually bought in Android rather than add their own app VM and GUI on say Debian (which was running on mobile devices before Android existed.) Sun or Oracle, I forget which, wouldn't licence the full java for mobile. So Google did their own copy of the JVM.
Ironically the VM (or p-code) used by Visual Basic originally and morphed into .net for C# and other VM based MS Languages AND the originally Sun's VM for Java are both inspired by UCSD runtime for the p-Code produced by Pascal and other compilers. Western Digital or someone even did a bit-slice cpu (5 chips?) to run p-code as native.
So really it's almost unreasonable Oracle citing copyright, especially as they refused to licence the thing for Mobile. It's not like Google has copied all the implementation, but only the interface so existing byte code would run.
Google and Oracle have both been idiots on this.
>> It's not like Google has copied all the implementation
Google haven't copied ANY of the implementation.
Google copied some of the interface (Enough so that existing Java tooling could work).
The only copy of implementation Oracle could cite was a 10 line rangecheck() function ruled as utterly trivial by the judge despite Oracles attorney insisting it was a complex and crucial piece of software (and the story of how it got copied showed the bad faith of their actions IMHO).
Plus a bunch of testing scripts included by accident (left in by an Israeli software company) which served no purpose and which no evidence has shown ever ended up on anybodies phone.
>> so existing byte code would run
They didn't do that either. Google implemented all of the library with their own code, taking only the function list. They then implemented their own bytecode engine called Dalvik which worked on different principles to the JVM (stack based I believe, check wiki if interested) which was considered to be too slow for mobile and too bloated for memory limited devices.
The Sun compiler compiled the source (containing no Sun/Oracle code) into Java bytecode. A converter then runs against the Java bytecode converting into Dalvik bytecode (a .DEX file). This is then what gets installed on Android.
With the shift to Lollipop and the ART a lot of this has now changed but AFAIK when you developed an Android application not a single line of code written by Sun or Oracle at any point was transferred to the phone.
Is beyond my comprehension why somebody would let himself being kidnapped by a company like Oracle, their whole purpose is to put the customer inside a cage and don't let them spend their money anywhere else but Oracle products, is the gain from using Oracle products really worth the hassle? Why did Google chose Java as the base for Android? There are tons of development tools out there that could've done the job without the Oracle licensing threat.
Right, you clearly didn't read the original lawsuit as to why the Java language/API was chosen. I will give you a guess, it's the toolchain and huge developer base. Don't believe me, just ask all the DOA mobile OSes that have chosen to use something else such as WebOS, Firefox OS etc ...
> Microsoft can finally crack down on DR-DOS!!
Except that Novell (as the purchaser of DRI) can crack down on MS-DOS first.
Actually DRI demonstrated to IBM that PC-DOS 1 infringed DRI's copyrights (allegedly it displayed a DRI copyright notice). The settlement included allowing DRI to use any part of the PC-DOS/MS-DOS API.
If an API can be protected by copyright, then the ENTIRE phone market (excepting M$) will owe royalties to AT&T.
The Lions' Commentary on the UNIX 6th Edition source code bears prominent copyright notices. Suddenly, fork() stat() getuid() signal() and the rest of the V6 kernel system call implementation is now owned by Bell Labs.
Bell Labs went to Lucent, which is being swallowed by Nokia.
How can this not impact anything POSIX?
Is that the end of environments like WINE (a Linux implementation of the Windows), Mono (a multi-platform port of .NET), Haiku (a open source implentation of the BeOS API), and AROS (an open source implementation of the Amiga OS).
A major part of all these projects is API-level compatibility. This could kill innovation and alternative O/S.
why didnt they do so in the first place?
Fair Use is a tricky legal doctrine. Having APIs declared unprotected would be a much safer position for Google (and everyone else).
And, as Alsup's original decision shows, it's not a clear-cut question. Verrilli's interpretation is that nothing in USC 17 Ch 1 excludes APIs from protection. Alsup's decision was, AIUI and IANAL, that protection didn't include APIs because their creative content is limited to sorts of expression that traditionally hasn't been protected, like names. (See my post above quoting the relevant sentences.) But note that's an interpretation based on implicit aspects of the law and precedent - not on what's explicit in the statute.
The Federal Circuit somewhat reluctantly disagreed with Alsup. SCOTUS might turn it around again, if they take it up, but I think there's a good chance they'll let the circuit decision stand.