The Associated Press wants to track reuse of their content through a “news registry.” This registry “will employ a microformat for news developed by AP”:
The microformat will essentially encapsulate AP and member content in an informational “wrapper” that includes a digital permissions framework that lets publishers specify how their content is to be used online and which also supplies the critical information needed to track and monitor its usage.
While Creative Commons is very sympathetic to the difficulty of explaining technical concepts in a short press release, we’re worried that the AP’s explanation, and in particular their reference to the Creative Commons’ Rights Expression Language (ccREL), might well be confusing.
The reference to Creative Commons appears in the AP’s microformat, hNews, which introduces hRights, a supposed “generalization” of ccREL. hRights is presumably the “digital permissions framework” that the AP diagrams as a box/wrapper around news content in order to “track and monitor usage.” Unfortunately, as Ed Felten points out, this claim doesn’t add up. Microformats and other web-based structured data, including ccREL, cannot track, monitor, or generally enforce anything. They’re labels, i.e. Post-It notes attached to a document, not locked boxes blocking access to the content.
When Creative Commons launched in 2002, we were often asked “is Creative Commons a form of DRM?” Our answer: no, we help publishers express their rights, but we don’t dabble in enforcement, because enforcement technologies are unable to respect important, complex, and often subjective concepts like fair use. Thus, ccREL is about expression and notification of rights, not about enforcement.
And when you think about it, there’s really no other realistic way. If the AP actually wants a “beacon” that reports usage information back to the mothership, then every endpoint must be programmed to perform this beacon functionality. Before it delivers content, every server must check that the client will promise to become a beacon. Which means the AP wants an architecture where every cell phone, computer, or other networked device is locked down centrally, able to run only software that is verified to comply with this policy. That’s another reason why we don’t dabble in enforcement: the costs of Digital Rights Enforcement (or its politically correct equivalent, Digital Rights Management) to publishers, users, to our culture and to our ability to innovate are astronomically high.
Then there’s the issue of “RSS syndication” compatibility. We simply don’t see how the AP’s proposed system would allow both widespread beacon enforcement and compatibility with existing formats like RSS. Compatibility means that current RSS tools remain usable. Obviously, these tools do not currently perform the AP’s rights enforcement, so how could they magically be made to start phoning home now?
That said, there is an interesting nugget in the AP’s proposal, one which we encourage them to pursue: tagging content with rights, origin, and means of attribution is a good proposal. When Creative Commons began the work that led to ccREL, there were no established or open standards for expressing this type of structured information on the web, so we had to lay down some new infrastructure. When we published ccREL, we made it easy for others to innovate on top of ccREL: we included “independence and extensibility” as the first principle for expressing license information in a machine readable format. We based ccREL on RDF and RDFa to enable this standards-based extensibility.
The AP could, rather than reinvent a subset of ccREL using an incompatible and news-specific syntax, simply use ccREL and add their own news-specific fields. By doing this, they would immediately plug into the growing set of tools that parse and interpret rights expressed via ccREL. We would be happy to help, but we built ccREL in such a way that we don’t need to be involved if the AP would prefer to go it alone. And, of course, the AP can use ccREL with copyright licenses more restrictive than those we offer, if they prefer.
This greedy attack on the traditional fair use rights to news must never stand!
I looked at this press release, but didn’t see any reference to CC?
It did talk a bit more about enforcement than makes sense, particularly a ‘built-in beacon’; don’t see how that can be done. But the idea of tracking rights information with a view to enforcing it makes sense. Only thing is, even then, it’s pretty hard to determine *how* a work is being used, so you’re going to have a lot of trouble figuring out who to chase and who to ignore. Particularly if works are spread widely.
Ben, your link to the draft for hNews is not current: http://labs.ap.org/wiki/hNews is the current draft. I am still considering how to clearly describe the rights associated with a piece of news in a way both human- and machine-readable, and acceptable to the news industry in general. ccREL was attractive because of the history of the organization, the broad level of acceptance on the web, and the simplicity of the framework–the only issue was that there was no microformat syntax for ccREL. hRights was my first effort at describing the simple and powerful expressions of ccREL in a microformat.
It is on hold now (and reference from the news format proposal have been removed), while we consider alternatives. As you rightly point out, the intent was to take advantage of the growing set of tools that parse and interpret rights expressed via ccREL, without extension or modification, in order to tag content with rights, origin and means of attribution. The intent was to base it squarely on ccREL, given the work that was done on your May 2008 paper, but presented as a microformat to fit with our other efforts. Whether we continue to pursue that through ccREL, or the growing microformat license effort (http://microformats.org/wiki/licensing), is still up for discussion. Feedback like this gives us quite a bit to think about.