Subject: Re: atom license extension (Re: [cc-tab] *important* heads up)

From: James M Snell <[email-masked]>
Date: Tue, 05 Sep 2006 15:11:22 -0700

Hello Thomas,

Thank you for taking the time to review the draft.  I have cc'd this
response to the atom-syntax list so that others in the Atom community
can comment.

Comments below.

Thomas Roessler wrote:
> Hi Mike, James, pleased to meet you.
> 
> I'm adding Wendy Seltzer to the CC list, who (I think) might have
> some points to add from a legal perspective.
> 
> Here's the quick review that I did earlier today:
> 
>> - What's the relationship between licensing information contained in
>>  a license-type link and licensing information contained in an
>>  atom:rights element?
> 
> (For the definition of atom:rights, see section 4.2.10 of RFC 4287.)
> 
>>  The example under 2.1 in the I-D suggests that the atom:rights is
>>  expected to reflect the license that is identified in the link
>>  element.  However, there seems to be no machine-readable way to
>>  express that connection.
>>  
>>  Also, there can be multiple license links, but only one rights
>>  element.
>>

This is the third time I've been asked this.  I guess I really do need
to add a clear statement about the relationship in the spec.  With
enough thumps on the head I usually come around ;-)

The relationship is relatively simple.  The atom:rights element is
always a human-readable statement of what rights are held over the feed
or entry.  It's is the equivalent of saying "Copyright (c) James Snell"
and cannot be relied upon to tell the consumer anything useful about
what the consumer can do with the feed or entry.  The license link, on
the other hand, is specifically intended to provide a reference to the
license applied to the feed/entry; that is, what kinds of things others
are allowed do with the feed/entry.

>> - An atom:rights element on a feed sets the default for the
>>  atom:rights elements on entries; a license link on a feed,
>>  however, is expected to apply to the metadata and NOT to the
>>  entries.
>>
>>  Why the difference in inheritance rules and semantics?

This is something that I've debated back and forth on but the difference
comes down to an issue with aggregated feeds.

