Mostrando postagens com marcador fork. Mostrar todas as postagens
Mostrando postagens com marcador fork. Mostrar todas as postagens

O Paradoxo do Navio de Teseu no mundo open source.

O Paradoxo do Navio de Teseu

O Paradoxo do Navio de Teseu no mundo open source.

 Este artigo é parte integrante de um livro sobre licenças de software livre e de código aberto que estou escrevendo (e que honestamente ainda não há previsão de lançamento). Mas o que me motivou a disponibilizar esta parte foram dois motivos. O primeiro foi que recentemente eu postei o artigo o envolvimento do Netfilter/Iptables em ações judiciais. O segundo foi durante a live sobre o projeto Pindorama Copa Cabana onde um dos pontos que abordamos foi sobre forks pois há alguns comandos no pacote Util-Linux que são forks de comandos do Core utils do GNU. E é aí que eu hoje resolvi bancar de filósofo sem formalidades e entro com O paradoxo do Navio de Teseu para que possamos analisar e melhor entender sobre código fonte e forks*. 

O NAVIO DE TESEU

 Teseu é aquele maluco da mitologia grega que enfrentou o Minotauro (o maluco é bravo mesmo).  Mas o que nos interessa aqui é sobre o paradoxo criado em torno dele. Em Vidas Paralelas, Plutarco propõe que se Teseu partiu com seu navio em uma viagem (que durou uns 50 anos) e ao longo dessa viagem seu navio precisou de manutenção (é obvio) ao ponto que ao final da viagem, todas as peças originais haviam sido substituídas, surge a questão:
Trata-se do mesmo navio ou de outro?
 E esse paradoxo virou uma bagunça; Heráclito e Aristóteles afirmaram que sim, aí vem Gottfried Leibniz afirmou que não; Thomas Hobbes piora ainda mais o assunto propondo que se remontassem o navio com as peças originais (por que alguém iria querer montar a porcaria de um navio com as peças velhas? Alias, quem seria desocupado o suficiente para ficar procurando estas peças?) se ambos os navios são o mesmo ou se são navios diferentes (aí que bugou a cabeça de todo mundo mesmo); John Locke já mete o bicão falando de meia furada (a conversa mais paralela que eu já ouvi) e o assunto foi tão longe que teve gente até mesmo falando de teletransporte...

 Esse paradoxo foi tema no ultimo capítulo da série Wanda Vision quando ambos Visões (a versão projetada por Wanda e o branco que foi reconstruído a partir do corpo original do Visão) lutavam entre si. O versão branca de Visão foi programada para destruir o Visão porém, ele é o visão; o original. Daí surge o debate entre os dois sobre o navio de Teseu e ambos chegam a conclusão de que os dois são o Visão (ou talvez não, sei lá. Assunto que vira uma bagunça na mente).

Vision vs Vision
Visão vs Visão em Wanda Vision.

 Bom, deixando essa balela filosófica de lado porque eu não tenho um pingo de interesse em falar de meia furada; vamos aproveitar a ideia do navio e substituir por código fonte.

 Então suponha que você seja o autor de um programa open source*; porém alguém cria um fork do seu programa e ao longo do tempo o código fonte foi tão modificado ao ponto que não há mais uma só linha do seu código original. E agora faço a mesma pergunta do navio:
Trata-se do mesmo programa ou de outro?
 Bom de acordo com a lei, quando um programa é totalmente modificado, não se trata mais do mesmo programa. Não há como reivindicar direito sobre o código fonte de outras pessoas.

 Externamente enxergamos o mesmo programa com funcionalidades semelhantes porém, internamente ambos são programas totalmente diferentes. Para entender melhor, vamos analisar dois projetos que passaram por situações semelhantes ao longo de sua história. São eles o 4.4BSD-LITE e o Busybox.

