And throw out the hard work __ALL__ browser vendors are doing TOGETHER on WebAssembly? In favor of a VM that clearly has restrictions and is owned by a litigious organization? Bloating browsers by adding another VM, which will hurt throughput by having multiple GC's to synchronize?
The JVM ecosystem and Hotspot are certainly modern marvels, but there's hurdles greater than the potential benefit.
"a VM that clearly has restrictions and is owned by a litigious organization"
Indeed - if there's one thing that this case has shown it's that java is poison legally. If a company the size & power of Google is being forced to take a project the size & importance of Android places they really don't want to technically, well, that's a very big deal. And I wouldn't like to think what would happen to any smaller group that wanted to take a java technology down a path that isn't Oracle-approved.
No. Variety breeds better products and WebAssembly is a pretty different thing from the JDK. You might as well say that web assembly competes with LLVM.
I don't see anyone adding Java back into the browsers, that ship probably sailed.
I also have a huge problem with the litigious nature of Oracle... However, this would mean that something was settled and might reduce the likelyhood of future lawsuits especially in regards to patents or copyright. WebAssembly didn't go thru that process which might mean that if it picks up some anonymous patent holder might start attacking it. It is vendor neutral though, which is both a plus and a legal liability as there is no single "responsible" entity.
The JVM is already open source. If this matter has indeed been settled, then the litigious organization issue might have been too. WebAssembly doesn't have a GC, and probably won't for some time. It also doesn't have ~20 years of performance tuning on different microarchitectures the way the JVM does. Benefits include getting scala, clojure, jython, jruby, and about 30 other languages working client side in the browser for free. Not to mention the languages that have been statically compiled will run way faster than the equivalent JS. That would be great for mobile, and the spread of the open web.
I can picture Google's lawyers using that in court against Oracle.
> then the litigious organization issue might have been too
That might is a big MIGHT, the same kind that keeps browser vendors from shipping various media codecs and news companies from using various media streaming protocols.
> WebAssembly doesn't have a GC
The GC all browsers currently have and will not get rid of that I was referring to was the JavaScript VM.
> It also doesn't have ~20 years of performance tuning on different microarchitectures the way the JVM does.
And the JVM doesn't have the start up performance of any JS VM. I would estimate the number of exploits to be significantly higher for the JVM, but worth less.
> Benefits include getting scala, clojure, jython, jruby, and about 30 other languages working client side in the browser for free.
JS is the most compiled to language in existence. Also, my point has been none of this would be free. How do you integrate JVM with DOM? Who's going to rewrite all that? Who's GC cleans up around here?
> Not to mention the languages that have been statically compiled will run way faster than the equivalent JS.
Are you talking about WebAssembly here? Cause it sounds like you are.
I actually worked for Sun/Oracle on VM's but on the embedded not hotspot team. The trick is actually simpler and its called MVM, which is something Sun kept avoiding on the desktop/server for some stupid reason but we did do it on mobile and it made startup almost instant.
The trick is to share one VM instance between multiple apps. So when the OS starts you start the VM process and then fork with a lot of the JITted code already in place so you get almost instant startup and reasonable process isolation.
In mobile where there are some restrictions this is very practical. On the desktop/server this gets a bit tricky with bytecode manipulation, classloaders etc. But this is totally doable.
My personal uninformed theory is that Sun or Oracle didn't do this because they didn't care. MVM has two use cases: faster startup/lower overhead on desktops (they don't care about that).
Server efficiency in small scale deployments (which they don't care about either). AFAIK Google did some work on MVM for App Engine Java, but those are just rumors.
> The trick is to share one VM instance between multiple apps. So when the OS starts you start the VM process and then fork with a lot of the JITted code already in place so you get almost instant startup and reasonable process isolation.
Android does this, unless it changed recently. The common parent process is called "Zygote".
MVM relies on the runtime system to enforce security isolation. In a system like Android that allows unrestricted loading of native code, this scheme can't work, since there's no way to get arbitrary native code to play along with the runtime security model.
Personally, I feel much more confident with the kernel enforcing application isolation than I would feel about relying on the Java security model.
As a sibling comment pointed out, Android already does this. To learn (an insane amount of) more detail about how this works, read this article I wrote a while back on how Process Loading on various systems is optimized.
It's not the same thing at all. Android first makes a process template, then takes clippings for each process it wants to run. That's not the same as running different applications in the same process.
The person who worked for Sun/Oracle, the one who first mentioned this technique earlier in this thread, was quite clear that the technique involves loading a single VM and then "fork[ing] with a lot of the JITted code already in place and reasonable process isolation". You are, of course, correct that this is not the same as "running different applications in the same process", but that is not the technique that was described.
> The trick is to share one VM instance between multiple apps. So when the OS starts you start the VM process and then fork with a lot of the JITted code already in place so you get almost instant startup and reasonable process isolation.
FYI that's how we implemented MVM in CDC mobile which isn't necessarily applicable for hotspot.
The MVM RFE for hotspot has been something desktop developers have asked for since JDK 1.2 days. It sort of got sidelined when the JDK started sharing loaded classes (the rt.jar) which is important but not quite MVM. Even the weakest of Android devices is probably more powerful than our "smartphone" targets in terms of heap. Using process isolation was often not an option back then since common OS's at the time (symbian) didn't really have isolation.
HotSpot has something called "Class Data Sharing" these days, in which pre-processed data is mmapped into the VM and shared between VMs as a result. More and more stuff is being put into the AppCDS files with the result that the VM has to do less and less work to start up. The jigsaw work also includes stuff like this via the jimage file format.
I don't think this is a significant issue because it's a one time cost. It could be done at browser startup. Even for a cold start, Hotspot and V8 are comparable.
$ time java com.Hello
real 0m0.096s
user 0m0.103s
sys 0m0.013s
$ time node /tmp/hello.js
real 0m0.073s
user 0m0.067s
sys 0m0.007s
OpenJDK has a full patent grant[1]. It is 100% open source in every way possible, its use is unrestricted, and it is released under the same license as Linux. AFAIK, Oracle has never sued anyone making use of it for whatever purpose whatsoever. It is important to remind the undisputed fact that -- at least so far -- Google has chosen not to use OpenJDK (or, in any case, they did not comply with its license), and therefore its open source status is irrelevant to the court case.
[1]: That grant is automatic, by the open source license. In addition (and unrelated to OpenJDK), there is an explicit patent grant to conformant implementations of Java (be they based on OpenJDK or not).
Of course, if you don't conform, Oracle will sue you into oblivion. Java is free software as long as you use it in exactly the way Oracle wants, right? It's for this reason that Java is poison to any of my projects. I'll choose Node-fucking-JS over Java, because nobody is going to sue me for using JavaScript the way I want.
> Of course, if you don't conform, Oracle will sue you into oblivion.
What? OpenJDK is as free as they come. No conformance with Java necessary, you can do with it whatever you damn well please. You can use it to implement .NET if you want. Oracle has never (to the best of my knowledge) sued anyone for the use (or modification) of OpenJDK.
Okay, so can I modify it so that it doesn't conform to the Java specification? Can I modify it bit-by-bit until it's bytewise identical to Harmony? Of course I can't. Because if I do, Oracle will sue me.
Oracle is lying. They claim to be offering free software, but will sue you once you take advantage of that freedom. It's a fucking trap.
Do you really expect the technology community to embrace Oracle technology after Oracle spits in their food and shits in their sink?
> Okay, so can I modify it so that it doesn't conform to the Java specification? Can I modify it bit-by-bit until it's bytewise identical to Harmony?
Absolutely (on both counts, although if it is identical to Harmony you may be in violation of the license due to a collision between GPLv2 and ASL, as ASL imposes further restrictions which GPLv2 does not allow -- see the next paragraph).
> Because if I do, Oracle will sue me.
They will not. In fact, they explicitly allow you to do whatever you want with it. They are not placing any restrictions; their own license (same as Linux's) does not allow them to do so (section 6 says: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein").
Oracle sued Google, not you. They didn't sue them for using Java, and they certainly didn't sue them over OpenJDK. Of course, it has been Google's PR department's strategy to make you think that the lawsuit may apply to you, but it doesn't. The circumstances leading to the lawsuit were very unusual.
> Oracle is lying.
Maybe about other things (I don't know a large company that doesn't lie), but not about this.
> They claim to be offering free software, but will sue you once you take advantage of that freedom. It's a fucking trap.
Again, to the best of my knowledge, that has never happened.
> Do you really expect the technology community to embrace Oracle technology after Oracle spits in their food and shits in their sink?
I don't expect anyone to do anything other than to understand the facts and then make their decisions[1]. Oracle has earned the distrust of many developers, but I don't find Google to be any more likable. Personally, I'll take Oracle's old-school greed over Google's sneaky espionage and manipulative PR, but that's just me.
----
[1]: I am willing to bet that very few people understand what the Oracle v. Google court case is all about, and the loudest voice was by far Google's PR.
I am biased towards Oracle because I do want Android to be closer to orginal Java and wish both companies collaborate for future Java versions. However I do agree that Google's PR has tried to picture Google as victim. If we see Google specifically didn't choose OpenJDK to avoid GPL. So they wanted to make profits but avoid collaboration. If this makes them bring to use GPL, let it be.
First, we should separate the motivation for the lawsuit from the legal arguments. Corporations don't go to court to win legal arguments; they go to court to defend or promote their business.
I) The motivation for the lawsuit was that at the time, Java's main revenue stream was licensing Java IP (either an actual implementation or the permission to implement the spec) for use in mobile devices. That was how Sun made money off of Java. Java's commercial license allowed people to freely implement the specification as long as they pass the compatibility test, unless the implementation was for use in mobile devices -- this required a paid license. Google then created an implementation of (a part of) the spec, and didn't reach a licensing agreement with Sun (they couldn't agree on a price; I think Sun wanted $25M for the first five years or something). Google used Java IP to directly attack said IP's main revenue source. That is not to say that what they did wasn't legal, but that is why what they did mattered to Sun (and then Oracle) enough to sue them. Google needed Java because developing a language ecosystem suitable for phone application takes years. Google knew that such a lawsuit is forthcoming -- you can't come at a company like that and not expect one -- but hoped that they could defend their actions in court, at least on legal grounds. So that's what the lawsuit was about.
II) Now for the legal case. Oracle wanted to get their (in their view -- fair) share of Android no matter how, so they used -- as anyone does -- any legal argument they could think of which would get the desired business result, from patents to copyright. Some stuck, some didn't. In the end, it was the API copyright argument that convinced the (appeals) court. But before I say a few words about that, let me reiterate: Oracle didn't set out to copyright APIs; they set out to get a share of Android, which attacked their main Java revenue stream directly using their own IP. Anyway, Google claimed that APIs aren't copyrightable, but Oracle won that round. Now, I will not go into this question itself -- there are good arguments for both sides -- but only into its ramifications. Google started a massive PR campaign to convince people that that ruling is disastrous for them, but it isn't, and for several reasons.
First, it applies only to language-level APIs; not REST protocols, recently also referred to as APIs. This is not open to interpretation. Web "APIs" are not copyrightable for completely other reasons, reasons which are impossible (as much as anything in law is impossible) to argue against. Second, the court ruled that some of Google's argument regarding the copyrightability of APIs are really fair use arguments, and this is the second crucial point: if something is copyrighted, that does not mean you may not freely use it for some purposes. When it comes to interfaces, one fair use defense has been interoperability[1]. Courts have ruled it legal to "violate" copyright for the purpose of creating components that are interoperable with the original. This means that if you implement an API in order to break vendor lockin, you're probably within your right to do so. However, that is not what Google did in this particular case (Android is not interoperable with Java, only very, very partially). So while Google may still lose the fair-use question (which is still on the table), nearly all other implementors would still be protected by fair use.
To sum up the legal issue, while it has been in Google's best interest to cause panic, the ruling does not apply to any other player but Google because:
1. It only applies to language-level APIs; it does not and cannot apply to web APIs and other protocols (either software or hardware).
2. Implementing an API is protected by the interoperability fair-use defense, even if Google's particular (and highly unusual) use isn't.
And in any case, unless you use a company's (language-level) API against it, there is little chance they'll come after you; if you do, well, you knew they'd come after you even before this court case.
III) Finally, it is important to note that all along Google had the option of freely using OpenJDK. The use of OpenJDK does not require conformance with the Java standard; it is completely unencumbered. The reason Google opted not to do it was because at the time they were afraid phone manufacturers would not like OpenJDKs license, GPLv2 + the classpath exception, even though Android also make use of Linux, which is also licensed under the GPL. This reasoning seems to have changed now.
You're saying that I can do whatever I want with OpenJDK until it cuts into Oracle's revenue stream, at which point Oracle will sue me and keep suing me until they find an argument that shuts me down?
No thanks. Free software is based on irrevocable legally-granted rights, not some horrible company's largesses. If OpenJDK really is free software, I should be able to hack it such that it no longer conforms, stick it in a phone, and ship millions of copies without being sued.
Google's case isn't unusual at all. The same logic applies to anyone reimplementing an existing API with anything but bug-for-bug compatibility. Your view means that we can improve nothing, delete nothing, and deprecate nothing, since as soon as an API implementation diverges from the original, it's suddenly not for "interoperability", but rather an illegal appropriation of somebody's revenue stream? That argument is blatantly inconsistent with free software principles.
I'm going to give you the benefit of the doubt and assume that you're just an ardent Oracle fan, not a paid shill. It's really hard to tell the difference sometimes. Please reconsider the effect Oracle's litigation has on the entire software ecosystem. Consider that we wouldn't even have Unix if its view prevailed. You should be ashamed of yourself.
> You're saying that I can do whatever I want with OpenJDK until it cuts into Oracle's revenue stream, at which point Oracle will sue me and keep suing me until they find an argument that shuts me down?
Not at all. I'm saying that you can do whatever you want with OpenJDK/Java, but if you don't abide by either of their licenses -- the commercial or the open source license -- Oracle will come after you, but probably only if you pose a serious threat to them, or else they wouldn't bother. Do you know of a company of Oracle's size that acts any differently? In fact, Google expected the timid Sun to come after them, and it was only Sun's decline that stopped them.
> Free software is based on irrevocable legally-granted rights, not some horrible company's largesses.
It is, but free software does have a license, and you don't get those rights until you comply with the license. That applies to OpenJDK just as it does to Linux, both released under the same license, BTW. Google is adopting Java's open-source license just now. They had their reasons, but they most definitely did not until now.
> I'm going to give you the benefit of the doubt and assume that you're just an ardent Oracle fan, not a paid shill
I am far from a fan. Oracle is a terrible company, and I wish it was a different company that had bought Java. But Google is worse. So I guess you could say that in this case, Oracle is the lesser of two evils. But what really bugs me is that the huge Google PR machine has done everything in its power (and quite successfully) to confuse everyone about this case, and convince people that the lawsuit has any bearing on them whatsoever. The ferocity Oracle's legal team is legendary, but it doesn't come close to the legendary manipulativeness of Google's PR. Employing paid shills is much more a Google thing than an Oracle thing; Oracle prefers lawyers.
I was, however, a fan of Sun.
> Please reconsider the effect Oracle's litigation has on the entire software ecosystem.
And what effect is that? I know that Google tries to convince people it has far-reaching effects, but the actual ruling doesn't seem to imply any of that.
> Consider that we wouldn't even have Unix if its view prevailed.
That's just Google PR talking. Let me make this short and hopefully clear: Google copied part of an Oracle/OSS API and broke compatibility in order to make a profit. They didn't try to build an interoperable alternative to Sun's Java, but to get into a ready-made market of Java tools and developers. The question of API copyrightability had never been settled, and whoever would have come after Unix after the ruling would (and certainly could) have done so before. Even if APIs are copyrightable, there's still fair use, two of those defenses -- interoperability and non-profit -- would apply to most implementations, but possibly not to Google's.
Sure, maybe APIs shouldn't be copyrighted (again, this is only language-level APIs) -- I can see good argument for either side -- but the effect of their copyrightability on the software industry is at worst minimal, and is most likely nil because of a thing called "fair use". I am not aware of another case where a replication of an API was done both not in order to build a compatible product and for profit.
Besides, their "view" wouldn't have even been made (as I said, Oracle didn't set out to make a legal point) if Google had only licensed Java in one of the two available ways, one of which they are finally doing now and the other they could have probably afforded at the time. Google knew full well that Sun would come after them, but hoped they could win in court.
> That's just Google PR talking. Let me make this short and hopefully clear: Google copied part of an Oracle/OSS API and broke compatibility in order to make a profit. They didn't try to build an interoperable alternative to Sun's Java, but to get into a ready-made market of Java tools and developers.
What's wrong with copying part of an API? You yourself admitting that I can do whatever I want with OpenJDK, including copying only part of it. I can then use this copy to make a product that turns a profit. If Oracle will sue me to this practice, then Google, not Oracle, is on the right side here.
> What's wrong with copying part of an API? You yourself admitting that I can do whatever I want with OpenJDK, including copying only part of it. I can then use this copy to make a product that turns a profit.
Absolutely, as long as you comply with the open source license, which is plain GPL in this case (just like Linux). Google didn't -- until today -- as they released Android under the Apache license rather than the GPL license. They always had the option of going GPL -- in which case Oracle would have not come after them -- but they didn't want to[1].
> If Oracle will sue me to this practice, then Google, not Oracle, is on the right side here.
Google did not comply with the license (either license, actually). Their legal claim was that they don't need to comply with any license, because if APIs aren't copyrighted, then they're not Oracle's to give (i.e. to license). That legal claim, too, is perfectly reasonable (as is its opposite), but it seems clear to me that it was Google who was at least ethically, if not legally, wrong in this case.
In any event, Java is also licensed with a standard open-source license (through OpenJDK), that you can use -- wholly or partially -- for any purpose whatsoever; Oracle has never sued anyone for using its code or APIs in this way for whatever purpose.
---
[1]: Which is why people in the free software community, even though they believed copyright shouldn't apply to APIs, were pissed off at Google for going to great lengths (and basically asking for this lawsuit) all in order to avoid the GPL option, which has been open to them all along.
For example, here is what the FSF had to say in 2010 on the matter (they were against Oracle's lawsuit because one of Oracle's tactics was to claim software patent infringement, which the FSF is against, as am I):
"Oracle's lawsuit threatens to undo all the good will that has been built up in the years since... Unfortunately, Google didn't seem particularly concerned about this problem until after the suit was filed. The company still has not taken any clear position or action against software patents. And they could have avoided all this by building Android on top of IcedTea [an early OpenJDK distribution], a GPL-covered Java implementation based on Sun's original code, instead of an independent implementation under the Apache License... It's sad to see that Google apparently shunned those protections in order to make proprietary software development easier on Android." (emphasis mine. Source: https://www.fsf.org/news/oracle-v-google)
I will add that while Oracle has treated some of its acquired open-source projects abominably -- e.g. OpenSolaris :( -- it has been very good to OpenJDK (more than Sun), so much so that virtually all development on the runtime at Oracle is done on OpenJDK these days. Also, Oracle still maintains more open source software than Google (and possibly any other company save for RedHat), but I'm not too hopeful about its future treatment. However, OpenJDK is now way too big for Oracle to ruin even if they tried.
> Google then created an implementation of (a part of) the spec, and didn't reach a licensing agreement with Sun
If Google used Apache Harmony, the ones implementing it where Apache Foundation. Why Oracle didn't sue Apache?
> hat is not to say that what they did wasn't legal, but that is why what they did mattered to Sun (and then Oracle) enough to sue them
Sun didn't sue Google in the 5 years Google used Android
> First, it applies only to language-level APIs; not REST protocols, recently also referred to as APIs. This is not open to interpretation. Web "APIs" are not copyrightable for completely other reasons, reasons which are impossible (as much as anything in law is impossible) to argue against.
And exactly why is different? The ruling talks about API and API's has nothing to do with being a language level API or a "web API".
> Second, the court ruled that some of Google's argument regarding the copyrightability of APIs are really fair use arguments"
As far as I know, the appeal court ruled that the fair use question must be decided in the forthcoming case, nothing more. As any other copyright case
> To sum up the legal issue, while it has been in Google's best interest to cause panic, the ruling does not apply to any other player but Google because:
>1. It only applies to language-level APIs, not web APIs.
You have to make your case why only applies to lkevel language API's
> 2. It is protected by the interoperability fair-use defense, even if Google's particular use isn't.
No, it has to go to court so yes, any player must be concerned
Simple: because they didn't have the motivation (see point (I)). Their goal wasn't to copyright APIs (that just was one of the many tactics used in court, and the one that just happened to win), but to get their share of Android. Suing Apache wouldn't have helped their goal in the least.
Also, while not relevant to the question, I will note that even if APIs are copyrighted, Harmony has a much stronger fair-use defense than Android: 1. It was done for the purpose of interoperability and 2. it was not intended to make a profit. Each of these is a fair use defense alone, and certainly together, but neither is true for Android (although the first might be partially true).
> Sun didn't sue Google in the 5 years Google used Android
Because they didn't have the resources and the inclination, as the company was already in a downward spiral and such a lawsuit could only have hurt them at the time. Google, however, fully expected them to.
> The ruling talks about API and API's has nothing to do with being a language level API or a "web API".
That's only because the term "API" -- until very recently -- was only used to describe language-level API, while what today is known as a web API has always been called a protocol, so don't let the recent overloading of the term confuse you.
More to the point, the reason copyright may apply to APIs but certainly not to protocols is because copyright law is not only concerned with the intent, abstraction, or use of the work, but also with its form. This why other IP protections (like patents) exist, to cover works whose form does not match those covered by copyright.
In particular, copyright requires a fixed representation (in text, image, recording etc.). So, for example, if I tell you a story, the story isn't copyrighted. But if I write it down -- or even record it -- then the text of the story or the recording is copyrighted. It doesn't matter that the purpose in all three cases was the same: to convey a story (once that fixed form is copyrighted, the protection may extend to non-exact reproductions, but that original fixed-form must exist). While a protocol may be described in a text and that text is copyrighted, the described protocol itself cannot be, because it does not have a fixed representation in text (a completely different text could describe the same protocol). A language API does have a fixed form.
> the appeal court ruled that the fair use question must be decided in the forthcoming case, nothing more. As any other copyright case
Yes, but that was the point. Google made some arguments that they believed would make APIs non-copyrightable. The court ruled that those arguments are fair-use arguments which are not relevant to the question of copyrightability, but may be used as a defense once APIs are copyrighted.
> No, it has to go to court so yes, any player must be concerned
Quite the opposite. It is the copyright holder who has to sue you. Any company would sue you if they believe they have a case, and you would still need to defend yourself in court when they do. The question of API copyrightability had never been decided, so even before the ruling there was a good chance you'd be sued, and you'd still need to defend yourself. Now, it is true that a ruling against API copyrightability would have removed this threat (which had existed even prior to this case), but now your position is not much different than before, only that except making two arguments (as Google did) -- that API are not copyrightable and if they are, you've made fair use of them -- you only have one: fair use.
> That's only because the term "API" -- until very recently -- was only used to describe language-level API, while what today is known as a web API has always been called a protocol, so don't let the recent overloading of the term confuse you.
A protocol is not the same as an API and I don't hink that the, for example, Google Maps interface is a protocol
> More to the point, the reason copyright may apply to APIs but certainly not to protocols is because copyright law is not only concerned with the intent, abstraction, or use of the work, but also with its form. This why other IP protections (like patents) exist, to cover works whose form does not match those covered by copyright.
But a web API is not a protocol and a communication protocol is not what is used to call Google Maps, beeminder or other web applications.
> Yes, but that was the point. Google made some arguments that they believed would make APIs non-copyrightable. The court ruled that those arguments are fair-use arguments which are not relevant to the question of copyrightability, but may be used as a defense once APIs are copyrighted.
NO, the appeal ruling had nothing to do with Google arguments about fair use. If there is a new trial to rule about the fair use is because in the original trial, the ruling about fair use was stalled by the jury and Judge Alsup stated that API's can't be copyrighted. And the Appeal court didn't wanted to rule about fair use
> Quite the opposite. It is the copyright holder who has to sue you.
Yes, but fair use is not automatically granted, so, you're in danger to be sued by the copyright holder. Microsoft can sue WINE developers or Amazon can sue anyone developing a clone of the AWS API.
> A protocol is not the same as an API and I don't hink that the, for example, Google Maps interface is a protocol
However you want to call it, unlike a "proper" API, it is not of the right form to be copyrighted, regardless of the ruling pertaining to "proper" APIs.
> NO, the appeal ruling had nothing to do with Google arguments about fair use.
The court didn't rule on fair use, but it did address it. They said that now that it has been clarified that interoperability is not relevant to the copyrightability analysis, it may still play a role in connection with fair use. Namely, that Google interoperability argument isn't an argument against copyright, but rather a fair-use defense, which should be argued separately (http://www.fosspatents.com/2014/05/oracle-wins-android-java-...).
> Yes, but fair use is not automatically granted, so, you're in danger to be sued by the copyright holder
That danger had existed even before the court case; the ruling simply did not lift it. Fair use is granted neither automatically nor in court. It is a defense to be used if you are sued.
> However you want to call it, unlike a "proper" API, it is not of the right form to be copyrighted, regardless of the ruling pertaining to "proper" APIs.
Still waiting an explanation about web API's not being a proper API. They are not protocols
> That danger had existed even before the court case; the ruling simply did not lift it. Fair use is granted neither automatically nor in court. It is a defense to be used if you are sued
So anyone is on danger of being sued by a copyright holder of an API.
> Still waiting an explanation about web API's not being a proper API.
It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all describing the exact same API. That is not the case for "plain" APIs. Plain APIs -- like all code -- do have a fixed form. But no fixed form means no copyright.
The very beginning of the definition of US copyright says[1]: "Copyright protection subsists, in accordance with this title, in original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device" (emphasis mine). There are other requirements, but without a fixed form no copyright may apply[2].
The bits of text comprising the names of JSON fields, while fixed, are too short (and lack the necessary structure) to be considered "a work" for copyright purposes.
> So anyone is on danger of being sued by a copyright holder of an API.
That has always been the case (because it had never been settled that code APIs are not copyrightable). A different ruling may have removed that particular threat, but it didn't. It certainly didn't add new legal threats.
But let me give you this advice: If you're a big company with deep pockets and you're coming after the income of another big company with deep pockets using something that may be law-related -- expect to be sued. In fact, I don't need to give you this advice because if you're a big company with deep pockets you probably know this, as you're already in the habit of suing and/or being sued all the time.
[2]: The law also says: "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", which is the source of Google's argument that copyright doesn't even apply to actual APIs, but that's a whole other discussion, and is far from simple. E.g. a book's table of contents could also be argued to be a procedure or a concept, yet it is certainly copyrighted. Oracle said that an API is like a table of contents. There are good arguments for arguing either way. But again, not having fixed form stops the discussion in its tracks.
> It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all describing the exact same API. That is not the case for "plain" APIs. Plain APIs -- like all code -- do have a fixed form. But no fixed form means no copyright.
You're joking, isn't?
> The bits of text comprising the names of JSON fields, while fixed, are too short (and lack the necessary structure) to be considered "a work" for copyright purposes.
What are you talking about?
Do you really know what an API is and how web services are defined? You're confusing argument names with the API definition.
What piece of (substantial) text is replicated when you implement someone else's web API? If there isn't one then there is nothing to copyright.
The question of how web services are defined is not material. The question is whether a "API" = "fixed text" or not. For library APIs, the answer is yes, for web APIs the answer is no.
For the purpose of this discussion there's no need to argue what an API is because it matters little. Like I said, it is like arguing whether a story is copyrightable or not. It turns out that whether something is a story is not the relevant question, but rather the (first) question is how is that thing (call it a story or foo) recorded in fixed form in tangible media. Java's APIs are recorded in fixed and tangible form; the Google Maps API isn't. Again, what it is may matter when you start asking further questions, but the very first thing in the US copyright code says that in order for something to be eligible for copyright it must be fixed in tangible media.
Just to make clear: I am not arguing that Java's APIs is copyrighted, just that there is good reason to see why -- from the perspective of copyright law -- the Google Maps API isn't, regardless of the status of the Java API. They could be absolutely identical from your perspective, and yet different enough from the law's perspective due to some minor detail that you -- but not the law -- may consider inconsequential.
Yes, it's utterly laughable. The sad thing is this isn't just him. This is actually what Oracle is arguing and the hoops they are jumping through to try and copywrite APIs for what they want but try and get around the very obvious problems.
You also can't label APIs as 'language level' either. It's ridiculous.
Not at all. Oracle is arguing nothing regarding web APIs, and I'm arguing nothing about library APIs. My argument's and Oracle's do not overlap. Oracle is saying that library APIs are copyrightable, and I am saying that even if they are, web APIs cannot be.
> You also can't label APIs as 'language level' either. It's ridiculous.
You don't need to label APIs in any way (and what you find ridiculous has little bearing on the law). The relevant question to this particular discussion is whether what you're trying to copyright is a piece of text or not. A library API -- like all code -- is text. A web API isn't. If there's no fixed text to copyright, all other discussions are moot.
You could also claim that copyrighting code while not copyrighting algorithms is ridiculous because in your mind they are the same. However, as far as copyright is concerned, an algorithm can be described in many different words -- and therefore there is no fixed form to copyright -- while a piece of code is fixed, and therefore could potentially (and, in fact, is) be copyrighted.
I think after a legal counsel it was impossible for Oracle not to move to courts. Else others would create spin-off's from Java and cite Android as an example.
You have a few things ass backwards with a fundamental lack of technological knowledge on more than a few points (to put it mildly), which is not unusual for lawyers and won't be for Oracle either.
> Google needed Java because developing a language ecosystem suitable for phone application takes years.
Google did not create a language 'eco system' from Java. They created an entirely new one. The only resemblance it has to Java is the fact that a few APIs look the same, and they presumably did this to help developers and phone manufacturers with familiarity and existing code. This is done every other day of the week in the software industry and presents no problem.
There is a fundamental comprehension problem about what the difference is between a set of APIs that a language uses, the language itself and its implementation.
> Anyway, Google claimed that APIs aren't copyrightable, but Oracle won that round.
The concept of APIs has been done and dusted before in the 80s and 90s and it will be again. If APIs are copywritable then there is no software industry. What's amusing is they they knew this was a problem because they had to build in a laughable fair use clause for interoperability. There is no situation where an API isn't used for interoperability and code reuse.
> First, it applies only to language-level APIs; not REST protocols, recently also referred to as APIs. This is not open to interpretation. Web "APIs" are not copyrightable for completely other reasons, reasons which are impossible
I think you need to re-read this back, carefully, and comprehend how utterly idiotic trying to separate 'web' APIs from 'other' APIs in terms of copywrite actually is. There is no difference and pigeon-holing this is plain laughable. The fact that you mention this shows that you, and probably Oracle, know what huge problems this causes. The whole argument is completely null and void and I'm afraid it very much is open for debate. Once again, we have legal people not knowing what they're talking about.
> Courts have ruled it legal to "violate" copyright for the purpose of creating components that are interoperable with the original. This means that if you implement an API in order to break vendor lockin, you're probably within your right to do so. However, that is not what Google did in this particular case (Android is not interoperable with Java, only very, very partially).
I'm afraid this is yet another piece of laughable misunderstanding and shows how shaky Oracle's legal case actually is. No one is under any obligation to implement a complete API. For example, there are many C standards and many implementations only implement a subset of a particular standard with a long list of caveats - and that's from compilers that claim to be C compatible. Implementing a subset of an API, taking code and compiling it on a new platform happens every other day of the week in software.
To attempt to claim that Google has no fair use argument because they didn't implement all of Java's APIs is completely laughable. There are a long list of exceptions going back decades that Google can use to completely invalidate this nonsense.
However, that's the big problem Oracle has. They have had to attempt to try and pigeon-hole what Google has used in Android as Java by jumping through a lot of nonsensical hoops.
> while it has been in Google's best interest to cause panic
There should quite rightly be panic. This means there is no software industry, and it goes way beyond Google and Oracle.
> It only applies to language-level APIs; it does not and cannot apply to web APIs and other protocols
This is complete tripe. It is impossible to pigeon-hole APIs in this manner because they exist at many different levels, and even this ridiculous definition still causes fundamental problems.
> Implementing an API is protected by the interoperability fair-use defense, even if Google's particular (and highly unusual) use isn't.
There is nothing unusual about what Google has done, but you would know that if you knew what you were talking about. Sadly, we have a lot of people, mostly legal, who simply don't.
As for what Google are doing with OpenJDK, I think it probably has more to do with tidying up their platform and multiple Android implementations more than anything else. Curiously, using OpenJDK and overriding core APIs with Classpath would also give them a pretty good example as to how ridiculous this whole thing is.
You may think this is the case and are entitled, of course, to your opinion, but:
> with a fundamental lack of technological knowledge on more than a few points (to put it mildly), which is not unusual for lawyers and won't be for Oracle either.
I am not a lawyer nor work for Oracle (or Google for that matter). Neither have I ever worked for Sun, Oracle or Google. However, I am a software developer and have been one for over twenty years. I have also collaborated with both Oracle and Google on OpenJDK (yes, Google has been collaborating with Oracle on OpenJDK throughout most of the court case, as much of Google's infrastructure is built upon OpenJDK).
> This is done every other day of the week in the software industry and presents no problem.
That's news to me, and I am quite familiar with the industry. I am not aware of many more cases where such a wholesale copying (without license compliance) of an API has taken place for reasons other than source/binary compatibility. There are a few (UNIX is a famous case, but that's been challenged in court already), but none recent. Again, regardless of how ridiculous, laughable or preposterous you think copyright law is, it most certainly does not apply to languages (like SQL or the Java language itself) nor to any other algorithm, protocol or API (as in web APIs) that does not have a fixed representation in text.
> I think you need to re-read this back, carefully, and comprehend how utterly idiotic trying to separate 'web' APIs from 'other' APIs in terms of copywrite actually is.
Again, the matter of whether you think this is idiotic or whether this really is has absolutely no relevance to the law. If I tell you a story it is not copyrightable; if I write the same story down, it is. If I record myself while telling you the story, it is also copyrightable. The same story, serving the same purpose may or may not be copyrighted depending on the very particular form it takes. You may think this is idiotic (although you may be persuaded otherwise if you studied the purpose of copyright vs other forms of legal IP protections), but that's how it's always been.
> I'm afraid this is yet another piece of laughable misunderstanding and shows how shaky Oracle's legal case actually is.
I don't know if you've noticed, but I'm not arguing Oracle's case. I think there are good arguments to copyright APIs and good arguments against, but I really -- in all honesty -- don't have a final opinion on the matter. You think Oracle's case is laughable -- fine. My point is that no matter if Oracle is right or wrong, from the perspective of copyright law a ruling on library APIs does not translate to web APIs regardless of how similar or even identical you believe they are. Copyright law is very specific about the forms protected works may take. If a work is a specific, fixed text it may be copyrighted (if it meets some other conditions); if not -- it may not.
> This means there is no software industry, and it goes way beyond Google and Oracle.
That's your opinion. However, the ruling does not apply to any API or protocol that is not recorded in fixed media, and interoperability has been accepted as a fair use defense before. I am not aware that the software industry is predicated on copying and re-implementing significant APIs (not a function here and there, which is definitely fair use) for purposes other than interoperability.
> Curiously, using OpenJDK and overriding core APIs with Classpath would also give them a pretty good example as to how ridiculous this whole thing is.
Maybe. I know that I and others wanted them to do this before the lawsuit ever happened, because everybody saw it coming (once Sun's fate was decided), but Google didn't listen. They preferred getting sued (which they had anticipated) over using GPL software.
All code can be a patent minefield. I predict we'll see patent trolls going after browser makers as soon as WebAssembly becomes popular. The fact that Java has a single, notoriously litigious owner actually works in its favour here - anyone trying to patent-troll Java will be issuing an invitation to Oracle's attack dogs, whereas WebAssembly could easily suffer a tragedy of the commons where no one browser vendor wants to spend the money to defend it.
> Remember that Web Assembly is designed to run in a JS engine.
Is it? It's a very low-level bytecode that's designed to be efficiently compiled in one pass, and completely unrelated to the JS engine. It isn't meant (at least at this time) to have an optimizing JIT (like HotSpot or V8). It is meant as a good target for languages that don't rely on/can't benefit greatly from good JIT optimizations, such as C/C++ (or Rust).
Of course, one could compile a JVM to wasm, provided that wasm allows applications to write to executable memory (which I doubt).
It is (though that's not the only thing it's designed for), but in a JS engine setting it only uses a few specific parts of the JS engine, such as the JIT backend to do the actual code generation work and interoperability with JS.
Indeed, wasm won't likely ever expose directly executable memory. But in the future it may expose JIT capabilities like creating and calling new functions, declaring "patchable" code fragments which can be manipulated through APIs, and so on, and with these capabilities it isn't unreasonable to think about porting JITing VMs onto wasm.
> WebAssembly doesn't have a GC, and probably won't for some time.
Yeah... because it's assembly. That's the whole point. You don't WANT a GC. It would be the wrong layer to place a GC in. Ask most professional game developers if they would consider using a platform with a GC. They won't, because you can't build a realtime system without stuttering if you're dealing with a GC.
1000s of games have shipped with gc. Every Unreal and Unity game uses gc. Every XNA game used gc. Many of the largest most popular AAA games use gc. So yes we can ask professional game devs if they want a gc. Most will say "yes". Like any tool you know when to use them and when not to
Further, a lot of shared data structures in super high perf C++ end up with "Free Lists" to allow multiple threads to perform atomic delete operations on the data structure. Point being that memory is no longer freed deterministically.
"If there's other threads working here, atomic compare and swap this pointer to the free list, otherwise last one out clean up."
Take a look at some of the code from Chapter 7 from Anthony Williams "C++ Concurrency in Action" [0].
I wasn't saying game developers never use GC's, I was saying they don't want the platform to make that decision for them. I'm not against GC at a language level, but I am against it in something that's supposed to be "assembly". It's just the wrong layer to place a GC in.
Anyway people are getting caught up in games, I'm just using that as one example of many where a GC may not be wanted.
In most of those cases, the performance-sensitive game engine itself does not use GC; GC is used in the scripting language that implements the high-level game logic.
The JVM ecosystem and Hotspot are certainly modern marvels, but there's hurdles greater than the potential benefit.