Take, for instance, Sam Ruby's Planet feed
(http://planet.intertwingly.net/atom.xml).  This feed consists of
entries that originated from many different sources, some of which may
have license links, some that might not.  If Sam decided to put a
license link at the feed level, and if license links were inherited, it
would mean that Sam's license would be extended over resources he may
have no right to license.  Obviously, that's wrong.

One two possible solution would be for Sam to some how indicate that an
entry in his feed did not have a license link, but doing so could cause
other problems (such as invalidating any XML digital signatures that may
be covering the entry).  Also, it's possible that the entry originally
came from a feed that did include a license link, but that some
intermediary along the way failed to properly carry over the license
link into the entry after separating it from the feed.  The bottom line
is that license inheritance opens too many potentially significant
issues. (and yes, these issues apply equally to the atom:rights element).

The simple solution, then, is to specify that license links only cover
the feed or entry containing the link.

>>
>> - It's probably worth noting that there are jurisdictions in which
>>  databases enjoy sui generis legal protection (e.g., the EU).  In
>>  such jurisdictions, it might be reasonable to have license
>>  information that refers to the collection, not just to its
>>  metadata.
>>

The selection and arrangement of entries in the feed is covered by feeds
license.

>> - The following statement:
>>
>>    Entry content might include or reference material from other
>>    sources. Licenses associated with an entry MUST NOT be assumed
>>    to cover such material.  Implementations cannot necessarily
>>    trust that publishers have the right to license material claimed
>>    to be covered by any associated license.  Care should be taken
>>    when making decisions based on the referenced license.
>>
>>  ... takes all of the value out of this scheme.  The very point of
>>  annotating content (even aggregate content) with a license is that
>>  this license be trusted.
> 
> (I understand this to be, in part, a legal layman's overstatement;
> I'll leave it to the lawyers to comment. ;)
> 

Yes, I don't like this either.  But the fact remains that an entries
content may include content from other sources that cannot be assumed to
be covered by the license associated with the entry.  The analogous
situation occurs in Open Source Software distributions in which
dependencies shipped with a project may have their own licenses that are
distinct from the license used for the project code itself.

The question really is whether or not this is worth calling out
explicitly in the spec.

>> Summary: The relationship to atom:rigts should be cleaned up.  The
>> questions above about what precisely a license applies to probably
>> points at a problem in terms of expressivity of the linking scheme
>> -- an argument could be made that there should be machine-readable
>> ways to express what precisely a license link is supposed to apply
>> to. Something like rel={content-license, dataset-license,
>> entry-default-license}?
> 
>> Overall, this document looks like it is in dire need of serious
>> review from legal experts -- e.g., from the Creative Commons
>> community.  

That would be excellent.

> 
> I, too, would be happy to move this discussion to a public mailing
> list.  Is the atompub list the right place to have this
> conversation, or should this go to the IETF plenary, as this draft
> is in IETF Last Call?
> 

The atom-syntax list would be an appropriate forum.

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Sep 2006 15:53:18 -0700

Hey Mike,

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
former approaches.

> 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.

From http://web.resource.org/rss/1.0/modules/cc/:

<!-- start -->
  This module aims to give metadata regarding the copyright license
  under which the RSS feed, and the objects it points to, are released
  under.

  [snip]

  <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.

  <rdf:RDF>
    <channel rdf:about="http://example.org/feed1">
      <cc:license rdf:resource="http://example.org/license1" />
      <items>
        <rdf:Seq>
          <rdf:li resource="http://blog.example.com/2006/08/foo" />
        </rdf:Seq>
      </items>
    </channel>
    <item rdf:about="http://blog.example.com/2006/08/foo">
      ...
    </item>
  </rdf:RDF>

  <rdf:RDF>
    <channel rdf:about="http://example.org/feed2">
      <cc:license rdf:resource="http://example.org/license2" />
      <items>
        <rdf:Seq>
          <rdf:li resource="http://blog.example.com/2006/08/foo" />
        </rdf:Seq>
      </items>
    </channel>
    <item rdf:about="http://blog.example.com/2006/08/foo">
      ...
    </item>
  </rdf:RDF>

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
itself.

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.

  <item rdf:about="http://c.moreover.com/click/here.pl?r123">
    <title>XML: A Disruptive Technology</title>
    <link>http://c.moreover.com/click/here.pl?r123</link>
    <cc:license rdf:resource="..." />
  </item>

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.
> 
> Mike
> 
> 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.

- James

> 
> 
>> 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.
>>>
>>> -Ben
>>>
>>> -------- Original Message --------
>>> Subject: Heads-up: IETF considering license links for ATOM feeds
>>> Date: Tue, 5 Sep 2006 16:10:06 +0200
>>> From: Thomas Roessler <[email-masked]>
>>> To: [email-masked]
>>> CC: [email-masked]
>>>
>>> Hi Ben,
>>>
>>> FYI, the IETF is considering license links for ATOM feeds.
>>>
>>> You might wish to point your colleagues at Creative Commons at this:
>>>
>>>
>>> http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-08.txt
>>>
>>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13576&rfc_flag=0
>>>
>>> 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
>>> harmful.
>>>
>>> Regards,

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Sep 2006 16:08:21 -0700

Hello Wendy,

Thanks for the feedback.  I've cc'd the atom-syntax list so the rest of
the Atom community can comment.

Comments below.

Wendy Seltzer wrote:
> Hi all,
> So my first thoughts upon seeing the draft are to wonder why it's
> necessary to make assertions about the legal effects of including a
> license -- especially since some of those assertions seem to obviate the
> purpose of using a license declaration.   While it's helpful to tell
> people how to indicate, technically, what they mean for a license to
> attach to, it's not useful to offer guidance on how to interpret the
> license.
> 
> Namely:
> 
> 1.1   It must also be noted that licenses associated with feeds or entries
>    using these mechanisms are advisory and are not, by themselves,
>    legally binding.  Nor can a license associated with a feed or entry
>    restrict or forbid access to, redistribution, aggregation, caching
>    and display of those items by third party intermediaries such as
>    search engines and so-called "online aggregators".
> 
> Why can't they be legally binding?  They're not self-executing, but
> licenses outside of feeds aren't either, and likewise may or may not be
> legally binding depending upon other things than just the form of their
> expression.
> 

To this point I've received exactly the opposite feedback from others
(all of whom weren't lawyers, btw, but who have had experience with
licensing issues in the past).

It is my understanding that the licenses cannot be considered legally
binding *by themselves*.  That is, precisely as you indicate, they are
not self-executing.

> 
> 2   "License" link relations appearing within a feed MUST apply to the
>    metadata of the containing feed element only and do not extend over
>    the metadata or content of any contained entries.
> 
> Why? Why would a feed need a license separate from its content?  Lots of
> the metadata elements would be functional or would give users fair use
> claims, absent a license.
> 

Sam Ruby's planet feed is a prime example.  Sam does not own rights over
the individual entries that appear within his feed, however, Sam does
own the rights over the feed itself, including the selection and
arrangement of entries within that feed.

I've mentioned before that it's roughly equivalent to distributing
dependencies with an open source project.  Each of the dependencies have
their own license, distinct from the projects license.

>    Entry content might include or reference material from other sources.
>    Licenses associated with an entry MUST NOT be assumed to cover such
>    material.  Implementations cannot necessarily trust that publishers
>    have the right to license material claimed to be covered by any
>    associated license.  Care should be taken when making decisions based
>    on the referenced license.
> 
> This seems to be going down a road of legal interpretation that's
> unnecessary and not necessarily correct. The current CC licenses are
> offered on a "taker beware" basis -- the licensor offers the rights he
> has, and doesn't guarantee a licensee's rights (or even his own) to
> anything he might have incorporated.  That's not the only way to write a
> license, though.  (Even within CC, version 1 had an explicit
> representation and warranty section that was dropped in v.2.)
> 
> Implementations should trust the legal representations only as much or
> as little as they trust any other claim made by the feed.  How licenses
> chain is a matter of individual legal interpretation.
> 

Ok, so if I'm interpreting this comment correctly, the recommendation
would be to simply remove the paragraph in question?

> 
> Forgive me (but please clarify!) if I'm misinterpreting some of the draft.
> 
> Thanks,
> --Wendy
> 

Thanks for taking the time to review,

- James

---

From: Wendy Seltzer <[email-masked]>
Date: Tue, 05 Sep 2006 19:40:24 -0400

>the Atom community can comment.

Thanks James,
I'm still not clear on what's happening in 1.1.

>binding *by themselves*.  That is, precisely as you indicate, they are

What I meant by that is that they don't actively restrict 
non-compliant use, as a technological protection measure does: I can 
receive a feed and choose to breach its license.   They can have 
legal effect, though:  Unless I have some legal excuse such as fair 
use, I'm then not compliant and possibly infringing copyright.  (You 
still have to come after me for copyright infringement.)

Are you trying to say that the license-rel in the feed is merely a 
notification to those who are curious that "this is probably (but 
we're not certain) the license under which the feed may be used" 
?  That's the way it reads.  If so, what's the point?  Don't you 
either want to assert "take the feed under this license or not at 
all" or say nothing and make people come to you and ask?

I'd recommend dropping this paragraph, as it may give incorrect legal advice.

>arrangement of entries within that feed.

That seems minimally useful to me (the license, not Sam's feed!), but 
why prohibit people from licensing their feeds' content too? Or am I 
just misreading this, and you're saying that depending on where you 
put the tag, the license's coverage differs?

>would be to simply remove the paragraph in question?

Yes.

Thanks,
--Wendy

-- 
Wendy Seltzer -- [email-masked]
Visiting Assistant Professor of Law, Brooklyn Law School
Fellow, Berkman Center for Internet & Society
http://cyber.law.harvard.edu/seltzer.html
Chilling Effects: http://www.chillingeffects.org

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Sep 2006 17:03:50 -0700

Comments below.

Wendy Seltzer wrote:
> What I meant by that is that they don't actively restrict non-compliant
> use, as a technological protection measure does: I can receive a feed
> and choose to breach its license.   They can have legal effect, though: 
> Unless I have some legal excuse such as fair use, I'm then not compliant
> and possibly infringing copyright.  (You still have to come after me for
> copyright infringement.)
> 
> notification to those who are curious that "this is probably (but we're
> not certain) the license under which the feed may be used" ?  That's the
> way it reads.  If so, what's the point?  Don't you either want to assert
> "take the feed under this license or not at all" or say nothing and make
> people come to you and ask?
> 

What I'm saying is that feed consumers have no guarantee as to who added
the license link to the feed/entry and whether whoever did had the legal
right to do so.  Nor is there any guarantee that license links within a
feed or entry have not been inappropriately modified. Feed publishers
can digitally sign Atom feeds and entries to provide some
non-repudiation protection, but doing so is optional and is not a
guaranteed solution.

> I'd recommend dropping this paragraph, as it may give incorrect legal

Ok.

> just misreading this, and you're saying that depending on where you put
> the tag, the license's coverage differs?
> 

It's the latter.  The license's coverage differs depending on where it
appears.

- James

---

From: Mike Linksvayer <[email-masked]>
Date: Wed, 06 Sep 2006 02:04:14 +0000

> RSS 1.0 or RSS 2.0 extensions for this as I see problems with both the

I understand having problems with RSS 1.0 and RSS 2.0 approaches but I
don't see an inherent and important difference in semantics,
particularly between Atom 1.0 and RSS 2.0.  Of course my vision is
probably foggy. :)

