Na postagem de hoje falaremos sobre licenciamento de software, algo que particularmente demorei muito tempo pra entender e procurar, porque ninguém nunca falou sobre isso diretamente pra mim, portanto nessa postagem me dedicarei em mostrar os pontos principais sobre licenças e como você pode tá quebrando a lei naquele seu projetinho de domingo.
Se você não sabe o que é ou acha que licenças são meramente ilustrativas, você pode ter um problema nas mãos. A licença define como aquele código pode ser usado, distribuído e incorporado em outros projetos e diga-se de passagem que diversos códigos de fóruns e documentações internet a fora são protegidos por alguma licença, então é uma péssima ideia você apenas sair copiando código alheio da internet, você pode se ferrar depois.
Não é necessário raciocinar muito pra descobrir que quebrar uma licença é a mesma coisa que quebrar propriedade legal e pode te render um processo custoso e dependendo do seu caso uma demissão também.
Então pra você não ser pego de surpresa depois, abaixo temos uma lista completa de tipos de licenças:
EULA (End User License Agreement): esse é um dos tipos mais comuns de licença de software, ele geralmente é empregado em aplicativos comercializados definindo regras de distribuição e modificação. Além de geralmente determinar algumas isentabilidades para empresa, como: se o software der problema na sua máquina a empresa ser isenta - e também delimita ações legais caso o usuário desrespeite a licença.
Proprietário: licenças do tipo proprietário são extremamente fechadas, não se é possível editar, redistribuir ou modificar sem permissão do desenvolvedor e ao descumprir a licença o desenvolvedor tem a permissão de tomar medidas jurídicas contra você.
Livre ou aberto: estas são as famosas licenças open-source que são abertas a comunidade usar, editar e modificar, obviamente dentro das condições impostas pela licença utilizada, falaremos sobre as licenças open-source a seguir. Há uma pequena diferença entre os dois, o livre se diz respeito a questões éticas também e o aberto não, é apenas questões técnicas.
Freeware: este é um pouco mais obvio, um software pode ser gratuito mas não quer dizer que seu código seja aberto ou livre, ele ainda tem uma licença e um contrato que deve ser respeitado para se evitar problemas jurídicos.
Agora que você conhece todos os tipos de licenças de software, vamos conhecer as licenças de software open-source e suas condições, que são várias e escondem diversas armadilhas que você pode cair:
GNU General Public License, version 3 (GPLv3): eu pessoalmente uso essa licença em quase todos meus projetos pessoais, ela garante segurança ao desenvolvedor e ao mesmo tempo mantém o código aberto a todos.
E nessa licença preciso criar um alerta: todos os arquivos do projeto que entrarem em contato com essa licença devem se tornar abertos também, por isso empresas, no mínimo, evitam usar GPL.
As condições dela são belíssimas pegadinhas portanto preste atenção:
Toda distribuição que você fizer de um software baseado nessa licença deve ser pública também. Ou seja se você editar um software e redistribui-lo este código deve ser público.
Toda alteração no código deve ser documentada.
Modificações no software devem se manter na mesma licença.
Se material patenteado for usado na criação do software os usuários terão permissão de usá-lo também.
Apache License 2.0:a licença Apache é um pouco mais aberta, até porque alguns softwares da Apache estão sobre essa licença e eles tem milhares de usuários com diferentes propósitos, então poderia ser um tiro no pé ser muito restritivo.
Vamos ver as suas condições:
A distribuição de software não precisa necessariamente ser pública.
Modificações podem usar licenças diferentes.
Toda alteração no código deve ser documentada.
Proíbe explicitamente o uso de nomes de marcas registradas encontradas no projeto.
Segue a condição 4 do GPLv3.
Berkeley Software Distribution (BSD): esse definitivamente você já deve ter ouvido falar, ele possui duas versões principais: 2-clause e 3-clause, vamos ver suas condições:
Segue as mesmas condições 1 e 2 do Apache License 2.0.
Alterações no software não precisam ser documentadas.
Nenhuma posição em relação a uso de material patenteado.
A licença e os direitos de uso precisam ser incluídos na documentação do software final.
Na versão 3-clause é proibido o uso de nomes de autores ou contribuidores do projeto em softwares derivados afim de promover a modificação.
MIT: essa definitivamente é a licença mais aberta de todas que vimos aqui, não precisa de lista para citar as diferenças, a distribuição de software não precisa ser pública, as alterações não precisam ser documentadas, ela não tem posição em relação ao uso de material patenteado e as alterações não precisam ser documentadas.
GNU Lesser General Public License (LGPL): a versão reduzida da GPL muda algumas condições, você agora pode trocar a licença de LGPL para GPL e os outros arquivos do seu projeto (que não são GPL) não precisam se submeter a licença.
Essas são as principais licenças open-source e agora você conhece elas de cabo-a-rabo, mas ainda não acabou, vamos falar sobre mais uma licença, que na verdade não é uma licença, é a falta dela:
Projetos sem declaração de licença: as licenças geralmente se dividem em 3 usos: o comercial, o estudantil e o pessoal, cada um desses casos tem suas condições próprias definindo até que ponto aquele material pode ser usado, agora pense num projeto que não há declaração de licença, você nunca saberá se o que você está usando é OK, portanto tome muito cuidado ao aproveitar de materiais que não tenham declaração.
Na teoria um projeto sem declaração não tem nenhuma condição a ser cumprida, mas e quando tiver? O que fará? Pode ser que seu trabalho todo esteja em risco por causa de uma mudança, além do fato de não ter uma licença declarada não ser uma revogação de direitos, os direitos ainda são do autor.
Agora digamos que você tem um projeto sob qualquer uma das licenças, é possível alterar ela posteriormente? Sim, é possível você alterar uma licença sempre que achar necessário, porém há um detalhe a se levar em consideração, as versões posteriores a nova devem continuar na licença que estavam.
Exemplificando: se você lançar uma v2.0 de código proprietário, a sua v1.9 com licença GPL deve se manter na licença que estava.
E agora vamos chegando mais perto do final da postagem, onde falaremos sobre ser empregado na área de desenvolvimento de software e como fica a propriedade legal dos seus códigos. Tudo que eu falar a partir de agora depende muito do seu contrato de trabalho, portanto não leve tudo ao pé da letra, se você não souber ao certo as definições do seu contrato de trabalho vale a pena procurar se informar.
Não deve ser surpresa pra ninguém que os códigos que você fizer em horário de trabalho (vulgo horário comercial) são de propriedade legal da empresa que te contratou, isso significa que por mais que você tenha feito o código ele não te pertence, ou seja você de forma alguma pode reutilizar ele em outros projetos não vinculados a empresa.
Porém o que você pode não saber, é que os seus códigos feitos em horário de lazer podem acabar se encaixando como propriedade legal do seu empregador, isso não é uma verdade geral e pode ir de contrato pra contrato, mas há sim a possibilidade que o seu passa tempo favorito seja propriedade legal do seu empregador.
E vamos mais longe, se seu empregador achar melhor ele pode pedir para que você dê fim ao seu projeto pessoal e os motivos podem até variar, como sendo algo considerado competição ou apenas eles não curtirem a proposta.
Eu volto a alertar, não reutilize códigos proprietários e cuide de entender muito bem o seu contrato de trabalho para não ter que perder seu esforço ou tomar um processo.
Acho que falei tudo que tinha que falar sobre este assunto por agora, espero que eu possa ter te ajudado a não perder um projeto e espero que a partir de agora você dê mais importância para as licenças que você usa diariamente.
Caso tenha encontrado algum erro na postagem peço que de forma respeitosa se dirija-se ao campo de comentários para me corrigir, se confirmado arrumarei o post em até 72h. Se tiver algo interessante a falar e compartilhar peço que use o campo de comentários também.
Agradeço a paciência, até mais!
Comments