Moltes de les llicències de codi obert inclouen des d'obligacions a reciclatge de codis font basats en el concepte d'obres derivades en la llei de copyright. Però què constitueix exactament una obra derivada d'un programa informàtic segons la legislació de copyright dels EUA i la UE? La interpretació no és senzilla. Primer de tot, "obres derivades" és un concepte legal estrictament dels EUA. 17 L'USC 106 (2) el defineix de la manera següent:

una "obra derivada" és una obra basada en una o més obres preexistents, com ara una traducció, un arranjament musical, una dramatització, una ficcionalització, una versió d'una pel·lícula, un enregistrament de so, una reproducció d'art, un resum, una condensació o qualsevol altra forma en què una obra pugui ser refosa, transformada o adaptada. Una obra que consta de revisions editorials, anotacions, elaboracions o altres modificacions, les quals, en conjunt, representen una obra original d'autoria, és una "obra derivada".

En la jurisprudència dels EUA, els tribunals han determinat que per ser derivat, un programa informàtic ha de ser considerablement similar, [1] i en alguna forma inclou una part de l'obra amb copyright. [2] En comparació, a la legislació europea no hi ha cap redactat que es correspongui exactament amb el concepte d'obra derivada, propi dels EUA. Considerem l'article 2 de la directriu sobre la protecció legal dels programes informàtics, la qual prohibeix:

"(b) la traducció, adaptació, arranjament i qualsevol altra alteració d'un programa informàtic i la reproducció dels resultats del mateix, sense perjudici dels drets de la persona que altera el programa".

Si interpretem aquestes paraules, podem afirmar que la definició europea d'obres derivades és molt més àmplia i estricta: qualsevol alteraciód'una obra existent crea una "obra derivada". [3] En canvi, als Estats Units, l'obra nova ha de basar-se en l'obra subjacent. En el context dels programes informàtics, prendre només un passatge curt d'un codi font amb copyright en un programa combinat podria considerar-se una "alteració de l'obra", mentre que el programa nou no podria considerar-se "basat en" el codi reciclat.

Qualsevol llicència de drets d'autor ha d'interpretar-se en cada jurisdicció de conformitat amb la legislació aplicable vigent. Tal com hem indicat, les lleis de copyright dels EUA i la UE difereixen en la seva respectiva definició formal d'obres derivades. S'han escrit moltes llicències de codi obert amb una referència explícita a l'estil de redacció dels EUA, però podem sostenir que la mateixa redacció cobreix també la definició europea, encara que el concepte d'obres derivades pot tenir una aplicació més àmplia a la UE que als EUA.

Interpretació del codi font. Suposem ara que tant el sistema europeu com el dels EUA reconeixen l'existència d'obres derivades. Així doncs, fins on arriba el control de l'autor original? Comencem suposant que hi ha dos codis font i s'afirma que un codi font és una obra derivada de l'altre. Els advocats han desenvolupat dues teories aplicables amb l'anàlisi del codi font d'obres derivades: la dicotomia idea-expressió i el mètode d'abstracció-filtració-comparació.

La dicotomia idea-expressió afirma que el copyright només és aplicable a les expressions i no a les idees. Per tant, qualsevol idea que hi hagi rere l'obra, posem un algoritme matemàtic o una idea per desenvolupar un nou tipus de programari de processament de paraules, no està protegida pel copyright. En altres paraules, el copyright no limita cap autor posterior a l'hora de desenvolupar un nou sistema operatiu o algoritme de compressió. Els programes existents poden estudiar-se i analitzar-se per a la base de noves obres originals, i només es restringeix la còpia literal del codi font o objecte.

El mètode d'abstracció-filtració-comparació s'ha desenvolupat en el litigi dels EUA entre Computer Associates International i Altai. [4] Ravicher ha trobat indicis que aquest mètode és actualment la manera predominant d'interpretar obres derivades de programes informàtics en els tribunals de districte dels EUA. [5] La idea en aquest cas és, en resum, que la similitud entre dos codis font ha de fer-se, en primer lloc, abstraient l'estructura i les funcions en els presumptes codis font, a continuació filtrant les parts no essencials (sense copyright, domini públic, etc.) i, finalment, comparant el resultat. La comparació no es basa en la dicotomia idea-expressió sinó en anàlisis contextuals més detallades d'estructura de codi font, noms variables, etc. El mètode s'il·lustra a la figura 13, més endavant.

Figura 13. Mètode d'abstracció-filtració-comparació.

L'abstracció essencialment dóna com a resultat una versió filtrada del presumpte derivat, que a continuació es compara amb l'original. El litigi entre CA i Altai depenia en gran mesura del testimoni expert del professor de ciències informàtiques Randall Davis, que considerava que un programa informàtic consta tant de text com de comportament. [6] D'acord amb aquesta visió, els codis font i objecte son textos susceptibles de tenir drets d'autor, mentre que l'operació real del programa és més com un comportament. Per tant, per exemple les interfícies i altres funcionalitats de comportament no podrien considerar-se com a text ni són susceptibles de tenir drets d'autor.

Interpretació basada en components. Analitzem el problema més a fons en termes de visió basada en components de programes informàtics. A la pràctica, la visió basada en components pot resultar més utilitzable en el desenvolupament de codi obert, el qual afavoreix els paradigmes de programació basats en la reutilització màxima de codi font. Potser els problemes més freqüents apareixen quan s'utilitzen els components de codi obert de terceres parts. La figura 14 il·lustra la qüestió:

Figura 14. Una visió simplificada basada en components d'un programa informàtic.

Suposem que un desenvolupador té un producte de programari en el qual utilitza un codi font de terceres parts distribuït en un component. La qüestió és si l'obra resultant que combina el programa principal i el component es considera una obra derivada del component i, per tant, està sota el control parcial del propietari del copyright de terceres parts. Distingim la qüestió més a fons:

