Got user created content plus an API? Be sure to plug your copyright hole.

Yesterday, I was extolling the policy virtues of automation at VON 2007.  Today I was reflecting that until super-intelligent agents arrive and do it for us, humans need to be sure to actually read the documentation attached to the APIs enabling some of the most compelling automated transactions and interactions we see today.

I spent the day at Under the Radar, which lived up to its reputation as a very cool event.  Dan Farber blogged much of the coolness, and I Twittered some as well.  But one thing caught my attention as a slumbering yet big issue for Live Web companies:  if you offer an API, and well you should, people are going to use it.  However, they might not be all that careful about reading and following your API's terms of service — assuming, and let's hope it does, your API has terms of service.  This is true even when the people using your API are in another part of your very own company.  (See:  OUTRAGEOUS: Yahoo!™ STEALS copyrighted photos from Flickr users!)

Consider this scenario: 

1. Site 1 provides a platform for submission and sharing of user generated material.
2. Site 1 offers APIs enabling third party mashups of Site 1's user submitted material in heretofore unimagined, creative ways. 
3. Site 1 neglects to give users the means to affirmatively license their submitted material for third party use; or, a large number of users decline to license, even though given the chance.
4. Site 1 fails to warn Site 2 (and Sites 3 - infinity) that some or all of its users' submissions are not licensed for third party use.
5. Site 2 develops an application, using Site 1's API to make Site 1's user submitted materials available for use or viewing by Site 2's users.
6. Mayhem, outrage, rioting in the streets, denial of service attacks, etc. ensue, instigated by Site 1's ticked off users.

There's a twofold lesson here.  First, if you're going to make user submitted material (ex)portable and mashable through an API, provide a licensing mechanism for your users.  While you're on the right track when you "encourage users to contribute their creations to the public domain or consider progressive licensing terms," Ev and Biz, as a practical matter without a convenient and automated means to apply such terms everything users submit will be "all rights reserved."  Flickr's incorporation of Creative Commons licensing means developers using the Flickr API can readily incorporate tens of millions of Creative Commons licensed works into their products and services.  I'm not sure developers using, for example, the Twitter API (checked out Twittervision yet?  mesmerizing) can incorporate any Creative Commons licensed works — and that's not because Twitter users don't want to license their work.

Second, API terms of service should alert developers to this napping but particularly grumpy grizzly.  Flickr's does this nicely:

1. Licensed Uses and Restrictions.

The Flickr APIs are owned by Flickr and its parent company Yahoo! Inc. (hereinafter "Flickr") and are licensed to you on a worldwide (except as limited below), non-exclusive, non-sublicenseable basis on the terms and conditions set forth herein. These terms define legal use of the Flickr APIs, all updates, revisions, substitutions, and any copies of the Flickr APIs made by or for you. Flickr user photos are owned by the users (the photographers) and not by Flickr. All rights not expressly granted to you are reserved by Flickr.

a. You shall:

1. Comply with the Flickr Community Guidelines at www.flickr.com/guidelines.gne, the Flickr Terms of Use at http://www.flickr.com/terms.gne, and the Yahoo! Terms of Service at http://docs.yahoo.com/info/terms/.
2. Comply with any requirements or restrictions imposed on usage of the photos by their respective owners. Remember, Flickr doesn't own the images - Flickr users do. Although the Flickr APIs can be used to provide you with access to Flickr user photos, neither Flickr's provision of the Flickr APIs to you nor your use of the Flickr APIs override the photo owners' requirements and restrictions, which may include "all rights reserved" notices (attached to each photo by default when uploaded to Flickr), Creative Commons licenses or other terms and conditions that may be agreed upon between you and the owners. In ALL cases, you are solely responsible for making use of Flickr photos in compliance with the photo owners' requirements or restrictions. If you use Flickr photos for a commercial purpose, the photos must be marked with a Creative Commons license that allows for such use, unless otherwise agreed upon between you and the owner. You can read more about this here: www.creativecommons.org or www.flickr.com/creativecommons.
3. Comply with any other terms and conditions a user has attached to his or her photo. For example, if a user marks a photo as "private" after using your service, your application must reflect those changes as soon as reasonably possible. If your application has any cached copies of photos that have become "private," you must remove as soon as reasonably possible.
4. Remove from your application within 24 hours any Flickr user's photos or other information that the owner of the photo asks you to remove.
5. If you use the Authentication APIs, insert a standard header that we will provide into pages you build that access the Flickr API. It's important to us that users have an easy way to return to Flickr if they wish, and have some reference point (the logo) to show them that they're still connected to Flickrland. http://www.flickr.com/services/partners/.
6. Disclose in your application through a privacy policy or otherwise displayed in the footer of each page, how you collect, use, store, and disclose data collected from visitors, including, where applicable, that third parties (including advertisers) may serve content and/or advertisements and collect information directly from visitors and may place or recognize cookies on visitors' browsers.

These terms, by the way, are right in line with the principles of the Attention Trust; bravo, Flickr.   

"Flying and virtual" contracts like machine readable licenses are absolutely fantastic.  Please just make sure that in our exuberance to encourage uptake and creativity through APIs, we don't make the mistake of forgetting about such licenses altogether, or of remembering them when it comes to user submissions but forgetting when it comes to API documentation and use.