Resistência Open Source: vamos proteger o open source durante o expediente

 (ossresistance.com)
6 pontos por GN⁺ 2026-05-15 | 2 comentários | Compartilhar no WhatsApp
  • Open Source Resistance é um manifesto de ação direta que propõe que a manutenção de softwares open source dos quais as empresas dependem seja feita de forma discreta e profissional, dentro do horário de trabalho
  • Rejeita a estrutura em que, apesar de nenhuma empresa conseguir operar sem open source, mantenedores precisam implorar por autorização separada, um botão de doação ou um tempo na tarde de sexta-feira
  • Já existiam alternativas como o Open Source Pledge (pedido de US$ 2.000 por ano por desenvolvedor) e o Open Source Friday (mínimo de 2 horas de contribuição toda sexta-feira), mas a proposta agora é uma execução mais direta
  • À crítica de que isso seria “roubo de tempo”, a resposta é que as empresas já vêm recebendo um subsídio gratuito de OSS, e manter dependências de OSS é um trabalho de infraestrutura compartilhada
  • É essencial verificar a cláusula de cessão de PI no contrato de trabalho e negociar por escrito uma exceção para open source

Manifesto: não peça permissão para consertar um trabalho que já precisa ser feito

  • Open Source Resistance propõe uma ação direta: em vez de empurrar a manutenção de software open source (OSS) do qual a empresa depende para noites e fins de semana como hobby, isso deve ser feito de forma discreta e profissional durante o horário de trabalho
  • Software open source não é um “hobby” de tempo livre, e as empresas extraem valor dele a todo momento, enquanto oferecem aos mantenedores apenas uma tarde de sexta-feira, um botão de doação ou um agradecimento numa reunião geral
  • Mantenedores devem trabalhar, dentro das empresas, no código OSS do qual elas já dependem durante o expediente, sem burocracia, programas internos ou aprovação gerencial
  • Isso não é uma ideia nova, e sim dizer abertamente como a maior parte do open source sempre foi feita
  • Mantenedores vêm sustentando a internet sem esperar por reuniões, sprints ou aprovação de product managers

Princípios centrais de ação

  • Proteja-se

    • Verifique seu contrato de trabalho, mantenha informações confidenciais dentro da empresa e garanta a titularidade da PI do open source que você publica

  • Faça o trabalho

    • Faça review de PRs, atualizações de dependências e correções de bugs em partes que já são OSS

  • Não seja imprudente

    • Não use 100% do horário de trabalho com OSS e depois culpe os outros se for demitido; o essencial é o equilíbrio

Alternativas já existentes

  • Open Source Pledge: pede que empresas paguem mantenedores (US$ 2.000 por ano por desenvolvedor)
  • Open Source Friday: pede que empresas doem tempo (mínimo de 2 horas toda sexta-feira)
  • Também existe a via educada de tentar convencer primeiro o empregador, e todas essas iniciativas são positivas e merecem apoio
  • Open Source Resistance é o próximo passo desse movimento: declarar que a manutenção da cadeia de dependências já é parte do trabalho, mesmo quando a gerência não a nomeia assim
  • Você não controla como a empresa aloca orçamento, mas controla como usa seu tempo de trabalho

Objeções previstas e respostas

  • “Isso é roubo de tempo / roubo contra os acionistas”

    • As empresas já extraem valor diariamente de mantenedores de open source, e os acionistas vêm recebendo há décadas um subsídio gratuito de open source
    • Se o empregador depende de OSS, manter isso é um trabalho de infraestrutura de bem público, não roubo

  • “Você precisa pedir permissão”

    • Pedir permissão é uma forma de manter o desequilíbrio de poder
    • Não é preciso a bênção da gerência para manter uma infraestrutura da qual o empregador já depende

  • “Isso é igual a quiet quitting”

    • Quiet quitting reduz a carga de trabalho; aqui, trata-se de produzir a infraestrutura de OSS sobre a qual a internet foi construída
    • O problema não é o trabalho em si, mas a recusa das empresas em classificá-lo como trabalho

  • “Até bons empregadores saem prejudicados”

    • Bons empregadores evitam esse problema permitindo manutenção open source no horário de trabalho, financiando mantenedores ou aderindo ao Open Source Pledge