• Els codi font del programa principal i el component han estat barrejats (un component intern o incrustat). Aquest tipus de component intern adaptat "a dins" de l'obra completa crea clarament una obra derivada del conjunt combinat.

• El producte utilitza la funcionalitat dels components (per exemple, afegeix un nou temps d'execució-interfície al damunt de tot). Tenint en compte que els drets d'autor no cobreixen l'ús o les interfícies, aquests components de temps d'execució externs no modificats, que operen només a través d'especificacions d'interfície, no serien clarament derivats del producte.

• El component ha estat vinculat a o vinculat des de (per exemple, una biblioteca externa o un programa de control de dispositius). Aquest és el cas més imprecís. Considerem un producte de programari vinculat a les tasques pròpies d'una biblioteca. Es converteix en un derivat de la biblioteca? Potser no, moltes tasques pròpies de biblioteca cobreixen només una funcionalitat estàndard per ajudar exactament en les tasques de "rutina". Però què succeeix si aquestes tasques cobreixen una funcionalitat essencial i original del programari i no es poden utilitzar altres tasques amb ell? A més, considerem un component conforme a un marc de servidor-client en què el component actua com un servidor del producte de programari del client (el component hi està vinculat). Potser el producte de programari no seria un derivat del component del servidor si només utilitza els serveis del servidor. Tanmateix, si el producte depèn en excés de la funcionalitat del servidor i no funciona separadament en qualsevol altre sistema sense ell, la situació és més dubtosa: si volem utilitzar el producte, aleshores també el component ha de copiar-se i distribuir-se.

Interpretació basada en les comunicacions. Els dos criteris d'interpretació anteriors estan basats en el coneixement convencional dels continguts de la llei de copyright. Encara que poden satisfer els advocats i els directors de projecte, els més tècnics poden seguir preguntant què constitueix realment un programa derivat entre dos components de programa aparentment separats. La Free Software Foundation ha suggerit una interpretació basada en criteris més tècnics i els mecanismes i la semàntica de comunicació entre els components.

"Què constitueix la combinació de dues parts en un programa? [...] Creiem que un criteri adequat depèn tant del mecanisme de comunicació (exec, canonades, rpc, crides de funció dins un espai d'adreça compartida, etc.) com de la semàntica de la comunicació (quins tipus d'informació s'intercanvien) [...] De manera que quan s'utilitzen per a comunicació, els mòduls solen ser programes separats. Tanmateix, si la semàntica de la comunicació és prou íntima, intercanviar estructures de dades internes complexes també podria ser una base per considerar les dues parts com a combinades en un programa més gran".

Aquest suggeriment d'interpretació pot il·lustrar-se a la figura següent:

Figura 15. Obres derivades i mòduls de càrrega.

La pregunta és si els mòduls són derivats d'algun altre quan es carreguen a partir de mitjans d'emmagatzematge a la memòria de l'ordinador. Bàsicament, en el cas de l'espai d'adreça compartida, la resposta seria "sí", i en el cas de l'espai d'adreça separada, la resposta dependria de les comunicacions. És interessant que la Free Software Foundation considera el programari com discurs i comunicació. Si una part del programa parla amb l'altra part amb "contacte físic", podria tractar-se d'una obra derivada. Des del punt de vista de la llei de copyright, aquesta interpretació és, tanmateix, discutible, ja que el copyright no cobreix la funcionalitat sinó el codi literal.

* * *

No és fàcil comparar els diferents criteris per analitzar quan dues parts haurien d'interpretar-se com la creació d'una unitat. Cadascun dels criteris tractats aquí poden aplicar-se millor que d'altres en situacions diferents. També hi ha algunes limitacions clares per als criteris anteriors. En la programació en xarxa, es pot pensar en situacions en què els components de terceres parts s'han barrejat amb altres parts, creant una "obra derivada" amb qualsevol dels criteris mencionats. Tanmateix, l'obra completa no s'emmarca en el concepte d'obra derivada, ja que funciona i s'hi accedeix a través d'Internet, però no es distribueix ni copia com un paquet de programari. Això és freqüent quan un programa està basat, per exemple, en serveis en xarxa o altres components en línia.

Antecedents Potser la característica funcional més rellevant de la GPL és la manera com controla la major distribució d'obres derivades. En resum, la GPL requereix que ningú pugui canviar les condicions de llicència de les obres derivades o modificades. Altrament, la redistribució no està permesa. La connexió entre la GPL i les obres derivades s'exposa a la condició 2b) de la llicència:

"Pots modificar la teva còpia o còpies del Programa o qualsevol part del mateix, formant una obra basada en el Programa, i copiar i distribuir aquestes modificacions ... sempre que... :

2b) Qualsevol obra que distribueixis o publiquis, que totalment o en part contingui o derivi del Programa o qualsevol part del mateix, haurà de tenir una llicència en conjunt sense càrrec per a totes les terceres parts, de conformitat amb les condicions d'aquesta Llicència".

Aquesta part de GNU GPL s'ha utilitzat en nombrosos debats polítics. Mentre el codi obert s'obria pas per dominar el sector del programari, molt en particular Microsoft va sostenir que a causa de la GPL 2b), qualsevol programari distribuït amb ell perjudicaria greument l'ecosistema de programari. L'any 2001, el gerent general de Microsoft, Steve Ballmer, va afirmar el següent: [7]

"De la manera com està escrita la llicència, si utilitzes qualsevol programari de codi obert, has de fer la resta del teu programari en codi obert... [el programari conforme a la GPL] és un càncer que, en un sentit de propietat intel·lectual, s'estén a tot allò que toca" (cursiva afegida).

