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
