Daily Deal: Complete Java Programming Bootcamp

from the good-deals-on-cool-stuff dept

Java is one of the most widely used paltforms and programming languages. It's easy and adaptable. Grab the $69 Complete Java Programming Bootcamp and you'll be on your way to mastering Java. The 10 courses will teach you how to build applications, how to create UIs with JavaFX, how to master data structures and algorithms and much more.

Note: The Techdirt Deals Store is powered and curated by StackCommerce. A portion of all sales from Techdirt Deals helps support Techdirt. The products featured do not reflect endorsements by our editorial team.

Filed Under: daily deal, java

Appeals Court Doesn't Understand The Difference Between Software And An API; Declares APIs Copyrightable

from the total-failure dept

We sort of expected this to happen after the appeals court for the Federal Circuit (CAFC) held its oral arguments back in December, but CAFC has now spit at basic common sense and has declared that you can copyright an API. As we noted, back when Judge William Alsup (who learned to code Java to better understand the issues in the case) ruled that APIs were not subject to copyright protection, his ruling was somewhat unique in that it was clearly directed as much at an appeals court panel who would be hearing the appeal as it was at the parties. Alsup rightly suspected that the judges on the appeal wouldn't actually understand the issues as well as he did, and tried to break it down clearly for them. Unfortunately, the three judge CAFC panel did not pay attention. The ruling is so bad that legal scholars are suggesting that it may be as bad as the horrific ruling in the Garcia case.

It's tragic that this case ended up before the CAFC. It shouldn't be there. It should be before the 9th Circuit (who issued the Garcia ruling, so it's not like they're particularly good either...), but because this case started out as a patent lawsuit, even if the patent stuff went away early, the appeals went to CAFC. CAFC is already famous for its maximalist bent on patents, and so it's perhaps not too surprising that it takes a similar view towards copyright. Or, as law professor James Grimmelmann astutely notes: "Is there any body of IP law that the Federal Circuit hasn't done its best/worst to screw up?" The answer, James, may be publicity rights. But, give them a chance and we'll see what it can do there too...

As for the ruling itself... well... it's bad. The court seems to not understand what an API is, confusing it with software functionality. It also appears to misread Judge Alsup's ruling, thinking that he's mistakenly using a fair use analysis to determine whether or not something is copyrightable. But that was not the basis of Judge Alsup's ruling. He very specifically noted that the "command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted." The CAFC panel doesn't seem to understand this at all. In case you're not readily up on your Section 102 knowledge, it covers what is copyrightable subject matter, and (b) is pretty explicit:

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.

Got that? Well, CAFC doesn't seem to get it. At all. They basically seem to think that because the API is "big" it must therefore be copyrightable as a "literary work" even though -- as Alsup rightly pointed out -- it's nothing more than a "system or method of operation" which 102(b) clearly states is uncopyrightable. And yet, CAFC spends many pages arguing how an API is not unlike a "literary work", ignoring its intent and purpose. CAFC argues that the various names that Sun/Oracle used for naming things in the API are subject to copyright because they're "creative." Yet, as Grimmelmann against notes, if that's the case, Brian Kernighan should sue Oracle for its "copying" of his creative choices in "int," "short," "long", "float", "double", and "char."

The original ruling pointed to the ruling in Lotus v. Borland, which found that pull down menus in an app weren't copyrightable. But here, the CAFC rejects this (in part) by saying that a big difference is that the "source code" wasn't copied. But in that case, the menu structure and names were copied -- which is basically the same thing that was copied from the Java API. But the CAFC judges don't even seem to realize that.

It seems fairly clear that the CAFC judges don't understand the difference between an API and software. And thus they make a decision that makes no sense. There is no distinction recognized when it comes to the functionality of an API and how it's entirely different than the purpose of the software itself. This is especially clear towards the end, in which the CAFC ruling misrepresents some discussions on whether certain functionality is best protected by patents or copyright. But the problem is that they misinterpret statements people are making about APIs, thinking that those statements were made about software as a whole. This is just a flat-out fundamental misunderstanding of what an API is, assuming that it's just software. Take the following example:

