Matthew, There might be a risk, yes. But I think there is a clear distinction between "pushing content" and "re-publising". When we "push" that content, it has no URL (meaning, it can't be accesses anywhere : if you're not subscribed to the feed, you'll miss it forever), however, when you re-publish, technically, you duplicate that content.
In my idea, pushing the content presents a very low risk, however, republishing presents one. Also, in a way, search engine would "fit" in the risk you're describing, because they actually fetch the content, exactly like we do. I am not sure this is a valid 'legal' defense to say : "if you sue us, sue Google too", but at least it proves that they "let" someone do what they don't want us to do. Thanks for the feedback. Julien -- Julien Genestoux, http://twitter.com/julien51 http://superfeedr.com +1 (415) 254 7340 +33 (0)9 70 44 76 29 On Wed, Oct 7, 2009 at 8:10 AM, Matthew Terenzio <[email protected]>wrote: > > > On Wed, Oct 7, 2009 at 11:01 AM, Pádraic Brady <[email protected]>wrote: > >> Isn't a permission to redistribute implicit by enabling rssCloud (or >> Pubsubhubbub)? Granted it's not rssCloud's nature to use fat pings, but >> nevertheless the intent remains getting the content to any subscriber >> supported by the protocol. The only difference is how the feed content >> reaches the Subscriber. >> > > I don't know. Just playing devil's advocate. > > If I were to make up a case, it could be that a publisher wanted metrics > that it thought were being diluted by the redistribution of fat pings. > > It's a good thing that the spec has thought about relaying subscriber count > information and in fact I think those types of metrics are pretty old > fashioned in this world of retweets and torrents and ajax etc. > > I just don't want anyone getting in trouble because they redistributed > Metallica's blog entry and the band thought it cost them money. ; ) >
