Inici » Llibres » L'expansió de les llicències de codi obert » Les llicències de codi obert com a mecanismes alternatius de governança » BSD i les llicències permissives

D'entre les llicències de codi obert, la de la BSD és la llicència permissiva més antiga i coneguda. BSD va sorgir en l'ambient universitari i reflecteix els principis de la llibertat acadèmica. Aquesta llicència permet que el codi font sigui obert, encara que no ho exigeix. La redistribució del programari sota BSD es podria fer també de forma binària sense codi font.

No hem de confondre BSD amb un domini públic. Per a les distribucions binàries amb altres llicències s'estableixen dos requisits secundaris. El primer és que la llicència BSD que inclou els noms dels titulars del copyright i les clàusules d'exempció de garanties ha de continuar amb la distribució. [1] El segon requisit és que la llicència ha de fer constar explícitament que no es poden utilitzar els noms dels autors en cas d'endossar qualsevol programa derivat del codi font de BSD. No obstant, és discutible que un endós d'aquest tipus sigui possible encara que no hi hagi una prohibició explícita.

És a dir, la llicència BSD garanteix l'atribució a tots els col·laboradors, però els protegeix de la responsabilitat i la mala reputació derivada dels principis dels drets morals del copyright. Aquests requisits també s'aplicaran als treballs derivats, si s'han realitzat tot enllaçant un mòdul sota BSD amb un treball ampliat o desenvolupant el codi font sota BSD.

Hem de remarcar que BSD no garanteix que el codi font resti obert ni tampoc que s'aportin condicions suplementàries noves en una còpia directa ni en una llicència completament nova per a una obra derivada o combinada. D'aquesta manera, qualsevol component registrat amb BSD es pot registrar de nou en una obra derivada o combinada, la qual pot transformar qualsevol altra llicència de codi obert recíproca a llicència privativa. Això també significa que la llicència BSD és compatible amb pràcticament qualsevol altra llicència.

Tanmateix, els requisits positius d'endós de les llicències permissives han presentat problemes d'incompatibilitat en el passat. La llicència BSD original de 1989 incloïa una clàusula que exigia la menció expressa de la Universitat de Califòrnia en la documentació del programari o materials associats per part de qualsevol persona que utilitzés aquest programari. Aquest detall insignificant va provocar que la Free Software Foundation declarés la llicència BSD incompatible amb la GPL. De fet, el requisit de menció es va suprimir el 1999. [2]

La llicència BSD guarda un silenci evident sobre les patents. Els experts sostenen que la llicència inclou una llicència de patent implícita: els desenvolupadors han d'aportar obligatòriament llicències de patent a tots els usuaris de programari perquè, de no fer-ho, seria impossible usar-lo. [3] Que la llicència superi els quinze anys potser hi té alguna cosa a veure.

Llicència del MIT. La llicència pública del MIT és una altra llicència permissiva molt popular. Té pràcticament la mateixa estructura que la llicència BSD i, potser, és fins i tot més breu. La diferència principal amb la llicència BSD és que la del MIT no exigeix cap endós. Com que quant a la funcionalitat no hi ha cap altra diferència amb la BSD, no cal continuar examinant els detalls de la llicència MIT.

Llicència Apache. Una de les llicències permissives de codi obert més elaborades és la darrera versió 2.0 de la llicència Apache. Les versions anteriors (1.0 i 1.1) d'aquesta llicència eren pràcticament iguals a la de la BSD, però la versió nova és considerablement més detallada. No obstant això, la funcionalitat de la llicència Apache no difereix de la BSD de manera radical. Els canvis en el llenguatge de la llicència reflecteixen els dubtes corporatius cada vegada més freqüents en les llicències de codi obert.

Pel que fa a les obres derivades, es poden utilitzar altres llicències per al codi Apache. A diferència de la BSD i de les primeres llicències Apache, aquesta opció es tracta explícitament al darrer paràgraf del punt 4:

«Podeu afegir la vostra clàusula de copyright a qualsevol modificació que feu. També podeu aportar termes i condicions de la llicència addicionals o diferents per a l'ús, reproducció o distribució de les vostres modificacions o de qualsevol treball derivat, sempre que l'ús, la reproducció i la distribució que en feu, compleixi les condicions establertes en aquesta llicència.»

La llicència inclou un requisit d'atribució semblant al de la BSD. També conté un requisit de no endós en el punt 7, on s'especifica que la llicència no inclou cap dret implícit o d'altra mena per utilitzar marques registrades i noms de productes del programari.

Una altra particularitat que la diferencia de la BSD és que la llicència Apache té una clàusula de patent detallada. En primer lloc, qualsevol col·laborador ha de registrar les seves patents referents al programari sense haver de pagar cap cànon. A més, la llicència de patent conté una clàusula de cancel·lació a llarg termini semblant a la de la CPL i la MPL: [4]

«Si inicieu una demanda de patent contra qualsevol entitat (reclamacions creuades o reconvencions en un plet incloses) al·legant que el treball o la col·laboració aportada constitueix una violació directa o parcial de la llicència de patent, llavors es donaran per cancel·lades totes les llicències de patent que se us hagin atorgat sota aquesta llicència quant a aquest treball determinat en el moment mateix en què es presenti la demanda.»

La llicència té una clàusula estàndard d'exempció de garantia. Una nova característica és que la llicència Apache estableix explícitament en el punt 9 l'opció d'aportar garanties addicionals:

«Al mateix temps que es redistribueix el treball o els treballs derivats, podeu decidir si voleu oferir acceptació d'ajuda, garantia, indemnització o d'altres obligacions de responsabilitat i drets derivats d'aquesta llicència, i si voleu cobrar per això.»

Llicència artística. Larry Wall va presentar la Llicència artística el març de 1991 com a part de Perl 4.0. La raó va ser que la GPL no satisfeia totes les necessitats corporatives ja que no podia usar Perl per a programes privatius. Per tal de mantenir una compatibilitat absoluta amb els projectes de la GPL, Perl es va registrar de manera dual, tant sota GPL com sota llicència artística. Larry Wall va comentar les seves intencions de la manera següent:

«La intenció de la llicència artística no ha estat mai de ser hermètica. Estaré satisfet si la llicència artística transmet el meu propòsit a la gent honesta i, alhora, proporciona als advocats corporatius el sentiment reconfortant de poder esmunyir-se si és el que volen fer.» [5]

Com suggereix el comentari de Wall, la llicència artística podria estar més orientada cap als hackers i ser més difícil de desxifrar que unes altres. La llicència artística és, bàsicament, una llicència permissiva, però amb més opcions: els usuaris poden decidir si volen adherir-se mitjançant una obligació de reciprocitat elevada.

Els experts han criticat la llicència artística a causa dels buits legals i el llenguatge imprecís. També s'ha intentat fer la llicència més clara, però les propostes no han tingut gaire èxit. Tanmateix, la llicència és un bon exemple del paper que encara exerceixen els desenvolupadors en les llicències escrites per a projectes molt importants de codi obert.

.^1. De fet, totes les altres llicències de codi obert que ja hem analitzat abans, també inclouen clàusules d'atribució semblants.

.^2. FSF (2003)

.^3. P.e. Rosen (2004), pàg. 78-79.

.^4. Vegeu Apache (2004) per trobar més informació sobre si aquesta clàusula és compatible amb GNU GPL o no.

.^5. Missatge de Larry Wall a gnu.misc.discuss 6.4.1994.