こちらの過失により、事実誤認を元にした分析になってしまったためこの記事は破棄します。フォロー記事が有ります。
RSSなりATOMなりを発行しているということは、「このデータは適当に使ってくれ」という意思表示だと、なんとなく思っていたのだが、そうでは無い人もいるかもしれない、という話。void GraphicWizardsLair( void ); //経由。
個人的に、RSSの存在意義は――というかRSS自体がメタデータの集約なわけで――「そのリソースの2次利用を簡単に」という点に有るものだと思っていた。一応、元データそれ自体の無断コピーを主張するものでは無いとしても、少なくとも{http://purl.org/rss/1.0/}description内のデータに関しては、第3者による2次利用を認めているものだと、なんとなく信じていた。
ところで、普通の人は{http://purl.org/rss/1.0/}description内のデータは本文の要約だと信じているはずだ。RSSの仕様書を読んでもdescription要素はA brief description of the channel's content, function, source, etc.
と定義されている。あくまでも、briefである。しかし、驚いたことに件のRSSは全文がdescription内に記述されている。
RSSで情報集めたとも書いてないから、まるで、オレ自身がこのサイトに記事を寄稿しているようにも見える。全文引用で敬称略だし。
という発言は、なんというか間が抜けている。確かに、アンテナであることは明言した方がいいだろうが、引用もくそもないと思うのだ（敬称についてはここでは触れない）。RSSを集めている側としては、要約（と信じているデータ）に権利を主張される事自体予想だにしなかったのではないだろうか。はてなアンテナのように、先頭数10文字程度なら引用で済ませられると思うのだけどね。
とクレームを付けた方はおっしゃっているが、先頭数10字程度こそがdescription要素に入っている内容であるべきであり、RSSの利用者はそれを前提としてデータを利用している。
もし、要約にすら権利を主張するのなら、それはもう「法律の認める範囲でご自由に」としか言いようがないが、個人的には、RSSのdescription要素の内容にまで著作権を主張するのは頭が悪いと思う。冒頭でも述べたが、RSSは「2次利用を促進するため」に存在すると言っても良いからだ。たかだか要約の権利に目くじらを立てるよりは適当に使って貰った方がみんなも便利だし、発信者側も楽で良いはずだ。わざわざ法律を持ち出して「著作権侵害だ」と叫ぶ所ではないだろう。
今回は、なんとなく勘違いが事の発端ではなかと思われるが、これから先RSSの扱いでトラブルが起こるケースが増えるのかも知れない。元々RSSというと、Wiki（なんとなくオープンな気がする）やMT（なんとなくCCライセンスと仲が良い）というイメージが強いせいか、どうも著作権フリーのイメージが強い。RSSのデータは自由に使って良い、と漠然と信じている人は結構多いのではないだろうか。素でRSS内のデータに対する権利を主張されてしまうと、なんというか、困るなぁ……。
脱線するが、個人的に凶悪だと思うのはblogWatcherだ。RSSを発行していなくても、もの凄い勢いでリソースを吸収されてしまう。とはいえ、私的には便利なサービスだと思うのだが。
仕様書を読み間違えて書いてしまったため、この記事の破棄します。この記事の内容は完全に間違えているので参考にしないでください。フォロー記事があります。
RSSのdescription要素内のデータは拡大傾向というか、もはやbriefである必要は無いのかも知れない。
Planet PHPを見ると、{http://purl.org/rss/1.0/modules/content/}encodedをつかって文全体を格納しているRSSが結構あるようだ。これが発信者の意志なのか、blogツールの標準設定による物なのかはしらないが（おそらく後者が多いのだろうが）、現状は本文全部格納の方向に流れているようだ。
個人的な意見を述べれば、本文が全部格納されていれば、それはそれで便利で良いと思う（なんせわざわざGETしなくて済む）。が、しかし、こうなってくると著作権の問題が面倒だ。自主的にRSSを発行して情報の拡散を促進しているような人は問題にならないが、RSSの存在意義自体を認識せずに、ツールの標準設定のまま吐き出している人の中には、「なんで私の著作物を勝手に使ってるんだ！」と叫ぶ人が増えるのではないだろうか。主張自体の是非はともかく、今後、RSSフィードに対する認識の差でトラブルが増えるかも知れない。
私個人の意見としては「著作権うんぬん言うぐらいならRSSなんて発行するなよ」と言いたいところだ。著作権の確認なんて面倒だし、そもそもRSSの存在意義は情報の利便性を高めることにあると思う。せっかく機械的処理だけで済むように規格が出来たのに、人間間での確認がボトルネックになってしまったらもったいない。そもそも、使われて困るようなデータならば、わざわざHTML以外の規格で発行しなければいい。
「ローカルでの私的利用は認める」という（私からすると）微妙なスタンスの人もいるだろうが、ローカルでもパブリックでも使用者としては大して変わらないはずなので、どうせならパブリックでの利用も認めて欲しいと思う。例えば、はてなアンテナとWWWCでどれだけコンテンツに対する利用者の認識に差があるかと言われたら、ほぼゼロだろう。もちろん、RSS内のデータを「私が書きました」と成りすまして利用するのはマズイだろうが、明示されていればそこまで神経質になる必要はないと思う。ここら辺は個人の価値観や認識の差が有るので、一概には言えないところだが……。
ところで、HTMLで完結していたWEBでのプレゼンテーションがRSSという構造にいくらかその役割を委譲した、とも考えることが出来るのも事実だ。極論をいえば、HTMLを廃止してRSSだけでblogを運用することも可能だろう。この場合、コピーされたくない（今まではHTMLがオリジナルだった）元データはRSSそのものになり、それを理由としてRSS内データの2次利用を拒否することは確かに妥当だと思われる。こうなってくるともう、RSSの身軽さは消えることになる。description要素内のデータは第3者のコントロールに置かれることになり、引用する場合は人間が必要な範囲を判断する必要が出てくるからだ。なにせ、description要素をコピーしてしまうと「全文引用」になってしまい、クレームが付く可能性が出てくる。
これから先、RSSを気軽に使えない時代が来る可能性が高い。HTMLの時代と同様、人間がデータ内で利用可能な範囲を判断する必要性が生じ、手続きを行う必要が出てくる。RSS内の利点であったXMLをベースとした機械のみで完結した処理が不可能になってしまうのだ。
ああ、メンドくさい世界がまた来るのか。
まず最初に、事実に反する記事を書いてしまったことについて、お詫びいたします。
階層構造をrss:description/content:encodedだと勘違いしていました。仕様書に有る通り、content:encodedはrss:itemの直下にあるべき要素でA module for the actual content of websites, in multiple formats.
（強調は石川による）となります。つまり、contentモジュールはある意味ではHTMLの代替としての構造であり、RSSは実データを提供するためのパッケージのような役割を果たします。
今回の件で言うと、content:encoded内のデータを無断でコピーすることは著作権的にマズイが結論です。RSSのcontent:encoded内に格納されているデータを第3者が使用する場合は必要に応じて許可を取るべきです。つまり、従来のHTMLや一般著作物と同様の手順を踏む必要があります（少なくとも権利者が要請する限りは）。
RSSというと「このデータは適当に使ってくれ」という認識が私自身も強かったのですが、少なくともcontentモジュールに関しては認識を改める必要が有るようです。これは単なるメタデータの送信ではなくて、実データそのものです。扱いには十分に注意する必要があります。破棄した文章で述べた通り、メタデータにまで著作権を主張するのはRSSの趣旨からすれば馬鹿らしい話ですが、実データのパッケージという側面から見た場合、それぞれ必要なライセンスが設定されるべきだと考えられます（個人的にはパブリックドメインが好きですが）。
一般論としては公開コンテンツに第3者のRSSを利用する場合は、従来通りdescription要素を使い、contentモジュール内のデータには手を出さないのが安全といえます。contentモジュール内のデータを使用する際は、ライセンスを確認し、必要なら許可を得る必要があるかもしれません。
全く逆の結論になってしまい申し訳ありませんでした。