A experiência de Mike McQuaid

  • Cofundador do Open Source Friday e do GitHub Sponsors, além de líder do projeto Homebrew (mantenedor desde 2009)
  • Em nenhum emprego, trabalhar em projetos open source como o Homebrew foi remunerado como função principal
  • Mesmo assim, ele fez isso em todos os empregos, negociou contratos de PI para tornar isso legal e também cumpriu seus compromissos de trabalho
  • Depois de ter filhos, mais de 90% do seu trabalho em open source passou a ser feito no horário de trabalho
  • Como escreveu em Open Source Maintainers Owe You Nothing, o fato de o modelo de negócio de uma empresa depender do seu código não dá a ninguém o direito de exigir do mantenedor noites, fins de semana ou tempo com a família sem pagamento

Cuidados e aviso legal

  • Isto não é aconselhamento jurídico

    • O texto deixa claro que isso não é aconselhamento jurídico, nem orientação sobre contratos, empregadores, status imigratório, obrigações de licença ou situações individuais
    • Se o risco for alto, é preciso consultar alguém qualificado antes de agir
    • Como a maioria das licenças open source, isto é fornecido “no estado em que se encontra”, sem qualquer garantia

  • Contratos, políticas e propriedade

    • Contratos de trabalho, políticas internas e cláusulas de cessão de invenções podem reivindicar direitos sobre trabalhos criados durante o emprego, em equipamentos do empregador ou dentro do escopo das funções
    • Em alguns estados, essas reivindicações sobre trabalhos feitos no tempo pessoal e com equipamento próprio são limitadas, mas os detalhes importam
    • Antes de agir, é preciso ler o contrato de trabalho e verificar se o empregador não é dono da PI do open source que você pretende publicar
    • Se dispositivo, rede ou conta mudarem o risco de propriedade, use os seus próprios

  • Negociação de contratos de PI

    • Cessão de PI muitas vezes pode ser negociada, e a recomendação é pedir por escrito uma cláusula de exceção para open source antes de assinar quando receber uma oferta de emprego
    • Primeiro, leia acordos de PI para funcionários para entender a que pontos você deve se opor
    • Mike McQuaid afirma ter negociado, com quase todos os empregadores, mudanças fora do contrato padrão, e que na maioria das vezes houve bem menos resistência do que ele esperava
    • É possível mostrar a empregadores em potencial o Balanced Employee IP Agreement do GitHub
    • Esse contrato foi open sourced sob CC0, já foi usado por uma grande empresa de capital aberto e foi desenhado para que o empregador mantenha aquilo pelo que pagou, enquanto o funcionário mantém trabalhos open source que não competem com o negócio

  • Confidencialidade e segurança

    • Não se deve divulgar repositórios privados, credenciais, incidentes, dados de clientes, roadmaps, vulnerabilidades ainda não divulgadas ou discussões internas
    • Não se deve burlar controles de segurança nem usar acessos não autorizados
    • A ação direta não é desculpa para expor informações confidenciais da empresa; trata-se de manter público o trabalho que já é público e claramente separado de segredos comerciais

  • Ser discreto não significa ser descuidado

    • Quando políticas, contratos, obrigações com clientes ou regras de segurança alterarem o risco, é preciso usar o próprio julgamento
    • Pode ser necessário trabalhar com seus próprios dispositivos, contas e rede
    • Não se trata de “roubar” da empresa, mas de reequilibrar o que a empresa tira do open source e o que você pode devolver
    • Você pode receber avaliações de desempenho piores do que colegas, mas um nível B sustentável é mais saudável do que esgotar a vida por uma nota A numa empresa que ainda pode demitir você amanhã

  • Limites de aplicação

    • O argumento é mais fraco quando o tempo é cobrado de clientes específicos, subsídios, órgãos governamentais, projetos de defesa ou ambientes regulados
    • Também é mais fraco para engenheiros juniores ou em situação instável sem poder para absorver retaliações
    • É mais forte para mantenedores seniores que consertam dependências públicas já usadas pelo empregador
    • A forma mais limpa não é “faça o que quiser no horário de trabalho”, e sim tratar manutenção open source como parte do trabalho de engenharia
    • Mantenha os projetos que você já mantém, melhore ferramentas compartilhadas que tocam seu trabalho e evite tarefas sem relação, código proprietário ou qualquer coisa que faça você falhar em compromissos reais

