Supreme Court Won't Hear Oracle v. Google Case, Leaving APIs Copyrightable And Innovation At Risk

from the dangerous-ruling dept

This is unfortunate, even if it was somewhat expected: the Supreme Court has now rejected Google's request to hear its appeal over the appeals court decision that overturned a lower court ruling on the copyrightability of APIs. The lower court decision, by Judge William Alsup (who learned to code Java to understand the issues), noted that APIs were not copyrightable, as they were mere methods, which are not subject to copyright.

The appeals court ruling, by the Court of Appeals for the Federal Circuit (CAFC) (famous for getting patent cases wrong over and over and over again) didn't just get things wrong, it got things laughably wrong, confusing the difference between APIs and software throughout, and quoting people entirely out of context (including taking things so out of context that it often pitted people on the same side against each other, solely because CAFC misread what they were saying). The case was appealed to the Supreme Court, and we were shocked and dismayed to see the Obama administration further reinforce the errors of the CAFC ruling in telling the Supreme Court not to hear the case. The filing by Solicitor General Donald Verrilli repeatedly confused software with APIs and insisted that there was really no difference between the two. That's just wrong. It's not a matter of debate. It's just wrong.

One would have hoped that with a ton of computer science experts explaining to the Supreme Court how CAFC got things wrong, the Supreme Court might recognize that the Obama administration was confused, but for whatever reason, the Supreme Court has declined to hear the case.

This is dangerous. The world of software and innovation relies on the kind of interoperability and the ability to connect via things like APIs. As we've noted, this is like claiming you can copyright an entire language, rather than the creative works written in those languages. Making APIs proprietary and locked up puts a ton of innovation at risk.

As for Google and Oracle directly, this probably doesn't matter much. They're two giant companies, certainly. And now that the case returns to the lower court, they'll either settle or fight it out over fair use (and hopefully win on that front as well). But saying fair use allows this is very, very different than saying there's no copyright on the API. And for smaller companies this will have a tremendous ripple effect, and will undoubtedly lead to a slower pace of innovation. The kinds of touchstones that people build on will no longer happen. Under this ruling, it basically overrules previous rulings that said pull down menus were not copyrightable. But with this ruling in place, it's hard to see how that's still true. Expect to see a bunch of ridiculous lawsuits over minor copying of functions like that.

While this case may eventually be resolved on fair use grounds (or through settlement), there are still two potential areas of hope. First, the "precedential" power of this ruling is actually somewhat limited. CAFC precedents are more or less meaningless in this context. CAFC handles all patent cases, and the only reason it heard this case was because it started as a patent case, even though those issues were resolved much earlier. So, while CAFC has made this particular ruling, it does not mean that the 9th Circuit, where this case was actually heard has to abide by it. The appeals court for the 9th circuit could rule otherwise (though it is somewhat famous for its own nutty copyright rulings).

Perhaps if this issue returns to another appeals court, and that court gets it right, the issue will return to the Supreme Court with a clear circuit split. And by then, we can hope, the people staffing the Solicitor's General office will finally include at least one person who understands the difference between code and APIs.

The really stunning thing in all of this is just how factually wrong many of the arguments were, and that the CAFC and Obama Administration bought them. These weren't questions of interpretation or opinion. They just flat out got the facts wrong, based on an astounding level of ignorance about a rather basic concept of an API not being software. Just because they both look like "code" does not make them both code. It would be nice if the people actually making these decisions weren't so easily fooled by their own ignorance.

Filed Under: api, apis, cafc, copyright, donald verrilli, scotus, software, supreme court, william alsup
Companies: google, oracle

What The Oracle-Google Copyright Fight Has To Do With Klingon... And Lots Of Other Innovations

from the a-language-is-only-useful-if-it's-shared dept

We've already written plenty on the Obama administration's absolutely ridiculous filing in the Oracle/Google case concerning the copyrightability of APIs. As we noted, the entire filing shows what appears to be a willful misunderstanding of the difference between "software" and an "API." That's problematic on many levels. In trying to explain this, we kept describing the API as something of a "recipe" -- which is not covered by copyright -- and how that's different from the actual food. But Charles Duan has come up with potentially an even better comparison, noting that an API is quite like an invented language, and wondering what would happen if the creators of Klingon tried to claim copyright against anyone using Klingon.

...according to Oracle, copyright can protect a language and prevent others like Google from speaking it.

That’s the connection of the Oracle v. Google case to Klingon and other constructed languages like Esperanto or Lojban: If broadly read, the ruling against Google, which is where the case currently stands, could also deem the speaking of such languages to be copyright infringement.

This is actually quite interesting. Getting beyond Klingon, Duan mentions Lojban, which is a kind of proof of the problems this kind of thing can cause. Lojban is actually a re-created language, building off the ideas in Loglan, whose creators tried to lock it up claiming ownership. In that case, the creator, James Brown, tried (and failed) to use trademark law to block others from using "his" language.

But this is a key thing: languages are only useful if they're shared and used more widely. The idea of locking up a language itself under copyright is almost nonsensical, but that's exactly what the appeals court did and it's what the Obama administration has now advocated for, based on a failure to understand the difference between an API and software.

And, of course, the impact on this goes beyond "languages" as Duan notes:

And it’s not just the linguists and Trekkies who should be concerned.

