Subject: Re: Inheritance of license grants by entries in a feed

From: David Powell <[email-masked]>
Date: Sun, 14 Jan 2007 20:04:12 +0000

Sorry for the delay in responding. I disagree that feed elements apply
to the feed document and not the feed itself. I believe that both the
spirit and letter of the specification make it clear that feed
elements are metadata about the feed not the document, and the typical
behaviour of implementations seems to agree.

I agree that it is important to distinguish between feeds and feed
documents, and this is why I think that feed level inheritance of
licenses should be dropped as it is incompatible with Atom.

Monday, December 18, 2006, 10:22:17 PM, Bob Wyman wrote:

> On 12/17/06, David Powell <[email-masked]> wrote:
>>  What you can do however, is to specify that feed licenses apply to the
>> "feed", and inherit to the entries in the feed. ... It
>> means that the license applies to all entries in that feed,  not just
>> ones in that specific feed document. This is probably reasonable
>> behaviour for licenses anyway.

> Particularly in the case of licenses, it is very important to
> distinguish between the "feed" or stream of all entries (past,
> present and future) associated with a feed id and the actual feed
> documents that encapsulate subsets of that stream.

> Atom provides no mechanism for associating meta-data with "feeds."

The text of RFC4287 seems to contradict this:

  The "atom:feed" element is the document (i.e., top-level) element of
  an Atom Feed Document, acting as a container for metadata and data
  associated with the feed.

Atom does support inheritance of <author> and <rights> elements, but
only because this is behaviour is clearly documented in the core
specification, so there can be no doubt of how implementations should
process these elements:

  If an atom:entry element does not contain atom:author elements, then
  the atom:author elements of the contained atom:source element are
  considered to apply. In an Atom Feed Document, the atom:author
  elements of the containing atom:feed element are considered to apply
  to the entry if there are no atom:author elements in the locations
  described above.

Effectively, this inheritance can be implemented by copying the
elements at the feed document parsing stage.

You can't just say that the license extension inherits and expect
every implementation out there to implement that.  You'd need an Atom
2.0 to do that: either support for must-understand (which was rejected
from Atom 1.0), or a special feed document extension container.  I
agree that feed document inheritance would be a useful feature, but as
we don't have it we'll have to write out these duplicate elements
longhand.  It isn't such a big deal though.

It also seems obvious to me that feed elements are metadata applied
to the feed based on the expected behaviour of implementations.  As an
example:

I observed a feed that I am subscribed to in Bloglines change its feed
title in the feed list pane. The feed did this by changing the value
of the <title> element for the feed. Surely you wouldn't say that no
conclusion can be drawn from this change in feed document as to the
intended change in state of the feed?

The whole feed model is based around changing feed documents
communicating the latest state of the feed; for both the entries in
the feed and the feed itself.

In fact the whole web is based around the fact that representations of
resources can vary over time, and that the latest representation is,
the latest.

> Data in one feed document does not apply to entries found in another
> feed document -- or to entries that stand-alone. Feed meta-data
> found in one feed document does not override, compliment or
> invalidate feed meta-data found in other feed documents.

If you poll a feed twice you have two feed documents.  These are
obviously related.  If I update an entry element, then the latter
version is understood to be a replacement.  You can correlate them by
the entry ids and updated.  If I update a feed element, then the
latter version is understood to be the replacement.  What's the
problem?  I don't see how it could work any other way.

> This is one of the many reasons we have atom:source -- so that we
> can bind specific feed meta-data to an entry no matter what context
> in which that entry might appear or when it might be read.

Atom doesn't describe the processing model of Atom documents
explicitly enough for me to infer much about the semantics of
atom:source.  If you want each entry (or a group of entries within a
document) to have its own private feed state, then atom:source is one
way to implement that.  Needing to do that is a good sign that you are
abusing feed elements to carry entry metadata though.

> If we had a case where data in one feed document overrides data in
> other feed documents, we'd have a mess. Some of the questions that
> we'd have to answer are:

