Direito Autoral e Software Livre
Direito Autoral
Software é monopolizado no Brasil e no mundo por direito autoral. Infelizmente, alguns países permitem patentes que monopolizam software.
No Brasil, as leis 9610/1998 e 9609/1998 regulam o direito autoral sobre software.
Internacionalmente, utiliza-se a convenção de Berna.
Direito Autoral
O autor detém privilégios sobre várias atividades, que podem ser concedidos a terceiros através de autorização prévia e expressa.
Exemplos: copiar, transmitir, traduzir, adaptar, etc.
Licença de software
A licença é o instrumento que o detentor do direito patrimonial utiliza para autorizar de forma prévia e expressa.
Uma EULA é um instrumento diferente, em que o usuário aceita abrir mão de outros direitos, não apenas aqueles excluídos pelo direito autoral.
Software Livre
Richard Stallman publicou o manifesto GNU em 1983, convocando outros desenvolvedores a criarem, em conjunto, um sistema operacional livre.
Em 1985, criou a Free Software Foundation e, tempos depois, publicou a definição de software livre, que mais tarde seriam as 4 liberdades.
Software Livre
As 4 liberdades são:
A liberdade de executar o programa, para qualquer propósito;
A liberdade de estudar como o programa funciona, e adaptá-lo às suas necessidades;
A liberdade de redistribuir cópias de modo que você possa ajudar ao próximo;
A liberdade de distribuir cópias de suas versões modificadas a outros.
Domínio público
Quando encerra o prazo do monopólio concedido pelo direito autoral. Em alguns países, é possível disponibilizar uma nova obra sob domínio público.
Obras derivadas de uma obra em domínio público têm novo monopólio garantido.
Copyleft
Uma licença que garante as quatro liberdades, permite obras derivadas, mas requer que essas sejam licenciadas da mesma forma, perpetuando as liberdades.
GPL
Criada em 1989, atualizada em 1991, e novamente, em 2006, a licença copyleft mais popular e utilizada.
Permite a distribuição comercial, com ou sem modificações, desde que o código fonte seja distribuído ou oferecido junto ao binário, sob a mesma licença.
Open Source Initiative
Criada em 1998, lançou o projeto Mozilla, e a definição de Open Source, baseada nas 10 diretivas do Debian.
Aceitava registros de novas licenças, que recebiam o "selo" OSI.
Proliferação de licenças
Em 2006, a OSI caiu na real, que a proliferação de licenças era prejudicial para a adoção do Open Source, pois dificultava a escolha da licença e criava novas incompatibilidades entre elas.
Fez uma classificação das licenças.
Classificação segundo OSI
Licenças populares, largamente utilizadas ou com fortes comunidades.
Licenças de propósito especial.
Licenças redundantes com as mais populares.
Licenças não reutilizáveis.
Outras licenças.
Licenças substituídas.
Licenças voluntariamente aposentadas.
GPLv3
Em 2006, a FSF convocou o público a ajudar a escrever a GPLv3. Ao final, muitas melhorias e defesas a novas ameaças:
Requer que o software possa ser modificado pelo usuário no dispositivo, caso seja modificável pelo fabricante;
Desqualifica software licenciado como GPLv3 utilizado em mecanismos de DRM como "mecanismo de proteção", impedindo pessoas de serem presas por quebrá-los;
Contribuidors cedem as licenças de suas patentes que cobrem o software;
GPLv3
Clarifica e cria novas compatibilidades;
Uma licença global.
GPLv3
Incompatível com GPLv2, mas aqueles que licenciaram seu software como GPLv2 ou superior, podem optar pelo relicenciamento para GPLv3 ou superior.
Esta incompatibilidade e alguns ataques feitos à GPLv3 foram prejudiciais e sua adoção não é tão grande quanto a GPLv2.
Apache License 2.0
Vários projetos passaram a adotar a Apache License 2.0, tornando-a uma das licenças mais populares nos últimos anos.
Infelizmente, ela também é incompatível com GPLv2.
Evite
Criar sua própria licença.
Usar a licença BSD original, com quatro cláusulas.
Adotar uma licença incompatível com várias outras.
Por que licenciar?
- Porque sem licença, software não pode ser compartilhado, distribuído, transmitido, alterado, sem a permissão do autor.
Por que se preocupar com compatibilidade entre licenças?
- Para respeitar as licenças do software de outros, permitindo a utilização dos direitos por ela concedidos.
Mais uma vez?
- Sem a autorização explícita, expressa, o usuário final ou intermediário não estará seguro. As incertezas causadas pelo sistema em que vivemos podem assombrar tais usuários no futuro.
Algum incentivo?
- Quando grandes empresas compram pequenas startups, os primeiros a chegarem são os advogados, com seus competentes auditores. Sem licença, sem fortuna!
Evite licenças confusas
- "Do no Evil" considerada má.
Mitos sobre licenças de software livre
Software Comercial e Software Livre
Software Livre pode ser comercializado e utilizado para fins comerciais.
Existe Software Livre comercial e gratuito.
Existe Software Proprietário comercial e gratuito.
GPL e Distribuição de código fonte
Código fonte não precisa ser contribuído pro projeto original.
Código fonte não precisa ser publicado na Internet.
Mas recipientes do software devem receber o código fonte e podem redistribuí-lo.
GPL e Distribuição de código fonte
Publicação do código fonte na Internet não é suficiente.
Recomendação: sempre que distribuir software em uma mídia, distribua o código fonte na mesma mídia ou acompanhe com uma segunda mídia com o código fonte.
Se oferecer o software para download, permita o download do código fonte nas mesmas condições.
Se não recebeu o código fonte, mas uma promessa, pode repassar o software de forma não comercial. Se fez o download onde o código fonte também estava disponível, uma promessa não foi feita, pois a distribuição foi cumprida.
Licenças "permissivas" são mais livres
Elas não garantem a liberdade de terceiros, ou daqueles que receberão o software.
Elas também têm condições, algumas delas danosas, como a cláusula de propaganda da licença BSD original.
Licenciamento na prática
Compatibilidade
Escolhendo a licença
Para projetos existentes, utilize a licença do projeto.
Em algumas comunidades, o compartilhamento entre os projetos pode ser beneficiado pela escolha de uma licença comum. A comunidade Perl, por exemplo, licencia seus projetos como o próprio Perl, que é duplamente licenciado como Artistic License e GPL1 ou superior.
Escolhendo a licença
As recomendações da Free Software Foundation são excelentes. Escolha a licença copyleft mais forte que não interfira com o propósito do projeto. Leitura recomendada.
Escolhendo a licença (por FSF)
Para backends web, escolha Affero GPLv3. O mesmo vale para aplicações finais em Javascript.
Para frameworks e bibliotecas, GPLv3 ou AGPLv3 ainda são excelentes opções quando trata-se de um software inovador.
Quando é uma substituição a algum equivalente proprietário ou não-copyleft, escolha LGPLv3.
Escolhendo a licença (por FSF)
Por fim, para um software cuja adoção é estratégica, como codecs livres, utilize Apache License 2.0. Sua grande vantagem em relação a outras licenças são os termos que impedem contribuidores e distribuidores de ameaçar com patentes.
Escolhendo a licença por compatibilidade
Se prezar por compatibilidade, considere com quais grupos de projetos espera ser compatível. Há um corpo muito grande de software licenciado como GPLv2. Portanto, não escolha licenças incompatíveis com essa. Se a escolha for por copyleft, adote GPLv2 ou superior. Se for por não copyleft, escolha MIT License.
Note, no entanto, que Apache License 2.0, é incompatível com GPLv2. Evite-a, escolhendo GPLv3.
Duplo licenciamento
Uma alternativa, em alguns casos, para ampliar a compatibilidade, é o duplo licenciamento. Vale principalmente para os casos em que as duas ou três licenças são incompatíveis entre si. Caso contrário, a de copyleft mais fraco anulará os efeitos daquela de copyleft mais forte.
Note que GPLv2 e GPLv3 são incompatíveis entre si. Licenciar como GPLv2 ou superior é uma forma de duplo licenciamento, que permite compatibilidade com as duas licenças.
Aplicando a licença em seu software
Acrescente uma nota sobre a licença no cabeçalho de todo arquivo.
Acrescente uma cópia da licença no repositório e distribuição do projeto.
Compatibilidade
Ao combinar dois ou mais software, sempre verifique suas licenças e a compatibilidade entre elas. Não é tarefa fácil, mas se uma das licenças for GPL, consulte a FSF.
Agradecimentos
FSF e Richard Stallman, pelo software livre, GPL, e GNU
W3C Brasil, pela oportunidade
Libre Planet BR (http://libreplanetbr.org/), pelo incentivo e apoio