Many of Google's arguments, and those of some amici, appear premised on the belief that copyright is not the correct legal ground upon which to protect intellectual property rights to software programs; they opine that patent protection for such programs, with its insistence on non-obviousness, and shorter terms of protection, might be more applicable, and sufficient.

But that's not true. No one is arguing that patents are more suitable overall for software. In fact, many in the software field have long argued the exact opposite. What they're saying is that copyright is inappropriate for APIs -- but the CAFC judges don't seem to be able to distinguish between APIs and software. In fact, they're so confused that they throw a bogus parenthetical "software" before "interfaces" in quoting Google:

Google argues that "[a]fter Sega, developers could no longer hope to protect [software] interfaces by copyright . . . Sega signaled that the only reliable means for protecting the functional requirements for achieving interoperability was by patenting them."

Note that "[software]" thrown in before interfaces? Google is talking about whether APIs -- "application programming interfaces" -- are copyrightable. Not whether or not software is copyrightable. And yet the CAFC doesn't even seem to realize this. Ridiculously, CAFC then uses its own misunderstanding and misquote, and points to some of the (many) arguments where people argue that patents are inappropriate for software to dismiss Google's argument about APIs. It honestly doesn't realize that it's comparing two totally different things. What lots of people agree on: software shouldn't be patentable and APIs shouldn't be copyrightable, but software can be copyrightable and API functionality may be patentable. But by confusing APIs and software, CAFC totally misreads both arguments.

This is a disaster all around. Of course, it's not over yet. Google can (and likely will) seek a review of this ruling, either en banc or by petitioning the Supreme Court. And even if that doesn't happen, the CAFC ruling tosses it back down to the district court for an entirely new battle about whether or not -- if the API is covered by copyright -- Google's use was fair use. So, there are still a few more years (and many more millions) to be thrown at this before there's any real conclusion. In the meantime, CAFC has mucked up another form of intellectual property law through a basic (and near total) misunderstanding of technology.

Filed Under: api, cafc, copyright, java, patents, software
Companies: google, oracle, sun

Appeals Court Considers Overturning Ruling That APIs Can't Be Covered By Copyright

from the and-on-and-on-it-goes dept

