Политика удаления DMCA

В этой статье

Добро пожаловать в руководство GitHub по Закону об авторском праве в цифровую эпоху, широко известному как «DMCA». Эта страница не предназначена для использования в качестве всеобъемлющего учебника по уставу. Однако, если вы получили уведомление об удалении DMCA, касающееся содержимого, которое вы разместили на GitHub, или если вы являетесь правообладателем, желающим опубликовать такое уведомление, мы надеемся, что эта страница поможет немного демистифицировать закон, а также наши политики его соблюдения.

(Если вы просто хотите отправить уведомление, вы можете перейти к пункту G. «Подача уведомлений».)

Как и во всех юридических вопросах, всегда лучше проконсультироваться с профессионалом по вашим конкретным вопросам или ситуации. Мы настоятельно рекомендуем вам сделать это, прежде чем предпринимать какие-либо действия, которые могут повлиять на ваши права. Это руководство не является юридической консультацией и не должно восприниматься как таковое.

Что такое DMCA?

Чтобы понять DMCA и некоторые политические линии, которые он рисует, возможно, полезно рассмотреть жизнь до того, как он был принят.

DMCA обеспечивает безопасную гавань для поставщиков услуг, которые размещают пользовательское содержимое. Поскольку даже один иск о нарушении авторских прав может повлечь за собой установленный законом ущерб в размере до $150,000, возможность привлечения к ответственности за пользовательское содержимое может быть очень вредной для поставщиков услуг. Учитывая потенциальный ущерб, умноженный на миллионы пользователей, облачные вычисления и сайты с пользовательским содержимым, такие как YouTube, Facebook или GitHub, вероятно, никогда бы не существовали без DMCA (или, по крайней мере, без передачи части этих затрат своим пользователям).

DMCA решает эту проблему, создавая безопасную гавань ответственности за авторские права для интернет-провайдеров, размещающих предположительно нарушающее авторские права пользовательское содержимое. По сути, до тех пор, пока поставщик услуг следует правилам уведомления и удаления DMCA, он не будет нести ответственность за нарушение авторских прав на основании пользовательского содержимого. Из-за этого для GitHub важно поддерживать свой статус безопасной гавани DMCA.

Закон об авторском праве также запрещает обход технических средств, эффективно контролирующих доступ к произведениям, охраняемым авторским правом.

Уведомления DMCA в двух словах

DMCA предоставляет две простые и быстрые процедуры, о которых должны знать все пользователи GitHub: (i) процедура уведомления об отмене прав владельцев авторских прав с запросом удаления содержимого; и (ii) процедура встречного уведомления для пользователей, которые хотят повторно включить содержимое после удаления по ошибке или неправильной идентификации.

Уведомления об удалении в DCMA используются владельцами авторских прав, чтобы попросить GitHub удалить содержимое, которое, по их мнению, нарушает авторские права. Если вы дизайнер или разработчик программного обеспечения, вы каждый день создаете защищенное авторским правом содержимое. Если кто-то другой использует ваше содержимое, защищенное авторским правом, на GitHub несанкционированным образом, вы можете отправить нам уведомление об удалении DMCA с просьбой изменить или удалить содержимое, нарушающее авторские права.

С другой стороны, встречные уведомления можно использовать для исправления ошибок. Возможно, человек, отправляющий уведомление об удалении, не обладает авторскими правами, не знал, что у вас есть лицензия, или допустил какую-либо другую ошибку в своем уведомлении об удалении. Поскольку GitHub обычно не может знать, произошла ли ошибка, встречное уведомление DMCA позволяет вам сообщить нам об этом и попросить, чтобы мы снова разместили содержимое.

Уведомление DMCA и процесс удаления следует использовать только для жалоб на нарушение авторских прав. Уведомления, отправляемые в рамках нашего процесса DMCA, должны указывать работу, защищенную авторским правом, или работы, которые предположительно нарушаются. Процесс не может использоваться для других жалоб, таких как жалобы на предполагаемое нарушение товарных знаков или конфиденциальности данных; мы предлагаем отдельные процессы для этих ситуаций.

А. Как это на самом деле работает?

Структура DMCA немного похожа на передачу заметок в классе. Владелец авторских прав передает GitHub жалобу на пользователя. Если он написан правильно, мы передаем жалобу пользователю. Если пользователь оспаривает жалобу, он может передать примечание в ответ. GitHub проявляет мало свободы в процессе, кроме определения того, соответствуют ли уведомления минимальным требованиям DMCA. Стороны (и их адвокаты) должны оценить обоснованность своих требований, имея в виду, что уведомления должны быть сделаны под страхом наказания за лжесвидетельство.

