|
|
Inici » Llibres » L'expansió de les llicències de codi obert » Les llicències de codi obert com a mecanismes alternatius de governança » La negociació a l'ombra de la llei de propietat intel·lectual
5.1 La negociació a l'ombra de la llei de propietat intel·lectual 5.1.1 Què fa que una llicència sigui de codi obert? L'Open Source Initiative accepta aquelles llicències que respectin l'Open Source Definition com a llicències de codi obert. Aquesta definició implica essencialment que una llicència qualificada permeti: [1]
Es tracta essencialment de requeriments basats en el fonament de la llei de copyright. La lògica bàsica és que els drets exclusius es transformin en no exclusius. Tots els elements importants del copyright, còpia, distribució i modificació, han de ser permesos explícitament en les llicències de codi obert. Això contradiu sorprenentment el pensament tradicional sobre els drets de propietat intel·lectual i atorgament de llicències en la indústria del programari. S'ha de subratllar que el codi obert no és de cap manera anticopyright. Tenir una llicència per al programari de codi obert no implica que el programari sigui donat automàticament al domini públic. El codi obert té propietari mentre el copyright tingui vigència. De fet, com veurem en el proper capítol, algunes llicències de codi obert posen condicions sorprenentment estrictes sobre l'ús del dret de modificació. A més, també es fan complir de forma explícita els components de copyright de caire moral (sobre tot aquells relacionats amb la propietat individual). 5.1.2 Què és el que no es requereix? L'Open Source Definition no és tan extensiva pel que fa al contingut típic de les llicències de programari. No hi figuren els requeriments explícits per a molts dels aspectes bàsics que apareixen en les lleis de propietat intel·lectual, excloent-hi les de copyright. No hi figuren requeriments sobre la compatibilitat de la llicència, garanties o formalitats. Drets morals. L'Open Source Definition fa menció omisa tant a l'atribució com a la reputació. Sens dubte, a la majoria de països les lleis de drets d'autor requereixen, per exemple, que el nom de l'autor no s'elimini dels treballs derivats. Però com ja hem dit al capítol anterior, els drets morals no han estat compilats en la llei de propietat dels Estats Units. A la pràctica, afortunadament, qualsevol llicència de codi obert requereix atribució. Com s'ha dit al final del capítol anterior, es pot entendre el codi obert com a quelcom que es basa fonamentalment en les idees sobre drets morals en el copyright. [6] Patents i altres llicències de propietat intel·lectual. Com ja s'ha dit, l'Open Source Definition planteja requisits en matèria de copyright però no pel que fa a la propietat intel·lectual. La definició no diu res en quant a patents. Òbviament, els requisits per a l'ús, dret de còpia, distribució i modificació sense cànons, impliquen que no pot haver-hi llicències que requereixin el pagament de cànons. El mateix s'aplica a les marques comercials. De totes formes, si que sembla permetre el cobrament de cànons de patents i marques comercials dirigides a qui no sigui l'usuaris particular del codi obert del programari. Per exemple, l'atorgant d'una llicència pot registrar la seva patent sense incloure-hi cànons per als usuaris dels codi obert, però alhora, pot cobrar cànons als usuaris d'un altre programari privatiu que implementi la mateixa invenció patentada. Drets de propietat controlats. Les llicències de codi obert no requereixen drets de propietat controlats però sí que han de permetre drets distribuïts i fragmentats. Com ja s'ha discutit en el capítol anterior, això implica certs advertiments. [7] Així doncs, la Free Software Foundation, per exemple, proposa als autors que utilitzin les seves llicències per transferir el copyright a la fundació, en el cas que aquesta s'hagi de fer complir legalment. Garanties. La definició tampoc requereix res pel que fa a les garanties. Això és, de fet, racional ja que les vendes de garanties tècniques (d'error) i legals (d'indemnització) poden constituir una font addicional d'ingressos per als desenvolupadors comercials de codi obert. Requerir un cert nivell de garantia mínima afebliria la possibilitat d'aquest model de negoci i, alhora, dissuadiria aquells desenvolupadors de programari que no poguessin acceptar cap responsabilitat legal pel que fan. La manca de tota garantia subratlla la possibilitat que hi hagi problemes de responsabilitat civil. Compatibilitat. L'Open Source Definition només estableix criteris per a la certificació d'algunes llicències de programari. No es tracta d'una especificació d'estàndards, que pretengui la interoperatibitat, i per tant el concepte de codi obert s'ha de mantenir fora del dels estàndards oberts. A la pràctica, en algunes ocasions un codi obert no es pot combinar amb un altre codi obert perquè les llicències dels dos codis font són incompatibles entre si. És cert que les incompatibilitats entre llicències fa que hi hagi menys efectes de xarxa, i fan més lenta la innovació. Formalitats. Finalment, aquesta definició no requereix que les llicències siguin vinculants o executables legalment. La validesa de qualsevol clàusula en una llicència de codi obert depèn de la capacitat d'execució legal que tingui. La qüestió de la validesa és especialment important en altres països fora dels Estats Units ja que la majoria de les llicències de codi obert s'han redactat i han estat formalment analitzades des de la perspectiva dels EUA. Els estudis legals en aquest camp semblen concloure que, tanmateix les llicències de codi obert, a la pràctica, s'haurien de poder executar a tot el món. [8] 5.1.3 Compliment d'un pacte de codi obert Teoria legal. La definició no diu si la llicència s'ha de basar únicament en la llei de copyright o s'ha de redactar com a contracte. Els pros i contres de les llicències de copyright en relació amb els contractes han estat un tema de debat important. El resultat potser ha estat que els contractes poden necessitar acceptació explícita del receptor de la llicència alhora que gaudeixen d'una base legal molt més solida. [9] Des que s'utilitzen llicències de programari, s'ha suggerit que aquests acords de llicència no poden ser executables ja que l'usuari pot no tenir en compte o acceptar les condicions de la llicència explícitament. De totes maneres, molts dels analistes de llicències de codi obert sostenen que les llicències són aplicables quan l'usuari segueix distribuint el programari, ja que la distribució d'aquest queda restringida fins que la llicència és acceptada. [10] És per aquesta raó que la lògica de la interpretació és que les llicències de codi obert són contractes (de mercats massius) que la llei fa executable: utilitzant qualsevol dels drets atorgats en la llei de copyright l'usuari ha d'acceptar la llicència completa. Pràctica paralegal. Tot i que és possible construir arguments a favor d'un fort sistema d'aplicació legal per a les llicències de codi obert , sembla ser que l'aplicació en si és paralegal. D'acord amb l'estudi empíric d'O'Mahony, la majoria dels projectes comunitaris cerquen el compliment de les llicències mitjançant mètodes informals com el debat a la xarxa, el correu electrònic o la publicitat negativa. Ni tan sols intenten amenaçar amb prendre accions legals o demanar compensació per danys i perjudicis. La justificació per l'aplicació ve de l"opinió col·lectiva imperant entre els membres de la comunitat. [11] Cal vigilar de no emfasitzar massa el paper dels mecanismes d'aplicació paralegal. Tot i que pugui ser ràpid, eficient i cobrir la majoria dels aspectes fonamentals de compliment de la llicència per una comunitat solidària de desenvolupadors, el seu abast és encara molt limitat. Si algú, acusat de violar una llicència, ho desitja, finalment pot anar a buscar l'opinió d'un tribunal de justícia. Però el que de debò compta és la lectura legal que es faci de la llicència en base a les lleis de propietat intel·lectual vigents. 5.1.4 Categories de llicències L'Open Source Initiative ha acceptat desenes de llicències de programari com a llicències de codi obert . Tot i que el nombre de llicències aprovades creix contínuament, no hi ha hagut gaires innovacions pel que fa a la funcionalitat de les llicències. Moltes de les llicències que s'han atorgat darrerament són variants específiques de llicències de projectes o empreses, o combinacions de llicències ja atorgades en el passat. Hi ha diferents maneres de classificar les llicències de codi obert . Metzger i Jaeger utilitzen sis tipus diferents en la seva anàlisi legal. [12] En aquest llibre utilitzem dos sistemes de classificació: funcional i històric. Segons la seva funcionalitat podem distingir tres categories diferents: Llicències amb (1) condicions de reciprocitat fortes i(2) estàndard i (3) llicències permissives. Basant-nos en el seu origen històric podem distingir quatre categories: (1) GNU, (2) acadèmiques, (3) de comunitat i (4) llicències corporatives. Anem a descriure cada una d'elles: Diferències funcionals. Des d'una perspectiva funcional, les llicències de codi obert es poden classificar segons la manera com tracten el dret de modificació del codi font (obres derivades). En primer lloc, definim la condició de reciprocitat estàndard i forta, de la següent manera: [13]
Algunes llicències amb condició de reciprocitat forta s'han ampliat encara més amb una condició d'ús en xarxa. Normalment es creu que les llicències amb condició de reciprocitat estàndard i forta són executables en el moment en què el programari és distribuït i, tradicionalment, la distribució és interpretada com a paquet de programari que es pot descarregar o en format tangible. La condició de xarxa afegeix que el simple ús del programari en una xarxa s'ha d'interpretar com a distribució. És per això que les llicències recíproques amb condicions addicionals d'ús en xarxa poden ser descrites com a llicències "encara més fortes" que aquelles amb condició de reciprocitat forta. A més de les llicències recíproques, una altra categoria funcional són les llicències permissives. Aquestes permeten la lliure distribució, còpia i modificació del programari. Fins i tot es permet el canvi de les condicions de la llicència del codi font original i per tant, en les llicències permissives no hi ha requeriments recíprocs. Les llicències permissives no inclouen clàusules per al seu ús en xarxa. En resum, podem il·lustrar les diferències funcionals entre els diversos tipus de llicències de codi obert en la següent il·lustració:
Figura 12. Diferències funcionals entre les llicències de codi obert segons combinació i modificació. El component d'un programari amb una obligació de reciprocitat forta mantindrà les seves condicions de llicència tot i que s'utilitzi com a part d'un treball combinat (com en el cas del programari incrustat). Sota els termes d'una condició de reciprocitat estàndard, un programari combinat pot ser rellicenciat, ja que el titular no està lligat per les condicions de la llicència. No obstant, si es desenvolupa més el component, tots el treballs derivats han de quedar englobats sota la mateixa llicència. Els components regits per llicències permissives no tenen cap d'aquestes restriccions i es poden combinar en programari privatiu i es poden desenvolupar sota qualsevol condició. - la condició d'ús en xarxa no apareix en aquesta il·lustració ja que aquesta es refereix a la distribució i no a la combinació o modificació del programari. Orígens històrics diversos. Moltes de les llicències de codi obert tenen una llarga història. Des d'aquesta perspectiva podem identificar quatre grans categories: llicències GNU, les acadèmiques, les de comunitat i les corporatives. Les diferencies aquí exposades no tenen a veure amb la funció de la llicencia sinó amb la llegibilitat de les llicències i el grau en què tenen en consideració altres drets i obligacions a més del copyright sobre el codi font. Aquest factors més pràctics poden ser decisius en l'elecció d'una determinada llicència, com veurem més endavant en aquest capítol. La primera categoria inclou les anomenades llicències GNU, introduïdes per Richard Stallman i la Free Software Foundation als anys vuitanta, que tenen una càrrega ideològica important. El llenguatge utilitzat en les llicències GNU és com el de qualsevol desenvolupador de programari "de mentalitat similar". Aquestes llicències ja són força populars entre els desenvolupadors. No sorprèn que a mesura que el codi obert s'ha popularitzat entre les empreses més grans, els advocats han començat a sentir-se indecisos vers les llicències GNU, tant per l'ambigüitat del seu llenguatge com per la incertesa en les implicacions del seu ús. De totes maneres, les llicències GNU es fan servir per tot tipus d'objectius, des del sistemes comunitaris com Linux fins al sistema MySQL, amb una orientació més empresarial. Desafortunadament però, les llicències GNU també pateixen problemes d'incompatibilitat amb altres llicències de codi obert, a voltes causats només per la ideologia intransigent de Stallman. Com és d'esperar, les llicències s'enfronten de cara amb les patents de programari: Aquelles patents vinculades a llicències GNU haurien de permetre l'ús gratuït universal de les patents dels programaris dissenyats amb llicències GNU. En la segona categoria hi trobem les llicències acadèmiques o de recerca. Aquestes llicències van néixer gràcies al desenvolupament dels grans projectes públics d'infraestructura d'Internet a les universitats dels EUA començant per l'UC Berkeley. Components importants relacionats amb Internet com, per exemple, el sistema denominador de dominis (BIND), el protocol d'Internet (TCP/IP) i el programa de gestió de correu electrònic (Sendmail) s'han convertit en estàndards de facto entre les permissives llicències acadèmiques. Les llicències acadèmiques estan escrites en un llenguatge curt i força entenedor tot i que no tenen gaire en compte els drets i obligacions amb els que els consells d'administració es puguin sentir a gust. De totes maneres, es podria suposar que una llicència acadèmica es llegeix més sovint que, per exemple, una llicència GNU i, probablement també és entesa per individus que no són desenvolupadors. Les llicències acadèmiques no acostumen a prendre una posició determinada en relació a les patents de programari o altres drets de propietat intel·lectual que no siguin aquells propis del copyright i són majoritàriament compatibles amb altres llicències de codi obert. La tercera categoria consisteix en les llicències de comunitat, i que normalment s'han originat en projectes importants de programari, i que han anat guanyant popularitat gràcies a Internet i als programes gratuïts de sistema Unix. La més popular d'aquestes és la Llicència artística distribuïda originàriament en llenguatge Perl. Es tracta d'un tipus de llicència molt orientada als hackers, amb una terminologia molt ambigua que presenta sovint problemes d'interpretació. Mentre que aquest tipus pot avenir-se clarament amb la cultura hacker, és molt probable que cap advocat corporatiu suggerís l'ús d'una terminologia tan arriscada i ambigua. Un altra llicència molt popular és la llicència Apache originària del servidor web i eines informàtiques de l'Apache Software Foundation. La llicència Apache, des d'un punt de vista legal, es considera més rígida que la Llicència artística, a més de tenir en consideració les possibles patents i marques registrades. Finalment, també s'hi podria afegir el domini públic dins la categoria comunitària, tot i que aquest també pot ésser vist com a grup separat. Quan, als anys noranta, el programari de codi obert es va popularitzar de forma important entre les empreses grans d'IT, moltes d'elles van començar a introduir llicències pròpies. La primera gran llicència corporativava ser introduïda per Netscape l'any 1998 quan van fer públic el codi font del seu popular navegador. Altres empreses grans d'IT incloent-hi IBM (Common Public License), Apple (Apple Public Source License) i SUN (Sun Public License i Sun Industry Standards Source License) van seguir aquest camí. La pròpia Open Source Initiative va introduir llicències de codi obert de caire més empresarial escrites en llenguatge legal (Open Software License i Academic Free License). Les llicències corporatives fan servir tradicionalment un llenguatge molt detallat i tracten qüestions com la llicència de patents i marques comercials, copyright de contribucions al codi i moltes altres qüestions formals que estan incloses en les llicències de codi obert. No obstant hi ha diferències. La llicència Sleepycat, que té els seus orígens històrics més enllà de l'Open Source Initiative, per exemple, s'assembla en el seu llenguatge a d'altres llicències de codi obert "pur". 5.1.5 Popularitat de les llicències de codi obert A la Taula 8, a continuació, hi figuren les llicències més populars a Sourceforge.net (a finals del 2004), que emmagatzema desenes de milers de projectes de codi obert i lliure.
Taula 8. Llicències de codi obert més utilitzades en projectes emmagatzemats a Sourceforge. [15] De tots els projectes a Sourceforge que inclouen informació sobre la llicència, un 1,7 % tenen una llicència privativa. Aquests percentatges només reflecteixen la popularitat de les llicències entre els projectes més recents i poc desenvolupats. Molts dels grans projectes de codi obert es coordinen mitjançant fòrums dedicats al desenvolupament. A més, la popularitat d'una llicència només indica la seva importància relativa. Com hem dit anteriorment, tot i que les llicències GNU semblen gaudir de molta popularitat, molts projectes importants de codi obert utilitzen llicències diferents. Hi ha estudis empírics sobre els usuaris i tipus de llicències. Lerner i Tirole van descobrir, a partir d'una anàlisi de Sourceforge, que els projectes de codi obert adreçats a desenvolupadors i els projectes que produeixen programari bàsic d'infraestructura d'Internet solen tenir llicències permissives. En comparació, els projectes de Sourceforge adreçats als usuaris finals solen tenir més llicències restrictives amb obligacions de reciprocitat. [16] A més, Fershtman i Gandal van observar que els projectes de Sourceforge amb llicències permissives generen més rendiment per desenvolupador que els projectes amb llicències recíproques. [17] 5.1.6 Marc per a l'anàlisi de les llicències A partir d'ara, algunes de les llicències de codi obert més rellevants en cada categoria s'introdueixen i s'analitzen des d'una perspectiva legal. Tenint en compte que les llicències canvien al llarg del temps, les anàlisis no tenen per objectiu una interpretació legal exhaustiva i pedant dels textos de llicència complets. Més aviat, l'objectiu és identificar com la funcionalitat principal s'ha aplicat en el text de la llicència i s'ha interpretat després a la pràctica. Amb cada llicència, es tractaran detalladament els aspectes següents:
A més, tractem la qüestió de la garantia de la propietat intel·lectual(indemnització) amb aquelles llicències que tenen o han tingut aquesta característica. També estem generalment interessats en com han evolucionat algunes llicències concretes. Es pot suposar que algunes de les característiques de les llicències són més estables, mentre que d'altres poden necessitar una revisió per raons, per exemple, d'interpretació o compatibilitat. El plantejament general de les llicències respecte als drets morals també s"esmenta breument. Abans de l'anàlisi, cal recalcar un cop més que la majoria de llicències de codi obert mai no han estat posades a prova als tribunals. Malgrat que les llicències poden fer-se complir a partir de la llei escrita, els litigis judicials sobre les llicències de codi obert han estat molt poc freqüents. [18] Comparant diferents condicions de llicència, des de les de codi obert fins a les privatives, el periodista Andrew Leonard ha observat que "les llicències són tan bones com la fe que la gent diposita en elles". [19] Per tant, a continuació, ens referim a més dels textos de llicència i les lleis de propietat intel·lectual, a les normes de comunitat informal, els debats en línia i els conflictes fora dels tribunals, els quals descriuen la manera com s'apliquen i interpreten les llicències en realitat. Notes .^1. Per a un resum similar de l'OSD, veure Rosen (2004), pàg. 9-11. .^2. Veure OSD, seccions 5 i 6. .^3. OSD, secció 1. .^4. OSD, secció 3. .^5. OSD, secció 2. .^6. Vegeu la secció 4.4. .^7. Vegeu la secció 4.2.5 .^8. Vegeu e.g. St. Laurent (2004), Guadamuz (2004), Malcolm (2003) i Metzger i Jaeger (2002). .^9. Les doctrines legals sobre contractes vinculants i llicències de copyright poden diferir significantment. Vegeu e.g. Rosen (2004). Sobre els argument en favor dels contractes, vegeu Malcolm (2003) .^10. Vegeu e.g. Moglen (2001a) i Guadamuz (2004), p. 334. .^11. O'Mahony (2003) es refereix a aquests mecanismes informals com a "tribunal de l'opinió pública". .^12. Vegeu Metzger i Jaeger (2002). .^13. El terme "reciprocitat" s'ha tret de Rosen (2004). En la documentació econòmica, per exemple, Lerner i Tirole (2005) utilitzen els termes restrictiva (estàndard) i molt restrictiva (forta) per referir-se a les llicències. És també força habitual, fins i tot en la documentació acadèmica, referir-se a les llicències recíproques simplement com a llicències "copyleft", seguint els objectius normatius de la Free Software Foundation. .^14. D'una banda, els crítics del codi obert poden comparar la situació amb la d'una infecció vírica en el sentit que fins i tot quan el nou programa es basi només parcialment en un codi font de reciprocitat forta, no es podran canviar les condicions de la llicència de la manera que estaria permès amb reciprocitat estàndard. De l'altra, la Free Software Foundation utilitza el terme copyleft, cosa que probablement defineix la seva postura ideològica envers el copyright. .^15. Les llicències descrites a la taula inclouen totes les versions. .^16. Vegeu Lerner i Tirole (2005). .^17. Vegeu Fershtman i Gandal (2004). Una raó pot ser que els projectes amb llicències recíproques tenen molts autors que només volen que hi figurin els seus noms. En canvi, els projectes amb llicències permissives solen atraure a persones que realment volen participar i aprendre del desenvolupament sense objectius oportunistes, com en la ciència ideal. .^18. Un d'aquests casos infreqüents va ser el litigi entre Progress Software Corp. i MySQL AB (2002), amb una sentència judicial d'un tribunal alemany a càrrec de Landgericht München, el 19 de maig de 2004. En ambdós casos, la GNU GPL va ser tractada com a vàlida. .^19. Vegeu Leonard (200b), comparant l'ètica de les llicències de codi obert amb les utilitzades pel sector de l'entreteniment. |
|
|||||
|
PORTADA
