Will or could RSS get forked?

Last year, Microsoft came out with an extension to RSS called Simple Sharing Extensions  or SSE.  Microsoft wisely published the extension under the Attribution-Share Alike Creative Commons license -- the same license under which RSS is freely usable.  Back in November 2005, Dave Winer, who is widely regarded as the father of RSS, praised the move in his blog.  Microsoft consulted with Dave prior to announcing SSE.  

Last week, while I was on vacation, I noticed that Dave Winer picked up on how Buy.com has extended RSS with a namespace.  Buy.com is calling it "Product RSS."  According to Buy.com's Web page about Product RSS:

"Product RSS" is a new RSS module that supplements the enclosure capabilities of RSS 2.0. RSS enclosures are already being used to syndicate featured products and their images. Product RSS extends enclosures to handle specific Buy.com product information as individual elements of data so the consumer of the feed can reformat or use the information the way they desire.

As a side note, most of us social networking hacks will recognize RSS enclosures as the operative feature of RSS that enabled podcasting.Hopefully, as these and other extensions and interfaces arise, they won't be saddled with stifling encumbrances.   More importantly, though, I don't see any disclosures (not to be confused with "enclosures") regarding the terms under which other online retailers could use Buy.com's extension.  I'm not saying they can't.  There's just no disclosure which adds a slight cloud to the statement "Product RSS extends enclosures to handle specific Buy.com product information as individual elements of data." Legally speaking,  specific Buy.com product information sounds very Buy.com specific.

Law and data structures are a pretty hazy area for me and I'm not exactly certain where the control points might be, but this example of where Buy.com is extending RSS to integrate with its product database seems to enter the territory of data schemas -- particularly XML schemas since XML is involved -- where intellectual property is known to be a thorny issue.

It was bad enough when, by virtue of precedent law (established in a landmark 1981 Supreme Court case), the US Patent and Trademark Office was forced to allow software patents.  But now that the definition of software has been stretched to include data formats (as in the formats of data when ushered across a system and/or network busses using a protocol or when accessing information at rest in a file or a database) and just about everything else under the sun, significantly more clarity and disclosure is required when such extensions are published by third parties like Buy.com.  Especially when two vaguely or more deliberately intertwined tiers are involved where one tier (the API) seduces the developer into using the second (a specific data format) where either could be encumbered with restrictions now or in the future.  With Microsoft, SSE is free for use with non-Microsoft schemas.  But is that the case with other extensions? I'm not saying it isn't.  But it's hard to tell if it is.

Perhaps that point takes on even more meaning given the recent news from Google.  Recently, I noticed from fellow ZDNet blogger Richard MacManus that Google now has its own extensions to both RSS and Atom.  Through Jeff Jarvis, Dave noticed this announcement as well.  But the problem is that silence on the issue -- be it from Buy.com, Google, or any other third party that decides to extend RSS (and there will be others) -- is forboding.  Google's Web page on "GData" (as Google wants it known) makes no mention either way (free/open or encumbered) on the legal terms and conditions. Terms and conditions are however listed with one of the services (Google Calendar) that will be accessible through GData.  Those terms and conditions very clearly state:

...you agree that you will not copy, reproduce, alter, modify, or create derivative works from the Service. You also agree that you will not use any robot, spider, other automated device, or manual process to monitor or copy any content from the Service. The Google Rights include rights to (i) the Service developed and provided by Google; and (ii) all software associated with the Service. 

I boldfaced "software" because it's an ambiguous catch-all term that, left undefined in a license, offers extremely broad protection to any licensor that uses the word in its licenses. As I indicated earlier, the term "software" can and has been stretched to include just about anything in the technology business. 

But even more worthy of discussion is how conflicting license language could result in a forked syndication standards.  Suppose, for example, two or more of these extensions start to get serious traction in the market to the point they start to earn de facto status.  Let's say you want to use Microsoft's SSE extensions in conjunction with Google's GData extensions to synchronize calendar data using a third party (non-Google repository).  I'm not a lawyer. But from the looks of the aforementioned proviso found in Google's license, copying content (which synchronization would do) is not allowed. 

Right now, somewhere out there is someone saying I'm an idiot because no programmer would ever use SSE and GData together.  That could very well be the case but it's not germane to my point.  Substitute GData for Buy.com's Product RSS and build some sort of real-time comparison shopping service that hurts Buy.com's business with its own technology and things could theoretically change.  Sooner or later, absentee or conflicting licensing language around all of these extensions and the schemas they integrate with could produce the sort of proprietary stovepipes that could lead to unfair advantage as well as the bi or trifurcation or even worse, an outright co-opting/hijacking of a standard.

To reality check these concerns, I checked in with Sun's director of Web technologies Tim Bray.  Bray is the co-inventor of XML (the markup language used in both Atom and RSS).  The interview is available as an MP3 that can be downloaded, or, if you’re already subscribed to ZDNet’s IT Matters series of audio podcasts, it will show up on your system or MP3 player automatically (See ZDNet’s podcasts: How to tune in). Said Bray in the interview:

The problem isn't syndication specific.... in general, if somebody produced a set of extensions that produced some useful purpose and a lot of people started using it and then it developed that there was some lock-in dimension whether it were legal or just by technology -- it didn't work unless you used their software -- well that would be a problem and yes, there's no reason to think that somebody with nefarious purpose wouldn't try and do such a thing.

I would tend to trust the court of public opinion to some extent. I think that syndication is a space which has thrived on relatively absolute openness and nobody to my knowledge has every successfully managed to put up a toll both on traffic in the syndication space. I suspect that there's a healthy level of paranoia that would prevent people from getting away with too much. Assuming that somebody did try something that had a lock-in agenda, I don't think it would be the schema that would be the pain point. It would be more like the semantics of the protocol or the application.  The schema is not a very interesting part of the picture.  

 

Bray did however agree that lack of intellectual property disclosure is problematic and that more disclosure is necessary.

Hopefully, as these and other extensions and interfaces arise, they won't be saddled with stifling encumbrances.  I agree with Bray that, of the ones so far discussed, they will probably remain unencumbered.  Thus, this blog entry isn't designed to be a red flag or to falsely accuse anyone of nefarious intent.  It is however (1) a warning to all developers to proceed with caution in situations where the rules aren't blatantly posted and (2) a suggestion to API providers to over-communicate and over-link to their policies and their intent if adoption is what they're ultimately after.