Comercialização de melhorias de software livre sob licenças Copyleft

Planejei começar este artigo com informações de que sempre há dificuldades significativas ao tentar comercializar as melhorias do software livre e citar a situação com o projeto Redis como um exemplo ilustrativo.

Mas então percebi que a situação com o Redis ( Redis está alterando sua licença novamente ) como exemplo não é muito adequada. E não apenas por causa da mistura infernal de várias licenças usadas no projeto, mas também por causa de confusão adicional resultante da interpretação dos termos Código Aberto e Software Livre.

Além disso, a julgar pelos resultados do trabalho dos provedores de nuvem no último trimestre de 2019, e esse negócio é baseado principalmente em software livre, isso encerra a questão de pelo menos uma maneira realmente eficaz de comercializar software livre.

Afinal, os números falam por si. A receita total de provedores de nuvem no último trimestre de 2019 ultrapassou US $ 30 bilhões . Entre eles, o líder é a Amazon (32,4% do mercado), o Microsoft Azure é quase a metade (17,6%), seguido pelo Google Cloud (6%) e Alibaba Cloud (5,4%).

No entanto, para empresas menores, esse negócio geralmente não é viável. Portanto, para eles, a questão da comercialização de aprimoramentos de software livre sob licenças da Copyleft (como a GPL) pode ser bastante relevante.
Trago à sua atenção uma maneira prática de comercializar modificações de software livre sob licenças da Copyleft, inclusive com relação à legislação da Federação Russa.

De que licenças estamos falando?


Este artigo é sobre software livre, no sentido que a Free Software Foundation (FSF) coloca nele.

Seus princípios são formulados por quatro liberdades:

  • Liberdade 0: Execute o programa para qualquer finalidade.
  • Liberdade 1: Estudar o programa e alterar seu trabalho para atender às suas necessidades. *
  • Liberdade 2: Distribua cópias do programa. **
  • 3: .*

*) As liberdades 1 e 3 exigem a disponibilidade do código-fonte do programa, que deve estar disponível para estudo e alteração. É justamente por isso que muitas vezes surge confusão, uma vez que Código Aberto significa exatamente código de código aberto, enquanto o conceito de Software Livre se refere a direitos de software e para os quais a presença do código fonte de um programa é obrigatória, mas não o único requisito.

**) O Freedom 2 permite a distribuição gratuita do programa e, por isso, também existe confusão com o termo Freeware , que significa apenas um programa gratuito, mas pode se referir a qualquer programa, não necessariamente gratuito.

Assim, a idéia do Software Livre é fornecer ao usuário as informações apropriadasdireitos ao software que o detentor dos direitos autorais garante a cada usuário.

Um princípio semelhante é chamado Copyleft , que exige a preservação de liberdades em trabalhos derivados e proíbe sua redução em comparação com o produto de software original.

Em linguagem legal, isso é formulado na GPL (GNU General Public License), que exige que o autor de um trabalho derivado preserve (não reduza) liberdades em comparação com o programa original.

É por causa da preservação das liberdades originais que essas licenças são chamadas de "aderentes" ou "virais".

Qual é o problema de comercializar a GPL?


Problema 1


O principal problema com a comercialização de software sob a GPL é que o primeiro cliente que recebe o programa ou suas fontes tem o direito de se tornar o distribuidor desse programa e o desenvolvedor não pode impedi-lo de nenhuma maneira: www.gnu.org/licenses/gpl-faq. ru.html # DoesTheGPLAllowNDA , www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowModNDA

E como qualquer usuário oficial pode obter a fonte, qualquer usuário pode postar o software recebido ou sua fonte gratuitamente e com acesso gratuito. Isso certamente criará problemas com o retorno das finanças investidas no desenvolvimento de um produto de software.

Não existe esse problema para licençaslicenças como BSD, MIT ou Apache. Eles permitem a redução de liberdades em produtos derivados, portanto, basta alterar a licença gratuita original para proprietária (proprietária) e não abrir o código-fonte do software para o usuário (cliente).

Problema 2


A segunda dificuldade na construção de um negócio em software de código aberto com licenças virais é que a total liberdade no gerenciamento dos direitos de um produto de software pertence apenas ao proprietário, o que é completamente lógico.

E somente o detentor de direitos exclusivos do programa pode usar o modelo de licenciamento duplo, o que implica uma licença comercial “não-gratuita” para software para clientes corporativos e uma licença compatível com GPL para representantes da comunidade.

Mas esse esquema não é adequado para projetos secundários (os chamados "garfos") ou projetos dedicados à criação de módulos adicionais que devem trabalhar em conjunto com o código GPL e, portanto, também devem ter uma licença compatível com GPL.
O método de comercialização de aprimoramentos de software livre proposto abaixo permite contornar os problemas descritos acima. É adequado para:

  • Licenças virais, como a GPL.
  • Comercialização de melhorias de software quando o desenvolvedor não possui direitos exclusivos sobre o produto de software.