Des d'aleshores, Microsoft ha mitigat d'alguna manera la seva posició. Els partidaris del codi obert, i el sector de programari ara de manera més general, afirmen que l'abast de l'obligació de reciprocitat en la GPL està limitat. De fet, la majoria d'autors de llicència recíproca proporcionen guies detallades sobre com evitar una situació en què la llicència plantejaria problemes en el procés de llicència d'una obra derivada. [8] Fins ara, no hi ha indicis que demostrin que els que concedeixen llicències de codi obert utilitzarien aquestes obligacions amb males intencions, intentant convertir tot el programari en codi obert. [9]

Així doncs, analitzem més detalladament la condició 2b): Què diu exactament? La definició inclou les paraules "procedeix de" i "conté totalment o en part". Aquesta última fa la impressió que la GPL podria cobrir més que el que implica el concepte d'obra derivada en la llei de copyright. Podem reformular la pregunta de la manera següent:

1. Quan un programa informàtic procedeix d'un programa de GPL? Aquesta és una relació força senzilla amb la redacció de la legislació de copyright dels EUA.

2. Quan un programa informàtic totalment o en part conté un programa de GPL? Es pot sostenir que aquesta darrera part crea una definició contractual imprecisa d'allò que GPL vol significar per una obra derivada: un altre programa només ha de contenir parts de codi font conforme a la GPL per estar-ne regit. Tanmateix, com que no hi ha cap indici de la quantitat o la qualitat del codi "contingut" i la seva relació amb l'obra combinada, es pot sostenir que la interpretació d'obres derivades s'aplica també a la segona part de la pregunta. Amb prou feines pot significar situacions en què s'utilitza el codi font sense copyright. Després de tot, si considerem la GPL com una llicència de drets d'autor, només pot regir quelcom que tingui drets d'autor, és a dir, obres d'art originals. [10]

Finalment, considerem la primera part 2b). Limita l'aplicabilitat de la llicència a aquelles obres derivades que estan "publicades" o "distribuïdes". Aquestes dues paraules fan referència a conceptes legals ben fonamentats en la llei de copyright. Tanmateix, en el context dels programes informàtics, la seva interpretació pot no ser tan senzilla. Per exemple, no està clar si vendre un servei de subscripció de programari significa que el programari es distribueix o es publica.

A continuació, analitzem diferents situacions d'interpretació pràctica en què no ha estat clar si l'obra completa deriva del component o qualsevol codi font extern conforme a la GPL. Alguns dels temes principals han estat els següents:

1. Sortida del programa

2. Biblioteques de programació

3. Connectors i programes de control de dispositius.

4. Programes client i interfícies d'usuari.

5. Subscripció de programari i serveis en xarxa

Sortida del programa. Considerem el model teòric d'un programa informàtic com una caixa negra que pren una entrada, realitza un càlcul i produeix una sortida. Es podria afirmar que qualsevol sortida d'un programa informàtic es calcula automàticament a partir de l'entrada. Per tant, és pertinent preguntar si la sortida podria interpretar-se com una obra derivada d'entrada i càlcul.

La pregunta és força freqüent pel que fa als compiladors de programes. Si la sortida del compilador es considera una obra derivada tant del codi font com de "l'obra" d'un compilador, podria l'autor del compilador tenir també els drets de la sortida resultant? Si la sortida no inclou cap codi o expressió des del compilador, la resposta sembla senzilla: no. Però què succeeix si el programa resultant inclou qualsevol expressió afegida pel compilador? En aquest cas, la pregunta torna a la interpretació basada en codis font.

La secció 0 de la GPL inclou una definició força indefinida del tema:

"... la sortida des del Programa només està coberta si els seus continguts constitueixen una obra basada en el Programa (independent d'haver-se fet executant el Programa). La veracitat d'aquesta afirmació depèn d'allò que faci el Programa".

La Col·lecció de Compiladors Gnu (GCC) es troba dins la categoria en què el codi es pot copiar en el binari. Per tant, té una exempció especial per a la GPL:

"Com a excepció especial, si vincules aquesta biblioteca amb altres arxius, alguns dels quals estan compilats amb GCC, per produir un executable, aquesta biblioteca no fa per ella mateixa que l'executable resultant estigui cobert per la Llicència Pública General GNU".

Mentre la qüestió de les obres derivades és específica de compilador, és pràcticament essencial. No es poden fer programes nous sense un compilador i el GCC funciona de manera que algun codi comú es copiarà a cada binari compilat. Sense aquesta excepció, seria possible crear només programes de GPL amb GCC sota una interpretació estricta del codi font de les obres derivades.

Biblioteques. Una qüestió debatuda amb freqüència és si les crides de funció a les funcions de biblioteca externa haurien d'interpretar-se per convertir el programa complet en una obra derivada. En aquest aspecte, podem distingir entre dos tipus de situacions:

• La vinculació del temps d'execució quan, per exemple, una crida de funció del sistema operatiu s'utilitza fora de l'executable.

• La vinculació estàtica, quan una crida de funció es compila en un executable i es crida dins el programa.

Temps enrere aquestes qüestions creaven controvèrsia, i molta gent comunitària sostenia que la vinculació del temps d'execució no constituïria una obra derivada. Tanmateix, els desenvolupadors de programari lliure semblen sostenir actualment que ambdós tipus de vinculació constitueixen el programa combinat per ser una obra derivada. [11] Per exemple, Metzger i Jaeger sostenen que si una funció conforme a la GPL es carrega a la memòria de l'ordinador al mateix temps amb el programa principal i s'hi vincula per convertir-se pràcticament en un executable únic, aleshores el treball complet hauria d'interpretar-se com un derivat de les seves parts. [12]

Per contra, haurien de quedar àrees en què la vinculació estigués permesa. Si no fos així, no seria possible crear cap aplicació per a un sistema operatiu modern sense l'acceptació explícita del propietari del copyright del sistema operatiu. La GPL ha resolt la qüestió amb la clàusula 3, que afirma el següent:

