Insanity Wins As Appeals Court Overturns Google's Fair Use Victory For Java APIs
from the this-is-bad dept
Oh, CAFC. The Court of Appeals for the Federal Circuit has spent decades fucking up patent law, and now they’re doing their damndest to fuck up copyright law as well. In case you’d forgotten, the big case between Oracle and Google over whether or not Google infringed on Oracle’s copyrights is still going on — and it appears it will still be going on for quite a while longer, as CAFC this morning came down with a laughably stupid opinion, overturning the district court’s jury verdict, which had said that Google’s use of a few parts of Java’s API was protected by fair use. That jury verdict was kind of silly in the first place, because the whole trial (the second one in the case) made little sense, as basically everyone outside of Oracle and the CAFC had previously understood (correctly) that APIs are simply not covered by copyright.
Section 102(b) of the Copyright Act says quite clearly:
In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.
And an API is pretty clearly a procedure, process, system or method of operation — it’s just instructions on how to access certain elements, similar to a recipe. But, CAFC (who shouldn’t be hearing this case in the first place) simply couldn’t be bothered to comprehend what an API is, and insisted that because to the judges non-technical brains, an API looks the same as software, it must be copyrightable as software. That was after Judge Alsup in the district court (following trial #1) had spent quite a lot of time explaining to CAFC why APIs are not copyrightable.
Thus, we had the second trial, which was weird, because all of the arguments about fair use, were couched in this weird “um, well, it’s not really copyrightable at all, but CAFC says it’s copyrightable, so let’s just say it’s fair use” argument. And the jury then said, yes, it’s fair use.
But CAFC has now rejected that and sent the case back to the lower court for a third trial for damages. And, while we normally expect bad reasoning from CAFC decisions, this one is particularly stupid. In short, CAFC’s reasoning is basically “we think this is infringement, and thus we’re going to handwave around the law to make sure that it’s infringement.” It’s bad. And, again, CAFC shouldn’t even be hearing the case. CAFC hears appeals on patent cases, and originally there were a few patent claims in this case, but they all got dumped at a very early stage. So this case should have gone to the 9th Circuit (who also might have messed it up, but it has at least a marginally better record than CAFC).
Anyway, the CAFC does an awful lot of handwaving around historical precedent to justify its decision to basically start from scratch in going through the fair use four factors. As we’ve discussed multiple times, one of the problems with the four factors test is that it allows a court to choose who it likes better, and then twist the four factors to give it the outcome it wants. That appears to be what is happening here. On the first factor (nature of the use), CAFC basically says “we think the jury is stupid, this is obviously commercial use, and thus it goes against Google.” Google had argued (and the jury had implicitly agreed) that because Google doesn’t charge for Android, and interoperability and progress of innovation enabled by using similar API setups are not inherently commercial motives, that this was fair use. The court basically says “but Google has so much money!” which is not how a fair use argument works. But… CAFC.
That Google might also have non-commercial motives is irrelevant as a matter of law. As the Supreme Court made clear when The Nation magazine published excerpts from Harper & Row?s book, partly for the purpose of providing the public newsworthy information, the question ?is not whether the sole motive of the use is monetary gain but whether the user stands to profit from exploitation of the copyrighted material without paying the customary price.? Harper & Row, 471 U.S. at 562. Second, although Google maintains that its revenue flows from advertisements, not from Android, commerciality does not depend on how Google earns its money. Indeed, ?[d]irect economic benefit is not required to demonstrate a commercial use.? A&M Records, 239 F.3d at 1015. We find, therefore, that, to the extent we must assume the jury found Google?s use of the API packages to be anything other than overwhelmingly commercial, that conclusion finds no substantial evidentiary support in the record. Accordingly, Google?s commercial use of the API packages weighs against a finding of fair use.
On the question of transformative use, the lower court had suggested that using the APIs in a “fresh context” (such as for smartphones) could be seen as transformative. But, again CAFC says “nope.”
Google?s arguments are without merit. As explained below, Google?s use of the API packages is not transformative as a matter of law because: (1) it does not fit within the uses listed in the preamble to § 107; (2) the purpose of the API packages in Android is the same as the purpose of the packages in the Java platform; (3) Google made no alteration to the expressive content or message of the copyrighted material; and (4) smartphones were not a new context.
CAFC also, once again, shows that it still doesn’t understand why APIs and code are not the same thing:
That Google wrote its own implementing code is irrelevant to the question of whether use of the APIs was transformative. As we noted in the prior appeal, ?no plagiarist can excuse the wrong by showing how much of his work he did not pirate.? Oracle, 750 F.3d at 1375 (quoting Harper & Row, 471 U.S. at 565). The relevant question is whether Google altered ?the expressive content or message of the original work? that it copied?not whether it rewrote the portions it did not copy.
But that’s not the relevant question. The relevant question is how the copied text is being used, and in Google’s case it’s in a completely different context, which is why it had to write its own implementing code. Again, this is fallout from CAFC’s earlier wrong decision in that it still does not understand that API instructions are not the same as implementing code itself.
The court also more or less laughs at the idea that Google had “good faith” reasons for doing what it did:
Ultimately, we find that, even assuming the jury was unpersuaded that Google acted in bad faith, the highly commercial and non-transformative nature of the use strongly support the conclusion that the first factor weighs against a finding of fair use.
On factor two of the four factors analysis — the nature of the work — CAFC again actually gives that one to Google and says that the jury could have found that weighed towards fair use, but immediately points out that it’s going to give this factor less weight, because… it still doesn’t understand the difference between APIs and software, and insists that if it gave this factor any weight, it would destroy the idea of copyright for software. Of course, that’s only true if you can’t tell the difference between an API and software.
We note, moreover, that allowing this one factor to dictate a conclusion of fair use in all cases involving copying of software could effectively negate Congress?s express declaration?continuing unchanged for some forty years?that software is copyrightable. Accordingly, though the jury?s assumed view of the nature of the copyrighted work weighs in favor of finding fair use, it has less significance to the overall analysis.
On factor three, concerning the amount use, the court again is so incredibly confused it’s frustrating. Google has long held (and the jury and the lower court appeared to agree) that it used the bare minimum of the Java API to enable basic interoperability in building apps for Android. But CAFC is so tied up in its own made up reality, that it insists no reasonable jury could agree with this:
Even assuming the jury accepted Google?s argument that it copied only a small portion of Java, no reasonable jury could conclude that what was copied was qualitatively insignificant, particularly when the material copied was important to the creation of the Android platform.
Eventually, though CAFC says factor 3 could be either “neutral” or “arguably weighs against” fair use.
On to factor four — the impact on the market. Factors one and four tend to be the ones that courts focus on the most. And, here, Oracle has spent plenty of time whining that its own total failure to capitalize on Java in the mobile market should be blamed on Google’s copying piece of its API as opposed to the reality, which is that Oracle completely botched its own efforts in the space, because it’s Oracle. The court more or less ignores various points about how Oracle wasn’t really in the mobile market and more or less says “Google was super successful, so clearly it was at the expense of Oracle.”
Given the record evidence of actual and potential harm, we conclude that ?unrestricted and widespread conduct of the sort engaged in by? Google would result in ?a substantially adverse impact on the potential market for the original? and its derivatives.
And, thus, the court then weighs factors one and four most heavily, and says it’s not fair use, and back to Northern California we go for trial number three, specifically on the damages question. I imagine Google will appeal this, either asking for an en banc rehearing or to the Supreme Court. The Supreme Court refused to hear the previous request on the question of copyrightability of APIs, so this is probably a long shot. However, there are a few oddities within the ruling that maybe will catch someone’s attention at the Supreme Court (and the Supreme Court has spent years dunking on CAFC and mocking its dumb decisions, so maybe they’d like to do that again).
Honestly, the most concerning part of the whole thing is how much of a mess CAFC has made of the whole process. The court ruled correctly originally that APIs are not subject to copyright. CAFC threw that out and ordered the court to have a jury determine the fair use question. The jury found it to be fair use, and even though CAFC had ordered the issue be heard by a jury, it now says “meh, we disagree with the jury.” That’s… bizarre.
Anyway, considering the importance of interoperability in software, this case is yet another potential disaster, limited only by the fact that CAFC doesn’t cover any particular region and most copyright cases aren’t influenced by CAFC precedent since those cases would flow up through the other appeals courts. However, you can see how someone wishing to go after others for API infringement might just throw in a silly patent claim just get it into CAFC. Hopefully the Supreme Court steps in and fixes this, but if not, it would be nice (I know, I know…) if Congress actually stepped up and pointed out that APIs are not covered by copyright at all. And while they’re at it, they should burn CAFC to the ground. It was a dumb idea in the first place and should be shut down.
Filed Under: api, apis, cafc, copyright, fair use, interfaces, interoperability, programming
Companies: google, oracle
Comments on “Insanity Wins As Appeals Court Overturns Google's Fair Use Victory For Java APIs”
Easy way to solve this...
Give the CAFC all the documentation on the API.
Let them ask as many questions as they’d like.
Let them have access to Oracle programmers.
Ask them to write a bit of code, using only the API, and then try to do something with it.
No other languages/editors/IDEs/programming environments.
Just API lines written in a text editor, saved as a file.
Try to run the API program using only the API.
Re: Easy way to solve this...
That doesn’t help. Copyright has nothing to do with usefulness; it has to do with creativity. Even broken code which does nothing would have copyright.
Re: Re: Easy way to solve this...
/lkajhsdlgfj ahg; IUjr’pigfu a;oihdefkujhg .ahd
I claim the copyright to this ‘code’.
No, since you ask it does not work or do anything, but what has they go to do with it? Right?
Re: Re: Easy way to solve this...
It certainly does do something.
It shows the morons^H^H^H^H^Hembers of CAFC that APIs are “not” code.
It shows conclusively that the CAFC are in fact morons for thinking they were the same and that copyrights do not apply to APIs.
Re: EASIEST way to solve this was to pay a TINY fee.
One would think that with all the billions for nearly nothing, several of which have been wasted on “Google Internet”, the ridiculous fuel cells, and various programming starts, that Google would just pay the pittance.
But that’s not the GOOGLE-BORG way. It wants to assimilate for free.
So yet again, GOOGLE went to court and got adverse decision.
Re: Re: EASIEST way to solve this was to pay a TINY fee.
Sure, blame the victim
Re: Re: EASIEST way to solve this was to pay a TINY fee.
And this whole post just tells me you still don’t understand the decision and the implications of it.
I think Google actually might have a good shot at the Supreme court, mainly on procedural grounds. The CAFC explictly ruled that a Jury should determine fair use. A superior court normally shouldn’t disregard the Jury finding, and they have noted no bad jury instructions or other reasons to disregard the Jury findings. That seems, from an outsider, to be a major misstep, the kind of which the Supreme Court has loved to smack around the CAFC for.
Re: Re:
I think the Supreme Court might take to smack the CAFC down because this ruling is so damaging. It’s mind blowingly terrible how the CAFC is so bad at their jobs
I bet Hollywood is working on getting all copyright cases appealed to the CAFC, as it always seems to side with the I.P holders.
This whole argument is being framed over language that is misleading to the extreme. "Declarative code" and "Implementing code" are not industry terms; the terms every CS101 student learns are "code declarations" and "code definitions". This is important, because the phrase "declarative code" implies that code declares, when in reality, code is declared. This is perhaps the biggest source (and evidence of) confusion in CAFC’s opinions (and that of the Solicitor General in his brief to the Supreme Court in the previous appeal).
Code declarations and implementations are like dictionary entries. Dictionary entries contain two parts: Syntax information (spelling, pronunciation, part of speech, etc) and the definition.
Syntax information allows writers to correctly use a word, as well as allows readers to determine if a word is used correctly. For example, if I tell you that the word feldercrump is a noun, then you can write the following sentences, and see that the sentence "I saw a feldercrump" uses it correctly, whereas "I feldercrump on Sunday" does not.
However, without the Definition, no one can extract any meaning from the sentence. You can’t know what idea backs the word feldercrump. Even still, different dictionaries might contain similar but different definitions for the word, even though the syntax information stays the same.
The former is equivalent to code declarations: they do not instruct computers, but rather, allow compilers, interpreters, and programmers to know how code is to be used, as well as determine whether code is used correctly, but there is no code to run or execute. Implementations, however, are the definition of a function, and consist of actual computer instructions. Any function used to implement a particular interface can be used to give meaning to a use of the interface.
Re: Response to: Anonymous Coward on Mar 27th, 2018 @ 11:23am
This. I agree the likelihood of confusion about an API could be at play here (and influence the result).
You can bet the definition of an API has been twisted by the attorneys to help their argument. They need not agree.
So they didn’t agree with the first decision and sent it back to get a decision based on more input. Then they are rejecting the second decision based on what they asked for. If the third decision disagrees with their view then what? Keep going until they can get something they agree with just because Google is rich? As much as you hate Google this is very wrong. Just imagine a smaller company scoring win after win and having to burn through their hard earned cash because some group of imbeciles can’t be bothered to understand what they are ruling over. This should be very, very disturbing to anyone with more than 2 neurons.
Way to go CAFC … that might be the last nail in the Java coffin.
Java hasd been dying for some time, and then there was some hope when Sun declared Java to be open source … wth happened?
I doubt any new development will use Java with this axe hanging over its head.
Re: Re:
Oracle!
Re: Re: Re:
Just picture this exchange mentioned in Steve Jobs’ biography:
“I said okay. That might work,” Ellison said. “But Steve, if we don’t buy Apple, how are we going to make any money?”
Ellison went on: “Steve stopped walking and turned toward me. We were facing each other and he put his left hand on my right shoulder and his right hand on my left shoulder.”
Jobs then said to Ellison: “Larry, this is why it’s so important that I’m your friend. You don’t need any more money. … I’m not doing this for the money, I don’t want to get paid. If I do this I need to do this standing on the moral high ground.”
Re: Re:
I’ve heard that same doom several times over several years and it still has had no detrimental impact on the market. Java is “dying” as programming is “dying”, i.e. it’s not.
What happens in the android world has next to zero impact on what happens in all other places java is used. And this ruling won’t have much, if any, impact on java usage elsewhere with the narrow possibility it will shut down OpenJDK.
Re: Re: Re:
Cobol is a dead language and yet it still lives.
But, yes – I agree. I suppose the term “dead” is inappropriate in these cases, I propose using the term “buggy whip language”.
Re: Re:
Because killing tech we don’t like is more important than decent legal precedents, right?
Re: Re: Re:
More like fading into the sunset than being killed.
Software usage is not a popularity contest. Some languages are simply better than others for certain applications.
And, I do not think it is an either / or situation here is it? Why can’t we both kill off old software and have legal precedents? You do not need Java to prove APIs are not copyrightable.
I am going to copyright a doorknob and everyone who opens the door will have to pay me or face copyright infringement.
then I will move on to copyrighting buttons.
Re: Re:
Downside is doorknobs have existed long enough for even copyright to expire on them. Same with buttons. You will have to find something else.
Re: Re: Re:
No, he just has to get his claim heard by the CAFC, and bingo total control.
Re: Re: Re:
Just limit it to doorknobs designed within the last 70 years. If re-releasing a song in a new album refreshes copyright, then redesigning a doorknob might as well too. No idea is too stupid for it to not work in IP-land!
Re: Re: Re:
In this case, the method of grasping the door knob is “copy righted”.
Re: Re: Re:
Normally you’ld be absolutely correct.
But this is the CAFC. History shows that the CAFC will be eager to entertain any mixed-up and confused — but semi-plausible — interpretation of facts and law, that might conceivably, in their view, lead to stronger “Intellectual Property protection.”
Re: Re:
That’s a completely irrelevant analogy. Not at all what this case is about.
Re: Re: Better example
You’re correct,
This is actually like an auto making suing another auto maker and winning because both vehicles adhered to federal automotive standards.
Re: Re:
As long as your copyright is for a doorknob or button “on the internet,” that would probably work.
At least, the Federal Circuit wouldn’t stop it.
Re: Re: Re:
It all depends on what type of door it is. If it’s a doorknob on a backdoor on the internet then law enforcement might be interested.
Re: Re:
Hey, can you copyright a secret handshake?
It sure has been a bad week for Masnick’s favorite companies.
Re: Re:
Sound like someone has a full nappy.
Re: Re: Re:
is*
Re: Re:
And only shitstains have been applauding. Which explains your presence.
Anyone keeping tally on how many millions have been wasted on this argument over stupid imaginary things?
It’a sad they can’t comprehend APIs should not be copyrightable. In truth, most software lacks the originality needed to deserve a copyright.
About only thing they got right was Google extracting boatloads of $$$ from Android. (Which is irrelevant to the reasons why this case should have been dropped ages ago.)
Re: Re:
I thought this had been beaten sufficiently during the SCO debacle and then Oracle tries the same shit, different software.
Important questions:
How many of the CAFC judges were paid off by Oracle?
How many anti-google Legislators pressured the CAFC to rule against google?
Re: Important questions:
None — they’re True Believers in stronger protections for “Intellectual Property”.
Good Riddance Oracle
Hopefully this will put the well-deserved final nail in Oracle’s coffin liberating us all from the misery of using their products.
Re: Good Riddance Oracle
Wait… People still use Oracle products?
Re: Re: Good Riddance Oracle
The U.S. government had a contract. Oracle might still have that contract.
Make of that what you will.
Re: Re: Good Riddance Oracle
Unfortunately yes. Their products suck big time too. Java is the best thing they’ve got and it’s only so so as a programming language. It’s best feature was that there were lot’s of APIs. Not anymore and it’s owned by Oracle. You’d have to be crazy to use it now. This is Oracle’s last hurrah and the US tech industry too if this ruling stands.
Re: Re: Re: Good Riddance Oracle
Oracle is handing JAVA EE over to the eclipse foundation, where it become Jakarta.
Copyright ruining the day, once again.
REPEAT of 2015: Designing and specifying API was creative work.
(That is, repeat of ME predicting / opinion from 2015 — which is now proved RIGHT!
Google as usual just trying to steal value. Very simple when put that way, isn’t it?
What chiselers those Googlers are. They even stole the name "google"!
And yet again, Masnick can’t see this any other way than Google’s. We all know why. Take the Copia link.
Re: REPEAT of 2015: Designing and specifying API was creative work.
Okay, one, how did they “steal” the name Google?
Second, you do know Masnick has often been quite critical of Google, right? I don’t get why people like you make him out to be some sort of pro-Google devout or something.
Finally, anyone could have predicted that the CAFC would have made this sort of decision… including Masnick. That doesn’t mean it’s the proper decision. Frankly, I think that the CAFC should only be dealing with patent law, and they never should have handled the copyright claims.
Re: Re: Not worth the time
Don’t waste too much thought on them, they’re the rabidly anti-Google/TD/Mike individual, and among their many charming qualities are some truly hilarious strawman versions of the site and those that run it that they like to beat up on to the amusement of those watching.
Re: Re: REPEAT of 2015: Designing and specifying API was creative work.
I’d guess the suggestion is that they borrowed “google” from one or both of “googly” (as in “googly eyes”) and “googol”.
Neither of which is any more of a direct copying than are a large number of other company names, particularly if you take into account that neither of the two terms has much connection to the search-engine field which is what the company was originally getting into – i.e., that even if the term was taken from those places, the chosen use was transformative.
Re: Re: REPEAT of 2015: Designing and specifying API was creative work.
The same way Microsoft stole the name "Windows".
(Just to avoid confusion — that was sarcasm).
In fact, API design and spec is some of the KEY creative
**work for a programming language.**
Google could have just paid a token fee and none of this long fight would be necessary!
But Google’s “business model” is to get values for free: whether it’s new headlines, web-site text, your web-site visits including activity such as downloads, phone calls, associations, or the java API, Google just TAKES.
Anyhoo, Masnick WRONG again on court case. SAD but Typical!
Re: In fact, API design and spec is some of the KEY creative
There is this little file, which is simple to use, which controls what Google, or any other search engine can index, and which can keep a site out of Google news. The fact that most sites that complain about Google stealing their value do not use robots.txt to control what Google indexes shows that they actually find being in the Google indexes valuable to them, by sending them visitors.
In other words, providing a searchable index is a valuable service sending searchers to content providers, and required significant investment in hardware, along with hardware and software design, most of which Google have made opensource.
Re: In fact, API design and spec is some of the KEY creative
As a programmer, I wholeheartedly disagree. Copyrighting an API is comparable to copyrighting a language; it’s nothing more than a framework for a systemic be implemented.
Re: Commin law says an API is fair use.
Re: In fact, API design and spec is some of the KEY creative
You think Google is the only corporation out there that takes things?
How cute.
The API is not the key creative component of any software anywhere. You obviously are not in the field.
Google began their software development prior to the Oracle purchase of SUN, who held the rights to Java and publically stated their intent to open source Java – but something got dropped and Oracle figured wth, let’s demand payment and the dev world gasped.
Re: In fact, API design and spec is some of the KEY creative
Let’s see, two actual court cases/trials that lasted months, if not years, with both sides presenting evidence said Google’s use of Java API was legal. One of which was court ordered to be tried by a jury and the jury sided with Google.
One appeals court takes a quick look without a full trial and rejects both decisions (including the jury trial they themselves ordered) “just because” with no evidence to support their decision and you think that proves you right?
I laugh in your general direction.
It seems the CAFC has an agenda and is not actually interested in neutral justice.
Re: Re: In fact, API design and spec is some of the KEY creative
It’s like the CAFC isn’t really a court at all.
And what set of rules determine how the Java APIs work?
Any Java code is compiledinterpreted according to strict rules and methods of operation, ALL of which are based on languages and interfaces that went before it.
The method of writing a Java API is no different to writing an API in any other language..
<return value> function name (function inputs/interfaces/pointers)
This case seems to ignore that writing an API is done via another API.
https://en.wikipedia.org/wiki/Application_programming_interface
"Find them GUILTY already dammit!"
The court ruled correctly originally that APIs are not subject to copyright. CAFC threw that out and ordered the court to have a jury determine the fair use question. The jury found it to be fair use, and even though CAFC had ordered the issue be heard by a jury, it now says "meh, we disagree with the jury." That’s… bizarre.
Only if you assume that the CAFC is operating from a position of neutrality. If you look at it through the lens of ‘We’ve already determined that they’re guilty, but these other courts keep screwing it up’ it makes perfect sense.
Anything other than ‘API’s are absolutely covered by copyright, Google was grossly infringing on Oracle’s copyright and they must pay’ is a ruling they’ll overturn and send back down to do again, ‘correctly’ this time.
CAFC has already determined that Google is guilty, and they’ll send the case back down as many times as they need to for those lesser courts to get it right.
Re: "Find them GUILTY already dammit!"
CAFC is staffed by IP extremists, and they always support the claims of IP owners, unless smacked upside of the head by the supreme court.
CAFC = Completely Absolutely F**king Clueless
Re: Re:
Corrupt And Fucking Clueless
APIs are plumbing
As a software engineer of many decades, and a Ph.D. graduate in computer science, I find the lack of understanding of APIs disturbing. An API is an interface, just like the shape of the holes in a power socket, or the size and shape of a bolt connecting a car’s engine to its wheels. It’s a means to an end. It’s generally not an enormously expressive and creative piece of work. Rather, it’s a necessarily functional interconnection which enables a machine to be plugged together.
Elsewhere some programmers have mentioned “int round(float)” as an API. That is an API for rounding a fractional number, and it’s a trivial case of someone writing down in a computer language a mathematical function that mathematicians have been writing or describing for centuries, using various words and symbols. Should the mere act of writing it in a computer language as opposed to a spoken language cause that line to gain or hold copyright? To me that’s like saying a verbal description of a hex bolt, written years ago, holds no copyright, but a CAD drawing of a hex bolt does, or that the physical item does. For the sake of interoperability, I believe such physical items have traditionally not held any copyright. They’re functional parts of a machine, despite any creativity involved in their design. Furthermore, such single API lines are often so trivial that it’s hard to see how any copyright could exist in them.
As far as I remember, Oracle wasn’t so much claiming that a single line of an API on its own should hold copyright, but rather that the “collection and organisation” of several such lines should hold copyright. APIs are often grouped into modules or classes, so that, for instance, several mathematical functions such as rounding and truncating fractions, square roots and exponentiation and logarithms, etc would all be placed into a Math module or class, while reading and writing files would be placed in a File module or class, and so on. The particular arrangement is somewhat arbitrary, but it may be necessary for a competitor to duplicate that arrangement exactly for interoperability. I believe this is what Oracle was claiming involved some creativity and was therefore due some copyright protection. To me, that’s like arguing that putting the carburettor on the left side of the engine and affixing it with hex bolts is a creative choice that no competitor should be allowed to replicate. Yes, the particular arrangement had to be creatively arranged and functionally designed, but for the sake of interoperability with competing manufacturers, copyright should not extend to such interface designs. If it’s truly innovative, that’s what patents are for. If not, it’s just plumbing.
From the point of view of a software engineer, APIs should clearly not hold copyright, any more than a hex bolt should, or an electrical wall socket specification should. I wonder how lawyers, arguing from a dry set of rules, can justify that their pronouncements are valid when they seem so divorced from industry practice. Ultimately, their motivations need to be understood to see why they’re pushing the particular interpretations they’re asserting. I think this sentence speaks loudly to the CAFC’s concerns: “allowing this one factor to dictate a conclusion of fair use in all cases involving copying of software could effectively negate Congress’s express declaration… that software is copyrightable.” I can see how the inability to perceive the differences between interface and implementation could lead someone to worry that allowing copying of APIs could unravel the whole copyrightability of software. But there’s a clear difference! The implementation specifies what work actually is done, whereas the API is just a way to interconnect that implementation with the rest of the program, and does not itself do the work. As far as I can see, Google did exactly the right thing that has been done many times in the computer industry: a clean room implementation. Copy the APIs, but not the rest of the code, then write your own code implementations which match that API. Either that long-used practice is allowed (good for competition and interoperability), or it is not (protectionism means preventing customers from shopping around). The CAFC seems to be coming down on the wrong side here, and should instead be focussing on defining that distinction between interface and implementation.
I note that Europe explicitly went the other way at the time of the first trial and decided that APIs are not copyrightable. This seems like the only sane solution. At this point CAFC has steered the argument into nonsensical territory and is busily arguing about fair use, whereas APIs on their own should not be copyrightable (and aren’t in other parts of the world). In a juridiction where APIs hold copyright, fair use must be the end result. The alternative is that every car and tractor manufacturer can design their own specially shaped bolts and creatively designed APIs to lock out competitors and prevent owners and users from shopping around for after-market parts or using independent repairers or doing self-repair. That’s a land-grab from manufacturers attempting to use software as a way to extend monopolies indefinitely. If the law fails to adequately specify the limits of copyright as it applies to machines (and software ultimately is a functional part of a machine, or it has no purpose), then fair use rulings must be the result, to protect competition and the established practice of clean room reimplementations.
Re: APIs are plumbing
You don’t need a Ph.D. for this. You won’t find anyone who passed computer-science courses at any level to disagree with you.
Re: Re: APIs are plumbing
Hmmmm
I did, and I do. “From the point of view of a software engineer, APIs should clearly not hold copyright” Really? Clearly? Oh how I wish I had such clarity and strength of conviction……However, this issue is being looked at through a legal not engineering lens.
Perhaps a review of just what the government has allowed to by “copyrighted” and “patented” and later upheld in court would be good place to start if one actually hopes to gain some perspective on what is going on here.
One thing does quickly become apparent even to a relative layperson like myself. Googles interpretation of “fair use” for its own use is far different that its interpretation of “fair use” when dealing with the end user. Hypocrisy knows no bounds…….
Re: Re: Re: APIs are plumbing
Then I sincerely question whether you actually passed a Computer Science course, let a lone actually took one in the first place.
As has been mentioned in other articles NOT published by TD, this decision has software engineers all over the world (not just employed by Google) concerned because none of them thought APIs were copyrightable and so ALL software that has been developed up until now would be made illegal because ALL software uses APIs of other software without having to worry about licensing agreements.
If that is no longer the case, that means that a lone developer can no longer write an application for Windows, Mac, iOS, Android, Linux, etc… without first paying each of those companies thousands of dollars in licensing fees to “use” their APIs.
Honestly, how do you not understand this?
Re: APIs are plumbing
Re: Re: APIs are plumbing
I was wondering when Mr. I-Hate-Fair-Use was going to show up…
Re: Re: Re: APIs are plumbing
Re: Re: Re:2 APIs are plumbing
Fair use is not copyright infringement. That’s why it’s “fair to use” and not infringement.
If you cannot accept that then the AC’s comment is correct, you are Mr. I-Hate-Fair-Use, because you don’t recognize any use other than forcing people to pay you every time they say supercalifragilisticexpialidocious. Hence, you hate fair use.
Re: Re: Re:3 APIs are plumbing
Re: Re: Re:4 APIs are plumbing
Um, no, that was the original intent behind fair use.
For instance, news reporting should not have to pay a license every time they show a photo, clip, video/audio segment, etc… of any copyrighted work in order to report the news on it.
The people who wrote the fair use clause recognized that in some cases it is absolutely dumb and stupid to charge a license to use or show a copyrighted work and does more harm than good. Especially if it is non-commercial in form such as news reporting, education, commentary or, you know, instructions on how to operate your software.
Re: Re: Re:5 APIs are plumbing
Re: Re: Re:6 APIs are plumbing
Once again you prove that you should never be in charge because education and media would collapse under your terms.
Re: Re: Re:6 APIs are plumbing
No, it’s not.
If fair use were not a thing, it would be.
But because fair use exists, and the described action is fair use, the described action is not copyright infringement.
Something which is fair use is not "permitted infringement", or whatever you want to call that; it is not infringement at all, it is use which does not require permission.
Re: Re: Re:7 APIs are plumbing
One point tp has brought up in the past that the permission culture he demands is important because otherwise, the “original creator” would be inundated by requests for tech support by those who pirated the software.
Except that anyone who actually does would not do anything to “phone home” to the original, hence the concern about cloud connections. And even so, how the hell does that apply here? When was the last time Oracle was contacted for support on anything Android?
Re: Re: Re:8 APIs are plumbing
Re: Re: Re:9 APIs are plumbing
You have no idea what you’re talking about. What does swapping disks have to do with anything being discussed here? Your response doesn’t even make sense in regards to the piracy comment.
If someone pirates a piece of software, they aren’t going to be swapping any disks. In fact, they probably aren’t even going to be sending much, if any, data back to the creator because they don’t want to get caught. If software companies are allowing pirates into their datacenter to swap disks in and out at will, then they have a very different problem.
APIs are strictly software instructions that other software can use to interface with the overarching software. If Java were a computer, then its APIs would be a keyboard, mouse, monitor, speakers, network port, usb ports, etc… What you are saying is that everyone should have to pay a license fee to use any of those interface devices.
Also, English man, learn it.
Re: Re: Re:10 APIs are plumbing
Re: Re: Re:11 APIs are plumbing
If you do not use the Java APIs, then you are not using Java, and that also means that you cannot use any of the available Libraries written in Java.
If all companies used different APIs, and did not allow others to use their APIs, then each companies software would be an isolated island. How a program interfaces with an Operating system is defined by an API, including such things as how data is stored on a disk.
Taking your approach to the extreme would mean a different and isolated computer for each companies software, oh and no Internet, because TCP/IP, HTML, CSS etc. are all just API definitions.
Re: Re: Re:12 APIs are plumbing
Re: Re: Re:13 APIs are plumbing
Why do you want to stop people sharing and selling the things that they create, or cooperating in creating things, as that is what common file formats and APIs allow.
Re: Re: Re:14 APIs are plumbing
Re: Re: Re:15 APIs are plumbing
Nope. The main feature in common file formats is that I can write a word document, send it to Sally, and not have to worry about whether or not we have the same software that can read that file. It’s about being able to reach the largest target audience and it’s a feature that is in EVERYONE’S best interests. If every music artist released their songs in their own unique file format, and people had to pay not only for the song but to buy the software to play it (I’m not talking about one piece of software like iTunes that can play everything, I’m talking about individual pieces of software for every single artist) no one would buy music because they couldn’t afford it and they’d have to keep switching applications all the time just to listen to a different artist. Seriously man, get a clue.
What does this even mean? English man. If everyone outputs to the same file format, it does in a sense become future proof because it guarantees that everyone is using the same formats. That’s literally why the .pdf file format was created, so that there would be one format everyone could output to and be sure that everyone else could read their document not only now, but also in the future.
What? There’s a demand for pirated files, common formats have nothing to do with it. Compatibility makes things popular for legitimate things too, not just pirates. Kind of like how English and Chinese are the business languages of the world? If you know one of those, you can do business anywhere.
Tell that to all of the billions, if not trillions, of songs in MP3 format. It’s sad how easy it is to shred your arguments.
I’m dumbfounded right now. Somehow you think there is some magic number of useful JPG files? Do you understand what a JPG file is? It’s just a container, a format, to store information. You know what’s commonly stored in JPG format? Every single picture you take on your digital camera or smart phone. You’re saying that because there are too many JPG files in existence that people should stop taking pictures of their family, friends, weddings, special events, memorable moments? You’re sick.
JPG has offered the world a great deal, and continues to do so. You’re the one who offers nothing useful.
Re: Re: Re:13 APIs are plumbing
Do you need a license from Oracle to download and install Java on your computer so you can view Java content on the web? Nope. Also, this is not the way it works. Ask any software developer. Hell ask Microsoft or any big name software company OTHER than Oracle, they’ll tell you you have no idea what you’re talking about.
There are no requirements. Java is free to use and program with. Any first year Computer Science student can tell you that because that’s literally one of the first languages you learn to program in. Reason for that? IT’S FREE!!!!
You’re not understanding what he’s saying. What he’s saying is that if all software companies did as you suggest, and didn’t allow other companies to use their APIs, then the only thing you could run on Windows would be Windows and Office. Want to run Adobe software? Oh, you need to buy a computer from Adobe that runs an Adobe OS that only has Adobe software on it. Those 100+ games you have in your Steam library? Yeah, you’re going to need 100+ computers, one for each game, to play them because you can’t run them on Windows because they can’t use Windows APIs, or the APIs don’t exist. It’s laughable how technically illiterate you are.
See my above statement about your technical literacy. These "mistakes", as you call them, are the exact thing that has led to and allowed computer systems and the internet to flourish as it has. It’s a concept known as "interoperability", it means that system interfaces are easily understood, documented, and are able to freely interface with other systems and interfaces.
Unix/Linux is a completely free and open source OS, why would this be a grey area? Who would you even pay license fees to? There’s literally hundreds of different versions out there.
Wrong again, same argument applies here as with interoperability.
Couple of reasons:
Go back to school, take Computing 101, then come back and engage us once you understand what we’re talking about.
Re: Re: Re:11 APIs are plumbing
I said it before and I’ll say it again, you have no freaking clue what you’re talking about. Your entire comment is literally a bunch of nonsense strung together into semi-coherent sentences.
They don’t, each company writes their own API for their own software. They then make those APIs publicly available so that people can actually use their software. Without APIs, their software would be unusable.
This is true of every single other programming language popular today. Oracle is the only one throwing a fit about it.
And when they do that, the software, in this case Java, becomes unusable. Or do you think that anyone who has ever written an application for Windows, Linux, MacOS, etc… has paid for a license to use their respective API’s? I’ll give you a hint, it’s less than 1.
Re: Re: Re:10 APIs are plumbing
Re: Re: Re:11 APIs are plumbing
No, I wasn’t talking about it being hot swappable. Solder or weld the devices to the tower for all I care, my analogy still stands.
What I was saying is that these are interface devices, no different than how an API is an interface part of the software. If you have no API’s, it’s like having a computer tower with nothing plugged into it. It looks great and all, but you can’t actually use it.
Try some critical thinking before you get all upset and completely (or deliberately) misunderstand what I’m talking about.
Re: Re: Re:4 APIs are plumbing
This is literally just false.
Re: APIs are plumbing
“APIs are plumbing”
Yes – and they are very similar to a standard in that interoperability requires them to be.
Standards should not be afforded copyright. Remember Rambus
CAFC = Circuit of Absolute F**king Clowns
What I want to know is how Oracle managed to turn Java from being an open source masterpiece into a such pile of shit that they need to sue someone just because they made something that can act as a replacement. You need to keep the interface the same in order to properly act as a replacement (for anything, software or not), and this lawsuit is completely disingenuous. IMHO, Any dev that works at Oracle should be ashamed of themselves. If you can’t do, sue I guess.
If this stays a win, it's good for security
Looking for the good in this, if this ruling stays developers will be forced to write all of their own code which in turn means no reliance on external sources and lowers attack vectors for hackers (re: Github hacked).
Re: If this stays a win, it's good for security
“means no reliance on external sources and lowers attack vectors for hackers”
lol – wut?
Re: If this stays a win, it's good for security
That’s not how it usually works in practice. Have to write it all yourself usually means more vulnerabilities because less eyes on the code/libraries, fewer reports of errors, and no large movement for fixing deficiencies once caught. The fact that everyone is working together on security of libraries means there are fewer security holes. Having Alice the Jr. Dev implement a one-off version of security with all of the errors a junior dev often does will make things worse, not better… and there aren’t enough good senior engineers to go around.
Re: If this stays a win, it's good for security
What a dystopian world you conjure up, one where you have to reboot your computer into a different operating system to change tasks.
Everything Oracle touches dies
You’ve already covered the legal issue thoroughly, and I’ve already long since weighed in on the folly of this entire case, so I’ll just note that Oracle is now nothing more than a parasite — like what remains of SCO — leeching off people and companies that do real work.
The Internet: This is blasphemy. This is madness!
Court of Appeals: Madness? This is America!
future proof – hahahaha – april fools
There is a much simpler way to explain this to the CAFC. If two dictionaries have some identical words and pronunciations but different definition texts, would one be considered infringing? How about Encyclopedias? At what point does code gain stricter copyright protections than books?