Hello Thomas, Thank you for taking the time to review the draft. I have cc'd this response to the atom-syntax list so that others in the Atom community can comment.
Comments below. Thomas Roessler wrote: > Hi Mike, James, pleased to meet you. > > I'm adding Wendy Seltzer to the CC list, who (I think) might have > some points to add from a legal perspective. > > Here's the quick review that I did earlier today: > >> - What's the relationship between licensing information contained in >> a license-type link and licensing information contained in an >> atom:rights element? > > (For the definition of atom:rights, see section 4.2.10 of RFC 4287.) > >> The example under 2.1 in the I-D suggests that the atom:rights is >> expected to reflect the license that is identified in the link >> element. However, there seems to be no machine-readable way to >> express that connection. >> >> Also, there can be multiple license links, but only one rights >> element. >> This is the third time I've been asked this. I guess I really do need to add a clear statement about the relationship in the spec. With enough thumps on the head I usually come around ;-) The relationship is relatively simple. The atom:rights element is always a human-readable statement of what rights are held over the feed or entry. It's is the equivalent of saying "Copyright (c) James Snell" and cannot be relied upon to tell the consumer anything useful about what the consumer can do with the feed or entry. The license link, on the other hand, is specifically intended to provide a reference to the license applied to the feed/entry; that is, what kinds of things others are allowed do with the feed/entry. >> - An atom:rights element on a feed sets the default for the >> atom:rights elements on entries; a license link on a feed, >> however, is expected to apply to the metadata and NOT to the >> entries. >> >> Why the difference in inheritance rules and semantics? This is something that I've debated back and forth on but the difference comes down to an issue with aggregated feeds. Take, for instance, Sam Ruby's Planet feed (http://planet.intertwingly.net/atom.xml). This feed consists of entries that originated from many different sources, some of which may have license links, some that might not. If Sam decided to put a license link at the feed level, and if license links were inherited, it would mean that Sam's license would be extended over resources he may have no right to license. Obviously, that's wrong. One two possible solution would be for Sam to some how indicate that an entry in his feed did not have a license link, but doing so could cause other problems (such as invalidating any XML digital signatures that may be covering the entry). Also, it's possible that the entry originally came from a feed that did include a license link, but that some intermediary along the way failed to properly carry over the license link into the entry after separating it from the feed. The bottom line is that license inheritance opens too many potentially significant issues. (and yes, these issues apply equally to the atom:rights element). The simple solution, then, is to specify that license links only cover the feed or entry containing the link. >> >> - It's probably worth noting that there are jurisdictions in which >> databases enjoy sui generis legal protection (e.g., the EU). In >> such jurisdictions, it might be reasonable to have license >> information that refers to the collection, not just to its >> metadata. >> The selection and arrangement of entries in the feed is covered by feeds license. >> - The following statement: >> >> Entry content might include or reference material from other >> sources. Licenses associated with an entry MUST NOT be assumed >> to cover such material. Implementations cannot necessarily >> trust that publishers have the right to license material claimed >> to be covered by any associated license. Care should be taken >> when making decisions based on the referenced license. >> >> ... takes all of the value out of this scheme. The very point of >> annotating content (even aggregate content) with a license is that >> this license be trusted. > > (I understand this to be, in part, a legal layman's overstatement; > I'll leave it to the lawyers to comment. ;) > Yes, I don't like this either. But the fact remains that an entries content may include content from other sources that cannot be assumed to be covered by the license associated with the entry. The analogous situation occurs in Open Source Software distributions in which dependencies shipped with a project may have their own licenses that are distinct from the license used for the project code itself. The question really is whether or not this is worth calling out explicitly in the spec. >> Summary: The relationship to atom:rigts should be cleaned up. The >> questions above about what precisely a license applies to probably >> points at a problem in terms of expressivity of the linking scheme >> -- an argument could be made that there should be machine-readable >> ways to express what precisely a license link is supposed to apply >> to. Something like rel={content-license, dataset-license, >> entry-default-license}? > >> Overall, this document looks like it is in dire need of serious >> review from legal experts -- e.g., from the Creative Commons >> community. That would be excellent. > > I, too, would be happy to move this discussion to a public mailing > list. Is the atompub list the right place to have this > conversation, or should this go to the IETF plenary, as this draft > is in IETF Last Call? > The atom-syntax list would be an appropriate forum. - James
