DMCA 削除ポリシー

この記事の内容

一般に「DMCA」と呼ばれる、デジタル ミレニアム著作権法に対する GitHub のガイドへようこそ。 このページは法律の包括的な概要となるものではありません。 ただし、お客様が GitHub に投稿したコンテンツを対象にした DMCA の削除通知を受け取っている場合、またはお客様がかかる通知を発行しようとしている権利者である場合、このページが法律およびその遵守に関する当社のポリシーを理解していただく一助になればと願っています。

(通知を送信したいだけの場合は、「G. 通知の送信」にお進みください。)

すべての法的問題と同様に、お客様固有の疑問または状況については常に専門家と相談することが最善策です。 当社は、お客様の権利に影響を与える可能性がある行動を起こす前に、専門家と相談すること強くお勧めします。 このガイドは法的助言ではなく、そのように解釈されるべきものでもありません。

DMCA とは何ですか?

DMCA および DMCA が定める施策方針を理解するために、この方針が成立する前の時代を考えてみるとよいでしょう。

DMCA には、ユーザー生成コンテンツをホストするサービス プロバイダー用の免責事項があります。 著作権侵害の 1 つの申し立てでも最大 $150,000 の法的損害賠償になることから、ユーザー生成コンテンツの責任を問われる可能性はサービス プロバイダーに大きな害をもたらしかねません。 数百万ものユーザー間で損害が倍増する可能性を考えると、YouTube、Facebook、GitHub などのクラウドコンピューティングおよびユーザー生成コンテンツ サイトは、おそらく DMCA なくして (または少なくとも下流コストの一部をユーザーに転嫁することなくして) 存在することはなかったでしょう。

DMCA は、権利侵害を主張されているユーザー生成コンテンツをホストするインターネット サービス プロバイダー向けに著作権に関する法的責任の免責事項を作成することにより、この問題に対処しています。 原則的に、サービス プロバイダーが DMCA の通知して削除する規則に従う限り、ユーザー生成コンテンツに基づく著作権の権利侵害に責任を問われることはありません。 このため、GitHub が DMCA の免責事項ステータスを維持することは重要です。

DMCA では、著作権で保護された作品へのアクセスを効果的に制御する技術的対策による回避 も禁止しています。

DMCA 通知の要約

DMCA には、GitHub ユーザーに認識していただく必要がある 2 つの簡単で分かりやすい手続きがあります。(i) 著作権者がコンテンツの削除を要求する削除通知手続き、(ii)コンテンツが間違いまたは誤認によって削除されたときにユーザーがコンテンツを再度有効にするための反論通知手続きです。

DMCA 削除通知 takedown noticesは、著作権者が権利侵害されていると考えるコンテンツを GitHub に削除を要求するときに使用します。 ソフトウェアの設計者または開発者であれば、著作権のあるコンテンツを毎日作成しています。 第三者がお客様の著作権のあるコンテンツを不正な方法で GitHub で使用している場合、当社に DMCA 削除通知を送信して著作権を侵害しているコンテンツの変更または削除を要求することができます。

一方、反論通知を使用して間違いを訂正することができます。 削除通知の送信者は、著作権を保有していなかったり、お客様がライセンスを保有していることを認識していなかったり、削除通知で他の間違いをしているかもしれません。 GitHub は、通常、間違いがあったかどうかを認識できないため、DMCA の反論通知を使用すると、お客様は当社に通知してコンテンツを元に戻すよう要求することができます。

DMCA 通知および削除プロセスは、著作権の侵害に関する苦情についてのみ使用してください。 当社の DMCA プロセスから送信される通知では、権利侵害が主張されている 1 つまたは複数の著作物を特定する必要があります。 このプロセスは、権利侵害が主張されている商標権侵害や機密データなどに関する苦情には使用できません。このような場合には別のプロセスが用意されています。

A. どのように機能するのですか?

DMCA のフレームワークはクラスでメモを回すことに似ています。 著作権者はユーザーに関する苦情を GitHub に手渡します。 正しく書かかれていれば、当社はユーザーに苦情を伝えます。 ユーザーが苦情に反論した場合は、その反論を著作権者に渡すことができます。 GitHub は、メモが DMCA の最小要件を満たしているかどうかを判断する以外に、このプロセスで自由裁量権を行使することはほとんどありません。 メモが偽証罪により罰せられるという条件で作成されたことを念頭に、申し立てのメリットを評価するのは両当事者 (およびそれぞれの弁護士) 次第です。

