Wikipedia:井戸端/subj/特定版削除後の履歴が存在しない版から、削除理由箇所以外の記載を(正当な手順で)復帰することについて、GFDL上の問題点

特定版削除後の履歴が存在しない版から、削除理由箇所以外の記載を(正当な手順で)復帰することについて、GFDL上の問題点[編集]

【問題の概要】

  • 前提として、Wikipediaの内部文書のコピーは履歴を保存する限り認められます。<Wikipedia:著作権#ウィキペディア内別文書からの複製・改変
  • その履歴が何らかの理由で「消えた」場合、その後の内部文書のコピー(転記)の可否について、Wikipediaは規定していません。「消えた」と書きましたが、正確ではありません。Wikipediaでは、たとえ特定版削除されたとしても、ログは残っています。<Wikipedia:管理者#ページの削除と復帰 つまり単に一般ユーザーに「見えない」だけで、「存在しない」わけではありません。
  • ここで問題です。「見えない」版の正確な日時を要約欄に記載して一部の記載を転記した場合、これは認められないのでしょうか。Wikipedia:著作権は「ペースト時に存在する元記事等の最新版よりも古い版からのコピーの場合は、コピー元の版も指定してください。」として、過去の記事からのコピー(転記)を認めています。ここには、こうは書いてありません。「コピー元の版が「見えない」場合は、履歴の正確な日時を要約欄に記載してもコピーを認めません」とは、ね。Wikipediaは、このようなケースを想定されていないわけです。
  • 現状ではWikipediaにルールが存在しないにも関わらず、管理者はとりあえず削除しておけと扱っています。管理者がルールが存在しないことを認めず、何となく決めてしまっています。これは不当です。不当性は、Wikipedia以外でのGFDLの運用を考えれば理解できると思います。GNUはOSに関するプロジェクトです(GFDLは、GNUが作りました。)。OSやそれに関わるソフト作成時に、GFDLに準拠した他人の著作物であるソフトを利用したとしましょう。作成者もGFDLに基づいて、(他人の)履歴を記載します。しかし、(他人の)履歴であるソフトが何らかの理由で「見えない」状況に陥りました。作成者はきちんと自身のソフトに関して(他人の)履歴を記載して公開しています。作成者は、履歴が「見えない」ことを理由に、自身のソフトを公開停止しなければならないのでしょうか。そんな馬鹿な。

【具体的な問題事例】

  • 過去の記載の一部が著作権侵害のため特定版削除された場合に、過去の記載以後に追加された部分のコピーが「見えない」ためにコピーできなくなってしまう。
    • 例を挙げます。
  1. 2009/10/1に、新聞社や本の著作権を侵害する書き込みが行われる
  2. 2009/11/2に、上記とは無関係の節に「問題のない記載」が書き込まれる
  3. 2009/11/3に、著作権侵害が明らかになり削除依頼が為される
  4. 2009/11/4に、削除依頼が認められ、10/1~11/2の記載が全て抹消される(履歴が見れなくなる)
  5. 2009/11/5に、11/2を要約欄に記載し、著作権の侵害のない部分を転記する
  6. 2009/11/6に、履歴が見れないことを理由に、11/5の転記の削除依頼が為される
  7. 2009/11/7に、管理者が不当な理由でルールなく削除を行い削除されてしまう

【管理者の失態】

  • Wikipediaの運営がプロジェクトを円滑に進めるために適切に管理されていればこの問題は起こりにくいはずです。上記具体例では、11/3・11/4の削除の際に管理者が「中抜き削除」を選択し、適切に著作権侵害部分のみを除去すればよいのです。つまり10/1に行われた著作権侵害部分を編集によって除去し、除去後のものを11/4に削除すれば、少なくとも最新版である11/2の版の状況は残り著作権侵害部分も無くなります。しかし、「中抜き削除」を選ばない管理者は多く、安易に全履歴削除によって問題を起こしてしまうケースが存在しています。
    • ただ、仮に「中抜き削除」を選んだとしても、最新版より以前の版の(著作権侵害のない記載)をコピーする場合に不都合があるので、これで全て解決ではありません。


