So, what's the most evil Oracle can be against future versions of Android given this?
And who actually guides the Java roadmap? The OpenJDK trademark grant (http://openjdk.java.net/legal/openjdk-trademark-notice.html) seems to spin on whether or not "the Software is a substantially complete implementation of the OpenJDK development kit or runtime environment source code retrieved from a single Website, and the vast majority of the Software code is identical to that upstream Original Software"?
What's to stop Oracle from deciding that future Java roadmaps are going to exclude Android-specific commits? Neither IBM nor Apple's interests seem particularly aligned with Google here (I'm assuming they throw some kind of weight in the OpenJDK politics).
Time and time again we see such short term thinking does not pay off. It wouldn't be evil on Oracle's part to do that, it would be just plain stupid. The resurgence of Microsoft shows that being open and transparent is the actual winning strategy. Goodwill among developers is not a quantifiable thing but it makes a huge difference.
The story I heard was that Larry Ellison was driving his sports car down 101, when a cop tried to pull him over for speeding, so he called ahead to Oracle security and had them stop the perusing cops at the security gate when they tried to follow him into the Oracle compound.
Too bad the ATF and Attorney General Janet Reno didn't take charge of the situation.
I find that story challenging to believe. Fleeing an officer would be probable cause for an officer to enter the property to make an arrest. I can't count the number of times I saw it on Cops (when I worked at a TV station that aired the show)...someone fleeing from a minor traffic violation goes into their home, police follow and make a dramatic arrest. It's not like playing "tag"; there is no "base" that protects you from being tagged by police in pursuit.
Funny you say that! This was a problem with drug smuggling. Now they have the shiprider program [0]. Basically a Canadian patrol boat has 1 american officer on it to make arrests if it crosses a border, and vice versa.
If I ever make a driving game... This will be in it.
I just love the absurdity of running a red light somewhere like California, Texas or Florida, then just going "F*&( it, TO CANADA!!!!!" <sound of engine revving up as driver floors it>
I bet OJ Simpson wishes he had his own private police force, a well defended secure compound, and a world class legal department on retainer and speed dial, like Larry Ellison does.
I don't think you deserve a down vote for being factually correct -- though a little hyperbole ain't gonna kill you. :)
But ORCL has gone from being an innovator to a rentier, and they're not averse to using hardball tactics on top of their historical position to try and stay relevant. Not using that HCM suite? Okay, but before you jump to a competitor just know that we'll increase your licensing fees if you stop using any of our products. Oracle is losing ground when it comes to new clients, but they're great at extracting every last drop of revenue from their legacy client base.
Their contracting arm is most notorious for massive boondoggles (USAF's ECSS, scrapped after a billion dollars of sunk costs; Cover Oregon, which ended in recriminations, lawsuits and an FBI criminal investigation), and its software was at the epicenter of the HealthCare.gov catastrophe. Oracle could have owned cloud computing -- hell, they bought the company that reinvented the concept and instead tried to use it to force expensive hardware purchases on their expensive software customers. Now they're a minor player in a field that is steadily expanding to cover their core business sector and they're milking their cash cows furiously in an attempt to extract maximum value from a dying field.
In other words, they're Blockbuster the year after Netflix debuted streaming; their model is faltering and they don't know how to replace it and still stay in business.
No, they're not evil, just a nasty piece of work to do business with, and they're not stupid, but they're slowly dying. I only wish they weren't taking the last remains of Sun with them.
"You actually don't need to be open minded about Oracle. You are wasting the openness of your mind. Go be open minded about lots of other things. I mean, let's face it: it's work to be open minded, right? I mean, you've got to constantly discard data and be like "ok, I need to be open minded about this". No, with Oracle, just be close-minded. It's a lot easier. Because the thing about Oracle, and this is just amazing to me, is, you know: what makes life worth living is the fact that stereotypes aren't true, in general. It's the complexity of life. And as you know people, as you learn about things, you realize that these generalizations we have, virtually to a generalization, are false. Well except for this one, as it turns out. What you think of Oracle is even truer than you think it is. There has been no entity in human history with less complexity or nuance to it than Oracle." -Bryan M. Cantrill
> The resurgence of Microsoft shows that being open and transparent is the actual winning strategy.
Or at least being a little bit open and transparent enough to build good will, anyway. There's a lot of non-open, non-transparent, non-friendly things about Windows 10.
He probably was but the way he phrased it he made it sound like Microsoft is widely open and trustworthy, when it's not. Some teams are able to be open and transparent, but the company as a whole is not.
I don't recall Microsoft saying that they would promise to stop. What they've done instead was to act in more honorable ways. The jury is still out when it comes to forgiveness, but they've made a pretty good start at it.
It's not just a promise. They have open sourced basically all the core parts of their developer infrastructure. What twitter did was be a dick and then promise to do better whereas Microsoft is actually doing it.
The trademark is orthogonal to the license and its patent grant. Why would Google be particularly concerned whether they can call what they ship "OpenJDK"?
Because ultimately the trademark is as much the "thing" as anything else could be said to be, at least as far as I could think it through.
Everything I can read also makes it seem like the patent grants (above the GPL) are all tied to the condition of generating a compatible implementation of Java.
If Google wants to fork OpenJDK at some point down the road, they'd better have faith in the GPL.
It doesn't mean OpenJDK will actually benefit from the improvements. All that's required from GPL is that you make the improvements available, not that you work with the upstream team to get them into master.
>When we asked Google why now, the company pointed to to the release of Java 8 last year and the introduction of new language features such as lambdas. As such, Google wants to put more resources into OpenJDK where the team can have a bigger impact on new features and improvements. That’s the developer story Google is pitching in any case, but there’s a massive legal narrative here that can’t be forgotten.
Yes, the legal narrative is certainly key here, but as a dev I'm all for a move that brings Java 8 to Android instead of just Java 6. It's about time!
No one should expect everyone to do that. This is basic, platform level stuff, that Google should be providing, unless they want Android to stagnate and whither away.
I will assume, for the purpose of this answer, that you mean "what is the big deal about Java 8 getting lambdas?". For other meanings of your question, see other replies.
In (pre-8) Java, variables can only hold primitive values or objects (in Java, an object is an instance of a class [c.f.]). Similarly, arguments to a method must all be primitive values or objects.
This is kinda crazy, by which I mean hilariously limiting. It's often useful to pass around other types of things, including types (in Java that'd be primitive types or classes or interfaces), or functions, or partially applied functions, or whatever. Of course, Java doesn't have functions, only methods. Whoops. See http://steve-yegge.blogspot.ca/2006/03/execution-in-kingdom-... for a bit of snark about how silly this whole situation is.
So Java programmers, while desperately lacking in aesthetic taste (I keed, I keed) and largely blinkered by the java-cultural context in which they find themselves, turn out to be a pretty clever lot after all. Clever enough that despite their language, they come up with all these conventions for doing things like passing around types and functions and so on. So you get ideas like the Runnable interface, wherein one makes a class just so that it can have a static method (perhaps called "run") that does what the function would do, and you then instantiate that class, and pass the instance, just so it can be used to get at the "run" method. It works, but it's oh so ugly.
So finally, after twenty years of this suffering, now Java programmers have some nice new syntactic sugar, to allow them to pass functions around with less explicit ceremony, thereby catching up with advanced languages like Python, C, Lisp, and basically everything except Cobol. Of course, under the hood it's still Predicate<T>, a generic type that represents a functional interface, which is a new bit of jargon they came up with to shoehorn this elementary functionality into their baroque conceptual framework. And you furthermore, in Java 8 you can even declare them anonymously (unlike e.g. C, AFAIK), to expedite the most common use case, which is passing a function as an argument to a higher-order function (like "map" or whatever). They're called "lambdas" because of the existence of the lambda calculus, an abstraction for computing that uses nothing but anonymous functions, and because many other languages have therefore referred to their anonymous function syntax as "lambdas" (Python even uses "lambda" as a keyword for this).
So the big deal about lambdas in Java is that Java has one less vile pain point.
(Any five-year-old could understand this explanation, right?)
Ok, so I think I'm half way there. Is passing a function pointer, or any pointer for that matter, the way it is done in C, related to lambdas?
I understand the use case of passing functions. Can be quite useful. Ok, still not fully there but I think I'm starting to understand what you are talking about.
It's useful to be able to pass functions. In C, the mechanism for doing so is the function pointer. Function pointers feel really complicated, relative to most other features in C, and relative to the mechanism for passing functions in other languages that allow it, but yeah, they do the job.
Consider, for example, how you'd pass a specialized comparator to a generalized quicksort function. In C, you pass a function pointer to a cmp() function. In Python you just pass a function, because functions are first-class values that you can use like anything else - you can pass it by name, or you can pass a lambda. In Javascript you can do like in Python, or you can declare a full-fledged function anonymously inline. In pre-8 Java, you have to pass a weird object that instantiates a class that has a static method with the right name; this is ugly as shit, but it does WORK. In Java 8 you've got lambdas, so that sucks less.
It's not like you can do anything you couldn't do before. It's just a little less stupid now.
Got it. One thing that really bothers me is the name lambda. It seems to be used for something I'm already familiar with and have used plenty before but with the added benefit of obfuscation to make me feel stupid. I wonder if somebody is trying to make themselves feel smarter or I'm just stupid. Anyhow, KISS.
Lambda calculus was invented in 1937 to describe this concept; it existed before function pointers, so the name is actually accurate, you're just not familiar with it.
I think the article is incorrect. I suspect they meant "implementation" rather than "APIs". As I understand it, OpenJDK has the same APIs (otherwise Google wouldn't be able to just switch to OpenJDK).
There are, actually. The Oracle JDK has some features that the OpenJDK does not. Look at the 'commercial features' to see what: examples include the resource management API, AppCDS, Flight Recorder, a few other things I forgot.
I think it's like this: Google copies Java's API. Oracle sues Google, claiming "You copied our API! It's copyright! You're infringing!" Google says, "Fine. We'll stop using your copyrighted API. We're going to copy the API of OpenJDK, which is GPLed so we're completely free to do so, and which just happens to have the exact same API. Good luck suing us for that one."
They're changing the Android Java runtime to actually use OpenJDK rather than its own proprietary implementation of the Java APIs.
Which is, perhaps, all that Oracle wanted all along.
Ater all, everybody wins from this.
- Android developers get up-to-date Java APIs that aren't years behind other Java platforms.
- Google gets to spend its engineering resources on things that matter specifically to Android rather than endlessly duplicating, and playing catch-up, to the OpenJDK platform.
- And Oracle gets a major industry player behind Java rather than fragmenting it and creating a slightly-incompatible variant.
Google's implementation isn't proprietary, it is Apache licensed. I think the idea of the parent comments holds. The irony is exquisite. Google is solving their copyright infringement problem by copying & distributing vastly more Oracle code.
It's not necessarily ironic. Oracle (or specifically Sun, which Oracle purchased) chose to create and distribute OpenJDK. They didn't choose to create Google's competing implementation, which perhaps they view as fragmenting the Java ecosystem.
That's true. It seems that alternatively Google could have relicensed their implementation as GPL and not have had to make any technical changes at all. Which shows that the only reason Google was maintaining their own implementation, and why they went through the lawsuit was just to keep GPL license out of their Java code. Seems nonsensical.
Google could not relicense APL code they did not write to GPLv2. The Java implementation is a subset of Apache Harmony, which they did not create from scratch.
Oracle maintains ownership of the OpenJDK project, which is the point here. Google simply relicensing its reimplementation of the Java APIs would not change the fact that the reimplementation is infringing under the law.
> Java APIs would not change the fact that the reimplementation is infringing under the law.
That's not an established fact at all. There is a whole lawsuit going on about it, if you haven't heard. If the final ruling is that APIs can be copyrighted, I'll change careers and never buy/condone the purchade of an Oracle product for as long as I live.
They do but there might be an important point embedded here. The OSS implementation is licensed for free use. That implies the API is authorized for that version. The two issues go hand in hand Im guessing.
from my understanding, openjdk is insulated from the supposed copyrighted api issue, though they still struggle with obtaining a test suite that can certify their implementation as "compatible", to some degree or another.
OpenJDK didn't exist in the early days of Android, so it wasn't an option.
Sun/Oracle created OpenJDK, effectively "open sourcing" Java in response to the popularity of clean-room Java reimplementations like GNU Classpath and Apache Harmony.
Why Android did not choose to adopt OpenJDK until now, however, is a mystery known only to Google. Maybe it was just a lot of work, technically speaking, to do so.
So far APIs cannot be copyrighted. There have been lawsuits over APIs but no decision that protects APIs from being used by other people and companies.
GNU/Linux for example uses Unix APIs and Mac OSX uses Unix APIs, so if APIs are copyrighted then they would be sued for using the Unix APIs without permission. Then they would have to remove Unix APIs and lose Unix compatibility.
Sun went after Microsoft and others over Java IP before Oracle bought them out. Sun used a lot of money on lawsuits and ended up losing money to the point that Oracle bought them out. This is the same as when SCO was suing over GNU/Linux using Unix source code. It usually doesn't work and costs more in court costs than any settlement or rewards.
Ummm...
"For the foregoing reasons, we conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages at issue are entitled to copyright protection. We therefore reverse the district court’s copyrightability determination with instructions to reinstate the jury’s infringement verdict. Because the jury hung on fair use, we remand Google’s fair use defense for further proceedings consistent with this decision. "
And just to save others some time, "declaring code" is defined in this footnote:
'Every package consists of two types of source code— what the parties call (1)declaring code; and (2) implementing code. Declaring code is the expression that identifies the prewritten function and is sometimes referred to as the "declaration" or "header." As the district court explained, the "main point is that this header line of code introduces the method body and specifies very precisely the inputs, name and other functionality." Id. at 979-80. The expressions used by the programmer from the declaring code command the computer to execute the associated implementing code, which gives the computer the step-by-step instructions for carrying out the declared function.'
> So far APIs cannot be copyrighted. There have been lawsuits over APIs but no decision that protects APIs from being used by other people and companies.
What about the decision of the Court of Appeals for the Federal Circuit in Oracle America, Inc. v. Google, Inc.? [1]
IANAL. Was that a decision that APIs were copyrightable, or that the trial judge couldn't definitively rule that they weren't?
[Edit: Ah, I see that this was answered by phonon in a post parallel to the parent. The appeals court ruled that they were. Note, however, that the Supreme Court declined to listen to an appeal by Google at this time. The Supreme Court did not rule that the Appeals Court was correct. Therein lies some hope...]
As I understand it, that's not how it works. When the Federal Circuit issued its decision saying APIs are copyright eligible, Google appealed to the Supreme Court, claiming the decision was incorrect. The Supreme Court, however, declined to hear the case, strongly implying (or maybe directly indicating?) that it thought the decision was correct. As such, there is no hope, at least as far as this case is concerned.
The way I read it, it is not just the APIs but Google copied source code from Java for use in Android:
With respect to the 37 packages at issue, “Google believed
Java application programmers would want to find
the same 37 sets of functionalities in the new Android
system callable by the same names as used in Java.” Id.
To achieve this result, Google copied the declaring source
code from the 37 Java API packages verbatim, inserting
ORACLE AMERICA, INC. v. GOOGLE INC. 11
that code into parts of its Android software. In doing so,
Google copied the elaborately organized taxonomy of all
the names of methods, classes, interfaces, and packages—
the “overall system of organized names—covering 37
packages, with over six hundred classes, with over six
thousand methods.” Copyrightability Decision, 872 F.
Supp. 2d at 999. The parties and district court referred
to this taxonomy of expressions as the “structure, sequence,
and organization” or “SSO” of the 37 packages. It
is undisputed, however, that Google wrote its own implementing
code, except with respect to: (1) the rangeCheck
function, which consisted of nine lines of code; and
(2) eight decompiled security files.
That is, Google copied the API. That's the declarations. That includes the package, class, and method names (and signatures) - that's what an API is in Java.
That's how I read this case as well. I've always been confused by the "API copyright" panic: If Google hadn't copied Oracle's source files (albeit interface-only source files) nearly verbatim, there would have been no liability. You're free to reproduce an API to provide to your clients; you're not free to take the interface files I wrote to provide the API, edit them a bit, and ship them as your product.
If I'm getting this wrong, I'd appreciate an explanation why.
There's no other way to "reproduce an API" in Java than to copy the names of methods, classes, interfaces, and packages verbatim. Otherwise, it would not be a compatible API.
The numbers in the telephone book are not copyright-able. You are perfectly able to produce a book of phone numbers in the same order and distribute it. However, if you were to photocopy an existing telephone book then you would be violating copyright.
Google did not produce their own compatible files containing the list of methods, classes, and interfaces. They copied Oracle's files.
> So far APIs cannot be copyrighted. There have been lawsuits over APIs but no decision that protects APIs from being used by other people and companies.
So, are you not familiar with the very very pertinent to this _particular_ platform recent case of Oracle v. Google?
I think the HN speculation yesterday that there's been a settlement is wrong. This is Google moving to protect itself going forward after it lost the case in the Federal Circuit. That case was sent back down to the lower court only for ruling if Google's use of Oracle's now apparently copyrighted APIs consists of "Fair Use". Since APIs are now copyrightable I don't see how copying thousands of APIs could possibly consist of "Fair Use" so it's looking like Oracle is going to get paid, big time. And Oracle will probably demand a royalty for every phone sold. So in order for Google to avoid paying that royalty going forward they need to move to OpenJDK quickly with their next release, with the belief that using Oracle's GPL JDK implementation also gives them a license to the API. Problem for Google is that OEM and user adoption of new Android versions is slow, it takes several years for phones with old versions to stop selling, and Oracle will get a cut of each sale.
In any case, I think this is a healthy development for Java developers and the Java ecosystem. Java has been effectively forked between Android and other uses and this will unify the language again. And it will bring the cool new Java 8 features to Android.
The answer is, it's fair use if you are trying to be compatible - DR-DOS could be considered a fair use copy of the MS-DOS APIs, because that's the only way to run DOS programs. But ordinary Java programs don't run on Android and Android programs don't run on the JVM. So Google lacks a fair use defense as far as I can tell.
I am sorry to see your comment was downvoted, as it is quite correct: if you read the actual court documents, this is the argument that was made surrounding fair use, and despite their attempts to lie and say they were, Google could not be shown to be trying to build a compatible product (as it is pretty obvious even to non-technical people that they aren't and never intended to even try). Back when this was first being published I wrote a much longer comment pointing out all of the intricacies and quoting the court opinion.
Having tried it myself, standard JVMs and Java bytecode are problematic if you intend to create an efficient handset OS. Danger and Android did a lot of interesting things to Java to make it work better, and the Android runtime has evolved away from from what JVMs look like for some very good reasons.
This isn't about the VM, it's about the code that runs on the VM. The Java language code, for example Object.equals(), that gets compiled into Dalvik/ART bytecode will now be OpenJDK code instead of Google's own implementation.
Google not buying sun was huge mistake.at least they could sell it after keeping java.something like what they did with Motorola. They kept all patent's. They could have done the same with java.
Consider Google bought Motorola for $12.5B[1] and Oracle bought Sun for $5.6 billion[2], I would think Google buying Sun would have been a better deal than buying Motorola.
Perhaps, but it's not like Google lost much by buying Motorola.
"I think the Motorola transaction has been a success for us. Financially, we bought the asset for $12.5 billion. It had $3 billion in cash; we were able to sell the Home division for $2.5 billion; we ended selling the handset division for $3 billion. There were some other tax assets as well. When you work through the math, you realize we spent between $2.5 billion and $3.5 billion for the patent assets. At the time, the nearest comparable transaction was the Nortel patent auction where Microsoft and Apple teamed up to buy that asset for $4.5 billion. And there’s a good argument that the Motorola patent portfolio is a better portfolio."
Motorola was threatening to start suing other Android ODMs which would have wrought havoc from within the ecosystem. IIRC, Sun was a lot more forgiving and basically willing to look the other way at Google playing fast & loose with Java stuff. It was not yet in the offing that a) Sun was for sale, or b) Oracle would be the one to buy them within 2-3 years almost exclusively to bludgeon Google with the IP. In hindsight, it would have made all the sense in the world. Back then, I don't think it was clear it would be necessary and would have surprised people in a negative way probably ("Google's going to sell SPARC servers, now?" -- remember IP was not the stated reason for buying Motorola even if it's obvious that is what it was about now - at the time Google claimed to want to make devices). Connecting the dots forward is hard.
Sun specifically approached IBM for merger talks, I have a hard time believing they were that secret given Oracle's actions. Looking at the threats, Sun under more litigious hands probably was more of a threat than Motorola.
I think they're pretty anti-GPL with Android, and have some rules against inclusion of GPLed components there, besides the kernel. I think the whole userspace is under non-copyleftish BSD/MIT/etc.
That's picking some major nits: whatever you want to claim is Google's internal mental opinion of GPL, the reality is they are building Android to cater to hardware manufactures, and those hardware manufactures do not want GPL, so Google has actively avoided GPL code in Android, often going to extreme lengths to build half-asses reimplementations of things that have perfectly stable GPL implementations so they don't have to rely on code using that license.
The JDK stays inside the development environment. The development toolchain translates Java bytecode to Dalvik bytecode. There are probably a few other GPL components in the toolchain, although they are transitioning away from GCC in the NDK.
Thank you for this.. that was my question, in a different comment. I was curious how using OpenJDK would prevent a similar lawsuit... Also, does this mean that Dalvik will be enhanced to support Java's compiled modules directly, or are they outright replacing Dalvik?
TFA doesn't make much of this all that clear to me. Though I admit I only skimmed it.
The original article title was changed to "Google won't implement Oracle's proprietary Java APIs", which makes more sense. This isn't about some special new APIs, it's about Google switching to the OpenJDK for the core APIs from its Harmony-based reimplementation.
It's also interesting to note that this is essentially the outcome advocated by the FSF in its amicus brief to the federal circuit. https://www.eff.org/cases/oracle-v-google
Well they based most of their original implementation on Apache Harmony. Just speculating here but it may have been due to dates. OpenJDK's first release was ~2007 but IIRC the original pre-Google Android team started work in 2003 or 2004.
OpenJDK starts much slower and consumes more memory than Dalvik and some official Java APIs are terrible (e.g. AWT); it's likely that Android would have failed if it used official Java.
Completely subjective here but no Go would not be better. Java has generics. Java has more support, more tooling and Android's existing eco system is fully mature. If they started out from scratch it would result in worse language with less tooling and a smaller ecosystem.
This is a huge win for open source if Google is going to build on OpenJDK. The implicit patent grants are huge! They can even pour resources into building a better GPL'd run time. So much of Google's internals are written in Java that they would certainly benefit from this.
Looks like another LibreOffice/OpenOffice Jenkins/Hudson split in the making. You'd think Oracle would have learned by now.
I wonder if they'll fork the Java language standard? That would seriously damage Oracle if it got traction. They couldn't use Oracle's trademarks but people are familiar enough now with Dalvik that they could just introduce Dalvik Server Edition and people would lap it up.
It makes sense. It future-proofs androids ongoing legal viability. If they haven't yet settled with Oracle then it also strengthens their negotiating position on the issue of damages for copying API signatures. Thanks Appeals court!
It also makes sense in light of Google's recent announcement that they are going to be shipping a desktop android os with chrome on it soon.
Unlike in 2008, Google no longer has to worry if phone vendors care about whether the runtime is GPL+classpath, which was probably the original motivation for an apache licensed runtime.
There is still however, the mystery of why the commit is missing the openjdk LICENSE file, or any mention of Oracle at all.
The following organizations and individuals have signed the OpenJDK Community TCK License Agreement (OCTLA) and been granted access to the JCK.
Signatories for Java SE 6
Azul Systems, Inc.
CACAO - Christian Thalinger
Cambridge Software Labs - Edward Nevill
Canonical - Matthias Klose
Google
Red Hat
Stratus Technologies
tarent
Yozosoft
I am kinda surprised they have not proposed a language (new or existing non-Java) yet for their phones. I thought this would at least be in the plans so they do not have to rely on Java alone. A big task for sure.
Perhaps they are waiting for Web Assembly to become mainstream. Then do a side-by-side:
1) Web Assembly -> new VM
2) Existing Java Apps -> Dalvik
With 2) eventually being phased out.
Edit: As pointed out below it is no longer Dalvik, but ART.
Seems like it would be massively messy to move to anything but another JVM language, considering the long history of Java-based Android. Matter of fact, I'm having trouble thinking of an example of any major platform making such a fundamental change and surviving. Maybe Apple switching from OS9 to OSX/Cocoa. They started building the Carbon compatibility layer, what, 2-3 years ahead of the switch, and IIRC the API is still available today, though considered deprecated. And no version of MacOS had anywhere near the adoption level or number of third-party apps as Android does.
If you distribute OpenJDK, then only the modules that are “derived from or based on” OpenJDK are required to be GPLv2[+CE] (the Classpath Exception allows you to link the library with an independent closed-source library). So I think it would only require platform/libcore itself to be released under GPLv2+CE. Probably manufacturers don’t need to modify platform/libcore too much anyway.
There's a bunch of GPL (or at least, open source) code in Android. Just go to Settings -> About phone -> Legal information -> Open source licenses and you'll see that lots and lots of parts of Android are open sourced (most of them using some version of GPL).
I'd like to see Google pouring vast resources into OpenJDK development and making Oracle Java obsolete. That's the karma they should get for being Oracle.
I don't think that's exactly the case. Oracle Java has some features that OpenJDK doesn't have. What if Google accelerated development of Open JDK beyond what Oracle is brewing so far that at some point Oracle will have a choice of just taking OpenJDK and stamping their brand on it (probably illegal) or being forgotten Java-wise?
Google would only need to fork and rename though, then Oracle wouldn't be running it. If using the fork were a requirement to running on Android, that's a big draw.
I'm not sure Google is really interested in that though.
This battle is very important: two questions it will answer are these:
1. Are APIs copyrightable?
2. If APIs are copyrightable, does providing an alternative implementation of someone else's API (the way Android provided an alternative implementation for some of the standard Java APIs) constitute a fair use [1]?
Google and Oracle settling this out of court would be very bad news: it would leave the above issues in limbo. That is a lot of legal uncertainty for any project that may wish to provide an alternative implementation of someone else's API.
That issue is going to be in limbo even if they don't settle out of court, unless the Supreme Court eventually takes the case (or Congress steps in and modifies copyright law to clarify this).
That's because this case is both a patent case and a copyright case, and that messes up the normal appeals path. Copyright precedent in the 9th Circuit is set by the 9th Circuit Court of Appeals and by the Supreme Court, and that is also the normal appeals path from the district courts in the 9th Circuit.
When a case involves patents the appeals path is to the Court of Appeals for the Federal Circuit and then to the Supreme Court. CAFC rulings on patent issues set precedent for all district courts.
Not so for CAFC rulings on copyright issues. 9th Circuit district courts, for instance, considering API copyrights in the future will continue to look to what the 9th Circuit Court of Appeals has said on this. What the CAFC has said is no more binding on them than what the 5th Circuit or the 7th Circuit or any other non-9th Circuit, non-Supreme Court court has said.
This is a pretty messed up situation. When CAFC gets something like a copyright issue that comes along for the ride on a patent issue, they are supposed to follow the precedent of the circuit from whence the case came on that non-patent issue.
If they botch that, there is nowhere to appeal to except the Supreme Court. But since the CAFC ruling on the non-patent issue won't be binding on anyone except the parties in that one case, it is not likely that the Supreme Court will take the appeal. Eventually, the issue will arise again in that same district, but without being attached to a patent case, and then can be appealed to the Court of Appeals for that circuit where they can clarify what the correct interpretation is in their circuit.
>So the only reason why you may object is that my lisp.a has an INTERFACE
that allows it to be linked to libreadline.a . As far as I know, only
the readline CODE is copyrighted, not its INTERFACE. (Would you object
because my libnoreadline.a has a similar interface?)
1) Gets an updated kernel
2) Can run standard JVM bytecode
3) Switches to CGroups
4) Allows for interop with desktop/server JVM
On a side note, I wish WebAssembly would just be JVM byte codes instead of this huge NIH syndrome. No need for the importing the Java SDK, broken sandbox mode, and all the other crap that made Applets fail... just the JVM itself.
It is unlikely that Android will run Java bytecode. The Dalvik runtime was aimed at keeping bytcode compact and interpreting faster than a JVM. ART is a pre-compiling (Dalvik bytecode to native) runtime. Using Java bytecode in the runtime on the Android device would open a whole big can of worms again. With open source APIs and no actual Java(tm) technology in an apk or on a device once code is translated from Java bytecode to Dalvik bytecode, Android stays clear of Oracle copyright claims.
You can actually load Java bytecode on Android (since 1.x!) by manually using a separate classloader at runtime[1]. There are even J2ME runners that have been doing that since Android's early days[2].
This would be great. The benefits of reuse of the toolchain and ecosystem alone are very compelling. That is another thing that will need to be reinvented by WebAssembly.
Sounds good. I hope that OpenJDK improves, because it's been sluggish and buggy in my experience. What Google should do is to move to something like Kotlin, which might make the whole programming environment less tedious than Java.
OpenJDK is licensed under the GPL. So as long as Google doesn't violate the terms of the GPL it's quite safe to use it. In addition, the GPL provides an implicit patent grant to the code: https://copyleft.org/guide/comprehensive-gpl-guidech7.html
I wish there was an option to disable the downvote arrow on comments, or only show the downvote arrow if I click the direct link for a comment (like with flagging comments).
I'd rather not create a new HN account just to read and reply on mobile without the risk of accidentally hitting a downvote button while scrolling or trying to upvote a comment.
I like Stylebot more. It integrates into the webpage better, so you can have live previews, and right click on an element to style in [0], and for basic changes (such as hiding elements) you can avoid touching CSS at all.
[0] Of course, it just takes its best guess as to which possible selector you really want to style when you do it this way.
As someone who had a neutral opinion of the importance of parent comment, I instead upvoted, thereby proxying and honoring your original intent in combination with tedivm.
I wish they had an agreement with Apple for the next 10 years for the use of Swift so we could write our apps once and run everywhere.
But we all know the NIH syndrome, which is a shame since everybody is adopting Google's web extensions standards and they should adopt whatever is best for all in other technologies too.
Swift? As an Android Developer I think it would not be a great idea.
C# maybe a better language(wasn't that open sourced?). It much closer to java than swift is and would allow people like me to move cover over faster.
I started off as a C# developer and had not done any real work in java before. I was able to move my C# code(couple thousand lines of code) over to Java in a matter of hours.
Anyway I do not wish or hope for a language change period.
Given that you know C# and Java, you should not have a great deal of trouble learning other C-family languages, including Swift.
Objective-C was/is a bit of an exception to this, as it's "funky" syntax could be a bit intimidating to developers coming from other languages - one of the motivations for Apple's switch to Swift was to address this.
From what I gathered in the previous discussion, it's not a drop-in replacement - they made several changes to OpenJDK already.