[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cc-tab] *important* heads up
Thanks for taking another look. Comments below.
Mike Linksvayer wrote:
> Hi James,
> The atom license extension was brought to my attention again. I'm not
> sure what concerns Thomas Roessler (cc'd) has below (I've also cc'd Lisa
> Dusseault as she mentioned the extension to me recently and appears to
> be involved in the process), but upon re-reading the draft I have one.
> I obviously did not read very carefully in the past and must apologize
> for that.
> In any case, the draft says the referenced license only applies to feed
> or entry metadata, not content. This strikes me as not particularly
> useful and does not match analogous extentions for RSS 1.0 and RSS 2.0:
The difference in semantics is precisely why I'm not using either the
RSS 1.0 or RSS 2.0 extensions for this as I see problems with both the
> http://web.resource.org/rss/1.0/modules/cc/ is RDF, so it is as clear as
> it can be what license annotations apply to, and in the examples they
> apply to the content at the feed (channel) URL (the feed itself) and the
> content at individual entry URLs (content of individual posts).
It is helpful to take a look at the RSS 1.0 rdf:license definition.
<!-- start -->
This module aims to give metadata regarding the copyright license
under which the RSS feed, and the objects it points to, are released
<cc:license rdf:resource="URI OF LICENSE" />
<cc:license rdf:resource=""> can be a sub-element of an RSS item,
channel or image. The license it refers to is applied to the parent
element. As with any RDF elements, an occurance of <cc:license> within
any element implies the copyright of the document contained with the
rdf:about attribute of that parent element, and not the document
pointed to by the <link> sub-element.
The element contains a single rdf:resource attribute which contains
the URI of the license applied.
<!-- end -->
>From this description, and the example that is illustrated in
specification of the rdf:license module, it is evident to me, at least,
that rss 1.0 channels and items are licensed independently from one
another and that an item does not inherit the license of the channel,
otherwise, you could end up with significant problems if two feeds
referenced the same content item with two difference licenses, e.g.
<cc:license rdf:resource="http://example.org/license1" />
<rdf:li resource="http://blog.example.com/2006/08/foo" />
<cc:license rdf:resource="http://example.org/license2" />
<rdf:li resource="http://blog.example.com/2006/08/foo" />
Because of RDF's data model and the definition of mod_cc, if licenses
are inherited by the items, these two feeds are either making
contradictory claims about the licensing of a single resource, neither
or which the channel publishers may actually have the right to license,
or they are claiming that the resource has been dual-licensed.
Unfortunately, neither claim can be substantiated by looking at the item
Note that, because of the RDFs data model, the same problem occurs if
the items in each of the above channels each contain their own
contradictory cc:license links.
Further, there is also the problem that the channel element is
describing a different resource that the item element. The definition
of cc:license says that the license applies to the parent element and
therefore the resource being described by the parent element. It is not
specified whether or not that license applies to other resources linked
to the channel.
Also, there is a bug in the spec that, in certain situations causes the
spec to contradict itself. Consider the sentence: "an occurance of
<cc:license> within any element implies the copyright of the document
contained with the rdf:about attribute of that parent element, and not
the document pointed to by the <link> sub-element" then look at the
example given in the spec itself.
<title>XML: A Disruptive Technology</title>
<cc:license rdf:resource="..." />
The link and the rdf:about attribute point to exactly the same resource,
making the assertion in the spec self-contradictory.
> http://backend.userland.com/creativeCommonsRssModule says license
> annotations apply to the "content of the RSS file" and "content of that
> item", mirroring the RSS 1.0 use.
I do not believe that the RSS 2.0 definition mirrors the RSS 1.0 use.
I've already noted the problems with inherited licenses when
resyndicating entries in aggregated feeds.
> My first thought is that it would be well worth reconsidering the
> semantics of the atom license extension. My second thought is that you
> must be well aware of the analogous RSS 1.0 and RSS 2.0 modules and did
> not follow their example for a reason.
> I'd appreciate any thoughts you might have on the matter. If there is a
> public or private list this should be taken to please let me know.
> p.s. There is also a problem in non-RDF formats in determining whether
> resources included in entry content (e.g., images) or enclosures are
> licensed. The mediaRSS module for RSS 2.0 http://search.yahoo.com/mrss
> seems to assume entry license annotations apply to "media" content.
> This is of course messy and probably beyond the scope of the discussion
> above and below.
Linked resources are *not* covered by license links.
>> On Tue, 2006-09-05 at 10:53 -0400, Ben Adida wrote:
>>> Hey all,
>>> I'm currently busy moving stuff from one office to another, but I have a
>>> feeling this heads-up from Thomas Roessler is worth looking at urgently,
>>> both with tech and legal eyes.
>>> -------- Original Message --------
>>> Subject: Heads-up: IETF considering license links for ATOM feeds
>>> Date: Tue, 5 Sep 2006 16:10:06 +0200
>>> From: Thomas Roessler <tlr@xxxxxx>
>>> To: ben@xxxxxxx
>>> CC: tlr@xxxxxx
>>> Hi Ben,
>>> FYI, the IETF is considering license links for ATOM feeds.
>>> You might wish to point your colleagues at Creative Commons at this:
>>> I understand the draft is in last call until 11 September.
>>> Reviewing the document, I've stumbled over a number of red flags
>>> (mostly in terms of legal meaning), to the point of possibly being