"Com a excepció especial, el codi font distribuït no ha d'incloure res que es distribueixi normalment (ja sigui en font o en forma binària) amb els components principals (compilador, nucli, etc.) del sistema operatiu en què funciona l'executable, a menys que el propi component acompanyi l'executable".

Hi ha hagut un litigi judicial en què la qüestió de la vinculació va estar a punt d'analitzar-se més a fons. [13] Progress Software Corporation havia vinculat el seu manipulador de taula Gemini a la base de dades de MySQL AB conforme a la GPL. Tècnicament, la vinculació de Gemini podria haver-se anomenat estàtica, ja que es va compilar dins la distribució binària de MySQL. Tanmateix, el progrés no va publicar el codi font de Gemini, i ambdues parts van acabar als tribunals. El tribunal va decidir en un manament judicial preliminar el següent:

"MySQL no ha mostrat cap probabilitat considerable d'èxit sobre els mèrits o els danys irreparables. Les declaracions jurades presentades pels experts de les parts provoquen un litigi objectiu sobre si el programa de Gemini és una obra derivada o independent i separada conforme a la GPL, [paràgraf] 2. Després de la vista, MySQL sembla tenir el millor argument, però l'assumpte és força controvertit. A més, no estic convençut que la publicació del codi font de Gemini el juliol de 2001 no solucionés la infracció".

El cas es va resoldre més endavant. El tribunal va donar suport a l'argumentació de MySQL, que sostenia que el mètode de vinculació utilitzat per Progress realment va motivar que Gemini fos un derivat de MySQL. Tanmateix, és interessant observar que podria ser possible no publicar el codi font d'un programa conforme a la GPL sense causar danys comercials. A més, qualsevol possible dany pot solucionar-se quan el codi font es publica en una data posterior (després de sol·licitar-ho el titular del copyright).

Connectors i programes de control de dispositius. Considerem ara una situació en què es desenvolupa un connector o programa de control de dispositius en un programa conforme a la GPL. És aquest connector una obra derivada del programa principal i, per tant, està conforme a la GPL? Les preguntes més freqüents de la Fundació de Programari Lliure inclouen respostes amb uns criteris d'interpretació basats en la substància i la forma. Afirma el següent:

"Si el programa vincula dinàmicament connectors, i aquests fan crides de funció entre ells i comparteixen estructures de dades, creiem que formen un únic programa, de manera que els connectors han de tractar-se com a extensions del programa principal. Això significa que han de publicar-se conforme a la GPL...". [14]

També hi ha hagut un debat pràctic rellevant sobre la qüestió referent als mòduls de nucli privatiu, com ara els programes de control de dispositius en Linux. Linus Torvalds, l'autor principal del nucli Linux, ha afegit la següent afirmació a la GPL de Linux:

"IMPORTANT! Aquest copyright *no* cobreix els programes d'usuaris que utilitzen serveis de nucli per crides de sistema normals. Això es considera merament un ús normal del nucli, i *no* es pot classificar amb el títol "d'obra derivada"".

Aquesta advertència ha fet pensar a molts que els programes de control de dispositius, i els connectors en general, no són obres derivades. Tanmateix, l'advertència té poc o cap efecte legal. Les obres derivades estan en última instància definides legalment i no en la llicència. A més, la llicència GPL no permet cap modificació de la llicència i, encara més important, Linus Torvalds és un dels nombrosos propietaris de copyright de nucli Linux, alguns dels quals es desconeixen. Referent a la doctrina d'impediment, alguns comentaristes creuen que aquesta advertència només podria prendre's com una indicació que Torvalds no donarà suport a cap acció legal contra cap fabricant de controladors privatius de dispositius Linux. [15]

Torvalds ha clarificat una mica la seva posició al llarg dels anys. El 1995, va explicar que els mòduls de nucli són "lògicament independents" del propi nucli, i que poden veure's més com a "ús" que com a "vinculació" al nucli. Pensava que qualsevol programa de control de dispositius escrit per exemple en Unix podria importar-se a Linux sense necessitat d'utilitzar la GPL. [16] El 2003, Torvalds també va explicar el següent: [17]

"- qualsevol cosa que estigui escrita pensant en Linux (funcioni o no funcioni després en altres sistemes operatius) és clarament i parcial una obra derivada.

- qualsevol cosa que tingui coneixement i jugui amb un comportament Linux intern fonamental és clarament una obra derivada. Si necessites recórrer al codi nucli, estàs derivat, sens dubte".

Òbviament, el Linux hauria de ser avui familiar per a la majoria de desenvolupadors, i la interpretació de Torvalds, per tant, significaria que bàsicament tots els mòduls de nucli nous en Linux haurien d'estar conformes a la GPL.

Programes client i interfícies d'usuari gràfic. Suposem que es desenvolupa un programa client comercial per a un altre programa conforme a la GPL. Un exemple pràctic és un client gràfic per gestionar bases de dades de MySQL. És un client una obra derivada i que està conforme a la GPL? La pàgina de llicència de MySQL AB recalca el concepte de distribució afirmant que "si d'alguna manera distribueixes una aplicació privativa", aleshores la GPL es converteix en vinculant. [18] Òbviament, l'empresa considera tots els clients com a obres derivades i, per tal d'utilitzar fins i tot un client amb altres condicions que la GPL, el desenvolupador del client necessitaria comprar una llicència privativa de MySQL AB. En efecte, semblen interpretar la GPL com si un programa client separat (basat en la interpretació tant basada en components com en el codi font) del seu servidor de base de dades -utilitzat per a finalitats comercials- estaria sotmès a la doctrina d'obres derivades a causa de la GPL 2b). [19]