Back in May 2012, Judge William Alsup (yes, he's popular today) issued a very good and very thorough ruling explaining why APIs could not be covered by copyright. Alsup, who claimed he learned to program in Java to better understand the technical details of the case, went into a fair bit of detail in his ruling, which looked like it was clearly designed to explain basic programming concepts to an appeals court who would surely be hearing the case -- and almost certainly with judges who had less (if any) programming knowledge. The appeal was officially heard by the Federal Circuit appeals court (CAFC) today and there are some reports suggesting that the judges are skeptical of Alsup's ruling and may be leaning towards overturning it. Reading through some of the details it appears that at least one judge is clearly on Oracle's side in believing that APIs can be covered by copyright, while it's not as clear where the other two judges on the panel sit.

Given CAFC's history as exceptionally supportive of locking up knowledge and information on the patent side, it wouldn't be terribly surprising if they did so as well on the copyright side (side note: while, normally, copyright cases should travel up the local appeals court route, since this case started as a patent case, even though it ended up as a copyright case, apparently the appeal still goes to CAFC, the court that hears all patent appeals). This is yet another issue with having a court like CAFC, which has long appeared to be captured by those who support a maximalist view of intellectual property.

Still, oral hearings in appeals are not always indicative of how judges are leaning. Reading the tea leaves there is often quite dangerous. The hearing sometimes focus on tangents, or involve judges really trying to test out a particular theory, and final rulings may be more strongly based on the written filings (and, sometimes, briefs from amici -- of which there were quite a few in this case). This case still has a long way to go, but hopefully the appeals court recognizes the careful level of detail that judge Alsup went into in determining that APIs do not deserve copyright protection.

Filed Under: android, api, cafc, copyright, java
Companies: google, oracle

Google Asks For $4 Million In Legal Fees From Oracle

from the sliding-backwards dept

Having lost its patent/copyright case against Google in somewhat spectacular fashion, Oracle is now facing the possibility of having to also pay Google over $4 million in legal fees. Google has submitted its calculation of legal fees that it's seeking from Oracle, and it totals up to $4,030,669. Of course, this case is heading for appeal, so this number may be meaningless. However, it does suggest that Oracle -- which once seemed to believe this case might bring it billions of dollars -- may quickly discover that it's costing an awful lot instead...

Filed Under: api, appeal, damages, java
Companies: google, oracle

Even The Judge Wonders What Oracle Is Up To As It Asks For $0 In Copyright Damages From Google

from the procedural dept

Having lost both its patent and copyright claims against Google in somewhat spectacular fashion (remember when it was claiming billions in damages?), Oracle recently agreed in court that it was fine with receiving $0 in statutory damages for the short snippets of code that were copied. This even took the judge by surprise, who asked if there was a "catch" he should be aware of. The issue is one that is really more procedural than anything else: everyone realizes that the only thing that matters now is what happens in the appeal, and if Oracle happens to win the appeal, it can revisit the damages question. Either way, however, it is a bit symbolic to see Oracle "accept" $0 in damages. And, of course, there is still one more part to this round in district court, which is that Google is expected to seek attorneys' fees from Oracle as well -- meaning that Oracle's plan to get billions from Google may turn into not just a loss, but a really, really expensive loss.

Filed Under: api, appeal, damages, java
Companies: google, oracle

Judge Delivers Thorough And Complete Smackdown Of Oracle's Copyright Claims

from the a-bit-narrowly-focused dept

Well, well. A few weeks ago, the jury in the Google/Oracle lawsuit ruled that Google infringed on a very small amount of Java API, but as we noted it was still an open question (and one for the judge to rule on) whether or not APIs were even eligible to be covered by copyright. In the second phase of the case, the jury completely rejected the idea that Google had infringed on Oracle's patents. So all that left was the 37 APIs. And that tiny "win" for Oracle is now gone as well, as the judge has ruled that those particular APIs are not covered by copyright:

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.

As some have pointed out the ruling is somewhat narrowly focused just on these 37 APIs, but the principles involved in why those 37 APIs are not copyrightable certainly will apply to plenty of other APIs as well. The ruling itself (embedded below) is pretty thorough and detailed. We had noted earlier that Judge Alsup had admitted that he'd learned to code Java in order to better understand the case (and that he'd had a history of knowing other coding languages as well) -- and it shows. Rather than using braindead broad analogies that don't make much sense, as we see all too often in court rulings, Alsup gets to the heart of the matter and clearly understands what an API is and how it works. His ruling is actually a decent primer on some parts of code for those who have never coded.

From that, Alsup points out just how ridiculous this entire case has been -- and specifically notes that he's explaining the level of ridiculousness of Oracle's position for the benefit of the appeals court who will surely hear this case once Oracle appeals (and which almost certainly will be staffed with judges not nearly as clued-in as Judge Alsup).

Oracle has made much of nine lines of code that crept into both Android and Java. This circumstance is so innocuous and overblown by Oracle that the actual facts, as found herein by the judge, will be set forth below for the benefit of the court of appeals.

He goes on to explain not just how insignificant the situation was, but he details how it happened and why it's crazy to consider it worthy of a copyright infringement suit. It's a pretty complete smackdown of Oracle's position.

Again, it is quite likely that Oracle will appeal, even though this ruling is so firm it might be smarter for Oracle to issue a giant apology to the tech community and just get on with doing business. That seems unlikely, of course, as Oracle probably hopes to find less knowledgeable judges on appeal. One hopes, however, that the appeals court judges will recognize the very, very thorough nature of Judge Alsup's ruling, and reject any appeal as well.

Filed Under: android, api, copyright, java, william alsup
Companies: google, oracle

Boom: Jury Says No Patent Infringement By Google In Oracle Case

from the there-goes-that-one dept

