Quando um trabalho criativo é desenvolvido (isso inclui código) o autor por padrão possui todos os direitos autorais sobre a obra, isso significa que ninguém pode distribuir, alterar ou sequer copiar o seu trabalho sem autorização prévia, o problema começa quando o trabalho criativo possui mais de 1 pessoa, e esse ‘ninguém’ inclui todos os participantes. Logo, ninguém pode continuar contribuindo sem uma declaração por escrito garantindo todos os direitos para esses contribuidores, o que é totalmente anti — produtivo em um cenário Open Source.
Um repositório público não garante esses direitos
Se você está utilizando o Github para criar seus projetos ou copiar projetos de terceiros isso significa que você aceitou os termos de serviço, entretanto eles só te respalda a ponto de você visualizar projetos de terceiros ou copiar e ter localmente na sua máquina, a partir do ponto que realiza um commit com material de terceiros em um repositório seu, na ausência de uma licença que lhe garanta a possibilidade de alterar o código, você está ferindo direitos autorais.
Projetos não licenciados
A falta de uma licença num projeto que está em repositório público geralmente é por um equívoco do criador, portanto nesse caso o mais recomendado é você abrir uma issue no projeto pedindo para que seja incluída uma licença e descreva os motivos para usar uma, porque talvez o criador não tenha o conhecimento sobre a necessidade de licenças. Outra maneira de pedir permissão é encontrando um meio de falar diretamente com o criador e garantir uma permissão por escrito para o uso do software em questão, caso não consiga fazer alguma das opções acima, não utilize de forma alguma esse software pois o criador estará em todo direito de tirar a sua cópia do ar e até mesmo processar você.
Copyright x Copyleft
Antes de entrarmos na licença em si, um tópico bem importante quando estamos falando sobre licenciar um software é a diferença entre Copyright e Copyleft.
Copyright garante que o uso, distribuição ou cópia do objeto licenciado é totalmente exclusivo do criador do objeto, vamos exemplificar para ficar mais fácil. Digamos que você queria muito jogar um jogo que seja lançamento, então você vai lá na sua steam ou outro marketplace qualquer, compra o jogo e garante uma cópia do jogo podendo baixar o executável para jogar na sua máquina. Até aí tudo ocorre totalmente dentro da lei de Copyright, mas caso queira criar um mod e compartilhar (em alguns casos as empresas permitem) , revender os arquivos do jogos ou mesmo dar uma cópia dos arquivos do jogo para um amigo você está infringindo a lei.
Mas não é isso que o criador deseja pro software open source, para isso ele disponibiliza uma licença que garanta o Copyleft, um texto que garante a liberdade de executar o programa como queira, estudar como o programa funciona e adaptar para as suas necessidades , distribuir a cópia original do software ou distribuir uma cópia modifica e acesso ao código fonte. Para isso o usuário só precisa garantir que esteja cumprindo todas as cláusulas da licença disponibilizada.
Quais as opções de licenças mais comuns ?
The Unlicense
A licença mais permissiva de todas, serve como um domínio público onde todos podem copiar, usar com intuito comercial, distribuir ou modificar o código fonte sem precisar cumprir cláusula alguma.
ver na integra: https://choosealicense.com/licenses/unlicense/
MIT
Essa licença é curta e simples, por isso é a mais recomendada pra se usar em projetos open source (amplamente utilizada em projetos no node package manager) ela só exige que o usuário que pretende alterar o projeto de alguma forma tenha a licença original em seu projeto e cite o autor, ademais garante tudo que a licença anterior garante.
ver na integra : https://choosealicense.com/licenses/mit/
Apache License 2.0
Ao contrário da anterior, a Apache é um pouco mais restritiva, usando ela terceiros necessitam explicitar toda alteração feita no código fonte e apresentar a licença original em seu projeto. Além disso, projetos podem utilizar este código em projetos patenteados.
ver na integra : https://choosealicense.com/licenses/apache-2.0/
Mozilla Public License 2.0
Nesse ponto as coisas mudam um pouco, apesar de possuir os mesmos requisitos do anterior e a possibilidade de uso em projetos patenteados, aqui o código fonte original deve permanecer sobre a licença Mozilla o que significa que sempre deve ser público, entretanto é permitido combinar esse código com outros que possuam licenças diferentes.
ver na integra : https://choosealicense.com/licenses/mpl-2.0/
GNU General Public License v3.0
Bem parecida com a licença da Mozilla, a GNU exige que o código por completo esteja sobe esta licença, existindo variações como a GNU AGPLv3, GNU GPLv3 e a GNU LGPLv3, das quais não entrarei muito em detalhes pois é um pouco complicado resumir em um artigo.
Como usar uma licença no seu projeto
Para usar uma das licenças citadas a cima, ou outra que você deseja utilizar basta criar um arquivo chamado LICENSE no seu projeto e colar a licença desejada lá, algumas você tem que alterar alguns trechos colocando o nome dos autores mais o ano do qual o software está sendo criado, no site de cada licença você irá achar essas singularidades com mais detalhes.
Mas caso você não queira ter o trabalho de ir no site da licença e copiar, eu encontrei uma extensão do Visual Studio Code, bem legal que facilita o seu trabalho
com ela basta a gente pressionar as teclas (Ctrl+Shift+P no Windows/Linux ou⌘⇧P no mac) e escrever Create LICENSE file que ele vai criar todo o boilerplate da licença junto do arquivo, com uns adendos sobre onde alterar os dados. Caso deseje licenças diferentes ( vem com a Apache License 2.0 por padrão) basta ir em configurações e escolher a licença que deseja
Observações
1º Existe uma infinidade de licenças diferentes, cobrir todas elas em um artigo conciso seria impossível, entretanto quando você conhece um pouco de algumas licenças as outras ficam bem mais fáceis de entender, uma que eu recomendo a leitura sobre é a BSD license que possui 3 cláusulas diferentes.
2º Meu conhecimento na área de direito é bem pequeno, portanto isso não é um guia de qual licença é a melhor em cada caso, esse artigo somente tem o intuito de informar sobre as licenças mais populares no mundo Open Source e algumas de suas peculiaridades, na dúvida procure um advogado.
Agradecimentos
Espero que esse artigo tenha sido útil para entender o básico sobre as licenças mais utilizadas, a ideia desse artigo surgiu pois eu precisava utilizar uma ideia de um projeto gringo em um projeto meu, ademais eu agradeço ao @brunocroh e ao @carlosramos por me ajudarem a revisar esse artigo, até a próxima.
Top comments (0)