Tanmateix, ni la llei de copyright ni la Definició de Codi Obert ni la llicència GPL GNU en realitat presenten cap restricció estrictament sobre l'ús de programari. Per tant, utilitzar una obra merament conforme a la GPL no modificada no pot ser la base per a una obra derivada. Per tant, els clients estan lliures de l'obligació de reciprocitat? A aquesta pregunta, MySQL AB respon -d'acord amb Linus Torvalds- que si es necessita la seva base de dades per tal de dirigir el client, aleshores s'està bàsicament distribuint una base de dades MySQL, i la GPL es converteix en vinculant. Una altra interpretació estaria en contra de la intenció de la GPL. Un crític pot preguntar: Què succeeix si el programari del servidor no està modificat? Al final, la pregunta es redueix a si un client pot interpretar-se de ser un derivat del servidor en el sentit de la llei de copyright.

Subscripció de programari i serveis en xarxa. Alguns comentaristes han observat que existeix un "buit legal d'ASP" en la GPL. En base a les nostres definicions funcionals anteriors, la GPL només té la propietat d'una obligació de reciprocitat forta i no la de l'ús de xarxa. En essència, la GPL només és aplicable quan les obres es distribueixen més. Utilitzar o executar el programa no vincula a algú a les condicions de la llicència. També és possible modificar el programa i utilitzar-lo privadament sense publicar el codi font. Aquest fet no suposava un problema quan es va introduir l'última versió de GPL, el 1991.

Tanmateix, avui en dia el programari no publicat es pot utilitzar comercialment. En un entorn en xarxa, no fa falta "publicar" el programa informàtic per tal d'utilitzar-lo. La majoria de programaris de servidors en xarxa funcionen pràcticament amagats dels usuaris finals i s'hi accedeix mitjançant navegadors. Com defensa Tim O'Reilly:

"... totes les aplicacions revolucionàries de l'era d'Internet (Amazon, Google i Maps.yahoo.com) funcionen en Linux o FreeBSD, però no són aplicacions com la gent ha pensat tradicionalment... una de les premisses fonamentals del codi obert és que les llicències estan totes condicionades per la distribució de programari, i un cop s'ha deixat de distribuir una aplicació, cap de les llicències significa res". [20]

Aquest tipus de modificació privada de la GPL sembla estar permesa segons 2b). No hi ha cap obligació de publicar el programari, la qual cosa és necessària perquè la GPL sigui eficaç. Però què és exactament la publicació de programari? La subcontractació o contractació de programadors per desenvolupar programari a dins l'empresa, molt probablement no constitueix una distribució. En canvi, si es contracta un desenvolupador independent o una empresa que pot desitjar autoritzar més endavant el programari a altres parts, aleshores la GPL molt probablement necessitarà que el programari es distribueixi a qualsevol amb uns costos de còpia mínims. De totes maneres, encara queda la possibilitat que cap tercera part sàpiga que el programari està desenvolupat i autoritzat conforme a la GPL.

Òbviament, la següent versió de la GPL podria tractar aquest model d'ús. Fins ara, per exemple Affero Public License ha inclòs una clàusula d'ús de la xarxa que necessita usuaris de servei en xarxa per publicar modificacions. [21] - Més endavant, tornem a tractar el problema de l'obligació d'ús de xarxa amb la Llicència de Programari Obert.

La llicència GPL té un plantejament més aviat negatiu respecte a les patents. La condició 7 diu el següent:

"7. Si, com a conseqüència [...] d'una vulneració de patent [...] se t'imposen condicions [...] que contradiuen les condicions d'aquesta Llicència, aquelles no t'excusen de les condicions d'aquesta Llicència. Si no pots distribuir per satisfer simultàniament les teves obligacions conforme a aquesta Llicència i qualsevol altra obligació pertinent, aleshores en conseqüència no pots distribuir el Programa. Per exemple, si una llicència de patent no permetés una redistribució lliure de cànons del Programa per a tots aquells que reben còpies directament o indirectament a través teu, aleshores l'única manera de satisfer-los a ell i a aquesta Llicència seria abstenir-se completament de distribuir el Programa. [";¦] ";

El preàmbul de la GPL explica la motivació que hi ha rere aquesta obligació:

" [...] qualsevol programa lliure està constantment amenaçat per patents de programari. Desitgem evitar el perill que els redistribuidors d'un programa lliure obtinguin individualment llicències de patent, convertint el programa en privatiu. Per tal d'evitar-ho, hem deixat clar que qualsevol patent ha d'estar o bé autoritzada per a l'ús lliure de tothom o no estar autoritzada".

En resum, la GPL disposa d'un mecanisme d'extinció incorporat que no permet el desenvolupament de programari que necessiti algun tipus de pagament de llicència per a patents de terceres parts. Més tècnicament, la GPL és incompatible amb els drets de llicència de patents: si existeix una patent per a un invent de programari i aquesta patent no està autoritzada lliurement per a tots els usuaris de GPL indefinidament, no resulta possible desenvolupar programari lliure per a aquest invent.

El mecanisme d'extinció té un abast limitat. En teoria, un propietari de patent que disposa d'un programari de GPL i que comença a cobrar drets de llicència de patent a d'altres usuaris, extingeix essencialment les llicències de tots els altres excepte la seva. A més, un propietari de patent pot autoritzar de manera natural la patent als usuaris d'altres programaris, que utilitzen l'invent patentat.

Segons la Fundació de Programari Lliure, la compatibilitat amb GPL significa que

"... pots combinar un codi publicat conforme a l'altra llicència amb un codi publicat conforme a la GNU GPL en un programa més gran... La GPL permet aquesta combinació sempre que sigui publicat conforme a la GNU GPL. L'altra llicència és compatible amb la GPL si també ho permet". [22]