Invented languages are the foundation of all sorts of innovation. Most prominently, computer networking technology depends on languages, like the Wi-Fi protocol, so that multiple computers can communicate and understand one another. Those protocols also include formally defined commands (vocabularies) and rules of operation and syntax (grammars), making them languages almost exactly on par with the Java API. Other fields, such as medicine, engineering, and sports, rely on well-known jargon for efficient communication of specialized concepts.

Languages and APIs are how we communicate. Languages may be how humans communicate with one another, while APIs are often how computers communicate with one another. Copyrighting the very language of communication seems not just nonsensical but actively counterproductive when you think about it that way.

It's just tragic that the lawyers working for the President didn't think about it that way.

Filed Under: apis, copyright, klingon, languages
Companies: google, oracle

Computer Scientists, Legal Experts Explain To Supreme Court Why APIs Are Not Copyrightable

from the let's-try-this-again dept

Back in May, the appeals court for the Federal Circuit (CAFC) enhanced its reputation of consistently getting basic patent law wrong by deciding to get copyright law wrong too, in declaring that APIs were copyrightable subject matter, in the Oracle v. Google lawsuit. As we explained at the time, the court appeared to make some rather serious fundamental errors, not understanding the difference between software and interfaces (and worse, totally misquoting some experts). Last month, Google asked the Supreme Court to review the case. On Friday, a bunch of interesting amicus briefs were filed, asking the Supreme Court to fix the CAFC's big mistakes.

Perhaps the most interesting was put together by the EFF, and was signed by 77 computer scientists, including many of the most well-known and most respected computer scientists around, including Hal Abelson, Brian Behlendorf, Ward Cunningham, Peter Deutsch, David Dill, Dave Farber, Ed Felten, Mitch Kapor, Alan Kay, Brian Kernighan, Guido van Rossum, Avi Rubin, Bruce Schneier and Bjarne Stroustrup among others. There are a lot more, obviously, but those were just a few of the names that stood out.

The key point made in the filing is that this upsets decades of what was considered a settled matter in computer science, while highlighting how much of computer history was built off of the recognition of non-copyrightable APIs, allowing for the creation of interoperable systems, much of which drove the early computer revolution. Here's the summary from the brief:

For decades, computer scientists have relied on the open nature of APIs to enable rapid innovation in computer technology. For decades, circuit courts have supported that reliance, concluding that Section 102(b) of the Copyright Act protects a programmer’s source code as creative expression, but does not cover the processes, systems, and methods of operation that code may employ to interface with other software. The district court correctly followed that precedent and rejected Oracle’s claim that the Java APIs could be copyrightable. Sadly, the Federal Circuit chose to split with the other circuits and reverse the district court. That decision upended decades of industry practice and threatens the basic principles upon which our technology sector was built.

Not surprisingly, the Federal Circuit’s decision has been harshly criticized. As many commentators have noted, if the Federal Circuit’s view had been accepted at the birth of modern computing, many important technologies would never have existed, and/or succeeded. For example, the widespread availability of diverse, cheap, and customizable personal computers owes its existence to the lack of copyright on the specification for IBM’s Basic Input/Output System (BIOS) for the PC. And open APIs were essential to many modern computing developments, including those of operating systems such as UNIX, programming languages such as “C,” the Internet’s network protocols, and cloud computing.

Today, open, uncopyrightable APIs continue to spur the creation and adoption of new technologies. When programmers can freely reimplement or reverse engineer an API without obtaining a costly license or risking a lawsuit, they can create compatible software that the interface’s original creator might never have envisioned or had the resources to develop. Moreover, compatible APIs help enable people to switch platforms and services freely, and to find software that meets their needs regardless of what browser or operating system they use. Without the compatibility enabled by the open nature of APIs, consumers could be forced to leave their data and programs behind when they switch to a new service.

The freedom to reimplement APIs also helps developers rescue “orphan” software or data—systems that are no longer supported by their creators. When a company stops supporting a computer platform or service, the ability to freely reimplement APIs protects the communities that rely on that software. Government entities and non-profi ts are especially susceptible to the orphan programs problem as they often cannot afford to upgrade and are left using legacy technologies for years or decades.

Next up, is a filing from CCIA written in part by Jonathan Band, which is noteworthy in part because Band co-wrote the book on copyright and interfaces (first published nearly 20 years ago), explaining how interfaces aren't copyrightable and why that simple fact was responsible for so much of the computer revolution. This filing similarly notes how much of history was driven by interoperability, but also digs deeper into what a mess it would be if the CAFC's view was determined to be correct:

If a company could exercise proprietary control over the interface specifications implemented by its products, that company could determine which products made by other firms – if any – would be compatible with its software. And should that company have a dominant position in a particular market, it could use its control over compatibility to expand its dominant position into adjacent markets. Moreover, such authority would extend the rights under copyright beyond what is necessary to protect the original expressive elements that have traditionally been offered protection under American copyright law, and it would override limitations on copyright crafted to protect the public good.

