Supreme Court Won't Hear Oracle v. Google Case, Leaving APIs Copyrightable And Innovation At Risk
from the dangerous-ruling dept
This is unfortunate, even if it was somewhat expected: the Supreme Court has now rejected Google's request to hear its appeal over the appeals court decision that overturned a lower court ruling on the copyrightability of APIs. The lower court decision, by Judge William Alsup (who learned to code Java to understand the issues), noted that APIs were not copyrightable, as they were mere methods, which are not subject to copyright.The appeals court ruling, by the Court of Appeals for the Federal Circuit (CAFC) (famous for getting patent cases wrong over and over and over again) didn't just get things wrong, it got things laughably wrong, confusing the difference between APIs and software throughout, and quoting people entirely out of context (including taking things so out of context that it often pitted people on the same side against each other, solely because CAFC misread what they were saying). The case was appealed to the Supreme Court, and we were shocked and dismayed to see the Obama administration further reinforce the errors of the CAFC ruling in telling the Supreme Court not to hear the case. The filing by Solicitor General Donald Verrilli repeatedly confused software with APIs and insisted that there was really no difference between the two. That's just wrong. It's not a matter of debate. It's just wrong.
One would have hoped that with a ton of computer science experts explaining to the Supreme Court how CAFC got things wrong, the Supreme Court might recognize that the Obama administration was confused, but for whatever reason, the Supreme Court has declined to hear the case.
This is dangerous. The world of software and innovation relies on the kind of interoperability and the ability to connect via things like APIs. As we've noted, this is like claiming you can copyright an entire language, rather than the creative works written in those languages. Making APIs proprietary and locked up puts a ton of innovation at risk.
As for Google and Oracle directly, this probably doesn't matter much. They're two giant companies, certainly. And now that the case returns to the lower court, they'll either settle or fight it out over fair use (and hopefully win on that front as well). But saying fair use allows this is very, very different than saying there's no copyright on the API. And for smaller companies this will have a tremendous ripple effect, and will undoubtedly lead to a slower pace of innovation. The kinds of touchstones that people build on will no longer happen. Under this ruling, it basically overrules previous rulings that said pull down menus were not copyrightable. But with this ruling in place, it's hard to see how that's still true. Expect to see a bunch of ridiculous lawsuits over minor copying of functions like that.
While this case may eventually be resolved on fair use grounds (or through settlement), there are still two potential areas of hope. First, the "precedential" power of this ruling is actually somewhat limited. CAFC precedents are more or less meaningless in this context. CAFC handles all patent cases, and the only reason it heard this case was because it started as a patent case, even though those issues were resolved much earlier. So, while CAFC has made this particular ruling, it does not mean that the 9th Circuit, where this case was actually heard has to abide by it. The appeals court for the 9th circuit could rule otherwise (though it is somewhat famous for its own nutty copyright rulings).
Perhaps if this issue returns to another appeals court, and that court gets it right, the issue will return to the Supreme Court with a clear circuit split. And by then, we can hope, the people staffing the Solicitor's General office will finally include at least one person who understands the difference between code and APIs.
The really stunning thing in all of this is just how factually wrong many of the arguments were, and that the CAFC and Obama Administration bought them. These weren't questions of interpretation or opinion. They just flat out got the facts wrong, based on an astounding level of ignorance about a rather basic concept of an API not being software. Just because they both look like "code" does not make them both code. It would be nice if the people actually making these decisions weren't so easily fooled by their own ignorance.
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, donald verrilli, scotus, software, supreme court, william alsup
Companies: google, oracle
Reader Comments
Subscribe: RSS
View by: Time | Thread
CAFC jurisdiction?
[ link to this | view in chronology ]
Re: CAFC jurisdiction?
Now, to your question, here's a resource, via Wikipedia references—
United States Court of Appeals for the Federal Circuit: Court Jurisdiction
[ link to this | view in chronology ]
Re: Re: CAFC jurisdiction?
[ link to this | view in chronology ]
Re: Re: Re: CAFC jurisdiction?
[ link to this | view in chronology ]
What Google did was nefarious. It took Java, decided what to keep and not use, then ditched the rest and rebrand the the programming language as "Android". In other words: It's not Java anymore.
While it's true one can use the Java SDK to write Android apps, not all the libraries and functions are supported in Android.
I think this is where Oracle sat up and said, "What the fuck?"
I highly doubt Apple or Microsoft would allow any company to sell an OS using its APIs either, and it makes perfect sense.
Now, I certainly don't agree APIs should be covered by copyright, and Apple and Microsoft make no qualms about any software developers using their APIs within their OS software, but there's a distinction between Fair Use within the bounds of software and outright copyright infringement of those APIs.
Java is a sandboxed language, and it uses its own virtual compiler. This is why it's the most widely used language on the planet. Because of this, Java has no ties to any OS. Without additional software, Java cannot access APIs on other systems, either. That's the whole point of "sandbox".
Google nefariously sidestepped this approach to claim Fair Use with the development of Android. I don't think Oracle would have a problem if Google used Java (and its APIs), but it sure didn't like the fact Java isn't even mentioned within Android at all.
In fact, head over to Android's official website and you'll see Java isn't mentioned at all. Not only that, it requests a download of the Android SDK, not the Java SDK.
That's pretty damn low, in my opinion, especially from a multi-billion dollar company who wrote its own database language for its search algorithms.
That, I believe, is the issue here, not that APIs should be copyright (and they shouldn't be, within the bounds of the OS the APIs are tied to).
Oracle is just using its legal firepower in the only manner it has with this action, relatively new (the Psystar case is completely different, by the way).
I'm not surprised SCOTUS balked, because this really is an issue to be settled by the two companies.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
You're right that 'Android' is not 'Java' anymore- That's the point. Nothing from Java remains, but you can use it the same way you use Java, even if the entire feature set isn't present.
There's nothing nefarious about that.
[ link to this | view in chronology ]
Re: Re:
Doesn't dismiss the fact Sun Microsystems wrote the APIs (now owned by Oracle) which were specifically designed for the sandbox compiler.
By stripping out the APIs to make another OS is nefarious. I didn't say it was wrong, but damn, does it cross an ethics line.
Google should have written its own APIs, even if they performed identically to the Java APIs.
That's why I'm on the fence with this. I don't think it's wrong, per se, but at the same time, I find it questionable why only the APIs were taken for an entirely different OS.
As a reminder: Google forked Linux for its kernel, but it's still called Linux. Not the same for Java, which is now Android.
I'm guessing if Google had made this Windows based and took what Windows APIs it wanted and called it Android wouldn't have Microsoft calling foul?
The only saving grace about all this is Android is open source. That's why I'm on the fence.
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
WINE implements the DirectX API for use on Linux. It is not called DirectX, because it is only the API that is used, not any executable code.
I don't understand why you think is crosses a line - the default Java threat/use model is vastly different than Android's intended thread/use model, and as such, while they wanted to make it easy for Java programmers to code for Android, the actual Java implementation was not right for them. The bulk of the work, and the work that should be copyrightable, was not used.'
I'd also like to point out that Sun actually applauded and promoted Google's use of Java, and it was Oracle that tried to put the breaks on it.
[ link to this | view in chronology ]
Re: Re: Re: Re:
WINE translates Windows APIs to use in Linux. Microsoft isn't going to raise a fuss here because WINE isn't an OS. It would be no different than someone writing software for Windows to run Linux programs using Linux APIs (though, that would be funny considering most Linux APIs are open source).
@The other AC: No, Java is not open source. At least, not as of today. Rumor has it Oracle is leaning towards making it open source, but time will tell.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re:
Almost.
UNIX is not an API. It is an operating system. The OS presents an API, which Linux, BSD, etc., implement in their own way.
If Google decided to create their own UNIX-like OS, the reason they wouldn't be able to call it UNIX is because that's a trademark owned by AT&T. It's the same reason Linux can't be called UNIX. (I'm ignoring the gray area of the non-all-caps "Unix").
"WINE implements the DirectX API for use on Linux."
WINE implements the Windows API generally, not just DirectX.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
AT&T (formerly Southwestern Bell Corporation) does not own the UNIX® trademark
See UNIX® Trademark Usage:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re:
Google's Java implementation is not licensed under the GPL but rather a more permissive license IIRC.
The FSF is not happy about the liberally licensed non-copylefted Clang/LLVM offering a large amount of GCC compatibility (including its assembler templates) and thus weakening the appeal of the copylefted GCC.
Similarly Oracle is not happy about the liberally licensed non-copylefted version of Java that Google offers. Frankly speaking, Oracle is probably less than happy about offering a GPLed version of Java themselves but that's what they bought themselves into. But they'll be damned to grant anybody more freedom than they are forced to.
The difference between the FSF and Oracle is that the FSF is not interested in fighting for their cause at the cost of confusing courts into creating insane legal precedents that threaten the whole software ecosystem.
The FSF tries fighting with words (which is tricky since their point is a rather subtle one many people don't care about) rather than lawyers.
It looks like a losing battle. In contrast, Oracle's fight looks like a sore loser's battle, and it looks like they get to poison the well for everyone in the process.
[ link to this | view in chronology ]
Re: Re: Re:
Because no api's were 'taken.'
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
Uh, that sentence does not make any sense at all. The whole point of an API is to define what it means "to perform identically". That's why it cannot be copyrightable because copyright protection would then not just cover a particular work but rather any work obeying the description that the API gives.
I cannot claim copyright interest over any dictionary containing all of the terms "Exeter", "Sussex", and "Worcester" in that order just because I wrote such a dictionary myself.
[ link to this | view in chronology ]
Re: Re: Re: Re:
The whole point of an API is to make code shareable between applications rather than developers having to rewrite the wheel every time they create a new program.
APIs are bound by the OS and the software/hardware they're written for. I've been programming for 30 years, so I'm confident what an API is used for. Hell, I've written my own, as well as encapsulated some by Microsoft.
In this world, Microsoft knows it's beneficial to share these APIs. Hell, they don't even charge to use them even if one wants to profit on their own software. It's a mutually exclusive relationship.
However, I absolutely cannot fathom for one second Microsoft wouldn't send the hounds after me if I took all their APIs, wrote my own OS, used those APIs, and competed with Windows.
Call it a hunch.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
the point of an API is to define functionalities that are independent of specific implementations. What you're referring to is much more akin to an SDK than an API, as an API encapsulates no code.
APIs are bound by nothing. They can be used on any OS and on any software/hardware. It is the implementation that is bound to an OS, software, and hardware. Java, Python, c#, c/c++ stdlib, etc, all define an API that can be used on any hardware/software provided that there is a corresponding implementation for that hardware/software. They don't even have to be tied to computers! The best example of this, by the way, is the joke RFC 1149 - IPoAC. It implements the IP API by using carrier pigeons.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
No. That's just one of the reasons. After all, a program can consume its own APIs and export none of them for sharing.
The principal reason for an API is to create a vocabulary and grammar for programs to use as building blocks. Thus, a function called "add(a, b)" introduces a new verb "add" together with a grammar for saying "add so much and so much together". Granting someone exclusive rights to declaring "a + b" as "add(a,b)" is therefore no different than granting exclusive rights to "a + b" itself: it's just two different ways to structure the same operation, using different vocabulary.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
It is NOT an API. An API, as the name states, is an Application Programming Interface, with emphasis on the second word.
What makes this problematic is the API general definition. However, what's important to realize is APIs are NOT transferable between systems.
One cannot use Windows APIs in a Java world, without additional software. In the previous example of using WINE, Windows APIs are translated to work within a Linux environment, but the actual code of the API is not altered.
Again, most companies who wrote the APIs aren't going to stop programmers from using them, but I certainly don't believe anyone believes a company will allow another business to take those APIs, verbatim, and create a new operating system.
I feel far too many people are confusing API with ABI, and ABIs are what cannot be covered by copyright. ABIs are what makes APIs work.
For those unaware, an ABI is an Application Binary Interface, which is the compiler code needed to ensure the API of "Add(x,y)" translates correctly, regardless what API is written to use the procedure."
I'm sure some will argue this is all "one in the same", but it's not. APIs are written code. Thus, under current copyright law, they are covered by that law.
So yes, my 30 years of experience in programming still has me confident APIs are written software.
If there's still confusion, keep this in mind: if you can't write it, it's an ABI. If you can, it's an API.
I don't believe I'm incorrect in this, but I'm also not sticking my fingers in my ears screaming everyone is wrong.
I really do want to know why people believe APIs aren't covered under copyright, and so far, all I've seen is the confusion between API and ABI.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
I mean, come on, Oracle "CLEARLY" stole IBM's SQL implementation and *GASP* APIs to make their SQL language compatible with IBMs and the R language.
Oracle cannot have it both ways.
Either APIs cannot be copyrighted, or Oracle has to close down shop and discontinue business as their primary product is based on clearly stollen APIs and Language structure.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
That's exactly backwards. WINE uses new code to allow programs to use the same Windows API. If it was a different API, my Windows program I'm trying to run in Linux couldn't work, because it was programmed to the Windows API.
For those unaware, an ABI is an Application Binary Interface, which is the compiler code needed to ensure the API of "Add(x,y)" translates correctly, regardless what API is written to use the procedure."
Why do you think that particular type of software is not copyrightable?
APIs are written code.
That's the part where you're disagreeing with everyone.
If there's still confusion, keep this in mind: if you can't write it, it's an ABI.
You just said an ABI is code - what do you mean, you can't write it?
I really do want to know why people believe APIs aren't covered under copyright, and so far, all I've seen is the confusion between API and ABI.
I still think you're the one who's confused. An API specifies a contract. It doesn't do anything. An API must then be implemented in code according to the specification. For example, Oracle's Java SDK is an implementation of the Java API. Google's Dalvik/Android system is another implementation of the Java API. Same API, different code. If you were correct that APIs are software, then that would be two different APIs, because it's two different pieces of software, but (ignoring anywhere Google might have deviated from the API) they both implement the same API.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
Everything you believe to be true about an API is true about a Compiled Library, but is completely false about an API.
And the most important word in API is Interface.
I am not sure how you have been a software engineer for 30 years and still do not understand the difference.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
And yet java is held up as an example of cross platform interoperability and code portability - huh, go figure.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
Oh yeah? It already happened. http://reactos.com/ And Microsoft hasn't sued them.
And neither did they sue https://www.winehq.org/ who basically implemented all the user-space APIs of Windows on Unix.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
There are also F/OSS implementations of parts of .Net and Silverlight.
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
Now, independent implementation of APIs and languages is quite common. Wine implements (a subset of) the Windows API and they call it Wine, not Windows. There is also Mono implementing Microsoft .NET.
[ link to this | view in chronology ]
Re: Re: Re:
Google should have written its own APIs, even if they performed identically to the Java APIs.
Then they are the same. They wrote libraries, by themselves, without copying the inner workings. And in order to be compatible to Java programs, they NEED to provide the same APIs. "perform identically" with regards to APIs means "are exactly the same".
But since they only covered a part of Java, and didn't base it on the Java source, they needed to rename it for trademark reasons.
So there is absolutely nothing "nefarious".
[ link to this | view in chronology ]
Re: Re: Re:
This is actually the crux of the issue. Oracle's license specifies that the Java bytecode that is produced be compatible with the JVM. (I don't know if it was the same under Sun.) Google actually implemented their own VM (Dalvik), and much of its bytecode was incompatible with the JVM - which is unsurprising given the need to run efficiently on mobile devices.
Google should have written its own APIs, even if they performed identically to the Java APIs.
This would be disastrous, especially for open-source projects. For example, it would require that Mono write its own API's. This would defeat the entire purpose of Mono, and force everyone who used the C# API's to use the Windows CLR (and possibly pay royalties to do so). Likewise, Unix could copyright what is now the POSIX standard (it's an API, after all), which would make other implementations of this standard be unlawful without a license.
By stripping out the APIs to make another OS is nefarious. I didn't say it was wrong, but damn, does it cross an ethics line.
I don't see why. For example, Linux could feel free to not implement some of the POSIX system calls, and I don't think there would be anything nefarious about it.
Also, the parts of the API that Google stripped out are the parts that were not relevant to a mobile language (like the Swing API).
As a reminder: Google forked Linux for its kernel, but it's still called Linux. Not the same for Java, which is now Android.
First: Java is a programming language, not an operating system. Android is an operating system, but applications for it are written in the Java programming language, using the Android API's to communicate with the OS. (Or not, if you use something like PhoneGap.)
Second: the OS is called Android, just as Ubuntu is called Ubuntu. The kernel may be a fork of Linux, but the kernel is not the entirety of the OS - at least, not how you define it. (The technical definition is that the kernel is the OS, and toolkits or software packages are not part of it. For example, the Bash shell is not part of the Linux OS.)
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Java, Android, API
[ link to this | view in chronology ]
Re: Re: Re: Java, Android, API
Why did you choose the word "cribbed"? They didn't copy anything from Java. They wrote their own virtual machine that implements the Java API.
Subverting control of future forks of a copied interface and behavior causes real problems: Java and Android will surely diverge and that will cause problems.
Depends what you mean by diverge - Android already adds lots of stuff that isn't in the Java SDK, and that's no problem. If you mean the Android SDK will start changing the semantics of things that are already defined in the Java API, I'm not at all certain they're going to do that.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Are you stupid or just dumb?
It's obvious in the EU, where APIs and languages themselves cannot by copyrighted.
http://www.zdnet.com/article/e-u-court-rules-programming-languages-not-copyrightable/
It was obvious to the judge who initially ruled for Google, that had actually programmed.
http://www.groklaw.net/article.php?story=20120531173633275
Perhaps if Obama or the SCOTUS members had actually pulled their heads out of their asses and their hands out of Oracle's checkbook, they'd actually understand the "WHY" of APIs not being copyrightable.
Without APIs being clearly available and free to use, nobody would have jumped on anybody's bandwagon / programming languages, and every vendor would have developed their own, proprietary languages, apis, etc...
We never would have had the IBM compatible PC, and we'd still be using Lotus 123 since Microsoft would not have been able to COPY Lotus's APIs to make Excel.
We'd be living in a world where innovation was slowed to such a crawl, that the 386 might be something just released as the newest, fastest, bestest thing, with 1 or 2 programs that it could run, everything else being locked down by copryight.
Having languages and APIs under control of copyrights would be the end of our ability to build new and innovative projects by standing on the shoulders of our predecessors.
So, to answer the question in my subject - Are you stupd or just Dumb?
Either way, you're clueless about the case and why SCOTUS got it wrong, way wrong.
[ link to this | view in chronology ]
Re:
What Google did was take Apache Harmony, an independently developed, open source Java implementation, which Sun knew about and had no problem with.
Most of the contribution and effort in Apache Harmony came from IBM.
Apache Harmony does not have any Oracle code in it.
Furthermore, Oracle's Java, at the time is under the GPL license. So how can the API's not be under the same license, since the APIs are in the source code.
In a nutshell: Google has money. Oracle wants it.
Before Oracle bought Sun, Sun knew about Android and had made public statements about not having a problem with it.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: You are contradicting yourself...
The statement "I don't agree that API's should be covered by copyright", and the statement "there's a distinction between Fair Use within the bounds of software and outright copyright infringement of those APIs" are fundamentally incompatible. If API's shouldn't be covered by copyright, then there can't be infringement, and fair use isn't a consideration. If they aren't covered by copyright, anyone can use them, at any time, for any reason.
[ link to this | view in chronology ]
Re: "Nefarious" == "Computer Science"
That's the way every every single programming language ever invented, was invented. And, surely, if something isn't "Java", the scrupulously honest thing to do would be to not call it "Java"?
I can't imagine anyone not understanding this. I don't even believe Microsoft doesn't understand this. (My suspicious is that when they "took Java, decided what to keep and not use, then ditched the rest", they were just too stupid to know it wasn't Java. And when the fact was pointed out to them, in the only way a fact can be pointed out to a company run by law-school dropouts, they did the honest thing and started calling their language "C#".)
On the other hand, I suppose there's someone somewhere stupid enough to accuse Microsoft of nefarity because the took the name "C++", omitted which characters to keep and added other characters to come up with a name that -- face it -- isn't "C++".
Now, what would be nefarious
[ link to this | view in chronology ]
Bought?
This is incorrect. The Obama Administration hasn't "bought" these arguments; they're one of the groups who are selling them. The Obama Administration's copyright maximalism has been paid for by campaign contributions and deals in smoke-filled rooms.
[ link to this | view in chronology ]
Re: Bought?
[ link to this | view in chronology ]
Re: Re: Bought?
[ link to this | view in chronology ]
Re: Re: Bought?
Is that why they were arguing for Oracle?
[ link to this | view in chronology ]
Re: Re: Bought?
This is pretty obviously bullshit. If the Obama administration is "littered with ex-Google types," it's only because Google is a big company that has hired lots of smart people, and the administration wants smart people.
But that "if" is wrong. The "ex-Google types" that are in the administration are far, far outweighed by the "types" that were previously lobbyists for big media companies.
And the whole "dodging a US anti-trust lawsuit" thing is stupid and ridiculous propaganda. Techdirt covered it here.
[ 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: Re: Re:
[ link to this | view in chronology ]
Re: Re:
Oracle might not be going after java programmers TODAY, but if an API is found to be copyrightable I suspect tomorrow will be much different.
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re:
Unlike Microsoft which licensed Java from Sun, created an incompatible version, called it Java and got sued.
You can't copyright a language, although you can trademark a language name.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Re:
Apparently there are over a billion Android users, and there were over a billion Android devices shipped just in Q4 2014. Not really a little guy by any standards.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
What is Oracle asking for in this suit other than money?
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
To further the language analogy
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 ]
Re: To further the language analogy
There are many ways to implement a function that will provide the same semantics. Each one different in some way, except maybe in the simplest of cases.
API's are a specification for use, it tells you the name you use to call, the kinds of parameters you need to supply with the call and what is expected back. However, it tells you nothing about how it is implemented. There should be some description of the semantics associated with the specification of the API as a part of the specification.
The implementation should conform to the semantics applicable to the API. The implementation should not be the "semantic definition" of the API.
Subtle that this point is, there is a significant difference between conformance and defining the semantics associated with an API.
Too often, however, the designers of an API or an implementation of an API base the semantic definition on their standard implementation and not on some other more appropriate methodology. This usually means that errors in the semantic definition caused by the implementation will flow into other areas.
[ link to this | view in chronology ]
This is what happens...
[ link to this | view in chronology ]
Re: This is what happens...
[ link to this | view in chronology ]
Designing and specifying the API was creative work. Google as usual just trying to steal value.
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: Designing and specifying the API was creative work. Google as usual just trying to steal value.
Yes, even oracle
[ link to this | view in chronology ]
Re: Designing and specifying the API was creative work. Google as usual just trying to steal value.
You're thinking of Googol or 10^100.
Google is the search engine.
Notice the difference in spelling.
[ link to this | view in chronology ]
Re: Re: Designing and specifying the API was creative work. Google as usual just trying to steal value.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Topic()
{
introduction
establish basic premise
establish three primary discussion points
define topic sentence
paragraph one
describe supporting point one
describe any opposing viewpoints
rebut opposing viewpoints
paragraph two
describe supporting point two
describe any opposing viewpoints
rebut opposing viewpoints
paragraph three
describe supporting point three
describe any opposing viewpoints
rebut opposing viewpoints
conclusion
restate thesis and how supporting points prove main argument
wrap up argument and counter-arguments
conclusion sentence
}
Anyone using this format on a computer now owes me royalties for its use. If you need me I'll be on a college tour...high schools are for next year. Be back later with yacht.
[ link to this | view in chronology ]
This case has taught me
Also, it's apparently a very difficult concept to explain to people.
I'm not sure what to do about this.
[ link to this | view in chronology ]
Re: This case has taught me
[ link to this | view in chronology ]
Re: Re: This case has taught me
[ link to this | view in chronology ]
Re: Re: This case has taught me
That's not quite what an API is. An API says something like: "if you have an instance of a class called Stack, and invoke a method called pop() on it, it will remove and return an object (of a specific type) that is semantically on the top of the stack."
A non-Java example of an API is the C++ STL (Standard Template Library). You can find the entire API for the STL here:
http://www.cplusplus.com/reference/
If you follow that link, you may say to yourself, "hey, I can't download any code from this site!"
Indeed, you can't - because and API is not actually code (and certainly not executable code). It is simply a specification.
[ link to this | view in chronology ]
Re: This case has taught me
Or maybe I don't understand it, and if my understanding is flawed, please let me know. But to use a code example, this is something you'd see in a (really crappy) SDK:
addtwoints(int x, int y)
{
// Add x and y to return an integer
int z;
z = x + y;
return z;
}
And this is the API for the same function:
addtwoints(int x, int y)
{
// Add x and y to return an integer
}
Sure, they both look like code. But anyone with even a shred of programming knowledge knows that second one doesn't actually do anything. They are also probably offended at my horrid example and are confused as to what crazy combination of syntax I'm using (it's been a while since I've touched anything based on the C language, sorry).
Again, please correct me if I'm wrong, but I'm pretty sure that's what an API is.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
CAFC and Obama Administration
Link: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja& uact=8&sqi=2&ved=0CB4QFjAA&url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDunning%25E2%2580 %2593Kruger_effect&ei=yP6RVf3MOMjusAXkgYz4CA&usg=AFQjCNHdFxS5Ah_HTg_qxfHGGMUYQzRviA&bvm= bv.96783405,d.b2w
[ link to this | view in chronology ]
The only thing Google did was write their own bytecode interpreter (Dalvik) to be interoperable with standard Java API calls. So that Java software developers didn't have to rewrite the API calls in their software in order to be compatible with Dalvik.
Note: Google didn't copy/paste any libraries or source code from Java's bytecode interpreter. Google wrote their own bytecode interpreter (Dalvik) from scratch.
That's called working smarter not harder and reducing time and money for developers who've already wrote their software using the standardized API calls in Java.
It appears to me that Java's not pissed because Google standardizing the Java API. They're pissed because Google wrote their own bytecode interpreter from scratch that cuts Java's bytecode interpreter out of the loop.
[ link to this | view in chronology ]
Abolish Copyright
[ link to this | view in chronology ]
What if I implement an interface?
[ link to this | view in chronology ]
Broken
[ link to this | view in chronology ]
[ link to this | view in chronology ]