Como a assinatura de um CLA evita problemas legais em projetos de código aberto?

Por exemplo: yeoman . É licenciado sob uma licença BSD. O formulário CLA (Contrato de licença do colaborador) não é específico do projeto e pode ser assinado eletronicamente.

• Como e quais problemas a assinatura deste contrato pode impedir?
• Importa quão grande ou menor contribuição eu fiz?
• Por que alguns projetos exigem CLA assinado para aceitar patches, enquanto outros não? (por exemplo, node.js vs trilhos)

Os CLAs geralmente existem para fazer várias coisas:

• Eles impedem que você revogue seu código no caminho. Nos países signatários da convenção de Berna, os autores retêm exclusivamente os direitos autorais de todas as obras originais, sendo permitido a outros copiá-las apenas com permissão explícita. Um CLA faz com que você conceda essa permissão explicitamente - e com frequência perpetuamente, para que você não possa mudar de idéia mais tarde. Este CLA contém essa cláusula, portanto, não há devoluções de código após a contribuição.
• Eles podem impedir que você os processe por violação de patente. Alguns contribuidores são duplicados e podem contribuir com o código que eles sabem que está coberto por uma de suas patentes, na esperança de que eles processem todos no futuro quando o código for difundido. Isso aconteceu em alguns órgãos importantes de padrões e também surgiu em software de código aberto. O CLA aqui proíbe que você faça esse truque: ao enviar o código para este projeto, você também concede a eles e seus usuários licenças perpétuas de royalties gratuitas para quaisquer patentes que você possui que cobrem o código que você mesmo envia.
• Ele cobre sua bunda se alguém outra processa-los ou reivindicações de direitos de autor. A maioria dos CLAs, incluindo este, faz você jurar que tudo o que você está contribuindo é seu. Isso basicamente serve como uma maneira para o Google (ou algum outro projeto upstream), que é processado por violação de direitos autorais, apontar para você e dizer: Desculpe, mas não fomos nós, era ele.
• Opcionalmente, pode reatribuir direitos autorais, dando à organização-mãe alguns dentes para processar os infratores da licença. Por fim, embora o CLA que você vinculou não faça isso, muitos projetos de código aberto, incluindo todos executados pela FSF, têm um CLA que requer atribuição total de direitos autorais, o que significa que qualquer código que você enviar terá os direitos autorais do projeto, e não você. Isso tem duas vantagens para a organização pai: eles não precisam reunir todos os colaboradores, se quiserem processar por uma violação de código aberto; e eles não precisam consultar os colaboradores se desejam alterar a licença no futuro. A maioria dos CLAs que exigem atribuição de direitos autorais também concede uma licença perpétua e isenta de royalties de volta ao colaborador e seus clientes, de uma forma inversa à maneira como outros CLAs funcionam. Como mencionado, este CLA não requer reatribuição de direitos autorais.

Projetos mais voluntários, como Rails e Node, não exigem CLAs, por nenhuma outra razão senão porque não há uma entidade de apoio que exija ou faça algo significativo com eles em primeiro lugar. (Os projetos apoiados pela FSF são a principal exceção aqui, como observado anteriormente.) A maioria dos projetos de código aberto apoiados comercialmente, como aqueles que são produtos oficiais do Google / Oracle / Apple, exigem algum tipo de CLA, porque a maioria das empresas possui advogados. que pensam sobre esses tipos de coisas, e porque não é uma entidade única apoio para impor esse tipo de coisa.

Os CLAs também podem (além de outras coisas mencionadas nesta página) proteger os colaboradores de questões legais. Veja este trecho de um CLA do Google :

Não é esperado que você forneça suporte para suas contribuições, exceto na medida em que desejar fornecer suporte. Você pode fornecer suporte gratuitamente, por uma taxa ou de forma alguma. A menos que exigido pela lei aplicável ou acordado por escrito, Você fornece Suas contribuições "COMO ESTÃO", SEM GARANTIAS OU CONDIÇÕES DE QUALQUER TIPO, expressas ou implícitas, incluindo, sem limitação, quaisquer garantias ou condições de TÍTULO, NÃO INFRACÇÃO, COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM OBJETIVO ESPECÍFICO.

A resposta de Benjamin foi bastante clara, mas eu gostaria de enfatizar um único ponto. Os CLAs protegem as empresas que usam ou contribuem para projetos. As empresas, principalmente as grandes, têm pavor de serem pegos de surpresa por questões legais. Já tive advogados corporativos dizendo às pessoas que sei que, mesmo em casos slam dunk em que a lei está do seu lado, você pode ter apenas 60% de certeza de que vencerá o caso.

Considere a situação de uma empresa, particularmente uma muito grande e com muita receita, que cria um produto em torno de uma ferramenta de código aberto. Eles conquistam clientes, constroem infraestrutura e contratam funcionários. Se, de repente, um colaborador da ferramenta original os processa por violação de patente ou direitos autorais, a empresa está com muita água quente legal. Se eles param de fornecer seu produto, desperdiçam dinheiro com infraestrutura e funcionários de que não precisam e, mais importante, estão irritando os clientes. Por outro lado, se eles param de fornecer seu projeto, sua responsabilidade termina enquanto o caso é descoberto.

Considerando o atual cenário jurídico de software, os CLAs são a melhor maneira de fazer com que as empresas se sintam confortáveis ​​usando e contribuindo para o software de código aberto. Não é o ideal (seria bom nunca ter que lidar com nada disso legal), mas agora é uma das poucas maneiras de fazer essas contribuições