CLAs, canónicas e excepcións.

Matthew Garrett fíxoo recentemente un artigo interesante explicando os acordos de licenza do contribuínte, compilados por muktware. Escribirei baseándome nos 2 artigos.

Os acordos de licenza dos contribuíntes ("CLAs") son un mecanismo para que un desenvolvedor ascendente insista en que os contribuíntes lles outorgan un conxunto adicional de dereitos. Estes varían no alcance: algúns CLA requiren que o colaborador reasigne os seus dereitos de autor na contribución ao desenvolvedor ascendente, outros simplemente outorgan ao desenvolvedor ascendente unha concesión de dereitos que non están explícitos na licenza de software (como unha concesión explícita de patentes para un BSD contribución con licenza).

Os CLA úsanse máis que nada para defender un produto ou un proxecto como distribuidores. Se distribuíse software con código de varios colaboradores, sen CLA, non tería dereito a defender o proxecto en caso de conflito, xa que só poden intervir os autores das contribucións. O que fan as CLA é outorgarme, como distribuidor, certos dereitos sobre o código para poder defendelo sen necesidade de que cada un dos colaboradores interveña. Faise máis doado se o proxecto conta con centos de colaboradores.

Os CLA non son novos. Proxectos FSF teñen o seu CLA no que os colaboradores deben asignar a súa autoría á FSF e a cambio prometen que o devandito código estará sempre baixo unha licenza tipo GPL. Durante unha década, os proxectos de Apache Software Foundation requiren colaboradores para asinar un CLA iso permítelles conservar os seus dereitos de autor, pero dálle a ASF o dereito de volver licenciar a súa contribución baixo calquera licenza. Do mesmo xeito, a licenza Apache non é copyleft.

Agora, ultimamente está de moda acadar Canonical polo seu CLA. Por que motivo? Se o fixas proxectos usando CLAs, a maioría son proxectos con licenzas BSD ou Apache, e algúns con licenzas GPL que prometen que calquera contribución só se distribuirá baixo unha licenza GPL. É dicir, ou cada un pode facer o seu propio garfo, ou ningún deles o fai.

Canonical é a excepción.

O CLA de Canonical é similar ao de Apache, é dicir, require que os seus colaboradores asinen un acordo que permita a Canonical volver licenciar as súas contribucións baixo calquera licenza e os contribuíntes conservan a propiedade. O problema é que o software baixo o seu CLA é GPLv3. Vexa o que pode ocorrer e verá por que moitos colaboradores teñen tanto medo de contribuír a proxectos como Mir, Unity, Upstart, LightDM, Ubuntu One e outros proxectos de Ubuntu.

Non obstante, tampouco está mal. Por que? Porque unha merda similar foi a que permitiu liberar o código QT. A palabra de Stallman:

Vender excepcións significa que o titular dos dereitos de autor do código libera o código baixo unha licenza de software libre e permite aos clientes pagar o permiso para usar o mesmo código en termos diferentes, por exemplo, permitindo a súa inclusión en aplicacións propietarias. Isto é diferente das extensións propietarias ou versións propietarias dun programa gratuíto. Cando se vende unha excepción, o código segue sendo gratuíto para o público. Pero unha extensión propietaria segue sendo propietaria.

O contorno KDE desenvolveuse nos anos 90 baseándose nas bibliotecas Qt. Qt era software propietario naquel momento e TrollTech cobrou permisos para incorporalo en aplicacións propietarias. TrollTech permitiu o uso gratuíto de Qt en aplicacións libres, pero este non era software libre. Os sistemas operativos 100% libres, polo tanto, non podían incluír Qt e tampouco podían usar KDE.

En 1998, a administración de TrollTech decatouse de que podían volver ao software libre QT e seguir cobrando permisos para incrustalo no software propietario. Non estou seguro de se a suxestión foi miña, pero estiven feliz de ver o cambio, que fixo posible que QT e KDE se puidesen empregar no mundo do software libre. Nun principio usaron a súa propia licenza, a Q Public License e máis tarde cambiárona á GNU GPL (agora QT está baixo a LGPL).

A venda de excepcións depende fundamentalmente do uso dunha licenza copyleft, como a GNU GPL, para a súa liberación como software libre. Unha licenza copyleft permite incorporar a un programa máis grande só se se publica todo o programa combinado baixo a mesma licenza; así garante que as versións estendidas tamén sexan gratuítas. Polo tanto, os usuarios que queiran facer o propietario do programa combinado requiren un permiso especial. Só o propietario pode conceder este permiso e vender excepcións é un xeito de facelo. Calquera outra persoa que recibise o código baixo a licenza GNU GPL ou outra licenza copyleft, non pode conceder unha excepción.

Volvendo ao artigo de Garrett, Greg Kroah-Hartman comentou de acordo co artigo, máis ben que os CLA son "arranxos limitadores da comunidade". Pero Linus vai máis alá e di: "Para ser xustos, á xente gústalle odiar Canonical. Os CLA de FSF e ASF están igual de rotos, e non por unha nova licencia, senón porque o trámite de cesión de dereitos de autor acaba matando á comunidade ".

Todo este artigo foi escrito baseado no debate Systemd vs Upstart e no rexeitamento xeneralizado da CLA de Canonical por aqueles que apoian systemd, que non tería xurdido se non fose por iso e por motivos de deseño.