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.

from the you-don't-need-a-registered-trademark dept

A few days ago, Twitpic, which was the original third party service for hosting images for your tweets, announced that it was shutting down "unexpectedly" because Twitter was threatening to pull its API access if the company didn't drop its trademark application for Twitpic -- an application that had been pending since 2009. Considering that Twitpic was one of the earliest of many third party services built on top of Twitter that helped make Twitter so valuable in the early days, it's certainly disappointing to see it go. It's also something of a legacy reminder that Twitter has been slowly, but surely, destroying all such third party services that helped make it so popular. That's disappointing, if not all that surprising. Platforms all too frequently end up swallowing those who rely too strongly upon them -- and, these days, to be honest, there's little reason to use Twitpic instead of Twitter's own image hosting (or some other options as well).

It's even more disappointing that this is all happening over a trademark dispute. Back in 2009, in fact, we highlighted Twitpic as one example (of a few) of how Twitter seemed to take a very open attitude towards its trademarks and let the various companies building on its platform make use of different forms of "twitter" and "tweet." A year later, the company was even more explicit in offering "free" licenses for its trademark for third party services. That's pretty clearly changed these days, and building Twitter as a more closed system where all of the innovation has to come from within, rather than from third parties, is unfortunate (and potentially quite limiting for the future).

All that said... I'm really not sure I buy this excuse for why Twitpic is shutting down:

We originally filed for our trademark in 2009 and our first use in commerce dates back to February 2008 when we launched. We encountered several hurdles and difficulties in getting our trademark approved even though our first use in commerce predated other applications, but we worked through each challenge and in fact had just recently finished the last one. During the “published for opposition” phase of the trademark is when Twitter reached out to our counsel and implied we could be denied access to their API if we did not give up our mark.

Unfortunately we do not have the resources to fend off a large company like Twitter to maintain our mark which we believe whole heartedly is rightfully ours. Therefore, we have decided to shut down Twitpic.

But... that makes no sense at all. Twitpic does not need a registered trademark in order to stay in business. It has no need to fight Twitter on this, and if its concern is the legal fees, why not just drop the whole trademark application. Registered trademarks have some uses, but common law trademarks are nearly as powerful for most important cases. Twitpic could easily just drop the trademark application process (saving legal fees there as well) and stay in business. The idea that you need a registered trademark makes no sense. The idea that you'd shut down the entire business just because Twitter opposed the trademark also makes no sense. It sounds much more like this was a convenient excuse for Twitpic to shut down while "blaming" Twitter for something, but without pointing out that the real problem might have been back when Twitter built in its own photo hosting service.

from the free-'em-up dept

In the wake of last week's horrible ruling saying that APIs are covered by copyright, we've pointed out that the negative impact on innovation could be massive, creating chilling effects concerning all sorts of development. Thankfully, at least some companies are being fairly proactive in distancing themselves from the crazy idea that APIs can be covered by copyright. Automattic, the makers of WordPress, just amended their API Terms of Use to make it explicit that they don't believe APIs are copyrightable subject matter, and they will not claim copyright on them:

[Update: 5.12.2014] One more thing – APIs like ours enable the kind of collaboration that makes the Internet great. We don’t think APIs are copyrightable subject matter, and don’t claim copyright in our APIs.

This is good to see, and hopefully we'll see other companies with APIs doing the same thing. It will help separate out companies that want to encourage open innovation -- from those who want to lock things down. In the end, perhaps this whole thing will even backfire on Oracle, as it makes people that much less interested in working on technologies from a company looking to lock up innovation.

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.

The Court confirmed that the way computer programs operate is not copyrightable. This is because computer program functionality is not "a form of expression" and therefore does not qualify for protection it said, ruling on a dispute involving rival software developers SAS Institute (SAS) and World Programming Limited (WPL).

"The ruling means that it will now be very difficult for software developers to challenge a competitor's software with identical functionality unless the underlying code for their software has been copied," intellectual property law expert Indradeep Bhattacharya of Pinsent Masons, the law firm behind Out-Law.com, said. "Even the general design, program interfaces and non coding structural elements of software are not protected by copyright. It is also not an infringement to take the ideas behind a computer program from its accompanying documents such as user manuals and technical specifications, though copying non technical descriptions would still be an infringement."

As that indicates, this is a strong affirmation that reverse-engineering software is legal, provided the code itself is not copied. It confirms an earlier decision by the Court of Justice of the European Union, whose opinion had been sought by the original UK judge that heard the SAS case. This multi-layered consideration of the key issues by different courts means that the question is pretty much settled across Europe.