Such a broad monopoly would have serious implications for consumer welfare. In the absence of competition during the effective lifespan of the product, the first developer would have little incentive to develop more innovative and less costly products. These negative consequences would be compounded by the fact that the personal computer revolution and the emergence of the Internet have produced an overwhelming need for interconnection between different elements of computer systems. Prohibiting competitors from accessing de facto standard interface specifications would lock users into a particular operating system or network software environment, and would inhibit the transfer of data between users with different computing environments.... The Petition shows a host of real-world problems and economic harms that would result if API copyright could foreclose compatibility, including the cost of rewriting interface code formerly understood to be unprotected, and lock-in costs resulting from consumers’ inability to switch operating systems or cloud computing providers.... Lock-in would deter competition, investment, and innovation in the burgeoning cloud computing industry, which is known to be sensitive to policy changes in copyright.

In short, in the computer industry, overly broad intellectual property protection directly restricts competition and innovation. This was the status quo in the computing environment in the 1970s. Once a buyer purchased a computer system, the buyer was essentially locked-in to that system: the system was incompatible with products manufactured by other companies, and conversion costs were high. Although “locking in” was extremely profitable for dominant vendors such as IBM, competitors and users suffered from high prices, indifferent service, limited choice, and slow innovation.

CCIA also reminds the Supreme Court that Oracle (and Sun) not to long ago were among those who fought strongly for the position that interfaces were not copyrightable and that interoperability should be allowed. The filing notes that Sun and Oracle fought hard against parts of the DMCA when it was introduced that would have blocked interoperability. For example:

In a 1998 press release, Michael Morris, then Vice President and General Counsel of Sun Microsystems, argued that the DMCA as introduced would “impose[ ] a new and unnecessary layer of restraint on lawful access to those unprotected elements of computer programs that are necessary to achieve interoperability, thus placing developers of interoperable products at the mercy of proprietary vendors.”

That resulted in changes to the DMCA to make sure that interoperability was allowed. And yet, now, Oracle (via its Sun acquisition) is trying to argue that the exact opposite is true.

Finally, Public Knowledge also submitted an interesting brief which lays out the ridiculous situation we're in today with an analogy using amusingly named stand-ins and products:

Say that Delphi Corporation manufactures screws. It hits upon a new design for a screw socket—the interface between screw and screwdriver—that is more efficient than the prevailing Phillips and flathead insertions. Capitalizing on this novel idea, Delphi manufactures a line of screws using this socket, which it calls Sumatra. The Sumatra socket is wildly popular. New lines of screwdrivers are made for the Sumatra socket. Engineering textbooks praise the Sumatra design. Wood-workers teach their sons and daughters to use it. And competing screw manufacturer Zillion decides to make its own screws compatible with the Sumatra socket. The screws otherwise differ, but use the Sumatra socket so that woodworkers need not purchase new tools.

Only then does Delphi declare the Sumatra socket a sculptural work, suing Zillion for copyright infringement.

Rather than focusing on more recent rulings concerning software, the Public Knowledge brief goes all the way back to Baker v. Selden from 1879, which found that you couldn't copyright a set of blank ledger forms.

Oracle repeatedly points to the “intricate web of connections" of the Java API, in an effort to suggest that its structure, sequence and organization of the API is copyrightable. Oracle Brief, supra, at 26. But so too can uncopyrightable blank forms constitute an intricate web of connections. Selden’s book included 19 forms and 24 pages of demonstrative explanation designed “to compress almost innumerable accounts under a few specific, intelligible heads.” .... For either blank forms or APIs, intricacy does not confer copyrightability.

Given that an API is factually on par with a blank form, it is unsurprising that the reasoning of Baker directly applies to the copyrightability of APIs. Baker held that blank ledger forms, including the “ruled lines and headings,” could not properly be the subject of copyright.... The Court said that copyright cannot cover “systems” or an “art”; the Java API is certainly a system, one that teaches the “art” of using the Java system....

The Java API is on all fours with the blank forms of Baker, both factually and legally. Since copying of the blank forms in Baker was permissible, copying of the Java API is too.

It's also nice to see the Public Knowledge brief call out the simple factual errors in the CAFC ruling (some of which we pointed out in our post at the time):

... the Federal Circuit misunderstands arguments that interfaces are more properly protected by patent law than copyright law... Google, several amici below, and the district court merely proffered the unremarkable argument that functional elements should be excluded from copyright law by § 102(b) and the idea/expression dichotomy... But the Federal Circuit mistook them to mean that software may only be patentable or copyrightable, but not both. The Federal Circuit further assumed that criticisms of software patents equate to suggestions to expand copyrightable subject matter to cover interfaces.

These propositions are flawed. First, the Federal Circuit t neglects that there is matter outside the realm of both copyright and patent; the court apparently supposed that every element of a software program must fit into one or the other. Second, the Federal Circuit fails to differentiate the discrete elements of a given software product that may be copyrightable and those that may be patentable, instead lumping those elements together into a single entity. Third, the Federal Circuit conflates programming interfaces with computer programs generally.

Hopefully, these and other arguments convince the Supreme Court of just how wrong the CAFC was in its ruling. Recently, the Supreme Court has been pretty bad on copyright cases, while generally good on patent cases, so it's always a little nerve-wracking when copyright cases get there. The one bit of good news is that the Supreme Court has clearly found itself regularly questioning CAFC's interpretation of laws, since most of those patent cases come up via CAFC. The only reason this copyright case went to CAFC was because it started out as a patent case, though the patent issues got tossed out early on.

Filed Under: api, apis, computer scientists, copyright, copyrightable subject matter, functions, interfaces, software
Companies: ccia, eff, google, oracle, public knowledge

