As obrigações de código aberto mudam com os ecossistemas de embalagens?

O mundo do software de código aberto evoluiu significativamente ao longo dos anos. O que começou como uma forma de os desenvolvedores compartilharem código livremente se transformou em um ecossistema complexo com seu próprio conjunto de normas, expectativas e até obrigações.

Muito tem sido escrito sobre o que as empresas devem e não devem esperar ou exigir dos mantenedores de projetos de código aberto e considerações de remuneração relacionadas. Para ser claro desde o início, concordo plenamente com o consenso geral de que o código-fonte aberto é fornecido gratuitamente e que os mantenedores que simplesmente publicam seu código não têm obrigações além do que a licença declara.

Mas quero explorar um tópico controverso, mas importante: o que nós, como comunidade, podemos e devemos esperar de projetos e mantenedores de código aberto que participam de ecossistemas de embalagens.

Quando um mantenedor dá um passo extra para participar de um ecossistema de embalagens, acredito que isso desencadeia uma nova esfera de obrigações e contratos sociais – e que mais discurso público e debate em torno deste tópico seriam especialmente saudáveis ​​para a indústria de código aberto neste momento em momento em que os XZ Utils e explorações semelhantes estão criando uma urgência especial em torno da confiança e da transparência nos sistemas de construção. Esta é uma conversa que está muito atrasada e está no cerne do movimento moderno de segurança da cadeia de suprimentos de software.

Novos modelos de distribuição, novas responsabilidades

Vamos começar dando uma rápida olhada em como o código aberto evoluiu.

Historicamente, as responsabilidades de construção e distribuição de software de código aberto eram normalmente separadas. Os desenvolvedores publicariam seu código-fonte bruto e, em seguida, outras comunidades, como as distribuições Linux, assumiriam a tarefa de empacotar e distribuir esse código aos usuários finais. Estas comunidades de distribuição, embora muitas vezes também de código aberto, operavam sob as suas próprias políticas e contratos sociais com os utilizadores.

No entanto, a ascensão de gerenciadores de pacotes específicos de linguagens como npm, PyPI e RubyGems confundiu essa linha entre “código vs. pacotes.” De repente, os pacotes de publicação tornaram-se acessíveis a qualquer desenvolvedor. Embora isso tenha acelerado bastante o desenvolvimento do código aberto, também introduziu garantias de segurança muito diferentes em comparação com os pacotes de distribuição Linux tradicionais. Muitos desenvolvedores, inclusive eu, não entenderam completamente essas compensações no início.

Esses gerenciadores de pacotes tornaram a publicação acessível a qualquer pessoa. Eles trouxeram UX semelhante, mas garantias de segurança muito diferentes. Minhas primeiras lembranças de Python envolviam lutar para fazer o NumPy funcionar e não entender a diferença entre apt-get install e pip install, exceto que um funcionou e o outro não. Eu não percebi nem entendi as compensações de segurança envolvidas. Os gerenciadores de pacotes têm a mesma aparência. npm install parece muito AppGet install ou PIP installpor exemplo, mas eles fazem coisas completamente diferentes do ponto de vista da confiança.

Embora os pacotes de distribuição do Linux tenham se estabilizado, os repositórios de pacotes de idiomas explodiram em popularidade e se tornaram a forma padrão pela qual a maioria dos desenvolvedores consome código-fonte aberto. É importante compreender que estes repositórios não são soluções mágicas; eles geralmente são administrados por voluntários e fornecem apenas curadoria básica, gerenciamento de formatos e remoção de malware. Eles operam sob suas próprias políticas e acordos de usuário.

Definindo o que significa confiança em ecossistemas de embalagens

Crucialmente, estes repositórios ocupam um lugar privilegiado no ecossistema. A comunidade Python, por exemplo, confiou no PyPI como índice de pacote padrão. Este é um contrato social implícito – a comunidade pode decidir mudar para um repositório padrão diferente se ficar insatisfeita com a administração do PyPI.

O mesmo contrato social se aplica a pacotes individuais dentro destes repositórios. Os mantenedores publicam pacotes em namespaces concedidos a eles pelo repositório, concordando em seguir suas políticas. Os mantenedores do repositório estabelecem as regras sobre quem tem permissão para publicar nesse registro. Eles eliminam spam e malware regularmente e recentemente começaram a prevenir ataques do tipo typosquatting e outros requisitos, como autenticação multifator para editores. Por sua vez, a comunidade utiliza esses pacotes para criar aplicações e alimentar a cadeia de fornecimento de código aberto.

Em última análise, a comunidade é quem manda aqui. Como usuários finais dos pacotes, a comunidade aprova a operação contínua do repositório de pacotes e dos pacotes dentro dele. Podem aparecer repositórios alternativos, mas a comunidade escolhe qual deles é o padrão.

Este é um contrato social multinível onde todos dependem da confiança da comunidade. Embora os editores de código não tenham obrigação de fazer nada com ninguém, os participantes dos ecossistemas de embalagens devem ter a obrigação de seguir as solicitações da comunidade através deste relacionamento transitivo.

A comunidade não pode tirar de alguém a capacidade de publicar código na Internet, mas pode reatribuir os direitos a um namespace de pacote específico, se necessário. E este não é um poder que deva ser encarado levianamente!

Um problema melhor resolvido pela comunidade (não por reguladores e advogados)

Historicamente, o código aberto funcionou principalmente com poucas políticas formais. Mas com o crescente escrutínio regulatório em torno da segurança de código aberto – à medida que as cadeias de fornecimento foram atacadas, mais recentemente com a vulnerabilidade XZ Utils – a mudança pode ser inevitável. Os usuários *com razão* precisam de mais garantias de segurança do que as disponíveis hoje, e não espero que o status quo dure indefinidamente.

Se você é um mantenedor de código aberto, não precisa se preocupar com seus direitos. Ninguém pode impedi-lo de publicar código na internet. Mas quando você toma a decisão de publicar seus pacotes em um repositório da comunidade, você está firmando um acordo com essa comunidade. E essa comunidade tem as suas próprias relações e obrigações.

Já estamos vendo operadores de repositório colaborando em políticas aprimoradas sobre como os pacotes são construídos, publicados e mantidos. Isto pode ser controverso, uma vez que os utilizadores finais e os mantenedores são muitas vezes grandes empresas que não contribuem tanto quanto poderiam. Estudos têm mostrado consistentemente que a maior parte do código na maioria dos aplicativos vem de código aberto mantido por um pequeno número de desenvolvedores. Pode parecer injusto para eles fazer exigências a mantenedores não remunerados.

Mas esta é uma conversa muito maior do que mera compensação. Uma pergunta melhor é quais mudanças precisam ser feitas nas cadeias de confiança e transparência nos ecossistemas de pacotes. Em vez de resistir à mudança, acredito que deveríamos concentrar-nos em garantir que as mudanças funcionam para todos. Temos a oportunidade, como comunidade de código aberto, de desenvolver novas tecnologias que tornem o que é melhor para a segurança o padrão “fácil de alcançar” para ecossistemas de embalagens.

Esta não é uma maré contra a qual devemos lutar. Trabalhando juntos, podemos garantir que o ecossistema de código aberto evolua para ser mais seguro e sustentável para todos os envolvidos. Estamos juntos nessa. E obteremos um resultado muito melhor debatendo como deveriam ser as obrigações e os contratos sociais nos ecossistemas de pacotes de código aberto, em vez de esperar por uma correção excessiva e pesada por parte de reguladores e advogados.

A postagem As obrigações de código aberto mudam com os ecossistemas de embalagens? apareceu primeiro em The New Stack.