> specified whether or not that license applies to other resources linked

The subject of the channel is the feed itself, which necessarily
includes any content delivered with the feed, including the full or
excerpted text of individual items, if delivered with the feed itself.
It is only in this sense that a feed level statement applies to item
content -- when the content is part of the feed.

> making the assertion in the spec self-contradictory.

The example could be more illustrative but it is hardly contradictory.
AFAICT the item subject (specified by rdf:about) and the link property
usually are the same, indeed the spec
http://web.resource.org/rss/1.0/spec#s5.5 says they "should be
identical ... if possible."  I have no idea why the link property of an
item even exists in RSS 1.0, but that's neither here nor there.

> I do not believe that the RSS 2.0 definition mirrors the RSS 1.0 use.

They look as close as they could be to me, given different models (URIs
for feeds and items vs. "content of" feeds and items).  Effectively they
mean the same things.

> resyndicating entries in aggregated feeds.

I agree that assuming entries inherit licenses specified at a feed level
is problematic.  My concern, at the feed and entry level, is that the
atom license extension draft says that a link relation can (only) be
used to associate a license with feed or entry metadata, rather than
content.  Unlike other children of <feed> and <entry> the license
extension is not metadata for the feed or entry but metametadata for the
feed or entry metadata, which strikes me as not particularly useful and
contrary to both RSS 1.0 and RSS 2.0 modules, whatever differences exist
between those.

-- 
  http://wiki.creativecommons.org/User:Mike_Linksvayer

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Sep 2006 20:50:49 -0700

> particularly between Atom 1.0 and RSS 2.0.  Of course my vision is

The difference boils down to one very simple point: contained resources
do not necessarily inherit the license of the container.  The RSS 1.0
and RSS 2.0 modules both assume that the rights holder of the channel
also holds rights over all of the contained items, which works fine when
I'm publishing my own blogs entries in my own feed, but breaks down when
I'm republishing entries from multiple sources.

>[snip]
(I'm still stewing over the bit of comments that I snipped out of this
:-) ...)

> contrary to both RSS 1.0 and RSS 2.0 modules, whatever differences exist