Remember back when Oracle was claiming that Google owed it billions of dollars for infringing on Oracle patents and copyrights? Yeah. Forget that. The jury just said that there's no patent infringement at all and the judge has dismissed the jury. All that's left in this phase of the case is for the judge to make a determination over the copyright issue -- and if he decides APIs cannot be covered by copyright, Oracle will have a complete and total loss. Of course, Oracle will almost certainly appeal, but this case has turned into something of a complete disaster for the company.

Groklaw has the details with "no" answers across the board:

Clerk:

Question 1: has Oracle proved by preponderance of evidence that Google infringed?

Claim 11: not proven
27: no
29: no
39: no
40: no
41: no

Question 2: not proven

1: no
20: no

Question 3: no answer, no response, not applicable.

Filed Under: android, api, java
Companies: google, oracle

Confused Jury Says Google Infringed On Oracle's Copyright, Sorta, But Maybe Not

from the if-it-was-fair-use,-it-wasn't-infringement dept

There was some indication last week that the jury in the Oracle/Google lawsuit was having trouble coming to agreement, and it appears that despite some effort to try to fix that, in the end the jury remained deadlocked on a bunch of issues. However, it did decide that Google infringed on Oracle's copyright in the Java APIs it used -- but what the jury punted on was whether or not those uses were allowed via fair use. This seems a bit odd, since fair use, despite supposedly being a defense, still means that there was no infringement. So, basically the jury said that Google may have infringed... which is pretty useless for a jury. Separately, the jury rejected the idea that Google infringed on the documentation of the APIs. It also found that Google did not infringe on the comments for some of the code, but did infringe on using rangeCheck in two files. That said, the jury again punted on whether or not the use was de minimis (which, again, would mean non-infringement).

According to The Verge (who is in the court room), the jury also wasn't buying the claim that Google relied on Sun's statements saying that Google's use was okay. The jury's main problem with Google's claim here wasn't that Sun hadn't made clear that the use was acceptable. It was that there wasn't much evidence that Google actually relied on such claims from Sun. I can understand why the jury might claim this, but I wonder why it would matter. Given that Sun made clear that Google's use was acceptable, in what world could you later turn around and claim that its use was unacceptable?

Either way, the fact that the jury couldn't come to an answer on the fair use/de minimis questions effectively sinks the entire process. Google immediately asked the judge to declare a mistrial, and the judge has supposedly asked both companies to prepare arguments over whether or not a mistrial should be declared, so this is far from over.

Filed Under: api, de minimis, fair use, java
Companies: google, oracle, sun

Oracle/Google Case Shows Just How Totally Pointless It Is To Have Patents On Software

from the it's-now-how-people-code dept

Julie Samuels has a fantastic piece over at Wired using the Oracle v. Google case to explain why patents simply don't make any sense in the software world:

For starters, software often does not require the type of heavy investment that should result in a 20-year monopoly. Instead of expensive laboratories or years of testing for FDA approval, for example, you often just need a coder and a computer. Even complex programs don’t require 20 years of exclusivity to recoup their investment. Software patents are often not even necessary for successful businesses: Facebook and, yes, Google — never relied on software patents to grow their early businesses.

Software patents are also notoriously vague and difficult to understand, making it impossible for small inventors to navigate the system without expensive legal help. And that brings us to the most dangerous aspect of software patents: litigation.

It turns out that software patents are nearly five times more likely to be the subject of litigation as other patents. In fact, lawsuits surrounding software patents have more than tripled since 1999, and they have become part of the price of doing business in America. Take Spotify. After realizing much success in Europe, Spotify launched its U.S. product in July, and just weeks later it found itself facing a patent suit.

Of course, tons of software developers recognize this implicitly. I know an awful lot of software developers in Silicon Valley. I can't think of a single one who thinks patents are a good thing or even remotely useful (and this includes many developers who have patents). In development circles, it seems that nearly everyone thinks patents are a waste of time and money. And that's because software doesn't work the way that the patent system envisions.

