On 2006-09-05 15:11:22 -0700, James M Snell wrote: > 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.
Well, the definition of the atom:rights field is really just another way to describe what a license is. Namely, the law gives you certain rights that you, and only you, can exercise. A license is about which of these rights you retain, and which ones you let others exercise. The example in section 2 of draft-snell-atompub-feed-license-08 actually uses the atom:rights field for indicating which license applies. How would that mix with a license link that points at another Creative Commons License? And what effect does that have for, say, license-based search engines? I don't think the spec can wriggle out of this by saying that the two aren't entirely the same and maybe shouldn't conflict. > >> - 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. Obviously, that's not obvious. Who are we to tell that Sam hasn't obtained the right to attach these licenses out-of-band? > 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. I don't think this spec needs to deal with the case that license links might be altered by intermediaries. It's fine to mention that in the Security Considerations section, but I don't think it's a case that should influence the overall design. In Atom, we so far have an atom:rights entry that describes licenses on entries. Either, it sets a default (with all the problems that you describe), or, it sets the rights for a specific entry. In what way this gets used (and whether that use is the right one) is up to the party that authors an entry or a feed. The rel=license proposal moves away from this approach: The semantics here are that it makes a statement about whatever object it is attached to -- either a feed (with peculiar semantics that might quite well depend on the jurisdiction), or to entries that are children of that feed. This inconsistency is a recipe for confusion. In the interest of consistency, I'd suggest to replicate the semantics of atom:rights for whatever URI-based scheme is introduced. If there's a need for feed-level licenses, then that should be marked up separately. (I can see use cases for that, see below; I'm not sure it's something urgent.) > >> - 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. >From draft-snell-atompub-feed-license-08: "License" link relations appearing within a feed MUST apply to the metadata of the containing feed element only and do not extend over the metadata or content of any contained entries. I don't see the selection and arrangement in there. It might be best to focus on licenses on entries for the moment, and do licenses for metadata, selections and arrangements separately, if at all. > >> - 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. I'll give a +1 to Wendy's suggestion to just drop this. There's one more point that the spec might need to drill down on: It is not clear to me whether atom:rights -- or rel=license, for that matter -- applies to the material in an entry [ultimately, metadata about a resource], or to the (in Atom speak) alternative versions [the resource that the entry is about, in RDF speak]. This probably doesn't matter too much for blog data; it likely does matter in other contexts. I'd hope that I'm missing some point, but quite possibly there needs to be an explicit decision here whether the license link is expected to apply only to the material in the entry, or to the "alternative versions" [resources the entry is about] as well. Regards, -- Thomas Roessler <[EMAIL PROTECTED]>