プロセスの基本的な手順は以下のとおりです。

  1. 著作権者が調査します。 著作権者は、必ず初期調査を実施して、(a) オリジナル作品の著作権を所有していること、および (b) GitHub 上のコンテンツが許可を与えられておらず権利侵害であることを確認する必要があります。 これには、使用が公正使用として保護されていないことを確認することが含まれています。 著作権で保護されたコンテンツのほんの一部のみを使用している場合、コンテンツを変形して使用している場合、教育目的に使用している場合、または前述を組み合わせて使用している場合など、特定の使用は公正と見なされます。 コードは本来このような使用に役立つものであるため、さまざまな使用事例があり個別に検討する必要があります。

    例: Acme Web Company の社員が GitHub リポジトリで会社のコードの一部を見つけました。 Acme Web Company は数社の信頼できるパートナーにソース コードのライセンスを付与しています。 削除通知を送信する前に、Acme は、当該ライセンスおよび契約を見直して、GitHub 上のコードがそのいずれの下でも許可されていないことを確認する必要があります。

  2. 著作権者が通知を送信します。 調査を実施したら、著作権者は削除通知を作成して GitHub に送信します。 削除通知が法廷要件 (ハウツー ガイドに説明される) に従って十分に説明されていると想定して、当社はパブリック リポジトリに通知を掲載して、影響を受けるユーザーにリンクを伝えます。

  3. GitHub はユーザーに変更を行うよう要請します。 通知で、リポジトリのコンテンツ全体が権利を侵害している、またはパッケージが権利を侵害していると主張されている場合、当社はステップ 6 に進んで、リポジトリ全体またはパッケージを迅速に無効にします。 それ以外の場合、GitHub は、リポジトリ内の特定のファイルへのアクセスを無効にできないため、リポジトリを作成したユーザーに連絡して、通知に指定されたコンテンツを削除または変更するためにほぼ 1 営業日の猶予を与えます。 当社は、ユーザーに変更する機会を与える場合は著作権者に通知します。 パッケージは変更不可能なため、パッケージの一部のみが権利を侵害している場合、GitHub はパッケージ全体を無効にする必要がありますが、権利侵害部分が削除された時点で復活を許可します。

  4. ユーザーは GitHub に変更を通知します。 ユーザーは、指定された変更を行うことを選択した場合は、ほぼ 1 営業日の期間内に当社に通知 しなければなりません。 ユーザーが行わない場合、当社はリポジトリを無効にします (ステップ 6 に説明する)。 ユーザーが変更を行ったことを当社に通知した場合、当社は、変更が行われたことを確認して、著作権者に通知します。

  5. 著作権者は通知を訂正または編集します。 ユーザーが変更を行った場合、著作権者は変更を確認し、変更が不十分なときには削除通知を更新または訂正する必要があります。 GitHub は、著作権者が当社に連絡して、元の削除通知を更新するか、訂正した削除通知を送信する場合を除き、さらなる措置を講じることはありません。 著作権者が変更に満足した場合、正式な撤回を送信する、または何もしないでいることができます。 GitHub は、2 週間以上の沈黙は削除通知の黙示的な撤回と解釈します。

  6. GitHub はコンテンツへのアクセスを無効にする場合があります。 GitHub は、以下の場合、ユーザーのコンテンツを無効にします。(i) 著作権者がユーザーのリポジトリ全体またはパッケージについて権利の侵害を主張している場合 (ステップ 3 に示す)、(ii) ユーザーが変更する機会を与えられた後でも変更を行っていない場合 (ステップ 4 に示す)、または (iii) 著作権者が、ユーザーが変更する機会を得た後に削除通知を更新した場合。 著作権者が、代わりに通知を_訂正する_ことを選択した場合、当社はステップ 2 に戻り、訂正された通知が新しい通知であるかのようにプロセスを繰り返します。

  7. ユーザーは反論通知を送信できます。 コンテンツを無効にされたユーザーは、弁護士に選択肢について相談することをお勧めします。 ユーザーは、間違いまたは誤認の結果としてコンテンツが無効にされたと考える場合、当社に反論通知を送信することができます。 元の通知と同様、当社は、反論通知が十分に説明されていることを確認します (ハウツー ガイドに説明する)。 十分に説明されている場合、当社はパブリック リポジトリに掲載し、リンクを送信して著作権者に通知を返します。

  8. 著作権者は提訴できます。 著作権者は、反論通知を受け取った後もコンテンツを無効にしておきたいと望む場合、GitHub 上のコンテンツに関するユーザーの権利侵害活動を抑制するために、裁判所命令を求める訴訟を起こす必要があります。 言い換えると、お客様は告訴される可能性があります。 著作権者が、管轄裁判所に送信された有効な訴状のコピーを送信して、10 ～ 14 日以内に GitHub に通知を行わない場合、GitHub は無効にしたコンテンツを再度有効にします。

