Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Asmodae writes "Judge Alsup in the Oracle vs Google case has finally issued his ruling on the issue of whether or not APIs can be copyrighted. That ruling is resounding no. In some fairly clear language the judge says: 'So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API.'"

Just about everything is safe. Ruling APIs copyrightable would have been a catastrophe of earth-shattering proportions. It is very much a good day for software. And, of course, Oracle has been handed their balls on a platter, though I'm assuming they will appeal this.

How could you possibly call an API if the argument structure was copyrightable? Buy a license for every single API set that was delivered with your machine, associated with every software product, or hosted somewhere on the web?

In a world of stupid IP laws, at least this judge gets it. (Which surprises the hell out of me).

It would have been a disaster. Just about every operating system vendor, programming toolkit, developer of document formats and protocols would have to amend licenses to grant developers the rights to access the outward facing layers. Big guys like Microsoft could just crush projects like Wine. It would have been absolute chaos and would have created years of uncertainty, not to mention the fact that as the EU has already ruled APIs cannot be copyrighted, it would have created a monstrous rift in IP rules between Europe and the United States.

I agree, but what makes me ponder is that the European court said to allow copyright on an API would allow monopolizing ideas. Isn't that what allowing business rules patents does? Ie patent ideas? Hopefully, somehow, Alsup's logic pervades into the business rule / software patent realm and blots out this travesty of justice too.

