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