Supreme Court Asked To Make It Clear That APIs Are Not Copyrightable

from the fingers-crossed dept

Back in May, the Court of Appeals for the Federal Circuit (CAFC), long famous for messing up patent law, decided to take a short break and mess up copyright law as well, by declaring APIs copyrightable (the case ended up before CAFC instead of the 9th Circuit because it originated as a patent case, even though all the patent issues were gone). The district court had ruled otherwise, and that judge, William Alsup, had actually gone into great detail to explain why copyright shouldn't apply to APIs. Alsup had learned to code Java to better understand the case, and you could basically tell from his ruling that he was quite worried that appeals court judges wouldn't take the time to truly understand the issues at play. He was right. Making APIs copyrightable is bad news for innovation in a variety of ways.

But, of course, CAFC is not the final stop in the line (even if some patent trolls wish it were). As was fully expected, Google has now asked the Supreme Court to hear an appeal on the case. Google's petition is a good read highlighting the "disarray" in the various different circuits about whether or not copyright law applies to APIs. The law itself (Section 102(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." Many of us clearly think that APIs fit under this as a system or method of operation. But, others disagree.

Some courts follow the statute’s plain meaning, holding that Section 102(b) precludes copyright protection for all systems or methods of operation, including those in computer programs. See, e.g., Lotus, 49 F.3d at 815. Like the Federal Circuit, however, other courts have rejected the statutory text and held that Section 102(b) is merely a reminder of the dichotomy between ideas (which are not copyrightable) and expressions of ideas (which generally are). See, e.g., Whelan Assocs., Inc. v. Jaslow Dental Lab., Inc., 797 F.2d 1222, 1234 (3d Cir. 1986). In those courts’ view, a “method of operation” embodied in a computer program is copyrightable so long as its creator could have designed it in different ways.

Having shown the circuit split to help entice the Supreme Court to hear the case, Google then explains why it's simply wrong to interpret the law to say that APIs are covered by copyright.

The Federal Circuit’s error is confirmed by the extent to which it would eliminate a fundamental distinction between patent and copyright law—and thus allow copyright to be used as an end-run around the limits on patent protection, including this Court’s recent decisions on patent-eligibility.

Basically, you may be able to patent a system and method (as many patents themselves note in their titles), but it shouldn't be copyrightable.

While the Supreme Court has a history of being pretty bad on copyright law, it has been pretty good (especially lately) on patent law -- in particular smacking down CAFC -- and the Google filing plays up to that fact, arguing that this is just another case of CAFC interpreting the law incorrectly.

The Federal Circuit’s error is all the more glaring because it is essentially the same error for which this Court has repeatedly reversed the Federal Circuit in patent cases. The court of appeals criticized the district court for confusing “the threshold question of what is copyrightable—which presents a low bar—and the scope of conduct that constitutes infringing activity.” App. 17. It then transformed Section 102(b)’s limits on copyright eligibility into just one of several factors to be considered as part of a fair-use defense....

The Federal Circuit had similarly held that the limits on patent eligibility are minimal and that other requirements of the Patent Act do the real work in limiting monopoly protections. See, e.g., Research Corp. Techs., Inc. v. Microsoft Corp., 627 F.3d 859, 869 (Fed. Cir. 2010) (referring to Section 101 of the Patent Act as a “coarse eligibility filter”). This Court has repeatedly corrected that misperception in recent years, stressing the importance of enforcing Section 101’s limits on patentable subject matter—including for software-related patents. See, e.g., Alice, 134 S. Ct. 2347; Ass’n for Molecular Pathology v. Myriad Genetics, Inc., 133 S. Ct. 2107 (2013); Mayo, 132 S. Ct. 1289; Bilski v. Kappos, 130 S. Ct. 3218 (2010). But the Federal Circuit would now eviscerate the analogous limitation on copyright eligibility for some of the same types of works.

Hopefully the Supreme Court recognizes this, takes the case and... (most importantly) doesn't make things worse.

Filed Under: apis, cafc, copyright, supreme court
Companies: google, oracle

Why Making APIs Copyrightable Is Bad News For Innovation

from the this-is-a-big-problem dept

Following last week's terrible ruling from the appeals court of the Federal Circuit (CAFC), a lot of people have been trying to dig into what this would mean if it stands. As we mentioned, this is far from the end of the line. Google can (and will) seek a reversal, either from the entire CAFC or the Supreme Court. And even if that is rejected or fails, the case still goes back to the district court level to determine the fair use question (which will then see its own series of appeals). In short, this is not even close to being settled yet -- which means many, many, many millions of dollars in legal fees are going to be tossed around before this is settled. That, alone, is a mess for innovators and entrepreneurs who are in a state of flux given the situation.

But, rest assured, if this ruling holds, it will be bad news for innovators. Over a year ago, Sacha Labourey had a good explanation of what's at stake here:

APIs exist for a reason: They act as the communication channel, the lingua franca, the boundary, between the provider of the implementation and users of that implementation — developers. Of course they require an investment to create. Deep expertise — and even taste — is required to create effective APIs. But, companies and individuals make those investments because they want developers to use an implementation that is exposed through the API. That implementation might give people an incentive to buy your hardware, software or services. Who knows, maybe it gives you a more effective way to sell ads.