However, one other part of the ruling by the UK Court of Appeal may offer a way for software companies to combat reverse engineering. The licensing agreement from SAS had not made it clear that the software could only be used by one person; this allowed others to study and test SAS's software with the aim of reverse-engineering its functions. Out-law.com points out how software companies can make this harder in future:

"In order to try to limit who can access learning or development editions of software products, companies may want to think about restricting who is the 'lawful user' of their software," Bhattacharya said. "This can be done by entering into the licence with individual users rather than the company. Doing this would help restrict the ability of rivals to have dedicated teams of people observing, studying and testing your software to develop alternative programs."

This shows once again how contracts can be used to add restrictions beyond what copyright law dictates. It will be interesting to see if software companies try to adopt this approach, and what effect it has. Meanwhile, we can be grateful for the UK Court of Appeal's sensible ruling that will allow competition and innovation to flourish, and we must hope that the US Appeals Court follows suit.

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.

“[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.

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.

from the ideas-and-execution dept

We're just about to start experimenting with a variety of new advertising setups here at Techdirt, which means we've been doing a lot of brainstorming about opportunities for creative, interesting campaigns in keeping with our philosophy that good advertising is good content. One thing we've been noticing over and over is that the most innovative online marketing pushes don't just come from the usual suspects (tech companies and online services) but also from unexpected places—like a century-old soup company.

This is your opportunity to revolutionize dinners everywhere: Develop a breakout idea based on the Campbell's Kitchen API that helps people decide: what’s for dinner tonight?

After seeing all the ideas, we’ll choose up to thirty semi-finalists and give them our API for three weeks to bring their ideas to life.

Up to ten finalists will then be invited to present their projects at Google’s HQ in NYC to compete for the championship and launch their ideas into the world.

It's a fantastic concept, and the API looks genuinely useful. Not only is the contest itself a great marketing opportunity, it's setting Campbell's up for ongoing exposure through the apps that are developed.

But, having said how cool this is from a marketing perspective, it's time for the disclaimer—and it's a big one. The moment you get past the initial idea and into the details, things really start to fall apart from an innovation perspective. Firstly, as you probably noticed, the API is not being opened up to the public—only to the contest semi-finalists. That severely limits the amount of innovation that will happen, and the amount of exposure the company will get as a result—it also limits the number of developers that will even want to participate. Unfortunately, Campbell's reason for this is clear: they intend to take total ownership of anything that comes out of this campaign.

In fact, they are so concerned about this that the fine print states the cash prizes ($25,000 plus a development contract for the winner, $10,000 to runners up) are not prizes at all—they are a fee for your work:

*Paid by Cambell for ownership of all ideas, concepts, code and intellectual property.

Setting aside the fact that you cannot own an "idea", this just stinks. On the one hand, it's not uncommon for creative contests to take ownership of submissions (though that's hardly universal), but it is the complete antithesis of what appears to be the spirit of this campaign: hacking and innovation. This is actually a big problem with corporate-run hackathons and coding contests, which frequently demand total ownership at the end. No smart developer with a truly great app idea would give it away for $25,000 for the copyright plus another $25,000 to build it—a popular app with a long tail can be worth way, way more than that.

There's nothing wrong with Campbell's trying to get an official app or two out of this—but when you look closely, the people who are submitting these ideas don't seem to be getting much in return. They want everyone to submit their best ideas for free, then they want 30 people to actually build those ideas—then Campbell's will plunk down $10k to take total ownership of any that "could be developed by Campbell in the future" (thus stopping all those runners-up from moving forward with their apps independently, and presumably cutting off their API access) and toss $50k to one developer to make their app market-ready. The winner gets an okay deal, while the runners-up pretty much get screwed.

So, for the next time Campbell's or another company tries a genuinely cool and innovative idea like this, I suggest a few tweaks to make the execution less distasteful. Firstly, open the API up to everyone, and leave it open; have sensible limitations like any public API, but let people build what they want. Secondly, give away modest but genuine prizes with no strings, while offering a bounty for ideas that you want to own without making that rights transfer a requirement of the contest. Thirdly, promote the submitted apps in a public gallery, and encourage all developers to move forward with building, deploying and marketing their apps—you'll get a hell of a lot more exposure, and you might even find your API becoming the de facto standard for such development.

In the mean time, to anyone eyeing the contest while an idea ferments in their brain, I suggest letting the Friday deadline for submissions lapse, and looking into some of the free and open recipe APIs to power your app.

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...