DMCAテイクダウンポリシー

このページは、GitHub によるデジタルミレニアム著作権法（DMCA）のガイドです。 これは法律を包括的に説明する入門書ではありません が、あなたが GitHub に投稿したコンテンツを対象とする DMCA テイクダウン通知を受け取った場合、またはそのような通知を発行しようとしている権利所有者の場合、このページはこの法律や、それに従うための当社の方針を理解する上で役立つはずです。

(If you just want to submit a notice, you can skip to "G. Submitting Notices.")

法律に関わるあらゆる事項と同様、具体的な疑問や状況については専門家に相談するのが常に最善です。 あなたの権利に影響を及ぼす可能性のある行動をとる前に、そうすることを強くお勧めします。 このガイドは法律上の助言ではなく、またそのように解釈されるべきではありません。

DMCA とは？

DMCA とそこから導き出されるポリシーの一部を理解するには、この法律が制定される前の世の中について考えてみると良いでしょう。

DMCA は、ユーザ生成コンテンツをホストするサービスプロバイダーにセーフハーバーを提供します。 たった一つの著作権侵害請求でも最大 15 万ドルの法定損害賠償金が生じる可能性があることを考えると、ユーザ生成コンテンツの責任を問われる恐れは、サービスプロバイダーにとって死活問題になり得ます。 損害規模が数百万人のユーザに及ぶ可能性がある、クラウドコンピューティングや YouTube、Facebook、GitHub などのユーザ生成コンテンツサイトは、おそらく DMCA なしでは（または少なくともそのコストの一部をユーザに負担してもらわなければ）存在しなかったでしょう。

DMCA は、権利侵害が申し立てられたユーザ生成コンテンツをホストしているインターネットサービスプロバイダー向けの著作権責任のセーフハーバーを設けることにより、この問題に対処しています。 基本的に、DMCA のノーティスアンドテイクダウンの規則に従っている限り、サービスプロバイダーはユーザ生成コンテンツに基づく著作権侵害の責任を問われません。 このため、DMCA のセーフハーバーの状態を維持することは GitHub にとって重要です。

また DMCA は、著作権で保護されている著作物へのアクセスを効果的に制限する技術的手段の迂回も禁止しています。

DMCA 通知の要約

DMCA には、すべての GitHub ユーザが知っておくべき 2 つの単純でわかりやすい手続きが用意されています。それは、(i) 著作権所有者がコンテンツの削除を要求するためのテイクダウン通知の手続き、および (ii) コンテンツが誤ってまたは誤認されて削除された場合に、ユーザがコンテンツを再度有効にするための異議申し立て通知の手続きです。

著作権所有者は DMCA テイクダウン通知を使用して、GitHub に著作権を侵害していると思われるコンテンツを削除するよう依頼することができます。 ソフトウェア設計者や開発者であれば、著作権で保護されたコンテンツを日常的に作成しているでしょう。 他の誰かが著作権で保護されたあなたのコンテンツを GitHub で不正に使用している場合、あなたは著作権を侵害しているコンテンツを変更または削除するよう要求する DMCA テイクダウン通知を当社に送信できます。

一方、異議申し立て通知は間違いを修正するために使用できます。 テイクダウン通知を送信した人が著作権を保持していない場合や、あなたがライセンスを所有していることを知らなかった場合など、間違いでテイクダウン通知が行われるケースもあります。 通常、GitHub には間違いがあったかどうかを知る術がないため、このような場合は DMCA の異議申し立て通知を使用してコンテンツの復元を依頼してください。

DMCA のノーティスアンドテイクダウンプロセスは、著作権侵害に関する苦情に対してのみ使用されるべきものです。 DMCA プロセスを通じて送信された通知では、著作物または著作権侵害が申し立てられた著作物を特定する必要があります。 このプロセスは、商標権侵害の申し立てや機密データに関する苦情など、他の苦情には使用できません。これらの状況に対しては個別のプロセスが用意されています。

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 は、元のテイクダウン通知を更新する旨または修正版を送信する旨の連絡が著作権所有者からない限り、それ以上の措置を講じません。 著作権所有者は、変更に満足した場合、正式な撤回を提出することも、何もしないこともできます。 沈黙が 2 週間以上続いた場合、GitHub はそれをテイクダウン通知の暗黙の撤回として解釈します。

6. GitHub がコンテンツへのアクセスを無効にする場合があります。次のいずれかの場合、GitHub はユーザのコンテンツを無効にします。(i) 著作権所有者がユーザのリポジトリ全体またはパッケージに対して著作権を主張している場合（ステップ 3 に記載）、(ii) ユーザが変更の機会を与えられた後、変更を行わなかった場合（ステップ 4 に記載）、(iii) ユーザが変更を行う機会を得た後、著作権所有者がテイクダウン通知を更新した場合。 著作権所有者が通知を修正することを代わりに選択した場合、当社はステップ 2 に戻り、修正された通知を新規の通知とみなしてプロセスを繰り返します。