My apologies if I haven't been clear on this.  If you look again at
section 1.3, you should find the following:

   For entry elements, "metadata" refers to the values and attributes of
   the author, category, content, contributor, id, link, published,
   rights, source, summary, title, and updated elements, as well as all
   extension elements appearing as children of the entry element and all
   elements appearing as children of the author and contributor
   elements.

Note that the value and attributes of the content, summary, title, etc
elements are all included in entry "metadata".  What isn't covered are
any linked resources.  So any content actually appearing within the
entry is covered by the entry license.

(Note that paragaph 4 of section two will be removed in the next
iteration per Wendy's suggestion)

- James

---

From: John Panzer <[email-masked]>
Date: Tue, 05 Sep 2006 22:02:59 -0700

>I'm republishing entries from multiple sources.
Here's my rationale:  Atom has explicit support in the core RFC 4287 
syntax  for 'synthetic' feeds containing entries from multiple sources 
produced by multiple authors with different copyrights.  RSS 2.0 doesn't 
have this core support.  So in the case of Atom, the issue is a bit more 
urgent.  So tackling the Atom case first makes sense to me.

(Aside: Is there any reason why an Atom extension couldn't also be used 
as an RSS 2.0 extension too?  In this case, there would be a valid 
reason to add to the already crowded space of license extensions:  
Because it lets you specify the feed license terms separately from the 
individual entry license terms, whereas the other RSS licensing schemes 
don't.)

>entry is covered by the entry license.
(Is it just me, or is there too much overloading of "metadata" here?)

Also, does this mean that an entry license would apply to this content:

    <content type="image/gif">TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG</content>

but not to the same content communicated through an indirect link?

    <content type="image/gif" src="http://example.org/catpicture001.gif"/>

(I'm deliberately picking a GIF picture as I believe there's no good 
solution for embedding license metadata inside GIFs.  )

-John Panzer

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Sep 2006 23:10:50 -0700

Yes, that's what it means, which I'll definitely admit is odd.  I think
there is a massive gray area here that needs to be worked out.  I'm not
sure how to work it out.

- James

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 6 Sep 2006 02:25:47 -0400

Wendy Seltzer wrote:
>> 1.1  It must also be noted that licenses associated with
>> feeds or entries using these mechanisms are advisory and
>> are not, by themselves, legally binding.  
	Section 1.1 contains two sentences that are, I think, at least in
part the result of a telephone conversation on this subject that James and I
had about a week ago. However, I think that James has written both sentences
too strongly and it is quite possible the first sentence is unnecessary.
I'll explain the logic behind my reasoning. First, the first sentence and
the second, later.
	The first sentence is concerned with the binding between the feed or
entry and the actual license. For one to rely on a license, either as a
rights holder or as a grantee, you need to be able to show what the license
actually said at the time that you relied upon it.
	Because of the nature of the tool being used here, a hyperlink, we
must accept that the binding between content and license is a weak and
fragile one. There is no guarantee that the content of the license
associated with a feed at one instance will be the same as it is at some
other instance. Also, there is no mechanism provided to ensure that claims
made about what the license was at one instance can be proved at a later
time. This weakness of the link is going to make it very difficult for
either a copyright holder or one who relies on a license found in a license
link to rely on being able to make definitive statements about what the
license content actually was. Certainly, there are special cases. For
instance, those who link to Creative Commons licenses using the appropriate
and presumably well managed URLs that Creative Commons provides are going to
be able to much more certain when making assertions about license content
since these licenses are only modified in very public and dated events.
However, Creative Commons is a special case and can't be generalized to all
possible licenses. Thus, while we might find that links to Creative Commons
licenses (and others which are similarly well managed) might be effective,
it is likely that links to at least some other licenses would not be
considered effective. Thus, it might be better to word the sentence
conditionally. Something like: "licenses associated with feeds or entries
using these mechanisms may not be legally binding"...
	My personal feeling is that given the customs of the net today, it
is likely that the most common licenses referred to in these links will, in
fact, be Creative Commons licenses which grant rights otherwise restricted
by copyright. The problems come in licenses which attempt to restrict
rights. One class of such licenses will be those that claim rights that are
already reserved under copyright. Such licenses are really redundant and
don't accomplish anything useful. I'll ignore those for now. The most
interesting cases will be those licenses that attempt to assert limitations
to rights which would normally be considered to be granted to consumers of
feeds. Such rights would include things like "Fair Use" and "implied
licenses." It is *vitally* important to our community that we ensure that
such restrictive licenses are not encouraged or facilitated by this rfc.
	There are those, I among them, who argue that the mere act of
encoding data in a syndication format such as RSS or Atom, posting that
content on an openly accessible web site, and doing such things as pinging
to publicize the presence of that content, creates a limited "implied
license" for others to access and copy the data for the purposes of
syndication. This is very much like the implied license to copy HTML into
system buffers, caches, network routers, local disks etc in the process of
reading it. With HTML, courts appear to accept that you have a right to do
something that would be prohibited by a strict reading of copyright law.
Under limited circumstances, you are allowed to make copies that are
technically necessary and facilitative to the achievement of the content
creator's assumed purpose of having you read the pages. Similarly, when you
publish to a syndication network, one accepts that there is an implied
license to do not only the same kind of copying that is permitted for HTML,
but also that you accept that your content will be processed by various
syndication-related intermediaries -- feed aggregators, feed filters, feed
format converters, publish/subscribe systems, etc. However, please note that
this is still a *limited* implied license. The fact that syndication is
permitted doesn't mean that the general creation of derivative works,
repurposing of feed content, etc. is permitted. The license doesn't allow
"stealing" -- it only allows moving the stuff around in the process of
getting it to readers.
	The syndication network can only work because we assume that there
is an implied right to syndicate. If, for some reason, we were to establish
that this implied right could be revoked or modified by licenses associated
with a feed or entry, then we'd probably have to shutdown the entire
syndication network until such time as every intermediary and aggregator was
modified to support license discovery and interpretation. The social and
economic cost of this destruction of one of the most exciting areas of
innovation on the net today would simply not be accepted by the courts -- at
least not in the USA (I believe). Courts aren't going to accept this
"poisoning of the stream" simply so that someone can commandeer the
syndication network and force it to process data in a manner different from
the way it was designed to work.
	Of course, one could argue that as long as the Atom license link was
used by everyone, then it should be easy for folk to make the adjustments
and thus the cost might not be too great. However, once we've accepted that
there is even one mechanism by which someone can publish content that
overrides the implied license to syndicate, we must ask the question: "In
how many ways can the override be expressed?" As far as the law is
concerned, there is nothing special about IETF standards. Thus, while the
IETF might say that you can use a license link to bind content and licenses,
the W3C might decide to create a "rights" link instead. ANSI might then
create a "copyright-assertion" link. And someone else might decide to use an
element instead of a link. The problem here is that operators of syndication
components and aggregators would have no means of being sure that they were
catching all the licenses associated with the feeds that they were
syndicating. Someone who was malicious might, in fact, create a new
"standard," publish content with a restrictive license, and then make a
bundle by suing everyone downstream. 
	I think courts won't permit a situation in which the consumer of
content has no idea how to determine if licenses are associated with content
in the same way that they don't let you rely on "Do not enter" signs written
in tiny, unreadable type. The courts would probably insist that legislatures
do as they did with the copyright symbol -- make a formal, legal
determination of how licenses are to be linked to. (Let's hope that we don't
get legislatures involved in the definition of Atom. We've got enough issues
to deal with already.)
	In any case, it may be that "Ignorance of the law is no excuse!"
however, ignorance of an optional, experimental extension to the Atom format
is certainly not a crime. No matter how earnestly content creators may be in
wanting to use the license link to restrict rights, they have no means of
compelling anyone to pay attention to or even take note of the links... Even
in the case of some system that can be shown to understand the license link
mechanism, it can be argued that in the absence of a legally accepted syntax
for stating restrictions on rights, that the reader can't compelled to
"understand" the limitations expressed. (Note: let's not talk about creating
a machine readable license format... Just about all useful methods of doing
so are already patented...)
	In summary:
	1. It is unwise to induce folk into believing that the license link
can be used to override the limited implied license to syndicate, and
	2. There is no way to compel anyone to take note of the links
anyway.
	The situation is, of course, different with things like Creative
Commons licenses. Courts are likely to say that any publisher who includes
the appropriate namespaces in their feeds and includes properly formatted
license links that point to Creative Commons licenses is demonstrating a
real knowledge and appreciation of the mechanism and is willingly granting
licenses to all those who share the same understanding of the mechanism and
willingness to use it. Basically, the publisher proves, by making the effort
and signaling via the published and controlled syntax, that they do, in
fact, wish to grant the rights expressed in the license. Readers of feeds
are then free to exploit their understanding of the publisher's signals to
exercise the rights granted -- just as they are free to refuse to understand
the restrictive licenses published by others.
	Thus, it would seem that the only effective use of the license link
is to grant rights not to restrict them.

The second sentence in 1.1 is:
>> Nor can a license associated with a feed or entry
>> restrict or forbid access to, redistribution, aggregation,
>> caching and display of those items by third party
>> intermediaries such as search engines and so-called
>> "online aggregators".
	This second part of 1.1 is stating support for the theory that the
act of publishing data in the Atom format creates an "implied license" for
the limited purpose of syndication and lists a number of processes which are
considered to be part of the syndication process. Hopefully, my discussion
of the first sentence explains what this is all about.
	My only suggestion for this sentence is that it might be less
strongly worded. Given that the law in this area is not settled, it might
make sense not to say "Nor can a license... restrict..." Rather, it might be
more accurate to say something like: "It is believed that a license ...
cannot restrict...."

	My apologies for such a long message...

	bob wyman

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 6 Sep 2006 11:02:12 +0200

On 2006-09-06 02:25:47 -0400, Bob Wyman wrote:

> 	Because of the nature of the tool being used here, a
> hyperlink, we must accept that the binding between content and
> license is a weak and fragile one. There is no guarantee that the
> content of the license associated with a feed at one instance
> will be the same as it is at some other instance. Also, there is
> no mechanism provided to ensure that claims made about what the
> license was at one instance can be proved at a later time.

I think this assessment mixes two aspects: The use of the
rel=license link as an *identifier* for a specific license (which is
pretty much what Creative Commons does), and the use of the link to
retrieve license information.

The value that this specification adds to Atom is mostly in the
"link-as-identifier" field: It enables software to offer, e.g.,
retrieval of feeds (or entries) by license.  Look at the Creative
Commons powered aspects of flickr search for a related example.  

Trying to dilute the value of the license link out of fear that the
link-as-retrieval-mechanism aspect is dangerous, however, impacts
the value of the link-as-identifier aspect. As you point out, the
weakness of the link between content and a specific license (in the
sense of legal code) causes problems for both the copyright holder
and the relying party.  A corollary of this is that, in fact, both
sides have an incentive to use licenses that are identified by a
stable URI.

Hence, I'd suggest that, in making balancing decisions for this
specification, emphasis be put on using URIs as *identifiers* for
licenses.  It's fine to point out the lack of an enforceable binding
on a technical level, but I don't think this spec is the place to
discuss the legal implications that this might have.

-- 
Thomas Roessler   <[email-masked]>

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 6 Sep 2006 11:28:47 +0200

On 2006-09-05 15:11:22 -0700, James M Snell wrote:

> The relationship is relatively simple.  The atom:rights element
> is always a human-readable statement of what rights are held over
> the feed or entry.  It's is the equivalent of saying "Copyright
> (c) James Snell" and cannot be relied upon to tell the consumer
> anything useful about what the consumer can do with the feed or
> entry.  The license link, on the other hand, is specifically
> intended to provide a reference to the license applied to the
> feed/entry; that is, what kinds of things others are allowed do
> with the feed/entry.

Well, the definition of the atom:rights field is really just another
way to describe what a license is. Namely, the law gives you certain
rights that you, and only you, can exercise.  A license is about
which of these rights you retain, and which ones you let others
exercise.

The example in section 2 of draft-snell-atompub-feed-license-08
actually uses the atom:rights field for indicating which license
applies.

How would that mix with a license link that points at another
Creative Commons License?  And what effect does that have for, say,
license-based search engines?

I don't think the spec can wriggle out of this by saying that the
two aren't entirely the same and maybe shouldn't conflict.

> have no right to license.  Obviously, that's wrong.

Obviously, that's not obvious.  Who are we to tell that Sam hasn't
obtained the right to attach these licenses out-of-band?

> One two possible solution would be for Sam to some how indicate
> that an entry in his feed did not have a license link, but doing
> so could cause other problems (such as invalidating any XML
> digital signatures that may be covering the entry).  

> Also, it's possible that the entry originally came from a feed
> that did include a license link, but that some intermediary along
> the way failed to properly carry over the license link into the
> entry after separating it from the feed.  The bottom line is that
> license inheritance opens too many potentially significant

> The simple solution, then, is to specify that license links only
> cover the feed or entry containing the link.

I don't think this spec needs to deal with the case that license
links might be altered by intermediaries.  It's fine to mention that
in the Security Considerations section, but I don't think it's a
case that should influence the overall design.

In Atom, we so far have an atom:rights entry that describes licenses
on entries.  Either, it sets a default (with all the problems that
you describe), or, it sets the rights for a specific entry.  In what
way this gets used (and whether that use is the right one) is up to
the party that authors an entry or a feed.

The rel=license proposal moves away from this approach:  The
semantics here are that it makes a statement about whatever object
it is attached to -- either a feed (with peculiar semantics that
might quite well depend on the jurisdiction), or to entries that are
children of that feed.

This inconsistency is a recipe for confusion.

In the interest of consistency, I'd suggest to replicate the
semantics of atom:rights for whatever URI-based scheme is
introduced.  If there's a need for feed-level licenses, then that
should be marked up separately. (I can see use cases for that, see
below; I'm not sure it's something urgent.)

> The selection and arrangement of entries in the feed is covered by feeds

From draft-snell-atompub-feed-license-08:

   "License" link relations appearing within a feed MUST apply to
   the metadata of the containing feed element only and do not
   extend over the metadata or content of any contained entries.

I don't see the selection and arrangement in there.

It might be best to focus on licenses on entries for the moment, and
do licenses for metadata, selections and arrangements separately, if
at all.

> The question really is whether or not this is worth calling out

I'll give a +1 to Wendy's suggestion to just drop this.

There's one more point that the spec might need to drill down on: It
is not clear to me whether atom:rights -- or rel=license, for that
matter -- applies to the material in an entry [ultimately, metadata
about a resource], or to the (in Atom speak) alternative versions
[the resource that the entry is about, in RDF speak].  This probably
doesn't matter too much for blog data; it likely does matter in
other contexts.

I'd hope that I'm missing some point, but quite possibly there needs
to be an explicit decision here whether the license link is expected
to apply only to the material in the entry, or to the "alternative
versions" [resources the entry is about] as well.  

Regards,

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 6 Sep 2006 11:36:53 +0200

On 2006-09-05 22:02:59 -0700, John Panzer wrote:

> Here's my rationale: Atom has explicit support in the core RFC
> 4287 syntax for 'synthetic' feeds containing entries from
> multiple sources produced by multiple authors with different
> copyrights.  RSS 2.0 doesn't have this core support.  So in the
> case of Atom, the issue is a bit more urgent.  So tackling the
> Atom case first makes sense to me.

This is an important use case for having per-item license links.  

I do not see, however, how this is a reason against having per-feed
default licenses, consistent with atom:rights.  Note, in particular,
that an aggregating party may very well be in a position to make
licensing assertions about all the entries in a feed.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 6 Sep 2006 12:21:24 +0200

* Thomas Roessler <[email-masked]> [2006-09-06 11:45]:
> > (http://planet.intertwingly.net/atom.xml).  This feed
> > consists of entries that originated from many different
> > sources, some of which may have license links, some that
> > might not.  If Sam decided to put a license link at the feed
> > level, and if license links were inherited, it would mean
> > that Sam's license would be extended over resources he may
> Obviously, that's not obvious.  Who are we to tell that Sam
> hasn't obtained the right to attach these licenses out-of-band?

That may be a good point in this instance, but an irrelevant one.

James’ points out that there may be feeds where the feed
publisher has the rights to the feed as a collection, but not to
the content of individual entries. Since these cases exist, it
would be a bad idea for the licence to inherit from the feed to
entries in it.

Whether Sam in particular is or is not in that position does not
affect the principle. He’s not, btw: he republishes my content,
but he has no permission from me to relicense it.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 6 Sep 2006 12:38:13 +0200

> would be a bad idea for the licence to inherit from the feed to

The conclusion here is fallacious: These cases are a use case for
having license annotations on the feed level.  As I said elsewhere,
I'm fine with that.

However, this does not mean that the capability to set a licensing
default on the feed level is a bad thing by itself -- in particular
when that is how the other mechanism works.

We are simply talking about different use cases, and violently
agreeing that it's a bad thing to confuse these.

So, here's the proposal:

- Use <link rel="license"/> for entry licenses -- either on the feed
  level, setting a default analogous to what atom:rights does, or on
  the element level.

- Introduce <link rel="collection-license"/> (or whatever else you
  find suitable) for licenses about the collection, to be used only
  on the feed level.

Regards,

---

From: James M Snell <[email-masked]>
Date: Wed, 06 Sep 2006 06:51:00 -0700

The problem with specifying a per-feed default license is that there is
currently no way of explicitly indicating that an entry does not have a
license or that any particular entry should not inherit the default
feed-level license.

- james

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 6 Sep 2006 16:43:58 +0200

That means that, in some use cases, setting a default is the wrong
thing to do.  That's the same limitation you have for atom:rights.
It's a limitation that can be stated in the specification.  But I
don't see how it is a limitation that means there must not be a
default license feature available to those who decide to use it.
-- 
Thomas Roessler   <[email-masked]>

On 2006-09-06 06:51:00 -0700, James M Snell wrote:
> From: James M Snell <[email-masked]>
> To: John Panzer <[email-masked]>, James M Snell <[email-masked]>,
> 	Mike Linksvayer <[email-masked]>, Ben Adida <[email-masked]>,
> 	Lisa Dusseault <[email-masked]>,
> 	atom-syntax <[email-masked]>, [email-masked]
> Date: Wed, 06 Sep 2006 06:51:00 -0700
> Subject: Re: atom liense extension (was Re: [cc-tab] *important* heads
> 	up)
> List-ID: <atom-syntax.imc.org>
> X-Spam-Level: 
> 
>

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 6 Sep 2006 12:47:09 -0400

Thomas Roessler wrote:
> It's fine to point out the lack of an enforceable binding on a
> technical level, but I don't think this spec is the place to
	If the spec does not make statements concerning the intended legal
implications of a feature which clearly addresses legal issues, the result
will almost inevitably be wide-spread misunderstanding of the implications
of using the feature. The mere act of going to the trouble of specifying the
license link indicates that the authors expect that there will be some
implication of having used the feature. The question that many readers will
have is: "What are the intended implications?" Leaving the answer to guess
work is not useful, I think.
	Given the unsettled and potentially dynamic state of the law in this
area, I certainly agree that the spec should not make pronouncements
concerning what the law is in this case. But I don't see any valid argument
against making statements of intent that may, or may not, be in conflict
with the law as it is or may one day be.
	The authors of the specification have, I think, not only good reason
to state their intention but an obligation to do so. Warning implementers
that the use of the license link may not, in at least some situations and in
some legal systems, create a legally enforceable binding is the right thing
to do.

	bob wyman

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 6 Sep 2006 18:54:25 +0200

On 2006-09-06 12:47:09 -0400, Bob Wyman wrote:

> 	The authors of the specification have, I think, not only
> good reason to state their intention but an obligation to do so.
> Warning implementers that the use of the license link may not, in
> at least some situations and in some legal systems, create a
> legally enforceable binding is the right thing to do.

The intent of this spec is to give those who publish a feed a way to
assert what licensing conditions apply to certain parts of that
feed.

That's what the spec should say; anything else -- in particular
elaborate discussions of corner cases -- is going to cause
confusion.

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 6 Sep 2006 13:46:54 -0400

Thomas Roessler wrote:
> The intent of this spec is to give those who publish a
> feed a way to assert what licensing conditions apply to
> certain parts of that feed.
	If a mechanism is provided for "asserting" rights, without warning
folk that the assertions may not be effective, the assumption on the part of
many folk will be that the assertion is, in fact, effective. The result will
be confusion and that confusion can be costly. (Note: I also don't think it
is responsible to sell guns without safety warnings...)
	In this case, protection of the limited implied license to syndicate
is a matter of extreme importance to the syndication network. Those of us
who run or have run syndication services already have enough trouble with
folk who stick random "rights language" in their feeds and then think that
these assertions are somehow effective -- or even that the automated
processes that we run can recognize that the language is present. The number
of folk who have attempted, usually unintentionally, to "poison the stream"
of syndication is large.
	One excellent example of the confusion that exists is that many
people actually think that Creative Commons licenses are restrictive! While
the CC licenses are generally well drafted, very few people actually read
the things. As a result, there are numerous folk who honestly believe that
Creative Commons licenses can be used as a form of DRM to restrict use. They
believe, for instance, that a CC non-commercial use license actually
restricts commercial use when, in fact, such a license is explicitly silent
on the subject and simply leaves in place pre-existing restrictions (such as
copyright), if there are any, on commercial use.
	In this context, I'm particularly concerned about people who will
try to use license assertions to override or diminish the vital but limited
implied license to syndicate -- for instance, when the syndication is
performed by "commercial" organizations. We already have many folk who think
that a CC Non-Commercial license has this effect when attached to a feed or
entry. I think it is in our interest to do what we can to avoid further
confusion by warning people of the limits of their assertions in the
specification. There will still be many who don't read the spec; however,
we'll be providing support to those who try to explain it...

	bob wyman

---

From: Antone Roundy <[email-masked]>
Date: Wed, 6 Sep 2006 16:08:06 -0600

> license or that any particular entry should not inherit the default

With respect to atom:rights (from RFC 4287 section 4.2.10):

    If an atom:entry element does not contain an atom:rights element,
    then the atom:rights element of the containing atom:feed element, if
    present, is considered to apply to the entry.

Thus, at the entry level, <atom:rights /> would (certainly ought to!)  
detach a feed level atom:rights element from the entry without  
replacing it with anything.  With <link rel="license"..., I'm not  
sure how you'd do the same thing.  Is it possible to specify a null  
URI?  <link rel="license" href="" /> points to the in-scope xml:base  
URI, right?  Perhaps the specification could define a "null license"  
URI.

With respect to the issue of aggregate feeds, I had thought that the  
existence of an atom:source element at the entry level blocked any  
"inheritance" of the feed metadata, but looking at RFC 4287, I don't  
see that explicitly stated.  Certainly if atom:source contains  
atom:rights, then that element overrides the feed-level atom:rights  
of the aggregate feed, but if neither atom:source nor atom:entry  
contains an atom:rights element, what then?  Perhaps in that case,  
the aggregator should add <atom:rights /> as a child of atom:source  
(I'd think that preferable to adding it as a child of atom:entry).

>   find suitable) for licenses about the collection, to be used only

If there's a @rel="license" at the feed level, but no rel="collection- 
license", does the @rel="license" also become a "collection- 
license"?  (People who don't read the spec would probably think so).   
If there is no license for the collection, but one wishes to specify  
a default license for the entries, a "null license" would once again  
be useful.

Antone

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 6 Sep 2006 19:05:16 -0400

Antone Roundy wrote:
> With respect to the issue of aggregate feeds, I had thought
> that the existence of an atom:source element at the entry
> level blocked any "inheritance" of the feed metadata, but
> looking at RFC 4287, I don't see that explicitly stated.
	It's not explicit, but it is implicit. The <source/> element
preserves the entry's feed metadata. Thus, to find the feed metadata
associated with an entry which has an atom:source, you should look to the
preserved data in the atom:source element (or the source feed itself...) --
you should NOT look to the metadata of the feed within which you found the
entry.
	Atom:source says, essentially: "This entry is not of this feed. It
is foreign and should be interpreted as such." Thus, the feed metadata of
the containing feed should never be allowed to leak into the interpretation
of an entry which contains an atom:source. To do so would make syndication,
aggregation, etc. a complete mess.

	bob wyman

---

From: David Powell <[email-masked]>
Date: Thu, 7 Sep 2006 00:49:05 +0100

>   level, setting a default analogous to what atom:rights does, or on

I think that there are data modelling issues with this approach. I
don't think that the inheritance of extensions from the 'feed
document', to the entries contained within that document is supported
by the spec, nor would it be likely to be supported by typical
implementations of stateful feed stores, frameworks and APIs.

Feeds and entries are seperate entities with seperate life-cycles.
Stateful feed platforms, such as the Windows feed platform,
typically store a single instance of feed metadata, and a single
instance of entry metadata.

When, for example, a feed title changes, the change applies to the
feed as a whole; it isn't localised to only apply to the entries that
were present in that feed document at the time of the change, because
each entry doesn't typically store its own private copy of feed
metadata.

Implementors can cope with the inheritance of atom:rights and
atom:author, because it is explicitly described in the spec, and
implementors know that they must implement the inheritance at the
document parsing stage, and apply the feed-level data to the entry
before storing the entry before they attempt to store the entries in a
database or whatever, but implementations cannot be expected to apply
all feed-level extensions to the entries that they were transmitted
with, just in case any of them might expect to implement feed document
inheritance.

Feed properties are properties of the feed, not the feed document. An
extension can't implement atom:rights/atom:author style inheritance
from the feed document to the contained entries.

-- 
Dave