B. フォークについて教えてください (またはフォークとは何ですか?)

GitHub の最も優れた特徴の 1 つはユーザーが別のユーザーのリポジトリに「フォーク」できる機能です。 それは何を意味していますか? 基本的に、ユーザーが GitHub 上のプロジェクトのコピーを自らのリポジトリに作成できるということです。 ライセンスまたは法律により許可されているため、ユーザーはこのフォークに変更を加えて、メイン プロジェクトにプッシュすることも、プロジェクトの独自のバリエーションとして保管することもできます。 このようなコピーはそれぞれが元のリポジトリ (フォークの "親" と呼ばれる場合もあります) の "GitHub 用語集" です。

GitHub では、親リポジトリを無効にするときに、フォークを自動的に_無効にすることはありません_。 これは、フォークは異なるユーザーに所属しており、多くの方法で変更され、公正使用の原則により保護されたさまざまな方法でライセンス付与または使用されているからです。 GitHub は、フォークの独自調査を実施しません。 フォークも権利を侵害していると考えられる場合は、著作権者がこの調査を行い、削除通知にフォークを明示して記載してください。

例外的に、お客様は、積極的にフォークされているリポジトリ全域で著作権侵害を主張することができます。 お客様が通知を送信し、権利侵害を主張された当該リポジトリの既存のフォークをすべて特定した時点で、当社は、通知を処理するときにネットワーク内のすべてのフォークに対する有効な申し立てを処理します。 この処理は、新しく作成されたすべてのフォークに同じコンテンツが含まれているという可能性を前提にして行われます。 また、権利侵害を主張されたコンテンツを含んでいると報告されたネットワークが 100 リポジトリを超えており、全体を確認することが困難な場合、当社は、お客様の通知で「確認した然るべき数のフォークに基づき、フォークのすべてまたは大部分が親リポジトリと同じ範囲まで権利を侵害していると考えます」と記載されていた場合、ネットワーク全体を無効にすることを検討します。 お客様の宣誓陳述書が、この陳述に対して適用されます。

C: 回避申し立てとは何ですか?

DMCA では、著作権法で保護されている作品絵のアクセスを効果的に制御する技術的措置の回避 circumvention of technical measures は禁止されています。 このような申し立ては本来しばしば高度に技術的なことを考慮して、GitHub ではこれらの申し立てに関する詳細情報を申立人に送信するよう求めて、広範な見直しを行います。

回避申し立てには、実施されている技術的措置に関する以下の詳細および告発されたプロジェクトが回避している方法を記載する必要があります。 特に、GitHub への通知には、以下に関する詳細な説明を含める必要があります。

  1. 技術的措置の内容:
  2. 著作権で保護された版権物へのアクセスを効果的に制御する方法、および
  3. 告発プロジェクトを、以前に説明した技術的な保護対策を回避するように工夫する方法。

GitHub では、技術専門家と法務専門家両者を含めて、回避申し立てを注意深く検討します。 技術的な見直しでは、技術的な保護対策がどのように機能するか、およびプロジェクトがどのような方法で回避しているとされているかについて詳しく検証します。 法的見直しでは、申し立てが DMCA の限度を逸脱していないことを確認します。 申し立てが有効かどうか判断できない場合は、開発者の意向を尊重し、コンテンツに手を付けません。 申立人がさらに詳しい情報を希望する場合は、見直しプロセスを再び開始して訂正された申し立てを評価します。

当社の専門家が申し立てを完全かつ合法的で、技術的に妥当であると判断した場合、当社は、リポジトリ所有者に連絡して、申し立てに対処するかリポジトリを変更して削除を回避する機会を与えます。 対処が行われない場合、当社は、さらなる措置を講じる前に、再度リポジトリ所有者に連絡を試みます。 言い換えると、回避技術の申し立てに基づいてリポジトリを無効にする場合は、必ずリポジトリ所有者に連絡して、対処するか最初に変更する機会を与えるということです。 リポジトリ所有者にまず連絡することで問題を解決できない場合、リポジトリ所有者が申し立てに異議を唱える場合、追加事実を当社に提示する場合、変更してコンテンツを復旧する機会を望む場合は、コンテンツを無効にした後でも、当社はいつでもリポジトリ所有者の対応を検討する用意があります。 コンテンツを無効にする必要がある場合、当社は、リポジトリ所有者がイシューおよびプル リクエストや、主張された回避コードが含まれていない他のリポジトリ データを法的に認められる範囲までエクスポートできるようにします。

