A few thoughts:

1. This is a meticulously researched, marvelously analyzed, and brilliantly synthesized order done by a judge who has a keen grasp of not just the facts of the case but of those that really matter. As the opinion notes, this was a case of "first impression" - meaning that no published decision has ever dealt specifically with the precise question raised of whether APIs in themselves are protectable by copyright or not.

2. The developer community needed a definitive ruling that was almost impossible to arrive at in light of the controlling precedents of the Ninth Circuit (which are binding on the judge). Why? Because (beginning with the Johnson Controls case in 1989) the precedents had held that the "structure, sequence, and organization" (SSO) of any part of a software program were potentially protectable by copyright and that the issues had to be determined case-by-case to determine whether a particular component was or was not protectable. Thus, the best a trial judge can do in such a case is to make a fact-specific conclusion about the case immediately being tried, one which would have limited impact in the next case, where the parties could argue the same issue on different facts. Yet, while doing just that and limiting his ruling to the particular facts before him, Judge Alsup has provided a definitive and logically compelling approach to how such issues are to be decided where they concern APIs and copyright and such reasoning is, in my view, destined to be widely applied throughout the court system going forward. Lower court rulings can have a powerful impact through the sheer force of their reasoning. This is just such a ruling. It is rare to get this. It could not have been better timed on a vital issue affecting interoperability in our modern era.

3. Fundamentally, Oracle had been arguing that the SSO of its 37 API packages reflected creative expression of precisely the type that the Copyright Act was intended to protect. And it is true that API design choices reflect all sorts of creative forms of expression. To deal with this issue, the judge got down to fundamentals, with the key language found at page 35 of the opinion: "Much of Oracle’s evidence at trial went to show that the design of methods in an API was a creative endeavor. Of course, that is true. Inventing a new method to deliver a new output can be creative, even inventive, including the choices of inputs needed and outputs returned. The same is true for classes. But such inventions — at the concept and functionality level — are protectable only under the Patent Act. The Patent and Trademark Office examines such inventions for validity and if the patent is allowed, it lasts for twenty years. Based on a single implementation, Oracle would bypass this entire patent scheme and claim ownership over any and all ways to carry out methods for 95 years — without any vetting by the Copyright Office of the type required for patents. This order holds that, under the Copyright Act, no matter how creative or imaginative a Java method specification may be, the entire world is entitled to use the same method specification (inputs, outputs, parameters) so long as the line-by-line implementations are different" (my emphasis). Thus, even though the judge was forced by Ninth Circuit precedents to assess the SSO based on the particular facts before him only, he did so by finding, as a matter of fact, that only a 3% layer of code dealt with the SSO of the API packages, that this consisted entirely of names that had to be identical for compatibility purposes and of tasks that could be performed in only one way in order to work, and in this way - having established the factual setting as consisting entirely of elements he concluded were unprotectable under copyright - he could make a powerful and sweeping statement of law that will undoubtedly have a huge impact on future cases.

4. The judge finally had to deal with the claim that the SSO constituted a sort of taxonomy that has been held protectable under copyright in other circuit courts. Here, too, he addressed the issue based on fundamentals: assuming that the API design structure here constituted a taxonomy, he nonetheless held that it was above all a command structure that was unprotectable based on 17 U.S.C. section 102(b) (which categorically excludes ideas, concepts, etc. from copyright protection). Thus (at page 39): "In our circuit, the structure, sequence and organization of a computer program may (or may not) qualify as a protectable element depending on the 'particular facts of each case' and always subject to exclusion of unprotectable elements. Johnson Controls v. Phoenix Control Sys., 886 F.2d 1173, 1175 (9th Cir. 1989). Contrary to Oracle, Johnson Controls did not hold that all structure, sequence and organization in all computer programs are within the protection of a copyright." This is another way of saying that what might otherwise constitute protecable expression (e.g., the creative design choices made in developing the SSO of APIs) is nonetheless not protectable if it functionally operates within a computer program as a command structure. This, of course, is what APIs do and this means that his conclusion can be used as a powerful guide in all future API copyright cases. As a trial court decision, this ruling is not binding on other courts, yet it is compelling and persuasive, which can amount to the same thing (including in its impact on the Ninth Circuit when it considers this case on appeal).

5. Oracle here is like the Black Knight in Monty Python: as each limb of this case was lopped off, it dismissively would say "a mere flesh wound." Now that its case has been reduced to a final stump, it can continue to declaim but who will listen? Maybe a long shot on appeal but I wouldn't hold my breath. This is an unbelievable outcome that illustrates that great good can come even from lousy things that people do. The computing world owes a great vote of thanks to Judge Alsup: the cause of interoperability has won a huge victory.

General advice for legal questions: it's fine to ask these sorts of questions, but please, for the love of god, don't listen to anyone who isn't a lawyer or who hasn't gone through something very similar to what you're going through. And, even in those cases, take their advice with a HUGE grain of salt. (If you disagree, please see below, where OP is variously advised to (1) commit unlicensed practice of law [serious repercussions], (2) commit fraud, (3) waste money, and (4) likely destroy his own case.)

As a lawyer (who doesn't have anywhere near enough facts to give you anything close to competent advice), my advice is to find a lawyer to represent you. If you can't afford one, try the EFF or similar organizations. If they won't take you, find a legal clinic nearby. If you're in the bay area, you have have two of the best lawschools in the country within bicycling distance of you (UC Hastings isn't half bad either...). They have legal clinics, generally led by highly respected and knowledgeable faculty that are happy to have cases like this.

Unless you really don't want to fight this, go get a lawyer who knows what he's doing. If you don't want to spend a lot of energy, possibly a lot of time, and likely some money, just roll over now. But, don't half-ass it and try to do this yourself. By blowing at least two deadlines, you've already shown you're not up for it.

I was an engineer on the Nook team. It isn't possible for the device software to change text of books.

Most likely the author or conversion service took the Kindle edition, ran a search and replace for 'Kindle' and there you have it.