> + Elements like atom:author, atom:contributor and atom:rights can
> and do change over time -- sometimes frequently. If such a change
> occurs, does it mean that we've implied a change to all previous
> entries published in all previously published feed documents? 

RFC4287 is clear about the semantics of these elements. They apply to
the feed, and are also inherited to the entries. They can do that
because that behaviour is prescribed in the RFC; we can't do that for
license extensions because it is not.

The authorship of the feed applies to the feed in general.  The
authors of boingboing might be Mark, Cory, David, Xeni, and John.
That doesn't mean that these have to be updated dynamically depending
on who the actual authors of each of the 10 entries in the feed are at
that instant.  Admittedly the behaviour of these "inheriting"
elements, and the interactions between their applicability to the feed
and to the entries is a bit odd.  I don't like it much.

> (i.e. if the earlier Feed document had an atom:contributor field but
> a later Feed Document does not, does this mean that we wipe out
> knowledge of the contributor who might have been essential to
> creating some of the earlier entries? (That's kind of heartless --
> it would be a high tech version of "What have you done for me
> lately?...") Or, do we improperly maintain the old contributor as a
> contributor of new entries --potentially long after the contributor
> has died?)

If you want the contributor to apply specifically to entries that the
contributor wrote, then put it on the entry.  If you just want to
describe general current contributor-ship then put it on the feed.

> + If data is present in one feed doc but not another later document,
> does the absence of the data in the later document override the
> previous document or do we combine what we know from both documents?

The former.  Its the same with feeds as it is with entries.

> + How do we handle mistakes? For instance, if after
> publishing several thousand feed documents in sequence, I might
> publish one that accidentally grants "all rights to everyone" when I
> really meant to grant only "non-commercial" rights. Does the new
> badly coded feed document force all of the thousands of entries I've
> been working on over time into the public domain even if that wasn't
> what I intended?

If you post a message on your website that says that all of your
website is in the public domain, by mistake, does that force all of
your website into the public domain.  I don't know, I'm not lawyer.

> + How do I "repair" the mistake discussed immediately
> above? If I publish a new feed document with a license grant for
> "non-commercial use," does that then apply to all previously
> published entries -- including those that were accidentally
> published with over-generous rights?

Yes.

> Does this mean that I can use a license in one feed document to
> *restrict* or rescind rights granted by another feed document? (This
> would be a very bad thing...)

Yes, documents on the Internet aren't immutable. I don't see how this
is surprising.

> + If I have an aggregator that picks up some content which is
> licensed for general use today, how can I be sure that I can still
> use the content tomorrow? If the content of a Feed Document applies
> retroactively, it would seem that I have to re-fetch the feed every
> time I use content from the feed so that I can check the metadata.
> This doesn't seem to make sense. If I were sued by someone, could I
> use the argument: "But, I didn't read the new, more restrictive Feed
> Documents!" Is ignorance an excuse?

The whole web works this way.  Here is a link:

http://www.apple.com/legal/terms/site.html  

How can you know that these terms and conditions haven't changed once
you've read them?  You can't.

>> if you store a feed in an implementation such as 
>> Microsoft's Feed Engine, only a single set of feed
>> extensions will be associated with the feed.

> While it is important to be aware of the inadequacies (as well as
> the strengths) of implementations by companies with significant
> market power, I don't think that we can simply delegate the
> standards writing process to such companies or modify standards to
> cover up their bugs. The fact that Microsoft or any other company
> has done the wrong thing should not, in itself, be sufficient to
> dictate the development of standards. Hopefully, they will
> eventually see the error in their ways and correct them. 

I believe that that implementation is behaving correctly. It follows
the RFC and it is no different that other feed readers I've seen.

-- 
Dave

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 14 Jan 2007 17:55:50 -0500

On 1/14/07, David Powell <[email-masked]> wrote:> You can't just say
that the license extension inherits and
> expect every implementation out there to implement that.
>  You'd need an Atom 2.0 to do that: either support for
> must-understand (which was rejected from Atom 1.0),
> or a special feed document extension container.

An implementation should only do things based on the license extension if it
understands what the license extension means. Since the draft now has
carefully written words to ensure that license extensions only grant
additional rights and do not restrict default rights, the worst case
situation is that an implementation that doesn't understand the license
extension inheritance will simply treat entries as though they only had
normal, copyright-defined rights associated with them. i.e. You would get
fair use, implied right to syndicate, right to read, right to make
facilitative copies, etc. but you wouldn't realize that you also get
whatever extra rights were granted by the license. This is, I think a
reasonable fall-back. Of course, implementations that do understand that
feed-level licenses are inherited will be able to manage rights just a bit
better. This is a good thing.

A failure to properly implement license inheritance tends to limit what the
*reader* believes they can do with entries, but it doesn't do any "harm" to
the owner of the intellectual property in the entries since no one can
believe that they have rights not granted. The worst that can happen is that
readers don't know all the rights they have. This is acceptable, in my
opinion.

bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 14 Jan 2007 18:43:10 -0500

On 1/14/07, David Powell <[email-masked]> wrote:>Atom doesn't
describe the processing model of Atom
> documents explicitly enough for me to infer much about
> the semantics of atom:source. ...
> Needing to [use atom:source] is a good sign that you
> are abusing feed elements to carry entry metadata
> though.

There are quite a few very common, non-abusive reasons for using
atom:source. For instance, the RFC clearly discusses the case where an entry
is copied from one feed document into another and needs to maintain its
association with the feed metadata of the source feed. There is also the
question of signatures....

In any case, I read the Atom spec as clearly intending that an entry with an
atom:source element can be semantically equivalent to a single entry feed
document whose feed meta-data is equivelant to that contained in the entry's
atom:source. If this isn't what appears to be written, then I suggest that
it is a case of non-optimal drafting and the history of this group should be
consulted to clarify the intent. I explained why entries with source needed
to be equivelant to single entry feeds when I made the original proposal for
atom:source at the first Atom community meeting at Sun in June of 2004 and I
made it continuously throughout the process of drafting the RFC. This is
also one of the many reasons why Atom "assigns no significance to the order
of atom:entry elements within the feed." The meaning of an entry derives
only from data which is either encoded within it or which is recorded as
part of the feed metadata associated with the entry. That association is
either by containment within a feed document or, more strongly, by
encapsulating the feed metadata within the entry. This equivelance property
is essential in order to make aggregated/synthetic feeds work and it is
necessary to make licensing work properly. (Yes, there were some of us
thinking about licensing long before James made his proposal...) Thus, the
"processing model" for an entry with an atom:source is just as precisely
described as the processing model for a single entry feed document...

bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 14 Jan 2007 19:16:24 -0500

On 1/14/07, David Powell <[email-masked]> wrote:> I agree that it is
important to distinguish between feeds
> and feed documents, and this is why I think that feed
> level inheritance of licenses should be dropped as it is
> incompatible with Atom.
Inheritance can't be "incompatible" with Atom since Atom defines it.
I do agree with you, however, if you argue that Atom would have been cleaner
without inheritance. Without inheritance, feed level meta-data would only
apply to the "collection" which contains entries and not to the entries
themselves. Without inheritance, we wouldn't need atom:source -- we would
have only needed atom:provenance (a simple link to an entry's origin feed
similar to the source element in RSS. Note: Synthetic feed producers still
would have wanted atom:source as a convenient way to reduce the need to
repeatedly fetch feed documents to get atom:title values.) However, folk
really wanted to keep inheritance of the feed metadata and so we ended up
having to define something more complex.

bob wyman

---

From: James M Snell <[email-masked]>
Date: Mon, 15 Jan 2007 08:16:38 -0800

In the current draft, license links *are* inherited.

Thomas Roessler wrote:
> On 2007-01-14 20:04:12 +0000, David Powell wrote:
> 
> [snip]
> Be that as it may -- the atom:rights element *is* inherited, and I'd
> expect some major confusion if a atom:license element wasn't.
>