Вот основные шаги в этом процессе.

  1. Правообладатель проводит расследование. Владелец авторских прав всегда должен проводить предварительное расследование, чтобы подтвердить (а) что он владеет авторскими правами на оригинальное произведение и (б) что содержимое на GitHub является несанкционированным и нарушает авторские права. Это включает в себя подтверждение того, что использование не защищено как справедливое использование. Конкретное использование может быть добросовестным, если оно использует только небольшое количество содержимого, защищенного авторским правом, использует это содержимое преобразующим образом, использует его в образовательных целях или сочетает в себе вышеперечисленное. Поскольку код естественным образом подходит для такого использования, каждый вариант использования отличается и должен рассматриваться отдельно.

    Пример: Сотрудник Acme Web Company находит часть кода компании в репозитории GitHub. Компания Acme Web предоставляет лицензии на свой исходный код нескольким доверенным партнерам. Перед отправкой уведомления об удалении Acme должна просмотреть эти лицензии и свои соглашения, чтобы убедиться, что код на GitHub не авторизован ни в одной из них.

  2. Владелец авторских прав отправляет уведомление. После проведения расследования правообладатель готовит и отправляет уведомление об удалении на GitHub. Если уведомление об удалении достаточно подробное и соответствует нормативным требованиям (как описано в руководстве), мы разместим уведомление в нашем общедоступном репозитории и передадим ссылку пользователю, которого это касается.

  3. GitHub просит пользователя внести изменения. Если в уведомлении утверждается, что все содержимое репозитория или пакет нарушает авторские права, мы перейдем к шагу 6 и оперативно отключим весь репозиторий или пакет. В противном случае, поскольку GitHub не может отключить доступ к определенным файлам в репозитории, мы свяжемся с пользователем, создавшим репозиторий, и предоставим ему примерно 1 рабочий день для удаления или изменения содержимого, указанного в уведомлении. Мы уведомим владельца авторских прав, если и когда предоставим пользователю возможность внести изменения. Поскольку пакеты неизменяемы, если только часть пакета нарушает авторские права, GitHub потребуется отключить весь пакет, но мы разрешаем восстановление после удаления части, нарушающей авторские права.

  4. Пользователь уведомляет GitHub об изменениях. Если пользователь решит внести указанные изменения, он должен сообщить нам об этом в течение примерно 1 рабочего дня. Если они этого не сделают, мы отключим репозиторий (как описано в шаге 6). Если пользователь уведомит нас о внесении изменений, мы проверим, были ли внесены изменения, а затем уведомим владельца авторских прав.

  5. Владелец авторских прав пересматривает или отзывает уведомление. Если пользователь вносит изменения, владелец авторских прав должен просмотреть их и обновить или пересмотреть свое уведомление об удалении, если изменений недостаточно. GitHub не будет предпринимать никаких дальнейших действий, если владелец авторских прав не свяжется с нами, чтобы обновить исходное уведомление об удалении или отправить исправленное. Если владелец авторских прав удовлетворен изменениями, он может либо официально подать опровержение, либо ничего не предпринимать. GitHub будет интерпретировать молчание более двух недель как подразумеваемый отзыв уведомления об удалении.

  6. GitHub может отключить доступ к содержимому. GitHub отключает содержимое пользователя, если: (i) владелец авторских прав заявил об авторских правах на весь репозиторий или пакет пользователя (как указано на шаге 3); (ii) пользователь не внес никаких изменений после того, как ему была предоставлена возможность сделать это (как указано на шаге 4); или (iii) владелец авторских прав возобновил свое уведомление об удалении после того, как у пользователя была возможность внести изменения. Если правообладатель решит вместо этого пересмотреть уведомление, мы вернемся к шагу 2 и повторим процесс, как если бы пересмотренное уведомление было новым уведомлением.

  7. Пользователь может отправить встречное уведомление. Мы рекомендуем пользователям, у которых отключено содержимое, проконсультироваться с юристом о своих возможностях. Если пользователь считает, что его содержимое было отключено в результате ошибки или неправильной идентификации, он может отправить нам встречное уведомление. Как и в случае с первоначальным уведомлением, мы позаботимся о том, чтобы встречное уведомление было достаточно подробным (как поясняется в руководстве). Если такое уведомление подано, мы опубликуем его в нашем общедоступном репозитории и передадим уведомление владельцу авторских прав, отправив ему ссылку.

  8. Владелец авторских прав может подать судебный иск. Если владелец авторских прав желает оставить содержимое отключенным после получения встречного уведомления, ему необходимо будет возбудить судебный иск с требованием постановления суда, чтобы удержать пользователя от участия в нарушении прав, связанных с содержимым на GitHub. Другими словами, вас могут засудить. Если владелец авторских прав не уведомит GitHub в течение 10-14 дней, отправив копию действительной юридической жалобы, поданной в суд соответствующей юрисдикции, GitHub повторно активирует отключенное содержимое.

