Por aproximadamente vinte anos, a Red Hat (agora uma subsidiária integral da IBM) experimentou a construção de um modelo de negócios para implantação de sistema operacional e distribuição que parece, sente e age como proprietária, mas no entanto, está em conformidade com a GPL e outros termos padrão de direitos autorais. Ativistas de direitos de software, incluindo SFC, passaram décadas conversando com a Red Hat e seus advogados sobre como o modelo de negócios do Red Hat Enterprise Linux (RHEL) era um desastre e era ativamente hostil para Software Livre e de Código Aberto (FOSS) orientado para a comunidade. Essas súplicas, discussões e incentivos, até onde sabemos, foram ouvidos e ouvidos com seriedade pelos principais membros do departamento jurídico e da OSPO da Red Hat departamentos e até mesmo pelos principais executivos de nível C, mas acabaram sendo rejeitados e ignorado - às vezes até com uma "multa, então nos processe por violação da GPL”. Ativistas encontraram esta discussão frustrante, mas manteve a natureza e a posse dessas discussões como um “segredo aberto” até agora porque todos esperávamos que o comportamento da Red Hat melhorasse. Eventos recentes mostram que o comportamento simplesmente piorou e é provável que fique ainda pior.
O que é exatamente o modelo de negócios do RHEL?
A maneira mais concisa e concisa de descrever o modelo de negócios do RHEL é: “se você exercer seus direitos sob a GPL, seu dinheiro não é bom aqui". Especificamente, o Red Hat da IBM oferece cópias do RHEL para seus clientes, e cada cópia vem com um suporte e atualização automática em um contrato de assinatura. Como entendemos, este contrato
afirma claramente que os termos não pretendem contradizer quaisquer direitos de cópia, modificação, redistribuir e/ou reinstalar o software quantas vezes e em quantos lugares como o cliente gosta (ver §1.4). Além disso, porém, o contrato indica que se o cliente se envolver nessas atividades, a Red Hat se reserva o direito de cancelar esse contrato e não fazer mais contratos com o cliente para suporte e serviços de atualização. Em essência, a Red Hat exige que seus clientes escolher entre (a) sua liberdade e direitos de software e (b) permanecer um cliente Red Hat. Em algumas versões desses contratos que analisamos, a Red Hat ainda
se reserva o direito de “avaliar” um cliente (efetivamente um
BSA -estilo de auditoria) para examinar como muitas cópias do RHEL estão realmente instaladas (consulte §10) — presumivelmente para o propósito da Red Hat obter as informações necessárias para decidir se deve “demitir” o cliente.
Os advogados da Red Hat claramente assumem a posição de que este modelo de negócios está em conformidade com a GPL (embora não tenhamos tanta certeza), alegando que nada nos acordos GPL exige que uma entidade deve manter uma relação comercial com qualquer outra entidade. Eles argumentaram ainda que tais negócios relacionamentos podem ser encerrados com base em qualquer comportamento - incluindo exercendo direitos garantidos pelos acordos GPL. Se essa análise está correta é uma questão de intenso debate, e provavelmente apenas um caso no tribunal que contestasse esta questão em particular produziria uma resposta definitiva sobre se esse comportamento desagradável é permitido (ou não) sob os acordos GPL. Os debates continuam, ainda hoje, nos círculos de especialistas em copyleft, se esso modelo
em si viola a GPL. Não há, porém, dúvidas de que este disposição não está no espírito dos acordos GPL. O modelo de negócio RHEL é hostil, capcioso, caprichoso e digno de vergonha.
Além disso, este modelo de negócios RHEL permanece, até onde sabemos, único na indústria no setor de software. A Red Hat da IBM definitivamente merece crédito por tão cuidadosamente construir seu modelo de negócios de tal forma que passou a maior parte das últimas duas décadas em território obscuro de “provavelmente não violar a GPL”.
O modelo de negócios RHEL viola os acordos GPL?
Talvez o maior problema com um modelo de negócios obscuro que contorna o linha de conformidade GPL é que as violações podem acontecer e acontecem - desde mesmo um pequeno desvio do modelo de negócios que claramente viola a GPL. Pré-IBM, a Red Hat merece uma certa quantidade de crédito, como a SFC ciente de apenas dois incidentes documentados de violações da GPL que ocorreu desde 2006 em relação ao modelo de negócios RHEL. Nós decidimos compartilhar alguns detalhes gerais dessas violações para fins de explicar onde esse modelo de negócios pode ultrapassar os limites com tanta facilidade.
Na primeira violação, uma grande empresa da Fortune 500 (que vamos chamar
de Empresa A ), que usaram o RHEL internamente e também construíram produtos baseados em Linux voltados para o público, decidiu criar um produto (que chamaremos
de Produto P ) baseado principalmente no CentOS Linux, mas
P incluiu alguns pacotes construídos a partir de fontes RHEL.
Empresa A não procurou nem solicitou serviços de suporte ou atualização para este separado
Produto P. A Red Hat mais tarde tomou conhecimento de que
o Produto P continha alguma parte do RHEL, e a Red Hat exigiu pagamentos de royalties pelo
produto P. A Red Hat ameaçou revogar o suporte e atualizações de serviços nos
servidores RHEL internos da Empresa A se tais royalties fossem pagos.
Como
a Empresa A era poderosa e tinha bons advogados e equipe de desenvolvimento de negócios, eles não concordaram.
Empresa A em última análise continuou (até onde sabemos) como cliente RHEL para seus servidores e continuou vendendo
o Produto P sem pagamento de royalties. No entanto, um a demanda por royalties para distribuição é claramente uma violação, pois essa demanda cria um “restrição adicional” nas permissões concedidas pela GPL. Como declarado na GPLv3:
Citar:Você não pode impor quaisquer outras restrições ao exercício do direitos concedidos ou afirmados sob esta Licença. Por exemplo, você pode não impor uma taxa de licença, royalties ou outro encargo pelo exercício de direitos concedidos sob esta licença.
A Red Hat tentou impor uma restrição adicional nesta situação e, portanto, violou a GPL. A violação foi resolvida, pois nenhum royalty foi pago e
a Empresa A não enfrentou consequências. A SFC soube do incidente mais tarde, e informou a Red Hat que a demanda anterior de royalties foi uma violação. A Red Hat não contestou nem concordou que era uma violação e concordou informalmente tais exigências não seriam feitas no futuro.
Em outro incidente de violação, descobrimos que a Red Hat, em um determinado país fora dos EUA, estava exigindo que qualquer cliente que diminuísse o número de máquinas RHEL sob contrato de serviço com a Red Hat assinam um acordo adicional. Este acordo adicional prometia que o cliente deletaria todas as cópias do RHEL em toda a organização, exceto o cópias do RHEL atualmente contratadas para serviço com a Red Hat. Novamente, esta é uma “restrição adicional”. Os acordos GPL dão a todos o direito irrestrito de fazer e manter tantas cópias do software como quiserem, e um distribuidor de software GPL pode não exigir de um usuário atestar que excluiu essas cópias legítimas e licenciadas de software licenciado por terceiros sob a GPL. A SFC informou o departamento jurídico da Red Hat desta violação, e nos foi assegurado que este acordo adicional não ser apresentado a qualquer cliente da Red Hat no futuro.
Em ambas as situações, nós da SFC estávamos preocupados que eles fossem apenas um “ponta do proverbial do iceberg”. Durante anos, ouvimos de clientes da Red Hat que eles estavam realmente confusos. É comum na indústria falar sobre “licenças por estação RHEL” e muitos especialistas em aquisições de software do setor não estão cientes das nuances do modelo de negócios RHEL e não entendem seus direitos. Nós permanecemos muito preocupado com o fato de os vendedores da RHEL confundirem propositalmente os clientes para vender mais “licenças por estação”. Muitas vezes nos leva a perguntar: “Se uma licença violação GPL acontece no mato, e todos os envolvidos não ouvem, como alguém sabe que os direitos de software foram de fato pisoteados naquelas matas?”. Assim como fazemos com o maior número possível de relatórios de violação da GPL, perseguimos zelosamente as violações da GPL relacionadas ao RHEL que são relatados para nós, e se você estiver ciente de um, por favor envie- [email='
[email protected]'] nos um e-mail para [/email]
[email protected] imediatamente. Tememos que seja por incompetência ou malícia, muitos vendedores e empresários profissionais de desenvolvimento da RHEL podem violar regularmente a GPL e ninguém sabe isto. Dito isso, o modelo de negócios
conforme descrito pelo Red Hat da IBM pode estar em conformidade com a GPL - é tão obscuro que qualquer ajuste para o modelo em qualquer direção parece definitivamente violar, em nossa experiência.
Além disso, a Red Hat explora o clássico “caveat emptor” abordagem - popular em muitos negócios obscuros ao longo da história. Enquanto, tecnicamente falando, um leitor cuidadoso dos acordos GPL e RHEL entende a barganha que está fazendo, suspeitamos que a maioria das pequenas empresas simplesmente não tem a perspicácia e o conhecimento de licenciamento da FOSS para realmente entender aquele negócio.
Por que um CentOS independente era tão importante?
Até
“aquisição” do CentOS pela Red Hat no início de 2014 , CentOS forneceu um excelente contrapeso para os problemas com o modelo de negócios RHEL. Especificamente, o CentOS era um projeto voltado para a comunidade, com muitos voluntários, apoiados por algum envolvimento de pequenos negócios, para recriar versões do RHEL usando as fontes feitas para o RHEL. Nossa visão pré-2014 era que o CentOS era o “canário em a mina de carvão escura” do negócio RHEL. Se o CentOS parecia vibrante, utilizável e uma alternativa viável ao RHEL para aqueles que não queriam adquirir as atualizações e serviços da Red Hat, a comunidade poderia ficar tranquila. Mesmo que houvesse violações da GPL pela Red Hat no RHEL, a vitalidade do CentOS asseguraria de que tais violações estavam tendo apenas um pequeno impacto negativo sobre a comunidade FOSS em torno da base de código do RHEL.
A Red Hat, no entanto, aparentemente sabia que essa comunidade vibrante estava cortando em seus lucros. A partir de 2013, a Red Hat iniciou uma série de ações que aumentaram sua aderência. Primeiro, eles “adquiriram” o CentOS. Isso foi inicialmente formulado como um acordo de cooperação, mas a Red Hat fez ofertas de trabalho sistematicamente aos principais voluntários do CentOS que não podiam recusar, adquiriu as pequenas empresas que podiam transformar o CentOS em um produto e, de outra forma, integrou o CentOS nas próprias operações da Red Hat.
Depois que a IBM adquiriu a Red Hat, a situação piorou. Tendo obtido direitos à marca CentOS como parte da “aquisição”, a Red Hat lentamente começou a mudar o que era o CentOS. O CentOS Linux rapidamente deixou de ser um check-and-balance no RHEL e acabou de se tornar um campo de testes para o RHEL. Então, em 2020, quando a maioria de nós estava distraída com o pior da pandemia do COVID-19, a Red Hat encerrou unilateralmente todo o desenvolvimento do CentOS Linux. Mais tarde (durante a parte da variante Delta da pandemia no final de 2021)
a Red Hat encerrou o CentOS Linux inteiramente .IBM Red Hat então usou o nome “CentOS Stream” para se referir a pacotes de origem relacionados ao RHEL. Estes não eram (e não são) realmente o RHEL originalmente - em vez disso, eles parecem ser principalmente um teste base para o que pode aparecer no RHEL mais tarde.
Finalmente, a Red Hat anunciou há dois dias que
as fontes do RHEL não estariam mais disponíveis publicamente. Agora, para ser claro, os acordos GPL não obrigam a Red Hat a fazer sua fontes publicamente disponível para todos. Este é um equívoco comum sobre os requistiso GPL. Embora os detalhes do provisionamento das fontes variem em diferentes versões dos acordos GPL, o princípio geral é que as fontes precisa ser fornecidas junto com as distribuições binárias para aqueles que receberem, ou (b) para aqueles que solicitarem de acordo com uma oferta por escrito para a fonte. Numa situação normal, sem atenuantes, o fato de uma empresa passou de distribuir fontes publicamente para todos para apenas darem para clientes que já receberam os binários, não aumentariam preocupações.
Nesta situação, no entanto, isso completa o que parece ser uma plano de uma década da Red Hat para maximizar o nível de dificuldade de aqueles na comunidade que desejam “confiar, mas verificar” que o RHEL está em conformidade com os acordos GPL. Ou seja, a Red Hat frustrou gravemente esforços de entidades como
Rocky Linux e
Alma Linux . Essas entidades são de fato os sucessores intelectuais de Projeto CentOS Linux que a Red Hat desmontou cuidadosamente na última década. Essas organizações procuraram construir distribuições baseadas em Linux que espelhassem os lançamentos RHEL, e agora não está claro se eles podem fazer isso de forma eficaz, já que a Red Hat, sem dúvida, se recusará caprichosamente a vender a eles exatamente um serviço RHEL e atualizar a “licença por estação” a um preço razoável. Parece que, a partir desta semana, é preciso ter pelo menos isso para obter acesso oportuno as fobtes RHEL.
O que aqueles que se preocupam com os direitos de software devem fazer sobre o RHEL?
Devido a esse mau comportamento contínuo da Red Hat da IBM, a situação torna-se cada vez mais complexa e difíceis de enfrentar. Nenhum terceiro pode monitorar efetivamente a conformidade do RHEL com os acordos GPL, uma vez que os clientes vivem com medo de perder seus tão necessários contratos de serviço. O Departamento jurídico da Red Hat recusou sistematicamente os pedidos da SFC nos últimos anos para estabelecer alguns forma de monitoramento pelo SFC. (Por exemplo, pedimos para revisar o treinamento materiais e documentos que os vendedores da RHEL recebem para convencer clientes a comprar RHEL, e a Red Hat não está disposta a compartilhar esses materiais conosco.) No entanto, uma vez que o SFC atua como o cão de guarda global para Conformidade com a GPL, [email='
[email protected]'] recebemos relatórios [/email] de violações relacionadas ao RHEL.
Finalmente expressamos nossa tristeza por este longo caminho ter levado a comunidade FOSS a um lugar tão decepcionante. Lembro-me pessoalmente de estar com Erik Troan em um estande da Red Hat em uma conferência USENIX no final dos anos 1990 e conhecendo Bob Young na mesma época. Ambos expressaram o quanto gostariam de construir uma empresa que respeitasse, colaborasse, se envolvesse e, acima de tudo, fosse tratado como igual para todo o espectro de indivíduos, amadores e pequenas empresas que fazem o pluralidade da comunidade FOSS. Esperamos que o a Red Hat moderna passa encontrar seu caminho de volta para esta missão sob o controle da IBM.
