Subject: Atom license link last call

From: James M Snell <[email-masked]>
Date: Mon, 14 Aug 2006 18:21:45 -0700

FYI...
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13576&rfc_flag=0

The current spec:
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-06.txt

The intended target is "Experimental"

- James

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 15 Aug 2006 18:16:18 +0200

>http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-06.txt

I do not understand section 4, it says the security considerations of
RFC 4287 apply; the only consideration there that could apply is that
IRIs are used, and as such considerations of RFC 3987 apply. The actual
registration then says there are no security considerations for the
new link relation. I think both sections should say the same, and if
security is truly irrelevant to the link relation, it should say that.
Perhaps you might to say something like, when used in Atom documents,
the security considerations for handling links in Atom documents apply.

I would personally like to see some note that implementations cannot
necessarily trust that the publisher has the right to license material
claimed to be covered by the license, and that care should be taken
when making decisions based on the license reference, such as
republishing the content.

The third paragraph in section 3 seems overly verbose to me, is there
no terminology introduced in RFC 4287 that could be used and/or re-
ferenced instead of the verbose discussion? Or is this assumed to be
the case already, and the "Implementors should note" non-normative
note just re-states what is stated elsewhere in the draft or the Atom
specification?

I do not quite understand feed-level licenses, the draft just says
what they don't cover, not what they do cover. Say I make a feed with
the five most insightful blog postings on international politics and
I license the feed under the most permissive license possible. Can
you then copy my list of entries over to your top five list? Just the
IRIs, or also the summary I wrote for those entries? What if I copied
the summary over from the original feed (assuming, e.g., I may copy
those, but you may not, for some twisted legal reason)? If I relate
the license to the entries, would the license cover my summary and
the third party entries, or just my summary, or just the content of
the third party entry? Should atom:source be used in such scenarios
specifically for license reasons?

I think the concept of "informational content" used to explain some
of these things is too unclear to me to answer these questions.

I think the reference to "copyright licenses" is a bit unfortunate.
Why is this reference to "copyright" necessary?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: James M Snell <[email-masked]>
Date: Tue, 15 Aug 2006 09:36:28 -0700

Bjoern Hoehrmann wrote:
>[snip]

Yeah, this would be better.  This draft doesn't introduce any security
concerns of it's own.

> republishing the content.

Good catch.

Another concern that was raised to me by a colleague is that the license
resource being pointed to could change over time, meaning that the
license being referenced today may not be the same license being used
tomorrow even tho URIs may be exactly the same.  If the license is
controlled by a different entity than the publisher of the entry, this
could cause problems.

> note just re-states what is stated elsewhere in the draft or the Atom

Unfortunately, there is no language in RFC4287 I can draw upon here.

> specifically for license reasons?

Yes, this should be clarified.  Feed level licenses cover the metadata
of the feed (title, subtitle, etc).  I've actually found very little use
for feed level licenses and would actually be quite happy to remove them
from the spec completely.

> of these things is too unclear to me to answer these questions.
Ok

> Why is this reference to "copyright" necessary?

Can you suggest a better term?

- James

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 15 Aug 2006 22:10:34 +0200

>controlled by a different entity than the publisher of the entry, this

Yeah, it would be good to have some of these things mentioned in the
draft, if only to encourage people to let a lawyer review tools they
may build upon this new link relation.

>Unfortunately, there is no language in RFC4287 I can draw upon here.

Okay, I guess this should be looked at when RFC 4287 is revised.

>from the spec completely.

I think removing it would be better, yeah.

>> of these things is too unclear to me to answer these questions.

I hope you can come up with a better term and/or explain this better
in the draft, as I'd have similar difficulties for entries.

>Can you suggest a better term?

Just "licenses"?

---

From: James M Snell <[email-masked]>
Date: Tue, 15 Aug 2006 13:18:20 -0700

Based on this and other feedback, I think I've come up with language
that is much more effective.  It keeps feed level licenses but very
clearly specifies what they cover.  I am putting the polishing touches
on the draft and will send it off shortly.

- James

