O que é open source e porque é importante para software e blockchain?

O que é open source?

Open source significa que o código-fonte do software está disponível e que uma licença concede a terceiros direitos claros para usar, consultar, adaptar e distribuir esse código. O código-fonte é a versão legível de um programa com a qual os programadores trabalham. Pode vê-lo como a receita por detrás de uma aplicação ou programa.

Por isso, colocar apenas o código online não é suficiente. Sem uma licença adequada, não fica automaticamente claro se pode copiar, alterar ou voltar a partilhar esse código. É precisamente a licença que determina o que é e o que não é permitido.

Open source também não significa necessariamente gratuito. Alguém pode vender software open source ou cobrar pela sua distribuição, desde que a licença o permita. O que está sobretudo em causa é a liberdade em torno do código, não o preço.

Uma verdadeira licença open source não pode, por exemplo, fazer distinções entre utilizadores, grupos ou aplicações. Assim, não pode disponibilizar o software apenas para um determinado grupo ou apenas para uso privado e depois chamá-lo open source. Além disso, as condições não devem depender de uma tecnologia específica.

Exemplo: Imagine que um programador lança um programa ao abrigo de uma licença open source. Pode estudar o código, criar uma versão própria e partilhá-la, desde que cumpra as condições dessa licença. Se o mesmo código estiver online sem licença, não tem esses direitos automaticamente.

Pontos principais

• Open source diz respeito ao código-fonte e aos direitos que uma licença concede.
• Muitas vezes, pode usar, estudar, adaptar e partilhar software open source.
• Open source não significa automaticamente que o software seja gratuito.
• Uma licença determina quais são as condições aplicáveis ao uso e à distribuição.
• Código-fonte público sem uma licença adequada não dá a terceiros direitos de utilização claros.

Como funciona o software open source?

O software open source funciona porque o autor publica o código-fonte ao abrigo de uma licença com regras claras. Outros programadores podem depois copiar, consultar e adaptar o código. Se também podem distribuir a versão adaptada depende das condições da licença.

Em muitos projetos, é utilizado controlo de versões. Trata-se de um sistema que regista que alteração foi feita, por quem e quando. Uma alteração guardada desta forma chama-se commit. Assim, normalmente é possível ver passo a passo como o software evoluiu.

Uma forma muito usada de colaboração funciona mais ou menos assim:

1. Criar uma versão de trabalho própria Um programador trabalha numa branch, uma linha de trabalho separada dentro do mesmo projeto. Por vezes, essa pessoa cria primeiro um fork: uma cópia própria de todo o projeto.

2. Alterar o código Nessa versão própria, alguém pode corrigir um erro, adicionar uma funcionalidade ou melhorar o código sem alterar de imediato a versão oficial.

3. Submeter um pull request Um pull request é uma proposta para incluir a alteração no projeto original. Outros programadores podem então consultar, discutir e testar o código.

4. Verificar a alteração Os projetos podem submeter as alterações a análise, testar automaticamente se o código funciona bem e verificar possíveis erros ou problemas de segurança.

5. Juntar ou não juntar Se as pessoas com os direitos adequados concordarem, podem juntar a alteração à versão oficial. Muitas vezes, isso chama-se merging.

Aliás, um fork nunca tem de voltar ao projeto original. Alguém pode continuar a desenvolver de forma independente com essa cópia própria. Só quando os responsáveis do projeto original aceitam a alteração é que esta passa a fazer parte da versão oficial.

GitHub, pull requests e forks são formas úteis e muito usadas de colaborar, mas não são uma condição para o open source. A licença é a base.

Quem gere o software open source e como são introduzidas as alterações?

O software open source não tem um único gestor geral; cada projeto determina por si quem gere o código e como as alterações são aceites. Podem ser maintainers individuais, mas também uma organização, fundação ou comunidade do projeto.

Um maintainer é alguém que ajuda a manter o projeto a funcionar. Essa pessoa pode, por exemplo, analisar alterações, lançar novas versões e decidir quem tem acesso ao repository oficial. Um repository é o local onde estão o código e o histórico de alterações de um projeto.

Os programadores externos podem, normalmente, comunicar um problema, propor uma melhoria ou submeter código adaptado. Em plataformas como o GitHub, isso acontece, por exemplo, através de um issue ou de um pull request. Um issue é muitas vezes uma comunicação de um erro, uma pergunta ou uma ideia de melhoria.

Os projetos podem definir regras adicionais antes de o código poder ser juntado. Pense em verificações obrigatórias por outros programadores, testes automáticos ou regras que impedem que código importante seja alterado diretamente sem mais.

No caso da blockchain, há ainda outro aspeto: o facto de novo código ser adicionado ao projeto oficial não significa que as regras da blockchain mudem automaticamente.