B. Что насчет вилок? (или Что такое вилка?)

Одной из лучших особенностей GitHub является возможность для пользователей «разветвлять» репозитории друг друга. Что это обозначает? По сути, это означает, что пользователи могут сделать копию проекта на GitHub в свои собственные репозитории. В соответствии с лицензией или законом пользователи могут затем вносить изменения в эту вилку, чтобы либо вернуться к основному проекту, либо просто сохранить как свою собственную вариацию проекта. Каждая из этих копий представляет собой «Глоссарий GitHub» исходного репозитория, который, в свою очередь, может называться «родительским элементом» вилки.

GitHub не будет автоматически отключать вилки при отключении родительского репозитория. Это связано с тем, что вилки принадлежат разным пользователям, могут быть существенно изменены и могут лицензироваться или использоваться другим способом, защищенным доктриной добросовестного использования. GitHub не проводит никаких независимых расследований вилок. Мы ожидаем, что владельцы авторских прав проведут это расследование и, если они сочтут, что вилки также нарушают авторские права, прямо включат вилки в свое уведомление об удалении.

В редких случаях вы можете заявить о нарушении авторских прав в полном репозитории, который активно разветвляется. Если на момент отправки уведомления вы определили все существующие ответвления этого репозитория как предположительно нарушающие авторские права, мы обработаем действительный иск против всех ответвлений в этой сети на момент обработки уведомления. Мы бы сделали это, учитывая вероятность того, что все вновь созданные вилки будут содержать одно и то же содержимое. Кроме того, если заявленная сеть, которая содержит содержимое, предположительно нарушающее авторские права, превышает сто (100) репозиториев и, таким образом, будет трудно проверить ее целиком, мы можем рассмотреть возможность отключения всей сети, если вы укажете в своем уведомлении, что «на основании относительно репрезентативного количества вилок, которые я рассмотрел, я считаю, что все или большинство вилок нарушают авторские права в той же степени, что и родительский репозиторий». Ваше заявление под присягой будет относиться к этому заявлению.

C. Как насчет требований об обходе?

DMCA запрещает обход технических средств, эффективно контролирующих доступ к произведениям, охраняемым авторским правом. Учитывая, что эти типы претензий часто являются чисто техническими по природе, GitHub требует, чтобы заявители предоставили подробную информацию об этих претензиях, и мы проведем более широкую проверку.

Заявление об обходе должно включать следующие сведения о технических мерах и способах их обхода обвиняемым проектом. В частности, уведомление для GitHub должно содержать подробные заявления, описывающие:

  1. Каковы технические меры;
  2. Как они эффективно контролируют доступ к материалам, защищенным авторским правом; и
  3. Как обвиняемый проект предназначен для обхода их ранее описанных мер технологической защиты.

GitHub внимательно рассмотрит заявления об обходе, в том числе техническими и юридическими экспертами. В техническом обзоре мы постараемся проверить детали того, как действуют меры технической защиты и как проект предположительно их обходит. В ходе юридической проверки мы будем стремиться к тому, чтобы претензии не выходили за рамки DMCA. В тех случаях, когда мы не можем определить, является ли претензия действительной, мы ошибаемся на стороне разработчика и оставляем содержимое вверху. Если заявитель желает получить дополнительную информацию, мы снова начнем процесс рассмотрения, чтобы оценить пересмотренные претензии.

Если наши эксперты определят, что претензия является полной, законной и технически законной, мы свяжемся с владельцем репозитория и предоставим ему возможность ответить на претензию или внести изменения в репо, чтобы избежать удаления. Если они не ответят, мы попытаемся снова связаться с владельцем репозитория, прежде чем предпринимать какие-либо дальнейшие действия. Другими словами, мы не будем отключать репозиторий на основании заявлений о технологии обхода безопасности, не пытаясь связаться с владельцем репозитория, чтобы дать ему возможность ответить или внести изменения в первую очередь. Если мы не можем решить проблему, связавшись сначала с владельцем репозитория, мы всегда будем рады рассмотреть ответ от владельца репозитория даже после того, как контент был отключен, если они хотели бы иметь возможность оспорить претензию, представить нам дополнительные факты, или внесите изменения, чтобы восстановить содержимое. Когда нам потребуется отключить содержимое, мы позаботимся о том, чтобы владельцы репозиториев могли экспортировать свои задачи и запросы на извлечение и другие данные репозитория, которые не содержат предполагаемый код обхода, насколько это возможно по закону.

