Google petitioned the Supreme Court to hear its case, joined by allies including Yahoo, HP, Red Hat, and open source advocates, but was rebuffed. Microsoft, EMC, and NetApp urged the high court to let the Federal Circuit ruling stand, and that's what happened.
WHY?? And here I thought Microsoft was coming around. Fuck these assholes (and EMC and NetApp too). What do these people have to gain by letting the ruling stand? It just makes interop harder. And here they are tapping into the Linux API shamelessly[1]. Shame on you fuckers.
I haven't found their brief to the Supreme Court, but if they raise the same arguments that the raised in their earlier amicus brief to CAFC [1] where they urged CAFC to take the appeal from the district court, their objection is not to the outcome of the case (Google not infringing) but rather to how the district court got there.
Briefly, they believe that the district court went too far in declaring that APIs are not subject to copyright in general. Instead, they believe that APIs are subject to copyright under existing statutes and precedent, but that there are various doctrines (fair use, merger, and others) that can allow copying for interoperability.
- Microsoft benefits when Google's mobile platform is hurt.
- Microsoft has many APIs so why the heck would they want to overturn a decision that puts them in a position of power?
If those weren't enough, Google has poached Microsoft talent for years. Maybe there are people at Microsoft who just don't like Google and will work to screw them over. Most likely though it's more to do with the two reasons I listed above.
Plus, a little too much emotion in your post. Hard to believe you can feel any emotion about this whatsoever let along being basically pissed off. This is super boring tech news.
This whole thing is unbelievable to me. We have Oracle spending who knows how much money suing Google and claiming that APIs are copyrightable. At the same time they, along with virtually every software company ever, rely on documented, standardized, ubiquitous protocols like IP, TCP/IP, and HTTP to create software that does anything useful. Even the most basic notepad or calculator application relies on APIs to function. I cannot imagine a world that forces us to treat every use of an API as a must-be-legally-contracted integration. Even the most trivial applications would never get completed because the cost just to agree to all these contracts would exceed any ability to generate profit from the resulting software.
If Oracle wins then in a way this might actually be good for open source; software developers would seek out the path of least resistance: APIs that could be licensed freely. This could simply extend the push of open source code further to APIs.
There's a strong fair use defense for interoperability (Sony v Connectix). In the hypothetical situation that someone claimed copyright on TCP/IP, presumably that would be a strong enough defense.
Google is in difficulty here because they didn't use Java for purposes of interoperability; their version isn't even compatible. If they had, Oracle would have no case.
The appeals court left open the question of whether Java being easier for developers because they already know Java counts as a fair use defense.
It might count, and then Google is free.
If Oracle wins then in a way this might actually be good for open source; software developers would seek out the path of least resistance: APIs that could be licensed freely.
That is why the FSF supported Oracle before the supreme court.
It's quite a stretch to say that the FSF supported Oracle before the Supreme
Court. Also you seem to think that the FSF supports API copyrightability as a
means of making free software more attractive to developers. This is not at
all their position. Here is what they said at the time of the Jury verdict in
the first trial[1]:
Were it grounded in reality, Oracle's claim that copyright law gives them
proprietary control over any software that uses a particular functional API
would be terrible for free software and programmers everywhere. It is an
unethical and greedy interpretation created with the express purpose of
subjugating as many computer users as possible, and is particularly bad in
this context because it comes at a time when the sun has barely set on the
free software community's celebration of Java as a language newly suitable for
use in the free world. Fortunately, the claim is not yet reality, and we hope
Judge Alsup will keep it that way.
As for their brief against Google's petition to the Supreme Court[2]:
SFLC and FSF take the position that the decision below is wrong, but that
certiorari should not be granted for three reasons: (1) the decision of the
Federal Circuit merely mispredicts what the Ninth Circuit would do if it had
been the Court resolving Oracle's appeal from the District Court's finding
that the application program interface declarations at issue are
non-copyrightable; (2) the decision rests on narrow factual grounds; and (3)
there is no public interest in continuing to adjudicate this dispute because
Google can now and could have used all material at issue under the terms of
the GNU GPL v2.
What to make of this? It's a bit convoluted. On the general issue of
proprietary APIs, the FSF supports Google's position. But they think the
judgement against Google from the Federal Circuit court carries virtually no
value as precedent, as they say in
their brief[3]:
Despite the manifestly erroneous character of the decision below, the petition
for writ of certiorari should not be granted. The precedential weight of a
decision so evidently mispredicting the law of another Circuit is essentially
nil.
Now independently of the Oracle v. Google dispute, they would prefer if Google
were using the GPL license for Android. Wouldn't it be nice if the bad Federal
Circuit judgment could incentivize Google to use the GPL, without affecting
other cases? I think that is the tactical advantage the FSF saw in opposing
Google's petition to the Supreme Court. And it might have been a good call, as
Google is indeed switching to the GPL Java implementation[4].
It's ironic that one of Oracle's core products (https://www.oracle.com/linux/operating-system/index.html) was created by the very practice that they are trying to outlaw, as an independent implementation of proprietary software (belonging to AT&T).
Oracle's core product is Oracle database. That is a product based on SQL, an API language invented by IBM's Codd, Boyce, and Chamberlin in 1970-1974.
Oracle developed Oracle database before IBM offered standardized free royalty-free licensing, so Oracle's core product, according to Oracle's legal theory, belongs to IBM.
It was a grave blunder for Google not to buy Sun. Besides Java, they would have gotten MySQL, ZFS and some hardware that would all be useful at Google.
Imagine Google the cloud operator having to tread carefully not to get into political infighting with Google the SPARC manufacturer. Google had very good reasons to stay clear of those recipes for disaster.
They could have still done a "Motorola" with Sun, but that's hindsight speaking.
1) they will win a lot of money in the near term but it will greatly diminish the popularity of Java/JVM in the long run because most tech companies shudder at the thought of having Oracle be the slumlord of their core program language.
2) there will be a painful transition of FUD and lawsuits but open source languages/libraries will be ultimately become stronger in industry b/c the licenses can easily be extended to API rights. Restrictively or vaguely licensed code will be looked up on with greater suspicion.
If Oracle wins this piece of brain damage then you will see every legal troll in existence coming out of the woodwork to claim ownership of APIs and how others are using them.
Only if you violate Java's GPL license. Google took a GPL code and licensed it under a different license - that's why they are sued.
So, even if Google looses, that basically strengthens the open source case AND Java, meaning that you can not hijack Java (GPL) and make its offshot non-free (in a copyleft sense).
Google took a GPL code and licensed it under a different license - that's why they are sued.
The only code that was alleged to be copied were a few test files (which weren't even distributed) and a 9-line function called "rangeCheck".
There was a second copyright claim on the APIs, but Oracle didn't claim the code was copied, just that the reimplementation had the same "structure, sequence and organization" (that is, same names and arguments).
What might this mean for open source platforms that target non-standard Java back-ends? Take scalajs[1] for example. It reimplements Java API's but not for the direct purpose of interoperability with standard Java. I believe this will be the case for Scala native as well.
In both those cases, it allows code to be written that targets both, so I would think interoperability would be a strong argument. But is that not the case for Android as well?
In this case the reimplementation is in Scala, but it could be argued that the "structure, sequence and organisation" definition of copying could apply.
If there is any chance this could be ruled as infringing copyright, then Oracle would have a powerful platform lock-in, and every line of code targeting their API's would contribute further to that.
This would pretty much projects like Wine or GNUStep would be illegal. For those who don't remember the days of the Microsoft Empire, this is a pretty big thing.
Once AWS becomes a monopoly (which should happen anytime in the 5 to 6 yrs), the only way to challenge the gorilla would be to build an API compatible competitor.
No. There's a fair use defense for interoperability. Wine is clearly built for interoperability purposes, so they are ok.
Google's primary difficulty in this case is convincing the jury that they have a fair use defense, when their version of Java is technically incompatible.
Who suggested it is neither here nor there. You don't use an API for anything other than compatibility and code reuse for developers. It's easily demonstrable. If it isn't the develop tools market has disappeared.
What is the fair use ? To topple a monopoly? Or interoperability on Linux - which is a not-intended-for usecase.
Becaiy Google can pull the same defense - interoperability on Android. If Google loses, then it's going to be hard to get something like this off the ground again. In fact, every "porting" project is in danger.
Your comment isn't coherent, but I think you're asking, "What fair-use defense is Google asserting?"
One approach is for Google to say, "Developers expect a reasonable platform that they are familiar with. To give them that, we had to use Java (or C# or similar)."
In other words, it is an interoperability defense, but for compatibility with developers, not devices or software.
IMHO such an argument from Google seems weak. Developers were more than happy to learn a new technology when the iPhone and Cocoa/ObjectiveC came along. And now these same developers all seem really keen on moving to Swift, a whole new programming language, because it offers compelling improvements.
Well there are more than some iPhone apps, there are many high quality apps. So those unwilling to learn a new language weren't needed after all. Learning the Android API will also be just as hard, probably harder, as learning another curly brace dialect. I wouldn't be surprised if Google replaces Java with Dart at some point anyway.
you're finding it incoherent, because your reasoning (though interesting) is fundamentally untrue.
The only reason Google went with creating its own implementation was that ARM, Samsung, etc would not have worked with the licensing of Sun Java. This is fairly well documented and actually came out during document discovery. Today Android has so much market dominance that it can basically whip everyone into submission.
What I'm essentially saying is that at this point, it has already become much harder for something like a Wine for OSX to be created. Because developers will have to prove "fair use" in court... which is a huge huge intimidation stick.
If Google and Android are finding it hard to prove fair-use defense - how easy it going to be for the rest of us.
Thought experiment - what would be Wine's fair-use defense ?
> Thought experiment - what would be Wine's fair-use defense ?
Huh? Wine exists solely for interoperability, the defense is "I have this lawfully obtained program and I want to run it on my OS". Which doesn't and can't apply to Android, because Android won't even run standard Java programs.
Which doesn't and can't apply to Android, because Android won't even run standard Java programs.
I keep seeing this as Oracle's defence, but it is neither here nor there. There are countless APIs in the world used where the result is not compatible with anything else that uses that API, or a subset of it, or whatever. The C world is full of incompatible compilers and those that use various subsets.
Oracle desperately wants to try and box this up into nice, neat exceptions and use cases and anyone with a single ounce of technical knowledge knows this is pure nonsense.
I keep seeing this as Oracle's defence, but it is neither here nor there.
It doesn't make sense to you because you misunderstood the case, and the legal argument. Oracle doesn't need to make a defense, it's already been ruled that Google is infringing.
Now Google has a chance to offer a fair-use defense, and a reasonable fair-use defense is to say, "Google infringed for purposes of interoperability." If they could demonstrate that, then they would win the case.
So when people say Android won't even run standard Java programs, they are giving evidence that Google's interoperability defense will not work in court.
It doesn't make sense to you because you misunderstood the case, and the legal argument.
Nope, it's Oracle's lawyers making technology judgements they are out of their depth to make.
Oracle doesn't need to make a defense, it's already been ruled that Google is infringing.
....and it will be shown to be nonsense and overturned, as it has been decades ago. You can't copyright or be defensive with APIs. If this is true there is no software industry, despite your desperate protestations that this is all about Google and Oracle and everyone else is fine.
"Google infringed for purposes of interoperability."
Ha, ha, ha. The problem is if this is true then the 'infringement' doesn't actually mean anything. It is up to Oracle to define why this infringes fair use, not the other way on I'm afraid. Why you use an API is very, very clear.
So when people say Android won't even run standard Java programs, they are giving evidence that Google's interoperability defense will not work in court.
Again, you keep repeating this crap. There are countless developer tools and compilers out there that implement subsets of APIs and build on them for code reuse and interoperability. What you compile won't necessarily be transferable between implementations. Your desperate wish for this not to be so will not make it so I'm afraid.
so why cant a defense "Oracle Java sucked on ARM... we built something better to help developers" work ? Does this mean that you can port.. but not improve ?
> so why cant a defense "Oracle Java sucked on ARM... we built something better to help developers" work ? Does this mean that you can port.. but not improve ?
There is a specific defense for interoperability. So yes, you might be able to use someone else's design for something like a hose connector or an electrical plug but not improve on it - if you're using their design to interoperate with their stuff. IANAL.
So yes, you might be able to use someone else's design for something like a hose connector or an electrical plug but not improve on it - if you're using their design to interoperate with their stuff.
Again, total nonsense. There are countless implementations of various development software out in the world right now that renders that load of extremely wishful thinking null and void.
Like I've said elsewhere, lawyers might think they can package these cases up into nice, neat boxes but they can't.
Nah, it's rather that you think they need to package them in neat boxes, but that's not how law works. Edge cases don't prevent rough rules from being made.
What I'm essentially saying is that at this point, it has already become much harder for something like a Wine for OSX to be created. Because developers will have to prove "fair use" in court
You're wrong, that hasn't change at all as a result of Google vs Oracle.
Thought experiment - what would be Wine's fair-use defense ?
Interoperability, see for example Sony v. Connectix
No, there is no exception here. Oracle is extremely desperate to create some distinction between its disagreement with Google and 'fair use' for everything i.e. those who it isn't suing.....yet.
There is absolutely no difference between what Google is doing and what happens in the software industry every other day of the week. Using an API for interoperability and to reuse code developers have written backed by their own implementation. The thing is so laughable because the only reason you use an API...is to interoperate.
Oracle knew fine well what can of worms it was opening here when it came up with the notion that everything else would be fine with 'fair use', but the definition of 'fair use' has to be defined - and thus far it hasn't. It exists only in the minds of Oracle's lawyers who know zip about software. Every legal troll in existence will crawl out of the woodwork on this one. No, Sony vs Connectix tells us nothing here, which shows just how clueless you are.
This was all done and dusted in the 90s with DR DOS amongst other things.
Let's hope that if this goes badly, the rest of the world retains some sense of sanity and doesn't allow intellectual property laws to be used to restrict essential principles like interoperability.
Maybe I'm thinking about this incorrectly but Google's use of the Java APIs seem to me to be the quintessential case of fair-use for interoperability. It's not like Android is shipped with a JDK and is constantly exercising the Java API internally on Android; they are only used so that I can write a Java algorithm on my desktop and use the source code to generate Dalvik bytecode that does something roughly similar to what the Java bytecode would do. The Java APIs are just a means to an end. The surface area of the copyright infringement is limited to the desktop Android build tools which convert Java sourcecode and some bytecode into Dalvik, i.e., interoperability. Now, that is only one-way interoperability so maybe that is enough to sway the matter away from fair-use.
So what would actually happen for reals in a copyrighted API universe? If someone wants people to interact with their API (such as a website) they will obviously license their API in such a way. And if they don't they won't.
So, what terrible things would happen? Most programmers agree it'd be terrible. I trust the masses. But for discussion's sake could someone provide a concrete example or two?
Somewhat related, I believe ARM's instruction set is protected. Probably by patents? I've always felt that source code should NOT be patentable but SHOULD (and is) be copyrighted. Where an API falls and how to draw that line I'm not sure.
You lost me at "…API (such as a website)"…. How is a website an API? UI I can see, but API? What do you mean by that?
In the case of UI, there's a good chance that, to the extent that the piece that is copied constitutes a method of operation, that piece is not copyrightable. For example, in Lotus v. Borland [1], the court ruled that the organization of menus and keyboard macro commands for the sake of compatibility was not copyrightable. However, certain more "artistic" things like icons and such are copyrightable.
GP is asking for examples of when copyrighting an API would be a problem. They used web APIs because that's apparently what they are most easily able to call to mind.
I've found many programmers think of APIs as ways of interacting with remote systems, usually via http/json/REST. Personally, I think of an API as things like an argument signature in a library, or even hooks in an OS.
To me, API literally means a programmatic interface to some code. How you write code to interact with other code.
[Not that you said anything differently, I was just trying to expand a little on the different perspectives of 'API' I have encountered.]
Ah, thanks. I really don't know anything about Web APIs. I'd heard the terms "Web API" and "REST", etc. before, but didn't realize it was just a site that you sent special HTTP requests to. Thought there might be something more involved than that? Like Websockets or something. Mostly that sounds like an RPC to me, which I suppose is technically an API, but I'm used to hearing the more specific term.
To be clear, what is at stake is not using the API, it is to copy the API.
In the case of a website, let's assume that you created ws.com, and that you developed an API that answered 'A' when you call ws.com/A, and 'B' when you call ws.com/B. Then you could sue anyone who'd develop a different website that behaves the same way even though the implementation itself may be completely different.
I'm not entirely convinced that's unreasonable. Designing a good API is hard. Most interfaces are terrible.
If someone wants to clone wordpress then maybe they should just design their own API. If the Wordpress API is that good then maybe it's worth licensing.
By that logic Ford should copyright a cars brake and gas pedal and force other manufacturers to design completely new interface systems to stop and accelerate cars that aren't brake or gas pedals. Sounds great /s.
I don't even know where Cloning WordPress came into your thought process. WordPress runs on top of Apache/nginx. That is what responds to ws.com/a. Interoperability is incredibly important, unless you want to go back to having to run a specific Web browser for every other website that isn't using Web standards / rfcs.
Actually car companies are starting to patent vehicle control interfaces, (for e.g. Teslas patents for Sunroof control interface [1], Audio Control interface [2], etc)
If the current craze of IP-as-offensive-weapon were the trend back in the days where basic vehicular controls were being defined, I think we would have seen some similar behavior from car companies - (and in my opinion, their case would be more defensible than Oracle's software API copyright protection).
Ford's API could be copyrighted. Sure. Why not? Every car manufacturer has their own software. Why would you even want Ford's version?
The braking API isn't "bool braking;". And acceleration isn't "float accel; // [0,1]". Those systems are wildly complex. Ford's copyrighting of their API does nothing to prevent another manufacturing from making their own.
Clearly some people at Oracle think that way too. They probably paid a lot for 'owning' the Java language and runtime, and only to see that Google just developed their own, and copied the whole API on top of it. So they are probably pissed that their language is slipping away (Java is definitely no longer associated with the Oracle brand).
Thing is Oracle got screwed in the first place, they shouldn't have thought they could "buy" the language.
I don't think Java was ever associated with the Oracle brand. By the time Oracle acquired Sun, Java was already starting to slip away from being associated with Sun! "Java" was only ever qualified when referring to third-party implementations: you never heard "Sun Java", but you'd sometimes hear "IBM Java", etc. "Sun Java" at some point became just "Java".
Personally, as a Java developer from 2005-2012, I never associated Java with Oracle. I can't imagine that I'm the only one. Even now, when I need a JRE or JVM, I navigate to http://java.sun.com/ instead of wherever it is I'm supposed to go.
Remember why there are govt protections for these things in the first place.
Imagine a spectrum - on one side, there are no protections, and people can copy ideas, implementations, etc. For some industries this is no big deal, but for others it would seriously harm the production of new ideas/products, because it remove any financial incentive. Take writers for example: While I think the US copyright terms are stupidly long, I wouldn't want to live in a world where the only books written and published were done so as labors of love.
On the other end of the spectrum is a collection of hard, strong rules governing the use of any other ideas. On this end too few new ideas/products are made, because it is in the short-term financial interests of those that have the lock on any market to prevent competition or disruption. We have several industries quite close to this end of the spectrum.
The happy place for society is in-between these areas. Lower barriers of entry for potential competitors, so that they can compete. Does this mean that some of these competitors would benefit from the hard work of those that came before? Absolutely! But the alternative is making the barriers to entry too high, so that no competitor can gain traction because they can't be better in all ways and produce an industry interested in compatibility overnight. (Witness Linux and device drivers for a good example)
The reason govt offer protections for various areas is NOT to benefit a small number of companies or individuals (in theory) - it's to benefit the whole of society, in the long-term (which should include those companies and individuals, along with future companies and individuals).
It's not about protecting that which is _that good_, but about pushing us towards _even better_.
It is extremely disingenuous to suggest that some combination of the Linux kernel and surrounding libraries are not intentionally knocking off at least a large subset of UNIX APIs.
And there's absolutely nothing wrong with that, which is part of what makes the Oracle assault so disgusting.
So despite all the hype, this case is unlikely to have a huge effect on the software industry.
Oracle might try and paint that picture, but I'm afraid it will. There can be no software industry if APIs are subject to copy-write, and if they are, simply using them always comes under fair use. That's why....you use them.
One thing to note is that if Google loses, this is going back up the appeal chain and will no doubt take another whack at the Supreme Court on the original issue. We don't know why the Supreme Court denied cert., but among the reasons that Oracle said that it should do so was that the appeal was interlocutory, and there is a preference in appeals courts agains such appeals -- that is, because the ruling that resulted in sending the case back to the trial court to decide the fair use issue, the decision was non-final, and, if the Supreme Court were to hear an appeal on the issue raised (which Oracle also argued that they shouldn't, for other reasons), they should do so only after a final decision in the courts below.
Because its possible that that was the reason the Supreme Court declined to hear the appeal, its certain that should Google lose at trial on the fair use issue, they'll be back up the appeal chain not only on that issue, but also attempting to raise the copyrightability issue with the Supreme Court again. Which may be more inclined to take and decide the issue on a final decision (and, depending how long things take to get through the courts, and what happens in the political sphere, may be a substantially different court than the one that refused the case previously, anyway.)
Also, since the patent claims are now gone from the case, I think the inevitable (whoever wins) first appeal from the trial court will now go to the Ninth Circuit and not the Federal Circuit, and its quite possible that the Ninth Circuit will rule differently on the issue than the Federal Circuit did.
It should be noted that the Court of Appeals for the Federal Circuit's ruling in this case does not set precedent for future copyright cases. For more details, see this comment from an earlier discussion: https://news.ycombinator.com/item?id=11377318
If I remember correctly, the appeals court did not rule that APIs are copyrighted, only that they might be copyrightable in some cases. Judge Alsup had ruled that they couldn't be copyrighted; that if you used the four-factor test, you would always always come to the "outside copyright protection" answer in all cases.
The Federal Circuit didn't remand on the question of copyrightability, it reversed. In other words, it explicitly held that the Java APIs at issue in the case were entitled to copyright protection, not merely that an API could be.
I had to dig up the ruling ( https://www.eff.org/files/2014/11/10/oracle_v_google_13-1021... ). It looks like my memory was faulty: "Because we conclude that the declaring code and the structure, sequence, and organization of the API packages are entitled to copyright protection, we reverse the district court’s copyrightability determination with instructions to reinstate the jury’s infringement finding as to the 37 Java packages. Because the jury deadlocked on fair use, we remand for further consideration of Google’s fair use defense in light of this decision" (pg. 5).
I don't think you're necessarily contradicting maxlybbert, if the Federal Circuit only reversed the lower court on the question of the Java API in particular.
Isn't such uncertainty by itself a death sentence for a vast range users relying on incorporation of APIs into their software? Can open source projects and small developers employ lawyers to decide if their particular use is "fair"? It seems to me that anything other than an extremely clear cut decision is going to be a disaster for the software industry here.
I certainly prefer a simple rule so that I don't need to ask an attorney whether a particular API is copyrighted before I start working. But I found the original article misleading in a few aspects, and wanted to clarify things before the discussion turned silly over misunderstandings.
It's also true that courts are expected to come to the right conclusion for the right reason. If a company spent years telling people they were free to use some particular API, then sued them for doing so, it would be important to distinguish between a case where the API isn't copyrightable and a case where the API is copyrightable but that people had permission to create derivative works based on that API. For some reason, many people are unable to make that distinction when talking about things around the water cooler.
One thought over the last years MS has seen the light, but they haven't. Maybe someone will sue them over their Ubuntu on Windows, it's not about interoperability either.
Seriously, when a corporation creates a VM and enforces a standard, and provides APIs for use in their framework/software ecosystem - just don't adopt it.
If it is done via a Foundation with an API/ABI that is freely available to use - then use this.
But never adopt a framework created by a corporation if you can avoid it. And that includes .NET. While the current corporation may be benign, some other rapacious and unethical corporation might buy them out - then you are screwed.
Of course it is a problem with ecosystems that already built around APIs like JSE/JEE / Java core. It is only a problem, because people did not care much about licenses or questioned copyright in terms of APIs.
I believe that APIs are copyrightable. It should be up to the creator to specify licenses that suits his agenda. I believe, if API users care about it and like to build a business on top, only APIs and standards with Copyleft licenses will thrive.
If it turns out that api's are copyrightable then in the short to medium term this will cause some indigestion. In the longer term though companies and developers will just insist that api copyrights are put in the public domain or they won't use them. Lockin avoidance.
WHY?? And here I thought Microsoft was coming around. Fuck these assholes (and EMC and NetApp too). What do these people have to gain by letting the ruling stand? It just makes interop harder. And here they are tapping into the Linux API shamelessly[1]. Shame on you fuckers.
[1] http://arstechnica.com/information-technology/2016/04/why-mi...