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

AOL Unclear On The Concept: Threatens Startup For Properly Using Creative Commons Content

from the that's-not-how-it-works dept

Oh, AOL. The company wants people to believe that it's a new kind of company, but it apparently can't help acting in a really dumb way. The latest: the company is threatening a company that is properly making use of AOL content that is available under a Creative Commons license. Pro Populi is using content from Crunchbase, the database of startup info that originated as a part of the site TechCrunch, both of which are now owned by AOL. The content is licensed under a Creative Commons CC-BY attribution license, which means it can be used in pretty much any way, even commercially, so long as it's properly attributed. That appears to be the case with Pro Populi, which is using the data in its People+ app.

AOL, however, has sent a cease-and-desist:

“[Y]our company’s People+ product in essence has made wholesale use of CrunchBase content to simply replicate what CrunchBase does,” wrote Grossman in another letter to the startup. The app, Grossman adds, “duplicates what CrunchBase offers in order to compete directly with us.”

Except, of course, that's entirely allowed under the license in question. So AOL is simply wrong here. Amusingly, AOL is trying to get around its blatant wrongness from a different direction, claiming that the scraping of the data abused the terms of their API that makes the use of the data improper:

That’s because Pro Populi downloaded the database through the CrunchBase API, a digital interface that allows anyone access to the data. Buried in the terms-of-service for the CrunchBase API is this caveat: AOL “reserves the right to continually review and evaluate all uses of the API, including those that appear more competitive than complementary in nature.” And AOL “reserves the right in its sole discretion (for any reason or for no reason) and at anytime without notice to You to ... terminate your rights” to use “any CrunchBase content.”

That clause is completely bogus. AOL can decide to forbid someone from using the API if they feel it violates their terms, but they cannot "terminate" the license to use the content. The content is free to use under the license, and there's nothing AOL can legally do about it -- other than lie and be a bully, which appears to be the choice the company has made. Thankfully, EFF is now representing Pro Populi and has sent a detailed letter explaining all of this to AOL. Hopefully, next time, their lawyers will actually understand their own licenses before misrepresenting them in bogus threat letters.

Filed Under: api, copyright, creative commons, crunchbase
Companies: aol, pro populi

Unfortunate: Twitter Forces Flattr To Stop Its Twitter Integration

from the well-that-sucks dept

Just a few weeks ago, we wrote about how Flattr had integrated with services like Twitter and Instagram to make it incredibly easy to support content creators (including us!) by just favoriting a tweet. Not surprisingly, in the first month after that went into effect, we saw a boost in revenue from Flattr. Unfortunately, Flattr has now announced that Twitter has forced the company to stop this integration.

Flattr had been using the Twitter API to figure out what people had favorited, and had been gathering data about the specific tweets. However, Twitter told the company that it was violating section IV. 2 C from its API terms. That term says that:

Your advertisements cannot resemble or reasonably be confused by users as a Tweet. For example, ads cannot have Tweet actions like follow, retweet, favorite, and reply. And you cannot sell or receive compensation for Tweet actions or the placement of Tweet actions on your Service.

It's that last part where the trouble came in. Of course, it seems clear that that particular line in the terms of service was designed for situations where people are "selling" tweets or something similar. Not for cases where a service like Flattr is helping people make money from supporters. In response, Flattr even said that it would waive its standard 10% fee on any Flattrs that come via tweets. Twitter told them it wasn't good enough. Now, you can argue that "rules are rules," but rules need to make some sense. And it's unclear what kind of sense this makes. There's nothing about the way in which Flattr is using Twttier that is negative for Twitter. It seems like a really nice and useful addition. Obviously, we're somewhat biased, because it also helped us make a few bucks (not much, but some), but I can't see how it makes sense for Twitter to block this functionality.

Filed Under: api, integration, micropayments, payments
Companies: flattr, twitter

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

Tech Still One Step Ahead: New Service Downloads Torrents Directly To Dropbox

from the it's-unstoppable dept

Update: Well, that didn't take long. Dropbox has already blocked Boxopus.

Every time some sort of file sharing service is shut down or someone else is arrested, we hear the regular crew of supporters of the existing copyright regime declare victory. But, every time, people just shift to some other service and move on. None of it leads people to suddenly spend money again when they hadn't before. TorrentFreak recently had an article about a service calls Boxopus, which uses Dropbox's API to automatically download content from torrents to a Dropbox file. Think of it as torrenting in the cloud. From a user perspective, there are plenty of advantages, including the fact that the content is then available on all your synced devices. Of course, there's also the fact that for an end user, it's somewhat anonymous -- since Boxopus is the "downloader" rather than the user themselves. So if the content is infringing, it's more difficult to track them down (though, I would imagine not impossible, if someone got access to Boxopus' logs). Apparently, a number of services have already implemented this as a download option. Of course, this probably just means that Boxopus will soon be targeted as a "problem" even though it has plenty of non-infringing uses, and actually could be quite handy for all kinds of authorized activities in a more cloud-centric universe.

Either way, what strikes me about this is a simple fact: the technology always advances. It sees areas where people try to stop it, and figures out a way to route around it. Whether or not people like this, it exists, and tons of other, similar offerings will likely exist in short order. You can fight the tide -- as some seem to want to do -- or you can look at ways that you might take advantage of tools like this. Only one of those is a winning strategy.

Filed Under: api, file sharing, torrents
Companies: dropbox

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

Judge Ridicules Oracle's Risky Choice To Forego Statutory Damages And Seek Bigger Payout

from the wow dept

We've written tons of stuff on the ridiculousness of statutory damages for copyright infringement -- which can put damages for a single infringement at up to $150,000 (for willful infringement). When you're talking about a $0.99 song, that seems completely out of line. The reason for statutory damages (supposedly) is that figuring out actual damages is simply too difficult, so a statutory range lets you ignore any discussion of having to prove real damages. In most copyright lawsuits, plaintiffs automatically take the statutory damages rates. It's pretty rare for anyone to opt-out. However, opting out is exactly what Oracle has done in its ongoing lawsuit against Google. And it did this despite the judge ridiculing the company for the decision. From Rachel King at ZDNet:

When Alsup heard Jacobs say this, he warned that if Oracle goes down this path, they might not win anything at all, adding that it is the “height of ridiculousness” to think that Oracle could claim “hundreds of millions” of dollars for nine lines of code.

“The law can’t operate that way,” Alsup said. “In my mind, you’re making a mistake.”

In a later discussion on Friday morning, David Boies, also representing Oracle, tried to defend this strategy, arguing that the burden of proof is on Google here — not Oracle.

“What we are saying is once you proved infringement, we think under the law we have claim for infringer’s profit case,” Boies asserted.

The only thing I can figure here is that Oracle is doing this just to be a pest. Even if it does eventually win on the copyright issue (still an open question given the judge needing to rule on the copyrightability of APIs), it's not going to get that much money either way. The $150,000 statutory damages numbers are pocket change for either company, but as the judge made clear, in all likelihood it would get less (or nothing) if it tries to get "infringer's profits," because the contribution of the code in question is so minimal. However, it is possible that the fight over what those "profits" might be will simply prolong the case... and the expense of the case. So perhaps this is just a strategy by Oracle to drag things out? Maybe its lawyers are hoping that will make Google want to settle? Other than that, I'm with the judge in being a bit perplexed by the reasoning here.

Filed Under: api, statutory damages
Companies: google, oracle