You make some bets when you create an API, but they’re not about monetizing the API. They’re about monetizing the things the API unlocks access to. You’ll find APIs documented and used in many books, blogs and open-source projects. Adoption is probably the key measure of success of an API. But then if you encourage developers to use your APIs, why can you prevent them from implementing “the other side” of them? When Captain Picard orders a “Tea, Earl Grey, Hot,” at the Oracle replicator, he’s using a kind of API: “Object. [Qualifiers...]”. Google or anyone else should be able to create their own replicator without Oracle insisting they use some other syntax.

Oracle lost in their attempt to protect their position using patents. They lost in their attempt to claim Google copied anything but a few lines of code. If they succeed in claiming you need their permission to use the Java APIs that they pushed as a community standard, software developers and innovation will be the losers. Learning the Java language is relatively simple, but mastering its APIs is a major investment you make as a Java developer. What Android did for Java developers is to allow them to make use of their individual career and professional investment to engage in a mobile marketplace that Sun failed to properly engage in.

In other words, properly recognizing that APIs shouldn't be covered by copyright benefits everyone, as it makes people programming on your platform more valuable since they have more options and more flexibility. The big companies who don't like this are being short-sighted. They're trying to lock in developers, by forcing them to only develop for their platform, but in doing so, are inherently making their own platform less valuable. If innovators can easily write for multiple platforms, the network effects apply across all of those platforms.

The folks over at EFF properly note that this kind of freedom is truly important for innovation:

The implications of this decision are significant, and dangerous. As we and others tried to explain to the court, the freedom to reimplement and extend existing APIs has been the key to competition and progress in both hardware and software development. It made possible the emergence and success of many robust industries we now take for granted—for mainframes, PCs, workstations/servers, and so on—by ensuring that competitors could challenge established players and advance the state of the art. In other words, excluding APIs from copyright protection has been essential to the development of modern computers and the Internet.

When programmers can freely reimplement or reverse engineer an API without the need to negotiate a costly license or risk a lawsuit, they can create compatible software that the interface’s original creator might never have envisioned or had the resources to create. Moreover, compatible APIs enable people to switch platforms and services freely, and to find software that meets their needs regardless of what browser or operating system they use. The freedom to reimplement APIs also helps rescue “orphan” software or data—systems whose creators have either gone out of business or abandoned their product in the marketplace.

Today's decision puts all of that at risk, potentially handing Oracle and others veto power over any developer who wants to create a compatible program. What is worse, if today's decision is taken as a green light to API litigation, large and small software tech companies are going to have to divert more and more resources away from development, and toward litigation. That will be good for the legal profession—but not so good for everyone else. 

What kind of litigation and what kind of mess are we talking about? Tim Lee, over at Vox, has some ideas:

One good example is the open source project Samba. It was created to allow users of open source operating systems such as Linux share files with Windows users. To do that, the Samba programmers reverse-engineered and then duplicated the functionality of the Windows file-sharing system. They didn't copy any Microsoft software; they simply duplicated the sequence of commands needed to transfer files, read the contents of folders, and perform other functions in the Windows file-sharing system.

Samba has become hugely popular. Not only did Apple incorporate Samba into some versions of Mac OS X to allow Macs and PCs to communicate, many third-party companies also used Samba to build stand-alone file servers.

The legality of projects like Samba has been widely accepted for more than two decades. But under the Federal Circuit's logic, Microsoft might be able to sue a Samba for copyright infringement. If the Federal Circuit's precedent isn't overturned, companies could become more reluctant to reverse-engineer competitors' products in order to make them compatible.

Grimmelmann also warns that the vague language of the decision could open the door to frivolous litigation. For example, the decision could make it easier for a company to sue a former employee if he goes to a new employer and writes software similar to the code he wrote at his old job. Even if the programmer writes the new code from scratch, courts could find that it's similar enough to the old code to trigger copyright liability.

Meanwhile, over at the Disruptive Competition Project blog, Jonathan Band, delves into the many, many ways that the CAFC appears to have totally misread the historical precedents that bind the court. But, even worse, he notes that many innovators and programmers have relied on those precedents for years -- and now all of that work is thrown into doubt:

For the past 20 years, since decisions such as Sega v. Accolade, Computer Associates v. Altai, and Lotus v. Borland, computer programmers in the United States have understood that copyright does not protect program elements necessary for interoperability. Based on this understanding, programmers have freely copied these elements, which has encouraged enormous creativity, innovation, and competition in the digital environment. Judge O’Malley’s decision casts doubt on this understanding. By ruling that interoperability is relevant only to fair use, and not to protectability, Judge O’Malley would require every developer to perform a fair use analysis before developing an interoperable product. This would place U.S. programmers at a competitive disadvantage to developers in other jurisdictions that recognized that copyright does not protect program elements necessary for interoperability. The Court of Justice of the European Union, for example, in the 2012 decision in SAS Institute v. World Programming Ltd., ruled that program functionality, programming languages, and data formats were not protectable under copyright.

While for non-programmers, all of this may seem like a minor, technical issue over whether some small bit of "software" is copyrightable, the practical implications of declaring APIs copyrightable will have vast and far-reaching implications for all kinds of innovation. This isn't just a bad ruling, it's a ruling that will create massive problems for today's innovators.

Filed Under: apis, copyright, innovation
Companies: google, oracle

The War On Computing: What Happens When Authorities Don't Understand Technology

