Hello Wendy, Thanks for the feedback. I've cc'd the atom-syntax list so the rest of the Atom community can comment.
Comments below. Wendy Seltzer wrote: > Hi all, > So my first thoughts upon seeing the draft are to wonder why it's > necessary to make assertions about the legal effects of including a > license -- especially since some of those assertions seem to obviate the > purpose of using a license declaration. While it's helpful to tell > people how to indicate, technically, what they mean for a license to > attach to, it's not useful to offer guidance on how to interpret the > license. > > Namely: > > 1.1 It must also be noted that licenses associated with feeds or entries > using these mechanisms are advisory and are not, by themselves, > legally binding. Nor can a license associated with a feed or entry > restrict or forbid access to, redistribution, aggregation, caching > and display of those items by third party intermediaries such as > search engines and so-called "online aggregators". > > Why can't they be legally binding? They're not self-executing, but > licenses outside of feeds aren't either, and likewise may or may not be > legally binding depending upon other things than just the form of their > expression. > To this point I've received exactly the opposite feedback from others (all of whom weren't lawyers, btw, but who have had experience with licensing issues in the past). It is my understanding that the licenses cannot be considered legally binding *by themselves*. That is, precisely as you indicate, they are not self-executing. > > 2 "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. > > Why? Why would a feed need a license separate from its content? Lots of > the metadata elements would be functional or would give users fair use > claims, absent a license. > Sam Ruby's planet feed is a prime example. Sam does not own rights over the individual entries that appear within his feed, however, Sam does own the rights over the feed itself, including the selection and arrangement of entries within that feed. I've mentioned before that it's roughly equivalent to distributing dependencies with an open source project. Each of the dependencies have their own license, distinct from the projects license. > 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. > > This seems to be going down a road of legal interpretation that's > unnecessary and not necessarily correct. The current CC licenses are > offered on a "taker beware" basis -- the licensor offers the rights he > has, and doesn't guarantee a licensee's rights (or even his own) to > anything he might have incorporated. That's not the only way to write a > license, though. (Even within CC, version 1 had an explicit > representation and warranty section that was dropped in v.2.) > > Implementations should trust the legal representations only as much or > as little as they trust any other claim made by the feed. How licenses > chain is a matter of individual legal interpretation. > Ok, so if I'm interpreting this comment correctly, the recommendation would be to simply remove the paragraph in question? > > Forgive me (but please clarify!) if I'm misinterpreting some of the draft. > > Thanks, > --Wendy > Thanks for taking the time to review, - James
