Re: atom license extension (Re: [cc-tab] *important* heads up)
On 2006-09-08 08:21:59 -0700, James M Snell wrote: I think the discussion around this has been absolutely excellent. Lots of very good information and perspectives. At this point I need to stew over things for a few days and think about how to proceed with the extension. The last call for this spec is ending today... I'm wondering a bit what the next step (if any) between you and Lisa (as the shepherding AD) needs to be in order to make sure that this goes as you intend it to go. -- Thomas Roessler [EMAIL PROTECTED]
Re: atom license extension (Re: [cc-tab] *important* heads up)
I talked with Lisa a bit about this next week. I'll be working on iterating the draft based on this conversation and will request another last call once it's ready to go. - James Thomas Roessler wrote: On 2006-09-08 08:21:59 -0700, James M Snell wrote: I think the discussion around this has been absolutely excellent. Lots of very good information and perspectives. At this point I need to stew over things for a few days and think about how to proceed with the extension. The last call for this spec is ending today... I'm wondering a bit what the next step (if any) between you and Lisa (as the shepherding AD) needs to be in order to make sure that this goes as you intend it to go.
Re: atom license extension (Re: [cc-tab] *important* heads up)
I think the discussion around this has been absolutely excellent. Lots of very good information and perspectives. At this point I need to stew over things for a few days and think about how to proceed with the extension. In addition to the several technical changes that I may end up making to the specification, I am thinking now that a detailed description of the non-technical issues surrounding this spec would be a great addition to the document. I'm just not sure I'm qualified to write such a thing myself. - James Bob Wyman wrote: John Panzer asks of Karl Dubost: (Let's say that Doc Searls somehow discovers a license that would deny sploggers more than implied rights to his content while allowing liberal use for others[1], and deploys it. Are you saying that all of his readers' feed software would have to drop his feed content until they're upgraded to understand the license?) [1] http://doc.weblogs.com/2006/08/28 I think John's question can be (aggressively) rephrased as: Can Doc Searls, by inserting a license in his feed, 'poison' the entire syndication system that we've built over the last few years? (i.e. Can he do things that make it unsafe or illegal for people to do things which the syndication system was intentionally built to permit and which he knew were being done before he willingly inserted his content into the syndication network?) I don't think so. As argued in other messages, I strongly believe that we should not do anything that hinders or conflicts with the establishment or recognition of a limited implied license to syndicate content which is formatted using RSS/Atom and is made openly available on the network. (An interesting question, of course, would be: What does it mean to 'syndicate'?) In any case, there is a general problem of proper notice here. As mentioned before, there is nothing special about an optional IETF protocol extension. This subject of inserting licenses in content should be discussed in a general sense -- not limited to this specific protocol extension. A vital question to ask is: What is proper notice of the presence of a license? No IETF standard has the force of law. Readers are not obligated to understand or even take note of the license links. Thus, no one using it should be able to have any expectation that readers will take note of it any more than they would of many other possible means of inserting licenses or references to them in content. Publishers and consumers should both be working on the assumption that normal copyright exists (i.e *all rights reserved*) except where there are fair use privileges of implied licenses that weaken the *all rights* default.) If we were to allow or encourage any one mechanism to associate restrictive licenses with content, we establish a precedent that would allow or encourage others as well. Any other standards group or informal collection of one or more persons could decide to define a new mechanism -- just like the IETF did. At that point, no reader could safely consume content since no matter how many mechanisms they supported there might be some others that they didn't know about. The issue here is about proper notice... How can we obligate folk to respect licenses that they have no means of discovering? We should also ask: At what point does a restrictive license become operative? Imagine that I decided that reading (copying) of my feeds by commercial organizations was to be prohibited. Could I bar such copying by putting a license in the content itself? Of course, if I did, that means that in order to discover that copying was not permitted the reader would have to actually do the thing which is prohibited. Clearly, even if there was some way to put effective restrictive licenses in content, there would have to remain some implied license exceptions to the *all rights provision of copyright. We are all best served by an assumption that copyright leaves all rights reserved to the publisher and that only fair use, limited implied license to syndicate, and explicit license grants (like CC) limit the totality of those rights. With this in mind it might be best to change from a license link to a rights-grant link... In other words, frame this link type as something which can *only* be used to broaden rights, not restrict them. bob wyman
Re: atom license extension (Re: [cc-tab] *important* heads up)
Karl Dubost wrote: IMHO, when the implementors do not understand the licenses, they have no rights to do things with content (because it's highly dependant of local laws) Ignorance of the law is no excuse. Implementors have the rights they have under the applicable set of laws, irrespective of whether or not they understand those rights. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: atom license extension (Re: [cc-tab] *important* heads up)
[EMAIL PROTECTED] wrote: Le 7 sept. 06 à 01:29, John Panzer a écrit : This is a critical point. Without this, implementors cannot safely ignore licenses they don't understand (falling back to things like fair use if they can't find any licenses that grant additional copying rights). This means that implementors would likely have to drop feeds containing new licenses on the floor, meaning that new license schemes would never be deployed. People with legal background will confirm or not, but fair use doesn't exist in the same way in all countries. Offering a mechanism to provide licensing information is good. Encouraging a *legal* fallback mechanism is bad, very bad. IMHO, when the implementors do not understand the licenses, they have no rights to do things with content (because it's highly dependant of local laws) That's why I said 'things like' fair use. Our legal department has been having fun with this topic over the past several months. I do agree with you that encouraging people to provide licenses is good. I think that there are fallback mechanisms whether or not we encourage them. I think that a fallback mechanism -- implied rights to copy for limited purposes -- is a good thing, and whatever gets specified should not work against it. It's an unfortunate fact that the available mechanisms are 'squishy' and vary with local laws, but they are better than nothing, which seems to be what you advocate. More practically, if every feed reader and processor has to be modified to understand a license before the license can be used in published feeds, the ability to deploy and experiment with licenses will be drastically reduced. Which drastically reduces the utility of having licenses. (Let's say that Doc Searls somehow discovers a license that would deny sploggers more than implied rights to his content while allowing liberal use for others[1], and deploys it. Are you saying that all of his readers' feed software would have to drop his feed content until they're upgraded to understand the license?) [1] http://doc.weblogs.com/2006/08/28
RE: atom license extension (Re: [cc-tab] *important* heads up)
John Panzer asks of Karl Dubost: (Let's say that Doc Searls somehow discovers a license that would deny sploggers more than implied rights to his content while allowing liberal use for others[1], and deploys it. Are you saying that all of his readers' feed software would have to drop his feed content until they're upgraded to understand the license?) [1] http://doc.weblogs.com/2006/08/28 I think John's question can be (aggressively) rephrased as: Can Doc Searls, by inserting a license in his feed, 'poison' the entire syndication system that we've built over the last few years? (i.e. Can he do things that make it unsafe or illegal for people to do things which the syndication system was intentionally built to permit and which he knew were being done before he willingly inserted his content into the syndication network?) I don't think so. As argued in other messages, I strongly believe that we should not do anything that hinders or conflicts with the establishment or recognition of a limited implied license to syndicate content which is formatted using RSS/Atom and is made openly available on the network. (An interesting question, of course, would be: What does it mean to 'syndicate'?) In any case, there is a general problem of proper notice here. As mentioned before, there is nothing special about an optional IETF protocol extension. This subject of inserting licenses in content should be discussed in a general sense -- not limited to this specific protocol extension. A vital question to ask is: What is proper notice of the presence of a license? No IETF standard has the force of law. Readers are not obligated to understand or even take note of the license links. Thus, no one using it should be able to have any expectation that readers will take note of it any more than they would of many other possible means of inserting licenses or references to them in content. Publishers and consumers should both be working on the assumption that normal copyright exists (i.e *all rights reserved*) except where there are fair use privileges of implied licenses that weaken the *all rights* default.) If we were to allow or encourage any one mechanism to associate restrictive licenses with content, we establish a precedent that would allow or encourage others as well. Any other standards group or informal collection of one or more persons could decide to define a new mechanism -- just like the IETF did. At that point, no reader could safely consume content since no matter how many mechanisms they supported there might be some others that they didn't know about. The issue here is about proper notice... How can we obligate folk to respect licenses that they have no means of discovering? We should also ask: At what point does a restrictive license become operative? Imagine that I decided that reading (copying) of my feeds by commercial organizations was to be prohibited. Could I bar such copying by putting a license in the content itself? Of course, if I did, that means that in order to discover that copying was not permitted the reader would have to actually do the thing which is prohibited. Clearly, even if there was some way to put effective restrictive licenses in content, there would have to remain some implied license exceptions to the *all rights provision of copyright. We are all best served by an assumption that copyright leaves all rights reserved to the publisher and that only fair use, limited implied license to syndicate, and explicit license grants (like CC) limit the totality of those rights. With this in mind it might be best to change from a license link to a rights-grant link... In other words, frame this link type as something which can *only* be used to broaden rights, not restrict them. bob wyman
Re: atom license extension (Re: [cc-tab] *important* heads up)
Wendy Seltzer wrote: ... The concern about limiting implied licenses is important, though. By definition, an implied license is one that's presumed from the context of an offering and by the absence of a contrary explicit license. If as a factual matter, many people have been acting based on implied licenses of broader scope than either fair use or what would be chosen in an explicitly linked license, then you might say it's better not to provide this encouragement to link licenses at all (and hoping that time and general practice will morph those implied terms into fair uses). If the rfc encourages people to add licenses, it opens up the possibility that their explicit terms will contradict and override what has previously been implied. That's a worrying Heisenburg effect. This is a critical point. Without this, implementors cannot safely ignore licenses they don't understand (falling back to things like fair use if they can't find any licenses that grant additional copying rights). This means that implementors would likely have to drop feeds containing new licenses on the floor, meaning that new license schemes would never be deployed. ... Thus, it would seem that the only effective use of the license link is to grant rights not to restrict them. Yes. Given the current murky and complicated legal situation with implied licenses, fair use, etc., granting explicit and well defined rights is a huge win for everyone. I don't think there's a legal mechanism for telling people you may only use this format if you grant a license equally or more permissive than X. (at least none short of patent claims on the format itself...) No, but I think there may be a technical mechanism for saying this particular extension only lets you grant rights with each new license link, not take them away: ... How about (IANAL of course): Nor can a license restrict or remove any implied copy or usage rights which would otherwise exist in the absence of the license. The intent being that adding a license, or a new type of license, is always safe: If what you're doing with content is allowable, if the feed provider adds a license, it is still allowable. There is a parallel with the principle of substitutability [1] in software engineering, which allows extension while maintaining desirable invariants (in this case, the ability to what one would naturally expect to do with a feed). [1] http://en.wikipedia.org/wiki/Liskov_substitution_principle -John Panzer http://abstractioneer.org
RE: atom license extension (Re: [cc-tab] *important* heads up)
Wendy Seltzer wrote: I'm still not clear on what's happening in 1.1. 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. Section 1.1 contains two sentences that are, I think, at least in part the result of a telephone conversation on this subject that James and I had about a week ago. However, I think that James has written both sentences too strongly and it is quite possible the first sentence is unnecessary. I'll explain the logic behind my reasoning. First, the first sentence and the second, later. The first sentence is concerned with the binding between the feed or entry and the actual license. For one to rely on a license, either as a rights holder or as a grantee, you need to be able to show what the license actually said at the time that you relied upon it. Because of the nature of the tool being used here, a hyperlink, we must accept that the binding between content and license is a weak and fragile one. There is no guarantee that the content of the license associated with a feed at one instance will be the same as it is at some other instance. Also, there is no mechanism provided to ensure that claims made about what the license was at one instance can be proved at a later time. This weakness of the link is going to make it very difficult for either a copyright holder or one who relies on a license found in a license link to rely on being able to make definitive statements about what the license content actually was. Certainly, there are special cases. For instance, those who link to Creative Commons licenses using the appropriate and presumably well managed URLs that Creative Commons provides are going to be able to much more certain when making assertions about license content since these licenses are only modified in very public and dated events. However, Creative Commons is a special case and can't be generalized to all possible licenses. Thus, while we might find that links to Creative Commons licenses (and others which are similarly well managed) might be effective, it is likely that links to at least some other licenses would not be considered effective. Thus, it might be better to word the sentence conditionally. Something like: licenses associated with feeds or entries using these mechanisms may not be legally binding... My personal feeling is that given the customs of the net today, it is likely that the most common licenses referred to in these links will, in fact, be Creative Commons licenses which grant rights otherwise restricted by copyright. The problems come in licenses which attempt to restrict rights. One class of such licenses will be those that claim rights that are already reserved under copyright. Such licenses are really redundant and don't accomplish anything useful. I'll ignore those for now. The most interesting cases will be those licenses that attempt to assert limitations to rights which would normally be considered to be granted to consumers of feeds. Such rights would include things like Fair Use and implied licenses. It is *vitally* important to our community that we ensure that such restrictive licenses are not encouraged or facilitated by this rfc. There are those, I among them, who argue that the mere act of encoding data in a syndication format such as RSS or Atom, posting that content on an openly accessible web site, and doing such things as pinging to publicize the presence of that content, creates a limited implied license for others to access and copy the data for the purposes of syndication. This is very much like the implied license to copy HTML into system buffers, caches, network routers, local disks etc in the process of reading it. With HTML, courts appear to accept that you have a right to do something that would be prohibited by a strict reading of copyright law. Under limited circumstances, you are allowed to make copies that are technically necessary and facilitative to the achievement of the content creator's assumed purpose of having you read the pages. Similarly, when you publish to a syndication network, one accepts that there is an implied license to do not only the same kind of copying that is permitted for HTML, but also that you accept that your content will be processed by various syndication-related intermediaries -- feed aggregators, feed filters, feed format converters, publish/subscribe systems, etc. However, please note that this is still a *limited* implied license. The fact that syndication is permitted doesn't mean that the general creation of derivative works, repurposing of feed content, etc. is permitted. The license doesn't allow stealing -- it only allows moving the stuff around in the process of getting it to readers. The syndication network can only work because we assume that there is an implied right to syndicate. If, for some reason, we were to establish that this
Re: atom license extension (Re: [cc-tab] *important* heads up)
On 2006-09-06 02:25:47 -0400, Bob Wyman wrote: Because of the nature of the tool being used here, a hyperlink, we must accept that the binding between content and license is a weak and fragile one. There is no guarantee that the content of the license associated with a feed at one instance will be the same as it is at some other instance. Also, there is no mechanism provided to ensure that claims made about what the license was at one instance can be proved at a later time. I think this assessment mixes two aspects: The use of the rel=license link as an *identifier* for a specific license (which is pretty much what Creative Commons does), and the use of the link to retrieve license information. The value that this specification adds to Atom is mostly in the link-as-identifier field: It enables software to offer, e.g., retrieval of feeds (or entries) by license. Look at the Creative Commons powered aspects of flickr search for a related example. Trying to dilute the value of the license link out of fear that the link-as-retrieval-mechanism aspect is dangerous, however, impacts the value of the link-as-identifier aspect. As you point out, the weakness of the link between content and a specific license (in the sense of legal code) causes problems for both the copyright holder and the relying party. A corollary of this is that, in fact, both sides have an incentive to use licenses that are identified by a stable URI. Hence, I'd suggest that, in making balancing decisions for this specification, emphasis be put on using URIs as *identifiers* for licenses. It's fine to point out the lack of an enforceable binding on a technical level, but I don't think this spec is the place to discuss the legal implications that this might have. -- Thomas Roessler [EMAIL PROTECTED]
Re: atom license extension (Re: [cc-tab] *important* heads up)
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
Re: atom license extension (Re: [cc-tab] *important* heads up)
* Thomas Roessler [EMAIL PROTECTED] [2006-09-06 11:45]: On 2006-09-05 15:11:22 -0700, James M Snell wrote: 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? That may be a good point in this instance, but an irrelevant one. James’ points out that there may be feeds where the feed publisher has the rights to the feed as a collection, but not to the content of individual entries. Since these cases exist, it would be a bad idea for the licence to inherit from the feed to entries in it. Whether Sam in particular is or is not in that position does not affect the principle. He’s not, btw: he republishes my content, but he has no permission from me to relicense it. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: atom license extension (Re: [cc-tab] *important* heads up)
On 2006-09-06 12:21:24 +0200, A. Pagaltzis wrote: James’ points out that there may be feeds where the feed publisher has the rights to the feed as a collection, but not to the content of individual entries. Since these cases exist, it would be a bad idea for the licence to inherit from the feed to entries in it. The conclusion here is fallacious: These cases are a use case for having license annotations on the feed level. As I said elsewhere, I'm fine with that. However, this does not mean that the capability to set a licensing default on the feed level is a bad thing by itself -- in particular when that is how the other mechanism works. We are simply talking about different use cases, and violently agreeing that it's a bad thing to confuse these. So, here's the proposal: - Use link rel=license/ for entry licenses -- either on the feed level, setting a default analogous to what atom:rights does, or on the element level. - Introduce link rel=collection-license/ (or whatever else you find suitable) for licenses about the collection, to be used only on the feed level. Regards, -- Thomas Roessler [EMAIL PROTECTED]
Re: atom license extension (Re: [cc-tab] *important* heads up)
Bob Wyman wrote: ... The mostinteresting cases will be those licenses that attempt to assert limitationsto rights which would normally be considered to be granted to consumers offeeds. Such rights would include things like "Fair Use" and "impliedlicenses." It is *vitally* important to our community that we ensure thatsuch restrictive licenses are not encouraged or facilitated by this rfc. This is a critical point. Without this, implementors cannot safely ignore licenses they don't understand (falling back to things like "fair use" if they can't find any licenses that grant additional copying rights). This means that implementors would likely have to drop feeds containing new licenses on the floor, meaning that new license schemes would never be deployed. ...Thus, it would seem that the only effective use of the license linkis to grant rights not to restrict them. Yes. Given the current murky and complicated legal situation with implied licenses, fair use, etc., granting explicit and well defined rights is a huge win for everyone. The second sentence in 1.1 is: Nor can a license associated with a feed or entryrestrict or forbid access to, redistribution, aggregation,caching and display of those items by third partyintermediaries such as search engines and so-called"online aggregators". This second part of 1.1 is stating support for the theory that theact of publishing data in the Atom format creates an "implied license" forthe limited purpose of syndication and lists a number of processes which areconsidered to be part of the syndication process. Hopefully, my discussionof the first sentence explains what this is all about.My only suggestion for this sentence is that it might be lessstrongly worded. Given that the law in this area is not settled, it mightmake sense not to say "Nor can a license... restrict..." Rather, it might bemore accurate to say something like: "It is believed that a license ...cannot restrict" How about (IANAL of course): "Nor can a license restrict or remove any implied copy or usage rights which would otherwise exist in the absence of the license." The intent being that adding a license, or a new type of license, is always safe: If what you're doing with content is allowable, if the feed provider adds a license, it is still allowable. -John Panzer
RE: atom license extension (Re: [cc-tab] *important* heads up)
Thomas Roessler wrote: It's fine to point out the lack of an enforceable binding on a technical level, but I don't think this spec is the place to discuss the legal implications that this might have. If the spec does not make statements concerning the intended legal implications of a feature which clearly addresses legal issues, the result will almost inevitably be wide-spread misunderstanding of the implications of using the feature. The mere act of going to the trouble of specifying the license link indicates that the authors expect that there will be some implication of having used the feature. The question that many readers will have is: What are the intended implications? Leaving the answer to guess work is not useful, I think. Given the unsettled and potentially dynamic state of the law in this area, I certainly agree that the spec should not make pronouncements concerning what the law is in this case. But I don't see any valid argument against making statements of intent that may, or may not, be in conflict with the law as it is or may one day be. The authors of the specification have, I think, not only good reason to state their intention but an obligation to do so. Warning implementers that the use of the license link may not, in at least some situations and in some legal systems, create a legally enforceable binding is the right thing to do. bob wyman
Re: atom license extension (Re: [cc-tab] *important* heads up)
On 2006-09-06 12:47:09 -0400, Bob Wyman wrote: The authors of the specification have, I think, not only good reason to state their intention but an obligation to do so. Warning implementers that the use of the license link may not, in at least some situations and in some legal systems, create a legally enforceable binding is the right thing to do. The intent of this spec is to give those who publish a feed a way to assert what licensing conditions apply to certain parts of that feed. That's what the spec should say; anything else -- in particular elaborate discussions of corner cases -- is going to cause confusion. -- Thomas Roessler [EMAIL PROTECTED]
Re: atom license extension (Re: [cc-tab] *important* heads up)
At 12:29 PM 9/6/2006, John Panzer wrote: Bob Wyman wrote: ... The most interesting cases will be those licenses that attempt to assert limitations to rights which would normally be considered to be granted to consumers of feeds. Such rights would include things like Fair Use and implied licenses. It is *vitally* important to our community that we ensure that such restrictive licenses are not encouraged or facilitated by this rfc. Restrictions on fair use couldn't be imposed unilaterally by license, but only by a contract (fictionally accepted by click-wrap, or actually negotiated and accepted). The concern about limiting implied licenses is important, though. By definition, an implied license is one that's presumed from the context of an offering and by the absence of a contrary explicit license. If as a factual matter, many people have been acting based on implied licenses of broader scope than either fair use or what would be chosen in an explicitly linked license, then you might say it's better not to provide this encouragement to link licenses at all (and hoping that time and general practice will morph those implied terms into fair uses). If the rfc encourages people to add licenses, it opens up the possibility that their explicit terms will contradict and override what has previously been implied. This is a critical point. Without this, implementors cannot safely ignore licenses they don't understand (falling back to things like fair use if they can't find any licenses that grant additional copying rights). This means that implementors would likely have to drop feeds containing new licenses on the floor, meaning that new license schemes would never be deployed. ... Thus, it would seem that the only effective use of the license link is to grant rights not to restrict them. Yes. Given the current murky and complicated legal situation with implied licenses, fair use, etc., granting explicit and well defined rights is a huge win for everyone. I don't think there's a legal mechanism for telling people you may only use this format if you grant a license equally or more permissive than X. (at least none short of patent claims on the format itself...) --Wendy The second sentence in 1.1 is: 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. This second part of 1.1 is stating support for the theory that the act of publishing data in the Atom format creates an implied license for the limited purpose of syndication and lists a number of processes which are considered to be part of the syndication process. Hopefully, my discussion of the first sentence explains what this is all about. My only suggestion for this sentence is that it might be less strongly worded. Given that the law in this area is not settled, it might make sense not to say Nor can a license... restrict... Rather, it might be more accurate to say something like: It is believed that a license ... cannot restrict How about (IANAL of course): Nor can a license restrict or remove any implied copy or usage rights which would otherwise exist in the absence of the license. The intent being that adding a license, or a new type of license, is always safe: If what you're doing with content is allowable, if the feed provider adds a license, it is still allowable. -John Panzer -- Wendy Seltzer -- [EMAIL PROTECTED] Visiting Assistant Professor of Law, Brooklyn Law School Fellow, Berkman Center for Internet Society http://cyber.law.harvard.edu/seltzer.html http://www.chillingeffects.org/
RE: atom license extension (Re: [cc-tab] *important* heads up)
Wendy Seltzer wrote: The concern about limiting implied licenses is important... If the rfc encourages people to add licenses, it opens up the possibility that their explicit terms will contradict and override what has previously been implied. This is precisely why I have normally argued against adding rights and licenses mechanism to Atom and other formats. Unfortunately, it is has been a losing battle (Atom has rights/) so, I'm now trying the tack of attempting to get explanatory text and weakness in the language in order to mitigate some of the damage that might be caused. Oddly, I think part of the push for these dangerous licensing mechanisms is the result of success of Creative Commons. We may be seeing that a movement intended to expand rights will indirectly create a situation where rights are more easily restricted. People really like the CC mechanism for granting rights and as a result want cleaner and better understood means for associating Creative Commons licenses with their content. Unfortunately, an unintended consequence of satisfying this desire to publish CC licenses might be that it becomes easier and more common for folk to publish restrictive licenses. Readers of this thread might be interested to see that Denise Howell has been discussing very similar issues on her new Logarithms blog.[1][2] I've put some comments in there and have also responded in length concerning what I, as a non-lawyer, consider some of the implied licenses that attach to RSS/Atom syndicated content.[3] bob wyman [1] http://blogs.zdnet.com/Howell/?p=17 [2] http://blogs.zdnet.com/Howell/?p=18 [3] http://www.wyman.us/main/2006/09/magazine_or_mus.html
Re: atom license extension (Re: [cc-tab] *important* heads up)
On Sep 6, 2006, at 7:51 AM, James M Snell wrote: The problem with specifying a per-feed default license is that there is currently no way of explicitly indicating that an entry does not have a license or that any particular entry should not inherit the default feed-level license. With respect to atom:rights (from RFC 4287 section 4.2.10): If an atom:entry element does not contain an atom:rights element, then the atom:rights element of the containing atom:feed element, if present, is considered to apply to the entry. Thus, at the entry level, atom:rights / would (certainly ought to!) detach a feed level atom:rights element from the entry without replacing it with anything. With link rel=license..., I'm not sure how you'd do the same thing. Is it possible to specify a null URI? link rel=license href= / points to the in-scope xml:base URI, right? Perhaps the specification could define a null license URI. With respect to the issue of aggregate feeds, I had thought that the existence of an atom:source element at the entry level blocked any inheritance of the feed metadata, but looking at RFC 4287, I don't see that explicitly stated. Certainly if atom:source contains atom:rights, then that element overrides the feed-level atom:rights of the aggregate feed, but if neither atom:source nor atom:entry contains an atom:rights element, what then? Perhaps in that case, the aggregator should add atom:rights / as a child of atom:source (I'd think that preferable to adding it as a child of atom:entry). On Sep 6, 2006, at 4:38 AM, Thomas Roessler wrote: So, here's the proposal: - Use link rel=license/ for entry licenses -- either on the feed level, setting a default analogous to what atom:rights does, or on the element level. - Introduce link rel=collection-license/ (or whatever else you find suitable) for licenses about the collection, to be used only on the feed level. If there's a @rel=license at the feed level, but no rel=collection- license, does the @rel=license also become a collection- license? (People who don't read the spec would probably think so). If there is no license for the collection, but one wishes to specify a default license for the entries, a null license would once again be useful. Antone
RE: atom license extension (Re: [cc-tab] *important* heads up)
Antone Roundy wrote: With respect to the issue of aggregate feeds, I had thought that the existence of an atom:source element at the entry level blocked any inheritance of the feed metadata, but looking at RFC 4287, I don't see that explicitly stated. It's not explicit, but it is implicit. The source/ element preserves the entry's feed metadata. Thus, to find the feed metadata associated with an entry which has an atom:source, you should look to the preserved data in the atom:source element (or the source feed itself...) -- you should NOT look to the metadata of the feed within which you found the entry. Atom:source says, essentially: This entry is not of this feed. It is foreign and should be interpreted as such. Thus, the feed metadata of the containing feed should never be allowed to leak into the interpretation of an entry which contains an atom:source. To do so would make syndication, aggregation, etc. a complete mess. bob wyman
Re: atom license extension (Re: [cc-tab] *important* heads up)
Wednesday, September 6, 2006, 11:38:13 AM, you wrote: So, here's the proposal: - Use link rel=license/ for entry licenses -- either on the feed level, setting a default analogous to what atom:rights does, or on the element level. I think that there are data modelling issues with this approach. I don't think that the inheritance of extensions from the 'feed document', to the entries contained within that document is supported by the spec, nor would it be likely to be supported by typical implementations of stateful feed stores, frameworks and APIs. Feeds and entries are seperate entities with seperate life-cycles. Stateful feed platforms, such as the Windows feed platform, typically store a single instance of feed metadata, and a single instance of entry metadata. When, for example, a feed title changes, the change applies to the feed as a whole; it isn't localised to only apply to the entries that were present in that feed document at the time of the change, because each entry doesn't typically store its own private copy of feed metadata. Implementors can cope with the inheritance of atom:rights and atom:author, because it is explicitly described in the spec, and implementors know that they must implement the inheritance at the document parsing stage, and apply the feed-level data to the entry before storing the entry before they attempt to store the entries in a database or whatever, but implementations cannot be expected to apply all feed-level extensions to the entries that they were transmitted with, just in case any of them might expect to implement feed document inheritance. Feed properties are properties of the feed, not the feed document. An extension can't implement atom:rights/atom:author style inheritance from the feed document to the contained entries. -- Dave
Re: atom license extension (Re: [cc-tab] *important* heads up)
Le 7 sept. 06 à 01:29, John Panzer a écrit : This is a critical point. Without this, implementors cannot safely ignore licenses they don't understand (falling back to things like fair use if they can't find any licenses that grant additional copying rights). This means that implementors would likely have to drop feeds containing new licenses on the floor, meaning that new license schemes would never be deployed. People with legal background will confirm or not, but fair use doesn't exist in the same way in all countries. Offering a mechanism to provide licensing information is good. Encouraging a *legal* fallback mechanism is bad, very bad. IMHO, when the implementors do not understand the licenses, they have no rights to do things with content (because it's highly dependant of local laws) -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: atom license extension (Re: [cc-tab] *important* heads up)
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
Re: atom license extension (Re: [cc-tab] *important* heads up)
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
Re: atom license extension (Re: [cc-tab] *important* heads up)
At 04:08 PM 9/5/2006 -0700, James M Snell wrote: Hello Wendy, Thanks for the feedback. I've cc'd the atom-syntax list so the rest of the Atom community can comment. Thanks James, I'm still not clear on what's happening in 1.1. 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. What I meant by that is that they don't actively restrict non-compliant use, as a technological protection measure does: I can receive a feed and choose to breach its license. They can have legal effect, though: Unless I have some legal excuse such as fair use, I'm then not compliant and possibly infringing copyright. (You still have to come after me for copyright infringement.) Are you trying to say that the license-rel in the feed is merely a notification to those who are curious that this is probably (but we're not certain) the license under which the feed may be used ? That's the way it reads. If so, what's the point? Don't you either want to assert take the feed under this license or not at all or say nothing and make people come to you and ask? I'd recommend dropping this paragraph, as it may give incorrect legal advice. 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. That seems minimally useful to me (the license, not Sam's feed!), but why prohibit people from licensing their feeds' content too? Or am I just misreading this, and you're saying that depending on where you put the tag, the license's coverage differs? 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? Yes. Thanks, --Wendy -- Wendy Seltzer -- [EMAIL PROTECTED] Visiting Assistant Professor of Law, Brooklyn Law School Fellow, Berkman Center for Internet Society http://cyber.law.harvard.edu/seltzer.html Chilling Effects: http://www.chillingeffects.org
Re: atom license extension (Re: [cc-tab] *important* heads up)
Comments below. Wendy Seltzer wrote: [snip] Thanks James, I'm still not clear on what's happening in 1.1. [snip] 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. What I meant by that is that they don't actively restrict non-compliant use, as a technological protection measure does: I can receive a feed and choose to breach its license. They can have legal effect, though: Unless I have some legal excuse such as fair use, I'm then not compliant and possibly infringing copyright. (You still have to come after me for copyright infringement.) Are you trying to say that the license-rel in the feed is merely a notification to those who are curious that this is probably (but we're not certain) the license under which the feed may be used ? That's the way it reads. If so, what's the point? Don't you either want to assert take the feed under this license or not at all or say nothing and make people come to you and ask? What I'm saying is that feed consumers have no guarantee as to who added the license link to the feed/entry and whether whoever did had the legal right to do so. Nor is there any guarantee that license links within a feed or entry have not been inappropriately modified. Feed publishers can digitally sign Atom feeds and entries to provide some non-repudiation protection, but doing so is optional and is not a guaranteed solution. I'd recommend dropping this paragraph, as it may give incorrect legal advice. Ok. 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. That seems minimally useful to me (the license, not Sam's feed!), but why prohibit people from licensing their feeds' content too? Or am I just misreading this, and you're saying that depending on where you put the tag, the license's coverage differs? It's the latter. The license's coverage differs depending on where it appears. [snip] - James