7. ユーザは異議申し立て通知を送信できます。コンテンツを無効にしたユーザは、選択肢について弁護士に相談することをお勧めします。 間違いや誤認によりコンテンツが無効にされたと思われる場合は、ユーザは異議申し立て通知を送信できます。 元の通知と同様に、当社は異議申し立て通知が十分に詳細であることを確認します（ハウツーガイドで説明されています）。 問題ない場合、当社はパブリックリポジトリに投稿し、リンクを送信することで著作権所有者に通知を返します。

8. 著作権所有者は法的措置を講じることができます。異議申し立て通知を受け取った後も引き続きコンテンツを無効にしたい場合、著作権所有者は GitHub のコンテンツに関連する侵害行為にユーザが関与することを抑制する裁判所命令を求める法的措置を講じる必要があります。 つまり、訴えられる可能性があります。 10〜14 日以内に著作権所有者が GitHub に通知しない場合、管轄権のある裁判所に提出された有効な訴状の写しを送信することにより、GitHub は無効化されたコンテンツを再度有効にします。

B. フォークの場合は？ （またはフォークとは？）

GitHub の最も優れた機能の 1 つに、ユーザが互いのリポジトリを「フォーク」できることがあります。 どういうことかと言うと、 基本的に、ユーザは GitHub のプロジェクトのコピーを自分のリポジトリに作成できます。 ライセンスや法律で許可されている範囲で、ユーザはそのフォークを変更してメインプロジェクトに戻したり、プロジェクトの独自のバリエーションとして保持したりすることができます。 これらの各コピーは、元のリポジトリの「フォーク」であり、フォークの「親」とも呼ばれます。

GitHub は、親リポジトリを無効にするときにフォークを自動的に無効にしません。 これは、フォークが異なるユーザに属し、著しく変更されている可能性があり、フェアユースの原則によって保護されている別の方法でライセンス供与または使用されている可能性があるためです。 GitHub がフォークに対して独立した調査を行うことはありません。 著作権所有者がその調査を行い、フォークも著作権を侵害していると思われる場合は、テイクダウン通知にフォークを明示的に含めることが求められます。

時には、活発にフォークされているリポジトリ全体で著作権の侵害を主張することもあるでしょう。 あなたが通知を送信した時点で、そのリポジトリの既存フォーク全体を指定して著作権を侵害していると申し立てた場合、通知を処理する際に、そのネットワークにあるすべてのフォークに対して、有効な請求を適用します。 新しく作成されたフォークすべてに同じコンテンツが含まれる可能性を考慮して、これを行います。 さらに、著作権侵害の疑いがあるコンテンツを含むとして報告されたネットワークが 100 リポジトリを超え、そのすべてを確認することが困難である際、通知の中であなたが次のように記載している場合にはネットワーク全体の無効化を検討します。「サンプルとして十分な数のフォークを確認した結果、私はこのフォークのすべてまたは大部分が、親リポジトリと同程度に著作権を侵害しているものと信じています。(Based on the representative number of forks I have reviewed, I believe that all or most of the forks are infringing to the same extent as the parent repository.)」 あなたの宣誓は、この申し立てに対して適用されます。

C. 迂回の申し立てへの対応

DMCA は、著作権で保護されている著作物へのアクセスを効果的に制限する技術的手段の迂回を禁止しています。 この種の申し立ては非常に技術的に高度である場合が多いので、GitHub は申立人に対し、申し立てについて詳細な情報の提供を求め、比較的大規模な確認を行います。

迂回に関する申し立てには、訴えるプロジェクトが備える技術的手段、および迂回の方法について、以下を詳述する必要があります。 特に GitHub への通知には、以下を説明する詳細な文章を記載する必要があります。

1. 技術的手段
2. 用いられている技術的手段が著作権で保護されたものへのアクセスを効果的に制限する方法
3. 訴えるプロジェクトが、前述の技術的保護措置をどのように迂回するよう設計されているか

GitHub は、技術的専門家と法的専門家の両者を交えて、迂回の申し立てを綿密に調べます。 技術的審査においては、技術的保護措置の仕組みと、プロジェクトが保護措置を迂回すると申し立てられている方法の詳細を検証するよう努めます。 法的審査においては、申し立てが DMCA の範囲を超えないように努めます。 申し立てが有効であるかどうかを判断できない場合は、開発者側を優先し、コンテンツを残します。 申立人が追加情報を提供して再度審査を求める場合、改訂された申し立てを評価するため再度審査を開始することがあります。

当社の専門家が、申し立てが十全で、法的、技術的に妥当であると判断した場合、当社はリポジトリのオーナーに連絡し、テイクダウンを回避するため、申し立てに応答するかリポジトリに変更を加える機会を与えます。 リポジトリのオーナーが応答しない場合は、さらなる対処を行う前に再度連絡を試みます。 つまり、リポジトリのオーナーに応答または変更の機会を与えるため連絡を試みる前に、迂回技術の申し立てに基づいてリポジトリを無効化することはいたしません。 リポジトリのオーナーに連絡して問題が解決しなかった場合、たとえコンテンツが無効化された後であっても、申し立てに意義を唱える機会を求める、追加の事実を提供する、またはコンテンツを復元するために変更を行う場合、当社はリポジトリのオーナーからの応答を検討いたします。 当社がコンテンツを無効化する必要がある場合は、Issue、プルリクエスト、および迂回コードと申し立てられているものを含まないその他のリポジトリデータについて、法的に可能な範囲でリポジトリのオーナーがエクスポートできるようにします。