Quando o valor comercial aparece?


De acordo com as explicações da Free Software Foundation (FSF), a GPL permite a distribuição paga dos programas www.gnu.org/philosophy/selling.html , www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowMoney .

Ao mesmo tempo, a GPL não impõe ao desenvolvedor a obrigação de publicar suas melhorias ao público em geral: www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic

Isso torna teoricamente possível o modelo de negócios de retorno do investimento em software de código aberto devido à sua distribuição paga, quando o valor comercial é criado através da propriedade exclusiva do produto de software, mais precisamente, limitando a disponibilidade de sua versão atual para uma ampla gama de usuários. De fato, isso é uma repetição do modelo de negócios de software proprietário com base na propriedade exclusiva do recurso.

Em outras palavras, você deve fazer temporariamente o segundo atraso entre o direito do cliente de distribuir mais a transferência do software para o cliente e o advento do software adquirido sob a licença GPL.

De fato, é a BP ,Restrição variável da liberdade de distribuição, conforme caso contrário, simplesmente "a economia não funcionará", porque a condição para a presença de demanda pelo produto será a falta de disponibilidade de análogos mais baratos (ou gratuitos) no mercado.

Criando um temporário no segundo atraso com base nas condições da licença


A primeira opção é a criação de temporário sobre o segundo atraso entre a transferência do software para o cliente e a aparência de seu direito a uma disseminação adicional das melhorias adquiridas, com base na criação das condições necessárias de acordo com a interpretação da cláusula da GPL por parte da Free Software Foundation.

Isso é possível ao transformar o comprador do produto de software em um (co) desenvolvedor: www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA

Para fazer isso, basta assinar um contrato com o comprador (cliente) em seu trabalho, por exemplo, como testador de produtividade. dados, que devem incluir um acordo sobre a não distribuição de cópias do produto de software durante a vigência deste contrato.

O esquema de interação do desenvolvedor com o usuário:

  1. «» .
  2. (-) , , .
  3. FSF . www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA
  4. .

GPL


A segunda maneira de criar um tempo no segundo intervalo entre a transmissão do cliente e a aparência do software em seu legítimo direito a sua propagação adicional é possível devido ao fato de que os direitos ao programa criados pelo pedido do computador e, consequentemente, a possibilidade de sua propagação no cliente somente após a conclusão cumprimento de suas obrigações pelas partes no acordo sobre a conclusão do software.

O esquema de interação com a empresa usuária:

  1. O desenvolvedor faz um acordo com a empresa usuária para finalizar o produto original relacionado ao software livre com uma licença de vírus.
  2. , ( 712. ; 1296. , ).
  3. () - . , .. .
  4. , .

?


Esses esquemas de trabalho foram propostos à comunidade em 2014 em várias conferências, mas antes disso, os autores contataram Richard Stallman para descobrir sua opinião sobre esses métodos de comercialização da GPL.

Obviamente, ele não estava entusiasmado, porque nesse esquema há uma violação temporária, mas ainda assim, das liberdades originais: Liberdade 2: Distribuir cópias do programa e Liberdade 3: Melhorar o programa e publicar essas alterações ou todo o código do programa.

No entanto, ele teve que concordar que o primeiro método com um (co) desenvolvedor não violaria a GPL, a menos que o trabalho do usuário fosse fictício. Em outras palavras, o usuário deve realmente trabalhar de acordo com as obrigações contratuais e esse trabalho deve ser realmente pago.

No segundo método, Richard Stallman acredita que o esquema viola a GPLv3, que afirma explicitamente que a licença tem precedência sobre as obrigações contratuais. No entanto, os advogados não concordam com isso, uma vez que a licença "começa a funcionar" somente após a transferência de direitos ao resultado do trabalho. Portanto, quem quer que seja o resultado de direitos só pode mostrar prática judicial real.

Finalmente


A criação de quaisquer restrições à distribuição de Software Livre é sempre percebida como "hostil" pela comunidade, mesmo que essas restrições obedeçam totalmente aos termos da licença, não contrariem a lei e ajudem no desenvolvimento de projetos livres.

Por outro lado, a falta de uma maneira normal de comercializar código sob a GPL limita significativamente a atração de investimentos e seu desenvolvimento, porque Os métodos normais de comercialização estão disponíveis apenas para proprietários de direitos exclusivos ao código fonte.

Como resultado, os desenvolvedores são forçados a se envolver em negócios não essenciais ou a usar as técnicas de desvio de licença da GPL para trabalhar com um modelo de negócios de software proprietário baseado na propriedade exclusiva do objeto de direitos autorais.

Espero que este material ajude alguém a construir um negócio usando software livre.

Autores: Alexander Ryabikov, Sergey Sereda, Ph.D.

Baseado em materiais da conferência:
Open Source Summit
LVEE 2014
Eu ficaria muito feliz em ter algum comentário sobre sua experiência na comercialização de software livre com licenças da Copyleft.

All Articles