Selecció d’una llicència¶
Un tema important per a un nou projecte de programari lliure (o l’alliberament de programari existent) és seleccionar la llicència de distribució.
N’hi ha moltes!
Mentre que la FSF recomana l’ús de la GPL (gairebé exclusivament!), en general es recomana utilitzar una llicència ja existent en comptes d’escriure’n una de nova. Això cada cop és més difícil, amb la proliferació de llicències lliures i de codi obert (fins al punt que la OSI està tractant de reduir el nombre de llicències certificades). Una tendència general és limitar-se a una de les llicències més comunes (GPL, LGPL, BSD, MPL, Apache, CPL, etc.). L’avantatge d’això és augmentar les probabilitats de la compatibilitat entre programes i components.
Una altra possibilitat és limitar-se a una llicència de «tercera generació» com la OSL (copyleft/recíproca), l’Apache o la AFL (permissives) o la CDDL (intermèdia), que cobreixen més temes rellevants (palesos, marques, etc.) i que poden ser més adequades al marc legal europeu, degut a una voluntat d’internacionalització en el moment de la seva redacció.
Per la selecció de la llicència s’han de considerar dues coses:
d’una banda, els objectius estratègics, tècnics, comercials (si escau) i ètics de l’alliberament de programari i les “condicions prèvies”, i
per l’altre, les característiques de les llicències “candidates”.
Objectius i “condicionants”¶
Una primera consideració és determinar quins són els objectius en alliberar programari. Serà per raons purament filosòfiques? En aquest cas, potser no importa el que es farà amb el programari en posteriors distribucions. O serà per proveir solucions comercials basades en aquest programari un cop alliberat (i aprofitar la comunitat creada per millorar el nucli del codi)? Potser sigui perquè és un codi universitari o el resultat d’una investigació, en aquest cas hi hauria raons més relacionades amb la difusió del coneixement. O podria ser part d’una iniciativa de l’administració pública o una altra institució que té una política ja determinada.
Un factor crític en l’alliberament de programari és considerar quins altres components de programari lliure s’incorporen, s’integren o es distribueixen amb el programa en qüestió. No serveix de res triar una llicència permissiva si un component fonamental es distribueix sota una llicència amb copyleft, com la GPL o la CPL. Recíprocament, no és raonable triar la GPL si s’ha d’integrar amb un programa sota una llicència incompatible amb aquesta (la FSF a la seva web proveeixi una llista de les llicències compatibles o no amb la seva llicència, segons la seva opinió) (vegeu Incompatibilitats de llicència).
Un altre element que podria tenir certa influència en aquesta selecció és el tipus de programari del projecte. Per exemple:
Programari d’usuari final (Mozilla, OpenOffice.org): en aquest cas, és menys probable que les funcions bàsiques es modifiquin per tercers per a crear obres derivades que “competeixin” amb aquest codi. Potser no caldrà intentar controlar (mantenir la llibertat) d’aquestes obres derivades. Tot i així, seria interessant permetre a tercers integrar components, extensions, etc. en el producte.
Programari que és part d’un sistema operatiu o middleware: en aquest cas, és més probable que tercers vulguin integrar el seu codi amb el programari alliberat i crear obres derivades. Com s’ha de redistribuir el resultat d’aquesta integració?
Part d’un entorn de desenvolupament o d’un llenguatge de programació (SDK, IDE, etc.): les eines per a crear altres productes solen tenir altres característiques i usuaris. Aquests són enginyers informàtics, usuaris finals del les eines… però potser el programari creat amb aquestes eines inclou llibreries comunes (que serveixen pel desenvolupament i formen part del programa final).
Programari que s’integra amb d’altres (amb una llicència establerta), com llibreries. Per a la major difusió i ús de les llibreries, una llicència permissiva (o amb copyleft suau, com la LGPL) podria ser la més adequada.
Des de la perspectiva legal, és important considerar si el programari serà utilitzat “tal qual”, sense modificacions, o si és més probable que es modifiqui i s’integri en sistemes o solucions més complexes. En aquest cas, els usuaris crearan obres derivades i el projecte haurà de considerar el grau de permissivitat o llibertat que vulgui donar a la distribució d’aquests productes derivats.
Altres factors
Uns altres factors són:
El tipus d’usuari (intermedi o final): quines necessitats té, quins usos, què faran amb el codi, com es pot maximitzar (a través d’una llicència “amigable”) la seva adopció del programari i el feedback o participació en la comunitat del projecte?
Els contribuïdors: quin tipus de contribució s’espera de la “comunitat” potencial? Ja són membres d’una comunitat lliure (GNU/Linux, Apache)? En aquest cas potser s’hauria d’adoptar la llicència dominant d’aquesta comunitat (o, almenys, una compatible).
El model de negoci (si s’escau): si el programari és part d’una iniciativa comercial, s’haurà de considerar el model de negoci contemplat pel futur. Els ingressos provindran de la venda de llicències (per exemple, sota una política de llicenciament dual, com la MySQL)? Es donaran serveis de valor afegit sobre el producte, suport de segon nivell, components addicionals o paquets “avançats” o “professionals”, s’oferiran garanties i suport…? En cada cas, els criteris per a la llicència seran diferents.
Aquesta llista de factors no és exhaustiva i cada projecte haurà de considerar les seves circumstàncies particulars.
Característiques de les llicències¶
La segona part de l’operació consisteix a adequar una llicència a aquests factors o criteris.
Abans d’esmentar les diferències, és útil recordar que totes les llicències lliures tenen els pactes següents en comú:
La cessió de drets de còpia, modificació i distribució del programa
L’obligació de mantenir l’avís dels drets d’autor
L’exclusió de garanties relatives al programari i la limitació de qualsevol responsabilitat del proveïdor i/o fabricant.
La llicència més simple, per exemple la MIT, conté només aquestes tres clàusules. Per tant, la selecció de la llicència dependrà de les característiques particulars.
Copyleft¶
El principal criteri de diferenciació és l’existència o no de pactes de “copyleft” o de “reciprocitat”: l’obligació que els desenvolupaments basats en el programari original (obres derivades, generalment) i, segons la GPL, altres obres que inclouen el codi original sota GPL, mantinguin la mateixa llicència per a la redistribució. Així mateix, cal oferir a qualsevol l’accés a l’aplicació modificada si aquesta es distribueix a tercers. Això garanteix que el programari lliure sempre queda lliure i es va ampliant el “pool” de programari lliure a mesura que els desenvolupadors incorporen programari amb copyleft en les seves aplicacions. No és pot “privatitzar” una aplicació distribuïda sota termes de copyleft. Cal notar que l’efecte de copyleft únicament s’aplica o “s’activa” en cas que el programa es redistribueixi, per tant una persona que només utilitzi o modifiqui una aplicació sota GPL (al seu negoci, o a casa) no té cap obligació de publicació ni redistribució.
La llicència recíproca per excel·lència és la llicència GPL. El seu efecte de copyleft «fort» o «robust» fa que no es pugui incorporar programari sota aquesta llicència en aplicacions que després es distribueixin sota llicència propietària o sota qualsevol altra llicència que no sigui la llicència GPL. L’ús de la llicència GPL té diversos avantatges:
No es pot privatitzar el codi, abusant de les llibertats originals del codi. Per tant altres empreses desenvolupadores (i competitives) no poden aprofitar-se dels esforços de l’autor original.
La majoria de les variacions i adaptacions del programari tornaran a la comunitat, publicades a Internet. Per tant, es podrà tornar a incorporar dintre del programa original (el codi base) qualsevol millora o ampliació realitzada per un tercer. Això tendeix a reduir el “forking” (l’establiment de projectes paral·lels que distribueixen una variació del codi original).
L’aplicació podrà integrar-se amb qualsevol altre programari sota GPL. Això significa un 75% o més dels projectes lliures existents.
Altres llicències amb copyleft són la llicència CPL, de IBM; o la llicència Sleepycat (de la base de dades Berkeley Database). La CPL no és compatible amb la GPL perquè duu obligacions de publicació i cessions de drets de patents.
Copyleft moderat o suau¶
Altres llicències tenen un efecte copyleft reduït: el seu efecte s’aplica únicament a l’obra (o component) original i qualsevol modificació d’ella. No s’estén a aplicacions que “integren” o “usen” el component lliure. La llicència LGPL és típica d’aquesta sèrie, on també figuren altres llicències com la Mozilla PL (MPL), la CDDL i la OSL. Aquestes permeten la integració o vinculació dels components originals amb altres codis, per crear el que es diuen “obres majors”. Aquestes poden distribuir-se com un tot sota qualsevol llicència, sempre que el component original quedi disponible sota la seva pròpia llicència. S’utilitzen sovint per a llibreries o altres components de programari lliure usats per altres programes.
Altres criteris¶
Les diferents llicències s’han redactat per a plantar cara o resoldre diversos temes i necessitats dels seus autors. Alguns aspectes particulars que han dut a incorporar nous pactes i crear noves llicències inclouen els següents casos:
El control de marca (per exemple la Zope, l’Apache 1.0): aquestes llicències tenen pactes referents a l’ús de la marca. Zope impedeix el seu ús sense l’autorització de la Zope Corporation, mentre que una llicència modelada sobre l’Apache 1.0 obligaria l’ús d’una marca en qualsevol programa que es basi en el programari i el reconeixement corresponent en qualsevol documentació que acompanyi el programa.
Avisos de modificacions (gairebé totes, excepte la BSD i la MIT): la majoria de les llicències obliguen a qualsevol persona que modifiqui el programari a indicar quines són les seves modificacions i quan es van realitzar.
Llicències de patents (ex. la MPL 1., la CPL, l’Apache 2.0, la CDDL): la segona i tercera generació de llicències (a partir de la MPL 1.0) inclouen pactes relatius a les patents: d’una banda, el llicenciant i els contribuidors cedeixen drets d’ús de patents als llicenciataris; d’altra banda, es preveu la revocació de la llicència si un llicenciatari iniciés una demanda basada en patents contra un llicenciant.
Implementació d’estàndards (ex. la Sun Industry Standards SL): la SISSL és una llicència una mica particular que obliga que qualsevol modificació es complementi amb estàndards identificats en un annex.
Possibilitat de diverses llicències (ex. la MPL 1.1): a causa de la necessitat de compatibilitat entre aplicacions, hi ha algunes llicències que inclouen pactes que permeten distribuir el codi sota altres llicències (llicències duals o múltiples). La més coneguda és la llicència MPL 1.1, que permet usar la MPL o altres llicències alternatives (segons permeti l’autor original).
Pegats (ex. la QPL): algunes llicències obliguen a qualsevol que modifiqui el programari a distribuir les modificacions en forma de pegats sobre el programari original.
Aplicació a distribucions ASP (ex. la Apple 2.0, la OSL, la CDDL, l”Affero): aquestes llicències estenen l’efecte de copyleft (parcial o total) a programari utilitzat per a oferir serveis web (model de tipus ASP). Qualsevol proveïdor de serveis ASP que utilitzi programari amb aquest tipus de llicència ha d’oferir als usuaris accés al codi font, encara que tècnicament no hi hagi cap distribució de programari.
Més d’una llicència¶
Un altra opció és triar una política de llicenciament dual (vegeu Estratègies de llicències duals). Aquest sistema, en el qual es distribueix el programa sota diferents llicències (normalment una copyleft i l’altra restrictiva), permet l’obtenció d’ingressos a partir de la versió propietària i col·laborar amb una “comunitat” per a millorar el programa lliure. Aquest sistema l’utilitza MySQL i Trolltech/Qt, entre d’altres empreses, i que ambdues distribueixen productes que són components de sistemes més complexos, per tant, pels intermediaris és interessant tenir una versió sota llicència sense copyleft per poder integrar-la en desenvolupaments propietaris.
A més, si el programa és modular, es pot contemplar l’ús de diferents llicències per a diferents components, sempre que siguin compatibles entre elles (depenent del grau d’integració) i amb la llicència sobre el programa distribuït “com un tot”. Algunes llibreries podrien tenir una llicència permissiva (BSD, Apache, etc.) o de tipus LGPL, mentre que altres parts de l’aplicació poden distribuir-se sota la MPL o la CDDL. Una altra estratègia per a sistemes client/servidor és utilitzar una llicència lliure per a una part (client) i una llicència propietària per al servidor.
Aspectes més legals¶
Finalment, anomenarem alguns factors més “legals” que podrien intervenir en la selecció de la llicència:
Dret aplicable (ex. la MPL 1.1, la CPL): algunes llicències imposen un dret aplicable i una jurisdicció competent per a resoldre qualsevol conflicte relatiu al programari. No té molt sentit per a una persona a Europa determinar el dret americà i els tribunals de Califòrnia per a resoldre conflictes relacionats amb la llicència. És recomanable utilitzar una llicència que deixi triar el dret i la jurisdicció del lloc del projecte, com la OSL/ASL o la CDDL.
Garanties i responsabilitats. Els projectes lliures solen voler evitar qualsevol garantia i responsabilitat relacionada amb el programari i les llicències lliures tracten de limitar-les en la mesura permesa per la llei vigent. No obstant això, la redacció d’aquestes limitacions d’acord amb el marc legal americà no quadra perfectament amb els règims legals europeus i es considera que la seva validesa i els seus efectes serien limitats pel dret local (protecció dels consumidors i usuaris, condicions generals de contractació). En particular, el règim espanyol obliga a proveir una garantia de títol. Projectes que volen una major seguretat jurídica en aquest àmbit seleccionarien una llicència més adequada al marc legal local (la AFL/OSL, per exemple, que és l’única llicència que inclou la garantia de títol). (Vegeu Garanties i responsabilitats legals).
Conclusions¶
Amb unes 55 llicències lliures i/o de codi obert com a candidates pel projecte, la selecció no és fàcil. No obstant això, una reflexió sobre els objectius del projecte i altres factors esmentats aquí, entre altres criteris, normalment reduirà la llista a unes poques. I amb una mica de sort a una única.
Enllaços d’interès¶
Llicències lliures (esmentades)
Affero (Affero General Public License)
AFL (Academic Free License)
Apache (Apache License 2.0)
Apple (Apple Public Source License 2.0)
BSD (Berkeley Software Distribution)
CDDL (Common Development and Distribution License)
CPL (Common Public License 1.0)
GPL (GNU General Public License)
LGPL (GNU Library o «Lesser» General Public License)
MPL (Mozilla Public License 1.1)
OSL (Open Software License)
QPL (Qt Public License)
SISSL (Sun Industry Standards Source License)
Zope (Zope Public License)