Hi ha bones raons per utilitzar una llicència compatible amb GPL. Primer de tot, el codi font conforme a llicències incompatibles no pot reutilitzar-se en projectes amb llicència GPL. En segon lloc, com que molts desenvolupadors prefereixen la GPL, pot succeir que una llicència incompatible no atregui el màxim nombre possible de col·laboradors disposats. Hi ha molts casos de projectes grans que han canviat la seva normativa de llicència per una compatible amb la GPL. Per exemple, Mozilla, el popular llenguatge de programació Python i els projectes Apache han adoptat nous programes de llicència que siguin compatibles amb la GPL. [23]

La incompatibilitat és també un problema per als desenvolupadors de programari de codi obert sense GPL. A més de les llicències privatives, la GPL és en realitat incompatible amb moltes altres llicències populars de codi obert. [24] Els desenvolupadors que no volen canviar les llicències de codi obert incompatibles no poden beneficiar-se directament o indirectament (en base a la interpretació d'obres derivades) de cap codi font amb GPL. Aquest és el motiu pel qual, per exemple, la base de dades de MySQL, conforme a la llicència de GPL, va haver d'afegir la següent excepció a la seva llicència de GPL per tal de permetre el desenvolupament de l'aplicació PHP en MySQL sense requisits de GPL: [25]

"Com una excepció especial de les condicions de la versió 2.0 de la GPL:

Ets lliure de distribuir una Obra Derivada formada totalment a partir del Programa i una o més obres (cadascuna d'elles, una "Obra FLOSS") amb llicència conforme a una o més de les llicències indicades més endavant a la secció 1, sempre que:

1. Compleixis la GPL en tots els respectes per al Programa i l'Obra Derivada, excepte per a seccions identificables de l'Obra Derivada que no deriven del Programa, i que poden considerar-se raonablement obres independents i separades per elles mateixes.

2. Totes les seccions identificables de l'Obra Derivada que no deriven del Programa, i que raonablement poden considerar-se obres independents i separades per elles mateixes, estan distribuïdes subjectes a una de les llicències FLOSS indicades més endavant, i... el codi objecte o la forma executable d'aquelles seccions estan acompanyats pel corresponent codi font complet i llegible per màquina per a aquelles seccions en el mateix mitjà i conforme a la mateixa llicència FLOSS, com el corresponent codi objecte o formes executables d'aquelles seccions, i" [26]

Bàsicament, la combinació del codi GPL conforme a aquesta excepció amb altres llicències de codi obert és possible, sempre que les obres derivades estiguin conforme a la GPL. Aquest tipus d'excepció fa que la GPL funcioni com una llicència recíproca estàndard cap a llicències de codi obert incompatibles.

Altres llicències importants amb obligacions de reciprocitat forta són, per exemple, la Common Public License (Llicència Pública Comuna) i l'Open Software License (Llicència de Programari Obert).

Llicència Pública Comuna (CPL) Allò que fa que la Llicència Pública Comuna sigui important no és la seva popularitat absoluta, sinó el fet que es va originar a IBM i es va convertir en la primera llicència de codi obert que va utilitzar Microsoft. [27]

Des d'una perspectiva funcional, la Llicència Pública Comuna recorda molt la GPL. La condició 3 b) iv) de la llicència afirma que el codi font ha d'estar disponible:

"Un Col·laborador pot escollir distribuir el Programa en forma de codi objecte de conformitat amb el seu propi acord de llicència, sempre que... el seu acord de llicència... especifiqui que el codi font per al Programa està disponible per part d'aquest Col·laborador, i informa els llicenciataris sobre la manera d'obtenir-lo de manera raonable sobre o a través d'un mitjà habitualment utilitzat per intercanviar programari".

La llicència defineix en la primera condició una contribució com la forma de constituir també obres derivades:

"... canvis i/o addicions al Programa... les contribucions no inclouen addicions al Programa que: (i) siguin mòduls separats de programari distribuïts juntament amb el Programa conforme al seu propi acord de llicència, i (ii) no siguin obres derivades del Programa".

Una lectura literal de la llicència realment suggereix una interpretació de reciprocitat forta similar a la GPL. [28] . Tanmateix, la qüestió no sembla estar gaire clara de moment. Les preguntes més freqüents d'IBM indiquen que podien haver tingut en ment alguna cosa en forma de reciprocitat estàndard:

"15. Quan incorporo una part d'un Programa amb llicència conforme a la CPL en el meu propi producte privatiu distribuït en forma de codi objecte, puc utilitzar una única llicència per al producte sencer, en altres paraules, cobrint la part del Programa més el meu propi codi?

- Sí. El codi objecte per al producte pot distribuir-se conforme a una única llicència sempre que faci referència a la part de CPL i compleixi, per aquesta part, les condicions de la CPL". [29]

Pel que fa a les patents, la CPL és més agressiva que la GPL. La primera llicència concedeix a tots els llicenciataris una llicència de patent sense copyright a la condició 2, i després, a la condició 7, afirma el següent:

"Si el Destinatari presenta una demanda sobre patents contra un Col·laborador respecte a una patent aplicable al programari (incloent-hi una contrarreclamació o contrademanda en una demanda judicial), aleshores qualsevol llicència de patent concedida per aquest Col·laborador a aquest Destinatari, de conformitat amb aquest Acord, s'extingirà en la data en què s'hagi presentat la demanda".

L'extinció de la patentes produeix en cas de litigi, i no és necessari que cap patent sigui vàlida. A més, la disposició sembla cobrir fins i tot les patents no relacionades amb el programari. Per tant, un llicenciador ha d'escollir essencialment entre utilitzar un programari conforme a la CPL i utilitzar patents (per a drets de llicència o demanda per vulneració). [30] Un llicenciador de GPL, en comparació, pot cobrar drets de llicència i presentar demandes per vulneració de patent contra altres usuaris sense perdre el dret d'utilitzar el programari. Per tant, la CPL va més enllà que la GPL en aquest respecte. És possible que la GPL es desenvolupi en el futur per incloure una funcionalitat antipatent similar. [31]

Llicència de programari obert. Hi ha hagut moltes iniciatives per aclarir les llicències de codi obert més utilitzades. Potser en la més notable, l'advocat legal de la Iniciativa de Codi Obert, Lawrence E. Rosen, ha estat desenvolupant la Llicència de Programari Obert en un llenguatge legal més rigorós, per tractar especialment la qüestió de les obres derivades i l'obligació de reciprocitat forta en la GPL. Advoca per la formalitat legal, pretenent que la llicència sigui més un contracte executable que una simple llicència de drets d'autor. [32]

"L'OSL està destinat a servir les mateixes funcions que la GPL excepte en el fet que és un contracte, i a ser interpretat de conformitat amb la llei contractual, en comptes d'una llicència de drets d'autor".

A més d'una claredat legal formal, l'OSL ha estat una plataforma per desenvolupar una funcionalitat de llicència de codi obert entre el conflicte de la comunitat i les exigències empresarials. L'opinió de l'OSL sobre les obres derivades és la següent. En la primera secció, la llicència concedeix a cada usuari el dret de preparar "obres derivades", però només amb la condició que totes aquestes obres derivades "es distribueixin de conformitat amb la Llicència de Programari Obert". A més, l'OSL també intenta estendre el seu abast, a través de mitjans contractuals, cap a l'ús de la xarxa. A la secció 5, la llicència defineix el "desplegament extern" com una situació en que l'obra:

"... es fa disponible com una aplicació destinada a l'ús en una xarxa informàtica. Com una condició expressa per a les concessions de llicència pel present, acceptes que qualsevol Desplegament Extern per part Teva d'una Obra Derivada es considerarà una distribució i s'autoritzarà de conformitat amb les condicions d'aquesta Llicència, tal com es prescriu a la secció 1(c) del present". (afegida cursiva)

Així doncs, què significa l'ús de la xarxa? Fins ara, només hi ha unes poques observacions sobre allò que podria significar. El mateix Rosen ha afirmat que, per exemple, si un cercador d'Internet estigués basat en un component de programari modificat segons l'obligació d'ús de la xarxa, no estaria obligat a publicar el codi font perquè simplement estaria fent disponible una informació, no un programari. Tanmateix, quan el cercador permet realitzar cerques privades de les pròpies pàgines internes dels usuaris, la clàusula potser és aplicable. [33] Sigui quina sigui la interpretació correcta, sembla obvi que aquesta funcionalitat d'ús de la xarxa va més enllà d'allò que necessiten la GPL i la CPL. Fa que l'OSL sigui més restrictiva que les típiques obligacions de reciprocitat forta. També es pot qüestionar si la disposició d'ús de la xarxa està conforme amb la Definició de Codi Obert, la qual requereix que no hi hagi obligacions per a l'ús de programari, per exemple en el marc comercial. [34]

Pel que fa a les patents, l'OSL inclou una simple llicència de patent lliure a tots els usuaris d'OSL per a aquelles patents del llicenciador que cobreixen el programari. En versions anteriors de la llicència (abans de 2.1), hi havia una clàusula d'extinció més estricta, que extingia la llicència fins i tot quan el llicenciador presentava una demanda basada en una patent de programari no relacionada contra els usuaris de codi obert, com afirma la condició 7 de la CPL. Lawrence Rosen va advocar per canviar la terminologia de la llicència de patents d'acord amb les necessitats del sector del programari (com a usuaris de programari): [35]

"... la preocupació per [l'extinció de la patent] es va expressar més fermament en un correu electrònic... d'HP. Des d'aleshores, ho he debatut en privat amb advocats per a diverses empreses. Estic d'acord amb ells que és necessari un canvi per fer que aquestes llicències siguin més favorables per a les empreses que posseeixen grans carteres de patents".

Potser la qüestió legal més problemàtica amb les llicències de codi obert és la responsabilitat per vulneració de la propietat intel·lectual. El nucli del problema és la possible responsabilitat estricta per les vulneracions de drets d'autor i patents, que afecten cada part que participa en la distribució de programari. La base del problema té la lògica de les lleis de propietat intel·lectual. Aquest fet no ajuda el distribuïdor que ha actuat amb bona fe. Si l'obra vulnera un dret de propietat intel·lectual d'una tercera part, tothom que participa a la cadena de distribució de l'obra pot estar subjecte a l'autor de la infracció.

La majoria de llicències de codi obert renuncien a totes les garanties, incloent-hi les possibles vulneracions de la propietat intel·lectual. Des de la versió 1.1 en endavant, la Llicència de Programari Obert, tanmateix, inclou una garantia limitada de DPI per demandes de terceres parts sobre drets d'autor i patents. Aquest fet és impensable en altres llicències de codi obert. La condició 7 afirma el següent:

"El Llicenciador garanteix que el copyright de l'Obra Original i els drets de les patents concedits en el present pel Llicenciador són propietat del Llicenciador o bé estan subllicenciats, de conformitat amb les condicions d'aquesta Llicència amb el permís del(s) col·laborador(s) d'aquests copyrights i drets de patent".

Rosen ha sostingut que el llicenciador està en una posició més favorable per jutjar si hi ha contribucions de vulneració, i recomana que tots els projectes que utilitzen OSL s'assegurin que les contribucions no tenen riscos de vulneració de DPI. [36] Aquesta base es pot rebatre fàcilment: Per què un desenvolupador de codi obert hauria de garantir alguna cosa per la qual no considera el preu en primer lloc? Per què un desenvolupador de codi obert hauria de prendre un risc addicional de vulneració de la propietat intel·lectual pel que fa, per exemple, a patents de programari de les quals no n'és conscient i no pot controlar la manera com s'utilitzarà el programari? - Reprenem aquesta qüestió més endavant amb les llicències Creative Commons i expliquem per què aquest projecte particular de llicència va decidir renunciar a una disposició de garantia més o menys similar. Al capítol 6, reprenem més detalladament l'anàlisi de la vulneració de la propietat intel·lectual.

.^1. Litigi entre Litchfield i Spielberg (1984). Vegeu també Lemley et al (2000), p. 208-209.

.^2. En el litigi entre els Estats Units i Manzer (1995) es va mantenir que un 70 % de similitud en la base de codi era suficient per considerar l'altra obra derivada. Vegeu també Lemley et al. (2000), p. 208, referint-se al litigi de Vault Corp. v. Quaid Software Ltd. (1988), en el qual es debat la qualitat de la còpia.

.^3. A més, es pot sostenir que el dret moral de reputació de l'autor estén l'abast del dret modificador a Europa. Vegeu Metzger (2004). També es pot afirmar que la modificació no amenaça la reputació del creador d'un producte industrial tant com la del creador d'una obra d'art. Vegeu Dietz (1994), p. 184.

.^4. Litigi entre Computer Associates International i Altai (1992).

.^5. Ravicher (2002).

.^6. Més endavant, Davis va publicar un article sobre el tema escrit conjuntament amb catedràtics de dret. Vegeu Samuelson et al (1994).

.^7. L'afirmació es comenta, per exemple, a Greene (2001).

.^8. Per exemple, les preguntes més freqüents de GPL en FSF (2004) inclouen actualment més de vint preguntes i respostes detallades sobre la interpretació de 2b).

.^9. Vegeu e.g. Boyle (2004) sostenia que la intenció dels autors de GPL i el sentit comú judicial estan en contra d'un escenari en què qualsevol producte important de programari necessitaria GPL si inclogués una quantitat important de codi font de GPL.

.^10. A més, la primera condició de la GPL dóna suport a aquesta interpretació amb la definició que "una obra basada en el Programa" significa el Programa o bé qualsevol obra derivada de conformitat amb la llei copyright: és a dir, una obra que conté el Programa o una part d'ell, ja sigui textual o amb modificacions i/o traduït a una altra llengua. (D'ara endavant, la traducció està inclosa sense limitació en el terme "modificació" (cursiva afegida).

.^11. Això s'explica detalladament, per exemple, a la Fundació de Programari Lliure (2003).

.^12. Metzger i Jaeger (2002), p. 44-45.

.^13. Vegeu el litigi entre Progress Software Corp. i MySQL AB (2002). El cas ha estat comentat, per exemple, per Majerus (2003).

.^14. Vegeu la Fundació de Programari Lliure (2003).

.^15. Raymond (2001).

.^16. Missatge de Linus Torvalds a gnu.misc.discuss, el 17 de desembre de 1995.

.^17. Missatge de Linus Torvalds a nucli-discutir, 3 de desembre de 2003.

.^18. MySQL (2004a).

.^19. La seva interpretació té una base comercial: El MySQL AB utilitza un model de negoci de llicència dual. Venen llicències privatives a aquells usuaris -en general a algú que insereix la base de dades en un altre producte- que no volen estar subjectes a la GPL 2b). Vegeu la secció 7.2 per a una anàlisi més detallada.

