Bruce Perens, defende uma revisão do conceito de Open Source
LoHá problemas intermináveis com licenças de código aberto e as reclamações constantes por parte dos desenvolvedores sobre o abuso de quem utiliza seus empreendimentos para projetos comerciais, são dois dos problemas que mais começaram a ter impacto na comunidade de desenvolvedores de código aberto.
Aqui no blog, Já partilhamos diversas notícias e opiniões sobre estes temas, assim como a proposta de ttransferir responsabilidades para projetos sobre vulnerabilidades que podem surgir no código que utilizam de outros projetos, bem como reclamações constantes sobre o pouco apoio financeiro, entre outros.
E agora, em notícias mais recentes, recentemente Bruce Perens, um dos autores da definição de “Código Aberto” e cofundador da iniciativa, reacendeu a chama do “post de código aberto” e pediu um repensar da ideia de uma evolução ou revisão do paradigma de desenvolvimento de software de código aberto.
Segundo Perens, as atuais licenças de código aberto não oferecem proteção suficiente e, portanto, hoje vemos cada vez mais desenvolvedores de código aberto expondo suas reclamações, É por isso que propõe um novo modelo isso inclui condições contratuais para melhorar as relações entre incorporadores e empresas comerciais.
“Em primeiro lugar, as nossas licenças já não funcionam”, disse ele. “Tivemos tempo suficiente para que as empresas encontrassem todas as lacunas e, portanto, precisamos de fazer algo novo. A GPL não está agindo como deveria quando um terço de todos os sistemas Linux pagos são vendidos com uma evasão da GPL. Esse é RHEL.
Bruce Perens destaca que a Licença Pública Geral (GPL) foi originalmente concebida apenas como uma licença e não como um contrato, permitindo que as empresas contornassem seus requisitos e limitassem a redistribuição do código-fonte. Perens sugere um novo modelo que incorpora elementos contratuais para resolver essas lacunas legais e desta forma garantir ou forçar (basicamente) aqueles que abusam dele, a realizar a ação retroativa correta para os desenvolvedores de software de código aberto.
«O que vem depois do código aberto deveria ter outro nome. Você nunca deve tentar se passar por código aberto.” Ele ainda está procurando um termo mais apropriado do que “pós-aberto”.
Um exemplo claro o que ilustra uma situação em que as empresas, ao “utilizarem” projetos e/ou desenvolvimentos com licenças de software de código aberto, é que eles abusam de certas estratégias para limitar a redistribuição do código-fonte, apesar das disposições de licenças abertas, como a Licença Pública Geral GNU (GPL).
No caso do Red Hat Enterprise Linux (RHEL), é mencionado que os clientes assinam acordos com a Red Hat para receber suporte e atualizações. Esses acordos podem incluir cláusulas que limitam a redistribuição de dados e mencionar o direito de rescindir o contrato se as cópias instaladas e adquiridas do RHEL não corresponderem. Isso cria uma situação em que os clientes se deparam com a escolha entre a liberdade de usar o software e manter seu status como cliente da Red Hat.
Além disso, observa-se que os patches fornecidos para RHEL que eliminam vulnerabilidades se aplicam ao código GPL, dando aos usuários o direito de distribuí-los de acordo com as disposições da licença. Porém, esta distribuição pode ser percebida como uma violação do contrato com a Red Hat, o que pode levar ao encerramento dos serviços prestados pela empresa.
Este exemplo destaca como as empresas podem utilizar certas lacunas legais ou disposições contratuais para restringir a redistribuição do código-fonte, apesar das liberdades proporcionadas pelas licenças de código-fonte aberto. Este tipo de práticas pode criar tensões entre as disposições das licenças de código aberto e os acordos contratuais específicos que as empresas estabelecem com os fornecedores de software.
Nesta nova abordagem, propõe-se que as empresas paguem pelos benefícios derivados de uso comercial de software de código aberto, participando do desenvolvimento ou pagando royalties. Está sendo considerada a possibilidade de utilizar uma certificação anual, após a qual as empresas obteriam os direitos de uso do software. Os fundos transferidos estimulariam o desenvolvimento e permitiriam que os desenvolvedores gastassem tempo criando aplicativos convenientes para os usuários finais.
Entre os desafios destacados está a necessidade de estabelecer uma organização que estude as contribuições para o desenvolvimento e distribua fundos de forma transparente e justa para os promotores. A implementação bem-sucedida deste modelo pós-código aberto exigiria uma consideração cuidadosa destes aspectos organizacionais e financeiros.
fonte: https://www.theregister.com