As regulamentações de código aberto têm requisitos incomuns para o sucesso. Saiba como os advogados de código aberto podem ajudar seus empregadores a encontrar um caminho viável a seguir.
Conforme compartilhei na primeira parte desta série de duas partes , sou advogado de código aberto na Red Hat. Uma parte importante do meu trabalho é fornecer informações a outras empresas, incluindo seus consultores internos, sobre como a Red Hat está adotando um modelo de desenvolvimento totalmente open source para criar produtos de nível empresarial e responder às suas perguntas gerais sobre licenciamento de código aberto. Depois de ouvir sobre os sucessos da Red Hat, a conversa que esses advogados têm comigo muitas vezes se volta para como suas organizações podem evoluir para organizações mais conscientes e capazes de código aberto, e eles muitas vezes me perguntam como podem melhorar suas práticas para se tornarem mais proficientes no fornecimento de código aberto. assessoria jurídica aos funcionários de suas organizações. Nestes dois artigos, compartilharei o que normalmente digo aos advogados internos sobre esses tópicos.
Sempre encontre um caminho viável
O que torna meu empregador, a Red Hat, único no uso de software de código aberto é que nosso modelo de desenvolvimento começa com uma comunidade de código aberto com milhares de colaboradores e resulta em um produto final que é experimentado, testado e confiável. Mais especificamente, através do nosso modelo de desenvolvimento exclusivo, começamos com software de código aberto criado pela comunidade e trabalhamos em cada projeto para fortalecer a segurança, corrigir bugs, corrigir vulnerabilidades e adicionar novos recursos. Em seguida, contribuímos com essas melhorias em cada projeto para que beneficiem toda a comunidade de código aberto. Os benefícios desta abordagem são importantes e incluem:
- Alavancar a inovação externa através da colaboração entre equipes internas e outras fora da organização;
- Quando uma comunidade existente ou potencial está trabalhando no mesmo problema que você e pode colaborar, você evita os custos e as ineficiências de desenvolver e manter você mesmo uma solução de código aberto;
- Através da colaboração produtiva com parceiros e a comunidade do projecto a montante, a manutenção dispendiosa das filiais a jusante do projecto principal pode ser evitada.
- Algumas empresas acham tentador criar ramificações não públicas de código upstream porque é uma maneira rápida de resolver um caso de uso específico ou porque não estão dispostas a colaborar na comunidade. No entanto, a carga de manutenção a longo prazo de tal ramo pode ser proibitiva devido ao aumento dos custos de desenvolvimento, perda de interoperabilidade e outras razões. Em contraste, a centralização do desenvolvimento na comunidade original a montante distribui os custos de desenvolvimento entre todos os participantes.
Com algumas exceções (como a Red Hat), a maioria das organizações que usam software de código aberto provavelmente possui um modelo de licenciamento de software proprietário (ou equivalente SaaS) e licencia software proprietário como parte de seus negócios. Estas organizações acreditam que possuem componentes de software que proporcionam alguma vantagem competitiva e não querem que esses componentes sejam disponibilizados a terceiros sob termos de código aberto. Isto é incompreensível. No entanto, eu encorajaria qualquer advogado de código aberto consultado sobre tais assuntos a instar seus clientes a adotarem um modelo de desenvolvimento de código aberto, especialmente para todos os softwares indiferenciados e comuns.
Por exemplo, se sua empresa desenvolve um aplicativo para telefones celulares e você precisa de um módulo de software para ler e gravar arquivos de imagem PNG, será muito mais barato usar um dos populares módulos de software PNG de código aberto no GitHub. Codificar e decodificar imagens PNG pode ser indistinguível para o seu negócio, então por que gastar um tempo valioso de engenharia escrevendo sua própria versão? Além disso, escrever seu próprio módulo para esta funcionalidade também pode causar problemas de compatibilidade com outro software que usa módulos de código aberto comumente disponíveis. Por que é isso? Embora seus módulos e módulos de código aberto possam ter sido escritos para codificar e decodificar a especificação PNG publicada, às vezes a especificação pode ser interpretada de maneira diferente e podem ocorrer erros de implementação. Todos que usam o mesmo módulo para executar essa funcionalidade garantem compatibilidade para a maioria dos usuários e reduzem custos de desenvolvimento e manutenção.
Também é importante perceber que você pode precisar que algum software permaneça proprietário e não esteja sujeito a termos de código aberto. Dependendo da arquitetura de software do seu sistema e da licença de código aberto utilizada, o código de software que se destina a permanecer proprietário poderá ficar sujeito aos termos da licença de código aberto, a menos que determinadas medidas (além do escopo deste artigo) sejam tomadas. É aqui que seria útil fornecer alguns serviços de consultoria aos clientes em relação à seleção e arquitetura de licenças.
Encontre soluções flexíveis
As organizações que anteriormente licenciavam principalmente software proprietário estão aumentando gradualmente o uso de software de código aberto, mas os requisitos para revisão e aprovação provavelmente aumentarão (até mesmo exponencialmente, na minha experiência). Essas organizações podem ter dificuldades devido a restrições de recursos. Aqui estão algumas soluções flexíveis que você pode adotar.
Autorizar e delegar a outros
Os advogados não podem e não devem ser guardiões. Isso é ineficiente e certamente levará a gargalos nos tempos de desenvolvimento e lançamento, criando frustração e perda de receita. Em vez disso, a autoridade de aprovação deve ser concedida a indivíduos competentes em gestão e engenharia de produtos ou projetos. Isso permite que as organizações permaneçam efetivamente flexíveis. Educar seus clientes (veja a próxima seção) é fundamental para conseguir isso com sucesso.
Uma abordagem que adoto é fornecer treinamento de código aberto para toda a organização de engenharia, para que possam fazer escolhas básicas de modelo de licenciamento e arquitetura, ao mesmo tempo em que forneço treinamento mais especializado aos desenvolvedores de software para permitir que forneçam orientações e decisões mais complexas. Considere também limites claros de permissões em cada nível, incluindo quais tipos de problemas e decisões devem ser encaminhados a você como advogado de código aberto. O nível de autorização específico da sua organização dependerá da experiência da sua equipe com código aberto e da sensibilidade a determinados problemas de código aberto.
Eduque os clientes
Descobri que o treinamento é uma das ferramentas mais eficazes para migrar sua organização para uma organização com mentalidade mais aberta. Treinar seus engenheiros de software e gerentes de produto é fundamental. Deixe-me elaborar.
Embora seus engenheiros de software estejam na vanguarda e geralmente tenham muito conhecimento sobre questões de código aberto e licenciamento de software, ainda é importante treiná-los com base nos requisitos específicos da sua organização. Por exemplo, sua empresa pode permitir apenas o uso de licenças permissivas de código aberto e pode ter determinados requisitos para aviso de direitos autorais e disponibilidade de código-fonte. Para evitar problemas no desenvolvimento que devem ser corrigidos posteriormente (uma prática cara e demorada), é melhor treinar engenheiros para minimizar a possibilidade de comportamento inadequado, especialmente no início de qualquer processo de desenvolvimento (ver próxima seção).
Os gerentes de produto também devem receber treinamento. Em muitas empresas, os gerentes de produto são responsáveis pelos quatro aspectos clássicos do marketing (produto, preço, posicionamento e promoção) e por todo o ciclo de vida de um produto, do berço ao túmulo. Todos os aspectos do trabalho de um gerente de produto podem ser afetados pelo uso de software de código aberto. Pelas mesmas razões mencionadas acima, é útil que eles compreendam os requisitos para usar software de código aberto. Além disso, e mais importante, a influência significativa dos gestores de produto dentro de uma organização significa que muitas vezes são capazes de fazer as alterações necessárias nos processos e políticas. Os gerentes de produto podem ser um dos seus mais fortes defensores de mudanças nos processos para a Abertura.
Detecção precoce
Resolver problemas de licenciamento de código aberto próximo ao final do processo de desenvolvimento é difícil e caro. À medida que a data de lançamento do software se aproxima, a arquitetura e os módulos do software de código aberto são escolhidos e difíceis de alterar. Se um problema for detectado, como software "copyleft" incorporado em um módulo de software proprietário (quando esse módulo proprietário não se destina a estar sujeito a termos de código aberto), modificar a arquitetura ou o módulo neste estágio de desenvolvimento pode ser difícil e caro caro. Em vez disso, o processo de análise arquitetônica e seleção de módulos de código aberto deve ocorrer no início do processo de desenvolvimento, para que possam ser feitas correções menos dispendiosas e mais eficazes.
As “recompensas” das regulamentações de código aberto
Praticar a regulamentação de código aberto é uma carreira gratificante porque a capacidade de influenciar uma organização em uma direção “aberta” traz grandes benefícios. O sucesso depende da sua capacidade de encontrar soluções viáveis e flexíveis à medida que sua organização cresce e amadurece.
Sobre o autor: Jeffrey R. Kaufman é consultor jurídico empresarial sênior na equipe jurídica de código aberto da Red Hat, fornecedora líder mundial de soluções de software de código aberto. Ele também atua como professor adjunto de direito na Universidade da Carolina do Norte. Antes de ingressar na Red Hat, Jeffrey atuou como consultor de patentes e código aberto da Qualcomm.
Perfil do tradutor: Xue Liang, diretor do Departamento de Negócios de Internet da Jihuizhijia Intellectual Property Consulting Company, é bom em análise de patentes, layout de patentes, rastreamento de concorrentes, análise de FTO e análise de risco de propriedade intelectual de software de código aberto. e empresas de alta tecnologia com serviços de consultoria em propriedade intelectual.