回避技術に対する当社の見直しプロセスは、無許可の製品ライセンス キー、無許可の製品ライセンス キーを生成するためのソフトウェア、または製品ライセンス キーの確認を免れるためのソフトウェアの共有に対する他に、当社の利用規約の制限を侵害するコンテンツには適用されません。 このような申し立ては、回避技術に関する DMCA 条項を侵害する可能性もありますが、一般に分かりやすくその他の技術的および法的見直しの正当な理由にはなりません。 それにもかかわらず、ジェイルブレイクの場合のように、申し立てが分かりにくいときには、回避技術の申し立ての見直しプロセスが適用されます。

GitHub が回避技術の申し立て見直しプロセスの下で DMCA の削除を処理する場合、当社は、リポジトリ所有者に GitHub の開発者擁護基金を使用して独立した法律相談を無料で受けられるよう紹介します。

D. 変更を行う期間をうっかり逃してしまった場合はどうなりますか?

当社は、お客様のリポジトリが無効になるまでのほぼ 1 営業日の猶予期間内に、変更を行うことができない正当な理由が多数あることを理解しています。 当社のメッセージが迷惑メールとしてフラグを立てられたり、お客様が休暇中だったり、電子メール アカウントを定期的にチェックしていなかったり、忙しかっただけのこともあるでしょう。 承知の上です。 お客様が応答して、変更を行うために接続するはずだったことを当社に知らせたが、どういうわけか最初の機会を逃してしまった場合、当社はほぼ 1 営業日を 1 回追加した期間リポジトリを再度有効にして、お客様が変更を行えるようにします。 繰り返しますが、上記のステップ A.4 に従い、お客様は、ほぼ 1 営業日の期間後もリポジトリを有効にしておくために、変更を行ったことを当社に通知する必要があります。 この追加の機会は 1 回限りということに注意してください。

E. 透明性

当社は、透明性は美徳であると考えています。 GitHub から削除されたコンテンツの内容および削除理由を理解していただく必要があります。 情報が提供されていれば、不透明なシステムで見過ごされていた潜在的な問題が見つかり、明らかになります。 当社は、受信した法的通知 (元の通知、反論通知、または撤回) の編集済みコピーを https://github.com/github/dmca に掲載します。 当社はお客様の個人的な連絡先情報を公開しません。通知を公開する前に、個人情報を削除します (URL のユーザー名を除きます)。 ただし、お客様から特に要請がない限り、通知の他の情報を編集しません。 公開された通知 と反論通知の例を以下に示します。 コンテンツを削除する場合、関連する通知のリンクを元の場所に掲載します。

未編集の通知は公開しませんが、当社が受信した通知の完全な未編集コピーを、通知によって権利に影響を受ける当事者に直接送信する場合があります。

F. 繰り返される権利侵害

適切な状況で独自の裁量により、GitHub または他者の著作権や知的財産権を侵害するユーザーのアカウントを無効化、終了させることは、GitHub のポリシーです。

G. 通知の送信

通知または反論通知を送信する準備ができた場合:

詳細と発言

インターネットで調べれば、一般的な著作権制度および特に DMCA に関する解釈や批評を見つけることはそれほど困難ではありません。 GitHub は、オンラインでの革新性の促進に DMCA が果たした重要な役割を認めて評価していますが、著作権法には、全く新しいリリースではなくとも、1 つまたは複数のパッチを使用できるのではないかと考えています。 ソフトウェアでは、当社はコードを常に改善し更新しています。 DMCA が定められた 1998 年以降どれほど多くの技術が変遷したかを考えてください。 ソフトウェアに適用される法律を更新することは無意味なことでしょうか?

すべてに答えられるとは思っていません。 興味をお持ちの方に、改革に関する意見や提案を記載した学術論文とブログ投稿のリンクをご紹介します。

GitHub は、これらの記事の見解を必ずしも支持しているわけではありません。 必要と思われる変更を検索するために、詳細を知り、独自の意見を形成し、選んだ代表者に連絡することができるリンクがあります (例: U.S. Congress または E.U.Parliament)。