Обратите внимание, что наш процесс проверки технологии обхода не распространяется на содержимое, которое в противном случае нарушило бы ограничения нашей Политики допустимого использования в отношении передачи несанкционированных лицензионных ключей продукта, программного обеспечения для создания несанкционированных лицензионных ключей продукта или программного обеспечения для обхода проверок лицензионных ключей продукта. Хотя такие претензии могут также нарушать положения DMCA о технологиях обхода цензуры, они, как правило, являются простыми и не требуют дополнительной технической и юридической проверки. Тем не менее, если претензия не является однозначной, например, в случае джейлбрейка, применяется процесс рассмотрения претензии в отношении технологии обхода защиты.

Когда GitHub обрабатывает удаление DMCA в соответствии с нашим процессом рассмотрения претензии по технологии обхода правил, мы предложим владельцу репозитория направление для получения независимой юридической консультации через Фонд защиты разработчиков GitHub бесплатно для них.

D. Что делать, если я случайно пропустил окно для внесения изменений?

Мы понимаем, что существует множество веских причин, по которым вы не сможете внести изменения в течение примерно 1 рабочего дня, который мы предоставляем, прежде чем ваш репозиторий будет отключен. Может быть, наше сообщение было помечено как спам, может быть, вы были в отпуске, может быть, вы не проверяете эту учетную запись регулярно, или, может быть, вы просто были заняты. Мы получим это. Если вы сообщите нам, что хотели бы внести изменения, но почему-то упустили первую возможность, мы повторно включим репозиторий еще раз примерно на 1 рабочий день, чтобы вы могли внести изменения. Опять же, вы должны уведомить нас о том, что вы внесли изменения, чтобы репозиторий оставался включенным по истечении этого периода примерно в 1 рабочий день, как указано выше в Шаге А.4. Обратите внимание, что мы предоставим только один дополнительный шанс.

Е. Прозрачность

Мы считаем, что прозрачность является добродетелью. Общественность должна знать, какое содержимое удаляется с GitHub и почему. Информированная общественность может заметить и выявить потенциальные проблемы, которые иначе остались бы незамеченными в непрозрачной системе. Мы публикуем отредактированные копии любых юридических уведомлений, которые мы получаем (включая оригинальные уведомления, встречные уведомления или опровержения) по адресу https://github.com/github/dmca. Мы не будем публично публиковать вашу личную контактную информацию; мы удалим личную информацию (за исключением имен пользователей в URL-адресах) перед публикацией уведомлений. Однако мы не будем редактировать никакую другую информацию из вашего уведомления, если вы специально не попросите нас об этом. Ниже приведены некоторые примеры опубликованного уведомления и встречного уведомления, чтобы увидеть, как они выглядят. Когда мы удаляем содержимое, мы размещаем на его месте ссылку на соответствующее уведомление.

Также обратите внимание, что, хотя мы не будем публиковать неотредактированные уведомления, мы можем предоставить полную неотредактированную копию любых уведомлений, которые мы получаем, непосредственно любой стороне, чьи права могут быть затронуты этим.

F. Повторное нарушение

Политика GitHub заключается в том, чтобы при соответствующих обстоятельствах и по собственному усмотрению отключать и удалять учетные записи пользователей, которые могут нарушать авторские права или другие права на интеллектуальную собственность GitHub или других лиц.

G. Отправка уведомлений

Если вы готовы подать уведомление или встречное уведомление:

Узнайте больше и выскажитесь

Если порыться в Интернете, нетрудно найти комментарии и критику системы авторского права в целом и DMCA в частности. Хотя GitHub признает и ценит важную роль, которую DMCA сыграло в продвижении инноваций в Интернете, мы считаем, что законы об авторском праве, вероятно, могли бы использовать один или два исправления, если не целую новую версию. В программном обеспечении мы постоянно совершенствуем и обновляем наш код. Подумайте о том, как сильно изменились технологии с 1998 года, когда был написан DMCA. Разве не имеет смысла обновить эти законы, которые применяются к программному обеспечению?

Мы не предполагаем, что у нас есть ответы на все вопросы. Но если вам интересно, вот несколько ссылок на научные статьи и сообщения в блогах, которые мы нашли с мнениями и предложениями по реформе:

GitHub не обязательно поддерживает какие-либо точки зрения в этих статьях. Мы предоставляем ссылки, которые позволят вам узнать больше, сформировать собственное мнение, а затем обратиться к избранным представителям (например, в Конгрессе США или Европейском парламенте), чтобы предложить любые изменения, которые вы считаете необходимыми.