App Developer Legal Issues: API TOUs, Copyright and Trademark

Copyright and trademark rules are sometimes obvious, but the platforms universally require covenants from developers that they actually own the intellectual property rights to their software.  But they also create contract commitments that can override traditional copyright and trademark rules such as fair use.


First, copyright.  A good example is use of the Flickr API, where at least one developer has argued that fair use allows him to freely republish thumbnails of user photos from Flickr.  He may have a valid fair use argument because of cases such as Kelly v. Arriba Soft Corporation from 2003 and the more recent cases of Perfect 10 v. Google and Perfect 10 v., but he is still breaching his contract commitment to Flickr (under Flickr’s API Terms of Use) which prohibits such use.

Copyright also is at stake when a developer uses previously copyrighted material from third parties in his app.  Neither Apple’s SDK nor most API Terms of Use make any distinction for fair use, instead simply requiring ownership of rights whether by actual ownership or by valid license.  When using video, music or other software in an app, fair use arguments are tricky because the platform itself likely will honor validly-submitted takedown demands for copyright infringement under the Digital Millennium Copyright Act (DMCA).  Fair use can be a valid defense to a claim of copyright infringement, but a practical problem is that the platform may give a presumption of validity to the copyright owner pending resolution of the dispute – and remove the app.

One more copyright comment: Even novel execution may not buffer against a valid copyright claim.  An example is an app based on a PC or desktop or console version of an existing game or application.  Development for the new API may very well involve extensive coder innovation, where the code is substantially dissimilar to the original.  Nonetheless, the original is copyrighted, and the new version may very well be deemed a “derivative work”, protected by the copyright law’s grant of exclusivity to the owner, and therefore infringing.


Next, trademark.  First, the obvious: trademark law gives certain exclusivity of use prior registered trademarks, and app development cannot infringe a prior registered trademark.

And even if not infringing copyright, use of the same or a similar name to an existing registered trademark (the standard under 15 USC 1114(1)(a) is “likelihood of confusion”, see a good discussion on what this means here) can infringe that trademark.  So even if an app is dissimilar from another app, deceptive names – closely resembling the trademarked name of another app – can trigger trademark problems.

The more interesting problem is understanding when trademark is actually infringed.  Trademark is in some ways synonymous with brand-building, and infringement is based on confusion as to the owner: If an application is deceptively misleading as to its source or origin, it can infringe a trademark even if the app is branded under a different name than the trademark.

This restricts distribution of an app that is, in everything but name, the same as another app.  But an app may infringe and not be the same but merely suggestive.  How so?  Look and feel, layout, color scheme, suggestively similar text, fonts, and on and on.

As with copyright, most API Terms of Use (and Apple’s SDK) typically require representations of trademark non-infringement.  They also restrict use of the platform’s trademarks, say, for example using the “Skype” name in your app.  And again similar to copyright, fair use rights under trademark law – which typically permit use of a trademark for “nominative” purposes, meaning simply to identify the trademark without implying any endorsement – may be trumped by contract terms of the API.

So, for example, Skype’s API Terms of Use limit references to “Skype, Skype API and Skype Software” to:

“works with Skype Software” or “works with Skype”

“uses Skype Software” or “uses Skype”

“for Skype Software” or “for Skype”

The point is avoiding the perception of endorsement by the platform, and Skype makes this explicit, requiring prominent display of this additional statement: “This product uses the Skype API but is not endorsed, certified or otherwise approved in any way by Skype.”

Add Comment