O CASO 4.4BSD-LIT vs USL

 Como já contei em uma live, a BSDI (Berkeley Software Design, Inc) tomou um processo da AT&T simplesmente por seu número de telefone conter a palavra Unix...1-800-ITS-UNIX. Pois é, um simples numero de telefone foi motivo o suficiente para a BSDI tomar um processo da AT&T que se estendeu por um bom tempo (em partes por culpa da própria galera do BSD).


 Só se chegou a alguma solução quando removeram certos arquivos e modificaram outros e assim surgiu o 4.4BSD. Em Julho de 1.994 foi lançado o 4.4 BSD-Lite não contendo nenhuma linha de código fonte AT&T (o 4.4BSDLite que deu origem aos BSDs que conhecemos hoje).


 Ou seja, com a remoção de todo código da AT&T, os BSDs continuam sendo Unix porém,  não mais o Unix da AT&T, Bell Labs, USL, Open Groups ou seja lá quem for. Não há como reivindicar direitos sobre os BSDs por não conter mais código fonte de autoria dessas instituições. No caso eles se tornaram outro Unix; Unix independente do original.

Busybox e o caso GPLv3

 O autor do Busybox é Bruce Perens; primeiro presidente a assumir o Debian após a saída de Ian Murdock. Bruce Perens é também o responsável pelo logo e pela ideia de codinomes do Debian serem inspirados na animação Toy story.

 Bruce desenvolveu o Busybox a partir de comandos já existentes, originados de outros pacotes como o Core utils do GNU e o Util-linux do... Linux.... A ideia era desenvolver uma ferramenta (um terminal de comandos) tendo somente os comandos necessários para que o kernel Linux pudesse utiliza-lo durante o processo de boot. Tanto que encontramos o Busybox dentro do initrd ou do initramfs.


 Porém, Bruce Perens deixou o projeto Busybox antes que ficasse pronto sendo então assumido por outros como Erik Andersen. Erik Andersen foi quem tornou o Busybox funcional para que pudesse ser utilizado como terminal de comandos padrão (assim como vemos no Alpine Linux e em muito roteadores). Após Erik Andersen, quem assumiu o projeto como mantenedor foi Rob Landley (o autor do terminal de comando toybox que é encontrado no Android desde a versão 7, no Tizen e em vários outros projetos).

 10 anos depois que o projeto se encontrava consolidado, com ferramentas funcionais e todos os problemas judiciais solucionados, eis que Bruce Perens surge de volta ao projeto como um herói (e até levando créditos pelos trabalhos de outras pessoas) e começa a querer ditar regras. Uma delas é que o Busybox deveria ser migrado para a licença GPLv3.

 Um dos motivos apresentados a Bruce Perens para que não ocorresse tal migração de licença foi que já não havia mais código do projeto GNU no Busybox. Então não haveria como fazer tal exigência.

BusyBox is not a GNU project, so the Free Software Foundation does not hold its copyrights; instead, those copyrights are retained by the original authors. As Rob looked over the code, he found many contributions with the usual "or any later version" language which would allow a change to GPLv3. Others, however, had the explicit "version 2 only" language. Some, contributed by one Linus Torvalds, state that they "may be redistributed as per the Linux copyright." Some other contributions carry a BSD license - originally with the GPL-incompatible advertising clause. It was quite the mixture of licenses.
Passe o cursor na imagem para ler a tradução (texto original clicando aqui)

 Um dos argumentos apresentados por Brunce Perens foi que ele era o autor do projeto e eles iriam fazer o que Richard Stallman mandasse.... Foram 9 meses de debate sobre o assunto que não levou a lugar nenhum. Houve até mesmo consulta de advogados (da qual Bruce Perens não compareceu).

 Rob landley chegou a passar dias analisando e comparando o código entre versões do Busybox para provar que existia mais códigos de Bruce Perens presente no projeto. A equipe do Busybox Sugeriu que Bruce perens fizesse um fork de qualquer versão do projeto para que atendesse às suas necessidade e Bruce até mencionou que faria porém... No final das contas, o BusyBox permanece até hoje sob GPLv2 e... Cadê o fork do Bruce Perens?