On the other hand, the EU has had a hard time finding a position on software patents, and the key difference is that copyright is automatic, patents have a specific set of conditions to be granted and go through a review process (even if it's not a terribly *good* review process)

Permitting the *automatic* granting of monopolies on ideas would be a disaster

It's widely recognised legally that awarding a patent IS giving a monopoly on the use of an idea, BUT for a limited time, and with other requirments such as disclosure. What the European court seems to have the most trouble with is an entity getting all the benefits of a patent by invoking some other form of "Intellectual Property" that doesn't have the same limitations. That's not as good as excellent laws in each specific area of IP, but at least it's something.

It's widely recognised legally that awarding a patent IS giving a monopoly on the use of an idea

I was under the impression that a patent cannot be used for an idea, but the specific implementation of an idea. You could get a patent for inventing a hoverboard that is powered by anti-gravitons and I wouldn't be in violation of your patent if I invented one that is powered by the hearts of orphan children, even if they looked essentially the same and behaved the same. They're the same idea, a board that can hover in the air, but different implementations.

Correct, the real trick is to write your patent to be specific enough to be granted, but broad enough to cover more than your specific implementation of your idea.
Meaning a good patent attorney could craft an anti-graviton hoverboard patent to also cover an orphan heart one.

I agree, but what makes me ponder is that the European court said to allow copyright on an API would allow monopolizing ideas. Isn't that what allowing business rules patents does? Ie patent ideas? Hopefully, somehow, Alsup's logic pervades into the business rule / software patent realm and blots out this travesty of justice too.

Patents do expire [wikipedia.org], where copyright [about.com] has been continuously extended (in the U.S. anyway) to near eternity.

On many days, the San Francisco courtroom where he presided was more like a computer science classroom. Alsup acknowledged during the trial that he had learned about Java coding to better prepare for the case, and it showed. On a daily basis, he would deftly query the lawyers and expert witnesses on the structure, sequence, and organizations of APIs to assist the jury in understanding the key facets of the copyright phase of the trial.

This is why I have respect for Judge Alsup. In order to apply the law in a complex engineering-related case, he worked to learn the subject matter in order to properly apply the law to the material. That's how I expect every Judge should apply the law rather than just sit and "trust the experts" per-se.

he worked to learn the subject matter in order to properly apply the law to the material

Being a hobbyist hacker himself helped a bunch too.

Generally, we have people who don't understand the material arguing before an arbitrator who doesn't understand the material to get a decision from a group of people who don't understand the material. We call these decisions 'precedent'.

perhaps Google just temporarily amended "Don't Be Evil" to "The End Justifies The Means" and bribed the everloving fuck out of this particular judge?

i do wonder how the system works, but in this case i think the judge just rightly saw that Oracle's case was ridiculous and dangerous (including to themselves) and would likely be turned over on appeal anyway.

There's a good chunk of the legal back and forth over at groklaw if you're interested. I spent probably a good hour reading testimonies just for fun. Turns out, the judge was competent, and the claims Oracle were making made perfect sense, but only to themselves.

In a world of stupid IP laws, at least this judge gets it. (Which surprises the hell out of me).

That's what happens when you have a judge who programs as a hobby. It would be great if all lawsuits that affect an entire industry like this had to be decided by a judge familiar with the industry. Not going to happen of course, but it would be awesome if judges deciding software patent cases had to have some sort of programming background.

In many industries, that requirement might force the judge to recuse themselves because there are few opportunities to acquire that experience without being significantly involved with one of the litigants. Low barriers to entry for learning programming and the large number of players in the industry make it pretty easy for a judge to have that experience without being compromised. That would be harder in the petroleum, telco, or broadcast industries.

It would be great if all lawsuits that affect an entire industry like this had to be decided by a judge familiar with the industry.

yBe careful what you wish for. If you have any experience in, say, hydraulic fracking for natural gas expansion, it's because you worked for a company that did it. Assuming you left on somewhat-amiable terms, you'll harbor generally-kind feelings to the company in particular and the industry in general, if only to justify to yourself why you did it. In this case, it turned out great - but mostly because you can program as a hobby, which isn't possible for banking, fracking, telco, etc...

Imagine the worst of regulatory capture (when the only people with sufficient experience to regulate an industry are the ones being regulated), but with much broader consequences. Not pretty. There's a reason our judges are supposed to be experts in law, and the lawyers are supposed to bring in expert witnesses to explain the relevant details of the subject to him.

His point is valid, though. The proper example to cite is government regulators. There's a revolving door between industry and the regulatory bodies who govern the industry, and as such, you get a lot of backroom deals and agents looking the other way.

If the primary criteria for familiarity with a topic is former employment, expect most judges to become industry-captured much the same way.

I'm not saying I *want* the judges to be ignorant of the topics they preside over, but having well-informed judges is a sticky problem.

1. regulatory roles don't pay as much as industry roles of equal skill level2. in general, regulators don't actually perform the tasks they regulate3. it's widely accepted that on the job skills are just as important, if not more important than the schooling received in order to get the job

given the above, how on earth can you regulate a complex industry without people who have worked and continue to work in that

Even if they appeal, the appellate judges will get a good education from reading the current decision, so they might do the right thing. I have to say, I doubt this would have happened if Google did not exist.

And, of course, Oracle has been handed their balls on a platter, though I'm assuming they will appeal this.

The judge has clearly anticipated the appeal, even devoting an entire section to explaining how utterly trivial the 9 lines of actually copied code are, and to describing, for the benefit of an appeals court, how ridiculously Oracle has exaggerated the claims around them--remember Oracle tried to claim that by copying the 9-line (including closing braces) implementation of rangeCheck, Google was able to bring Android to market sooner. Goddamned fools.

This ruling and opinion looks very water tight. If it goes up through the appeals process, I think it is likely to be affirmed the whole way up the food chain.

The ruling goes way beyond even settling the issue of copyright over APIs, but even goes so far as to say that EULAs that restrict the use of APIs are dead in the water and are void in terms of enforceability. This ruling does strengthen the copyright claims of people who write up API libraries as the original implementation of a particular API function is expressly covered under copyright law, but the way data is passed between two different software packages simply can't be copyrighted at all.

The only way this is going to be overturned is to place a stamp of copyright protection on API interfaces directly and hand this whole case to Oracle, giving them everything they ever wanted and more. I just don't see any higher court will do something like that.

The only way this is going to be overturned is to place a stamp of copyright protection on API interfaces directly and hand this whole case to Oracle, giving them everything they ever wanted and more. I just don't see any higher court will do something like that.

I don't see it happening, either, especially as it runs contrary to the interoperability clauses contained within the DMCA [copyright.gov]. If we are granted special privileges to reverse engineer copy protected works for the purposes of interoperability, surely it is a difficult sell that using an API could be construed as infringing. There is nothing I saw at a glance that explicitly says so, but it is pretty clear that cross-compatibility of programs is considered important, and any ruling to lock down APIs is a compl

Mostly. If you read the judge's ruling (and the observations thereof on Groklaw), the judge makes it clear that this applies to the Java API SSO because the java package SSO is essential to method invocation. (i.e. you need to import java.lang.String to access the string methods or need to explicitly invoke the class methods using the full package hierarchical path). The judge leaves open the possibility that an API's SSO would be copyrightable in a language where conforming to that SSO was not required for API interoperability, where the SSO was expressive only and not functional in any way.

Mod parent up. It's important to notice that the judge did *NOT* rule that APIs couldn't be copyrighted. He was VERY careful to say:

This order does not hold that Java API packages are free to use without license. It does not hold that the structure, sequence and organization of all computer programs may be stolen. Rather, it holds on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act.

His ruling is VERY specific to Google's use of Java and is NOT a blanket declaration about copyright of APIs.

It's possible that in a future court case a different judge might take this ruling and turn it into a ruling that applies ot all APIs, but that's not what this ruling does.

It would have been bad, but not the end of the world as people keep believing. Calling APIs would have almost certainly been a fair use exemption and pretty much no vendor is likely actually sue over it even if it wasn't. You might have had some issues calling undocumented APIs, and stuff like WINE and SAMBA could have had issues if Microsoft had felt particularly inclined to do so.

Bullshit. If copyright could be extended to APIs, it means whoever developed those APIs automatically can dictate how and by who they are accessed. I love the comment "WINE and Samba could have had issues". Even in your own "this ain't a big deal" post you admit, in a minimalistic sort of way, that Microsoft could potentially have had the power to invoke copyright over the work-alike APIs. For "problem" read "shut down".

The biggest problem with this case is that both sides need to lose. Dalvik needs to be stopped, and copyrighting APIs needs to be stopped, more importantly someone needs to take the execs at Google into the alley out the back and beat them until they promise to stop doing this kind of shit. They knew damned well what they were doing and they've rolled the dice at terrible risk to everyone and spent millions of dollars getting into a pissing match they never should have started. If they'd just licensed Java in the first place none of this would have been necessary.

1. They don't need to license Java. It's a programming language, and cannot be copyrighted (this is long standing in US and international IP law). And, as we see, they don't need to licence the JVM if they go out and build their own virtual machine.2. How is what Google did with Dalvik one bit different than what the GCJ team did allowing Java source to be compiled to native machine code? If Google is so evil for daring to develop it's own virtual machine, then the Gnu folks must be even worse for allowing a Java developer to bypass the JVM entirely.3. It's a free country. Don't use Dalvik if you don't want to. Maybe somebody needs to take you into the alley and beat a little respect for free enterprise into you.

Wine is just a single piece of software that is safe. This would have been huge if it had gone the other way. It could have been using all the way up to the point of processor instruction sets being illegal to use unless you paid a license fee.

Hell, it would have meant Open/LibreOffice and just about anyone with software or libraries that can read or write the old Word 97-2003 formats would be insanely vulnerable. The distance between an API, a document format or a protocol is no distance at all, and anyone who didn't have a license to write Word-compatible files could be nailed to the wall.

Keep in mind two things: First, this is a district court judge. Surely he won't have the final say on an issue of this import. It will most likely be decided at the Court of Appeals or Supreme Court level.

The other interesting thing is how this could affect the GPL. As I understand it, the difference between the GPL and say, the LGPL, is that if you write code that uses GPL libraries, your source code must also be GPL'd, even if you don't distribute those libraries with your code. (i.e. your installation instructions direct users to download and install the libraries themselves.) The way it works is, your code is written to the API specified by those libraries and you are therefore bound by the license terms of those libraries. If API's are not covered by copyright, then you wouldn't be bound by those license terms, and so effectively there's no difference between the GPL and the LGPL.

The other interesting thing is how this could affect the GPL. As I understand it, the difference between the GPL and say, the LGPL, is that if you write code that uses GPL libraries, your source code must also be GPL'd, even if you don't distribute those libraries with your code. (i.e. your installation instructions direct users to download and install the libraries themselves.) The way it works is, your code is written to the API specified by those libraries and you are therefore bound by the license terms of those libraries. If API's are not covered by copyright, then you wouldn't be bound by those license terms, and so effectively there's no difference between the GPL and the LGPL.

You're misunderstanding the licensing issue with GPLed libraries. The licensing issue is that by linking against the GPLed library, you are using the actual GPLed code as part of your product, not just the headers, thus making your code a derivative work of that GPLed code because it depends on that code for correct operation. Now there is some room for debating whether or not that really is the case, but that's the basic argument.

This case, by contrast, says that the headers themselves cannot be copyrighted. What this means is that you are free to do what both the BSD and GPL folks seem to do on an almost daily basis—take some library (or set of functions within a library) that is under one license and reimplement it under a less/more restrictive license, keeping the same basic interface so that code can be compiled against either version of the library and still work correctly.

You're misunderstanding the licensing issue with GPLed libraries. The licensing issue is that by linking against the GPLed library, you are using the actual GPLed code as part of your product, not just the headers, thus making your code a derivative work of that GPLed code because it depends on that code for correct operation.

You're missing my point. I'm talking about distributing code that links either dynamically to user-installed GPL libraries, or even source code which the user compiles (which you don't want to release under GPL, but rather, say, BSD or some other license.) So you won't be actually distributing the GPL libraries at all.

If what you mean to say is that you've created a derivative work by writing code that links to these libraries, that is equivalent to saying that the APIs that the libraries implement is copyrightable. I.e. writing code that meets the API specifications for a specific set of libraries is creating a derivative work is equivalent to saying the APIs enjoy copyright protection. There's no difference. This is what the judge rejected.

Note that when pressed on the issue, the FSF will waffle on the "dynamic linking" point. I think they understand it would only hold up in court under some specific circumstances. So few libs are GPL that it is hardly an issue.

I have heard disagreeing positions from GPL advocates on that very point of dynamic linking to libraries which the user installs separately. And I don't think there are so few libraries that are GPL'd. It is a very significant point.

I was trying to write a counter-argument to your other post in this thread, and then stopped. You do raise a fascinating point.

Stallman's own words [wikipedia.org] seem to indicate that one would put a library under GPL (instead of LGPL) so that it cannot be used by proprietary software, even through dynamic linking. However, the only "use" of the GPL library by the proprietary software in such a case would be the API interface. But without copyright protection of the API, maybe it is as you say: a GPL library simply becomes a LGPL library.

Looking at this from another direction, what happens if someone writes a proprietary library that duplicates the function of a GPL library? Does that infringe? I don't think so, because it doesn't use the GPL library, it replaces it. Now, what if someone (maybe even the same person or company) writes a proprietary program that uses this proprietary replacement? Does either the program or the proprietary library infringe? Again, I don't think so. Now for the really interesting part: what if someone runs the proprietary program with the now plug-compatible GPL library? Is anyone infringing? If so, who?

Oracle has nothing to show for all of its efforts> For those who have depended on the self-described patent expert for your understanding of this case . . . well, maybe now you will know better than to trust a paid spokesman.

Basically: "this court doesn't matter, there will be an appeal" mixed in with a healthy lack of recognition that APIs have been de facto uncopyrightable for years, it's just never been said by a judge before.

Having read the entire order (and having followed this case from near the beginning), all I can say is that I *wish* that all orders were so well prepared and presented. It appears to close all avenues for appeals, and I think the best 'showing' of any parties to this case has been Judge Alsup. He kept control of a tough case, and in my opinion, all his rulings have been well thought out, and his 'go-the-extra-mile' attitude has made this process a clear win for all (except Oracle).

How exactly is it a win for Oracle? They now have a competing VM that can run Java code. Considering Android's position in the mobile market, I'd say for Oracle this means Java goes into a slow eclipse.

It's a partial win for Oracle because now they too can use APIs without fear of lawsuits. Also, it helps the Java language because if this ruling went the other way then other companies would be motivated to move away from Java for fear of lawsuits from Oracle.

Meet Alice. Alice thinks she has the right to shoot anyone she wants in the head. In particular, Alice wants to shoot Bob. Bob objects, and Alice and Bob take their dispute to court. After a long and vexatious trial, Alice loses.

Charlie, Alice's estranged ex-boyfriend, is standing outside the courtroom, menacingly brandishing a gun. "Alice", Charlie says. "You lucked out!" "What do you mean," Alice exclaims. "I just lost my case!" "All is lost, for now I can't shoot Bob in the head, or anyone else I don't l

But Java isn't really a money maker for oracle, it never was going to be. They sell databases, big fancy expensive databases. If they suddenly find out that APIs are copyrightable all their database management software, that uses linux/windows copyrights for all of the UI elements to manage the databases, all of the library api calls they use for the graphics system to visualize the database etc. All of their networking hooks, probably someone elses APIs...

Sounds like he's figuring "Oracle has been prevented from shooting themselves in the foot with what they thought was a pistol but is actually just an aimer for an orbital laser cannon. In the long run they're better off, so really it's a win for them. Along with everyone else, of course."

Having read the entire order (and having followed this case from near the beginning), all I can say is that I *wish* that all orders were so well prepared and presented. It appears to close all avenues for appeals, and I think the best 'showing' of any parties to this case has been Judge Alsup.

This this this. Most of those old fart judges would have thrown their hands up in exasperation at trying to understand all this computery gobbledygook, not written an order that explains the difference between public and private or instance vs. static methods. Couldn't have gotten a better judge for this case.

I'm sorry, but what planet have you been living on for the last 20 years. Our supreme court (with special kudos for justices Kennedy and Scalia), just defined corporations as people with the first amendment rights to buy elections. Judges across the land have been giving large corporations anything they damn well want without the slightest concern to the damage done to society, and I for one am thrilled that this judge actually had;

1. A positive measurable IQ.
2. A sense of the urgency of this decision.
3. A grasp of the implications facing society and business if the wrong decision were made
4. And a basic idea just how bogus Oracle's claims were.

It almost gives me faith in the system when someone does something so right, and for the right reasons. Now someone needs to buy Oracle a speedo with an ice bag in the front... take down some of that pain and swelling...

Really... what are some long term consequences of this decision? Could Oracle decide that if it can't have its way with Java, then nobody should have their version of Java, and simply stop making new versions? What would such a decision mean for Java?

"In order to declare a particular functionality, the language demands that the method declaration take a particular form," notes Alsup (emphasis in original).

Indeed, this is just so. And you can't copyright "functionality"; that's akin to copyrighting a concept, which is not what copyright is about. Copyright is about protecting implementations of concepts, and those are still protected. But a programming language requires a rigid codification of the concept itself.

Oracle's response made me chuckle a little...

"The court's reliance on "interoperability" ignores the undisputed fact that Google deliberately eliminated interoperability between Android and all other Java platforms," the company said in a statement issued this afternoon. "Google's implementation intentionally fragmented Java and broke the "write once, run anywhere" promise."

That's really immaterial to the reasoning for why an APIs aren't protected under the Copyright Act in the first place. It would be relevant if "interoperability" were a defense against copyright infringement, but it's not, since the item in question wasn't protected in the first place.

Just because my implementation of fopen() breaks programs that depended on your implementation of fopen() that doesn't suddenly mean that your declaration of a function called fopen() is protected and my identical declaration is infringing. This would imply that copyright infringement claims based on APIs would suddenly be dependent on some kind of compatibility test.

And on that note, it was that last line that made me chuckle. Brings to mind something about ships and sailing, or barn doors and horses.

The entire summary of ruling is worth reading - it lays it out concisely yet clearly.

SUMMARY OF RULING

So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different. When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.

It is true that the very same functionality could have been offered in Android without duplicating the exact command structure used in Java. This could have been done by re-arranging the various methods under different groupings among the various classes and packages (even if the same names had been used). In this sense, there were many ways to group the methods yet still duplicate the same range of functionality.

But the names are more than just names — they are symbols in a command structure wherein the commands take the form

java.package.Class.method()

Each command calls into action a pre-assigned function. The overall name tree, of course, has creative elements but it is also a precise command structure — a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted. Duplication of the command structure is necessary for interoperability.

So; API is a "system of method of operation", and hence non-copyrightable.

That interoperability is at the heart of the command structure is
illustrated by Oracle's preoccupation with what it calls "fragmentation,"
meaning the problem of having imperfect interoperability among platforms. When
this occurs, Java-based applications may not run on the incompatible platforms.
For example, Java-based code using the replicated parts of the 37 API packages
will run on Android but will not if a 38th package is needed. Such imperfect
interoperability leads to a "fragmentation" -- a Balkanization -- of platforms, a
circumstance which Sun and Oracle have tried to curb via their licensing
programs. In this litigation, Oracle has made much of this problem, at times
almost leaving the impression that if only Google had replicated all 166 Java
API packages, Oracle would not have sued. While fragmentation is a
legitimate business consideration, it begs the question whether or not a
license was required in the first place to replicate some or all of the command
structure. (This is especially so inasmuch as Android has not carried the Java
trademark, and Google has not held out Android as fully compatible.) The
immediate point is this: fragmentation, imperfect interoperability, and
Oracle's angst over it illustrate the character of the command structure as a
functional system or method of operation.

[...] In Sony, the accused product implemented only 137 of the
Playstation BIOS's 242 functions because those were the only functions invoked
by the games tested. Connectixâ(TM)s Opening Appellate Brief at 18, available at
1999 WL 33623860, (9th Cir. May 27, 1999). Our court of appeals held that the
accused product "itself infringe[d] no copyright." Sony, 203 F.3d at 608
n.11. This parallels Google's decision to implement some but not all of
the Java API packages in Android.

Oracle's obsession over fragmentation was turned against them because
it showed they agree that the APIs are functional and hence
not copyrightable. They seem oblivious to the fact that they were
hoist by their own petard. Like the dinosaur they are, there is
a long time delay before signals get transmitted to their tiny brains.

No, "J++" was a contract violation. Microsoft licensed Java from Sun and agreed to keep it compatible with Sun Java. MS changed enough things to break it and Sun sued to prevent them from distributing their bastard Java.

There was another lawsuit where Sun sued Microsoft for antitrust violations (and settled for like a billion dollars), but this was several years later.

Thank you for your pedantry. While decimate did originally refer to the removal of every tenth part of something, today the meaning is extended to include the destruction of any large proportion of a group, and this definition has been accepted for quite a few decades... going back to at least WWII.

Look the word up in practically any modern dictionary... while your 1/10th definition will probably be there, it will probably have an (archaic) or (obsolete) qualifier on it. At the very least, the newer d

Look the word up in practically any modern dictionary... while your 1/10th definition will probably be there, it will probably have an (archaic) or (obsolete) qualifier on it.

OED lists 4 definition of the verb.
All four explicitly have to do with removing 1 in 10. Two of these four are marked "obs."
The last of the four has as second meaning (b) attached marked as "rhetorically or loosely"; only that is not explictly in reference to 1 in ten.

The problem is that modern use has deviated from the original meaning of the word (which meant to reduce by 1/10th... not *to* one tenth, but *by* 1/10th... it was a punishment in to the Roman Army in which one of every 10 soldiers was killed)

Modern usage would have you think that it means to reduce to near nothing, rather than simply losing 10%.

You must have spitting fire when GCJ created the ability to compile Java to native machine code.

Java is a language, just like C, C#, PHP, Cobol, and all the rest. If someone wants to write something that compiles to native machine code, to some other language or to some other VM, then so what? This all happened because Sun, and later Oracle, thought they had a level of control it now is shown they do not. This whole "purity of Java" line is bunk. It's like saying "the only true C is C compiled to a PDP-7".

Besides, your Java code is, for the most part, just a cross-compile away from Dalvik. The situation is hardly that dire.

You must have spitting fire when GCJ created the ability to compile Java to native machine code.

While I don't like GCJ, the reason for that is that it has proved incapable of building/running any application I'm interested in. I'm not just interested in Java as a (fussy and bureaucratic) language, I'm interested in it for the libraries, frameworks and applications that are written in it. That ecosystem (which happens to be pretty strongly security-related in my case) is critical; without it, I'd use something nice like a scripting language...

It's possible that the next time something like Java is being considered as an open-source target that the owners will carefully plan and consider how they can make it available without the same thing happening. But it's far, far more likely that they just won't bother at all.

Java failed in it's promise of Write Once, Run Anywhere a long time before Dalvik came to the scene. It's more like Google saw how fucked up Java was (with SE, ME and EE), and decided to do their own version , you know, like how Microsoft has.Net.

Actually "Write Once, Run Anywhere" works - I know, back in the day I would write Java on a 16-bit Windows and run it on a 64-bit Irix machine. Stuff like that has continued for me throughout the years (these days I write on Mac OS X 64-bit and deploy to Linux, Windows 7 32 and 64), and I've never had a problem so far as long as I've only used the proper APIs and not implementation-specific class.

Hence, my own experience over 17 years with Java has been that WORA actually works. I'd be interested in hearing your experience where you used a standard Java library and it didn't work. Otherwise, you are repeating incorrect hearsay.