¿Cómo cerrar sesión en un CLA previene problemas legales en proyectos de código abierto?

Por ejemplo: yeoman . Tiene licencia bajo una licencia BSD. El formulario CLA (Acuerdo de licencia de contribuyente) no es específico del proyecto y se puede firmar electrónicamente.

• ¿Cómo y qué problemas puede evitar la firma de este acuerdo?
• ¿Importa la gran o menor contribución que hice?
• ¿Por qué algunos proyectos requieren CLA firmado para aceptar parches, mientras que otros no? (por ejemplo, node.js vs rails)

Los CLA generalmente existen para hacer varias cosas:

• Le impiden revocar su código en el futuro. En los países que son signatarios de la convención de Berna, los autores conservan exclusivamente los derechos de autor de todas las obras originales, y otros pueden copiarlo solo con permiso explícito. Un CLA te obliga a otorgar ese permiso explícitamente, y con frecuencia a perpetuidad, para que no puedas cambiar de opinión más adelante. Este CLA contiene una cláusula de este tipo, por lo que no hay devoluciones de código después de su contribución.
• Pueden evitar que los demande por infracción de patente. Algunos contribuyentes son duplicados y pueden contribuir con un código que saben que está cubierto por una de sus patentes, con la esperanza de que luego demanden a todos en el futuro cuando el código esté muy extendido. Esto ha sucedido en algunos de los principales organismos de normalización y también ha aparecido en software de código abierto. El CLA aquí le prohíbe sacar este truco: cuando envía un código a este proyecto, también les otorga, y a sus usuarios, licencias perpetuas libres de regalías para cualquier patente que posea que cubra el código que usted mismo envíe.
• Cubre su trasero si alguien más los demanda o reclama derechos de autor. La mayoría de los CLA, incluido este, te hacen jurar que todo lo que estás contribuyendo es tuyo. Básicamente, esto sirve como una forma para que Google (o algún otro proyecto anterior), que es demandado por infracción de derechos de autor, señale y diga: Lo siento, pero no fuimos nosotros, fue él.
• Opcionalmente, puede reasignar los derechos de autor, dando a la organización matriz algunos dientes para demandar a los infractores de licencias. Finalmente, mientras que el CLA que vinculó no hace esto, muchos proyectos de código abierto, incluidos todos los ejecutados por la FSF, tienen un CLA que requiere una asignación directa de derechos de autor, lo que significa que cualquier código que envíe tendrá los derechos de autor del proyecto, y no usted. Esto tiene dos ventajas para la organización matriz: no necesitan reunir a todos los contribuyentes si quieren demandar por una violación de código abierto; y no necesitan consultar con los contribuyentes si desean cambiar la licencia en el futuro. La mayoría de los CLA que requieren asignación de derechos de autor también otorgan una licencia perpetua libre de regalías al contribuyente y a sus clientes en una forma inversa a la forma en que funcionan otros CLA. Como se mencionó, este CLA no requiere reasignación de derechos de autor.

La mayoría de los proyectos de voluntariado completo, como Rails y Node, no requieren CLA, por ninguna otra razón que no sea porque no hay una entidad de respaldo que requiera o haga algo significativo con ellos en primer lugar. (Los proyectos respaldados por FSF son la principal excepción aquí, como se señaló anteriormente). La mayoría de los proyectos de código abierto respaldados comercialmente, como los que son productos oficiales de Google / Oracle / Apple, requieren algún tipo de CLA, ambos porque la mayoría de las compañías tienen abogados que piensan acerca de ese tipo de cosas, y porque no es una sola entidad de respaldo para hacer cumplir ese tipo de cosas.

Los CLA también podrían (además de otras cosas mencionadas en esta página) proteger a los contribuyentes de problemas legales. Eche un vistazo a este extracto de un CLA de Google :

No se espera que brinde asistencia para Sus Contribuciones, excepto en la medida en que desee brindar asistencia. Puede brindar soporte de forma gratuita, por una tarifa, o en absoluto. A menos que lo exija la ley aplicable o se acuerde por escrito, Usted proporciona sus Contribuciones "TAL CUAL", SIN GARANTÍAS O CONDICIONES DE NINGÚN TIPO, expresas o implícitas, incluidas, entre otras, cualquier garantía o condición de TÍTULO, NO- INFRACCIÓN, COMERCIABILIDAD O APTITUD PARA UN PROPÓSITO EN PARTICULAR.

La respuesta de Benjamin fue bastante clara, pero me gustaría enfatizar un solo punto. Los CLA protegen a las empresas que usan o contribuyen a proyectos. Las empresas, particularmente las grandes, están aterrorizadas de ser sorprendidas por problemas legales. He tenido abogados corporativos que le han dicho a la gente que sé que incluso en casos de clavada donde la ley está de su lado, solo puede estar aproximadamente 60% seguro de que ganará el caso.

Considere la situación de una empresa, particularmente una muy grande con muchos ingresos, crea un producto alrededor de una herramienta de código abierto. Ganan clientes, construyen infraestructura y contratan empleados. Si de repente un contribuyente a la herramienta original los demanda por infracción de patentes o derechos de autor, la compañía está en una gran cantidad de agua caliente legal. Si dejan de proporcionar su producto, han desperdiciado dinero en infraestructura y empleados que no necesitan y, lo que es más importante, están molestando a los clientes. Por otro lado, si dejan de proporcionar su proyecto, su responsabilidad finaliza mientras se resuelve el caso.

Teniendo en cuenta el panorama actual del software legal, los CLA son la mejor manera de hacer que las empresas se sientan cómodas usando y contribuyendo al software de código abierto. No es ideal (sería bueno no tener que lidiar con ninguna de estas cosas legales), pero en este momento es una de las pocas formas de hacer estas contribuciones pos.