Conclusão

 As regras apresentadas aqui não são exclusivas a forks ou a software livre e de código aberto. Elas também são aplicáveis tanto ao próprio projeto ou até mesmo software proprietário. Você pode ter por exemplo um programa e modificá-lo por completo que ele também deixará de ser o mesmo programa.

 Como exemplo, reparem as duas imagens abaixo. tratam-se do código fonte do comando fsck. A primeira apresentada é do código de autoria do Linus Torvalds de 1991 e 1992 (quando foi lançada a versão 0.11 do kernel) e está disponível no util-linux-ng-2.13.0.1. Já a segunda está disponível no util-linux-2.38-rc1 e possui seu código totalmente modificado por Ted T'so, Karel Zak e outras pessoas. 

Fsck de autoria de Linus Torvalds no util-linux-ng-2.13.0.1
Fsck de autoria de Linus Torvalds no util-linux-ng-2.13.0.1

util-linux-2.38-rc1
O mesmo fsck do util-linux-2.38-rc1

 Mas mesmo que um programa tenha dado origem a outro, ambos são considerados programas diferentes se totalmente modificado (ambos possuem a mesma origem, o mesmo propósito, funcionalidades iguais, mas são programas diferentes), não tendo ao autor do original créditos e direitos sobre o posterior; esse é o foco principal deste assunto; tratar da questão de direitos autorais sobre o código fonte (sim, software livre e de código aberto também acabam agregando direitos autorais a seus autores). Os créditos são sempre reservados a cada um que realizou alguma contribuição (todos são autores e todos merecem seu reconhecimento).

 Mas se me perguntarem sobre o navio; se trata-se do mesmo ou de outro. Para mim trata-se de um navio pow... Vai entender o que passa na cabeça dos seres humanos. Não é a toa que ficar buscando inteligência fora da terra...
Busy busy busybox

OpenZFS abandona o termo slave em seu código

OpenZFS abandona o termo slave em seu código
OpenZFS abandona o termo slave em seu código
 Na Quarta Feira (dia 10 de Junho) o desenvolvedor Matthew Ahrens da ZFS founding enviou  a pull request para o git do projeto OpenZFS. Não se trata de um bugfix ou adição de novos recursos e sim um cleanup alterando o termo "slave" para "dependents" de todo o código do OpenZFS.

 Na request, Matthew explica que sua motivação é que o efeito horrível da escravidão humana continua a afetar a sociedade e que o termo "slave" na computação é uma referencia desnecessária para uma dolorosa experiencia humana.

Pull Request de Matthew Ahrens
Pull Request de Matthew Ahrens
 A pull requeste foi aceita e a partir de agora iremos passar a utilizar o termo deps no ZFS. Então, fica a dica para irem se adaptando ao novo termo; não é algo que vai impactar no trabalho de ninguém, não é algo que necessite toda uma curva de aprendizado, é simplesmente uma mudança de termo.

 Esse já não é o primeiro caso que vemos acontecer no mundo de software que há a iniciativa de adotar um novo termo devido o anterior ser ofensivo. Pouco antes do escândalo em que Stallman se envolveu, um grupo resolveu criar um fork do editor de imagens Gimp pelo mesmo motivo. O fork recebeu o nome de Glimpse (vislumbre) já que o nome Gimp pode referir-se a vários termos ofensivos de acordo com o site Merriam.