Um node é um computador que executa o software e verifica transações e blocos de acordo com as regras de uma blockchain.

No caso da Bitcoin, os BIPs servem como propostas públicas de melhoria. No caso da Ethereum, os EIPs desempenham um papel semelhante para normas e alterações à rede. Uma proposta deste tipo pode incluir explicação, feedback e adaptações anteriores. Mas a publicação de um BIP ou de um EIP não altera automaticamente as regras da Bitcoin ou da Ethereum.

Também a junção do código não faz isso automaticamente. Para uma verdadeira alteração das regras do protocolo, as regras técnicas da rede, os participantes relevantes têm, em última análise, de executar software que siga as mesmas novas regras.

Na Bitcoin, nenhum órgão formal ou informal decide sozinho sobre a adoção dos BIPs. Na Ethereum, os EIP editors tratam sobretudo de tarefas administrativas e editoriais, não da decisão de conteúdo sobre se uma proposta é desejável.

Que licenças open source existem?

Dois tipos comuns são as licenças permissivas e as licenças copyleft. As licenças permissivas chamam-se assim porque permitem muito: normalmente, pode usar, adaptar e voltar a distribuir o código livremente. Copyleft é um trocadilho com copyright. Nestas licenças, também pode adaptar e partilhar o código, mas o software derivado tem muitas vezes de continuar disponível sob as mesmas condições abertas.

Estas são algumas licenças conhecidas:

• MIT Trata-se de uma licença permissiva. Pode usar, copiar, adaptar, distribuir e até utilizar comercialmente o software. No entanto, tem de incluir a menção de copyright e o texto da licença. O software é fornecido sem garantia e com responsabilidade limitada.

• BSD-2-Clause e BSD-3-Clause Também são licenças permissivas. Permitem uma reutilização e distribuição amplas, normalmente desde que a informação de copyright e de licença seja mantida.

• Apache-2.0 A Apache License 2.0 também é permissiva. Além disso, esta licença inclui acordos sobre patentes das pessoas que contribuem com código para o projeto.

• GPL-3.0-only A GPL é uma licença copyleft. Em termos simples, esta licença procura garantir que a liberdade de partilhar e adaptar código se mantém quando o software é distribuído mais amplamente. Quem distribuir software ao abrigo da GPLv3 tem de disponibilizar também o código-fonte correspondente, sob determinadas condições.

• MPL-2.0 A Mozilla Public License 2.0 é uma forma de copyleft que se centra sobretudo em ficheiros individuais. Se adaptar um ficheiro abrangido pela MPL, esse ficheiro alterado tem, normalmente, de continuar disponível sob as mesmas condições abertas. Outros ficheiros num projeto maior podem estar sujeitos a outras condições.

Importa saber o seguinte: etiquetas como permissiva, copyleft forte e copyleft fraco são úteis como primeira explicação, mas as condições exatas constam sempre do texto da licença. Sobretudo quando diferentes componentes de software com licenças distintas se juntam, a situação pode tornar-se complexa.

Porque é que o open source é importante para cripto e blockchain?

O open source é importante para criptomoeda e blockchain porque os nodes executam software que verifica transações e blocos com base em regras fixas. Quem executa o seu próprio node pode, por isso, querer confirmar que regras esse software executa exatamente.

Na Bitcoin, o Bitcoin Core é um exemplo conhecido. O código-fonte está publicamente disponível e o software é distribuído ao abrigo da licença MIT. Assim, programadores e outras pessoas interessadas podem estudar o código, propor contribuições ou criar uma versão própria dentro das condições dessa licença.

A Ethereum pode ser utilizada com vários programas open source diferentes, chamados clients. Este software processa, entre outras coisas, transações e ajuda os computadores a participar na rede Ethereum. Os diferentes clients são desenvolvidos por equipas diferentes e, por vezes, usam linguagens de programação diferentes.

Porque é que isso é útil? Se uma rede dependesse totalmente de um único software, um erro grave nesse software poderia afetar muitos participantes ao mesmo tempo. Vários clients independentes tornam a rede menos dependente de uma única versão do software.

Naturalmente, esses diferentes clients da Ethereum têm de seguir as mesmas especificações relevantes. As especificações são os acordos técnicos comuns sobre o funcionamento da rede. Pense em regras para transações, blocos e na forma como a rede chega a consenso sobre quais os dados válidos.

Os BIPs e os EIPs também ajudam na coordenação pública. Tornam visíveis propostas, explicações técnicas, feedback e revisões. Isto é valioso em cripto, porque alterações às regras podem ter consequências grandes para todos os que executam software, guardam criptomoedas ou usam aplicações como smart contracts.

O open source também torna possíveis versões independentes e forks. Isso dá mais escolha a programadores e utilizadores. Mas código aberto por si só não garante que uma blockchain seja segura, descentralizada ou amplamente utilizada. O código tem de ser bom, executado corretamente e, no fim, também tem de ser utilizado por nodes e outros participantes.