from the here-we-go dept

We've obviously been covering a lot about Aaron Swartz lately, but his case is really just one of many similar cases involving people in positions of authority who simply don't understand basic technology, but feel that something must be illegal because they try to overlay an analog view on a digital world. In the Swartz case, Carmen Ortiz famously used the incredibly misguided and misleading "stealing is stealing" concept. However, as Cory Doctorow has been fond of pointing out lately, we're entering a war on general purpose computing, and this is just one battle front.

Two other recent skirmishes show the same sorts of things happening in slightly different contexts. A few months ago, we wrote about the case of Andrew Auernheimer, the security researcher who's been convicted and likely to face a long period of time in jail for exposing a blatant security hole from AT&T that allowed him (and anyone else) to gather personal data on the owners of any iOS device. Remember, AT&T set up some stupid security, making all of this data public via its own API. Now about to be sentenced, Auernheimer was asked to write up a "statement of responsibility" for the court, and chose to do a blog post in which he calls out what a farce the whole situation is:

The facts: AT&T admitted, at trial, that they “published” this data. Their words. Public-facing, programmatic accesses of APIs happen upwards of a trillion times per day. Twitter broke 13 billion on their API ages ago. This is something that happens more than the entire population of Earth, daily. The government has no problem with this up until you transform the output into something offensive to important people. People with “disruptive” startups, this is your fair warning: They are coming for you next.

The other one of my prosecutors, Zach Intrater, said that a comment I made about Goatse Security, my information security working group, starting a certification process to declare systems “goatse tight” was evidence of my intent to personally profit. For those not in on the joke: Goatse is an Internet meme referencing a man holding open his anus very widely. The mind reels.

I can’t survive like this. I am happy to be hitting a prison cell soon. They ruined my business. The feds get approval of who I can work for or with: they rejected one company because the CEO had a social network profile with an occupation listed as “hacker.” They prohibit me from touching any computer that isn’t federally monitored. I do my best to slang Perl code on an Android device to comply with my bail conditions. It isn’t pretty.

Meanwhile, up in Canada, there's been a fair bit of talk about how Dawson College computer science student Ahmed Al-Khabaz was expelled for discovering a security hole in a system used across many Canadian colleges to store personal data of students. In his case, part of the problem was that, after alerting people to the hole, he went back a few days later to run a script to see if they had closed the hole. This caused the company that managed the system to accuse him of criminal activity:

“It was Edouard Taza, the president of Skytech. He said that this was the second time they had seen me in their logs, and what I was doing was a cyber attack. I apologized, repeatedly, and explained that I was one of the people who discovered the vulnerability earlier that week and was just testing to make sure it was fixed. He told me that I could go to jail for six to twelve months for what I had just done and if I didn’t agree to meet with him and sign a non-disclosure agreement he was going to call the RCMP and have me arrested. So I signed the agreement.”

Even with the signed agreement, Dawson expelled him. While Dawson stands by its decision, the company Skytech says that it's now offered to hire him part time.

Yes, in all three of these cases you can make a case that what the individual did went further than others would go. Some might call it discourteous. Swartz downloaded a lot more than the system intended, even though the network was open and the terms allowed for unlimited downloads. Auernheimer didn't just find the hole, but he scraped a bunch of data and sent some of it off to a reporter. Al-Khabaz didn't just find the security hole, but he also went back and probed the system again later. But, in the context of someone who lives in this kind of world and understands technology, all three represent completely natural behavior. If the technology allows it, why not probe the system and see what comes out? It's the natural curiosity of a young and insightful mind, looking to see what information is there. When it's made available, how do you not then seek to access it?

But there is a fundamental disconnect between an older, non-digital generation who doesn't get this. They think in terms of walls and locks, and clear delineations. The younger generation, the digital native, net savvy generation looks at all of this as information that is available and accessible. The limitation is merely what they can reach with their computer. But this isn't a bad thing -- this is how we discover new things and build and learn. Treating that as criminal behavior is insane and backwards. It's trying to apply an analog concept to a digital world, and then criminalizing exactly what the system allows and what we should be encouraging people to do -- to push the network, to explore, to learn and to access information.

This is a culture clash, of sorts, but it represents a real problem, when we're criminalizing the most curious and adept computer savvy folks out there.

Filed Under: aaron swartz, access, ahmed al-khabaz, andrew auernheimer, apis, data, hacking, information, war on computing

Does Google Have What It Takes To Be A Platform, Rather Than A Product, Company?

from the the-challenge-is-(still)-on dept

Nearly seven years ago, I wrote about the idea that there was a "battle to own the internet," and that if Google really wanted to succeed, it had to move away from just being a product company to being a true platform company that had a much more open setup, which did much more to encourage developers to build on top of it. Over the years, occasionally I've repeated that point. And while Google has done a few things at the margin, it still has always seemed to resist becoming a true platform. There are, certainly, some folks inside Google who get this, and I seem to hear from a bunch of them any time I bring this up. But the company has a history of having trouble really opening up to outside developers.

So it's really interesting to see this "internal" note from Google employee Steve Yegge, that he accidentally posted publicly via Google+. It's a very detailed and honest criticism of the company's attitude on certain things, but not done to slam Google, but rather to push Google to change. It's getting tons of attention, and Yegge removed the post, but has allowed others to keep up a reposted version. He's also pointed out that Google PR was careful not to pressure him to take down the post, noting that employees are free to express their opinions.