【利用者側の苦肉の策】 著作権法は、アイデアもしくは情報自身ではなく、アイデアの独創的な表現に当てられることを覚えておいてください。それゆえ、百科事典の記事や他の著作を読んで、それをあなた自身の言葉で再構成し、ウィキペディアに提出することは完全に合法です。 (どの程度の再構成が一般的状況の下で必要かという議論に関しては剽窃および公正使用を見てください。)

  • Wikipedia:著作権よりの引用です。コピー(転記)が認められないと、結局Wikipedia内部文書なのにも関わらずこれを再構成をするという何ともオマヌケな話になってしまいます。
  • GFDLの趣旨と目的とは何でしょうか。
    • GFDLに基づいて公開された文書。
    • その履歴閲覧ができない状況では、文書のコピーは認められないのですか?
    • 文書のコピーが認められないのだから、再構成しなければならないのですか?
    • それが履歴を削除された作成者の合理的意思といえるのでしょうか?

私にはそうは思えません。適切に運営し、プロジェクトをより円滑に進めるために、何らかのルールが必要だと思います。--Imakuni 2009年11月3日 (火) 18:09 (UTC)[返信]

コメントまずはここだけ。《「見えない」版の正確な日時を要約欄に記載して一部の記載を転記した場合、これは認められないのでしょうか》については、「管理者以外からは見えない版」からの転記であるが故に、虚偽の転記がなされた場合にどうなるのかを考える必要があるでしょう。管理者以外はそれが虚偽であることは確認できませんから、発覚する可能性はかなり低いのではないかと思います。それを避けるためには、1人以上の (管理者の) 目で確認するフェーズが必要になってくるかと思います。
削除に巻き込まれた版の記述をどうするのかについては、Wikipedia:著作権/履歴の保存あたりが対象としていることのはずなので、まずはそちらを読んでいただいた上で議論に参加していただければよいのではないかと思います。--iwaim 2009年11月3日 (火) 19:05 (UTC)[返信]
見えない版の「履歴ページ」が保存されているなら、削除する必要はないですよ。削除された版の履歴ページが要約欄できちんと保存されていれば、削除する必要はありません。ただし、それは「見えなくなったコピペ元の版の日時」ではなく、「見えなくなったコピペ元の履歴ページ」が保存されていなければなりません。履歴が見えている状態なら、指定されたコピペ元のページの履歴を合わせ読むことができます。履歴が見えなくなる場合は、それができなくなります。
管理者は「中抜き削除」を自由に選択することは、基本的に認められていません。対処する管理者が個人として裁量で判断することがないとはいいませんし、ぼくが長期案件の一部を対処するときには、そういう独自に判断することもあります。しかし、一定の責任は生じるでしょうし、多くの場合境界的な事例についての判例や学説の知識を求められ、その上でも判断は難しく、また履歴を精査するには労力がかかります。削除される前には、誰でも調査し、判断をすることができるのですから、それを覆すことを管理者に求めるのであれば、管理者というものの役回りそのものを変える必要があるでしょう。
GFDLの目的は、「機能本位で実用的な文書を(無料ではなく)自由という意味で「フリー」 とすること、<略>すなわち、改変の有無あるいは目的の営利非営利を問わず、文書 を複製し再頒布する自由をすべての人々に効果的に保証すること」です。また、「著者や出版者が自分たちの著作物に対して相応の敬意と賞賛を得る手段も保護」され、「他人が行った改変に対して責任を負わずに済む」ことが加えられています(八田真行による非公式日本語訳[1])。財産権は実質放棄するが、人格権、特に氏名表示権は、「すべての人々に効果的に保証すること」も目的となりますから、強く保護される必要があります。--Ks aka 98 2009年11月3日 (火) 19:22 (UTC)[返信]
コメントGFDLの要求するところは、すべての改変について著作権者の帰属を明確にしろということで、GFDLの求めるところの明確にする方法についてはウィキメディア財団が決定することです。現状では編集するテキストに著作権の帰属は含めずに、履歴のタイムスタンプを著作権の帰属とするというのは財団が決定です。したがって、履歴にない版からはGFDL文書に該当しないので、そのような引用は禁則行為です。
しかしそれが問題点があるという以前に、本来ウィキペディアの記事は外部の第三者が検証可能な情報源に基づいて記述されるべきものです。つまりウィキペディアの記事は常に二次情報なので、一次情報から引用すれば(つまり本文中に一次情報の出典をつければよいので)何ら問題は発生しないはずです。それを削除された版を情報源に拘泥しなくてはならない状況というのはそもそも引用したい部分というのが検証可能性をみたしていないことを示唆します。検証可能性が曖昧であるならはそれは(削除の)原状復帰をも飲めるのではなく、出典を明確にした新しい版を加筆すれば済む話だと存じます。--あら金 2009年11月3日 (火) 19:40 (UTC)[返信]