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:

Mashup Camp Concludes

Mashup Camp just concluded in the Computer History Museum.  A very nice, direct, simple mash-up -- PodBot -- won 'best mashup'; second prize went to the everyhing-you-ever-wanted-to-know-about-Chicago-crime-statistics mashup ChicagoCrime.org.  PodBot does just one simple thing but does it for data around the world; ChicagoCrime does lots of things for just one city and subject.  Also, PodBot is all about having fun and ChicagoCrime is about not getting killed.  Sort of a yin/yang thing.

The unconference itself was good.  A lot of good sessions conflicted, so I had some quandaries; but I think I made the best locally optimal choices possible.  No regrets.  The WiFi was good (better than most conferences with 250 people in a single room) but still not perfect.  But it wasn't too bad since there was little need for a backchannel.

Software Development's Evolution towards Product Design

Software Development's Evolution towards Product Design -- Danc Redmond writes a great article from the perspective of a product designer.  I agree with nearly everything he says, especially the need for small, unified, cross-functional teams.  A few minor caveats:

• Programming, done properly, is not a production activity that can easily be separated from product design.  If it could be, it's basically rote work that can and should be automated.  The non-rote work that programmers should focus on is all about figuring out how to hack the universe in order to deliver superior benefits to the customer.  Which is part and parcel of product design, which is why those small, cross-functional teams are so valuable.
  
• A big factor in game development and web design companies' successes was sheer volume and high competition.  There are plenty of terrible user experience in both camps (books have been written), but the industries have thus had a chance to learn from lots of successes and failures and iteratively improve. 
  
• Nit: The benefits summary is great -- 98% success vs. 18% success is a great statistic that can get business people to sit up and listen.  But y'know, this needs to be backed up with specific references to really pack the necessary punch.

In the past, most of the software industry has been busy creating dancing bears.  It's not how well the bear dances, but that it dances at all.  That is changing.  There will be some isolated refugia for internal corporate software, niche verticals, and bleeding-edge hardware interfaces where those clumsy dancers will survive and even thrive.  But the rest of the industry is going to start competing on more than bare functionality, and that will quickly shake out the companies which won't or can't adapt.