Site oficial do editor de imagem Glimpse
Site oficial do editor de imagem Glimpse
 Será que o Bash não vai entrar na mesma onda? Há pouco tempo anarquistas apareceram segurando placas com a frase "IT TAKES A BULLET TO BASH A FASH" (é necessário uma bala para esmagar um arrogante). Em inglês, o termo bash tem os significados pancada, bater, xingar, esmagar, surrar.

 OK, podemos até afirmar que no caso terminal, Bash é o acrônimo de Born Again Shell fazendo referencia e homenagem ao terminal Born Shell e não tem nenhuma intenção de expressar nenhumas das palavras que mencionei. Sim, é verdade, mas o Gimp também não pois seu nome é a abreviação de GNU Image Manipulation Program e anteriormente (antes de integrar o projeto GNU) era General Image Manipulation Program e mesmo assim resultou em um fork por conta de seu nome... Como diria o grande pensador contemporâneo:
Se Gimp quer dizer GNU Image Manipulation Program e GNU quer dizer GNU is Not Unix e Unix quer dizer UNiplexed Information and Computing Service for UNIX; logo, o nome Gimp quer dizer GNU is Not UNiplexed Information and Computing Service for UNIX Image Manipulation Program.
 Se tem duas outras expressões que também deveriam pensar em mudar é o nome de #! (te garanto que vai encontrar certas coisas que não estava esperando) e do comando word counter (wc, parece banheiro em inglês). Geraçãozinha viu...

CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.

Lançado Unleashed 1.3

illumOS
illumOS ganha um fork
 Unleashed é um fork do sistema operacional illumOS (e sendo o illumOS um fork do Open Solaris e por sua vez, um derivado do Solaris). O meu primeiro vídeo no canal eu relatei um pouco sobre o Open Solaris já que havia ouvido pessoas dizendo que se tratava de uma distribuição Linux. Caso não saiba o que é um fork, eu tenho um artigo aqui no blog que pode conferir e entender melhor, basta clicar aqui ;)

 Automaticamente o Unleashed herda as características do Open Solaris como o ZFS, o DTrace e o Crossbow e vários outros recursos que podem ser conferidos clicando aqui. Veja aqui meu antigo vídeo sobre o Open Solaris.


 Existem vários em torno de oito distribuições derivadas do illumOS; cada um desses destinado a soluções diferentes como Workstation, servidores, storagesHypervisorA lista de distribuições derivadas do illumOS que podem ser conferidas clicando aqui ou visualizando a imagem abaixo.
Distribuições derivadas do illumOS
Distribuições derivadas do illumOS
 Esse fork surgiu pela comunidade acreditar que poderia fazer melhor do que os derivados do illumOS adotando uma postura diferente em relação à compatibilidade e redução de interações de códigos, buscando modernizar o sistema operacional através da remoção de código legado. Com isso, apesar de um descendente do Solaris, o Unleased torna-se binariamente incompatível com o Solaris por removerem um monte de partes (digamos) sujas.

 A comunidade quer adotar um ambiente de compilação diferente já que do illumOS é antigo. Querem que o ./configure seja o suficiente para a maioria dos programas (sem ser necessário ficar especificando flags ou lincar bibliotecas adicionais).
sendo o 
Curso Linux: Da migração a administração do sistema operacional
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
 Essa é uma comunidades sendo totalmente Open Source (não pretendem ter binários proprietários e nem blobs no sistema operacional), com uma liderança limpa, um sistema operacional completo, com lançamentos periódicos (um a cada três meses com patches de segurança entre os lançamentos),


A polêmica história do código de conduta do Linux

Essa semana eu tratei sobre o código de conduta do kernel Linux onde exponho a minha opinião sobre o assunto. No vídeo proponho também o que poderia ser solução (bem difícil de implementar) para o futuro (talvez longínquo) mostrando casos já existentes no próprio kernel Linux e que poderiam evitar tal problema recorrente:


Porém, gostaria de debater mais dois comentários; um que li quando o CoC estava em alta e esqueci de debater e outro que recebi e achei interessante.

-O primeiro o pessoal anda falando de criar um fork do Linux para solucionar esse problema... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... É sério isso?