Bjoern Hoehrmann wrote:
> [snip[

---

From: Karl Dubost <[email-masked]>
Date: Wed, 16 Aug 2006 08:39:50 +0900

Le 16 août 06 à 01:16, Bjoern Hoehrmann a écrit :
> you then copy my list of entries over to your top five list?

hmmm.
I would not say that it's not useful but there are potentially  
troubles. We should have a use case reasoning with regards to the  
technology and *not* the legal aspects.

I can indeed decide to license the content for all my feed items in  
one shot because I own the content.  If it's the meaning of link at  
the feed level, no trouble.
So with regards to the comment of Bjoern, what's missing is the scope  
nature of link, not necessary if it's right or not to license a  
republished content with difference license. Here it fells in the  
legal part of it, which has to been handle by the civic society.

-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***

---

From: James M Snell <[email-masked]>
Date: Thu, 17 Aug 2006 08:29:32 -0700

Hello Bjoern,

Please take a look at the latest draft:

http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-07.txt

- James

---

From: James M Snell <[email-masked]>
Date: Fri, 18 Aug 2006 11:18:14 -0700

Hello Bob,

Bob Wyman wrote:
> James,
> 	My apologies if these questions and comments have been dealt with
> before:
> 	* What is the expected or intended relationship between data carried
> in the atom:rights element and data pointed to by the license relationship?

The relationship is subtle, but important, consider the following
example pulled from draft-07 that I just published:

     <feed xmlns="http://www.w3.org/2005/Atom">
       <id>http://www.example.com/myfeed</id>
       <title>My Example Feed</title>
       <updated>2005-07-28T12:00:00Z</updated>
       <link href="http://www.example.com/myfeed" />
       <link rel="license" type="application/rdf+xml"
         href="http://creativecommons.org/licenses/by-nc/2.5/rdf" />
       <rights>
         Copyright (c) 2005. Some rights reserved. This feed
         is licensed under a Creative Commons Attribute-NonCommercial
         Use License. It contains material originally published by
         Jane Smith at http://www.example.com/entries/1 under the
         Creative Commons Attribute License.
       </rights>
       <author><name>James</name></author>
       <entry>
         <id>tag:entries.org,2005:1</td>
         <title>Atom Powered Robots Run Amok</title>
         <updated>2005-06-28T12:00:00Z</updated>
         <link href="http://www.example.org/entries/1" />
         <summary>Atom Powered Robots Run Amok</summary>
         <author><name>Jane Smith</name></author>
         <link rel="license" type="text/html"
           href="http://creativecommons.org/licenses/by/2.5/" />
       </entry>
     </feed>

Note that the feed level rights element covers the attribute requirement
of the contained element.  The distinction is similar to NOTICE and
LICENSE files distributed with many open source projects.

> 	* Why did you choose the word "license" when Atom itself uses the
> word "rights" for a very similar (if not identical) concept?

Because I specifically wanted to differentiate the two.

> 	* If the intent of the license link is to provide a mechanism to
> support "out of line" rights elements, then did you consider doing something
> similar to the handling of out-of-line atom: content via a "src" attribute?
> For example: Does the license link do anything that would not be
> accomplished by adding support for rights elements in the following form:
> 	<rights src="http://..."/>
> 

Changing the atom:rights element via an extension is out of the
question.  The rights element is what it is.

> 	* If a feed reader discovers both atom:rights and a license link in
> a single entry or feed, is there any concept of precedence between the two?
> For instance, if the text of the license is more or less restrictive than
> what is in the atom:rights element, what should the reader assume about the
> rights that are granted?
> 

The two serve different, but related, purposes.  The two should not
contradict each other.  If they do, consumers must go back to the
content publisher to resolve the problem.

- James

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 18 Aug 2006 14:08:36 -0400

James,

	bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 21 Aug 2006 15:57:43 -0400

James Snell wrote:
> [1] The relationship [between license and atom:right] is
> subtle, but important ...
> [2] I specifically wanted to differentiate the two. ...
> [3] The two serve different, but related, purposes.  The
> two should not contradict each other.  If they do,
> consumers must go back to the content publisher to
> resolve the problem.
	Given the subtle differences, the claimed importance of the
differences, and their supposed utility, I would strongly suggest that these
points should be clearly stated in the ID itself. It is highly unlikely that
readers of an eventual RFC are going to universally come here and read the
illuminating messages in the mailing list archive. Thus, the subtle
distinctions that you see are highly likely to be lost once the RFC is
published -- unless you document them. Also, it is more likely that
reviewers will be able to make more informed judgments if these distinctions
are clearly documented in the ID text.

	bob wyman

---

From: Andreas Sewe <[email-masked]>
Date: Tue, 22 Aug 2006 11:03:22 +0200

> Because I specifically wanted to differentiate the two.

IIRC James' answer to a mail I wrote him about the very same issue, it 
is also to maintain consistency with the already established rel-license 
microformat <http://microformats.org/wiki/rel-license>.

FWIW, the above page claims that "Rel-License is a simple, open, format 
for indicating content licenses which is embedable in (X)HTML, Atom, 
RSS, and arbitrary XML." But using rel="license" on atom:link would have 
been, up to James' I-D, highly dubious, since that would have been 
equivalent to <http://www.iana.org/assignments/relation/license> which 
is not yet registered.

Maybe we should tell the microformats.org people that Atom uses IRIs for 
its link relations, not bare names. (They would even benefit from it, 
since some experimental <http://microformats.org/relation/foo> relation 
would not require IANA registration.)

Regards,

Andreas Sewe