Code, and other laws... (part 1)

There are tens of millions of RSS and Atom feeds published on the Web.  And nearly all of them are copyrighted.

If an author doesn't explicitly give up all rights to a work, which might be a bit tricky, it's automatically copyrighted in the United States and most other countries.  Of course the same is true of web pages.  But web pages are mostly intended to be viewed in a browser.   Feeds are generally intended to be syndicated, which means that their content is going to be sliced and diced in various and unforeseeable ways.  This makes a difference.

In what ways is an application allowed to copy and present a given feed's content?  To start with, it can do things covered by fair use (*).  There are some interesting issues around what exactly fair use means in the context of web feeds, but ignore those for the moment.  What about copying beyond what fair use allows? 

It would be awfully helpful if every feed simply included a machine readable license.  For example, a <link rel="license" href="..."/> element (http://www1.tools.ietf.org/wg/atompub/draft-snell-atompub-feed-license-00.txt).  We could then write code that follows the author's license for things beyond fair use.

Specifically, if a feed author wanted to put their feed content in the public domain, they would simply link to the Creative Commons public domain license which includes the following RDF code:
<rdf:RDF xmlns="http://web.resource.org/cc/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<License rdf:about="http://web.resource.org/cc/PublicDomain">
<permits rdf:resource="http://web.resource.org/cc/Reproduction"/>
<permits rdf:resource="http://web.resource.org/cc/Distribution"/>
<permits rdf:resource="http://web.resource.org/cc/DerivativeWorks"/></License></rdf:RDF>
The code here is a machine-readable approximation of "put this in the public domain". 

Alternatively, if a feed author just wanted to require attribution, they'd instead use http://creativecommons.org/licenses/by/2.5/.  To allow copying for non-commercial use only, they'd use the popular http://creativecommons.org/licenses/by-nc/2.5/.  This license means that the content must be attributed, and may be freely copied only for non-commercial uses.   Plus, of course, fair uses.

According to the Creative Commons proposed best practice guidelines, the non-commercial license would mean that a web site re-syndicating the feed would not in general be able to display advertisements next to the feed content.  Such an application could fall back to fair use only for that feed (perhaps showing only headlines), or it could suppress ads for that one feed.  The main point is that it would know what it needed to do.

So, in this perfect world where everything is clearly licenced, I think life is fairly simple.  Let me know if you think I'm missing something.

In part 2 I intend to return to the messy real world and start complicating things.
--
(*) ...or other applicable national legal codes, since fair use applies only in the U.S. as Paul pointed out.

Tags: Feed Copyright

"Yet another departure from AOL's infamous 'walled garden' days."

I think there's some API momentum building: The I Am Alpha site is officially announced and getting good reactions.  Greg just linked to the IAmAlpha blog.  I'd like to note that the developers have been working from the start with the microformats community to make everything as open as possible.

Tags: AOL I+Am+Alpha APIs

AIM SDK

The AIM guys just announced the Open AIM SDK.  Very cool; you can do AIM Triton plugins or write your own AIM network client.

New Feature: Common Feeds Icon

Another update to Journals this week was the switchover to the Common Feeds Icon (). This is the same icon used by Firefox, and soon Internet Explorer and Opera.  Also, AOL's Favorites Plus.  It's also being adopted by web sites at an astonishing rate.

(Why a new icon to indicate feeds?  Because "RSS" doesn't exactly scream "dynamic feed of updates for this web page".  And lots of people our testing thought the tiny icon said "R55", which is even more useless.)

Rogers Cadenhead has a nice discussion here (see the comment thread too).

There's a debate over whether this icon should indicate an action (subscribe to this feed) or be a link to the feed resource (see the feed, and maybe subscribe).  I personally don't think this is a huge issue, as long as a user isn't left staring at XML source.  If an application only lets you do one thing with a feed, jumping directly to subscribing seems like a good idea.  If you can do multiple things, give a menu of some kind (like Journals does) or a preview with options... humans can figure it out given reasonable feedback.  Machines can't, but then they're not looking at the icon, they're looking at the <link rel="alternate" type="application/atom+xml" ...> markup in the page header.

Also, they're called "feeds".  Doesn't matter if they're RSS 0.91, RSS 0.92, RSS 1.0, RSS 1.1, RSS 2.0, RSS 3.0, or Atom.  And it really doesn't matter that they're in XML (well, except for RSS 3.0 :) ).  What matters is that you just look for the if you want to keep track of what's new.  Simple.

New Feature Demo: Flickr Photos

One of the little things we did for our latest update was to open things up a little bit to allow some types of iframes inside entries -- basically iframes from trusted sites.  We'll be adding to the list of allowed sites as we go forward.  Right now Flickr makes for a great demo: