Subject: Inheritance of license grants by entries in a feed

From: "Bob Wyman" <[email-masked]>
Date: Sat, 16 Dec 2006 20:55:39 -0500

In general, I think the latest version of James Snell's license ID [1] is
much better than earlier versions. I am particularly pleased that this draft
only speaks of license "grants." I remain, as always, opposed to anything
that would encourage people to attempt to restrict the implied license to
syndicate. I do, however, have a few small issues. The text on "inheritance"
is, I think, almost correct in this draft however, as written it seems to
create a risk of the incorrect granting of rights as well as unfortunate
loss or decay of grants when entries are copied between feeds.

The current draft states: (focus on the underlined bits. The first
underlined sentence is too restrictive, the second too inclusive.)

2.3. Inherited Licenses
> The license on a feed MAY be inherited by entries. Generally, a more
> specific license overrides the less specific license. More specifically,
> if an entry has any license link relations at all, including the
> "undefined" license, it does not inherit the license of
> the feed. If an entry has no license link relations, it does inherit the
> license of its parent feed(s). Since an entry may appear in multiple
> feeds, it may inherit multiple licenses. This is equivalent to stating
> multiple licenses on the entry itself.
>

I am concerned that some readers who are not intimately familiar with
RFC4287 may not understand that entries which contain atom:source elements
do NOT inherit feed metadata from the feeds in which they are found. The
text of the current draft seems to override this constraint on inheritance.
Thus, I propose the following new wording for the third and fourth sentences
in the first paragraph of section 2.3 (the one's quoted and underlined
above):

More specifically, if an entry has any license link relations at all,
> including the "undefined" license, [or, if the entry contains an
> atom:source element,] it does not inherit the license of the feed. If an
> entry has no license link relations[, and contains no atom:source
> element,] it does inherit the license of its parent feed(s).
>

Additionally, I believe that this draft should align with the handling of
atom:rights defined in section 4.2.11 of RFC4287 by adding the following
text at some appropriate location:

If an atom:entry which does not contain an atom:source is copied from one
> feed into another feed then if the feed into which it is copied contains a
> license, an atom:source element SHOULD be added to the copied entry. If a
> source feed contains a license, that license SHOULD be preserved in an
> atom:source element added to any entries copied from the source feed which
> do not already contain atom:source elements.
>

The first constraint is necessary to ensure that the act of copying entries
does not result in rights being granted by the copyist even though those
rights were were not granted by the entry's author. The second constraint
helps to prevent the "loss" or "decay" of rights as things are copied from
feeds with licenses that grant rights into feeds that contain no or lesser
grants.

I realize that clarifying these constraints on inheritance allows for at
least one "odd" result. That is, I might have a feed which contains entries
whose atom:source elements declare license grants that differ greatly from
what is seen in the feed's metadata even though all those entries claim the
enclosing feed as their "source." This actually makes a good bit more sense
than it might seem to at first glance. The reason for this is that the
rights granted for entries added to a feed can change over time even though
changes to the feed's default rights may not impact previously created
entries. Thus, a feed might have granted liberal rights when an entry was
first created but might not offer the same grants when the entry was
updated. The author should be able to maintain with the entry the rights
that were originally granted (or not granted) rather than being forced to
update the rights in order to do something as simple as a spelling
correction. (Yes, I realize that the author could, in some cases, simply
attach the old rights to the updated entry rather than using an atom:source
which contains the same information. However, this can get messy in some
situations and causes us to lose some information about the source of the
license grants -- it may be useful in some cases to distinguish between
licenses granted in feed metadata and those granted in entry metadata.
Forcing attachment of licenses to entries would also require using the
"undefined" license in more cases than is desirable.)

I've got a few other comments -- destined for other messages. Nonetheless,
this draft is looking much better than earlier drafts.

bob wyman

[1]
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-10.txt

---

From: James M Snell <[email-masked]>
Date: Sat, 16 Dec 2006 18:10:58 -0800

Bob,

As always, thanks for the feedback.  These are excellent suggestions.
I'll work them into the next draft.

- James

Bob Wyman wrote:
> In general, I think the latest version of James Snell's license ID [1]
> is much better than earlier versions. I am particularly pleased that
> this draft only speaks of license "grants." I remain, as always, opposed
> to anything that would encourage people to attempt to restrict the
> implied license to syndicate. I do, however, have a few small issues.
> The text on "inheritance" is, I think, almost correct in this draft
> however, as written it seems to create a risk of the incorrect granting
> of rights as well as unfortunate loss or decay of grants when entries
> are copied between feeds.
> 
>     specific license overrides the less specific license. More
>     specifically, if an entry has any license link relations at all,
>     including the "undefined" license, it does not inherit the license of
>     the feed. If an entry has no license link relations, it does inherit
>     the license of its parent feed(s). Since an entry may appear in
>     multiple feeds, it may inherit multiple licenses. This is equivalent
>     to stating multiple licenses on the entry itself.
> 
> 
> RFC4287 may not understand that entries which contain atom:source
> elements do NOT inherit feed metadata from the feeds in which they are
> found. The text of the current draft seems to override this constraint
> on inheritance. Thus, I propose the following new wording for the third
> and fourth sentences in the first paragraph of section 2.3 (the one's
> quoted and underlined above):
> 
>     More specifically, if an entry has any license link relations at
>     all, including the "undefined" license, [or, if the entry contains
>     an atom:source element,] it does not inherit the license of the
>     feed. If an entry has no license link relations[, and contains no
>     atom:source element,] it does inherit the license of its parent feed(s).
> 
> 
> Additionally, I believe that this draft should align with the handling
> of atom:rights defined in section 4.2.11 of RFC4287 by adding the
> following text at some appropriate location:
> 
>     If an atom:entry which does not contain an atom:source is copied
>     from one feed into another feed then if the feed into which it is
>     copied contains a license, an atom:source element SHOULD be added to
>     the copied entry. If a source feed contains a license, that license
>     SHOULD be preserved in an atom:source element added to any entries
>     copied from the source feed which do not already contain atom:source
>     elements.
> 
> 
> The first constraint is necessary to ensure that the act of copying
> entries does not result in rights being granted by the copyist even
> though those rights were were not granted by the entry's author. The
> second constraint helps to prevent the "loss" or "decay" of rights as
> things are copied from feeds with licenses that grant rights into feeds
> that contain no or lesser grants.
> 
> least one "odd" result. That is, I might have a feed which contains
> entries whose atom:source elements declare license grants that differ
> greatly from what is seen in the feed's metadata even though all those
> entries claim the enclosing feed as their "source." This actually makes
> a good bit more sense than it might seem to at first glance. The reason
> for this is that the rights granted for entries added to a feed can
> change over time even though changes to the feed's default rights may
> not impact previously created entries. Thus, a feed might have granted
> liberal rights when an entry was first created but might not offer the
> same grants when the entry was updated. The author should be able to
> maintain with the entry the rights that were originally granted (or not
> granted) rather than being forced to update the rights in order to do
> something as simple as a spelling correction. (Yes, I realize that the
> author could, in some cases, simply attach the old rights to the updated
> entry rather than using an atom:source which contains the same
> information. However, this can get messy in some situations and causes
> us to lose some information about the source of the license grants -- it
> may be useful in some cases to distinguish between licenses granted in
> feed metadata and those granted in entry metadata. Forcing attachment of
> licenses to entries would also require using the "undefined" license in
> more cases than is desirable.)
> 
> I've got a few other comments -- destined for other messages.
> Nonetheless, this draft is looking much better than earlier drafts.
> 
> bob wyman
> 
> [1]

---

From: David Powell <[email-masked]>
Date: Sun, 17 Dec 2006 22:33:22 +0000

Sunday, December 17, 2006, 1:55:39 AM, Bob Wyman wrote:

>  2.3.  Inherited Licenses
> The license on a feed MAY be inherited by entries.

James,

I'm not sure exactly what you are trying to achieve with the
inheritance rule for licenses, but I think that it could do with the
term "feed" being more accurately specified.

Whilst it would be very useful for extensions to be able to support
inheritance rules like the ones that Atom specifies for atom:author
and atom:rights, which cause properties applied to a "feed document"
to inherit to the entries declared within the "feed document"; there
is nothing in Atom's specification of extensions elements that
supports this short-hand notation, and attempting to emulate this
behaviour in an extension will cause real-world implementations of
feed stores to incorrectly assign, or not assign, licenses to the
wrong entries. Simply because Atom implementations tend to give
entries and feeds seperate life-cycles, and implementations that
maintain a feed-state over multiple pollings of a feed are unlikely to
associate each entry with the set of feed document metadata from each
of the documents that it occurred in.

Eg, 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. This will mean that if you change the license in the feed
document when a feed is subsequently polled, intending it only to
apply to the entries within that new feed document, you will
effectively retroactively apply the license to the old entries too.
Atom, unfortunately, doesn't have a way of indicating that an
extension applies at "feed document"-level and MUST be processed at
the feed document parsing stage.

What you can do however, is to specify that feed licenses apply to the
"feed", and inherit to the entries in the feed. This behaviour doesn't
require implementations to be psychic and guess that an unknown
extension needs to be processed at the document parsing stage. 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.

This might be your intention, but I'm not clear from the draft.

-- 
Dave

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 18 Dec 2006 17:22:17 -0500

On 12/17/06, David Powell <[email-masked]> wrote:
> "feed", and inherit to the entries in the feed. ... It

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." Atom only supports associating meta-data with Feed Documents.
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. 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.

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? This rule would tend to force us to
   create new feeds (i.e. new feed ids) whenever authors, contributors,
   or rights change. This would make a mess for aggregators and feed readers
   who have enough trouble keeping up with changes in the syndisphere...
   - 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? (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?)
   - 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?
   - 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? 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...)
   - 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?

I could go on...But, I hope the case is made. Feed Documents only describe
themselves and the entries they contain. They do not "describe" the feed.

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

bob wyman