discussion of the Creative Commons Metadata work

[Mike Linksvayer <ml AT creativecommons.org>]

Hello cc-metadata,

First, I'm the new Creative Commons CTO.  Ben Adida hasn't left us 
entirely -- he's now an advisor.  I've met or corresponded with some of 
you (possibly regarding Bitzi, which I cofounded and uses RDF), look 
forward to working with all of you, and all that fluff.  No, really!

  ...

Creative Commons licenses are currently mostly used for content 
published on the web.  There's a whole lot more stuff out there, 
including files shared on P2P networks.  The following draft outlines a 
strategy for referencing Creative Commons license metadata in such 
content generally, and MP3 files specifically.  Please, let me know what 
you think.  I welcome and encourage all criticism.

I'll take all the blame for flaws in the draft, but credit goes to CC 
staff and advisors, particularly Neeru Paharia, who suggested putting 
licenses on the web (duh!) as we kicked around far worse ideas.  Also 
thanks to outside reviewers Lucas Gonze and Gordon Mohr for helpful 
comments.

Thanks!
Mike

  ...

 Creative Commons Metadata and Non-Web Content

[DRAFT -- NOT AUTHORITATIVE]

For the purposes of this document, "web content" suggests content
typically distributed and accessed by web servers and web browsers and
identified by a URL, or Uniform Resource /Locator/. "Non-web content" is
typically distributed and accessed on P2P networks and identified by a
Uniform Resource /Name/ (or something resembling one), typically a
"hash" -- a deterministic, secure and unique (the latter two in the
sense that it is essentially impossible to create two files with the
same hash) identifier.

Most HTML, XML-encoded, and plain text content falls solidly into the
first camp. Audio and video files often fall into the non-web category.
Images appear everywhere.

The crucial difference in this context between "web" and "non-web"
content is that web content has a /location/. The web server hosting web
content can always be identified and located. Usually the entity
publishing content at a specific URL can also be identified and located.
Non-web content, identified by /name/, typically cannot tied to any
specific location, nor can any single entity be identified as the publisher.


     Licenses Backed By Location

What does this distinction mean for license metadata? License metadata
for HTML and RSS is published with, often embedded in the content it
describes licensing terms for. If someone publishes false metadata about
web content, some combination of the URL, the publisher, and the ISP can
be identified, shamed, and legally threatened. The result is that the
false licensing information will be removed from the web. Because of
this process, you can generally trust that license notices and metadata
embedded in web content are legitimate.

License metadata typically isn't embedded in non-web content, and for
good reason -- it can't be trusted. Anyone can embed any license claim
in any non-web content that supports embedded metadata. Once content is
available on P2P systems, it is nearly impossible to identify the entity
making a license claim, and also nearly impossible to remove the content
from the network.

The general solution to the problems raised by non-web license metadata
is to move license metadata for non-web content to the web. That is,
rather than embedding a license or reference to a license in non-web
content, embed a reference to a license /claim/ in the non-web content.

*Unclaimed Non-Web License Metadata*

foo.bar (hypothetical file that supports embedding metadata) contains:

   metadata.licenseinfo=http://creativecommons.org/licenses/by/1.0/

*Web-Claimed Non-Web License Metadata*

foo.bar (hypothetical file that supports embedding metadata) contains:

   metadata.licenseinfo=http://example.com/licenseinfo

http://example.com/licenseinfo contains (excerpt):
   <Work rdf:about="urn:sha1:NFL46WSL6ZDQZ6OJG2RTGQ2IUD5JEEB8">
      <license 
rdf:resource="http://creativecommons.org/licenses/by/1.0/"; />
   </Work>

As a result of this indirection, license claims for non-web content can
be trusted to the same extent license claims for web content can be
trusted -- the license claims are themselves web content, and can be
removed from the web if false.

Pushing license metadata to the web has other benefits as well. Metadata
on the web can be referenced and extended by other web content (e.g.,
RDF/Semantic Web) and also indexed and searched by web search engines.
It isn't hard to imagine searching the web for a particular type of
music under a specific Creative Commons license, for example.
Additionally, the web allows for third parties to build authentication
services that extend the scheme described here. These may include
offline identity verification, community moderated metadata, web of
trust, and others.


     Guidelines For Non-Web License Metadata

*Publishers/Creation Software*

   * *Do not* embed unqualified license metadata in non-web content.
   * *Do* embed a license claim URL in non-web content metadata.
   * *Do* publish license metadata at license claim URL as RDF. The
     license claim URL may return an RDF document, or RDF embedded in
     HTML. [examples forthcoming]
   * RDF at license claim URL *must* identify licensed work(s) by a
     content-based URN. This might be hash-based, such as SHA1, or
     derived from any other description of the work that can be
     independently verified by the user.
   * License claim URL may redirect to another URL returning license
     claim RDF.
   * If possible include a human readable license/verification
     explanation in a metadata field likely to be displayed, .e.g.,
     "1995 Example Band licensed
     http://creativcommons.org/licenses/by/1.0/ verify at
     http://example.com/licenseinfo";. If the license claim URL returns
     an RDF document and it is not possible to do content negotiation,
     it is permissible to include a different URL in the explanation
     that will return HTML (e.g., http://example.com/licenseinfo.rdf
     and http://example.com/licenseinfo.html) so long as the HTML
     document includes a link to the RDF document. [examples forthcoming]
   * License RDF may be embedded, but is considered unverified and
     secondary to web-published metadata.

*Consumers/Client Software*

   * Consider embedded license metadata not backed by web-based claims
     suspect. *Do not* alter program behavior based on suspect license
     metadata.
   * If possible display human readable license/verification
     explanation alongside other file information.

*All*

   * [legalistic disclaimer forthcoming]


     Technical Threats

*Denial of Service attackers could spread files with intended victim URL
as the license claim URL.* Software may mitigate this threat via local
caching or routing requests through a license aggregator. The resources
and coordination required to effectively use this attack seem greater
than those required to simply launch DoS attacks from compromised machines.

*Spy or enforcement agents could spread files with an agent-controlled
URL as the license claim URL.* Use of general proxies or license
aggregators mitigate this threat. Threat no greater than same threat
normally faced by P2P file sharing software users resulting from
possibility of agents in a download mesh.


 Creative Commons Metadata and MP3

[DRAFT -- NOT AUTHORITATIVE]

Embedding Creative Commons license metadata in MP3 files follows the
guidelines established for Creative Commons metadata in non-web content.

MP3 embedded metadata is placed in ID3 frames
<http://www.id3.org/id3v2.4.0-frames.txt>. Two of these will be used for
embedding Creative Commons license claim metadata:

*WCOP* Copyright/Legal informatiton URL
   WCOP must include the license claim URL. Example value:
   |http://foobarband/cclicenses.html|

*TCOP* Copyright message
   TCOP should include human readable license and license claim
   information. The contents of this frame are displayed by many
   programs in a "file info" context. Example value: |1995 Example Band
   licensed http://creativecommons.org/licenses/by/1.0/ verify at
   http://example.com/licenseinfo|

There at some point be a recommendation for embedding RDF in MP3 files.
Candidate frames include USER, GEOB, TXXX and COMM. At this moment we
wish to emphasize the need to publish RDF on the web, and defer
RDF-embedding decisions. In any case, embedded license metadata should
only be considered valid if backed by RDF at a license claim URL.