- A mudança nas condições de fornecimento do código-fonte do RHEL deve ser vista dentro da longa história de Unix, GNU, Linux e IBM, e a posição da IBM/Red Hat é que continuam cumprindo o princípio da GPL de “fornecer o código-fonte a quem recebe os binários”
- No início, o software era criado e compartilhado por pesquisadores e usuários conforme a necessidade, mas a partir dos anos 1980 direitos autorais e licenças foram reforçados, separando EULA, contratos de código-fonte, licenças permissivas e GPL
- GNU e Linux cresceram com código aberto e contribuições da comunidade, e a IBM fortaleceu a confiança no ecossistema ao anunciar um investimento de 1 bilhão de dólares em Linux, contratar desenvolvedores e enfrentar o processo da SCO
- O RHEL é um produto de servidor corporativo que usa o Fedora como base de experimentação, e a Red Hat busca recuperar via licenças dos clientes os custos com suporte, QA, documentação, engenharia de release e estrutura global de suporte
- Usuários de clones do RHEL podem escolher outras distribuições Linux, mas, para quem cria clones, é mais produtivo fazer uma distribuição que concorra com o RHEL do que uma simples cópia
Posição básica sobre a mudança da Red Hat
- A recente mudança nas condições de venda da Red Hat gerou controvérsia, mas o ponto central é a forma de fornecer o código-fonte aos clientes que receberam binários do RHEL
- A essência da GPL está em garantir acesso ao código-fonte e possibilidade de modificação para que quem recebe os binários possa corrigir bugs e ampliar o sistema operacional
- IBM/Red Hat entendem que fornecem aos clientes sob contrato o código-fonte e as informações necessárias para recriar os builds distribuídos, e que continuam enviando para upstream as alterações em código GPL
- É difícil reunir todos os interesses apenas sob a palavra “comunidade”, e usuários que não precisam do mesmo nível de engenharia e suporte podem escolher outras distribuições Linux
Do compartilhamento de software à era das licenças
- Por volta de 1969, programar era em grande parte algo feito por pesquisadores, professores e engenheiros para o próprio trabalho, e a profissão de “programador profissional” ainda não era comum
- Grupos de usuários como o DECUS distribuíam software escrito por clientes pelo custo de cópia, e muitos usuários publicavam seu código como Public Domain
- Na época, a aplicação de copyright e patentes a software era limitada, então, para proteger código, era preciso recorrer a segredo comercial, direito contratual e distribuição em binário
- No início dos anos 1980, com a forte aplicação do direito autoral a binários e código-fonte, os desenvolvedores passaram a precisar de licenças para explicar os direitos dados aos usuários
- Para o usuário final, surgiram as EULAs
- Para desenvolvedores, passaram a valer contratos de código-fonte separados
A base criada por Unix, BSD e GNU
- O Unix começou em 1969 no Bell Labs e depois se espalhou para universidades de pesquisa como UC Berkeley, MIT, Stanford e CMU
- O BSD Unix da UC Berkeley oferecia demand-paged virtual memory, TCP/IP nativo e um conjunto rico de utilitários, tornando-se base para vários fornecedores iniciais de Unix
- Produtos como SunOS, Ultrix e HP/UX adotaram a base BSD
- O comentário de John Lions sobre o Unix Version 6 teve sua publicação oficial bloqueada por muito tempo, mas cópias circularam e ensinaram a inúmeros programadores Unix a estrutura do kernel e a lógica do seu design
- As licenças de código-fonte do Unix da AT&T eram caras e restritivas, então algumas empresas optaram por contratos de redistribuição para vender sistemas tipo Unix apenas em binário
- Richard M. Stallman, ao se deparar com distribuições Unix fornecidas apenas em binário, passou a ver como problema o fato de os usuários não poderem fazer as modificações de que precisavam, e iniciou o projeto GNU
- O objetivo do GNU era criar um sistema operacional livre em que quem distribui binários também garanta ao destinatário o acesso ao código-fonte e a possibilidade de modificá-lo
- Primeiro foram criados softwares diretamente úteis para programadores, como emacs, suíte de compiladores e utilitários
A diferença entre licenças permissivas e a GPL
- Universidades como MIT e UC Berkeley queriam distribuir, e não vender, o código de pesquisa, mas após a aplicação de copyright passaram a precisar de licenças com condições de uso e limitação de responsabilidade
- Essas licenças mais tarde passaram a ser chamadas de licenças permissivas no open source
- O desenvolvedor pode criar distribuições apenas em binário
- Não há obrigação de revelar ao usuário final alterações feitas além do código-fonte originalmente recebido
- A GPL passou a ser entendida como uma licença restritiva que obriga que o usuário final que recebe binários possa ver também as modificações
- Houve vários mal-entendidos no início sobre a GPL
- Algumas pessoas achavam que binários criados com compiladores GNU também ficariam sob GPL
- Outras acreditavam que não era permitido vender código GPL, mas RMS contestava isso
- Empresas como Walnut Creek e Prime Time Freeware for Unix vendiam coleções de vários códigos open source em CD-ROM e DVD
A pressão no mercado Unix e a ascensão do Linux
- Fabricantes de sistemas como DEC, HP, Sun e IBM criavam sistemas operacionais tipo Unix baseados em AT&T System V ou BSD e, para isso, contratavam engenheiros, redatores de documentação, equipes de QA e gerentes de produto
- Para criar um sistema tipo Unix competitivo, cada empresa teria gasto algo na faixa de 1 a 2 bilhões de dólares por ano
- A Microsoft vendia o mesmo sistema operacional independentemente do fabricante do PC e, ao avançar para o mercado de sistemas operacionais de servidor, passou a pressionar os fornecedores de Unix
- O projeto do kernel Linux surgiu no fim de 1991 por uma combinação de fatores e, no fim de 1993, várias distribuições já estavam em fase de crescimento
- Já existia software de projetos GNU, MIT, BSD e independentes
- Havia mais informação na internet sobre o funcionamento interno de sistemas operacionais
- Internet rápida começava a chegar às residências
- Processadores de baixo custo com demand-paged virtual memory estavam se popularizando
- Houve sorte e oportunidade
- Havia um líder de projeto obstinado e carismático
- Surgiram distribuições como Soft Landing Systems, Yggdrasil, Debian, Slackware e Red Hat; algumas nasceram como distribuições comerciais, outras como projetos comunitários
Linux e o modelo de comunidade
- Um dos motivos de o Linux ter atraído atenção popular antes do BSD foi o fato de o BSD estar envolvido no processo “Unix Systems Labs Vs BSDi”
- A GPL criou um efeito dinâmico ao exigir a distribuição do código-fonte junto com os binários, e qualquer pessoa podia iniciar um projeto de distribuição sem pedir permissão, o que levou ao surgimento de centenas de distribuições
- O X Window System veio do Project Athena, do MIT, e o Kerberos também surgiu do mesmo projeto
- O desenvolvimento do X Window System saiu do MIT e do Project Athena e foi para o X Consortium, que abriu em 1993 e encerrou suas atividades em 1996
- A OSF foi criada para estabelecer padrões de código-fonte e APIs para sistemas Unix e, em 1996, se fundiu com a X/Open para formar o Open Group
- Vários consórcios começaram com muito financiamento, mas seguiram um padrão em que as empresas participantes saíam por achar que “outra empresa vai bancar isso”, fazendo o dinheiro secar
O problema da sustentabilidade no desenvolvimento FOSS
- No início do FOSS, um pequeno número de desenvolvedores trabalhava com entusiasmo para um pequeno número de usuários, muitas vezes sem remuneração
- Como o número de usuários crescia mais rápido do que o de desenvolvedores, a pressão de manutenção aumentava
- A falta de pessoas era especialmente visível em áreas “não sexy” como QA, engenharia de release, documentação e tradução
- Alguns desenvolvedores se incomodavam com o fato de outras pessoas ganharem dinheiro com código ao qual eles haviam contribuído de graça, mas a posição defendida é que empresas precisam poder lucrar com Linux para que o Linux avance rapidamente
- Com o tempo, a comunidade passou a incluir não só quem escreve código, mas também quem cuida de documentação, tradução e divulgação, e mais tarde aumentou o número de pessoas que usam apenas software gratis sem entender o software freedom
Pirataria de software e o custo do software livre
- Pirataria de software é o ato de copiar e usar ilegalmente em desacordo com a licença
- Alguns integrantes da comunidade FOSS tratam propriedade intelectual ou copyright com pouco peso, mas, sem copyright, também desaparece o controle sobre o software
- Em uma conferência no Brazil, ao dizerem que “deveriam usar Free Software”, houve quem respondesse “todo o nosso software já é free”
- Na época, quase 90% do software para desktop no Brazil era pirateado
- Nesse cenário, parte da vantagem de baixo custo do Free Software desaparece
- A avaliação é que, se todos que usam o kernel Linux pagassem apenas 1 dólar por plataforma de hardware, seria fácil sustentar a maior parte do desenvolvimento FOSS
A participação da IBM no Linux
- Dentro da IBM já havia pessoas que acreditavam em FOSS e trabalhavam em projetos no próprio tempo, e Daniel Frye buscou reuni-las numa organização interna de FOSS para impulsionar o Linux
- Lembra-se de que Lou Gerstner, da IBM, teria enviado uma carta dizendo, em essência, que antes a IBM só era open source quando havia razão de negócio, mas que no futuro só iria para código fechado quando houvesse razão de negócio
- A IBM então anunciou um investimento de 1 bilhão de dólares em Linux, o que causou grande impacto
- Depois disso, a IBM contratou desenvolvedores Linux para trabalharem em tempo integral em várias áreas ligadas ao Linux e também passou a pagar desenvolvedores em áreas como o Apache Web Server
- Cerca de um ano depois, a IBM teria recuperado o primeiro investimento de 1 bilhão de dólares e anunciado outro investimento do mesmo valor
- A IBM vendeu seu negócio de laptops e desktops para a Lenovo e adquiriu a Price Waterhouse Cooper, mudando seu foco para uma empresa de soluções de negócio
- Depois disso, as soluções de negócio não precisavam mais ficar presas apenas a hardware e software IBM
- Open Source passou a ser tratado como um elemento que permite aos provedores de soluções IBM criar soluções melhores com custo menor
O papel da IBM no processo da SCO
- A Santa Cruz Operations produzia uma distribuição Unix baseada em código da AT&T e mais tarde foi vendida para o Caldera Group
- Após mudar o nome para SCO, a Caldera adotou uma estratégia de processos alegando que o Linux continha código-fonte da AT&T e violava os termos de licença
- Grande parte da comunidade Linux via essa alegação como falsa e, com base na experiência de leitura dos contratos entre AT&T e Novell, também parecia difícil acreditar que a Santa Cruz Operations possuísse os direitos autorais sobre o código da AT&T
- IBM, Novell, Red Hat e outras empresas participaram da disputa judicial, e a conclusão resumida é que os tribunais entenderam que a SCO só poderia discutir um problema de contrato extinto com a IBM, enquanto o Linux em si não tinha problema
- Nesse processo, o fato de a Big Blue ter entrado na briga judicial deu aos fornecedores e usuários de Linux confiança de que tudo acabaria bem
O modelo de negócios da Red Hat e do RHEL
- A Red Hat começou como uma pequena empresa de Raleigh com forte capacidade técnica, mas pouca força em negócios e marketing, e Bob Young ajudou a definir políticas e direção da empresa
- Bob Young comparou a Red Hat a um “Heinz ketchup do Linux”, e a Red Hat passou a ganhar dinheiro vendendo serviços
- Com o tempo, a Red Hat concentrou-se em um negócio corporativo centrado no RHEL
- O desktop só era importante como plataforma de desenvolvimento do RHEL, e o desenvolvimento de desktop foi deixado com o Fedora
- O Fedora serve como base de teste para novas ideias que depois podem entrar no RHEL
- Os clientes do RHEL são empresas e governos que exigem ambientes “mission critical” e “always on”, muitas vezes operando não dezenas ou centenas, mas milhares de sistemas
- Esses clientes lidam com condições de serviço como MTTF, MTTR e uptime de 99,999%, além de cláusulas de penalidade, e esperam suporte de segundo e terceiro nível, não apenas atendimento inicial comum
- A Red Hat investe em suporte corporativo, QA, documentação, certificação e engenharia de release, e os clientes pagam por isso
Empresas full stack e a lógica da aquisição da Red Hat pela IBM
- O caso da aquisição da propriedade intelectual da Sun Microsystems pela Oracle é tratado como uma estratégia full-stack, com controle de hardware, sistema operacional e aplicações
- Uma empresa full-stack pode alterar a pilha inteira para beneficiar as aplicações e testar toda a pilha para encontrar ineficiências e fragilidades
- IBM e Apple são classificadas como empresas full-stack, e seus produtos, embora mais caros, encontram muitos clientes sérios dispostos a pagar esse custo
- A IBM precisava de uma solução full-stack baseada em Linux para usar em seu negócio de soluções corporativas, e o RHEL da Red Hat já tinha reputação e engenharia para soluções empresariais
Clones do RHEL e a mudança de condições da Red Hat
- Com o tempo, alguns clientes passaram a comprar apenas um pequeno número de sistemas RHEL e usar, nos demais, outras distribuições compatíveis com a Red Hat até no nível de bug-for-bug
- Isso reduzia o custo para o cliente, mas também reduzia a receita da Red Hat apesar de ela fazer o mesmo volume de trabalho, pressionando a empresa a aumentar o preço das licenças, cortar funcionários ou abandonar outros projetos
- IBM/Red Hat tomaram a decisão comercial de distribuir código-fonte e informações de build apenas para clientes que compram licenças para todos os sistemas em execução com RHEL
- Essa condição é vista como compatível com o núcleo da GPL
- Quem recebe os binários pode obter o código-fonte para corrigir bugs e expandir o sistema
- Red Hat e IBM continuam enviando para upstream as alterações em código GPL
- O compartilhamento de ideias com a comunidade mais ampla também continua
- Não se chama os desenvolvedores de clones de “freeloaders”, mas considera-se que usuários que usam clones sem devolver nada à comunidade de qualquer forma estão próximos disso
A proposta de criar concorrência em vez de clones
- Após a mudança da Red Hat, várias distribuições anunciaram que continuariam fazendo “not RHEL”, o que pode deixar ainda mais confuso para o usuário comum decidir qual distribuição usar
- Em vez de criar vários clones separados, a posição defendida é que seria melhor construir juntos uma boa distribuição única ou criar um concorrente real do RHEL
- O fato de a SuSE ter dito que investiria 10 milhões de dólares para criar um concorrente do RHEL é visto de forma positiva
- Ainda assim, não é barato montar os mesmos canais de negócio, equipes globais de suporte e estrutura de suporte corporativo
- 10 milhões de dólares podem ser apenas um ponto de partida
- Clientes do RHEL devem escolher olhando para o valor do suporte oferecido pela Red Hat/IBM e por seus parceiros de canal
- Se a IBM não quiser mais fazer negócios com clientes que compram apenas uma cópia do RHEL e operam o restante com distribuições gratuitas, esses clientes terão de buscar outro fornecedor de Linux corporativo que aceite esse perfil
Conclusão pessoal
- Jon “maddog” Hall afirma que já trabalhava com código-fonte aberto e com a entrega de código aos clientes desde antes do surgimento de Open Source, da Free Software Foundation e do projeto GNU
- Contribuições à comunidade não se limitam a escrever código, documentação ou relatórios de bug
- É possível promover o Free Software em escolas, empresas e governos
- É possível criar Linux Clubs ou ajudar em iniciativas de Upgrade to Linux
- Desde que não violem a licença, empresas podem definir suas condições de negócio, e os clientes podem aceitá-las ou recusá-las
- Há um desequilíbrio em retratar Red Hat e IBM como “más” enquanto não se observa com o mesmo rigor empresas que, com base em licenças permissivas, não garantem código-fonte ao usuário final ou oferecem apenas licenças de código fechado sem permitir clones
- Para pesquisadores, estudantes, usuários por hobby e pessoas com muito pouco dinheiro, existem centenas de distribuições Linux que até suportam arquiteturas não cobertas pelo RHEL
1 comentários
Comentários do Hacker News
Desde o fim dos anos 90, uso Red Hat Linux (no começo, Caldera Linux, um clone dos anos 90), Fedora, RHEL e seus clones (Scientific, CentOS, Rocky) pessoalmente, para ensino e no trabalho, e também os recomendei para desktops e servidores
Eu costumava dizer que, se alguém quisesse usar Linux, havia duas opções estáveis e bem suportadas: Red Hat e Debian. Mas, para mim, a Red Hat morreu recentemente. RIP
Agora não tenho certeza de que o Fedora continuará existindo como um projeto open source ativo. Se a IBM está matando os clones do RHEL agora, por que eu deveria arriscar achando que o Fedora não será o próximo?
Sei que dizem “o RHEL é derivado do Fedora” e “o Fedora é um projeto open source separado”, mas hoje o RHEL é derivado do CentOS Stream. Então me pergunto por que o Fedora é necessário e por que a Red Hat deveria fornecer engenharia e infraestrutura ao Fedora
É verdade que o Fedora é um projeto separado, mas a maior parte das contribuições vem de funcionários da Red Hat. Se amanhã a IBM decidir que o CentOS Stream é suficiente e parar de pagar os custos do Fedora, o Fedora conseguirá se sustentar de forma independente?
Isso pode ser apenas medo, incerteza e dúvida (FUD), mas não confio mais em uma distribuição Linux pertencente à IBM. Já migrei meus equipamentos pessoais para Debian e também recomendo Debian no trabalho. Acho irresponsável que uma organização que customiza bastante suas instalações Linux escolha uma distribuição baseada na Red Hat/IBM, incerta, em vez de um projeto open source completo e sem amarras. Se me enganam uma vez, a culpa é do outro; se me enganam duas, a culpa é minha, e não vou cair de novo com a IBM
O Fedora ainda serve como campo de testes para tudo no CentOS e, portanto, para tudo no RHEL. Fico curioso para saber qual seria o argumento contra esse modelo de desenvolvimento, no qual uma “distribuição do futuro” como o Fedora é usada para modelar releases futuros do RHEL
Para quem não acompanha de perto o kernel Linux: maddog é uma figura lendária
A perspectiva dele é muito interessante e digna de apreço, especialmente pela forma como estrutura o assunto com base na história. Conhecer a história ajuda muito a entender o contexto. O texto original é longo, mas vale a leitura
Sou cerca de 30 anos mais novo que Jon Hall, então não pude conhecer diretamente suas realizações além do que foi transmitido oralmente ou por escrito. Ele também não deixou um livro de enorme sucesso nem um software que eu pudesse usar (tudo bem, existe o Linux for Dummies), então eu via as pessoas continuarem chamando-o de lenda, mas não entendia por quê
No fim, perguntei à comunidade do kernel Linux e me explicaram o alcance das contribuições dele. Em certo sentido, ele foi um mentor de Linus. Quando se conheceram, em 1994, Linus era um estudante de 25 anos e Jon era um gerente de marketing da DEC de 44. Costumo imaginar a conversa entre os dois como uma cena do tipo “garoto, preste atenção no que vou dizer. Agora, o que você precisa fazer é isto”
Pensando nisso, uma frase da biografia de Jon Hall na Wikipedia chama a atenção. Ela diz que, durante seu período na Digital, ele se interessou por Linux e teve um papel importante em conseguir equipamentos e recursos para que Linus Torvalds fizesse o primeiro porte para a plataforma Alpha da Digital
Uma linha da experiência dele no LinkedIn mostra a mesma perspectiva. Senior Marketing Manager, DEC, 1983-1998: em 1994, conheceu Linus Torvalds, reconheceu o valor comercial do Linux e conseguiu financiamento para portar o Linux para o processador Alpha de 64 bits, abrindo uma linha de negócios de bilhões de dólares em supercomputadores de alto desempenho baseados em Linux
WP: https://en.wikipedia.org/wiki/Jon_Hall_(programmer)
LI: https://www.linkedin.com/in/maddog/
Concordo com a afirmação de que “as pessoas que usam esses clones sem devolver nada à comunidade, de nenhuma forma, são ‘caronas’”, mas isso é algo que o software livre sempre aceitou em certa medida. Disponibilizar algo gratuitamente também significa que nem todo mundo vai devolver algo — ou qualquer coisa
A diferença em relação a algo como Oracle Awesome Linux é que, nesse caso, eles vendem como serviço o trabalho de valor agregado e o ecossistema da Red Hat. Na prática, é algo como: “compre isto se quiser suporte junto com nossos outros produtos. Distribuímos exatamente o que a Red Hat publica”
Na minha opinião, a mudança da Red Hat está mais para tornar mais caro criar um modelo de negócios proprietário do tipo “Oracle Red Hat for X”. Quem não conseguia pagar por RHEL para infraestrutura acadêmica de alta performance continua sem conseguir pagar e simplesmente escolhe outra coisa
Reclamar aqui sobre Fedora não faz muito sentido. O Fedora é um projeto com finalidade comercial que atende às necessidades da empresa, e existirá até o dia em que deixar de existir
A Red Hat não é a Microsoft. Todo mundo reconhece que há muitas distribuições, e várias delas são excelentes. Você poderia começar uma distribuição hoje mesmo. Mas “tudo bem, então é só usar Debian” também não é exatamente uma resposta válida. O Debian é um ótimo projeto e produto, mas, se você escolheu Red Hat por motivos que não fossem ter recebido um CD encartado em uma revista em 1998, é provável que o Debian não seja ideal sem muito trabalho. No fim, é uma questão de dinheiro entre o custo de pessoas fazendo isso manualmente e o custo de deixar a Red Hat cuidar disso enquanto essas pessoas fazem outras coisas
Lembro de uma vez em que eu doava servidores e hospedagem para o projeto Fedora. Ao configurar os servidores, perguntei ao responsável: “Vocês vão querer rodar RHEL, certo?” Ele respondeu “sim”. Quando perguntei “vocês têm uma chave de licença que possamos usar?”, ele disse: “até conseguimos arrumar, mas é chato; simplesmente instalem CentOS”
O instrutor recomendou usar CentOS para os exercícios depois da aula (antes da aquisição do CentOS). Mais tarde, em um dos projetos, acabamos usando Red Hat
Depois disso, era CentOS e clones; por um tempo, parecia até que, quando as pessoas diziam RHEL, na verdade queriam dizer CentOS
Com Qt é parecido. Mesmo que quase todo o software dependa de Qt, ficam presos no Qt 4.x para não pagar à Digia
Como funcionário da Red Hat, fico grato pela perspectiva do maddog. Gostaria que outras pessoas também conseguissem ver de forma tão ampla o que as empresas fazem pelo open source
Ver por dentro como o trabalho é criado muda a perspectiva. Gostaria de poder explicar às pessoas o que realmente vendemos. Nós não vendemos software nem licenças de software
Não estamos contornando licenças open source, nem mudando licenças. Estamos tentando manter trabalhando as pessoas que fazem coisas valiosas para os clientes. Grande parte do que fazemos sobe para projetos upstream e é compartilhada com concorrentes, a comunidade e usuários
É bom ouvir essas ótimas histórias históricas do maddog. Quando ele fez uma das visitas a Austin mencionadas no texto, eu trabalhava no LTC, e tive a oportunidade de conversar com ele durante o almoço. Isso foi cerca de 20 anos atrás
É sempre interessante ouvir o que uma pessoa na casa dos 70 considera “pontos de inflexão” na própria carreira. Também é especialmente marcante a forma como os meus pontos de inflexão se entrelaçam com os deles
Eu estava no meio de toda a confusão da SCO, mas não sei se posso falar sobre parte disso. Talvez agora os advogados da empresa já tenham se aposentado ou morrido em número suficiente para que eu possa dizer o que quiser. Se eu me sentir motivado
Fico feliz que o maddog ainda esteja compartilhando suas histórias. Quanto mais velho fico, menos interesse tenho em compartilhar qualquer coisa com qualquer pessoa na internet. As conversas significativas para mim hoje em dia acontecem quase todas presencialmente, então parece haver pouco valor em compartilhar ou me envolver com pessoas que não conheço pessoalmente
A empresa onde trabalho tentou colocar RHEL nos equipamentos de servidor de alta performance que fabricamos, mas nos cotaram cerca de US$ 1 milhão por licença, sem negociação. Isso teria tornado nosso produto caro demais
Então acabamos indo para CentOS e depois migramos para Rocky, e contratamos uma equipe de cerca de 30 pessoas para gerenciar isso (também responsável por outros projetos). Respeito a Red Hat e o direito deles de administrar o software da forma que quiserem, mas, pela experiência dos últimos anos, parece que eles estão tentando extrair o máximo possível da marca. Tenho curiosidade para ver como isso vai se desenrolar nos próximos cinco anos
No trecho em que ele diz “comecei a programar em 1969” e “na verdade, não só era difícil vender software, como também não era possível aplicar direitos autorais”, fiquei curioso se essa era mesmo a situação jurídica em 1969. Era verdade que não se podia aplicar direitos autorais ao software?
É totalmente plausível que o autor acreditasse nisso em 1969, mas fico curioso se essa crença era juridicamente correta
Eu não atuava na prática jurídica na época, mas, pelo entendimento que me foi transmitido, não estava claro se o copyright se aplicaria a software e, se sim, como se aplicaria. Ainda assim, atores perspicazes em geral esperavam que surgisse alguma forma de proteção para software escrito, além de segredo comercial
Havia todo tipo de perguntas, teorias e propostas sobre se isso ocorreria sob a lei de copyright ou por meio de um regime específico para software. A resposta dos EUA ficou clara quando “computer program” entrou na definição do escopo da lei de copyright. Até hoje, ao discutir questões que continuam em aberto, as pessoas seguem citando a CONTU, a comissão que impulsionou essa recomendação
https://en.wikipedia.org/wiki/Software_copyright#History
É estranho não acreditar em Jon Hall, mas querer acreditar em qualquer desconhecido nas redes sociais
Conheci maddog por volta de 2000, em um evento que coorganizei em Paris. Fizemos muitas perguntas, e ele deu respostas perspicazes. Às vezes respondia envolto em uma longa história, como no texto linkado
O que mais me marcou foi isto. “Pergunta: como podemos ajudar o Linux a ganhar participação de mercado no desktop, além dos poucos pontos percentuais que ele já tem?”
“Resposta: não dá. Encontre um mercado que ainda não usa computadores, crie um produto que resolva as necessidades desse mercado e faça esse produto usar Linux. Pense em smartphones, por exemplo”
É bom ver que maddog ainda está ativamente envolvido com FOSS
Lá pelo fim dos anos 90, na COMDEX em Chicago, ele convenceu a mim e a um amigo a ficarmos algumas horas cuidando do estande dele para que pudesse dar uma volta pela feira. Não lembro se era da LPI, da LI ou de alguma outra organização relacionada a Linux. Acho que distribuímos CDs de distribuições e explicamos Linux às pessoas
Foi uma época maluca, em que o Linux estava tomando conta do mundo dos PCs, e o Tux estava em toda parte