.^20. McMillan (2003).

.^21. La GPL modificada d'Affero també està recolzada per FSF(2002).

.^22. Vegeu FSF (2003). Per ser precisos, la secció 6 de la GPL afirma explícitament: "No pots imposar més restriccions a l'exercici dels destinataris dels drets atorgats en el present".

.^23. Vegeu Wheeler (2004) per aquests i d'altres exemples. Alguns projectes simplement han autoritzat per duplicat el seu codi font amb GPL a més d'una llicència incompatible, mentre d'altres han revisat les seves llicències perquè siguin compatibles.

.^24. Vegeu FSF per a una llista. Gairebé totes les altres llicències recíproques són incompatibles. A més, algunes llicències permissives són incompatibles a causa, per exemple, de patents addicionals o requisits d'atribució.

.^25. Shankland (2004a). PHP té la seva pròpia llicència, que és de codi obert però incompatible amb GPL.

.^26. MySQL (2004).

.^27. Lawson (2004). Rosen (2004) analitza en profunditat la CPL en el seu llibre, i afirma (pàg. 163) que "alguns aficionats creuen que poden escriure llicències de codi obert. En primer lloc, haurien de llegir una bona llicència com la CPL i preguntar-se si són capaços de fer-ho tan bé".

.^28. Cal remarcar que la CPL no inclou explícitament res sobre obres més grans o combinades.

.^29. IBM (2002).

.^30. Rosen (2004), p. 172.

.^31. Actualment, el comentari de llicència de FSF remarca que mentre la clàusula fa la CPL incompatible amb la GPL, "no creiem que aquests requisits de llicència de patent siguin intrínsecament una mala idea". Vegeu FSF (2004).

.^32. Missatge de Lawrence Rosen a license-discuss@opensource.org el 28/7/2002.

.^33. Vegeu el missatge de Rosen a license-discuss@opensource.org el 5/11/2004. Per ser precisos, Rosen descriu el darrer exemple com una situació en què l'usuari penjaria el material als servidors del desenvolupador del cercador.

.^34. La secció 6 de l'OSD diu el següent: "La llicència no ha de limitar a ningú de fer ús del programa en un camp específic d'esforç", i aclareix que es refereix especialment a l'ús comercial. La GPL afirma que "l'acte d'executar el Programa no està limitat, i la producció del Programa només es cobreix si els seus continguts constitueixen una obra basada en el Programa".

.^35. Missatge de Rosen a license-discuss@opensource.org el 25/3/2004.

.^36. Rosen (2002).