Some have been reading it as an insider's "attack" on Google, but I don't see that at all. It seems like a call to action from someone who thinks the company is missing the boat on being a platform. Yegge spends a lot of time talking (very openly) about his prior experience working at Amazon, and about how Jeff Bezos got the "we need to be a platform" religion big time nearly a decade ago, and effectively forced the entire company to focus on that as job number one. While Yegge criticizes many problems with Amazon, he does recognize that such a vision has put Amazon in a good position (along with others who have clearly embraced being "the" platform: Facebook, Apple and, almost by accident, Microsoft).

The key part of the post, which is what many people are focusing on, is where Yegge criticizes Google+, and how it wasn't designed as a platform, whereas its main direct competitor, Facebook, has clearly embraced being a platform in a very meaningful way.

Google+ is a prime example of our complete failure to understand platforms from the very highest levels of executive leadership (hi Larry, Sergey, Eric, Vic, howdy howdy) down to the very lowest leaf workers (hey yo). We all don't get it. The Golden Rule of platforms is that you Eat Your Own Dogfood. The Google+ platform is a pathetic afterthought. We had no API at all at launch, and last I checked, we had one measly API call. One of the team members marched in and told me about it when they launched, and I asked: "So is it the Stalker API?" She got all glum and said "Yeah." I mean, I was joking, but no... the only API call we offer is to get someone's stream. So I guess the joke was on me.

Microsoft has known about the Dogfood rule for at least twenty years. It's been part of their culture for a whole generation now. You don't eat People Food and give your developers Dog Food. Doing that is simply robbing your long-term platform value for short-term successes. Platforms are all about long-term thinking.

Google+ is a knee-jerk reaction, a study in short-term thinking, predicated on the incorrect notion that Facebook is successful because they built a great product. But that's not why they are successful. Facebook is successful because they built an entire constellation of products by allowing other people to do the work. So Facebook is different for everyone. Some people spend all their time on Mafia Wars. Some spend all their time on Farmville. There are hundreds or maybe thousands of different high-quality time sinks available, so there's something there for everyone.

Our Google+ team took a look at the aftermarket and said: "Gosh, it looks like we need some games. Let's go contract someone to, um, write some games for us." Do you begin to see how incredibly wrong that thinking is now? The problem is that we are trying to predict what people want and deliver it for them.

This part rings incredibly true. I know that when Google+ launched, I liked it as a program, but asked people about APIs, because it needed to better integrate into my workflow -- and was told that that would be coming "sometime later." And while I still mess around with Goolge+, it's largely become an afterthought to me, because it just lives off in its own separate world, rather than integrating well. There are still features I like, but until developers have a chance to dive in and make it useful... it just doesn't feel like a necessity.

But there's a bigger lesson in this, beyond Google's continued platform-itis. And it goes back to the issue of cargo cult copying -- a topic I've discussed a number of times. People seem to think it's easy for companies (especially big companies) to "copy" products of their competitors. In fact, with Google, many people think it's so easy that there are antitrust investigations going on. But Google+ and the points that Yegge raise remind us, yet again, that while copying the basic "features" of a product may be possible, really recreating what makes it tick and what makes it successful is difficult.

It's easy to copy the superficial. It's difficult to copy the soul.

With Google+, the company built a really nice copy (with some clear improvements) of Facebook, the product -- which is the superficial, public-facing part. But it completely missed the boat on Facebook, the platform -- which is the real soul of what makes Facebook such a powerhouse. Google certainly can get there. And, in the back of my mind, I'd always assumed that was exactly the path they were on. But remembering that post from 2004, and the lack of any sustained, involved effort within and across Google to be a platform, combined with this post from Yegge, again makes me wonder if Google just doesn't recognize the importance of being a platform.

I've argued in the past that one big achilles heel for Google is its awful reputation when it comes to customer service, but it's lack of deeply ingrained platform-focused thinking may represent a much bigger threat.

Filed Under: apis, platform, product, services, social networking, steve yegge
Companies: amazon, apple, facebook, google

Side Show In Oracle, Google Patent Fight: Are API's Covered By Copyright?

from the we-may-find-out dept

While the main event in the Oracle lawsuit against Google is around patents, there is an interesting copyright sideshow as well, focused on the question of whether or not Oracle can copyright an API. A couple weeks ago, Google filed for summary judgment on this, noting (among other things) that Sun's own CTO had flat out declared that "internet specifications are not protectable under copyright," prior to Oracle buying out Sun. The other key claim is that even if Google copied the API, the accusation has them copying 12 files out of over 50,000, which would qualify for de minimis copying, which is a common defense against minimal copyright infringement.

Oracle has now responded and is arguing that copyright for APIs is perfectly reasonable, claiming that the APIs "contain many original and creative elements." Just as Google quotes a former Sun CTO, Oracle (somewhat snarkily) quotes a current Google employee (and former Sun employee) in noting, "API design is an art, not a science."

As Groklaw notes in the above link, Google probably won't win on the motion for summary judgment on this issue, even if it has a better chance at trial:

Although we don't buy all of Oracle's arguments (most importantly, we don't believe much of what they assert is copyright protected subject matter is, in fact, protected by copyright, such as API's), Oracle has probably done enough in its response to put the issue of copyright infringement before a jury. Of course, the court still needs to rule on Google's summary judgment motion.

