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.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: api, apis, cafc, copyright, fair use, interfaces, interoperability, programming
Companies: google, oracle
Reader Comments
Subscribe: RSS
View by: Time | Thread
Easy way to solve this...
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.
[ link to this | view in chronology ]
Re: Easy way to solve this...
[ link to this | view in chronology ]
Re: Re: Easy way to solve this...
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?
[ link to this | view in chronology ]
Re: Re: Easy way to solve this...
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.
[ link to this | view in chronology ]
Re: EASIEST way to solve this was to pay a TINY fee.
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.
[ link to this | view in chronology ]
Re: Re: EASIEST way to solve this was to pay a TINY fee.
[ link to this | view in chronology ]
Re: Re: EASIEST way to solve this was to pay a TINY fee.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Response to: Anonymous Coward on Mar 27th, 2018 @ 11:23am
You can bet the definition of an API has been twisted by the attorneys to help their argument. They need not agree.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re:
Oracle!
[ link to this | view in chronology ]
Re: Re:
"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."
[ link to this | view in chronology ]
Re:
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.
[ link to this | view in chronology ]
Re: Re:
But, yes - I agree. I suppose the term "dead" is inappropriate in these cases, I propose using the term "buggy whip language".
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
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.
[ link to this | view in chronology ]
then I will move on to copyrighting buttons.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
No, he just has to get his claim heard by the CAFC, and bingo total control.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re:
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."
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Better example
This is actually like an auto making suing another auto maker and winning because both vehicles adhered to federal automotive standards.
[ link to this | view in chronology ]
Re:
At least, the Federal Circuit wouldn't stop it.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
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.)
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Important questions:
How many anti-google Legislators pressured the CAFC to rule against google?
[ link to this | view in chronology ]
Re: Important questions:
[ link to this | view in chronology ]
Good Riddance Oracle
[ link to this | view in chronology ]
Re: Good Riddance Oracle
[ link to this | view in chronology ]
Re: Re: Good Riddance Oracle
Make of that what you will.
[ link to this | view in chronology ]
Re: Re: Good Riddance Oracle
[ link to this | view in chronology ]
Re: Re: Re: Good Riddance Oracle
Oracle is handing JAVA EE over to the eclipse foundation, where it become Jakarta.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re: REPEAT of 2015: Designing and specifying API was creative work.
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.
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re: Re: REPEAT of 2015: Designing and specifying API was creative work.
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.
[ link to this | view in chronology ]
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).
[ link to this | view in chronology ]
In fact, API design and spec is some of the KEY creative
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!
[ link to this | view in chronology ]
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.
[ link to this | view in chronology ]
Re: In fact, API design and spec is some of the KEY creative
[ link to this | view in chronology ]
Commin law says an API is fair use.
[ link to this | view in chronology ]
Re: In fact, API design and spec is some of the KEY creative
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.
[ link to this | view in chronology ]
Re: In fact, API design and spec is some of the KEY creative
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.
[ link to this | view in chronology ]
Re: Re: In fact, API design and spec is some of the KEY creative
[ link to this | view in chronology ]
And what set of rules determine how the Java APIs work?
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
[ link to this | view in chronology ]
"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.
[ link to this | view in chronology ]
Re: "Find them GUILTY already dammit!"
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
APIs are plumbing
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.
[ link to this | view in chronology ]
Re: APIs are plumbing
[ link to this | view in chronology ]
Re: Re: APIs are plumbing
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.......
[ link to this | view in chronology ]
Re: Re: Re: APIs are plumbing
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?
[ link to this | view in chronology ]
Re: APIs are plumbing
> 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.
There's a nice story related to this problem. When developing some software, and trying enforce rules for other programmers to follow, all of them didn't like the new rules and tried to change the rules. Their request came as "can we start using STL library in this project?", when the original rule was that its use was not allowed. STL has some important functionality, so it seemed reasonable that limited/most stable parts of STL's behaviour would be allowed in the project. This "limited amount" wasn't what actually happened. When you give a permission to do even a small exception to rules that they don't like, they would go all-in with STL and try to make it impossible to ever remove STL usage from the project. They did this to prevent fixing the mess that they caused.
This is valid claim that providing any leeway in relaxing the rules would make some people go all-in and try to expand the scope of the "relaxed rule". It's neverending story, they always go to the most amount of freedom, without ever thinking why the rules have been in place. Strictest possible reading NEEDS TO BE USED, or else there will be whole communities going ALL-IN with any relaxed rules.
The real problem is that these people DO NOT WANT TO FOLLOW ANY RULES WHATSÒEVER. They only follow the rules because they must, and they're always looking for loopholes in the rules and ways to AVOID FOLLOWING THE RULES.
This is completely wrong approach. This is the reason why there must always be strictest possible reading of any rules that you actually want to enforce.
[ link to this | view in chronology ]
Re: Re: APIs are plumbing
[ link to this | view in chronology ]
Re: Re: Re: APIs are plumbing
You'd first need to admit copyright infringement, and then maybe fair use will be useful for you. Why would you admit that?
[ link to this | view in chronology ]
Re: Re: Re: Re: APIs are plumbing
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: APIs are plumbing
Yeah, but the original purpose of "fair use" was something completely different than what you try to use it for. Fair use is not a permission to copy/distribute/perform copyrighted works without taking a license from the copyright owner. It's more like "copyright infringement" + some odd bullshit reasoning of why the infringement should be allowed.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: APIs are plumbing
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
well, but when they do this -- it's technically copyright infringement since they copy the content verbatim. Some of the scandals couldn't be reported at all, if copyright owners could prevent their publication by rejecting their request for permissions. But reporters are always taking a risk, if they need to go to that area in their reporting. Basically their proof of it being fair use must succeed or they're liable of copyright infringement. The real issue is the "copy verbatim" -part. When that is required, permissions usually are needed.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: 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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
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?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
Yeah, but for widest possible market impact, you need to think what happens when you have 2 million of these idiots swapping disks. Your hotline for tech support will gets calls 2am in the morning since the 2nd breakfast when this happens in USA happens to be exactly 2am in your local time.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
Why does one company need to use the same API than some another company? There isn't any reason for that. Especially in java/android case where the software need to anyway be rewritten to work on android. The cloned API definitions do not even make sense whatsoever. The only reason is that the oracle's java market has tons of young programmers who already know the interface, and thus supposedly don't need to learn new practises.
> What you are saying is that everyone should have to pay a license fee to use any of those interface devices.
No. They don't need to pay. They can always stop using the API definitions.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
But if you're using java, java API's and libraries written in java, then you need a license from oracle. They just refused to take it (probably because oracle's license's compabilty requirements are too strict and google didn't have time to implement those requirements).
> then each companies software would be an isolated island.
Android definitely needs to be an island separate from oracle's java. If they want to join the java island, they would take the license and implement the stict compability requirements associated with the license.
> Taking your approach to the extreme would mean
I consider that there are significant mistakes done in computing, for example linux has "wine" which supposedly allows running windows applications in linux - it needed to replicate windows apis to get binary compability. Or usage of unix api's in linux is clearly in grey area. Using standardized file formats like .jpg, .png, .mp3, .avi are another big mistake.
Why does everyone think they should get "access" to large libraries of content that they don't own?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
Nope. Main feature in common file formats is that "your code becomes compatible with _existing_ large library of copyrighted works".
The secondary concern is that "_existing_ application programs output those formats" and thus it becomes "futureproof".
3rd idea is that "There's large demand for pirated .jpg / .png files, so compability would make the software popular (among pirates)"
Note that it has nothing to do with "allowing people to share the works they create in the future", since number of those works in that category is significantly smaller than what the first 3 categories are doing.
Basically there's already enough .jpg files in the world, and we've already seen what exactly jpg has to offer to the world. Creating new jpg files isn't useful activity - and has not been in long time.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 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:
We're not actually stealing content, just interfacing with it.
Go back to school, take Computing 101, then come back and engage us once you understand what we're talking about.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: 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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
This is biggest bullshit reasoning I've seen in a long time. So you think that hot-swapping some other vendor's keyboard needs to be possible in this situation? Unfortunately this hotswapping has never worked in android or java. So the whole argument is bullshit.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: APIs are plumbing
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.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: APIs are plumbing
[ link to this | view in chronology ]
Re: 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
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]
If this stays a win, it's good for security
[ link to this | view in chronology ]
Re: If this stays a win, it's good for security
lol - wut?
[ link to this | view in chronology ]
Re: If this stays a win, it's good for security
[ link to this | view in chronology ]
Re: If this stays a win, it's good for security
[ link to this | view in chronology ]
Everything Oracle touches dies
[ link to this | view in chronology ]
Court of Appeals: Madness? This is America!
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]