Bem-vindo ao Guia do GitHub para o Digital Millennium Copyright Act, comumente conhecido como "DMCA". Esta página não pretende ser uma cartilha abrangente para o estatuto. No entanto, se você recebeu um aviso de remoção da DMCA visando o conteúdo que publicou no GitHub ou se você é um detentor de direitos que deseja emitir tal aviso, esperamos que esta página ajude a desmistificar um pouco a lei, bem como nosso políticas para cumpri-la.
(Se você quiser apenas enviar uma notificação, poderá ir para "G. Envio de Notificações".)
Como em todas as questões jurídicas, é sempre melhor consultar um profissional sobre suas dúvidas ou situações específicas. Nós encorajamos você a fazê-lo antes de tomar qualquer ação que possa afetar seus direitos. Este guia não é aconselhamento jurídico e não deve ser considerado como tal.
O que é o DMCA?
Para entender o DMCA e algumas das linhas de política que ele traça, talvez seja útil considerar a vida antes de ser promulgada.
O DMCA fornece um porto seguro para provedores de serviços que hospedam conteúdo gerado pelo usuário. Como mesmo uma única reclamação de violação de direitos autorais pode acarretar danos legais de até $150,000, a possibilidade de ser responsabilizado por conteúdo gerado pelo usuário pode ser muito prejudicial para os provedores de serviços. Com possíveis danos multiplicados por milhões de usuários, sites de computação em nuvem e de conteúdo gerado por usuários, como YouTube, Facebook ou GitHub, provavelmente nunca teriam existido sem a DMCA (ou pelo menos não sem repassar parte desse custo para seus usuários).
A DMCA aborda esse problema criando um porto seguro de responsabilidade de direitos autorais para provedores de serviços de Internet que hospedam conteúdo gerado pelo usuário supostamente infrator. Essencialmente, desde que um provedor de serviços siga as regras de aviso e remoção da DMCA, ele não será responsável por violação de direitos autorais com base no conteúdo gerado pelo usuário. Por isso, é importante que o GitHub mantenha seu status de porto seguro DMCA.
A DMCA também proíbe a evasão de medidas técnicas que efetivamente controlam o acesso a obras protegidas por direitos autorais.
Avisos DMCA em poucas palavras
A DMCA fornece dois procedimentos simples e diretos que todos os usuários do GitHub devem conhecer: (i) um procedimento de notificação de remoção para os detentores de direitos autorais solicitarem que o conteúdo seja removido e (ii) um procedimento de contranotificação para que os usuários reativem o conteúdo quando o conteúdo for removido por engano ou identificação incorreta.
As notificações de remoção da DMCA são usadas por proprietários de direitos autorais para solicitar ao GitHub que retire o conteúdo que eles acreditam estar infringindo seus direitos. Se você é um designer ou desenvolvedor de software, cria conteúdo protegido por direitos autorais todos os dias. Se outra pessoa estiver usando seu conteúdo protegido por direitos autorais de maneira não autorizada no GitHub, você pode nos enviar um aviso de remoção da DMCA para solicitar que o conteúdo infrator seja alterado ou removido.
Por outro lado, contranotificações podem ser usadas para corrigir erros. Talvez a pessoa que está enviando o aviso de remoção não tenha os direitos autorais ou não tenha percebido que você tem uma licença ou cometeu algum outro erro no aviso de remoção. Como o GitHub geralmente não pode saber se houve um erro, o contra-aviso da DMCA permite que você nos informe e solicite que coloquemos o conteúdo novamente.
O processo de notificação e remoção da DMCA deve ser usado apenas para reclamações sobre violação de direitos autorais. Os avisos enviados por meio de nosso processo de DMCA devem identificar trabalhos protegidos por direitos autorais ou trabalhos que supostamente estão sendo violados. O processo não pode ser usado para outras reclamações, como reclamações sobre supostas violações de marca registrada ou dados suscetíveis; oferecemos processos separados para essas situações.
R. Como Isso Realmente Funciona?
A estrutura DMCA é um pouco como passar notas na aula. O proprietário dos direitos autorais entrega ao GitHub uma reclamação sobre um usuário. Se estiver escrito corretamente, repassamos a reclamação ao usuário. Se o usuário contestar a reclamação, ele pode devolver uma nota dizendo isso. O GitHub exerce pouca discrição no processo além de determinar se os avisos atendem aos requisitos mínimos da DMCA. Cabe às partes (e seus advogados) avaliar o mérito de suas reivindicações, lembrando que as notificações devem ser feitas sob pena de perjúrio.
Aqui estão as etapas básicas do processo.
-
O proprietário dos direitos autorais investiga. Um proprietário de direitos autorais deve sempre conduzir uma investigação inicial para confirmar (a) que possui os direitos autorais de um trabalho original e (b) que o conteúdo no GitHub não é autorizado e é infrator. Isso inclui a confirmação de que o uso não está protegido como uso permitido. Um uso específico pode ser justo se usar apenas uma pequena quantidade de conteúdo protegido por direitos autorais, usar esse conteúdo de maneira transformadora, usá-lo para fins educacionais ou alguma combinação dos itens acima. Como o código naturalmente se presta a esses usos, cada caso de uso é diferente e deve ser considerado separadamente.
Exemplo: Um funcionário da Acme Web Company encontra parte do código da empresa em um repositório do GitHub. A Acme Web Company licencia seu código-fonte para vários parceiros confiáveis. Antes de enviar um aviso de retirada, a Acme deve revisar essas licenças e seus acordos para confirmar que o código no GitHub não está autorizado em nenhum deles.
-
O proprietário dos direitos autorais envia uma notificação. Após conduzir uma investigação, o proprietário dos direitos autorais prepara e envia uma notificação de remoção para o GitHub. Supondo que a notificação de remoção seja suficientemente detalhada de acordo com os requisitos legais (conforme explicado no guia de procedimentos), postaremos a notificação em nosso repositório público e passaremos o link para o usuário afetado.
-
O GitHub pede ao usuário para fazer alterações. Se o aviso alegar que todo o conteúdo de um repositório viola ou um pacote viola, pularemos para a Etapa 6 e desabilitaremos todo o repositório ou pacote rapidamente. Caso contrário, como o GitHub não pode desabilitar o acesso a arquivos específicos dentro de um repositório, entraremos em contato com o usuário que criou o repositório e daremos aproximadamente 1 dia útil para excluir ou modificar o conteúdo especificado no aviso. Notificaremos o proprietário dos direitos autorais se e quando dermos ao usuário a chance de fazer alterações. Como os pacotes são imutáveis, se apenas parte de um pacote estiver infringindo, o GitHub precisaria desabilitar o pacote inteiro, mas permitimos a reintegração assim que a parte infratora for removida.
-
O usuário notifica o GitHub sobre as alterações. Se o usuário optar por fazer as alterações especificadas, ele deverá nos informar no prazo de aproximadamente 1 dia útil. Caso contrário, desabilitaremos o repositório (conforme descrito na Etapa 6). Se o usuário nos notificar que fez alterações, verificaremos se as alterações foram feitas e notificaremos o proprietário dos direitos autorais.
-
O proprietário dos direitos autorais revisará ou retirará a notificação. Se o usuário fizer alterações, o proprietário dos direitos autorais deverá revisá-las e renovar ou revisar seu aviso de remoção se as alterações forem insuficientes. O GitHub não tomará nenhuma medida, a menos que o proprietário dos direitos autorais entre em contato conosco para renovar o aviso de remoção original ou enviar um revisado. Se o proprietário dos direitos autorais estiver satisfeito com as alterações, ele poderá enviar uma retratação formal ou não fazer nada. O GitHub interpretará o silêncio por mais de duas semanas como uma retração implícita do aviso de remoção.
-
O GitHub poderá desabilitar o acesso ao conteúdo. O GitHub desabilitará o conteúdo de um usuário se: (i) o proprietário dos direitos autorais alegou direitos autorais sobre todo o repositório ou pacote do usuário (conforme observado na Etapa 3); (ii) o usuário não fez nenhuma alteração após ter tido a oportunidade de fazê-lo (conforme observado na Etapa 4); ou (iii) o proprietário dos direitos autorais renovou a notificação de remoção depois que o usuário teve a chance de fazer alterações. Se o proprietário dos direitos autorais optar por rever a notificação, voltaremos à Etapa 2 e repetiremos o processo como se a notificação revisada fosse nova.
-
O usuário pode enviar uma contranotificação. Incentivamos os usuários que tiveram o conteúdo desativado a consultar um advogado sobre suas opções. Se um usuário acreditar que seu conteúdo foi desativado como resultado de um erro ou identificação incorreta, ele poderá nos enviar uma contranotificação. Assim como na notificação original, nós nos certificaremos de que a contranotificação seja suficientemente detalhada (conforme explicado no guia de procedimentos). Se for, nós a publicaremos no repositório público e repassaremos a notificação ao proprietário dos direitos autorais enviando a eles o link.
-
O proprietário dos direitos autorais pode entrar com uma ação legal. Se um proprietário de direitos autorais desejar manter o conteúdo desativado após receber uma contranotificação, ele precisará iniciar uma ação legal buscando uma ordem judicial para impedir que o usuário se envolva em atividades infratoras relacionadas ao conteúdo no GitHub. Em outras palavras, você pode ser processado. Se o proprietário dos direitos autorais não notificar o GitHub dentro de 10 a 14 dias, enviando uma cópia de uma reclamação legal válida apresentada em um tribunal de jurisdição competente, o GitHub reativará o conteúdo desativado.
B. E os garfos? (ou o que é um garfo?)
Um dos melhores recursos do GitHub é a capacidade dos usuários de "bifurcar" os repositórios uns dos outros. O que isso significa? Em essência, isso significa que os usuários podem fazer uma cópia de um projeto no GitHub em seus próprios repositórios. Conforme a licença ou a lei permitir, os usuários podem fazer alterações nesse fork para retornar ao projeto principal ou apenas manter como sua própria variação de um projeto. Cada uma dessas cópias é um "Glossário do GitHub" do repositório original, que por sua vez também pode ser chamado de "pai" do fork.
O GitHub não desabilitará automaticamente os forks ao desabilitar um repositório pai. Isso ocorre porque os forks pertencem a usuários diferentes, podem ter sido alterados de maneira significativa e podem ser licenciados ou usados de uma maneira diferente, protegida pela doutrina do uso justo. O GitHub não conduz nenhuma investigação independente sobre forks. Esperamos que os proprietários de direitos autorais conduzam essa investigação e, se acreditarem que os forks também estão infringindo, incluam expressamente os forks em seu aviso de remoção.
Em casos raros, você pode estar alegando violação de direitos autorais em um repositório completo que está sendo ativamente bifurcado. Se, no momento em que você enviou sua notificação, você identificou todas as bifurcações existentes desse repositório como supostamente infratoras, processaremos uma reivindicação válida contra todas as bifurcações nessa rede no momento em que processarmos a notificação. Faríamos isso dada a probabilidade de todos os forks recém-criados conterem o mesmo conteúdo. Além disso, se a rede denunciada que contém o conteúdo supostamente infrator for maior que cem (100) repositórios e, portanto, for difícil de revisar em sua totalidade, podemos considerar a desativação de toda a rede se você declarar em seu aviso que "Com base no número representativo de forks que revisei, acredito que todos ou a maioria dos forks estão infringindo na mesma medida que o repositório pai." Sua declaração juramentada se aplicaria a esta declaração.
C. E quanto às alegações de evasão?
A DMCA proíbe a evasão de medidas técnicas que efetivamente controlam o acesso a obras protegidas por direitos autorais. Uma vez que esses tipos de alegações geralmente são de natureza altamente técnica, o GitHub exige que os autores forneçam informações detalhadas sobre essas alegações e realizaremos uma revisão mais extensa.
Uma reivindicação de evasão deve incluir os seguintes detalhes sobre as medidas técnicas em vigor e a maneira pela qual o projeto acusado as contorna. Especificamente, o aviso ao GitHub deve incluir declarações detalhadas que descrevam:
- Quais são as medidas técnicas;
- Como eles efetivamente controlam o acesso ao material protegido por direitos autorais; e
- Como o projeto acusado é projetado para contornar suas medidas de proteção tecnológica descritas anteriormente.
O GitHub analisará de perto as reivindicações de evasão, inclusive por especialistas técnicos e jurídicos. Na revisão técnica, buscaremos validar os detalhes sobre o funcionamento das medidas técnicas de proteção e a forma como o projeto supostamente as contorna. Na revisão legal, procuraremos garantir que as reivindicações não ultrapassem os limites da DMCA. Nos casos em que não pudermos determinar se uma reivindicação é válida, erraremos do lado do desenvolvedor e deixaremos o conteúdo no ar. Se o reclamante desejar dar mais detalhes, iniciaremos o processo de análise novamente para avaliar as reivindicações revisadas.
Quando nossos especialistas determinarem que uma reclamação é completa, legal e tecnicamente legítima, entraremos em contato com o proprietário do repositório e daremos a ele a chance de responder à reclamação ou fazer alterações no repositório para evitar uma remoção. Se eles não responderem, tentaremos entrar em contato com o proprietário do repositório novamente antes de tomar outras medidas. Ou seja, não desabilitaremos um repositório com base em uma alegação de tecnologia de evasão sem tentar entrar em contato com o proprietário do repositório para dar a ele uma chance de responder ou de fazer alterações primeiro. Se não pudermos resolver o problema entrando em contato com o proprietário do repositório primeiro, sempre teremos prazer em considerar uma resposta do proprietário do repositório, mesmo após o conteúdo ter sido desabilitado, caso ele queira uma oportunidade de contestar a reivindicação, apresente-nos fatos adicionais, ou faça alterações para que o conteúdo seja restaurado. Quando precisarmos desabilitar o conteúdo, garantiremos que os proprietários do repositório possam exportar seus problemas e solicitações de pull e outros dados do repositório que não contenham o suposto código de evasão na medida legalmente possível.
Observe que nosso processo de análise de tecnologia de evasão não se aplica a conteúdo que violaria nossas restrições de Política de Uso Aceitável contra o compartilhamento de chaves de licenciamento de produto não autorizadas, software para gerar chaves de licenciamento de produto não autorizadas ou software para ignorar verificações de chaves de licenciamento de produto. Embora esses tipos de reivindicações também possam violar as disposições da DMCA sobre tecnologia de evasão, elas geralmente são diretas e não garantem uma revisão técnica e legal adicional. No entanto, onde uma reclamação não é direta, por exemplo, no caso de jailbreaks, o processo de revisão de reclamação de tecnologia de evasão se aplicaria.
Quando o GitHub processar uma remoção de DMCA segundo o processo de revisão de alegação de tecnologia de evasão, ofereceremos ao proprietário do repositório uma indicação para receber consultoria jurídica independente por meio do Fundo de Defesa do Desenvolvedor do GitHub sem nenhum custo para ele.
D. E se eu acidentalmente perder a janela para fazer alterações?
Reconhecemos que há muitos motivos válidos para que você não consiga fazer alterações dentro da janela de aproximadamente 1 dia útil que fornecemos antes que seu repositório seja desativado. Talvez nossa mensagem tenha sido sinalizada como spam, talvez você estivesse de férias, talvez não verifique essa conta de e-mail regularmente ou talvez estivesse apenas ocupado. Entendemos. Se você responder para nos informar que gostaria de fazer as alterações, mas de alguma forma perdeu a primeira oportunidade, reativaremos o repositório mais uma vez por aproximadamente 1 dia útil para permitir que você faça as alterações. Novamente, você deve nos notificar de que fez as alterações para manter o repositório ativado após esse prazo de aproximadamente 1 dia útil, conforme observado acima na Etapa A.4. Observe que forneceremos apenas uma chance adicional.
E. Transparência
Acreditamos que a transparência é uma virtude. O público deve saber qual conteúdo está sendo removido do GitHub e por quê. Um público informado pode perceber e trazer à tona possíveis problemas que, de outra forma, passariam despercebidos em um sistema opaco. Postamos cópias editadas de quaisquer notificações legais que recebemos (incluindo notificações originais, contranotificações ou retratações) em https://github.com/github/dmca. Não publicaremos publicamente suas informações de contato pessoais; removeremos informações pessoais (exceto nomes de usuário em URLs) antes de publicar avisos. No entanto, não eliminaremos nenhuma outra informação do seu aviso, a menos que você nos solicite especificamente. Aqui estão alguns exemplos de uma notificação publicada e contranotificação para você ver como é o formato delas. Quando removermos o conteúdo, publicaremos um link para o aviso relacionado em seu lugar.
Observe também que, embora não publiquemos publicamente avisos não editados, podemos fornecer uma cópia completa não editada de quaisquer avisos que recebermos diretamente a qualquer parte cujos direitos sejam afetados por eles.
F. Violação Repetida
É política do GitHub, em circunstâncias apropriadas e a seu exclusivo critério, desativar e encerrar as contas de usuários que possam infringir os direitos autorais ou outros direitos de propriedade intelectual do GitHub ou de outros.
G. Envio de avisos
Se você estiver pronto para enviar uma notificação ou uma contranotificação:
Saiba mais e fale
Se você vasculhar a Internet, não é muito difícil encontrar comentários e críticas sobre o sistema de direitos autorais em geral e o DMCA em particular. Embora o GitHub reconheça e aprecie o importante papel que o DMCA desempenhou na promoção da inovação online, acreditamos que as leis de direitos autorais provavelmente poderiam usar um patch ou dois, se não uma versão totalmente nova. Em software, estamos constantemente melhorando e atualizando nosso código. Pense em quanta tecnologia mudou desde 1998, quando o DMCA foi escrito. Não faz sentido atualizar essas leis que se aplicam ao software?
Não presumimos ter todas as respostas. Mas se você estiver curioso, aqui estão alguns links para artigos acadêmicos e postagens de blogs que encontramos com opiniões e propostas de reforma:
- 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? (O Blogue de 1709)
- 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? (Revisão de Direito de Santa Clara)
O GitHub não endossa necessariamente nenhum dos pontos de vista desses artigos. Fornecemos os links para incentivar você a saber mais, formar suas próprias opiniões e, em seguida, entrar em contato com seus representantes eleitos (p. ex., no Congresso dos EUA ou Parlamento da UE) para solicitar as mudanças que você acha que devem ser feitas.