CLAs, Canonical y Excepciones.

Hace poco Matthew Garrett hizo un artículo interesante explicando los Acuerdos de Licencia del Contribuyente, que fue recopilado por Muktware. Voy a escribir basándome en los 2 artículos.

Los Acuerdos de Licencia del Contribuyente («CLAs») son un mecanismo para que un desarrollador del upstream insista a los contribuyentes que le otorguen un conjunto adicional de derechos. Estos varían en extensión – algunos CLAs requieren que el contribuyente reasigne sus derechos de autor sobre la contribución al desarrollador upstream, otros meramente otorgan al desarrollador upstream una concesión de derechos que no son explícitos en la licencia de software (como una concesión de patentes explícita para una contribución con licencia BSD).

Los CLAs son usados más que nada para defender a un producto o un proyecto como distribuidores. Si yo distribuyera un software que tiene código de varios contribuyentes, sin un CLA no tendría el derecho de defender el proyecto en casos de conflicto, puesto que sólo pueden intervenir los propios autores de las contribuciones. Lo que los CLAs hacen es otorgarme como distribuidor, ciertos derechos sobre el código para que pueda defenderlo sin necesidad de que intervengan cada uno de los contribuyentes. Se vuelve más fácil si el proyecto tiene cientos de contribuyentes.

Los CLAs no son nuevos. Los proyectos de la FSF tienen su CLA en el que los contribuyentes deben asignarle su autoría a la FSF y a cambio prometen que dicho código siempre estará bajo una licencia del tipo GPL. Durante una década, los proyectos de la Apache Software Foundation requieren que los contribuyentes firmaran un CLA que les permitiera retener sus derechos de autor, pero le otorga a la ASF el derecho de relicenciar su contribución bajo cualquier licencia. Igual la licencia Apache no es copyleft.

Ahora, ultimamente está de moda pegarle a Canonical por su CLA. ¿Por qué razón? Si se fijan en los proyectos que usan CLAs, la mayoría son proyectos con licencias tipo BSD o Apache, y unos pocos con licencias tipo GPL que prometen que cualquier contribución será sólamente distribuida bajo una licencia tipo GPL. O sea, o todos pueden hacer su fork privativo, o ninguno lo hace.

Canonical es la excepción.

El CLA de Canonical es similar al de Apache, o sea pide que sus contribuyentes firmen un acuerdo que permita a Canonical relicenciar sus contribuciones bajo cualquier licencia y los contribuyentes conservan la autoría. El problema es que el software que está bajo su CLA es GPLv3. Fíjense que puede pasar y verán por qué muchos contribuyentes tienen tanto miedo a contribuir a proyectos como Mir, Unity, Upstart, LightDM, Ubuntu One y otros proyectos de Ubuntu.

Sin embargo, eso tampoco es malo. ¿Por qué? Porque una chanchada similar fue lo que permitío que se liberara el código de QT. Palabra de Stallman:

Vender excepciones significa que el titular de los derechos de autor del código libere el código bajo una licencia de software libre, y que permita que los clientes paguen por un permiso para usar el mismo código bajo terminos diferentes, por ejemplo permitir su inclusión en aplicaciones propietarias. Esto es distinto a las extensiones propietarias o versiones propietarias de un programa libre. Cuando se vende una excepción, el código sigue estando libre para el público. Pero una extensión propietaria sigue siendo propietaria.

El entorno KDE fue desarrollado en los 90s basado en las librerías Qt. Qt era software propietario en aquel entonces, y TrollTech cobraba permisos para embeberlo en aplicaciones propietarias. TrollTech permitía el uso gratuito de Qt en aplicaciones libres, pero esto no lo hacía software libre. Los sitemas operativos 100% libres por lo tanto no podían incluir Qt, y tampoco podían usar KDE.

In 1998, la administración de TrollTech se dio cuenta que podían volver a QT software libre y seguir cobrando permisos para embeberlo en software propietario. No reguerdo si la sugerencia fue mía, pero me sentí feliz al ver el cambio, lo cuaal hizo posible que se usaran QT y KDE en el mundo del software libre. Al principio usaron su propia licencia, la Q Public Licence y luego la cambiaron por la GNU GPL (ahora QT esta bajo la LGPL).

Vender excepciones depende fundamentalmente de usar una licencia copyleft, como la GNU GPL, para la liberación como software libre. Una licencia copyleft permite el embebido en un programa más grande sólo si todo el programa combinado es liberado bajo la misma licencia; así es como asegura que las versiones extendidas sean también libres. Por lo tanto, los usuarios que quieran volver propietario el programa combinado requieren un permiso especial. Sólo el titular puede otorgar dicho permiso, y vender excepciones es una manera de hacerlo. Cualquier otro, que recibió el código bajo la GNU GPL u otra licencia copyleft, no puede otorgar una excepción.

Volviendo al artículo de Garrett, Greg Kroah-Hartman comentó estar de acuerdo con el artículo, que más bien los CLAs son «Arreglos que Limitan la Comunidad». Pero Linus va más allá y dice «Para ser justos, a la gente le gusta odiar a Canonical. Las CLAs de la FSF y la ASF están igual de rotas, y no por el relicenciamiento sino porque el papeleo de la asignación de derechos de autor acaba matando la comunidad.»

Todo este articulo fue escrito en base al debate Systemd vs Upstart y al rechazo generalizado hacia la CLA de Canonical por quienes apoyan a systemd, el cual no hubiera surgido si no fuese por esto y por cuestiones de diseño.