A Red Hat limitou o acesso ao código-fonte do RHEL. Qual a real consequência dessa mudança?
3 curtidas
Por mais que possam haver justificativas técnicas e operacionais, quando chega nesse ponto, qual o sentido de fazer software livre ? Se as pessoas tem dificuldade de acessar o código fonte e mesmo quando tem acesso são proibidas de redistribuir, todo o sentido de se fazer software livre e aberto se perde na minha opinião.
1 curtida
Ainda existem vários sentidos para se produzir software aberto e livre. Por exemplo, é graças ao movimento do código aberto e livre que ainda podemos usar o código-fonte do CentOS Stream para fazermos algum projeto nosso se assim desejarmos; é graças ao movimento do código aberto e livre que a Red Hat contribui em vários dos softwares que utilizamos. Por aí vai…
Antes de mais nada eu discordo que alguém pegue todos os seus pacotes, redistribua-os por aí e depois faça uma parceria com a NASA graças a isto. O que eu acabei de relatar foi o que aconteceu com o Rocky Linux. O que o Rocky Linux fez para merecer tantos créditos? Eu gostaria de saber, pois essa distro é literalmente o RHEL com uma etiqueta diferente.
Eu gostaria de lembrar que o RHEL não é livre, ele é pago.
Se essa é uma preocupação, deviam fazer software proprietário, o direito de redistribuição é um dos fundamentos do software livre, sem isso não faz sentido. É como se o Debian quisesse limitar a Canonical de redistribuir os pacotes deles no Ubuntu ou o Arch Linux limitar a redistribuição dos pacotes deles pelo SteamOS. Não é essa a lógica do software livre, você acaba com todo o ecossistema de software que existe ao seu redor.
Não importa se é pago ou não, me refiro a licença do software, tanto que até pouco tempo publicavam o código fonte.
1 curtida
Você está quase praticamente colocando software aberto como sinônimo de software livre, mas não é assim que as coisas funcionam. O direito de redistribuição é um fundamento do software livre, portanto não se aplica ao RHEL por este não ser livre.
O Debian e o Arch Linux são projetos da comunidade e sempre foram livres. Eles e a Red Hat são coisas totalmente diferentes.
A Red Hat não feriu qualquer licença de software porque ela disponibilizará tudo que deve ser público através do CentOS Stream, que é o upstream do RHEL.
Esse fundamento de que falo, não é apenas algo filosófico, mas se encontra justamente nas licenças de código aberto, se você utiliza GPL, por exemplo, você não pode impedir a redistribuição do software, não importa se é pago ou não.
Não são.
Não tenho como entrar nesse mérito.
A GPL confere o direito de redistribuição a quem recebe o software. No caso da Red Hat, quem recebe o software são os seus clientes. Sim, os clientes têm o direito de fazer o que quiserem com o código-fonte do RHEL. Entretanto, a Red Hat inclui em seus contratos que quem redistribuir o código-fonte perderá o direto ao suporte, logo, não receberá futuras atualizações. Juridicamente falando isso é legal.
Me explique como uma empresa que tem uma distro não livre é igual a dois projetos da comunidade que são livres.
1 curtida
Não tenho como entrar no mérito do que é juridicamente correto ou não, mas é algo pelo menos contraditório.
O que existe de fundamentalmente diferente em termos de composição de software entre Debian, Arch e RHEL ? Tirando as versões de pacotes e downstream patches ? O mesmo trabalho que a Red Hat faz com os pacotes do RHEL, as comunidades do Debian e do Arch também fazem com os seus e outros projetos pegam seus pacotes e redistribuem por aí, não entendo a relevância de ser empresa ou comunidade.
É uma decisão estranha para aquilo que estamos acostumados, mas devo dizer a você que eu não faço questão alguma de ter acesso ao código-fonte do RHEL. Se a Red Hat não quer que usemos o que é dela, beleza! Há outras sei lá quantas distros que nos querem como usuários. Não insistamos em querer usar de graça aquilo que não é grátis.
O Debian e o Arch Linux foram feitos para serem usados por todos, então restringir o acesso ao código-fonte seria ir contra os próprios objetivos dessas duas distros. Já o RHEL foi feito para ser usado por quem paga por ele.
Licenças GPL não funcionam assim, se a RHEL mantiver o Software apenas dentro de suas instalações, Ok, o problema é que ela vende o binário resultante das modificações do sistema (que obviamente não estão no Cent OS Streaming) sem liberar o source isso é uma violação direta da GPL, não tem essa de “tudo o que deve ser público”, o que acontece é, se é GPL tudo deve ser público, o direito de suporte pode ser cortado, porém se eu, você ou o Super OS Que Quer Clonar o RHEL quiser comprar mensalmente o suporte e redistribuir o código legalmente a RHEL não pode fazer nada, tanto pela GPL, tanto pelas leis de mercado dos EUA, piora mais se a empresa comprar o pacote de suporte pelo Brasil, em outras palavras: a RHEL pode cobrar pelo código, pode cortar o suporte se a pessoa compartilhar o código, mas não pode fazer tratamento diferencial e a pessoa pode fazer compra recorrente dos repositórios do código fonte e ela quer limitar isso é aqui que está o problema
3 curtidas
dura lex, sed lex: o que é propriedade dela, pode usar a licença que quiser. e deve respeitar as dos demais apps que ela usa mas não produz. não conheço detalhes, mas a GPL refere-se apenas ao código fonte? acho que binários está “fora do combinado”. ela é obrigada a disponibilizar binários de software livre que ela compilou? acho que não.
O binário não, mas o fonte sim
Em outro comentário eu falei que a Red Hat não pode impedir a redistribuição se algum de seus clientes quiser fazer isso. Como a pessoa perde o suporte se fizer isso, não há sentido em redistribuir os pacotes já que ela não terá acesso às atualizações futuras. Não vejo esse código-fonte como público porque não é todo mundo que pode ter acesso a ele, mas se você pagar, você tem acesso.
Ja atualizaram o status, Oficialmente “closed source”
Se você pegar uma das licenças grátis ou pagar pelo RHEL, você tem acesso ao código-fonte, então ainda é código aberto. Código aberto esquisito, mas ainda é código aberto.
Bom dia.
O que vocês vão fazer ?
Estamos pensando em migrar para o Debian.
A questão é a licença se fosse apenas software da RHEL ok, justo, o problema é software GPL no meio, inclusive software GPLv3
1 curtida
Vou esperar e ver como o Alma e o Rocky vão ficar daqui pra frente.
Uma análise abrangente dos problemas de GPL com o modelo de negócios do Red Hat Enterprise Linux (RHEL)
Este artigo foi originalmente publicado principalmente como uma resposta para a mudança da Red Hat por não mais publicar por completo, a fonte correspondente para RHEL e o prévia descontinuação do CentOS Linux (que são eventos relacionados, como descrito abaixo). Esperamos que isso sirva como um documento que discute a história do modelo de negócios RHEL da Red Hat, o fornecimento de código-fonte relacionado e os problemas de conformidade GPL com RHEL.
Artigo completo
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:
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- nos um e-mail para compliance@sfconservancy.org 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, recebemos relatórios 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.
5 curtidas
A GPL obriga que a Red Hat forneça o código-fonte apenas a quem recebe os binários. A Red Hat não é obrigada a deixar o código-fonte disponível para todo mundo.