If the context isn't a Web page, can you legally hyperlink?
Although Jared Benedict has gone to some lengths not to characterize a letter he received as a nastygram, he and Jon Udell have apparently received the equivalent of take-down notice from the producers of This American Life (one of my favorite National Public Radio-broadcasted programs). The letter threatened legal action.
What had to be taken down? Context really doesn't matter. If the URL exists, you must acquit. It appears as though Udell and Benedict were pointing to This American Life-hosted MP3 files from some RSS feeds they had set up. In other words, although the RSS feeds may have been emanating from domains within their control, Udell and Benedict were only pointing to MP3 files hosted in another domain. They were not re-hosting those MP3 files.
Most people don't know or understand the underlying mechanics behind podcasts. Nor should they. But understanding them is critical to figuring out if there's a new legal test that podcasters and potential podcasters need to be familiar with. People usually take deliver of podcasts in one of two ways. They either download them manually much the same way they'd download any other MP3 through their browser or they use a podcasting client (also referred to as a podcatcher) to automatically retrieve the MP3s for them.
I use the terms "podcasting client" and "podcatcher" very loosely. Some software is dedicated to podcatching. Other software, particularly RSS reading software, just tacks podcasts on as another supported form of content (in addition to the text that normally comes through RSS subscription). Much the same way you point your RSS reader at some RSS feed to subscribe to it, you point your podcatcher at an RSS feed that, with each item that comes through it, includes the direct URLs to audio files on the Web. Here at ZDNet, the URLs (to the audio files) that we send through our podcast feeds are the same exact one that we provide in the text of the associated blog entries. For example, if you examined the RSS feed for ZDNet's IT Matters series of podcasts, you'll see that the URL it points to for my MP3-based interview of Doc Searls is same URL as the one I pointed to from the blog entry that discusses that interview (where I say it can be downloaded manually).
In our case, not only are we the producers of our podcasts, we also host them. So, no big deal. But what if you're neither the producer nor the original host of an MP3 file? Much the same way there's nothing that prevents me from pointing to any offsite URL (MP3, or not) from one of ZDNet's Web pages, there's nothing that physically prevents me from doing what Udell and Benedict did: point to MP3s hosted by someone else from their own RSS feeds. But is there something that legally prevents me from doing that as is suggested by the takedown letters?
Personally, I think not. Since all RSS feeds are also viewable with a Web browser (it's not a friendly view, but it's a view), you can argue that consumption context (browser vs. a podcatcher) is a user choice, not a publisher choice. So, if if it's OK to publish the URL in browser-viewable HTML, it should also be OK to publish the URL in browser viewable XML (how RSS feeds are encoded). Need more precedent? PDFs are not HTML. The architecture isn't all that unlike podcasting. An additional technology above and beyond something capable of understanding HTML (in PDF's case, a plug-in), is required to complete the content consumption process. Yet people point to third-party URLs from PDFs all the time. It's a slippery slope. If the lawyers tell us we can point to a link from HTML, but not from XML, what's next. Will they start to tell us we can't point from PDFs too?
Context really doesn't matter. If the URL exists, you must acquit. Otherwise, if you're putting MP3 files on the Web and you don't want someone pointing to them from the contexts of their choice, then, instead of sending takedown notices to that someone, take down the content itself. That way, nobody will point to it.