Perhaps most troubling, the patent system fails to recognize how people create and use technology. Software is fundamentally situated as a building-block technology. You write some code, and then I improve upon it — something the open source community has figured out. Google’s use of Java in its Android OS also demonstrates how innovators create, by making its own product and and incorporating some elements of the Java language (which, incidentally, Java’s creators have a history of supporting). And when those two come together, it results in an incredibly popular product, here the Android OS.

It's the difference between an idea and actually bringing that idea to market. That difference is always ignored or underestimated by patent lawyers -- but developers know the difference. The patent system wasn't designed by software developers, though. And it shows.

Filed Under: android, java, monopoly, silicon valley, software
Companies: google, oracle

Fight Is On Between Oracle And Google Over Java API Copyrights

from the shouldn't-have-gotten-this-far dept

Last summer, we noted that there was an interesting "sideshow" in the patent dispute between Oracle and Google -- a question of whether or not Java's APIs are covered by copyright. That "sideshow" has become the main attraction now that the trial has started and many of the patent claims have been kicked out.

Oracle has been quite public with its argument (pdf), which is mostly based on taking snippets from Google emails that suggest a need to license Java. The favorite of the bunch is this one:

They also point to some snippets of code that do appeared to be copied:


If you just see that side of it, you might be convinced, but the details suggest a much less convincing story. First off, there are serious concerns about whether or not an API even can be covered by copyright. In fact, before Sun was acquired by Oracle, Sun's own CTO had said that "internet specifications are not protectable under copyright," which (you might think) gives Google an implied go ahead to make use of the API. Furthermore, many of the email snippets that Oracle presents are taken out of context -- they show little snippets of big emails and pull from very very different time periods -- ranging from 2005 to 2010, when different factors applied. Oracle also scrubbed a blog from former Sun CEO Jonathan Schwartz in which he warmly welcomed Google to the Java family when the company launched Android.

Perhaps more damning: Larry Ellison himself in 2009 at the JavaOne event spoke about Google's Android development and how they were contributing code back to Java. Ellison himself was put on the stand and appeared to contradict his own depositions when it came time to discuss the specifics of the copyright. That can't go over well. Not only that, but he stumbled, and claimed he was "not sure" when asked specific questions:

On cross-examination, Google came out firing and the room got tense quickly. “Do you understand that no one owns the Java programming language?” lead counsel Robert Van Nest asked.

Ellison began a longer answer, but Judge William Alsup interrupted him and said it was a “yes or no” question. Finally Ellison said, “I’m not sure.”

“And anyone can use it without royalty?” Van Nest followed up.

“I’m not sure,” Ellison said again.

Then Van Nest showed a video of Ellison receiving the same question on a deposition video and answering “That’s correct” to both.

Oracle's response, of course, will be that it just meant for developing apps, not for using the API -- but its other statements are a lot less clear on that. Either way, it seems pretty clear that Sun gave an implied open license to these things, so to come back now and insist otherwise is pretty questionable. Furthermore, there still are questions as to whether or not an API can actually be covered by copyright at all.

Separately, Oracle keeps talking about just how much work it is to create APIs, and even points to some Google statements about the difficulty of doing so. That's smoke and mirrors. Difficulty has no bearing on copyright law. It's kind of surprising that Oracle's lawyers would even bring it up, as "sweat of the brow" arguments won't get very far. Hell, even if it biases a jury, it would get rejected on appeal. It seems like Oracle's strategy here is just to confuse the jury and go for guilty by association because they're going to have trouble showing actual guilt.

As for the specific code snippets shown above, those a few lines out of 50,000 or so files. Under copyright there's a defense known as de minimis copying, if you're just found to have copied a very tiny portion of something. It seems like that might apply here as well.

Also, you may have heard stories about the results of this trial potentially being worth billions of dollars or something, but that was before most of the patents got thrown out. The patents left over aren't worth very much at all, and the end result means that if Oracle wins, it'll likely get less than $100 million. That's still a significant sum, but it's a lot less than what Oracle had hoped to get in this lawsuit.

In the end, as it seemed from the beginning, Oracle's case looks pretty weak (and getting weaker).

Filed Under: api, copying, de minimis, java, larry ellison
Companies: google, oracle, sun