Indeed. I have trouble seeing how APIs can be covered by copyright. Oracle's key argument beyond that misleading quote is that creating a good API is "difficult." Difficulty alone does not determine if something is copyrightable, of course. Either way, allowing for copyright claims on APIs seems like a good way to create a lot more problems for important (legal!) things like reverse engineering. Once again, it seems like stupid intellectual property laws may get in the way of important methods for innovation.

Filed Under: apis, copyright
Companies: google, oracle, sun

UK National Rail Threatens App Maker For Even Discussing His Train Time App

from the it's-better-if-people-don't-know-the-train-times dept

Last year, we had a discussion about all of the various transit authorities that had been threatening various app makers for creating rather useful train schedule apps for mobile devices. Now you might think (if you thought) that transit groups would be thrilled with such apps, which would make taking the train easier and more convenient. And, really, when you realize that others would be building these apps that get more people to take the train, without you even having to pay them as developers, it sounds absolutely great for the folks who make the trains run. If they thought. But, apparently, thinking is not a pre-requisite for some of these jobs, and many of them couldn't think beyond "those apps use our data" and freaked out. In some cases it was because the train operators wanted to license the data. In some cases it was because they were offering or building their own, competing, app.

National Rail, in the UK, seems particularly short-sighted about this, and now they're taking it even further, threatening people for even talking about their threats. Glyn Moody points us to the news that a developer, Alex Hewson, who had created a web (not mobile) app that used National Rail's open API, which was even listed in the government-run list of open data feeds that developers are encouraged to make use of, who was first told to shut down the app (a year after it had been running). The backstory here is even more ridiculous. Even with the open API, Hewson sent a note to the National Rail asking if it was okay if he turned his web app into an Android app -- and charged enough to cover the costs of development. At first he received no response, so he sent another letter, and finally got this response:

"I can confirm the National Rail Enquiries Website is for personal and non-commercial use only. Therefore, the suggestion made in your letter, to utilise the data to build an Android application is expressly prohibited. I'm sorry that we cannot be of any further assistance."

Based on that he killed the Android app idea -- even though the response is a bit odd, as it implies that any Android app is automatically a "commercial use." Either way, apparently National Rail is now working to lock up the API, and quietly put up a note saying that to use it, you would soon need to use "tokens" which you could only get with a license. Hewson only discovered this after a friend pointed it out, so Hewson sent a friendly note to National Rail asking for a token, noting that his app was purely non-commercial. He also asked if there was some mailing list he could sign up for, so he wouldn't be surprised by such things.

Instead, he got a demand that he immediately shut down his app, and a haughty claim that "there has always been a requirement for a license to use this service." Of course, as Hewson pointed out, that contradicted what the National Rail had told him earlier. The author of the note, Derek Parlour, also noted that it was "highly likely" any license would require a fee. Of course, that seems strange. That's because in response to an article from Wired criticizing National Rail's refusal to open up its data, National Rail's chief executive, Chris Scoggins, scolded Wired saying:

It isn't true that National Rail Enquiries (NRE) refuses to open up its data feeds.... We've opened up our data to a range of organisations, often free of charge, so they can provide information about trains.

That seems to to contradict Parlour's comments. That led to Hewson trying to reach Scoggins via a comment on Scoggins blog. Scoggins replied -- not by admitting to a mistake, or by fixing things and allowing this app which (again, must we remind everyone?) makes it more convenient for people to take the train, but by threatening Hewson for publishing Derek Parlour's original email, claiming that it was "confidential."

So, not only can you not use the "open" API (that Scoggins himself claims is open, despite it not being so), you also can't even discuss the contradictory and misleading statements made by National Rail employees. Hewson admits that there was a confidentiality statement on the email, but just like in another recent story about someone in the UK relying too much on a poorly written confidentiality notice, the National Rail's confidentiality notice only says you can't share it if you're not the intended recipient. Since he was the intended recipient, the confidentiality policy clearly states he is free to share it.

As it stands, it sounds like Hewson may be giving up on the app. He can't even get a direct answer to the simple question of whether or not he needs to shut down the existing app (which, yes, I'll say it again, is being used to help more people use the train) while they discuss any kind of licensing deal. No matter how you look at this, National Rail appears to be making a series of really ridiculously bad moves here. Not opening up the data is just the first mistake. Then trying to abuse confidentiality policies, along with having inconsistent overall policies, just makes the entire operation seem like a mess.

Filed Under: apis, apps, data, open access, uk
Companies: national rail

Wait, So The RIAA Is Offended That Google Won't Do Work For Free?

from the i-thought-free-was-bad? dept

The RIAA and the IFPI have been going on and on for years about just how ridiculous it is for people to suggest music should be "free." They will go on, at great length, to talk up the "value" of music and how it should be paid for. But, apparently, they don't think that applies to anyone else. They're apparently screaming angry at Google because Google (gasp) responded to their request to provide them tools to help them track down unauthorized copies, by quoting their standard prices for how much it costs to use Google's API. So, RIAA, please explain: why is it sacrilege for you to demand people pay up, but it's even worse if Google asks you to pay to use its resources?

Filed Under: apis, copyright, fees, policing, search engines
Companies: google, riaa