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.

Campbell's is running a very cool campaign called Hack The Kitchen, for which they've developed a full-fledged recipe searching API that pulls data from their Campbell's Kitchen repository.

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.

So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different. When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.

It is true that the very same functionality could have been offered in Android without duplicating the exact command structure used in Java. This could have been done by re-arranging the various methods under different groupings among the various classes and packages (even if the same names had been used). In this sense, there were many ways to group the methods yet still duplicate the same range of functionality.

But the names are more than just names — they are symbols in a command structure wherein the commands take the form java.package.Class.method() Each command calls into action a pre-assigned function. The overall name tree, of course, has creative elements but it is also a precise command structure — a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted. Duplication of the command structure is necessary for interoperability.

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

Clerk:

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

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

Question 2: not proven

1: no
20: no

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

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

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

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

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

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

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

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

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

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

Shortly after hearing of Bin Laden's unexpected mortal coil shuffling, Rob Domanski, who blogs as The Nerfherder, was informed of an archive of Osama Bin Laden-related tweets, all packaged up in handy XML format for use with DiscoverText software:

The datafiles were samples taken from live feed Twitter imports starting shortly after the announcement that Osama bin Laden’s death.

• Twitter searches for "bin laden" (647,585 documents, 505 MB)
• Twitter searches for "osama" (586,665 documents, 451 MB)

This was all for research purposes, however Twitter quickly shut down the project citing their Terms of Service (TOS) Agreement.

Stuart Shulman of DiscoverText had compiled the documents "using an authorized connection to Twitter via their API" which is apparently a violation of Twitter's API Terms of Service. He received an email from Twitter asking him to remove the datasets:

I'm writing about Twitter data being offered for sale on DiscoverText. Scraping the Twitter service is prohibited by our site Terms of Service, and furthermore, resyndicating data obtained through the Twitter API is prohibited by section I.4.a of our API Terms of Service (http://dev.twitter.com/pages/api_terms).

As such, we request you remove the datasets listed at http://discovertext.com/osamabinladen.aspx and any other datasets containing Tweets offered on your site.

Shulman responded:

Let’s be clear. We have never sold a Tweet. The data collected through the Twitter API and shared through our system is the same publicly available data other users capture with screenshots and share on blogs, Facebook or Twitter itself. Nonetheless, the datasets we have assembled and similar samples are being taken temporarily off the Web site pending a resolution of this issue with Twitter.

Well, "temporarily" has turned into "indefinitely." As of June 1st, Shulman's dataset contained 4.5 million Osama Bin Laden-related tweets, all of which can only be marveled at as a REALLY BIG NUMBER but not shared in any usable fashion thanks to Twitter's complaint.

If it's just a "policy first" decision on Twitter's part, it seems a little short-sighted. This information was (and is) of great interest to people worldwide. Perhaps some sort of warning could have been issued instead of a full takedown, thus allowing Twitter to assert its position on API usage without locking up the dataset. Once the dataset already exists, why block it? It's disheartening to see something with as much potential as Shulman's project getting thrown under the TOS bus.

"It is not our responsibility or duty to explain complex US Intellectual Property rights law, we however enjoy many protections from them. I suggest you hire an IP attorney to explain it to you. From your response, it seems to me you have no intentions of moving forward in a legal manner. We closely monitor any and all usage of our content and if we discover your unlawful usage of it, we will exercise our rights to their fullest extent of the law."