Quais são as vantagens do open source?

A maior vantagem do open source é que os utilizadores não só podem usar o software, como também podem analisá-lo, adaptá-lo e partilhá-lo. Isto é útil quando uma organização quer que o software se adapte às suas próprias necessidades técnicas ou operacionais.

Além disso, o código público permite verificação. Pode consultar alterações no histórico de versões e ver o que foi modificado. Num fluxo de trabalho com pull requests, outras pessoas podem discutir uma alteração antes de esta ser juntada. Testes automáticos e verificações de segurança podem ajudar a encontrar erros mais cedo.

O open source também pode facilitar a colaboração. Os programadores podem reutilizar componentes existentes em vez de construir tudo do zero. Naturalmente, isso só é permitido se as licenças forem compatíveis e se todos cumprirem as condições.

Um fork oferece ainda outra vantagem: continuidade. Imagine que um grupo de programadores quer seguir uma direção técnica diferente da dos maintainers originais. Nesse caso, podem continuar com uma cópia própria. Assim, um projeto não tem necessariamente de parar porque existe desacordo sobre o futuro.

Na blockchain, a diversidade de clients é uma vantagem. Isto significa que existem vários clients diferentes: programas com os quais os computadores participam, por exemplo, na Ethereum. Se estes clients forem desenvolvidos por equipas diferentes, a rede fica menos dependente de uma única versão do software. Assim, é menos provável que um único erro afete imediatamente todos os nodes, os computadores que mantêm a rede a funcionar, da mesma forma.

Mas é importante lembrar: o facto de poder inspecionar o código não significa que especialistas o tenham realmente analisado em profundidade. O open source torna a verificação possível, mas não prova que todos os erros já tenham sido encontrados ou resolvidos.

Que riscos e limitações tem o open source?

O open source não é um certificado de segurança. Mesmo o código público pode conter erros de programação, vulnerabilidades ou escolhas de conceção inseguras. O facto de todos poderem consultar o código não significa que pessoas suficientemente especializadas o tenham efetivamente feito.

A manutenção é um risco importante. O software precisa, normalmente, de manutenção contínua, por exemplo para corrigir bugs, atualizar a segurança e gerir novas dependencies. Uma dependency é um componente de software externo do qual um programa depende. Se um projeto não for bem mantido, problemas conhecidos podem ficar por resolver.

Quanto mais componentes de software externos um programa utilizar, mais pontos podem existir onde surja um problema de segurança. Uma dependency maliciosa ou comprometida pode, por isso, colocar em risco um sistema inteiro. Por isso, é sensato verificar se cada dependency é realmente necessária, de onde vem e se a versão utilizada ainda está atualizada.

No software open source, as licenças também desempenham um papel. Se combinar componentes com licenças diferentes, podem aplicar-se condições relativas à disponibilização do código-fonte, menções de copyright, alterações ou patentes. Isto é algo que deve ser bem analisado antes de o software ser distribuído.

Os forks também têm um lado menos favorável. Dão liberdade de escolha, mas podem distribuir programadores, utilizadores, documentação e manutenção de segurança por vários projetos. Um fork precisa dos seus próprios maintainers, segurança, novas versões e utilizadores ou operadores de nodes para continuar a funcionar bem a longo prazo.

Para a cripto, existe ainda um ponto de verificação adicional. O código num repository público não tem de ser automaticamente exatamente o mesmo que o software que instala. Por isso, é importante verificar de onde vem o software e se a versão que instala corresponde à versão oficial.

No caso dos smart contracts, também pode verificar se o código publicado corresponde ao contrato que realmente está a correr na blockchain.

Em suma: o open source dá-lhe mais possibilidades de verificação, mas não retira todo o trabalho de controlo. Por isso, ao analisar software e projetos de criptomoedas, veja também a manutenção, as práticas de segurança, as dependências e a versão que está realmente a utilizar.

Conclusão

Open source significa que o código-fonte está disponível ao abrigo de uma licença que concede direitos claros para usar, estudar, adaptar e partilhar o software. A licença é, neste contexto, pelo menos tão importante como o próprio código.

Para a cripto e a blockchain, o open source é ainda mais relevante porque os nodes executam regras de protocolo e vários clients independentes podem tornar uma rede menos dependente de um único software. Ao mesmo tempo, código público não é garantia de segurança ou qualidade. Boas verificações, manutenção ativa e dependencies seguras continuam a ser igualmente importantes.

Veja, por isso, o open source sobretudo como uma base sólida para a transparência, a colaboração e a liberdade de escolha. Oferece possibilidades, mas continua a ser necessário analisar como um projeto é gerido e se o software utilizado é mantido de forma fiável.