Fonte e projeto

Leituras relacionadas

2 comentários

 
roxie 26 일 전

No geral... acho que a expressão "resistência" parece apropriada.
 
GN⁺ 2026-05-15
Comentários do Hacker News

  • Na maioria dos casos em que trabalhei, as empresas davam uma autorização ampla para contribuir com determinados projetos de código aberto
    A forma de apresentar isso importa. Em vez de “posso fazer um pouco de caridade para me sentir bem?”, é melhor dizer: “posso receber revisão rigorosa gratuita de especialistas dessa área e incorporar as correções ao projeto open source upstream para eliminar custos futuros de manutenção da empresa?”
    Esse é o ponto essencial na prática, e nunca tive um empregador que recusasse quando colocado dessa forma. Isso está totalmente alinhado aos interesses da empresa; basta ajudá-los a enxergar isso

    • Uma das coisas de que mais me arrependo em ter sido demitido do meu emprego anterior é que estávamos discutindo publicar como open source uma mudança bem grande que fiz na biblioteca Kafka Streams
      Reescrevi bastante coisa mantendo a API majoritariamente compatível, com ênfase em E/S não bloqueante, permitindo usar semântica de backpressure quando necessário. Isso abriu espaço para coisas interessantes, preservando um desempenho muito bom mesmo misturando state stores com E/S bloqueante e não bloqueante, e eu tinha muito orgulho do projeto porque ele extraía desempenho em vários pontos pouco visíveis
      Insisti para publicarmos no GitHub ou enviarmos um PR para o projeto upstream do Kafka Streams, mas antes disso houve demissões em massa e depois eu já não tinha mais um defensor interno para impulsionar isso, então o código ficou preso como proprietário
      Ainda penso em recriar tudo do zero e publicar como software livre/open source. Já faz bastante tempo, então acho que não haveria problema em reescrever e publicar, não havia nada como patente envolvida, e também há coisas que eu gostaria de mudar, como remover a dependência de Vert.x. Talvez eu faça isso algum dia, quando tiver uma semana de folga
    • Sinto falta da época em que trabalhava em lugares que permitiam esse tipo de coisa
      Em algumas empresas, só o processo de revisão jurídica já emperra tudo
      Uma vez pedi autorização para enviar um patch para certo projeto e surgiu uma cadeia de e-mails interessante. No fim, a pergunta era só uma: se o patch foi escrito em horas cobradas do cliente para corrigir um bug em um produto entregue, se a biblioteca corrigida precisa ser recompilada e entregue junto com o código-fonte, e se o contrato diz que todo o trabalho e toda a propriedade intelectual relacionados ao produto são transferidos ao cliente, então nós temos o direito de liberar esse patch em domínio público?
      O jurídico não quis responder
    • Em geral, essa é uma boa abordagem e um ótimo exemplo de como enquadrar o trabalho de forma profissional. Ainda assim, ela não resolve o problema central. Especialmente em empresas orientadas por engenharia, a liderança deveria entender imediatamente esses benefícios; se não entende, isso já é um problema
      A forma como você pode abordar isso também depende muito da sorte com o empregador
    • “Legal, vou passar isso para o time de compliance. Só quero garantir que não há violação de propriedade intelectual. Qual repositório e issue exatamente?”

  • Sobre a frase “e certifique-se de possuir a propriedade intelectual do open source que você publica”, nas jurisdições em que trabalhei o código escrito e publicado no horário de trabalho pertencia ao empregador, não a mim
    Eu não podia decidir sozinho contribuir durante o expediente; era preciso um acordo formal para trabalhar em código open source. Toda vez que eu pedia, levava meses passando pelo jurídico, então eu acabava desistindo, ou nesse meio-tempo outro contribuidor já tinha aberto o PR e eu deixava de pedir

    • Acho que a ideia era mais “não tente doar livremente algo que não é seu”. Há uma seção separada sobre isso mais abaixo, mas olhando só os tópicos acima fica confuso
      Para desenvolvedores experientes isso é óbvio, mas para alguns juniores em certas empresas isso já foi um problema real. Se a empresa está fazendo algo bacana internamente, eles podem pensar que seria ótimo contribuir com isso para algum projeto open source, sem considerar que isso pode significar submeter código substancialmente semelhante usando conhecimento de código privado, ou às vezes até copiar e colar
    • Não pesquisei isso diretamente, mas eu entendia que na Alemanha, por padrão, todo código-fonte escrito no horário de trabalho pertence ao empregador
      A maioria dos empregadores que não são centrados em TI provavelmente nem entende o que é open source ou como isso funciona. Então conseguir autorização de muita gente pode ser desesperador
      O site mencionado faria melhor em focar primeiro em explicar aos empregadores os benefícios do open source e defender diretrizes legais para empregadores
    • Eu não trabalharia em um lugar que não libera código sob licença permissiva, exceto as partes que entram em produção. Para mim isso destrói a motivação e me levaria ao limite mental. Eu preferiria ser mais pobre

  • É uma boa ideia, até uma ótima ideia, mas não sei se é bom enquadrar isso como resistência
    O objetivo do cargo normalmente é atingir alguma meta. Como atingir essa meta é algo que o desenvolvedor, como especialista, deveria poder decidir. Se essa decisão inclui software open source, então manter esse software também deveria fazer parte da decisão
    Não é nada radical; é simplesmente fazer o próprio trabalho, preservando a estabilidade futura e a manutenibilidade das coisas das quais o trabalho depende

    • Isso também é simplesmente bom senso de negócios. Empresas que incentivam colaboração via open source estão cultivando o ecossistema que sustenta o próprio negócio delas
    • Concordo com tudo o que foi dito, mas a realidade da maioria das empresas de tecnologia hoje, na minha experiência, é diferente. Elas não investem tempo nem para manter a própria infraestrutura e bibliotecas, a menos que sejam obrigadas; open source então, menos ainda
      Funcionalidades inúteis para jogo de métricas, enshittification, dark patterns e integrações da moda quase equivalentes a malware têm prioridade sobre investir em infraestrutura e bibliotecas básicas
    • Concordo. Descrever assim faz parecer que alguém só quer chamar mais atenção nas redes sociais. É triste que tenhamos chegado ao ponto em que tudo precisa ser exagerado

  • Concordo totalmente em termos gerais, mas acho complicado fazer isso na prática. Não sou advogado, mas em geral entendo que o empregador é dono da propriedade intelectual, então é preciso autorização explícita para publicar como open source
    E conseguir essa autorização muitas vezes é difícil, envolvendo processos intermináveis e o departamento jurídico
    “Nos EUA, no Reino Unido e em várias outras jurisdições, quando um empregado cria uma obra como parte de suas funções, o empregador é considerado o autor legal ou o titular inicial dos direitos autorais”
    https://en.wikipedia.org/wiki/Work_for_hire
    Ainda assim, acho que trabalho em open source — isto é, manutenção e desenvolvimento — deveria ser feito por profissionais remunerados, não por voluntários mendigando doações. A questão central é como tornar isso realidade e como fazer as empresas aceitarem contribuições para open source como prática padrão, e não como exceção que exige negociação caso a caso

    • Os problemas descritos parecem mais “problemas teóricos” do que problemas práticos
      Na prática, basta fazer. Não existe uma sub-rotina dentro do computador impedindo git push. Na prática, empregadores colocam todo tipo de coisa no contrato de trabalho. Escrevem o máximo possível para se isentar de responsabilidade em todas as direções. Se eles podem simplesmente escrever o que quiserem, por que nós não poderíamos simplesmente fazer? Nada importa
      Na prática, o número de projetos open source que foram contestados por propriedade intelectual por esse tipo de motivo técnico é quase zero
    • É verdade que, se o trabalho estiver relacionado às suas funções, o empregador detém a propriedade intelectual
      Se não estiver relacionado, depende do estado. Muitos estados impõem limites ao que o empregador pode reivindicar como sua propriedade intelectual. Contratos padrão tentam redigir isso de forma ampla para reivindicar tudo, mas a lei muitas vezes diz que a empresa não pode ficar com trabalho feito no tempo livre que não tenha relação com o empregador
      Se você fizer isso no horário de trabalho ou usar o notebook da empresa, ela passa a ter base para reivindicar direitos. A maioria das empresas provavelmente não vai se importar, mas se houver disputa, é melhor manter tudo limpo e não ser descuidado
      Trabalhe no seu tempo pessoal, com seu equipamento pessoal, e sem sobreposição com o que você faz no emprego ou com o que conheceu na empresa
    • Não sou advogado, mas se você deu uma cópia para um colega executar, isso por si só já não seria usar uma licença open source? Esse colega então teria os direitos legais concedidos pela licença e também o direito de redistribuir as modificações, não?
      Subir as mudanças para o upstream é a melhor forma de garantir manutenção, então tudo isso parece muito ridículo. O mesmo vale para a incerteza jurídica de manter forks proprietários internos
    • O texto parece sugerir seguir o caminho de menor resistência: fazer no horário da empresa, sem criar muita comoção. Se descobrirem, peça perdão. Do ponto de vista da empresa, perdoar é o caminho mais fácil. Envolver advogados sai muito caro e ainda pode virar um pesadelo de relações públicas
    • Se o estado atual da programação mostrou alguma coisa, é que leis de propriedade intelectual e direitos autorais já não existem mais

  • Trabalho em uma empresa bem grande. A nossa política de open source é mais ou menos: “pergunte antes ao seu gerente, não faça em nome da empresa e não divulgue informações confidenciais”
    Nunca deu problema, e no geral isso me parece totalmente razoável

  • Eu vejo zero problema em contribuir com correções de bugs e coisas do tipo para projetos open source de terceiros no horário de trabalho, mas não sei bem como tratar o seu próprio open source
    Por exemplo, imagine que você tem uma pequena biblioteca criada por você e a empresa passa a usá-la; aí você encontra um bug nela durante o expediente. Contribuir com ela nesse horário me parece uma zona cinzenta
    Alguém já negociou esse tipo de coisa em entrevista? Tenho curiosidade de saber como foi

    • Nunca trabalhei em uma empresa que realmente se importasse com isso. Eu simplesmente fazia o que precisava ser feito. Mesmo quando perguntei como deveria fazer “do jeito certo”, nunca obtive resposta

  • Quando trabalhei em grandes corporações, em geral qualquer pedido para fazer algo que não fosse escrever código diretamente na codebase da empresa recebia do gerente imediato a resposta “faça no seu tempo livre”, por mais justificativa que eu apresentasse
    Em um ambiente voltado ao lucro, tende-se a valorizar só o que parece ter valor imediato. A atitude é bastante parasitária, e a pressão por mais eficiência e competição por métricas, vinda de cima, leva a isso

  • Já fiz fork de algo para corrigir um problema de trabalho e depois enviei o resultado como PR para o upstream
    Esse é um dos bons lados de usar e ter acesso a open source. É também por isso que git é quase uma opção de primeira classe em package.json e cargo.toml: você pode apontar diretamente para o fork até que a mudança seja incorporada upstream

  • Quando você vira sênior, na etapa da entrevista em que perguntam “você tem alguma pergunta para nós?”, eu pergunto: “qual é a posição desta empresa sobre eu dedicar parte do meu tempo aos projetos open source dos quais ela depende?”
    A resposta ajuda a decidir se vale a pena continuar ali