ただし、当社の迂回技術に関する審査プロセスは、当社の利用規定に反して、不正な製品ライセンスキー、製品ライセンスキーを不正に生成するソフトウェア、および製品ライセンスキーのチェックを迂回するソフトウェアを共有するコンテンツには適用されません。 この種の申し立ては、迂回技術に関する DMCA の規定にも違反していることがありますが、通常は違反が明白であり、技術的および法的審査の実施は保証できません。 しかしながら、ジェイルブレイクなど、申し立ての真偽が明白でない場合は、申し立ての審査プロセスが適用される可能性があります。

When GitHub processes a DMCA takedown under our circumvention technology claim review process, we will offer the repository owner a referral to receive independent legal consultation through GitHub’s Developer Defense Fund at no cost to them.

D. うっかりして期間内に変更できなかった場合は？

正当な理由で、リポジトリが無効になる前に提供されるおよそ 1 営業日の期間内に変更を行うことができないケースも多々あることでしょう。 当社からのメッセージがスパムフォルダに入ってしまう場合も、休暇中だった場合も、対象のメールアカウントを定期的に確認していない場合も、単に忙しかった場合もあるでしょう。 このように 変更を行いたかったが、何らかの理由で最初の機会を逃した場合は、その旨を当社にご連絡ください。変更を行うことができるように、リポジトリを再度約 1 営業日有効にします。 繰り返しになりますが、上記のステップ A.4 で説明したように、約 1 営業日が過ぎてもリポジトリを有効に保つためには変更を行ったことを当社に通知する必要があります。 なお、この追加の機会が提供されるのは 1 度限りですのでご注意ください。

E. 透明性

当社は、透明性は美徳であると信じています。 GitHub から削除されるコンテンツとその理由は公にされるべきです。 知識のある人は、不透明なシステムでは見過ごされてしまう潜在的な問題に気づきこれを表面化することができます。 当社は、受け取った法的通知（元の通知、異議申し立て通知、撤回を含む）の編集後の写しを https://github.com/github/dmca に投稿します。 当社は、個人の連絡先情報は公開しません。通知を公開する前に個人情報（URL のユーザ名を除く）を削除します。 ただし、特別な要請がない限り、当社が通知のその他の情報を編集することはありません。 こちらに公開された通知と異議申し立て通知の例を示しますのでご覧ください。 当社は、コンテンツを削除すると、関連する通知へのリンクを代わりに投稿します。

また、当社が未編集の通知を公開することはありませんが、受け取った通知の未編集の完全な写しを、それによって自身の権利が影響を受ける当事者に直接提供する場合はありますのでご注意ください。

F. 繰り返しの侵害

GitHub は、当社のポリシーとして、状況によっては独自の裁量により、GitHub またはその他の著作権またはその他の知的財産権を侵害する可能性のあるユーザのアカウントを無効化および解約します。

G. 通知の提出

通知または異議申し立て通知を提出する準備ができている場合

• DMCA 通知の提出方法
• DMCA 異議申し立て通知の提出方法

詳細および当社の見解

インターネットを探せば、著作権システム全般、特に DMCA についての解説や批判は難なく見つけることができるでしょう。 GitHub は、オンラインでイノベーションを促進する上で DMCA が果たしてきた重要な役割を認識し、評価していますが、著作権法については刷新とまではいかなくても、多少の改訂を加える程度のことはあってもいいのではないかと考えています。 ソフトウェアの世界では、コードは絶えず改善、更新されています。 DMCA が作成された 1998 年から、テクノロジーはどれほど変化したことでしょう。 ソフトウェアに適用されるこうした法律を更新することは理にかなっているのではないでしょうか。

もちろん当社の考え方が絶対ではありません が、改革に関する意見や提案について私たちが見つけた学術記事やブログ投稿を以下に紹介しますので、もしご関心がございましたらご覧ください。

• Unintended Consequences: Twelve Years Under the DMCA (Electronic Frontier Foundation)
• Statutory Damages in Copyright Law: A Remedy in Need of Reform (William & Mary Law Review)
• Is the Term of Protection of Copyright Too Long? (The 1709 Blog)
• If We're Going to Change DMCA's 'Notice & Takedown,' Let's Focus on How Widely It's Abused (TechDirt)
• Opportunities for Copyright Reform (Cato Unbound)
• Fair Use Doctrine and the Digital Millennium Copyright Act: Does Fair Use Exist on the Internet Under the DMCA? (Santa Clara Law Review)

GitHub は、必ずしもこれらの記事の視点を支持しているわけではありません。 私たちがこうしたリンクを提供するのは、あなたがより多くのことを学び、あなた自身の意見を形成し、そしてあなたが選んだ代表者（例えば、米国 議会や欧州 議会）に働き掛けて、あなたが考える必要な変化を求めることができるようにするためです。