Sun wouldn't license the TCK under terms acceptable to the Harmony project, which is why it doesn't use the Java trademark. Sun wouldn't license Java SE to run on a mobile device, so Google used Harmony instead (and did not use the Java trademark). They were under no obligation to make it binary compatible. It wasn't compile once, run anywhere.

Also, just because your VM requires one extra step to run a binary doesn't mean it's not compatible.

The Java ME API that Sun wanted them to license would have been even less compatible with Java SE than the API they created. So much for write once, run anywhere.

It could also be phased in, along with the tax structure to support it. At the same time, phase out the programs it replaces.

Example - $2000/mo UBI, 50% flat tax, 25% VAT - start off at $200/mo, 5% flat tax, 2.5% VAT, reduce all other programs to 90%, reduce current total tax amount to 90%. Next year, go to 20% and 80%, etc.

Dalvik wasn't found to be infringing.

The Java SDK wan't GPL at the time, that happened after Google came out with the Android API.

They followed the license of the code base they did copy from, Harmony with the Apache license.

The interoperability was at the source code level. They copied the interface for most of 37 packages. None of the implementation code (other than a trivial rangeCheck routine) was found to infringe on Oracle's code.

Binary compatibility isn't the only kind, plus Android actually starts by being compiled to Java byte code before being translated to Dalvik byte code.

Yes, they did copy rangeCheck, inadvertently, which was so inconsequential that the damages were $0.

They also disassembled some "security files", but that wasn't anything that ended up in the Android API.

What other code do you claim they were found to have copied other than the declarations?

The exact same reasoning used by the CAFC to find the declarations of the Java API to be copyrightable would also find the details of any interface or protocol to be copyrightable, and the fair use arguments would make almost any unlicensed use of such protocols infringing, with no fair use defense.

This case isn't about copying software, it's about copying the interface requirements required to make your software able to interact with someone else's software.

It doesn't matter if you like Google or not, the principle being tested is extremely important.

Ironic, since the Android API covers more of the Java SE API than the Java ME API that Sun/Oracle wanted Google to use.

They refused to license Java SE to Google, which is the primary reason they wrote their own (including a portion of the Java API, copied from the Harmony version under the terms of the Apache license).

The only part of Oracle's code they were found to have infringed is the declarations, including the names of classes and method signatures.

They did not copy any of Sun's code. They started off with the Harmony version of the Java API, and followed the terms of the Apache license it was released under.

At the time they started, the Sun source code was not under the GPL. Sun wanted them to use Java ME, and wouldn't agree to let them use Java SE.

The license that Harmony was developed under allowed for development of an independent version of the Java API, under whatever license they wanted to release it as. The sticking point for the Apache Foundation was that the TCK, used to validate an implementation as conforming to the interface specification, couldn't be released as open source. Without that, you can't use the Java trademark on your product.

So Apache decided to just not get it certified as conforming.

Google never used the Java trademark. Their implementation of individual methods, and the documentation (as javadoc comments) was also found to be non-infringing.

What the CAFC found to be protected, that Google had copied, was the interface itself, the hierarchy of names and the structure of the relationships (e.g. class and interface inheritance). They also found that Google had infringed on the declarations from the Java API source code (which can only be written one way in Java if you want to describe the same API).

Why would you think that in a full implementation, taxes would stay the same? Add a flat tax income tax of 8.4% (not including the UBI itself, of course), and the $700/month would effectively be decreased to zero by the time you got to $100,000 annual income. You can adjust the UBI and rate to set the point where you want it to be neutral to an individual's tax rate.

With total individual income, you can also figure out where to set those values to make it revenue neutral (after taking into account the savings from replacing some of the safety net programs and, hopefully, reducing administrative overhead). You can also reduce the current tax rate by a fixed percentage while adding on a larger flat tax. That's also a way to phase in a UBI, e.g. set a target UBI and flat tax rate, then start off with 10% of each, increasing by 10% every year, for example.

So, first year with a $1000 UBI with 10% flat tax, you'd receive $100/month and a flat tax of 1% on all other income.

You could also go much bigger, $2000/month, flat tax of 50% (break-even point at $48000), but phase it in while phasing out the current tax. Fully phased in, you'd effectively pay no taxes with $48000 income, effective rate at $75000 would be 18%, and 40% at $250000.

a) the question is much better;
b) the case has ripened considerably;
c) the CAFC didn't fix their mistakes.

Sure, that's code. It describes a portion of an API, a class definition.

While the code can be copyrighted, Google's question asks if the API itself is copyrighted, or is it a functional "system or method of operation" and excluded from copyright protection by 102(b) (including the names).

If it is excluded by 102(b), then the code you wrote would also not be protected, because of merger (the 97% of the code that isn't declarations would still be protected).

It's not that "declarations" have some special powers, but that declarations in Java are, by design, required to be almost identical when describing the same API.

Google was a bit sloppy, Harmony less so. Ultimately, it didn't matter, the one method that was inadvertently copied (rangeChevk) was the ONLY code that was found to infringe, other than the declarations, and the damages were found to be $0.

Properly done, AFC would filter out the declarations from consideration, assuming Google is correct and the (abstract) Java API is not protected by copyright.

The fair use defense is for doing reverse engineering (which involves copying protected expression) for the purpose of discovering the "functional requirements for compatibility", which are not protected by copyright. 102(b), Sega

If you can find out the information another way, such as if the specifications are published and freely available, there's no need to do reverse engineering, and any copying of protected expression for reverse engineering purposes would not be fair use any longer.

What you do with that information is not restricted to creating compatible software, nor is it even about fair use at that point. That information is simply not protected by copyright.

If the Java API is a "system or method of operation", and is excluded from copyright protection by 102(b), why wouldn't I be allowed to re-implement the Java API if I want to?

If I rewrite Linux from scratch, without copying any source code, copying only the functional requirements, I won't be infringing even if I ignore the GPL.

If you make a movie with the characters Han Solo and Yoda from Star Wars, you'd be infringing on the copyrights on those two characters. They are not excluded from copyright protection by 102(b). It wouldn't matter if you used real actors or virtual actors.

The names are not copyrighted, though the characters are, and the names can be trademarked.

No, you're describing scenes a faire, which is related but different.

Oracle agreed in court that Google can freely use the Java language. That was not part of this case. Google's bytecode interpreter was not accused off copyright infringement. There were some patent issues, but those were resolved in Google'a favor.

The only other issue was the Java API, and in particular, the names. Are the names part if the unprotected functionality in the Java API?

"Authorship", which is what you can copyright, is predicated on choice. Choosing to write a program in Java is not a copyrightable choice Having made that one choice, the declarations for the Java API now can only be written one way.

102(b) excludes "systems" and "methods of operation" from copyright protection. If the Java API itself (the abstraction, apart from any specific description) is a "system or method of operation", then the declarations merge with that and are themselves excluded from copyright protection.

The lawsuit with Microsoft was about trademark and breach of contract. Sun failed in a copyright action against MS.

The case against Google is copyright, not trademark. Google never claimed that their platform was Java, as in the Java Platform, using the Java trademarks.

The linked page says Google uses the Java programming language (which they do) and implements parts of the Java API (which they do). None of that is claiming to be Java, nor do they use any Java trademarks.