Ok, forks do Linux já existem como o do Facebook para utilizado para manter o foco do desenvolvimento do Btrfs e toda a melhoria alí vão para a mainline do kernel vanilla; o de Matthew Garrett que já foi desenvolvedor do kernel Linux e, após sair do desenvolvimento, decidiu criar um fork para manter um patch que adiciona suporte em nível de segurança estilo BSD; o da FortiNet chamado FortiOS e muitos outros. Além de já existirem forks, do que adiantaria criar fork (ou forks) do linux se o código dos mesmos desenvolvedores estarão lá? Eles irão requerer seu código até mesmo do(s) fork(s) por se tratar exatamente do mesmo código (e logo, propriedade deles)... Iriam cair no mesmo paradigma dos BSDs que mencionei...

O segundo trata-se de uma pergunta; se a GPL não foi adotada pensando no modelo de desenvolvimento bazar. A verdade é que a GPL não implica em nada em modelo de desenvolvimento nenhum; ou seja, não tendo nada a ver com o modelo de desenvolvimento Bazar do livro "A Catedral e o Bazar" de Eric S. Raymond".  Os próprios modelos catedral e bazar são coisas muito além do GNU. Você pode adotar qualquer outra licença e seguir o modelo de desenvolvimento que você preferir. Provas disso são que:
  1. O modelo bazar já era adotado no Linux quando Linux ainda estava sob a licença da convenção de berna do século XIX (que foi a primeira licença adotada no Linux).  
  2. O próprio micro kernel GNU Mach do GNU está sob GPL e a comunidade GNU segue o modelo catedral (e não o modelo bazar ;)
Por hora é só pessoal, um abraço e FALOWSSSS...

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (1) ambiente gráfico (19) AMD (14) analise (10) Andriod (15) android (7) artigo (5) aws (1) bc (18) benchmark (5) BSDs (27) btrfs (31) bugs (1) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (26) comp (1) compressores (5) container (6) CPU (19) criptografia (4) crowdfunding (9) cursos (24) daemons (13) Debian (31) desenvolvimento (82) desktop (19) DevOps (3) DevSecOps (3) dic (1) Dica de leitura (87) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (1) diocast (1) dioliunx (3) distribuições Linux (13) Docker (11) DragonflyBSD (21) ead Diolinux (2) edição de vídeo (5) EMMI Linux (4) emuladores (6) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (10) filesystem (78) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (20) Funtoo Linux (13) games (90) gerenciadores de pacotes (3) GOG (3) google (8) gpu (3) hardware (102) hash (1) helenos (3) I.A (1) init system (8) Intel (15) IoT (1) ispconfig (1) jogos (36) kde (1) kernel (134) lançamento (62) leis (1) LFCS (1) licenças (8) Linus (16) linus torvalds (2) Linux (194) linux foundation (3) linux para leigos (1) live (5) LPI (8) LTS (1) machine learning (1) matemática (5) mesa redonda (27) microsoft (6) microst (1) muito além do GNU (149) não viva de boatos (9) navegadores (3) NetBSD (7) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) open source (83) OpenBSD (5) OpenShift (1) os vários sabores de Linux (39) padrim (2) palestras e eventos (5) partições (6) pentest (8) pipewire (1) processadores (27) professor Augusto Manzano (11) Programação (61) promoção (1) propagandas com Linux (8) Red Hat (21) redes (3) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (12) RISCV (11) runlevel (2) segurança digital (19) servidores (1) shell (3) sistema operacional (23) smartphones (3) Software livre e de código aberto (151) sorteio (3) Steam (9) Steam no Linux (7) supercomputadores (4) suse (7) systemd (7) terminal (84) terminal de comandos (12) toca do tux (1) toybox (23) tutorial (6) Tux (3) unboxing (7) UNIX (16) UNIX Toolbox (14) vartroy (1) vga (1) virtualização (1) vulnerabilidade (4) wayland (5) whatsapp (1) Windows Subsystem for Linux (2) wine (14) WoT (1) ZFS (14) zsh (2)