L'expansió de les llicències de codi obert Mikko Välimäki Publicat per Turre Publishing, una secció de Turre Legal Ltd. Aleksanterinkatu 17, 6th floor, Helsinki, FI-00100, Finlàndia, http://pub.turre.com/ Copyright (c) 2005 Mikko Välimäki Primera edició Alguns drets reservats. Aquest llibre està sota les condicions de la llicència Reconeixement-NoComercial-SenseObraDerivada 2.0 de Creative Commons, disponible a http://www.creativecommons.org/. D'acord amb això, es permet la còpia, distribució, exposició i interpretació de l'obra sota les condicions següents: (1) cal donar crèdit a l'autor original, (2) no es permet l'ús de l'obra amb fins comercials, i (3) no es pot alterar, transformar, ni ampliar aquesta obra. ISBN: 952-91-8769-6 (printed) 952-91-8779-3 (PDF) Imprès a Helsinki University Printing House. Mikko Välimäki Taula de continguts Prefaci 8 Abreviatures 11 1 Introducció 13 1.1 Problema 13 1.2 Terminologia, perspectiva i limitacions 15 1.3 Mètode 17 1.3.1 Raó fonamental per als diferents mètodes utilitzats 17 1.3.2 Continuació de models en la història empresarial 18 1.3.3 Una perspectiva econòmica 19 1.3.4 Dret comparatiu i normes socials 20 1.4 Context i fonts acadèmiques 22 1.5 Visió global de l'estudi 24 2 De privatiu a obert: Evolució dels models de llicència en la indústria del programari 26 2.1 Indústria del programari 26 2.1.1 Breu repàs històric 26 2.1.2 Dimensions i regions del mercat 28 2.1.3 Emergència de codi obert 30 2.1.4 Models comercials de programari i codi obert 33 2.2 Llicències privatives 36 2.2.1 La decisió de separació d'IBM i les llicències empresarials 36 2.2.2 Llicència de mercats massius i programari de prova 39 2.2.3 Llicències privatives avui 42 2.3 Programari lliure i llicències de codi obert 46 2.3.1 Llicència de la BSD i copyrights d'Unix 46 2.3.2 Llicència pública general de GNU, Linux i SCO 49 2.3.3 El codi obert entra al vocabulari 53 2.4 Dimensions socials i polítiques del codi obert 57 2.4.1 El codi obert i l’apoderament individual 57 2.4.2 La Comunitat i els seus fronts 60 2.4.3 Objectius ètics o tècnics? 61 2.4.4 Influència en les institucions polítiques 63 2.4.5 Iniciatives pràctiques de polítiques públiques 64 2.5 Conclusió: Explicació del paper cada cop més important del codi obert 65 3 Principis econòmics dels productes informàtics 67 3.1 Caracterització econòmica dels productes informàtics 67 3.1.1 Perspectiva de l'economia de xarxa 67 3.1.2 Programari com un bé econòmic 68 3.1.3 Components i sistemes 71 3.1.4 Trajectòria de la dependència, immobilització i efectes de xarxa 73 3.2 Economia del copyright informàtic 75 3.2.1 Motivació dels desenvolupadors 76 3.2.2 Inversors i incentius 77 3.2.3 El cost de copiar 79 3.2.4 Límits òptims del copyright 80 3.2.5 Mecanismes de compensació 83 3.2.6 És ineficaç el copyright informàtic? 86 3.3 Economia de la innovació informàtica i les patents 87 3.1.1 Innovació a la indústria del programari 88 3.3.2 Relació difícil entre la innovació i les patents 90 3.3.3 Les patents com a actius estratègics 91 3.3.4 Diferents mitjans per apropiar-se la innovació 93 3.3.5 Un model d'innovació obert 94 3.4 Normativa de competència i els límits dels drets d'exclusivitat 97 3.5 Resum: Justificació econòmica de les llicències obertes 99 4 La propietat intel·lectual i els seus malcontentaments 101 4.1 Repte de la protecció del programari 101 4.1.1 Inicis de la discussió i pràctica 101 4.1.2 Proposta de l'OMPI 104 4.2 El copyright i els seus límits 105 4.2.1 El programari entra a la llei del copyright 106 4.2.2 El debat de la interoperabilitat 107 4.2.3 Abast actual del copyright informàtic 111 4.3 El retorn de les patents 113 4.3.1 L'exemple dels EUA 114 4.3.2 Europa segueix 115 4.3.3 Normativa internacional 119 4.3.4 Abast actual de les patents de programari 120 4.4 Protecció tècnica 121 4.4.1 Primers sistemes de protecció de còpia 122 4.4.2 Legislació antipirateria 123 4.4.3 És efectiva la protecció tècnica? 125 4.4.4 La promesa dels sistemes de confiança 126 4.5 Estan desequilibrades les lleis de propietat intel·lectual? 126 4.5.1 Principi d'equilibri 127 4.5.2 Tendència d'expansió 127 4.5.3 El codi obert com a força d'equilibri? 130 4.6 Reflexions finals: Perspectiva oberta sobre la propietat intel·lectual 132 5 Les llicències de codi obert com a mecanismes alternatius de governança 134 5.1 La negociació a l'ombra de la llei de propietat intel·lectual 134 5.1.1 Què fa que una llicència sigui de codi obert? 134 5.1.2 Què és el que no es requereix? 135 5.1.3 Compliment d'un pacte de codi obert 137 5.1.4 Categories de llicències 138 5.1.5 Popularitat de les llicències de codi obert 143 5.1.6 Marc per a l'anàlisi de les llicències 145 5.2 GNU GPL i reciprocitat forta 146 5.2.1 Obres derivades en la llei de copyright 146 5.2.2 Obres derivades i la GPL 153 5.2.3 Les patents i la GPL 162 5.2.4 GPL i compatibilitat de llicència 163 5.2.5 Altres Llicències amb Reciprocitat Forta 165 5.3 GNU LGPL i reciprocitat estàndard 170 5.3.1 Funcionalitat LGPL 170 5.3.2 Altres llicències amb reciprocitat estàndard 172 5.4. BSD i les llicències permissives 175 5.4.1. La funcionalitat de BSD 175 5.4.2 Altres llicències permissives 176 5.5 Excursió: Llicències de continguts oberts de Creative Commons 178 5.5.1 Antecedents 178 5.5.2 La funcionalitat de Creative Commons 180 5.5.3 Assignació de riscos i garanties 182 5.5.4 Internacionalització i formalitats 184 5.5.5 Reflexions finals 186 5.6 Resum Competència entre les normes de concessió de llicències en evolució 186 6 Defensa amb codi obert Gestió del risc d'usurpació i patents 189 6.1 Com fer front al risc d'usurpació dels DPI? 189 6.1.1 Antecedents 189 6.1.2 Natura de les usurpacions dels DPI per tercers 191 6.1.3 Alternatives per afrontar els riscs 194 6.1.4 Pràctiques reals de gestió 200 6.1.5 Reflexions finals 205 6.2 Els problemes de les patents i les possibles polítiques per resoldre-ho 206 6.2.1 Antecedents 206 6.2.2 Llicències de codi obert i risc de violació de patents 207 6.2.3 Procés de desenvolupament des de la perspectiva de les patents 208 6.2.4 Debat sobre polítiques de codi obert i patents 210 6.2.5 Exempció de responsabilitat en el cas del codi obert? 212 6.3 Conclusió: Les lleis sobre drets de propietat intel·lectual són millorables 213 7 Us ofensiu del codi obert: Alguns casos pràctics sobre llicències 215 7.1 Llicències de codi obert per obtenir guanys 215 7.1.1 Possibilitats d'establir preus per als productes 215 7.1.2 Com controlar el desenvolupament? 216 7.2 Estudi de cas 1: Les llicències lliures i el programari dels sistemes operatius 219 7.2.1 Introducció 220 7.2.2 Perspectiva general del mercat 222 7.2.3 Marc d'estudi 223 7.2.4 Microsoft Windows 224 7.2.5 Apple OS X 228 7.2.6 Distribucions GNU/Linux 230 7.2.7 Reflexions finals 232 7.3 Estudi de cas 2: Llicència dual i programari incrustat 234 7.3.1 Com funciona la llicència dual? 234 7.3.2 Marc d'estudi 236 7.3.3 Sleepycat Software Inc. 237 7.3.4 MySQL AB 240 7.3.5 TrollTech AS 241 7.3.6 Quan té sentit la llicència dual? 243 7.4 Reflexions finals 245 8 Conclusions 247 8.1 L’expansió del codi obert 247 8.2 Impacte sobre les pràctiques llicenciadores 248 8.3 Impacte en la gestió de la propietat intel·lectual 250 8.4 Impacte en la regulació comercial i estudi legal 251 Figures i Taules 254 Referències 256 Articles, llibres i informes 256 Notícies, entrevistes i recursos en línia 268 Jurisprudència, documents oficials i llicències 278 Índex analític 282 Repte a l'ús de la propietat intellectual en la indústria del programari Prefaci Aquest llibre és el resultat del meu doctorat a la Universitat de Tecnologia d'Hèlsinki. Vaig començar a treballar en el meu doctorat just després de llicenciar-me a la Universitat d'Hèlsinki el 1999. Havia d'escriure una tesi en dret. Ara m'he d'excusar davant dels meus directors de tesi d'aleshores, el professor Niklas Bruun i el docent Pekka Timonen per no haver completat la tesis a la facultat de Dret en quatre anys, tal com s'havia planificat. El que va passar és que vaig conèixer el meu futur mentor acadèmic, el professor Jukka Kemppinen, que tot just començava aleshores el seu mandat a la Universitat de Tecnologia d'Hèlsinki. A finals de 1999, em va convèncer de canviar de plans i d'universitat. El veritable tema d'aquesta tesi es va començar a perfilar durant el meu any a la UC Berkeley del 2000 al 2001. En aquell moment treballava amb Olli Pitkänen i havíem d'estudiar la gestió de drets digitals. Però vaig seguir endavant i em vaig trobar amb el codi obert. Vaig tenir la sort de participar en algunes de les primeres conferències de comerç i tecnologia de la història organitzades sobre aquest tema a Califòrnia. Vaig concloure que aquesta és l'àrea de la que n'entenc més i, cal dir que no sembla que sigui una moda que hagi de desaparèixer en els pròxims dos anys. Per tant, per què no escriure sobre aquesta qüestió? Els períodes més importants per a la redacció d'aquest llibre van ser a l'octubre del 2003 a biblioteques i cafès de Berkeley, i a l'agost del 2004 als Starbucks de Santiago de Xile. A més, hi va haver també aquelles nits numerables en què enllestia articles independents, que formen subparts importants d'aquesta tesi. Vaig acabar l'obra completant totes les parts que faltaven o quedaven per lligar sota la supervisió del professor Juha Laine. Els examinadors de tesi, el professor Jukka Heikkilä i el doctor Ikka Rahnasto van fer molts comentaris substancials a una versió primerenca d'aquest llibre. La majoria, els he tingut en compte. El professor Thomas Riis de l'Escola Empresarial de Copenhague va acceptar amablement la invitació a ser l'oponent acadèmic. La meva comprensió del codi obert s'ha beneficiat en gran mesura de les discussions amb aquells que treballen en la indústria del programari. A mesura que l'interès públic en el codi obert ha augmentat, m'he trobat donant conferències i assessorant sobre llicències de codi obert a diverses organitzacions, des d'empreses finlandeses de programari a l'Inter-American Development Bank. Vull fer menció especial d'Antti Halonen que em va introduir al MySQL abans que existís una empresa per aquest projecte en particular. Mårten Mickos, director executiu de MySQL des del 2001, també ha ajudat amb comentaris constructius i compartint amablement les seves connexions. Un gran agraïment també per als meus col·legues d'investigació Ville Oksanen i Herkko Hietanen. A més de diversos articles escrits en col·laboració, la fundació d'Electronic Frontier Finland el 2001 m'ha perfeccionat la meva destresa en l'argumentació i l'escriptura en general. Mitjançant aquesta associació, he tingut l'oportunitat de participar en la discussió, des de dins, sobre la regulació pública de copyright i patents. També vull donar les gràcies a Olga ja Kaarle Oskari Laitisen Säätiö, la Fundació Jenny i Antti Wihuri, Helsingin Sanomain 100-vuotissäätiö, Soneran tutkimussäätiö, la Fundació Ella i Georg Ehrnrooth, i la Fundació de Recerca de la Universitat de Tecnologia d’Hèlsinki per les seves subvencions per a la meva investigació en el moment que més necessitava aquest suport. Finalment, gràcies a la meva família, amics i col·legues que no han estat esmentats especialment. És molta la gent que he conegut a les universitats, conferències, reunions de negocis i bars arreu del món que han donat el seu suport i contribució d'una manera o una altra a aquest projecte. No em sembla bona idea posar-vos tots a la llista. "Meet the new boss - same as the old boss."* Lauttasaari, Hèlsinki, 30 de març de 2005 Mikko Välimäki Abreviatures BSA Business Software Alliance BSD Berkeley Software Distribution CC Creative Commons CPL Common Public License (Llicència Pública Comuna) CP/M Control Program for Microcomputers EPO European Patent Office (Oficina Europea de Patents) UE Unió Europea FLOSS Free/Libre and Open Source Software FSF Free Software Foundation GNU GNU que no són Unix* GPL GNU General Public License (Llicència Pública General de GNU) PI Propietat Intel·lectual DPI Drets de Propietat Intel·lectual TI Tecnologia de la Informació LGPL GNU Lesser General Public License (Llicència Pública General Menor de GNU) MIT Massachusetts Institute of Technology MPL Mozilla Public License (Llicència Pública de Mozilla) MS-DOS Microsoft Disk Operating System OSD Open Source Definition OSI Open Source Initiative OSL Open Software License OSS Open Source Software PC Personal Computer TC Trusted Computing EUA Estats Units USPTO United States Patents and Trademark Office (Oficina de Patents i Marques dels EUA) W3C World Wide Web Consortium WIPO - OMPI World Intellectual Property Organisation - Organització Mundial de la Propietat Intel·lectual WTO - OMC World Trade Organisation - Organització Mundial del Comerç 1 Introducció 1.1 Problema MOUNTAIN VIEW, Califòrnia (23 de febrer del 1998) - Netscape Communications Corporation (NASDAQ:NSCP) ha anunciat avui la creació de mozilla.org, un equip especialitzat dins de Netscape amb un lloc web associat que promourà, fomentarà i guiarà un diàleg obert i desenvolupament de codi del client de Netscape. "Netscape és la primera gran empresa en explotar el poder de l'estratègia del codi obert, " ha dit Eric S. Raymond, defensor i desenvolupador de codi obert. "Fer que la font del programari del seu client sigui de codi obert per als desenvolupadors és un pas decidit que representarà grans millores per als seus productes."1 Craig Mundie, Microsoft CTO, 16 de maig del 2001: "Quan es compara el model de programari comercial amb el model de programari de codi obert, cal mirar amb atenció el model comercial i les estructures de llicència que formen els seus fonaments. Aquesta comparació porta a la conclusió que només el model de programari comercial té la capacitat de mantenir un veritable creixement econòmic. El capital intel·lectual sempre ha estat, i serà, l'actiu principal de la indústria del programari, i gairebé totes les altres indústries. Si es conserva aquest capital, i s'inverteix en la seva renovació constant, tothom se'n beneficia."2 Aquest llibre és un estudi sobre la manera com el codi obert ha desafiat el pensament i ús real de la propietat intel·lectual en la indústria del programari. L'emergència del programari de codi obert i la ràpida expansió de la Internet han introduït noves pràctiques de llicència de programari al mercat massiu. Per poc temps, com a mínim, nous candidats han desafiat els titulars en els mercats en expansió de programari amb l'ajuda d'estratègies innovadores de llicència de copyright i una atrevida normativa antipatent. El sistema operatiu de GNU/Linux, el servidor de web Apache i la base de dades MySQL són potser els exemples més coneguts de programari de codi obert. Per la seva banda, les empreses més grans de la indústria des d'IBM a Apple s'han adaptat als canvis del medi amb diverses estratègies d'operació i de llicència de codi obert. Però no tothom hi surt guanyant; Netscape ha perdut el seu mercat malgrat el seu "pas decidit" cap a un estratègia de codi obert el 1998. Altres iniciatives tampoc no ho han tingut fàcil per convèncer que passar-se al codi obert pot ser realment una decisió comercial viable. Això ens condueix a les preguntes principals d'aquest estudi: El codi obert ha canviat les pràctiques de llicència en la indústria del programari des d'una perspectiva històrica? (capítol 2) Funcionen les teories econòmiques sobre programari, copyright, i innovació amb els principis de codi obert? (capítol 3) Desafia el codi obert el desenvolupament de copyright de programari, patents i altres lleis de propietat intel·lectual? (capítol 4) Quines són les llicències de codi obert més rellevants i com s'han bastit pel que fa a la llei de la propietat intel·lectual i la teoria econòmica? (capítol 5) Com són de reals els riscs d'infracció de patent o altra propietat intel·lectual en l'ús del codi obert i com els riscs potencials es poden gestionar defensivament a nivell de política social i empresa individual? (capítol 6) Hi ha casos interessants en la indústria on els models de llicència de codi obert s'han utilitzat com a eines competitives? (capítol 7) L'argument general del llibre és que la llicència de codi obert ha canviat realment la manera de pensar de la indústria del programari i d'utilitzar la propietat intel·lectual . Gairebé totes les principals empreses de programari del món han començat a adoptar, des del 1998, models de llicència de codi obert com a part del seu negoci. Models de codi obert i còpia i distribució lliure han fet camí en la pràctica de llicències de propietat intel·lectual de les empreses de pes de la indústria. Pot molt ben ser que en algunes àrees d'aplicació -com el programari bàsic d'infraestructura d'Internet- no hi hagi en el futur mercats massius de llarga durada per a productes de programari de codi tancat amb condicions de llicència restrictives. Tot i amb això, es fa difícil valorar si el canvi ha estat realment fonamental i profund. En molts sectors de la indústria del programari -tal com el desenvolupament de programari personalitzat i les aplicacions específiques de la indústria- el codi obert encara no es considera una possibilitat. Aquest llibre també defensa que les implicacions del codi obert per a la gestió de la propietat intel·lectual tenen dues vessants. Primer, els riscs d'infracció de la propietat intel·lectual s'han de prendre més seriosament quan es fa servir el programari de codi obert. I això és perquè el codi obert augmenta els efectes negatius de l'expansió continua dels drets de propietat intel·lectual . En segon lloc, "les empreses d'Internet" estan arribant finalment als mercats de programari. Això vol dir que el valor de la propietat intel·lectual augmenta en compartir-lo però també resulta més complex apropiar-lo. Finalment, aquest llibre demostra que el codi obert pot tenir implicacions rellevants en la normativa dels drets de propietat intel·lectual. En primer lloc, l'obertura equilibra la normativa comercial. Els sistemes de llicència oberta han demostrat que els possibles inconvenients de la sobreregulació es poden superar sense intervenció de l'Estat. D'aquesta manera, el codi obert també posa de relleu un estudi més material dels drets de propietat intel·lectual. Quan un nombre considerable de titulars de drets en una indústria determinada decideixen no fer valer els seus drets bàsics de propietat intel·lectual -basant-se en arguments econòmics i racionals- les premisses de la discussió sobre la normativa es veuen d'un altre color. Per què i com ho fan les empreses? Què significa això per al sistema de la propietat intel·lectual en conjunt? El fet que s'hagin de fer valer totalment davant del govern els drets de propietat intel·lectual és novament una qüestió rellevant tant per a un desenvolupador de programari com per a un legislador. 1.2 Terminologia, perspectiva i limitacions L'objectiu principal d'aquest llibre és el dret de la propietat intel·lectual (DPI) Es pot definir com un monopoli (o privilegi) limitat -tant pel que fa a termini i abast- acordat pel govern per regular certs usos de programari. Aquesta definició de monopoli assumeix implícitament que els drets no poden ser omnipotents sinó que s'han d'equilibrar. Per questions pràctiques, la discussió es limita al copyright (referent a "obres") i patents (referent a "innovacions"). En documents legals més formals, les expressions "la protecció de copyright de programes informàtics" i "innovacions implementades amb ordinador" són d'ús corrent. Aquest llibre fa servir, tanmateix, termes més generals com ara copyright de programari i patents de programari quan es parla de copyright i patents en referència a programes informàtics. Aquesta terminologia és també més corrent en documents econòmics i d'altres ciències socials. Les llicències de programari són documents contractuals, que defineixen com s'han de fer servir el drets de patent i el copyright. Unllicenciador acostuma a ser un desenvolupador de programari que dóna llicència per més o menys d'aquests drets a llicenciats. Un llicenciat tant pot ser un altre desenvolupador com un usuari final. El terme codi obert es defineix com un seguit de llicències de programari, que segueixen certs criteris definits en l’Open Source Definition. Així, aquest llibre estudia com les empreses de programari apliquen les lleis de propietat intel·lectual amb llicències de codi obert. - Amb programari privatiu i llicències, aquest llibre es refereix en general a tot menys al codi obert. Tot i amb això, no es tracta d'una categorització clara i neta. Hi ha moltes llicències privatives que compleixen alguns dels criteris de codi obert, (és a dir, codi font compartit, sense copyright ni drets de patents), però no tots. Per indústria de programari en aquest llibre ens referim a empreses que ofereixen productes comercials de programari per a servidor i ordinadors de taula. Específicament, es refereix a aquelles parts de la indústria on les llicències de codi obert es fan servir de forma considerable. Evidentment no és possible valorar les pràctiques i implicacions de llicències a la indústria en general. Així, per exemple, qüestions específiques amb jocs d'ordinador i sistemes incrustats en general s'han omès. En aquest llibre hi ha dues perspectives principals: En primer lloc, la d'un desenvolupador de programari - que acostuma a ser una empresa de programari. Com que la llicència és essencialment una de les funcions operatives de qualsevol empresa de programari, és natural que es discuteixi l'impacte del codi obert en les pràctiques de llicència. A més, la perspectiva del desenvolupador sovint encaixa amb l'opinió d'empreses petites o mitjanes, o altres empreses independents, tot el negoci de les quals depèn de les decisions sobre les llicències. En segon lloc, la d'un legislador. Les implicacions generals de canviar pràctiques de llicències tenen a veure amb la normativa. Aquest estudi identifica implicacions en la regulació de copyright i patents com també en la gestió de la propietat intel·lectual dins de les empreses de programari. En resum, aquest llibre veu els drets de propietat intel·lectual "en acció". Les perspectives seleccionades limiten necessàriament i fins a cert punt el plantejament. Per exemple, les discussions descriptives sobre l'evolució històrica i els conceptes legals (estàtics) de copyright de programari finalment només recolzen les tesis principals del llibre. 1.3 Mètode 1.3.1 Raó fonamental per als diferents mètodes utilitzats Capítols 2-4 construeixen una teoria de llicència de programari des de les perspectives històrica, econòmica i legal. En el segon capítol, la discussió parteix de la història empresarial que explica el paper de les llicències de programari lliure en la indústria del programari. En el tercer capítol, es descriuen les teories econòmiques de xarxes, copyright, patents i innovació i es debat el paper dels models de llicències de codi obert dins de la teoria. En el quart capítol, el mètode és bàsicament la descripció mitjançant la història legal de la protecció legal del programari desenvolupada i interpretada fins al moment actual. El raonament per aquest plantejament en tres parts (història, economia i llei) és pressuposar que per entendre completament les llicències de codi obert cal ser conscient d'una sèrie de factors que els desenvolupadors de programari consideren abans de decidir res sobre llicències. A més dels raonaments purament econòmics, hi ha importants ramificacions legals que determinen les opcions de llicència disponibles. I per sobre de tot això, hi ha fets ideològics, filosòfics, tècnics i socials que poden ser decisius en alguns contextos. És a dir que una visió superficial del fenòmen de les llicències de programari de codi obert estaria plena de mitges veritats i errors. Tot i amb això, cal preguntar-se: per què parlem de diferents plantejaments en un estudi? Per què no delineem simplement el problema a estudiar de manera que per exemple només s'estudiés el caràcter legal i l'analítica legal de les llicències? De nou, aquí es pressuposa que aquest estudi per separat tindria menys importància pràctica i històrica que la que barreja el coneixement dels diferents camps d'estudi. 1.3.2 Continuació de models en la història empresarial Uns quants aclariments sobre el mètode d'anàlisi històrica utilitzada en aquest llibre. En la recerca històrica, aquest llibre posa èmfasi en el paper de models i processos socials continuats per sobre d'esdeveniments únics. Per exemple, l'arrel de l'assoliment del codi obert a finals dels anys 90 la trobem en les comunitats dels primers aficionats informàtics dels anys 60. Amb els canvis necessaris en l'entorn, tal com el creixement d'Internet com a plataforma de comunicació i el desplaçament en la informàtica empresarial d'ordinadors centrals a microordinadors barats, el codi obert i les idees de compartir i de comunitat van tornar i van prendre el relleu. Hi ha semblances substancials entre la nostra anàlisi del triomf del codi obert i el plantejament de Chandler de la història empresarial de l'electrònica i les indústries informàtiques del segle XX com també el plantejament de Christensen dels models d'innovació tecnològica.3 Les innovacions han pogut guanyar repetidament mercat (provisional) en la indústria del programari fins que els proponents de noves fites i idees tecnològiques han pres control. En aquest sentit, el codi obert es pot veure com una nova manera revolucionària de fer i distribuir programari en el nou entorn. Tot i amb això, el codi obert no és un paradigma tecnològic. Es tracta encara més de quines maneres fonamentals se està desenvolupant socialment el programari i se li atorguen llicències legalment. En aquests sentits, el canvi que el codi obert ha portat a la indústria del programari sembla, si més no per ara, més fonamental. La tecnologia canvia, es podria dir, més ràpidament que les normes legals i socials. Per tant, es posa més èmfasi en les dimensions social i normativa que en els estudis més tradicionals de la història de la indústria.4 Per exemple, qüestions com l'emergència de normes comunitàries de desenvolupament i la formació d'una normativa legal envers interfuncionabilitat i patents de programari es tracten en aquest llibre amb més detall. Finalment, a l'hora de descriure models històrics cal ser selectiu. Òbviament no és possible detallar a la perfecció tots els esdeveniments, la combinació dels quals va portar a resultats particulars. Hi ha moltes maneres alternatives i convincents d'explicar la història del codi obert en el context de la indústria del programari. L'autor ha fet servir un plantejament de baix a dalt: per exemple la història de les llicències del programari es veu des de la perspectiva de desenvolupadors individuals i autors de llicències. Al capdavall, les llicències de codi obert es poden relacionnar amb les idees de programadors individuals i les seves pràctiques de llicències anteriors. Així, la història, per exemple, les llicències de programari de prova dels anys 80 s'han d'explicar més que les pràctiques de llicències del programari empresarial d'aquella època. 1.3.3 Una perspectiva econòmica L'anàlisi econòmica en aquest llibre es pot descriure millor dient que segueix el plantejament anomenat de fàbrica d'agulles. En resum, l'objectiu és entendre com el negoci i l'economia de les llicències de codi obert funcionen a la pràctica mitjançant entrevistes i observacions pràctiques tant en temps real com en els arxius de discussions a Internet. Per tant, el resultat s'explica en termes d'economia.5 Els conceptes econòmics emprats en la discussió acadèmica sobre xarxes, copyright, patents i innovacions s'introdueixen i es discuteix la seva aplicabilitat en el desenvolupament del codi obert. Un repte evident en aquesta mena de plantejament descriptiu és que molts d'aquests conceptes s'utilitzen en la discussió de regulació normativa com la regulació de patents de programari. El fet és que molts acadèmics poden tenir molts objectius normatius amagats en els seus arguments. Aquesta és la raó principal per la qual la discussió sobre conceptes econòmics es manté més aviat abstracta. Tot i que aquest llibre discuteix els aspectes econòmics del copyright i les patents entre altres, cal aclarir que l'objectiu no és seguir un plantejament legal i econòmic tradicional. Acceptem que les lleis són sempre més o menys ineficients. A més, és útil tendir cap a més eficiència social mitjançant desenvolupament legal només quan la llei es troba seriosament desequilibrada i quan es pot aplicar amb un cost relativament moderat. En molts casos hi ha mecanismes alternatius de governança per complementar el desenvolupament d'institucions legals formals.6 Així, la idea principal d'aquest llibre és estudiar com les llicències privades de codi obert equilibren les ineficiències "normals" en la regulació de propietat intel·lectual i com els arranjaments de llicències han causat potser diferents menes d'ineficiències en els mercats de programari.7 També, ens interessen les possibilitats estratègiques i pràctiques que tenen els desenvolupapadors de programari per reaccionar a les implicacions econòmiques de les lleis existents. En aquesta anàlisi, el joc que els models teòrics van crear en la documentació econòmica de l'estratègia empresarial -incloent els aspectes econòmics de les xarxes i la innovació- en general van ajudar a posar de relleu els trets de l'entorn més importants que afecten la presa de decisió individual.8 1.3.4 Dret comparatiu i normes socials Tot i que la majoria de llicències de codi obert s'han redactat segons les lleis dels Estats Units, cada una s'hauria d'interpretar legalment en la jurisdicció on la llicència realment s'usa. Tanmateix, cal destacar que l'ús real de les llicències és flexible i extraterritorial -independentment d'interpretacions legals nacionals possiblement diferents. Desenvolupament distribuït i redistribució gratuïta a Internet no s'aturen a les fronteres ni davant de lleis nacionals. Per tant, aquest llibre té un plantejament internacional i comparatiu de l'anàlisi legal.9 Seguint Mattei, veiem les fonts legals en un marc competitiu.10 No hi ha cap llei específica sobre els drets en programari i els litigis en qüestions de llicències de codi obert han estat ben pocs. Així doncs, la interpretació de les llicències hauria de començar pels principis de copyright i altres lleis de propietat intel·lectual i per una jurisprudència ja desenvolupada en llicències de programari. A més, també s'han de tenir en compte les anomenades normes de comunitat com a font normativa competitiva. Es manifesten, per exemple, en les pautes ètiques de la comunitat de desenvoolupament i les llistes de preguntes més freqüents fetes pels autors de llicències i portaveus de la comunitat.11 Des d'una perspectiva legal restringida, les normes de la comunitat es poden veure com normes secundàries que reflecteixen els objectius de les llicències. A la pràctica, les normes concretes de la comunitat poden afectar encara més el comportament dels desenvolupadors de programari i els usuaris que les lleis i contractes formals. Els motius potencials són que les regles legals aplicables sobre els drets i llicències de propietat intel·lectual són poc clares, les comunitats de desenvolupadors formen unes xarxes socials força unides que voluntàriament eviten disputes legals, i que els costos de l'aplicació de la llei a Internet són alts.12 Linus Torvalds ha dit respecte al risc que la GNU General Public License (GPL) de Linux no es respectés: "Les meves pors s'han mitigat amb la realitat. Algú ho farà un temps, però es la gent que realment respecta el copyright, la que aporta els canvis al nucli i el milloren... En canvi, la gent que no respecta la GPL no podrà beneficiar-se de les actualitzacions, i els seus clients els deixaran. Això espero."13 Tal com s'ha indicat, els conflictes legals i violacions de llicències actuals han estat notablement pocs tenint en compte la popularitat del codi obert. Això s'ha d'atribuir sobretot a l'autocontrol proactiu de la comunitat i l'efectiva resolució mútua de conflictes, per exemple aturant la distribució de codi obert que no respecta la llei, reescrivint les parts que no la respecten o comprant una llicència privativa.14 Amb aquesta base, la recerca legal en aquest llibre no s'atura en l'anàlisi conservadora de riscos del capítol sis sinó que continua investigant les possibilitats i efectes empresarials de les noves i innovadores tècniques de llicències del capítol set. 1.4 Context i fonts acadèmiques Ja s'han publicat molts llibres sobre codi obert des de perspectives tècniques, empresarials i socials.15 Fàcilment es poden trobar centenars d'articles acadèmics des d'angles diferents.16 També hi ha com a mínim tres llibres que tracten específicament de les llicències de codi obert.17 Tanmateix, la majoria de material publicat en forma de llibre és fins ara més aviat pràctic i limitat estrictament a l'anàlisi legal. En contrast, l'objectiu d'aquest estudi és oferir una visió integral i acadèmica, però alhora històricament equilibrada i pràcticament útil, de tot el ventall de fenòmens de llicències de codi obert. Tot i que es pugui criticar aquest objectiu per ser massa ampli, el llibre sí que té un plantejament clar. La tradició acadèmica principal a la que es pot connectar aquest llibre és a la dels aspectes econòmics i legals dels drets de propietat intel·lectual. Les anàlisis històriques i legals recolzen al capdavall la feina d'explicar com la popularitat creixent de les llicències de codi obert afecta (i ho fa) les pràctiques de la indústria de la gestió de drets de propietat intel·lectual. De manera específica, aquest llibre vol contribuir a: Una perspectiva històrica empresarial sobre l'emergència de llicències de codi obert com a model combinant llicències anteriors de programari i pràctiques de desenvolupament. Anàlisi més profunda de les qüestions claus de la propietat intel·lectual en llicències de codi obert i el seu impacte en les empreses de programari. Nous estudis de casos reals en el món de gestió de riscos en propietat intel·lectual i pràctiques de llicències en desenvolupament de codi obert. Les fonts principals d'estudi són la documentació acadèmica sobre la història de la indústria del programari, aspectes econòmics del programari i dret de propietat intel·lectual en programari. A més, s'han fet servir revistes importants de l'ofici i fonts en línia per proporcionar detalls sobre les pràctiques reals de la indústria i comentaris sobre esdeveniments històrics. A les parts empíriques dels capítols sis i set, les dades s'han obtingut en entrevistes, qüestionaris i dades comercials i estadístiques disponibles. Molts estudis sobre la indústria del programari comencen declarant que no hi ha massa investigació prèvia donat que la indústria és encara relativament jove.18 Tot i que aquesta afirmació és força certa, també menysvalora la quantitat de recerca feta. Avui no és gaire difícil trobar recerca recent sobre la indústria del programari començant per la història de la indústria. El mateix es pot dir sobre els aspectes econòmics; els conceptes centrals utilitzats en aquest estudi tal com l'economia de les xarxes, copyright, patents i innovació tecnològica s'han estat estudiant de manera important des dels anys 60. Les qüestions legals referents a la protecció de programari tampoc són noves; les arrels de la discussió sobre copyright i patents de programari modern també vénen dels anys 60. Tal com s'ha indicat, al llarg dels últims anys, la documentació acadèmica sobre codi obert ha pres volada. 1.5 Visió global de l'estudi El segon capítol del llibre descriu el creixement, la dimensió i la segmentació de la indústria internacional de programari. Estem especialment interessats en la manera com s'ha venut el programari i com les llicències de programari lliure i de codi obert han emergit per desafiar les pràctiques establertes de la indústria. També parlem de les qüestions de llicències en el desevolupament de normativa de la indústria. El tercer capítol analitza les teories econòmiques de xarxes, copyright, patents i innovació en el contex dels productes de programari. Totes les teories caracteritzen diferents aspectes dels productes de programari amb algunes diferències però també alguns similituds. L'objectiu d'aquest capítol és construir una teoria coherent on els models de llicències de programari de codi obert es puguin analitzar dins un context econòmic més ampli. El quart capítol discuteix l'evolució de la protecció legal i tècnica del programari. Alguns comentaristes han criticat que l'expansió continuada de diferents lleis de propietat intel·lectual de programari que se solapen ha implicat que la llei ara estigui considerablement desequilibrada. Acabem el capítol repassant les proves i discutint les possibilitats d'equilibri particular de les lleis de propietat intel·lectual mitjançant el codi obert. El cinquè capítol explica com han evolucionat en la pràctica diferents llicències de codi obert. S'han categoritzat les llicències i se n'ha analitzat més la funcionalitat. S'han identificat qüestions d'interpretació oberta de la indústria del programari. Finalment, el capítol acaba amb una discussió de contingut obert sobre la manera com les tècniques de llicències de codi obert s'han adoptat per ús en altres obres d'art fora del programari informàtic. Tot ús de codi obert en un entorn empresarial inclou riscos legals. En aquest capítol expliquem com els riscos d'infracció de les patents de programari i de la propietat intel·lectual es poden gestionar a nivell d'empresa individual i de regulació social. Comencem per les alternatives més generals de la gestió de riscos d'infracció de drets de propietat intel·lectual en el desenvolupament del codi obert. A partir d'aquí, la discussió s'extén fins al problema social de les patents de programari especialment en el context de la normativa europea. Finalment, el capítol set estudia com les llicències de codi obert s'han fet servir de manera ofensiva com part d'una estratègia empresarial de canvi de mercat. El primer cas tracta els mercats de programari de sistema operatiu i com les alternatives de codi obert han canviat l'estructura del mercat existent durant els últims anys. El segon descriu un model específic de llicències de codi obert anomenat llicència dual i explica com diverses empreses noves s'han beneficiat fent-lo servir. 2 De privatiu a obert: Evolució dels models de llicència en la indústria del programari Aquest capítol descriu el creixement, la mida i la segmentació de la indústria internacional de programari. Estem especialment interessats en la manera com s'ha venut el programari i com les llicències de programari lliure i de codi obert han emergit per desafiar les pràctiques establertes de la indústria. També parlem de les qüestions de llicències en el desevolupament de normativa de la indústria. 2.1 Indústria del programari 2.1.1 Breu repàs històric La indústria del programari és un concepte ambigu. És una indústria jove i a la vegada es caracteritza per un desenvolupament tecnològic ràpid. La indústria s'ha format mitjançant nombrosos temps d'expansió i canvis de paradigma tecnològic durant els menys de cinquanta anys d'història. Milers d'empreses han crescut i desaparegut. Avui, només unes quantes empreses de les que funcionaven en els anys 50 i 60 han sobreviscut i la majoria dels líders industrials contemporanis van ser fundats fa menys de trenta anys. Campbell-Kelly ofereix una taxonomia útil de la indústria del programari des d'una perspectiva històrica. Identifica tres categories principals d'empreses de programari basades en el seu model de funcionament: contractistes de programari, productors programari empresarial i productors de programari massiu. Taula 1 Una taxonomia històrica de la indústria del programari19 Amb la primera onada van venir els contractistes de programari. Van establir la indústria del programari als anys 50 venent projectes de programari a gran escala al govern dels Estats Units i a les empreses més grans. Als anys 60, la indústria es va decantar lentament cap a productes de programari i es va extendre a Europa i altres continents. Després que IBM, el monopoli "natural" de la indústria, separés el programari del maquinari el 1969, els mercats de productes de programari es van disparar. Es van fundar moltes empreses de productes de programari i la indústria es va expandir per servir un ventall més ampli d'usuaris. Els serveis de programari, formació i suport eren fonts d'ingressos importants per als productors de programari de l'època. El que els contractistes i les empreses de productes tenien en comú era que tots servien sobretot el mercat corporatiu, basat en maquinari d'ordinador central.20 La revolució de l'ordinador personal va ser el següent punt de canvi en la indústria. Una nova forma d'empresa de programari era el programari massiu basat des de l'inici en vendes de llicències de copyright i serveis mínims postvenda. Aquesta nova part de la indústria estava en certa manera desconnectada dels mercats de programari empresarial. Els mercats massius de programari es van expandir ràpidament en la "febre de l'or" de finals dels anys 70 i començaments del 80.21 El 1981, IBM va introduir el seu PC, basat en arquitectura oberta de manera que altres fabricants poguessin produir tant el programari com el maquinari.22 El PC aviat es va convertir en la tecnologia dominant i va ajudar els nouvinguts de més èxit a créixer a les alçades de les empreses de programari corporatiu. Aquest estudi se centra en els productors de programari. Des de finals dels anys 90, els límits entre els productors corporatius i massius de programari, fins a cert punt s'han començat a esborrar. Tant el creixement d'Internet com l'emergència de productes de codi obert han catalitzat un procés de construcció de pont entre els mercats corporatius i els d'usuaris finals. Per exemple, Microsoft, típic exemple d'empresa de productes de programari per al mercat massiu, i Oracle, un arquetipus d'empresa de programari corporatiu, competeixen avui amb bases de dates corporatives i aplicacions d'ordinador personal.23 2.1.2 Dimensions i regions del mercat Actualment, és difícil avaluar les dimensions i la importància dels mercats de productes de programari. En certa manera, el programari s'ha tornat invisible. El programari es troba en tota mena de productes des de cotxes a raquetes de tennis.24 La xifra de sota mostra com han crescut els mercats de programari als Estats Units -excepte per una caiguda històrica al 2002- i ara es valora en més de 300 bilions de dòlars. Figura 1. Ingressos totals de les 500 empreses de programari més importants dels EUA.25 Les valoracions més fiables, com el European Information Technology Observatory, dirigeixen al voltant del 30 % dels mercats als Estats Units i més o menys el mateix a l'Europa occidental, amb la gran majoria d'empreses de programari situades als EUA.26 Hi ha moltes raons per al domini dels Estats Units en el mercat mundial de programari. Naturalment, els Estats Units té el mercat domèstic més gran mentre, per exemple, a Europa les llengües locals i altres diferències estructurals han fet que el progrés sigui més lent. El desenvolupament de programari també està estretament lligat al maquinari i els majors fabricants de maquinari han estat empreses dels EUA. La decisió de separació d'IBM que va obrir mercats de programari el 1969 va afectar primer els mercats dels EUA i com a nació, va donar-li l'avantatge d'innovador. Les situacions crítiques de la indústria, com Silicon Valley, van sorgir de la unió d'empresaris, la recerca universitària, els mercats de capital i altres serveis de suport.27 La indústria del programari als Estats Units també ha gaudit d'un gran suport públic des dels anys 50 mentre a Europa l'interès dels líders nacionals s'especialitzava en el maquinari i l'electrònica. Cal dir també que el desenvolupament legal a Europa ha seguit el dels Estats Units tant pel que fa a la propietat intel·lectual com a la competència. Finalment, segons l'estudi de Torrisi, les empreses dels EUA s'han centrat més en el producte i la R&D que els seus homòlegs europeus.28 Aquest estudi també reflecteix el domini històric dels EUA en la indústria del programari. El fet és que les empreses més grans de programari són als Estats Units i les pràctiques de llicències s'han desenvolupat en gran part segons les tradicions empresarials i legals dels EUA. Així, si els models empresarials i de llicències de codi obert són un repte per a la indústria del programari, els efectes haurien de ser clarament visibles en els mercats dels Estats Units. 2.1.3 Emergència de codi obert És fins i tot més difícil valorar la dimensió de la "indústria de programari de codi obert". Les empreses de codi obert pur són molt petites i moltes estan en mans de particulars. Tot i amb això, la popularitat del codi obert és significativa i pràcticament totes les grans empreses d'IT disposen de serveis i productes de codi obert. El mercat del codi obert ha crescut amb l'expansió d'Internet ja que són els productes de codi obert els que pràcticament la fan funcionar. El programari de codi obert ha donat forma potser a la majoria de mercats de programari de servidor de web, cosa que s'ha convertit en un mercat nou per a productes de programari entre els ordinadors personals i els ordinadors centrals corporatius. Una combinació de programari coneguda amb l'acrònim LAMP (Linux, Apache, MySQL and PHP/Perl) ha estat la tria preferida per a molts integradors de sistema durant els últims anys. IBM i Oracle, per exemple, venen solucions de servidor basades en Linux i Apache; és clar que Oracle farà funcionar la seva pròpia base de dades al damunt i també IBM té els seus propis productes de base de dades. La figura 3 il·lustra la popularitat del servidor web Apache, cosa que també indica la popularitat del programari de codi obert en els mercats de servidors de web: Figura 2. Participació en el mercat de servidors de web.29 La gràfica de la figura 4 descriu els diferents segments del mercat de servidors de web a començament dels anys 2000. És possible construir un servidor fiable de web fent servir només components de codi obert. Figura 3. Principals components de programari per a servidors de web a començaments dels anys 2000.30 La popularitat del codi obert il·lustra com la normalització i la generalització tant en el maquinari com en components de programari han generat una activitat innovativa disruptiva. Grans passos en la innovació de maquinari han repercutit també en la innovació del programari. 31 El creixement ràpid d'equipament de xarxa ha significat una demanda creixent de programari amb plataforma segura, de fiar i barata allà on la plataforma dominant de Windows PC no ha estat adequada. Microsoft han desenvolupat ràpidament la seva tecnologia NT Windows en aquest mercat. Per altra banda, ordinadors centrals corporatius i cars amb plataformes Unix privatives no han estat dirigides al mercat de baix cost on s'ha esdevingut l'expansió més ràpida d'Internet. Tanmateix, la popularitat no implica directament participació en els ingressos. El codi obert té típicament un preu significativament més baix que els productes privatius. Segons un IDV, la participació de Microsoft en tots els enviaments de servidor que generen ingressos el 2002 va ser de 55 % mentre Linux tenia només el 23 %.32 Aquests dos eren els únics sistemes de funcionament de servidors amb una participació creixent en el mercat. IDC també va valorar que els ingressos comercials totals eren al voltant dels 18,6 bilions de dòlars.33 A més, el codi obert no ha tingut encara gaire èxit en el programari d'ordinador personal. La participació en el mercat no ha canviat gaire. Si es fan servir cerques fetes amb Google com a indicador, durant el mes de juny del 2001 i juny del 2004, un 1 % constant de totes les cerques venien d'ordinadors amb el sistema operatiu Linux. La participació en el mercat de Mac OS ha estat al voltant del 3-4 % mentre altres sistemes operatius que no siguin Windows han guanyat un altre 4 %. La resta de cerques de Google, és a dir més d'un 90 %, eren fetes des d'ordinadors amb Windows de Microsoft.34 També hi ha programari fiable de codi obert disponible en les categories més importants de programari d'aplicacions, amb inclusió del programari d'oficina (processador de text, full de càlcul, i presentació), navegador de web i correu electrònic però ha resultat difícil trobar cap participació de mercat rellevant dels productes dominants de Microsoft.35 2.1.4 Models comercials de programari i codi obert Els models comercials de programari actuals es poden distingir des de diferents perspectives. Per exemple, segons si el programari es ven com a producte o com a servei, l'estructura del canal de vendes, i les fonts d'ingressos.36 Taula 2 identifica una possible classificació utilitzada en la documentació basada en quatre models més aviat genèrics: Taula 2. Models comercials genèrics de programari.37 Potser la manera més corrent de comercialitzar que tenen les empreses de programari és venent projectes de programari. En aquest model, una empresa ven la seva feina de programació com un servei, més que com un programari. El negoci de projectes no es diferencia gaire d'un servei de taxi en el fet que com més cotxes hi hagi (programadors) més diners es poden recaptar. Per exemple, grans empreses d'IT com IBM segueixen el model comercial del projecte quan venen serveis "d'integració de sistema".38 A continuació, el model tradicional per al comerç de productes de programari es podria descriure com publicació de programari. En aquest model, el programari es llicencia com si es vengués com un producte físic. La publicació de programari funciona de manera força similar a la publicació impresa, en la qual es venen llibres fets a partir de manuscrits. Microsoft n'és un clàssic exemple venent el sistema operatiu Windows i les aplicacions Office. La Internet com a canal de distribució i entorn d'ús ha permès diverses maneres de comercialitzar el programari. La subscripció de programari es pot considerar una combinació dels dos models tradicionals. Anomenada de vegades aplicació que proporciona servei, la subscripció és una manera més interactiva de vendre programari com a producte en línia amb serveis afegits de manera personalitzada. Gairebé totes les empreses de programari que venen serveis relacionats amb el programari a Internet com els mercats en línia es poden classificar sota el model de subscripció. Finalment, han aparegut diferents models de negoci basat en programari comercial. Aquí, es disposa d'un producte bàsic o un component estandaritzat gratuït o per un preu simbòlic. La majoria de productes de programari de codi obert, com Linux i Apache es poden situar en aquesta categoria. Per definició, totes les vendes en el model comercial es basen en mitjans indirectes que produeixen un efecte multiplicador en la base d'usuaris potencialment gran i dinàmica. Per exemple, serveis afegits, productes combinats i marca són fonts d'ingressos indirectes essencials. Evidentment, es pot criticar qualsevol classificació de models empresarials de programari. Es pot dir per exemple i amb raó que només hi ha models de negoci basats en producte (amb llicència) i models de negoci basats en servei.39 Per exemple, publicacions i subscripció es poden caracteritzar com a models diferents de llicències dins de la categoria general d'empreses de productes de programari. La taula 2 es basava en aquesta simple categorització. On se situa el codi obert dins d'aquest marc? Clarament, el codi obert no s'acaba en el model empresarial de programari comercial tal com es descriu en la bibliografia inicial. 40 Tal com veurem, moltes grans empreses d'IT com IBM, HP i Novell que venen projectes (serveis) de programari fan servir de forma considerable components de programari de codi obert. El codi obert també permet en gran manera la subscripció de programari. Els llocs web més populars, siguin comercials o no, funcionen bàsicament amb codi obert. Finalment, podem distingir empreses de codi obert que venen llicències tradicionals a més de la gratuïta i per tant fan servir el model de publicació. Empreses noves com MySQL, TrollTech i Sleepycat Software han estat capdavanteres en aquest plantejament.41 El resultat és que el programari de codi obert es pot combinar amb qualsevol model empresarial de programari popular. No té sentit parlar d'empreses de programari de codi obert com si això fes referència a un model empresarial específic de programari. 2.2 Llicències privatives 2.2.1 La decisió de separació d'IBM i les llicències empresarials Abans que existissin mercats separats de programari, el maquinari i el programari es venia junt. Pugh troba l'inici d'aquesta pràctica de combinació en Herman Hollerith que va obtenir el contracte de tabular el cens dels EUA el 1890. Com que els seus primers clients no sabien com funcionaven els sistemes o no en volien la responsabilitat, era ben normal llogar l'equip i vendre els serveis addicionals L'empresa de Hollerith es va convertir més tard en IBM i la pràctica de combinació va continuar en les èpoques de Thomas J. Watson Sr. and Jr.42 Essencialment, IBM combinava programari amb maquinari i serveis. Llogaven la combinació de programari i maquinari i venien suport addicional i manteniment. En certa manera, el programari era gratuït i no hi havia un cost addicional per obtenir programari d'IBM. D'altra banda, no hi havia cap mercat per al programari ni cap altra plataforma a més d'IBM. Durant la primera part del segle, IBM tenia un monopoli natural en la indústria de la informàtica. IBM va anunciar la separació del seu programari del maquinari el 1969 després d'una sèrie d'estudis interns. Aquesta separació es basava tant en els factors competitius com en les pors antimonopolis.43 S'afirmava que IBM feia servir la seva posició de monopoli contra pràctiques comercials justes. Oferia programari gratuït i serveis segons les necessitats del client i per tant tenia avantatge per guanyar nous clients. També s'afirmava que IBM dificultava el desenvolupament de sistemes interfuncionals i rebaixava preus per evitar competència.44 Cal destacar que després de la decisió de separació els preus van baixar un simbòlic 3 %, mentre que molts clients esperaven fins un 25 % de reducció en els preus del maquinari.45 Just després de la decisió de separació, IBM va seguir diversos models de llicència per a la venda de programari. Oferien quotes d'un sol pagament i llicències de lloc. Watts S. Humphrey, en aquell moment treballador d'IBM implicat en moltes de les decisions de la separació, va explicar més endavant com van confiar en un model de llicències de compliment legal en lloc d'un de compliment tècnic (proteccions contra còpia, etc.): "Encara que creiem que la criptografia seria possible tècnicament, especialment amb l'ajut d'un maquinari especial, totes les solucions que pensàvem haurien fet molt difícil que els clients de confiança utilitzessin els nostres programes. Les grans empreses sovint necessitaven còpies de seguretat, els programes es passaven constantment de màquina a màquina i IBM animava a ampliar a sistemes més grans. Amb la criptografia, totes aquestes activitats necessitarien el permís d'IBM. Vam considerar que això no seria gens pràctic ni còmode per als usuaris, i car per a IBM. També vam arribar a la conclusió que qualsevol bloqueig i claus per a un sol equip, o bé els programes amb una durada determinada especial i autodestrucció, serien feixucs per als nostres millors clients, apart de no tenir cap eficàcia contra qualsevol lladre llest. Com que no vam poder idear cap mesura física de seguretat pràctica, vam haver de confiar en la honestedat inherent dels nostres clients. Esperàvem que la protecció legal i els processos criminals limitessin el problema de la pirateria".46 Tot i que sens dubte és un fet important, no cal destacar de manera exagerada la decisió de la separació d'IBM. La majoria dels professionals del sector estan d'acord que era un pas necessari de cara al naixement del sector dels productes de programari als anys 70.47 Tot i així, només és una part de la història. Segons Campbell-Kelly, els factors principals que van portar a l'aparició del sector dels productes de programari a finals dels anys 60 van ser la proliferació en augment de les aplicacions de la informàtica, un augment de les despeses de desenvolupament del programari, la manca de programadors i l'aparició de la plataforma estàndard d'IBM.48 Davant d'aquests fets, la separació del programari es pot considerar una decisió racional de l'empresa davant l'evolució evident cap als mercats de programari. Després del canvi de política d'IBM, el programari es va vendre com a producte amb llicència a partir de finals dels anys 60. Els primers acords de llicència ja regulaven detalladament l'ús del programari.49 La base legal de les llicències era essencialment secret comercial i llei contractual, tot i que també s'hi mencionaven drets de propietat intel·lectual (però sobre els quals no se'n reclamava necessàriament la propietat). Per exemple, les primeres llicències d'Unix de principis dels anys 70 esmentaven drets de reproducció, secrets comercials i patents. Les llicències es basaven en la suposició que Unix i el codi font d'Unix estaven sota secret comercial i es llicenciaven sota confidencialitat. A més, les condicions en restringien les còpies com qualsevol llicència de copyright (això sí, sense esmentar explícitament que el programari podia estar protegit per drets de copyright). Les condicions també declaraven que no existeixen explícitament llicències de patents o marques comercials que protegeixin el programari i que no existeix cap mena de garantia davant de copyright o patents de tercers, o violació del secret comercial.50 2.2.2 Llicència de mercats massius i programari de prova Els mercats massius d'ordinadors personals van aplicar el model comercial de publicació del sector discogràfic. Es venien paquets de programari en forma de còpies del programa original. Els llibres populars destinats als desenvolupadors de programari explicaven que els drets de reproducció eren la principal eina legal per protegir el programari dels efectes negatius produïts per les còpies no desitjades. De fet, la protecció de la propietat intel·lectual va anar cobrant importància i els models de llicències cada cop van ser més restrictius, prohibint per exemple les còpies de seguretat i l'enginyeria inversa. Però això tampoc era tot. Els mercats massius també van veure el creixement del model de llicència de programari de prova o bé el model de "prova'l abans de pagar-lo" a principis dels anys 80. El primer programari de prova amb èxit van ser aplicacions de PC, però més endavant també es van distribuir amb èxit eines de sistema i jocs en forma de programari de prova.51 A principis dels anys 80, era ben possible que qualsevol persona competent desenvolupés programes simples i competitius que realitzessin tasques bàsiques, com per exemple, el processament de textos. L'únic problema era que els mercats de publicació de programari encara s'estaven formant i que els editors es quedaven una part dels ingressos. El programari de prova va ser probablement el primer model de llicències on els usuaris finals distribuïen el programari. Essencialment, el programari tenia copyright, però se'n permetia la còpia i distribució. Això no obstant, per utilitzar el programari durant més d'un període determinat de temps o per aconseguir característiques addicionals, normalment l'autor feia pagar als usuaris una quota de llicència per a una versió registrada o amb totes les característiques. A més, no es facilitava el codi font del programa i no se'n permetien les modificacions. El programari de prova es distribuïa primer a través de BBS i la còpia directa entre usuaris. Més endavant van aparèixer venedors per correu postal que publicaven llistes de programari de prova disponible i que cobraven petites quantitats per la producció de discos. Aquest extrem final dels mercats sencers de programaris presentava molta activitat. Nelson Ford, el fundador de la Public Software Library (PsL), un dels primers distribuïdors de programari de prova, va explicar: "Mentre PsL i els distribuïdors de gran volum dominaven el mercat de distribució del programari de prova, a finals de la dècada dels 80 van aparèixer centenars (o potser milers) de petits venedors de programari de prova. Sense que es necessitessin coneixements informàtics ni qualsevol altre coneixement, qualsevol que tingués un grapat de dòlars podia comprar discos de programari de prova d'un altre venedor, imprimir un "catàleg" i vendre còpies d'aquests discos a altres persones. Gran part d'aquests "venedors de programari de prova" venien a fires d'informàtica i als encants".52 La popularitat del programari de prova es va anar esfumant lentament dels mercats de PC a principis dels 90. Només algunes empreses van obtenir beneficis importants abans que es comercialitzessin gairebé tots els seus productes de programari.53 Quan per exemple Microsoft comprava o desenvolupava alguna eina essencial del programari de prova a dins del seu sistema operatiu, el mercat d'aquell programari de prova acabava extingint-se. Tot i que constantment s'anava introduint programari de prova nou, l'èxit d'aquests era molt limitat.54 2.2.3 Llicències privatives avui Restriccions i preus de llicències. Tradicionalment, les empreses de programari privatiu han desenvolupat programari intern i han utilitzat diferents tipus d'acords de llicència d'usuari final que atorguen als concessionaris drets limitats per utilitzar el programari amb uns objectius específics. La idea bàsica és ajustar el preu de la llicència amb les restriccions d'ús. La taula 3 enumera les restriccions que s'utilitzen sovint, i que poden basar-se, per exemple, en el programari, l'entorn de maquinari, els usuaris del programari o les característiques d'ús: Taula 3. Restriccions típiques de llicències privatives. Figura 4. Il·lustració dels models de llicència des de la perspectiva de la generació d'ingressos al llarg del temps.55 En la documentació econòmica, s'han debatut els models de llicències de programari sota temes com la discriminació de preus i les versions. Els productes poden diferenciar-se i valorar-se, per exemple, mitjançant retards en l'aparició de versions, discriminació de qualitat, ampliacions, lloguer i la creació de paquets.56 En teoria, la discriminació de preus maximitza el valor de l'ús del programari ja que cada usuari paga segons la valoració individual. Els drets de propietat intel·lectual (que atorguen als productors de programari els drets exclusius de còpia, distribució i modificació) proporcionen el recolzament legal d'aquests models de llicència. Llicències contra serveis. Les tarifes de llicència cànons) només són una part dels ingressos totals de les empreses de programari. Normalment, fins i tot les empreses amb productes amb llicència i instal·lables per part del client disposen de servei postvenda i manteniment. Per tant, val la pena destacar que encara que s'han multiplicat diferents models de llicència, els preus mitjans de les llicències, a la llarga, han anat baixant.57 Simultàniament, els ingressos totals de les empreses de programari han augmentat per la llicència de productes i altres fonts. Per tant, l'ús global de programari ha d'haver crescut a gran velocitat. La taula següent il·lustra més detalladament com les empreses de programari més importants del món comparteixen els ingressos entre llicències / productes i serveis / manteniment. Taula 4. Llicències de programari i ingressos per serveis d'algunes de les empreses de productes de programari més importants del món.58 Cal tenir en compte que aquest tipus de càlculs entre les quotes d'ingressos per llicències i serveis només són indicatius, ja que els mètodes de comptabilitat no són totalment equiparables. Tot i això, les xifres demostren clarament que algunes empreses de programari depenen completament de les vendes de llicències i que moltes empreses obtenen una part substancial dels seus ingressos a través de quotes de llicència i cànons. Com demostrarem més endavant, la popularitat en augment del codi obert perjudica potencialment els models d'empresa basats en quotes de llicència i cànons. Malgrat tot, les llicències tenen altres funcions apart de generar ingressos. Especialment en les llicències de codi obert, la funció de la llicència no és generar cànons directes, sinó afegir altres restriccions amb l'objectiu, per exemple, de la cooperació en el desenvolupament, atribució de l'autoria o fins i tot alguna forma d'ideologia. Per tant, les llicències de programari es poden percebre, en un context més ampli, com una part de la funcionalitat del programari i no només com el preu.59 Codi font. Normalment, el codi font no es comparteix en les llicències privatives i el producte informàtic només es distribueix en codi objecte (o codi objecte intermedi, com en Java) amb restriccions addicionals sobre enginyeria inversa. Se suposa que el codi font conté informació valuosa amb secrets comercials, que cal protegir de la vista de la competència. Els drets de reproducció i les patents no garanteixen cap protecció per exemple per les estructures, idees i lògica descrites en el codi font. Malgrat tot, a vegades és necessari el codi font, especialment si el producte de programari es una eina de desenvolupament o un component que cal integrar amb altres components (programari incrustat). Els titulars de llicències esperen més capacitat d'adaptació i, per tant, cal facilitar el codi font o, com a mínim, descripcions detallades de la interfície.60 La figura 5, a continuació, explica les opcions de distribució del programari des del punt de vista del codi font. Figura 5. Tres vies principals per distribuir productes de programari des del punt de vista del codi font.61 Per acabar, cal destacar que a vegades es ven el programari privatiu amb el seu codi font. Això no obstant, la inclusió del codi font del programari privatiu per a l'usuari sovint suposa unes despeses superiors de compliment de la llicència; amb el codi font a les seves mans, l'usuari té moltes més probabilitats d'utilitzar el programari de maneres no autoritzades pel que concedeix la llicència. 2.3 Programari lliure i llicències de codi obert A continuació repassarem breument la història del programari lliure i les llicències de codi obert. Van codificar-se les idees dels termes de distribució lliure amb codi font disponible i a continuació van guanyar popularitat amb dos projectes de sistemes operatius principals: BSD i GNU/Linux a partir de la dècada de 1980.62 Més endavant, l'Open Source Initiative va encunyar el terme general "codi obert" per descriure diferents tipus de llicències lliures a finals de la dècada de 1990. 2.3.1 Llicència de la BSD i copyrights d'Unix Rerefons universitari. En els cercles acadèmics, el programari s'ha desenvolupat durant molt temps seguint els principis del codi obert i la distribució lliure. Diverses universitats van triar l'ús del sistema operatiu Unix d'AT&T. Des d'un bon principi va tenir llicenciar per a institucions educatives amb tot el codi font sota un acord de secret comercial.63 A continuació s'animava als usuaris a desenvolupar encara més el sistema (de fet, això es va convertir en una necessitat pràctica, ja que realment AT&T no oferia el suport del sistema). Una implicació evident de la política d'AT&T va ser que Unix es va convertir en la base de la primera xarxa de desenvolupament col·laboratiu obert a gran escala.64 Una variant principal d'Unix d'AT&T va sorgir de la Universitat de Califòrnia, a Berkeley. Bill Joy, el hacker més destacat de Berkeley, que llavors era un estudiant d'informàtica, va començar a treballar en el que finalment es va convertir en la Berkeley Software Distribution (BSD) el 1975. En poc temps, la BSD es va convertir en la plataforma acadèmica de desenvolupament d'Unix. Els usuaris enviaven els trucs, pedaços i correccions a Berkeley i si aquests s'acceptaven, el codi facilitat s'afegia al codi base de la BSD.65 Gran part del desenvolupament d'Unix es va produir a la BSD, la qual rebia generosos ajuts de la Defense Advanced Research Projects Agency (DARPA) dels Estats Units.66 Bob Fabry, cap del grup d'investigació informàtica de Berkeley fins al 1983, va descriure la seva motivació en una entrevista:67 "Crec que l'esperit en què col·laboràvem s'assemblava bastant al que van agafar més endavant la Free Software Foundation i tota la gent que intentava desenvolupar programari per a tothom... La idea és que la duplicació de programari no costa res, així que bàsicament hauria de ser gratuïta, i treballàvem tots junts per intentar assolir aquest sistema ideal que ens agradaria a tots tenir i que ens agradaria que tots poguéssim utilitzar ". Per evitar problemes per possibles violacions dels drets de reproducció, es van pagar quotes de llicència a AT&T per a qualsevol distribució de variants d'Unix. Per exemple, totes les distribucions de la BSD incloïen des de principis dels anys 80 una referència a la llicència d'AT&T. Això no obstant, els pagaments de llicències, cada cop més cars, es van convertir ràpidament en una càrrega per a molts.68 A més, les empreses que només utilitzaven parts del codi i dissenyaven productes autònoms per a la gestió de xarxes per als mercats en expansió dels ordinadors personals van demanar una versió diferent que respongués a les seves necessitats. Al final, una creació independent de Berkeley anomenada Networking Release 1 va sortir a la llum el juny de 1989. Es va distribuir sota la primera llicència moderna de la BSD. Més endavant, l'informàtic de Berkeley Marshall Kirk McKusick va explicar:69 "La BSD va originar codi de gestió de xarxes i el juny de 1989 es van llançar utilitats de suport amb el nom de Networking Release 1, el primer codi de redistribució lliure de Berkeley. Els termes de la llicència eren generosos. Un titular de llicència podia publicar el codi modificat o no modificat en forma de font o binària sense haver de respondre o pagar cap cànon a Berkeley. Els únics requisits eren que calia deixar intactes els avisos sobre drets de reproducció de l'arxiu font i que els productes que incorporaven el codi havien d'indicar a la documentació que el producte contenia codi de la Universitat de Califòrnia i els seus col·laboradors. Encara que Berkeley cobrava una quota de 1.000 dòlars per obtenir-ne una cinta, qualsevol podia fer-ne una còpia de qualsevol que ja la tingués". Cas judicial d'AT&T. L'èxit de la Networking Release 1 va fer plantejar la possibilitat de poder publicar de la mateixa manera tot el sistema operatiu. Un altre informàtic de Berkeley, Keith Bostic, va iniciar el projecte. Va poder atreure voluntaris perquè l'ajudessin a rescriure els centenars d'arxius amb drets de reproducció d'AT&T. Els programadors de diversos països van recrear els arxius necessaris utilitzant les especificacions disponibles públicament.70 Després de treballar més amb el nucli, es va publicar una versió gairebé completa de BSD amb el nom de "Network release 2", creient que no contenia res del codi d'AT&T, i sota llicència de BSD. Això calia demostrar-ho als mercats. Berkeley Software Design Inc. (BSDI) va publicar aquest codi com a producte comercial denominat BSD/386 adaptat per a l'arquitectura del processador Intel 386, cada cop més popular, de principis de 1992. No va passar gaire temps fins que Unix System Laboratories (USL), una filial sota control d'AT&T, va denunciar-los per violació de copyright i secret comercial. Més endavant, USL va afegir la Universitat de Califòrnia al plet com a demandat. La Universitat de Califòrnia es va afanyar a interposar una demanda contra USL perquè AT&T també havia utilitzat el codi de Berkeley en la seva distribució d'Unix i les parts van començar una batalla legal.71 De seguida va quedar clar que les dues parts havien comès errors: AT&T havia distribuït arxius de la BSD sense els avisos de copyright adequats i la BSD encara tenia alguns arxius amb fragments de codi font d'AT&T. La disputa de BSD va acabar quan Novell va comprar USL el 1993. El gener de 1994, es va finalitzar l'arranjament. El resultat va ser l'eliminació de tres arxius de la BSD i el reconeixement que 70 més pertanyien a USL. Poc després de l'arranjament del cas, va dividir-se el desenvolupament de la BSD en diferents branques: FreeBSD, NetBSD i OpenBSD. Totes es podien executar amb l'arquitectura barata dels PC. Ara era possible desenvolupar lliurement i redistribuir les branques d'Unix de la BSD sota la llicència de BSD. Tot i això, ja s'havia perdut el concurs de popularitat del sistema operatiu preferit dels servidors d'Internet. L'afer legal, un model de desenvolupament obert però d'estreta coordinació, i ara la divisió en diferents vies de desenvolupament van garantir a Linux una sortida potent com a nou i preferit sistema operatiu basat en Unix per als servidors d'Internet. 2.3.2 Llicència pública general de GNU, Linux i SCO Stallman inventa la GPL. Richard Stallman, un antic treballador del laboratori d'intel·ligència artificial del MIT, va iniciar el seu projecte de GNU publicant el manifest de GNU el 1983 i fundant a continuació la Free Software Foundation. Encara que el manifest de GNU tenia un to polític i ideològic, en principi el projecte se centrava en la tecnologia. L'objectiu era escriure un sistema operatiu complet i compatible amb Unix. Malgrat tot, no va passar gaire temps fins a l'aparició de les llicències. Quan Stallman va iniciar el projecte de GNU, treballava sobre l'editor de textos Emacs. Stallman havia escrit el primer Emacs durant la dècada del 1970, però com que ho escrivia en un altre llenguatge de programació, el codi font no era útil. Més endavant, James Goslig havia escrit una versió d'Emacs per a Unix l'any 1982 i la va distribuir com a codi font. Stallman va agafar el codi font de Gosling i va començar a modificar-lo fins a convertir-se en GNU Emacs. Mentrestant, Goslig va vendre Emacs a una empresa, que va dir que Stallman no podia distribuir GNU Emacs perquè no disposava de l'autorització del nou propietari del copyright. De fet, Stallman es va veure obligat a rescriure tot el codi escrit per Gosling.72 Stallman va recordar els fets en una conferència l'any 1986: 73 "És ben estrany, van canviar d'opinió i no van voler signar l'acord i van posar un missatge a la xarxa que deia que jo no podia distribuir el programa. Realment no van dir que farien res, només van dir que no tenien clar si algun dia farien alguna cosa. Amb això n'hi va haver prou per espantar a la gent, així que ningú va tornar a utilitzar-lo, quin fet més trist...". Aquesta va ser una de les moltes vegades en què es va excloure Stallman del desenvolupament d'un projecte interessant.74 Per acabar amb tots aquests "fets tristos", Stallman va escriure la llicència pública general d'Emacs l'any 1988. El text de la llicència dels drets de reproducció contenia per primer cop la idea del copyleft, on declarava que GNU Emacs no era de domini públic, sinó que tenia copyright.75 Es podia copiar i distribuir, però no es permetia canviar els termes de la llicència en cap obra derivada. Val la pena destacar que abans d'Emacs GPL, Free Software Foundation no utilitzava cap llicència per al programari i Stallman semblava oposar-se a protegir el programari amb copyright.76 Amb una llicència innovadora, Stallman va poder enfrontar-se als efectes exclusius dels drets de reproducció amb l'ajuda d'aquests mateixos drets de reproducció. L'any 1989 es va tornar a redactar parcialment el text de la llicència d'Emacs GPL per aclarir-lo; a més, va rebre el nom de Llicència Pública General de GNU. Es va convertir en la llicència predeterminada de tots els programes GNU. L'any 1991 es va publicar la segona versió de la GPL GNU; actualment se'n prepara la tercera versió. Cas judicial de Linux i SCO. L'èxit de la GPL no va ser el programari GNU de Stallman. Aquest va ser el nou nucli del sistema operatiu compatible amb Unix de Linus Torvalds, que va començar a desenvolupar l'any 1991. El gener de 1992, Torvalds va decidir atorgar la llicència GPL a Linux.77 L'èxit posterior de Linux acompanyat per GNU i més programari lliure va significar que la llicència de GPL cada cop fos més coneguda i popular també fora dels cercles de hackers. Igual que la BSD, Linux també s'ha hagut d'enfrontar a pugnes legals pels seus orígens amb grans venedors d'Unix. La següent demanda va venir de SCO, que va comprar la part d'Unix a Novell l'any 1995. Més endavant, Caldera va comprar SCO; Caldera va tornar al nom de SCO l'any 2002. SCO / Caldera es va concentrar, durant uns anys, en el codi obert, ja que tenien una distribució pròpia de Linux; això no obstant, mai no van aconseguir treure'n un rendiment continuat. L'any 2002 l'empresa va semblar que decidia fer el que comercialment era més sensat: utilitzar els drets sobre l'Unix original d'AT&T per emprendre accions legals. SCO va començar a emetre comunicats sobre possibles accions judicials contra qui donés suport a Linux i finalment va demandar IBM el març de 2003 per mil milions de dòlars; més endavant, la demanda va pujar fins a tres mil milions. SCO primer va declarar que era la propietària dels drets de totes les característiques afegides a qualsevol sistema, com per exemple Linux, relacionat amb l'Unix System V d'AT&T. Van declarar que IBM, amb l'accés al codi font d'SCO, havia facilitat aquestes característiques a Linux.78 Finalment va quedar clar que les demandes d'SCO no tenien cap base fonamentada. No es va aconseguir trobar codi font de Linux copiat d'Unix System V. Novell va disputar la claredat de la propietat d'SCO sobre els drets de reproducció i les patents d'Unix. A més, SCO, com a Caldera, havia distribuït les primeres fonts d'Unix l'any 2002 sota llicència de GPL sense restringir el desenvolupament d'obres derivades en cap sentit. Per tant, SCO va haver de fer-se enrere de les demandes de la propietat intel·lectual i concentrar-se en possibles violacions del contracte. A finals del 2004, el cas continua obert. 2.3.3 El codi obert entra al vocabulari Open Source Initiative. Després d'arranjar el cas BSD i la popularitat de Linux, semblava que el codi obert havia passat les proves de foc necessàries per tenir credibilitat en el sector. L'interès de les empreses en el programari de codi obert creixia ràpid i paral·lel a l'expansió d'Internet. Malgrat tot, els gerents i gairebé tot el personal tècnic del sector del programari desconeixien els models de llicència de la BSD i de la GPL. Les empreses també tenien problemes per entendre la ideologia del programari lliure de Stallman. Eric S. Raymond va ser l'individu clau que va donar l'embranzida final al que més endavant es va denominar el moviment del codi obert. El seu influent article "The Cathedral and the Bazaar" (La catedral i el basar), publicat per primera vegada el 1997 i les xerrades posteriors van cridar l'atenció de Netscape.79 En aquell moment, l'empresa del navegador de web estava perdent quota de mercat respecte Microsoft i estava disposada a experimentar amb alternatives radicals. Amb una separació clara dels ideals de Stallman, Raymond va aconseguir convèncer Netscape perquè adoptés una estratègia de codi obert; l'empresa va ser la primera empresa de programari coneguda en fer-ho el gener de 1998. Just després que Netscape anunciés el canvi cap al codi obert, l'editor de llibres d'informàtica Tim O'Reilly va organitzar una reunió amb els desenvolupadors de codi obert més coneguts per debatre una estratègia pública compartida.80 Així es va fundar Open Source Intiative (OSI) el febrer de 1998 per tractar l'interès cada cop més gran en Linux i la resta de programari desenvolupat sota els principis unificadors del codi obert. Va començar a certificar aquelles llicències que complien els termes generals de l'Open Source Definition segons l'esborrany de Bruce Perens.81 El sector del programari va anar incorporant gradualment el codi obert al gran mercat. El juny de 1998 IBM va anunciar que donaria suport a Apache i el juliol Oracle va anunciar que passaria la seva base de dades principal a Linux. L'agost del mateix any, Microsoft va declarar oficialment que els preocupava Linux i Apache especialment. La premsa comercial i les revistes famoses van començar a incloure històries sobre l'èxit del codi obert.82 Reacció del sector. Avui en dia, després de més de sis anys, podem dir que el codi obert ha esdevingut una pràctica acceptada generalment per desenvolupar i distribuir gairebé qualsevol tipus de programari que sigui comercialment viable. Els següents extractes de diferents llocs web d'empreses reflecteixen el nivell d'entusiasme de 2004: IBM: "Linux és perfecte per als que vigilen el pressupost i necessiten un sistema operatiu fiable i escalable". (ibm.com/linux) Oracle: "Amb les col·laboracions tècniques per millorar Linux, amb suport des del codi dels sistemes operatius clau Linux i amb associacions estratègiques, Oracle ofereix una plataforma Linux sense fissures on els clients poden confiar en la seguretat de Linux en un entorn crucial de missions". (otn.oracle.com/tech/linux) HP: "HP participa en una sèrie de projectes de programari de codi obert per executar en diversos sistemes HP". (opensource.hp.com) Apple: "Els projectes de codi obert d'Apple permeten als desenvolupadors adaptar i millorar el programari clau d'Apple. A través del model de codi obert, els enginyers d'Apple i la comunitat del codi obert col·laboren per crear productes millors, més ràpids i més fiables per als nostres usuaris". (developer.apple.com/darwin) Microsoft: "Sovint, el sector del programari es divideix... en faccions rivals entre proveïdors comercials i de codi obert. Els moviments del mercat, però, demostren que aquesta visió ha quedat obsoleta. Ambdós models han demostrat ser beneficiosos per al mercat del programari".83 Molts estudis del sector han explorat els possibles beneficis i riscos pràctics de la migració de les empreses cap als productes de codi obert. Per exemple, Forrester Research va entrevistar l'any 2004 els gerents de tecnologies de la informació de cinquanta empreses nord-americanes amb valor superiors a mil milions de dòlars perquè els esmentessin beneficis i reptes del programari de codi obert: Figura 6. Els beneficis del codi obert segons les entrevistes a gerents de tecnologies de la informació l'any 2004 Figura 7. Els reptes del codi obert segons les entrevistes a gerents de tecnologies de la informació l'any 200484 És clar que el baix preu de les llicències i no quedar lligat a un únic proveïdor són factors claus a favor del codi obert. També cal destacar que sovint es menciona la qualitat dels programes; tot i que és probable que la qualitat mitja de qualsevol programa de codi obert publicat no sigui molt elevada, hi ha alguns exemples estrella que garanteixen una bona imatge pública al codi obert. El codi obert es coneix més i més ja que actualment la majoria d'estudiants d'informàtica i enginyeria ho estudien tot en codi obert. També val la pena destacar que la possibilitat pràctica de modificar el codi font no es troba entre els principals criteris d'ús del codi obert. Malgrat tot, encara queden molts reptes per resoldre. El mencionat amb més freqüència és la falta de suport comercial. Mentre que les empreses de les tecnologies de la informació comercialitzen el codi obert com una part de la seva solució de maquinari (com IBM, HP o Apple), o com a plataforma per al seu programari privatiu (com Oracle i IBM), és probable que no sempre ofereixin suport directe de determinats productes de codi obert. Les llicències passen al segon pla. Les llicències poden ser clarament problemàtiques, especialment per qui desenvolupa o comercialitza un programari propi basat en codi font obert. També hi ha diversos reptes generals que, suposadament, estan relacionats amb el fet que els productes de codi obert encara són una cosa massa recent per a moltes empreses. Aquests reptes inclouen dubtes de seguretat, la viabilitat i credibilitat global dels productes de codi obert i la falta de formació empresarial. 2.4 Dimensions socials i polítiques del codi obert85 Abans d'avançar la teoria, fem un petit viatge per les comunitats de desenvolupadors i el debat sobre les polítiques públiques. Intentarem traçar-ne els valors ètics, que són la base de les normes comunitàries i queden reflectides a les llicències. 2.4.1 El codi obert i l’apoderament individual L'any 1976, quan encara s'havien de formar els mercats de programari massius, el fundador de Microsoft, Bill Gates, va enviar la seva carta, ara famosa, als aficionats: "An Open Letter to Hobbyists". En aquesta carta, Gates advertia als primers hackers ("aficionats") que no podien distribuir-se lliurement programari comercial entre ells. Gates no creia que els hackers tinguessin mai la motivació d'escriure programari que pogués competir amb els productes de les empreses de programari: "Qui es pot permetre realitzar una feina professional a canvi de res? Quin aficionat pot dedicar tres anys de la seva vida a programar, trobar tots els errors, documentar el producte i distribuir-los de manera gratuïta? La realitat és que ningú llevat de nosaltres ha invertit una gran quantitat de diners en programari d'aficionats".86 La carta anava dirigida als membres del Homebrew Computing Club, una reunió informal d'alguns dels primers hackers de Silicon Valley a meitat de la dècada de 1970.87 El primer producte de Microsoft, ALTAIR Basic, es va distribuir dins del Club sense l'autorització de Microsoft.88 En certa manera, el món de Gates ha quedat completament capgirat comparat amb trenta anys enrere. Les eines i metodologies de desenvolupament de programari han arribat a un grau d'estandardització que finalment han permès que el desenvolupament distribuït i organitzat lliurement sigui eficient. Els informàtics aficionats s'han organitzat a Internet i han establert els fonaments d'un codi ètic competent.89 Avui es pot parlar d'una comunitat de codi obert i programari lliure establerta en garatges i soterranis tots junts. Les grans empreses, amb l'excepció remarcable de Microsoft, recolzen la feina de la comunitat i n'adopten els fruits per als models empresarials principals. Què ha passat mentrestant? Es pot analitzar des del punt de vista de la ciència. Sempre hi ha hagut universitats en les quals ha dominat la cultura de la llibertat per compartir i el desenvolupament obert. Richard Stallman va anunciar el projecte de GNU al MIT l'any 1983 i els sistemes UNIX acadèmics oberts van venir dels hackers de la UC Berkeley. A més, Linus Torvalds va començar Linux mentre estudiava informàtica a la Universitat d’Hèlsinki: "Llavors, l'any 91 o 90, la majoria de gent d'Internet estava a les universitats, el que volia dir que tota la filosofia d'Internet estava plantejada des del punt de vista universitari. La millor raó per fer que Linux estigués disponible en aquell moment va ser probablement perquè encaixava amb la cultura".90 És a dir, el programari lliure no està connectat de manera formal o accidental a la ciència, sinó que en forma part.91 Les universitats eren el lloc natural on podien alimentar-se els mètodes del codi obert. D'alguna manera, l'estructura del desenvolupament del codi obert uneix la lògica del descobriment científic amb suposicions i refutacions constants. Encara més, inclou elements de disciplines d'humanitats i de càlcul. Aquest element humà, o artístic, destaca el paper del coneixement, compromís i passió personals de cada participant individual. Per tant, la caracterització del desenvolupament del programari lliure com a procés idealment obert, col·laboratiu i acumulatiu encarat cap a la superioritat tècnica és clarament insuficient. Els individus no compten. Això ho sap tothom, tant en cercles acadèmics com empresarials. El desenvolupament del programari amb prou feines s'organitza com un procés democràtic entre iguals, ja que cada individu té unes capacitats completament diferents per desenvolupar programari.92 L'únic que han fet Internet i el codi obert ha estat fer que aquests pocs individus encara siguin més forts i visibles que mai. Si creiem en el poder de les persones instruïdes, arribarem a la conclusió que els pensadors radicals d'avui estableixen els ideals pràctics quotidians del demà. Individus des de Richard M. Stallman a Eric S. Raymond i Linus Torvalds han tingut un paper crucial en el llançament del canvi institucional que finalment ha deixat de dependre d'individus particulars. Possiblement el punt crucial va ser quan els individus clau de les comunitats del codi obert i programari lliure van entendre el context social i cultural més ampli que estaven canviant. Amb arguments econòmics o tècnics d'experts, mai no haurien canviat els codis ètics acceptats i altres pilars socials fonamentals de la societat de la informació. Douglass C. North afirma que apareixeran noves organitzacions institucionals quan calgui un canvi institucional.93 Creiem que són arguments vàlids que els codis legals i ètics internacionals sobre propietat de l'economia del coneixement hagin arribat fins aquest punt. Hi havia la necessitat social d'un canvi institucional que ara estan aconseguint les llicències de codi obert i la ideologia del programari lliure.94 2.4.2 La Comunitat i els seus fronts Els conceptes de codi obert i llibertat són ambivalents i on es defineixen millor és en el discurs.95 Per tant, cal que comencem identificant els principals actors, o líders d'opinió, del debat. En el món del codi obert no hi ha diferències fonamentals entre les institucions (com ara empreses i estats) i els individus. En principi, tothom pot participar en un projecte de codi obert, fins i tot de manera anònima. Per això no és sorprenent que el nombre i diversitat de participants als debats sigui enorme. Segons Fink, "hi ha massa empreses, massa grups i massa individus perquè [el codi obert] desaparegui d'aquí poc temps".96 Malgrat tot, enmig del soroll, hi ha algunes veus que parlen molt més alt que les altres. Eric S. Raymond pot considerar-se una mena d'antropòleg de la comunitat del codi obert. Abans de redactar "The Cathedral and the Bazaar" i començar a recomanar el terme codi obert, Raymond ja era conegut a la comunitat hacker pel manteniment del "Jargon File", un diccionari de l'argot dels hackers. Des que va cofundar l'Open Source Initiative l'any 1998, Raymond ha estat un comentarista i defensor actiu de la imatge més propera a l'empresa del moviment del codi obert. Al cor de la comunitat continua havent-hi la figura de Richard M. Stallman. De tots els individus de la comunitat, potser és qui actualment està més a prop d'una institució. El poder també significa lluita. Un observador que comenci a llegir els escrits i els comentaris de Stallman a Internet aviat veurà que la comunitat és més aviat un sistema social heterogeni. Hi ha la típica competència pel liderat, la barreja d'opinions, aliances, etcètera. Però gairebé l'origen de tot el que és visible pot atribuir-se a Stallman: Linux, les llicències de GNU i el concepte de programari lliure. Durant els últims anys, Stallman ha ampliat el concepte de programari lliure fins a societat lliure.97 Això s'ha fet principalment a través de la Free Software Foundation. En els problemes de la política pública, també hi ha uns altres actors importants amb deute i vincles ideològics amb el programari lliure i el codi obert. Entre aquests s'hi inclouen diversos moviments populars i grups d'interès, amb l'Electronic Frontier Foundation al capdavant.98 De fet, es pot dir que els impactes culturals i polítics més importants derivats de les comunitats de codi obert i programari lliure no tenen res a veure amb el moviment oficial del codi obert. L'Open Source Initiative no és políticament activa, sinó un grup informal d'interès amb objectius pràctics i limitats. Malgrat això, tot i que s'ha utilitzat i desenvolupat programari lliure durant anys, l’OSI va ser l'esforç vital que va accelerar-ne l'entrada a la societat en general. Sense l'OSI, és probable que les implicacions polítiques i culturals encara s'haguessin endarrerit més. 2.4.3 Objectius ètics o tècnics? "No recomano el codi obert" (Richard Stallman) Passem al debat real i comparem els dos camps ideològics (les comunitats de programari lliure i codi obert) entre elles. Què intenten dir-nos? Stallman està interessat en el programari i els problemes tècnics i, a més, en política, cultura i ètica. De fet, sembla que per a ell compten més els aspectes culturals i polítics del programari lliure. En general, Stallman destaca les llicències de programari de GNU i el seu concepte de llibertat per davant de qualsevol qüestió tècnica. A priori, subratlla clarament la norma ètica per sobre qualsevol qüestió tècnica: "Hi ha programari lliure desenvolupat de manera col·laborativa i n'hi ha que no, però això és secundari... [El codi obert] anima a les persones a pensar en termes pràctics, i no activa la part del cervell on es pensa en la llibertat i el bé i el mal i el tractar bé o malament la gent... Dirigeixen la lluita cap allà on creuen que poden guanyar pel que fa a qui proporcionarà el millor programari i suport durant els següents anys...".99 És probable que el camp del codi obert no respongui. Linus Torvalds ofereix una resposta curta: "Per mi, no és una religió. Crec que segurament el codi obert és gairebé la millor manera d'obtenir la millor tecnologia".100 Stallman no en fa cas. En els seus discursos, Stallman és com si escrivís a una comunitat de votants que només poden triar la seva ideologia o la de la competència (el codi obert). Stallman compara les opcions per al seu públic: "Comparem les dues filosofies. El codi obert dóna prioritat als desigs del desenvolupador; nosaltres donem prioritat a allò que fa possible una comunitat de persones lliures. El moviment del codi obert considera el programari no lliure una solució poc òptima; en el moviment del programari lliure, el programari no lliure és un problema, un problema social, la solució del qual és substituir-lo amb programari lliure. Per això les empreses s'estimen més "codi obert": perquè no els provoca problemes que no volen".101 Stallman indica clarament que el programari privatiu provoca un "problema social" i que la comunitat del programari lliure té la missió de solucionar-lo. En aquest sentit, la comunitat de codi obert té un plantejament més flexible. Intentant no polaritzar massa l'assumpte, Eric Raymond s'oposa clarament a Stallman amb la següent afirmació: "Considero que intentar convèncer explícitament amb tanta paraula sobre aquests temes sol ser contraproduent. Jo m'estimo més enfocar-ho amb més tranquil·litat: a vegades té sentit econòmic abandonar el control de la propietat i deixar totes les discussions i deixar que cadascú arribi a la seva pròpia conclusió."102 2.4.4 Influència en les institucions polítiques "El problema solia ser senzillament la falta de programari lliure, així que vam escriure programari lliure. Però ara ens trobem amb intents d'aprovar lleis que prohibeixin la nostra feina". (Richard Stallman) S'ha realitzat el pas dels matisos tècnics cap al discurs polític complet. El codi obert cada cop està més polititzat, en gran mesura gràcies a l'aliança dels grups d'activistes per als ciberdrets amb els acadèmics i l'expansió de la ideologia de Richard M. Stallman a través del programari amb llicència de GNU. No és difícil trobar una organització sense ànim de lucre, polític o periodista conegut que doni suport a uns drets justos en la informació. Si s'accepta la caracterització de Peter Drucker de les organitzacions sense ànim de lucre com a "agents de canvi humà" que configuren una comunitat i defineixen un objectiu comú, Stallman i la seva Free Software Foundation estan guanyant terreny clarament.103 La pregunta ara és fins on poden arribar. Al final, Stallman creu que el programari lliure pot ajudar a resoldre problemes socials fonamentals: "El programari lliure també pot ajudar a solucionar altres problemes socials. Un d'aquests problemes és la divisió digital, el fet que una gran part de la humanitat no es pot permetre l'accés a la tecnologia informàtica".104 També és interessant destacar que Eric S. Raymond al capdavant del moviment del codi font obert pot ser descrit com una mena de fonamentalista polític. Un tractament pràctic sense compromisos dels problemes inherentment polítics porta al que alguns denominen fonamentalisme del mercat lliure i d'altres llibertarisme.105 Per tant, no es poden establir les arrels de les opinions polítiques al discurs dels líders d'opinió de la comunitat a dins d'un partit polític o creença en particular. Hi ha elements llibertaris de protecció de la llibertat individual mentre simultàniament es pot trobar oposició envers el capitalisme corporatiu global al costat dels moviments socialista i verd. 2.4.5 Iniciatives pràctiques de polítiques públiques L'impacte polític del codi obert assoleix la màxima visibilitat en diverses iniciatives públiques. Durant els últims anys, s'ha publicat una sèrie d'informes que van des de política de desenvolupament del codi obert a política governamental del codi obert.106 Alguns esperaven que el codi obert reduís les diferències tecnològiques entre les parts riques i pobres del món. Altres s'han esforçat perquè el codi obert fos l'opció preferida de les polítiques de subministrament de programari governamental. A més, hi ha gent que afirma que els militars haurien de triar codi obert per aconseguir la independència dels venedors. Arreu del món ja s'han proposat i acceptat centenars de normatives públiques i lleis relacionades amb el codi obert.107 L'objectiu d'aquest llibre no es estudiar les polítiques públiques sobre el codi obert. Això no obstant, val la pena destacar que històricament el govern ha tingut un paper decisiu en el naixement i creixement del sector del programari en molts països. Els governs continuen sent grans compradors de programari i, per tant, el recolzament públic del codi obert podria suposar un gran impacte en el sector del programari. No sorprèn doncs, que les empreses que tenen més a perdre si el codi obert guanya popularitat hagin començat una campanya explícitament contra la normativa del codi obert. Especialment Microsoft, que va llançar l'any 2002 la Iniciativa per a l'Elecció de Programari, que afirma, entre d'altres coses, el següent:108 "Les lleis de "preferència" perjudiquen la indústria de les tecnologies de la informació basada sobretot en el programari privatiu perquè els administradors del govern tenen ordres de comprar automàticament o preferir programari de codi obert i desestimar les ofertes de programari privatiu. De manera més radical, les propostes "preferents" representen una agressió fonamental al sistema d'incentius que permet que floreixi la indústria IT i beneficiï els consumidors. No només bloquegen la competència en els mercats governamentals, sinó que també indiquen al sector les nocions bàsiques del lliure mercat, de les proteccions de la propietat intel·lectual, i l'empemta innovadora ja no afecta els seus productes i serveis. Els defensors del codi obert han reaccionat durament davant d'aquests arguments.109 A més, la declaració de dalt fa que un es pregunti si el codi obert treballa realment contra el "sistema d'incentius", la "competència", l'"empresa del mercat lliure", la "propietat intel·lectual" i la innovació en la indústria del programari. El capítol següent tractarà amb més detall les qüestions econòmiques que hi ha darrere de la feble argumentació de les polítiques públiques. 2.5 Conclusió: Explicació del paper cada cop més important del codi obert El codi obert ha format part de la indústria del programari des dels seus inicis. La idea de codi obert es va amagar durant els vuitanta i principis dels noranta quan el desenvolupament i les condicions de mercat afavorien el desenvolupament centralitzat i tancat i l'acord de llicència privativa. Tot i així, el model de distribució de programari de prova als mercats massius i el desenvolupament continu del codi obert a les universitats va demostrar que seria beneficiós en alguns aspectes distribuir programari lliurement i utilitzar un mètode de desenvolupament obert. Als noranta, l'entorn finalment va canviar . Ara podem oferir moltes explicacions sobre el sorgiment del codi obert en el corrent principal del sector del programari. Inclouen: Des d'una perspectiva tècnica, el ràpid creixement d'Internet, la tendència cap a ordinadors personals barats i la necessitat de mètodes de desenvolupament més flexibles han afavorit el codi obert. Des d'una perspectiva empresarial, el codi obert ha fet possible que empreses noves canviessin l'estructura de mercat existent i les regles del joc. El codi obert també ha alterat les estratègies de mercat dels implicats. Des de la perspectiva de la política social, s'ha reclamat que el codi obert sigui una eina per obtenir més democràcia, per accedir a la informació i la igualtat social a mesura que la funció del programari a la societat continuï augmentant. Els efectes socials i culturals del codi obert són cabdals. És crucial que les empreses entenguin les dimensions socials i ètiques si realment es desitja participar i influir sobre el desenvolupament del codi obert. Introduir el codi obert pot requerir també una reconsideració fonamental de l'estratègia dels drets de la propietat intel·lectual de les empreses. També hem vist que el codi obert és un concepte força ambigu. No hi ha cap comunitat de codi obert única sinó múltiples veus individuals que provenen de la cultura dels hackers. Les idees més d'esquerres i liberals tenen el seu origen en els anys setanta. No obstant, la indústria del programari va adoptar el terme codi obert un cop va ser introduït i institucionalitzat a finals dels noranta. En aquest llibre utilitzem codi obert tal i com el contempla la indústria del programari, com una referència a diverses empreses de programari de codi obert. 3 Principis econòmics dels productes informàtics Aquest capítol tracta les teories econòmiques de les xarxes, el copyright i les patents en el context dels productes de programari. Totes les teories caracteritzen diferents aspectes dels productes de programari amb algunes diferències però també alguns similituds. L'objectiu d'aquest capítol és construir una teoria coherent on els models de llicències de programari de codi obert es puguin analitzar dins un context econòmic més ampli. 3.1 Caracterització econòmica dels productes informàtics 3.1.1 Perspectiva de l'economia de xarxa En aquest estudi seguim el plantejament dels economistes i analitzem el programari en el context de les indústries de la xarxa.110 El punt de vista que s'ha pres és el d'una empresa fabricant de productes de programari per als mercats competitius. Estem interessats principalment en el programari com un producte econòmic del sector del programari. A continuació, expliquem com els conceptes desenvolupats en la documentació de l'economia de la xarxa s'apliquen als mercats de productes de programari. Per desgràcia, això no és tan senzill com sona, ja que és difícil jutjar quins conceptes econòmics son els més rellevants. El fet és que actualment hi ha una oferta excessiva de caracteritzacions econòmiques i classificacions dels mercats del programari que a més són molt exhaustives.111 Per exemple, el llibre de text de Shy identifica quatre atributs principals com compatibilitat i estàndards; externalitats de la xarxa; costos d'immobilització i de substitució; i economies d'escala.112 Gottinger fa un llistat amb setze "característiques estratègiques".113 A més, hi ha arguments sensats i amb base empírica de, per exemple, Liebowitz i Margolis suggerint la funció general i el poder d'explicació del plantejament econòmic de la xarxa limitat al context del mercats del programari 114Mentre ells reconeixen la rellevància de la teoria, les implicacions i la utilitat dels resultats no són sempre vàlids en totes les situacions de mercat. Tenint en compte aquests defectes, avancem amb la teoria. 3.1.2 Programari com un bé econòmic Programari com un bé informatiu. El punt inicial per a l'anàlisi és la teoria econòmica de la informació. El supòsit és que el programari es pot descriure com un bé que inicialment és costós de produir, però que després és barat de reproduir. Això significa que la producció de programari implica el que els economistes anomenen l'economia d'escala. Podem il·lustrar els costos de producció i reproducció dels productes de programari amb la següent xifra: Figura 8. Funcions de cost diferents en la producció de béns d'informació.115 La xifra pO indica els costos de producció inicials i els pm costos de reproducció de cada còpia addicional. La funció de costos total és un conjunt de les altres dues i la mitjana dels costos és igual als costos totals dividits entre el número de còpies. La xifra ajuda a explicar que per a cada preu indicat a dalt pm hi ha un cert nivell de vendes (q) després del qual cada còpia reproduïda implica un benefici. Ja que el preu del producte no depèn de pO, podem apuntar que els costos de desenvolupament no són una bona base per a la cotització del producte de programari. Encara que el model sigui simple i s'expliqui en molts llibres de text econòmics, té severes limitacions d'aplicabilitat en la indústria dels productes de programari. El model no té en compte els costos de venda i manteniment del producte, com per exemple, els costos de màrqueting, manteniment i millora no estan inclosos en els "costos marginals", que se suposen que són constants i mínims en comparació amb els costos de producció. El model de programari com un bé d'informació es pot aplicar, per exemple, al programari d'entreteniment i a altres aplicacions de l'usuari final amb un esforç mínim de vendes i suport per part del productor. Programari com un bé capital. Els béns capitals són costosos de produir i el distribuïdor del producte treu un benefici de la instal·lació, manteniment i suport. La teoria del bé capital s'ha aplicat, per exemple, a projectes de construcció. Però els productes de programari més grans també es poden comparar, en molts aspectes, amb els béns capitals. Especialment els primers productes de programari eren molt costosos de produir, i un cop el sistema estava en alça s'esperava que anés adquirint experiència al llarg dels anys venidors. Per exemple, avui en dia el programari de la gestió global de l'empresa (ERP) es pot descriure millor com un bé capital. Es podria pensar que els efectes econòmics de fer còpies depenen de si l'obra s'hauria de contemplar com un producte de consum o un producte capital. És freqüent reivindicar, per exemple, que els costos socials de copiar béns de consum són menys perjudicials ja que la societat consisteix majoritàriament de consumidors individuals. També és costós controlar el comportament del consumidor. A més,es pot defensar que, en els béns capitals, la difusió de tecnologia augmenta la innovació i també el benestar social. Especialment quan els productes de programari s'utilitzin com a mitjans de producció, haurien de tenir probablement uns drets d'ús més flexibles que els adoptats en la llei del copyright. Per altra banda, sempre és possible reconvenir que copiar disminueix la creació d'obres noves sempre i quan siguin consumidors de béns capitals.116 El programari com un bé públic. Independentment de la teoria de la informació i dels béns capitals, el programari com un producte també pot ser contemplat com un bé públic. Per establir una distinció entre bé públic i bé privat hi ha dos subconceptes que requereixen ser definits: No excloïble. Pot haver-hi un número il·limitat d'usuaris simultanis d'un bé. L'un no pot restringir als altres l'ús del bé. La quantitat del bé no pot ser controlada, és igual per a tothom. Exemples de béns no excloïbles són els espais públics i el programari de codi obert.117 No rivals Els béns no consumeixen. L'ús d'un bé per part d'una persona no disminueix la seva capacitat d'ús pels altres. No es pot controlar la qualitat del bé. És igual per a tothom. Els exemples típics de béns no rivals són l'aire i el programari privatiu. Els béns públics són tant no rivals com no excloïbles. Així, el seu valor no disminueix sinó que augmenta amb l'ús.118 Els béns privats, en comparació, són tant rivals com excloïbles. Això potser pot il·lustrar-se millor a la taula següent: Taula 5. Els béns públics, com el programari lliure, són tant no excloïbles com no rivals. La teoria dels bens públics sembla atractiva en el context del programari de codi obert. Els drets de la propietat intel·lectual, per la seva part, privatitzen la naturalesa del bé públic del programari en oferir capacitat d'exclusió. A més, el programari privatiu és no rival: copiar programari en contra dels seus termes de llicència (pirateria) no disminueix el seu valor per als usuaris (però alguns productes o serveis complementaris com la garantia i el suport poden no estar disponibles). 3.1.3 Components i sistemes Finalment, el programari pot caracteritzar-se com un producte del sistema. Sabem que el programari s'utilitza en els sistemes informàtics que consten de diferents components de maquinari i programari. El programari mai no s'utilitza aïlladament, sinó com una part del sistema. El sistema pot constar de components separats de maquinari i de programari i perquè el sistema funcioni, els components han de treballar, d'alguna manera, conjuntament. És a dir, han de ser compatibles els uns amb els altres. En aquest estudi, definim els termes compatibilitat, interoperabilitat i estàndard de la següent manera: Un component és compatible amb un altre si poden intercomunicar-se sense que es modifiquin. A més, la compatibilitat pot ser en un o en dos sentits. Si els dos components poden comunicar-se l'un amb l'altre (compatibilitat en dos sentits), es diu que són interoperables. Per exemple, el programari nou pot ser compatible amb el programari antic (compatible "cap enrere") però no viceversa. En aquest cas, el programari nou i el programari antic no són interoperables. Un estàndard és un conjunt de regles ex ante dirigit a la compatibilitat entre components. Els components interoperables segueixen el mateix estàndard. A més, els estàndards poden ser oberts o tancats. En principi, qualsevol persona és lliure d'escriure una implementació pròpia per a un estàndard obert.119 Òbviament, la documentació d'un estàndard obert ha de ser oberta i les successions de proves han d'estar disponibles obertament. Per exemple, molts llenguatges de programació i de formatació són clars exemples d'estàndards oberts. L'estàndard tancat és el complement d'un estàndard obert. Més avall hi ha una il·lustració del plantejament de components al programari: Figura 9. Plantejament de components als productes de programari. Els dos fabricants A i B produeixen dos components, aquí anomenats 1 i 2. Si només són possibles les combinacions A1A2 i B1B2 , llavors els components són incompatibles. I si A1B2 o B1A2 és possible, llavors són compatibles en un sentit (o, per exemple, cap enrere). Si totes les combinacions són possibles, els components són compatibles en dos sentits i perfectament interoperables. La compatibilitat pot ser gradual. Una compatibilitat perfecta significaria que no hi ha cap cost ni reducció del rendiment entre les comunicacions entre dos components. A la pràctica, per exemple, els sistemes operatius Unix són més o menys compatibles els uns amb els altres. Mentre el nucli del sistema Unix està estandarditzat (estàndard POSIX obert), cada implementació segueix l'estàndard només parcialment o afegeix característiques pròpies incompatibles. Si els components pertanyen a diferents empreses, pot produir-se una fragmentació. Si hi ha massa propietaris amb drets exclusius per a diferents components del sistema, pot produir-se una subutilització perquè els costos per negociar els drets necessaris per a la totalitat del sistema poden ser massa elevats.120 Tot sovint es pensa que el programari de codi obert ha de ser compatible per la seva pròpia naturalesa (codi font disponible i modificable) i ha de seguir els estàndards oberts. No obstant, aquest no és sempre el cas. És possible, tal i com s'explicarà posteriorment, que el codi obert segueixi un estàndard tancat.121 A més, algunes llicències de fonts obertes poden ser incompatibles les unes amb les altres i fins i tot poden sorgir problemes de fragmentació com amb qualsevol component privatiu.122 3.1.4 Trajectòria de la dependència, immobilització i efectes de xarxa L'enfocament del producte de sistema es pot utilitzar per explicar perquè és típic en la indústria del programari que només uns quants productes dominin el mercat en un moment determinat. En resum, potser no té gaire sentit per als usuaris canviar d'una trajectòria de producte a un altra perquè es podria perdre la compatibilitat del sistema o els beneficis del la xarxa existent de l'usuari. Això porta a definir els costos de substitució i els costos d'immobilització. Els costos de substitució són els costos de la migració entre components incompatibles. A més, podem identificar costos d'imputació en un o en dos sentits. Per exemple, si es necessita aprendre com funciona un component abans d'utilitzar-lo, no hi haurà costos de substitució per retornar al component antic (un de ja conegut). En canvi, qualsevol cost a la transacció actual de substitució significa que també hi haurà costos a la substitució de retrocés.123 Recentment, els costos de substitució s'han analitzat com una eina per crear situacions d'immobilització. Si els costos de substitució són suficientment elevats com per afectar l'opció de compra de l'usuari a favor del producte que utilitza actualment, llavors diem que existeix una situació d'immobilització.124 La immobilització pot ser, per exemple, contractual, referent a una adquisició duradora o basat en programes de lleialtat.125 Tant la immobilització del maquinari com del programari han estat comuns. En principi, els efectes de la immobilització del maquinari poden ser pal·liats amb l'arquitectura oberta dels sistemes i la immobilització del programari amb el programari de codi obert. Un argument comú per a les migracions de codi obert és que no implica immobilització per als desenvolupadors particulars. En teoria, és ben possible canviar de desenvolupadors si el codi font està disponible i es pot modificar lliurement. No obstant, el desenvolupament d'un codi font particular pot requerir normalment el coneixement tàcit dels desenvolupadors originals, cosa que pot ser molt costosa d'adquirir, especialment si el producte és molt complex. 126A més, tal i com s'indicarà més endavant, els termes de llicència poden incloure encara certes limitacions, que posteriorment tenen com a resultat una situació d' immobilització de facto. Finalment, els efectes positius de la xarxa també caracteritzen els mercats del programari: 127 Si el valor del bé per a l'usuari depèn del número dels altres usuaris, es diu que el bé té efectes de xarxa.128 En els mercats del programari, els efectes de xarxa normalment són positius: una gran base d'usuaris augmenta el valor del producte per a un individu. Els efectes de xarxa poden ser tant directes com indirectes. Els propis efectes del producte es diuen que són directes i els efectes a altres productes mitjançant la compatibilitat o no compatibilitat es diuen que són indirectes.129 Els efectes de xarxa no estan restringits a béns materials. S'ha sostingut que, per exemple, no només es comparteix el programari sinó també la capacitat dels desenvolupadors i es gaudeix dels beneficis de la xarxa en expansió.130 A la pràctica, potser no sempre és apropiat parlar d'externalitats de la xarxa, ja que els productors de programari prefereixen interioritzar el resultat dels efectes de xarxa mitjançant, per exemple, copyright privatiu o la llicència de patents. No obstant, en el cas del codi obert, els desenvolupadors de programari en molts casos no tenen poder per internalitzar els efectes amb aquests mitjans directes. Així, es pot argumentar que, per exemple, la còpia i ús del nucli del sistema operatiu GNU/Linux - el copyright del qual està permanentment sota una llicència de codi obert - causa externalitats de la xarxa a les companyies que competeixen en els mercats del programari de sistemes operatius.131 3.2 Economia del copyright informàtic Per començar, la societat necessita realment una llei de copyright? Aquesta qüestió tan antiga segueix sent tan rellevant avui en dia com ho era quan la premsa escrita era una tecnologia nova i els primers privilegis eren garantits a les ciutats-estats medievals d'Europa. El creixement desenfrenat de la còpia de música i pel·lícules d'Internet ha provocat que la indústria de l'entreteniment apliqués estrictament els drets d'autoria mentre que els crítics mantenen que el copyright s'hauria de reformar per a les obres digitals. En mig d'aquest debat, no obstant, sembla ser que el copyright del programari funciona sorprenentment bé. 3.2.1 Motivació dels desenvolupadors Mentre que la llei tracta el copyright com una forma de creació artística, els economistes solen parlar d'innovació. I la innovació no creativa sempre impactarà a la societat humana a menys que les empreses i els comerciants comencin a distribuir-ho a la societat. No obstant, la qüestió bàsica de per què existeix la creativitat encara no té resposta. Per exemple, se'n donen les raons següents:132 Recompensa monetària i altres recompenses materials Diversió i "per satisfer la curiositat"133 Fama i mèrit Servei a la societat o a la humanitat134 Instint d'habilitat en el treball Un dels tòpics més discutits sobre el codi obert ha estat la motivació dels desenvolupadors. Per què alguns desenvolupadors dediquen el seu temps lliure a projectes comunitaris com el Linux o Apache? S'ofereixen respostes que van des de l'economia de la senyalització als objectius ètics.135 Pels propòsits d'aquest llibre és suficient indicar que la indústria del programari dóna ferm suport al codi obert. Els projectes comercials de codi obert i altres interessos corporatius en el desenvolupament del codi obert mostren que també hi ha clars motius de benefici industrial a més dels possibles motius altruistes dels individus. 3.2.2 Inversors i incentius No hi ha respostes definitives pel que fa a l'augment de les activitats innovadores i creatives en la societat. Per exemple, Machlup ha indicat que l'augment en la compensació dels inventors, el número d'inventors o el número d'invencions no es correspon directament amb el número de noves invencions i innovacions efectives.136 Sobretot no està gens clar com la creativitat està relacionada amb la propietat i la propietat intel·lectual. La història del copyright mostra dos motius darrere d'una institució per a propietat limitada d'obres creatives. Fins als temps moderns, un objectiu important del copyright era donar als propietaris de la premsa escrita i a l'Estat cert control sobre què es publicava i s'imprimia. Però, en comptes de crear incentius per als autors nous o innovadors, els primers privilegis anteriors a les lleis modernes del copyright van sorgir de la idea que en primer lloc s'haurien de protegir els que han invertit en les màquines de copiar i les estructures institucionals de suport. El paper de l'autor no va començar a tenir importància fins uns quants segles més tard. Normalment es fa referència a John Locke com el primer filòsof que va explicar l’existència dual tant de la propietat intel·lectual comuna com de la individual.137 La idea era que cada membre individual de la comunitat social havia de tenir el dret a la seva pròpia persona. A més, tota obra i els seus resultats poden indicar-ne l'origen. Inicialment, tota la propietat pertany als comuns, però quan un individu mescla la seva obra amb els comuns, això es converteix en la seva propietat personal. Les teories dels drets de propietat estan vinculades al bagatge cultural. Per exemple, en moltes cultures asiàtiques s'ha acceptat la còpia de creacions intel·lectuals des de fa molt de temps. A la Xina, el valor d'un artista pot dependre directament del volum de còpies i imitacions dels seus treballs.138 Al segle XVIII les lleis del copyright van reconèixer posteriorment els interessos dels autors individuals i la institució es va justificar com un incentiu pels autors per crear més obres noves.139 No obstant això, el copyright també es va seguir desenvolupant paral·lelament al desenvolupament tecnològic i als interessos dels inversors. Al llarg del segle XX, el copyright va començar a incloure mapes, dibuixos tècnics, programes informàtics, i més recentment també mecanismes tècnics de protecció (tots els productes de les empreses industrials en comptes dels autors individuals). Expressat de forma barroera, el copyright va seguir un canvi tecnològic i en algun moment determinat, la distinció precoç entre autors i inversors es va difuminar. En efecte, es pot argumentar que el copyright avui en dia es justifica tant com un incentiu pels autors individuals com un mitjà institucional per protegir les inversions creatives. Una raó òbvia de la relativa solidesa de la justificació de les inversions és la consolidació de l'analogia de la propietat. Actualment, el copyright i la gestió de la propietat intel·lectual es contempla com una part rellevant de l'estratègia de qualsevol empresa de tecnologia i de mitjans de comunicació.140 3.2.3 El cost de copiar Però quant els costa realment, als autors, inversors i a la societat en general , les còpies? Potser la resposta és: no gaire. Ja és ben conegut l'argument de Plant que la llei del copyright no és la millor manera de regular la còpia de llibres.141 En canvi, ell va intentar demostrar que fins i tot sense el copyright se seguirien creant llibres nous, que la indústria del llibre continuaria existint i que la societat en general estaria molt millor. Però no va tenir en compte la pèrdua de benestar dels autors individuals i dels editors. El terme "pirateria" s'ha utilitzat durant segles per caracteritzar la còpia il·legal.142 Un estudi recent d'IDC comissionat per la Business Software Alliance (BSA) va calcular que, el 2003, un 36 % del programari utilitzat arreu del món eren còpies pirates. En els mercats principals, aquest índex de pirateria ha anat disminuint lentament: Als EUA la quota era d'un 22 % i a Europa occidental d'un 26 %. A partir d'aquestes dades, l'estudi també calcula les "pèrdues" dels venedors de programari suposant que cada còpia il·legal s'hagués venut legalment a preu de mercat.143 Molts economistes han mostrat el seu desacord amb aquest càlcul de pèrdues des que es publiquen aquests estudis sobre la pirateria.144 El problema econòmic de concebre que la còpia és categòricament perjudicial és a grans trets el següent: el qui copia no pren res exclusiu del titular del copyright sinó que simplement imita i reprodueix. L'obra abstracta com un objecte intel·lectual no canvia de mans, només se'n multipliquen les representacions en el món real. Ara bé, si aquesta multiplicació augmenta o disminueix el benestar dels autors, usuaris i del conjunt de la societat és un assumpte completament independent. Però no es pot demostrar de cap de les maneres si la còpia il·legal té els costos que normalment organitzacions com la BSA reclamen.145 En canvi, els economistes s'han concentrat en construir models per estimar l'índex òptim de còpia (il·legal) des de la perspectiva dels autors. Se suposa que cap dels dos extrems (0 o 100 % de la quota de pirateig) és beneficiosa per als autors. Permetre la còpia fins a cert punt crea la base comercial per a l'obra juntament amb l'augment del benestar de la societat en conjunt.146 En un mercat altament competitiu, establir nous participants toleraria òbviament més pirateria mentre que els titulars haurien de lluitar contra ella.147 3.2.4 Límits òptims del copyright Sembla ser clar que el copyright no és un dret típic de la propietat. A més, per protegir els interessos de l'autor i de l'inversor, el copyright també hauria de permetre als usuaris accedir i modificar les obres d'una manera raonablement liberal. Es diu que no es crea cap obra nova sense haver-ne après de les altres. En resum, el copyright hauria de compensar els beneficis de la creació d'obres noves amb els costos de limitar l'ús lliure d'aquestes obres.148 Riis separa tres components dels drets d'autor que bàsicament determinen el seu abast: drets coberts, l'abast d'aquests drets i el terme de copyright.149 Anem a debatre'ls per torns partint de la qüestió de si és beneficiós o no per a l'autor permetre la còpia indirecta. Còpia indirecta. Els economistes han establert diferències entre la còpia directa i indirecta (imitació). Quan es modifica una obra o es barreja amb una altra és difícil esbrinar quin és l'impacte econòmic d'aquesta obra nova per al titular del copyright de l'original.150 Potser la còpia indirecta s'hauria de regular de manera més flexible tenint en compte els efectes econòmics cas per cas sobre el titular del copyright de l'obra original. El valor de la còpia indirecta és naturalment diferent per a l'usuari o per a l'autor original. Per exemple, Besen i Rasking argumenten que l'autor original hauria de tenir uns drets molt limitats per influir sobre les modificacions o les obres derivades. Donar als imitadors possibilitats de crear obres noves basades en obres existents, dóna suport a l'empresariat i evita els costos de la reinvenció.151 Landes i Posner també indiquen que quan es creen obres noves, normalment s'utilitzen de base les antigues, explícita i implícitament, en afegir una contribució nova o de forma literal. Òbviament, un copyright més ampli augmena els costos de creació d'obres noves si es confereix als autors existents el poder de controlar la creació de les còpies indirectes o de les obres modificades.152 Aquí també podem assenyalar la idea de Liebowitz d'aplicar el concepte de la discriminació de preu al copyright. En resum, el titular del copyright pot autoritzar l'obra amb un preu i uns drets adaptats als grups per usos diferents segons la seva necessitat, per exemple, de fer còpies directes o indirectes. Part dels usuaris estarien disposats a pagar més per la possibilitat de copiar o modificar l'obra mentre que no seria raonable fer pagar res a la majoria, a no ser que fos només un preu simbòlic. 153Especialment en el cas que el mercat impliqui efectes de xarxa , el titular del copyright hauria de considerar en primer lloc expandir la base del mercat permetent la còpia i després el preu posterior hauria de discriminar aquells usuaris que estarien més disposats a acceptar la comissió del copyright i pagar la quota de la llicència per alguns tipus d'ús.154 Excepcions del copyright. Des de la perspectiva econòmica, qualsevol exempció a l'abast d'un dret està justificat si els costos d'imposar el dret superen el possible benefici. Per exemple, l'ús privat d'una obra normalment està permès com una exempció especial. L'ús privat d'una obra seria molt costós d'imposar, i per altra banda, l'ús privat podria afectar directament al rendiment dels autors individuals quan estudiïn les obres existents de maneres creatives. En el context dels programes informàtics, l'enginyeria inversa i les interfícies han estat qüestions sotmeses a debat. S'hauria d'estendre l'abast del copyright també a les interfícies dels programes? En cas contrari, s'hauria de permetre l'enginyeria inversa per a la interoperabilitat, que podria requerir la còpia i modificació del programa, com una exempció especial del copyright? No hi ha cap resposta correcta. L'enginyeria inversa del programa podria fomentar la creació d'obres noves però, per altra banda, podria resultar en obres de competència injusta i en menys incentius per crear de nou. El terme de copyright. Braunstein et al va assenyalar en el seu informe d'estudi tan influent per a US Copyright Commission abans que els programes informàtics tinguessin copyright, que el període òptim de protecció s'hauria de determinar cas per cas. Com a regla general, el temps de protecció hauria de ser inferior a la vida econòmica de l'obra. Contemplant ara la llei del copyright, una qüestió crucial és si els guanys d'eficàcia haurien de superar els costos administratius de múltiples períodes de protecció en la legislació del copyright.155 La durada ajustada del copyright és racional si assumim que l'objectiu del copyright és obtenir un benefici compensat entre els propietaris del copyright i els usuaris; abans no caduqui el copyright, els propietaris tenen un monopoli temporal. En el cas del programari, els cicles de vida del producte han estat històricament de 5 a 15 anys.156 La protecció del copyright dels programes informàtics encara segueix avui en dia les mateixes durades que qualsevol obra artística i actualment la majoria de les vegades és superior a la vida del producte. Des d'una perspectiva econòmica, l'augment de la durada del copyright afegeix els costos de transacció per copiar i d' altra banda, reutilitza les obres antigues que ja no estan en circulació,però segueixen protegides pel copyright. Pot ser difícil contactar amb l'autor o l'editor d'una obra publicada fa més de cinquanta anys i negociar el permís per copiar l'obra. En canvi, gairebé no hi ha cap augment dels incentius econòmics pels autors que creïn obres noves si el copyright dura 50 o 70 anys més després de la mort de l'autor.157 Afortunadament, el llarg termini teòricament ineficient del copyright no ha alentit, a la pràctica, el desenvolupament de programari nou. Com que els cicles de vida d'un producte són breus i els nous avenços tecnològics comuns, les parts essencials dels productes nous es desenvolupen des de zero. Per tant, qualsevol tecnologia heredada i els seu copyright o qualsevol altra protecció legal pot no afectar de cap manera el desenvolupament de productes nous. Es pot especular que potser en implementar durades variables de copyright per obres de programari no s'haurien assolit els guanys d'eficiència suggerits per alguns economistes. El model de cicle de vida no s'aplica als jocs d'ordinador. Fins i tot els primers jocs desenvolupats poden ser utilitzats, i de fet encara s´hi juga en ordinadors nous mitjançant emuladors.158 En un sentit estrictament legal, és il·legal descarregar-se la majoria dels jocs retro, ja que el copyright d'aquests jocs encara no han caducat i moltes vegades la companyia editora amb qui s'hauria de negociar ja no existeix. Els adeptes dels jocs retro anomenen aquests jocs abandonware i suggereixen que siguin alliberats de copyright Per exemple, l'abandonware de codi obert no és possible si la situació del copyrightno està clara i l'única manera de reduir els riscos legals de distribució i copiar tals jocs seria esmenar la durada del copyright. 3.2.5 Mecanismes de compensació Hi ha moltes maneres de rebre compensació per les obres amb copyright. Possiblement la més evident és recaptar quotes directes per tots els actes restringits tal i com es defineix en la llei del copyright. Un bon exemple és el model presentat per Landes i Posner on el titular del copyrightrecapta les quotes d'autorització (cànons) d'actes restringits com la còpia i la distribució.159 Les quotes de llicència també poden ser tractades mitjançant un sistema controlat pel govern. La idea és recaptar algun tipus de quotes de tots els usuaris i després dividir-les seguint un criteri decidit democràticament. Aquest és, per exemple, el model utilitzat per les societats encarregades de cobrar copyright per als compositors i artistes discogràfics. A gran escala, els sistemes de compensació col·lectiva s'utilitzaven en els antics països socialistes on cobrien bàsicament tot tipus d'obres. Tot i que és difícil jutjar la rellevància del copyright socialista en el debat actual sobre el copyright digital, és interessant aprendre com se'n va dissenyar el sistema. A la Unió Soviètica, els autors eren compensats segons els cànons establerts en el reglament del govern. Els factors que van afectar la quantitat del cànon de llibres, , per exemple, eren la seva llargària, gènere, còpies impreses i la qualitat determinada per l'Estat. La quantitat del cànon no depenia del preu o de les còpies venudes.160 El sistema soviètic pretenia compensar als autors com a altres treballadors basant-se principalment en la qualitat i quantitat del seu rendiment. Per desgràcia, a la pràctica el sistema no funcionava d'aquesta manera. Aspectes secundaris, com ara la quantitat de caràcters de l'obra van convertir-se de vegades en factors determinants. També hi havia un clar incentiu per als grans tiratges.161 El sistema tampoc era igual. A la pràctica, alguns autors ben coneguts i afavorits pel govern estaven exempts del programa fixat per l'Estat i rebien cànons més elevats en comparació amb altres autors.162 Tot i que el sistema de preus basat en els cànons privats potser no funciona de forma òptima, també és difícil trobar cap evidència històrica que doni suport als sistemes de compensació col·lectiva. Els sistemes de compensació basats únicament en les quotes de llicència, són, no obstant, fàcils de criticar. De fet, els autors reben una part substancial de la seva compensació mitjançant altres mecanismes més indirectes que les quotes de llicència. Una manera alternativa de categoritzar aquests mecanismes de compensació indirecta és:163 1.Fer que la còpia resulti cara.La idea és que el que posseeixi una creació intel·lectual tingui la possibilitat de protegir tècnicament la seva creació mitjançant diferents construccions "de filferro espinós". Encara que la còpia de les obres sigui il·legal, l'autor pot tenir un incentiu perquè la còpia resulti més difícil a causa de la limitació de l'abast del copyright i, a problemes d'aplicació evidents.164 2. Béns complementaris. Un altre producte pot ser una condició necessària per a l'ús de l'obra o una característica o servei opcional generador de beneficis. Així se'n crea la venda lligada. Els anuncis també es poden incloure dins d'aquesta categoria. 3. Sincronicitat.L'autor pot controlar el moment de la introducció de l'obra i fer contractes anticipats abans de crear res. I també, l'autor pot intentar introduir noves versions de l'obra tan ràpidament que les còpies sempre estan caducades. 4.Fixació de preus i control de qualitat.Si les còpies il·legals costen més i la seva qualitat és substancialment inferior que la de les còpies legals, llavors hi ha pocs incentius per copiar. Fixar els preus a la baixa pot ser una estratègia eficient especialment quan el mercat té efectes de xarxa positius. Inicialment, Raymond va considerar que les empreses de codi obert eren alternatives al model de la quota de llicència. Va argumentar que existien empreses de codi obert basades en serveis complementaris i suport, béns complementaris com el manual i el maquinari, la legislació de marques registrades i l'obtenció de quota de mercat per a productes privatius.165 Aquests inclouen bàsicament els béns complementaris, l'ajustament del temps i del preu de les alternatives de compensació indirecta presentades més avall. 3.2.6 És ineficaç el copyright informàtic? Durant aquests últims anys, s'han sug gerit força propostes de reforma del copyright. Algunes de les més importants inclouen: 1.copyright semblant a les patents.Bàsicament, el copyright s'hauria de registrar i tindria una durada més breu. D'alguna manera, això faria que el copyright s'assemblés més als béns immobles, però per un període estrictament limitat.166 2. Mecanismes alternatius de compensació. Tal i com s'ha exposat a la secció anterior, aquests inclouen a més dels sistemes de retribució privats, els sistemes col·lectius imposats pel govern, com els impostos del maquinari -que actualment s'utilitzen a gran part d'Europa per a altres obres menys per al programari - i les llicències obligatòries.167 3.Abolició del copyright.Alguns activistes tecnològics segueixen debatent la qüestió.168 A més, alguns acadèmics escèptics de l'eficiència del copyright utilitzen aquests arguments, si bé no ho fan directament, sí entre línies.169 Es pot dir que aquests plantejaments de la reforma no pretenen un copyright més compensat, sinó simplement amb alguna tendència extrema. Potser el debat sobre el copyright perdura simplement perquè hi ha propostes extremistes tant dels que volen més protecció com els que demanen la reforma del copyright. Cal destacar que l'abast del debat sobre la reforma del copyright afecta principalment les indústries d'entreteniment. Des de la perspectiva de la indústria del programari, aquestes propostes tenen menys validesa. Tal i com s'ha indicat, la durada del copyright del programari no és rellevant si el cicle de vida dels programes és breu. Els mecanismes privats de compensació, des dels cànons de llicència fins als models alternatius pel programari, de fet, funcionen per a productes de programari en comparació amb la música i les pel·lícules. Les quotes de pirateria del 30 % indiquen que, malgrat que la majoria de programes es poden descarregar gratuïtament de les xarxes d'igual a igual, els usuaris de programari simplement no ho fan a tal escala com per fer que la comercialització de les llicències sigui obsoleta.170 Al contrari, l'absència de societats recaptadores del copyright en la indústria del programari fa suposar que fins i tot els autors individuals i les petites empreses de programari poden autoritzar de forma efectiva els seus productes de programari amb copyright en els mercats massius. 3.3 Economia de la innovació informàtica i les patents Els economistes han comparat amb freqüència la producció de programari amb la innovació industrial. Un argument tradicional contempla les patents com un incentiu ex ante per destinar a la innovació ex post. Una observació més detallada de la innovació del programari ens mostra, no obstant, que les patents s'utilitzen més com recursos d'estratègia per exercir influència sobre els competidors que com a mitjans per destinar a la innovació. La innovació òptima del programari hauria de seguir de fet un paradigma d'innovació obert i col·laboratiu on la innovació fos dirigida per mitjans alternatius. 3.1.1 Innovació a la indústria del programari Per començar, s'ha debatut si hi ha activitat innovadora en el desenvolupament de programari. Molts programadors famosos no es contemplen a si mateixos com innovadors però sí com autors. Per exemple, els creadors de la majoria dels sistemes operatius moderns han comparat el disseny i el desenvolupament del programari del sistema operatiu amb l'escriptura.171 No creuen que la innovació del programari es "descobreixi" sinó que simplement s'implementa. Per als propòsits d'aquest estudi suposem, no obstant, que el desenvolupament del programari es pot analitzar en termes d'activitat innovadora tal i com ho fan molts economistes. Per exemple, Torrisi identifica en el seu estudi empíric tres categories d'empreses de programari des de la perspectiva de la gestió de la innovació:172 1.Inicis empresarials (d'uns cinc anys d'antiguitat) Aquestes empreses creen noves innovacions. Estan dirigides per organitzacions flexibles i no utilitzen tècniques d'enginyeria ja que és difícil codificar les seves pràctiques. 2.Les petites i mitjanes empreses s'especialitzen en pocs productes o serveis (més de 5 anys d'antiguitat i menys de 500 empleats). Incrementen la innovació del producte (qualitat, diferenciació) i contribueixen principalment a la difusió de les innovacions. Aquestes empreses compten amb una gestió centralitzada.173 3. Les grans corporacions que ofereixen programari de sistemes i serveis (més de 500 empleats). La seva funció és en la combinació creativa d'innovacions de fonts diferents. Les corporacions depenen de regles formals per a la gestió de la innovació. La innovació en la indústria del programari es pot considerar serial i acumulativa: La innovació serial (o contínua) es basa en les innovacions existents. La innovació acumulativa (o incremental, seqüencial) es basa en petites innovacions individuals que juntes fan un producte. En la tecnologia de la informàtica, moltes innovacions provenen de les tecnologies complementàries.174 La innovació acumulativa implica un problema de fragmentació. També podem distingir entre innovació contínua i radical: La innovació contínua construeix damunt de la innovació existent i millora la tecnologia a petites passes La innovació radical (disruptiva o revolucionària) canvia per complet l'estructura de mercat175 Tècnicament parlant, els productes de programari normalment evolucionen mitjançant una quantitat de mínimes innovacions que es construeixen i depenen del coneixement previ. Els productes radicalment innovadors que canvien totalment el mercat solen sorgir de llargs processos socioeconòmics. També és important entendre el context o el nivell del que provenen aquestes innovacions radicals. En un entorn de xarxa, la funció dels usuaris com a innovadors esdevé central i tots els aspectes socials de l'activitat innovadora es reforcen.176 Així, la innovació en xarxa també fa augmentar les interdependències i possibilitats de llicència creuada entre diferents tipus d'empreses.177 3.3.2 Relació difícil entre la innovació i les patents Schumpeter va explicar la innovació amb estructures institucionals legals i d'altres que creen incentius.178 Els economistes a continuació van argumentar que les patents fortes són la institució que maximitza de forma òptima la innovació.179 Va ser difícil criticar l'argument de la innovació. Sense activitat d'innovació ni capacitat empresarial, el progrés tècnic en la societat s'aturaria i no es crearia cap valor nou. Gairebé ningú vol parar l'activitat d'innovació. No obstant, ara sembla que els acadèmics no estiguin d'acord amb el criteri per a les estructures institucionals que de debò promouen l'activitat innovadora. S'han qüestionat patents fortes en particular. Ja el 1958, Machlup va assenyalar al seu estudi seminal del sistema de patents dels EUA el següent: "Cap de les evidències empíriques evidencia la nostra disposició i cap dels arguments teòrics presentats tampoc no confirma ni refuta la creença que el sistema de patents ha promogut el progrés de les arts tècniques i la productivitat de l'economia." Avui en dia, el debat sobre els efectes econòmics de les patents és intens. D'acord, històricament les indústries informàtiques i de programari han tingut una protecció de patents més aviat feble i encara ningú no ha posat en dubte que els camps han estat molt innovadors. Alguns economistes han presentat l'evidència empírica en contraposició a les patents fortes, especialment en la indústria del programari. Sembla ser que en els camps de la tecnologia on s'han utilitzat les patents, s'han reduït les inversions per a la investigació i el desenvolupament.180 Altres economistes defensen les patents del programari argumentant que els assumptes més importants estan precisament en la qualitat de la patent. Segons ells, les patents són un incentiu important per a la innovació, també en la indústria del programari.181 És interessant com el programari de codi obert dóna un argument més que refuta la connexió necessària entre la innovació i les patents. Les llicències del codi obert també es poden contemplar com estructures institucionals per a la innovació i la creació d'informació nova. En el món del codi obert, la font més important d'innovacions són els participants individuals, i l'ús de patents està explícitament rebutjat.182 Els nombrosos mitjans possibles dels individus per compartir i explotar el seu coneixement tàcit afecta, sens dubte, al procés d'innovació. Així, es podria advocar per una explicació Hayekiana per a una innovació del codi obert on els individus cooperen de forma espontània dins d'una estructura governada per la llicència en qüestió.183 Per concloure, tant si les patents fomenten o no la innovació, també tenen altres funcions. Per exemple, Levin et al van observar en llargues entrevistes que moltes empreses registren una patent per observar qui són els innovadors dins l'empresa. 184Les patents també es poden cobrar per raons de reglamentació; per exemple, alguns països desenvolupats requereixen llicències tecnològiques per poder entrar als seus mercats.185 Però molt sovint, les patents s'analitzen en el context d'estratègia corporativa, on la funció és reforçar el poder de mercat influint el comportament d'altres empreses. 3.3.3 Les patents com a actius estratègics Aquests darrers anys, s'han publicat nombrosos estudis sobre l'ús real de les patents en la indústria del programari.186 Actualment les grans companyies d'IT sol·liciten més patents que les seves homòlogues en altres camps tècnics. De totes maneres, les patents de programari no sols s'utilitzen per crear llicències, sinó que cada vegada més s'utilitzen per raons estratègiques. Acumular carteres de patents estratègiques pot servir per avisar a inversors, saltar barreres a noves entrades, actius ofensius i defensius en litigis i per objectius de llicències creuades.187 Stac contra Microsoft és un exemple de l'ús estratègic de les patents de programari. Microsoft va acordar amb Stac Electronics una decisió de patent de programari el 1994. Stac havia presentat una demanda al·legant que Microsoft havia vulnerat el seu disc d'emmagatzematge de patents.188 Després que el jurat fallés a favor de Stac amb 120 milions de dòlars per danys, el cas va quedar resolt pagant Microsoft 40 milions a Stac i comprant-ne les accions. El cas representa tant un exemple d'una patent de programari pròspera protegint una innovació com un esforç legal estratègic d'una empresa que lluita per sobreviure a costa del desenvolupament teconològic. Stac Electronics va tancar poc després perquè havia perdut el lideratge tecnològic i era fàcil "reinventar" la seva carpeta de patents. La naturalesa estratègica de les patents queda reforçada pel fet que si es vol que les patents siguin útils, a la pràctica, les companyies necessiten tenir-ne moltes. S'estima que als Estats Units un 1,5 % de les patents són contencioses i un 0,1 % ho són fins al judici.189 A més, ben bé un 46 % de les patents litigades a judici són finalment declarades invàlides.190 D'aquesta manera, Lemley i Shapiro han caracteritzat les patents no com a exclusives sinó com a drets de propietat "probabilístics".191 Com que no totes les patents tenen valor real, les empreses tenen un incentiu per crear una carpeta de patents tan gran com sigui possible, si volen entrar en el joc de les patents. Finalment, hem d'adonar-nos que si les grans empreses incrementen les patents, no necessàriament vol dir que les empreses de programari petites o independents pateixin i hagin d'estancar la innovació. Tal i com veurem més endavant, sembla que els qui tenen patents les utilitzen principalment contra els altres, si "l'art de la guerra de les patents" mai entra en un estat actiu. La dinàmica del joc de les patents inclou el fet sorprenent que les grans empreses protegeixen, per exemple, els desenvolupadors de codi obert amb les seves patents.192 3.3.4 Diferents mitjans per apropiar-se la innovació Evidentment, l'apropiació de programari és complexa ja que el programari és barat replicar i encara falta molt perquè la protecció i aplicació de la propietat intel·lectual sigui total. 193D'acord amb l'estudi empíric de Torrisi, les eines legals es consideren específicament un instrument dèbil d'apropriació en la indústria de programari. 194A més dels mitjans legals com el copyright i les patents, com a mínim els següents mètodes són possibles per apropiar els beneficis per innovacions de programari. 195 1.Temps de gestació. Ser el primer en el mercat és, segons els estudis empírics, la manera més important per apropiar-se dels guanys . Les fortes vendes i el màrqueting són essencials per establir una posició forta davant els seguidors. 2.Millora contínua. Amb un temps de preparació quasi igual, trobar-se tècnicament (en qualitat) al davant de la competència, també impacta els guanys, segons els estudis empírics. 196 3.Personal qualificat. Es pot argumentar que les innovacions d'avantguarda preparen l'innovador a adaptar-se millor als canvis tècnics del futur. Això també indica que les empreses haurien de comprometre's en el desenvolupament i evitar la trampa de "no inventat aquí". 4.Secret. Molts estudis han demostrat que el secret és relativament el mitjà menys útil, encara que també possibiliti l'apropiació. La breu recerca empírica disponible mostra que el temps de gestació, la millora contínua i el personal qualificat han estat a la pràctica eines d'apropiació més importants que el copyright i les patents. 197 De totes maneres, mentre la protecció legal sigui una eina dèbil, la protecció intel·lectual i les patents també fomenten possibilitats per apropiar-se els beneficis pels complements de la innovació.198 Per exemple el coneixement tàcit requerit per usar la innovació no es pot protegir directament a través de mitjans legals, però pot ser usat com un argument de vendes pel mateix programari.199 Es pot observar que les patents poden treballar contra el mercat basat en incentius per la innovació de programari. Mentre que amb el copyright hi havia diferents mètodes complementaris, amb les patents, hi ha més alternatives clares. 3.3.5 Un model d'innovació obert Els nous models que proposen fer servir personal extern i flux lliure d'idees més enllà dels límits de l'empresa han qüestionat la gestió tradicional d'innovacions rere les portes tancades d'una empresa. Coase ja va observar que si la tecnologia de la comunicació baixa més els costos de l'externalització cap als mercats que els costos organitzacionals, reduir les activitats internes de l'empresa pot ser una mesura assenyada.200 Actualment, només perquè l'adquisició i gestió de drets exclusius als resultats de les innovacions és costosa i, d'altra banda, els costos de la comunicació i la cooperació voluntària en els mercats han baixat, val la pena considerar un model obert per a la majoria de les activitats innovadores. Chesbrough presenta un model possible: Figura 10. Un model d'innovació obert201 Podem dir que són pocs els projectes de recerca que arriben a la fase de desenvolupament tecnològic. La cooperació i l'intercanvi lliure d'informació de recerca traspassant els límits de l'empresa pot conduir al desenvolupament de nous projectes exteriors que combinin la base de coneixement existent de manera innovativa. Més endavant, la companyia tindrà avantatge (basat en mèrits anteriors per ajudar a llançar el projecte) per beneficiar-se dels projectes externs, per exemple mitjançant l'intercanvi informal de coneixement i les llicències.202 Aquest tipus de model d'innovació oberta té similituds evidents amb l'economia de la ciència. 203La divulgació informal de la nova informació, l'intercanvi d'investigadors i la cultura de cooperació poden produir noves innovacions més eficients que els projectes de tecnologia tancada. També s'ha discutit molt que un model de desenvolupament de codi obert s'assembla molt al de recerca científica.204 Podem trobar moltes raons econòmiques perquè les empreses que busquen beneficis participin en la recerca bàsica i viceversa. Per exemple, Foray ha proposat que econòmicament val la pena revelar lliurament la recerca i el desenvolupament de la informació si:205 els sistemes de recompensa adrecen les qüestions de còpia i distribució lliure. Això ens torna als mecanismes de compensació alternatius i a l'apropiació de la innovació, que s'ha discutit més amunt. Les empreses han d'utilitzar obligacions de reciprocitat per participar en la cooperació de desenvolupament. Les empreses tenen interès en millorar la mitjana d'accions del sector. Per a la indústria del programari, el desenvolupament d'una infraestructura d'Internet més segura podria ser una àrea. Les empreses tenen una estratègia de codi obert, que implica que altres no tenen incentius per comercialitzar invents a través dels mitjans privatius. Una qüestió difícil és com la innovació oberta afecta els models de desenvolupament de programari privatiu en el sector del programari. Es podria dir que els models privatius no desapareixeran d'un dia per l'altre encara que les empreses adoptessin models d'innovació oberta. Els models de llicència privativa també es poden adaptar de manera que permetin compartir i intercanviar el coneixement, amb limitacions, sense perdre el control del desenvolupament i la propietat mitjançant els copyrights i les patents. 3.4 Normativa de competència i els límits dels drets d'exclusivitat Els drets de propietat privada, la part dels drets de propietat intel·lectual, són vistos en general com una condició necessària per a la creació de mercats lliures. Posem per cas que North pertany als optimistes de la propietat intel·lectual: els uneix al canvi tecnològic i defensa la idea que només els drets de propietat ben definits cap a la innovació poden garantir un desenvolupament econòmic continu dirigit pel mercat.206 De totes maneres, la intervenció de l'Estat en els mercats de la propietat intel·lectual també es poden justificar en termes econòmics. Històricament, els Estats han tingut interès en censurar la premsa escrita i els drets de propietat intel·lectual desenvolupats en moltes jurisdiccions com a part de lleis de censura. En els temps moderns, l'interès de l'Estat ha passat de la censura a garantir el funcionament eficient dels mercats lliures. L'interès ara està en la intersecció entre la normativa de la competència i la propietat intel·lectual. La indústria del programari ha estat particularment vulnerable als fracassos del mercat. Com s'ha comentat anteriorment, les indústries de programari i maquinari han presentat molts casos exemplars del comportament ineficient del monopoli. Alguns dels processos legals antimonopoli més grans de la història han estat contra els fabricants de maquinari i de programari. Fins als anys 90, IBM va dominar pràcticament la indústria del programari. Als Estats Units, des de finals dels 60 hi va haver reclamacions antimonopoli perquè IBM lligava el programari amb el maquinari. En aquella època, IBM feia impossible que cap empresa vengués programari ja que IBM l'incorporava gratuïtament al seu maquinari estàndard. Als anys 90, quan Microsoft ja s'havia convertit en monopoli del sistema de programari per als ordinadors personals, el Departament de Justícia dels Estats Units va registrar diverses demandes antimonopoli contra Microsoft per tal que part del seu programari no fos exclusiu, sinó possiblement de codi obert. A la Unió Europea també es va investigar la pràctica de Microsoft. La companyia fou acusada de lligar el navegador de web i reproductor multimèdia al seu sistema operatiu estàndard excloent així del mercat petites companyies que oferien productes de programari competitius. 207 La base del problema del monopoli es troba en les lleis econòmiques de xarxes. Els guanyadors guanyen més. Els drets de propietat intel·lectual poden contribuir encara més al seu poder de monopoli: una empresa titular pot tenir el poder d'excloure altres empreses del mercat mitjançant l'execució de copyrights i patents. Aquests arguments, s'han repetit, per exemple, en el cas de Microsoft. De totes maneres, les mateixes lleis econòmiques de la xarxa i la propietat intel·lectual també poden funcionar per augmentar la competència. Com recorda Posner, "la competència per obtenir el monopoli és una forma important de competència".208 Molts economistes argumenten que les situacions de monopoli en la indústria del programari són ineficients per a la societat. Es produirà programari de més baixa qualitat a causa d'una menor competència. La innovació quedarà ofegada. De totes maneres, Liebowitz i Margolis han argumentat que particularment la posició de monopoli de Microsoft en les aplicacions d'oficina no és un resultat d'immobilització, efectes de xarxa i de cotització depredadora, sinó simplement perquè tenen productes tècnicament millors. Quan Microsoft estava en els mercats, els preus van baixar més ràpid que en aquells mercats on Microsoft no estava present. Per tant, afirmen que els consumidors mai es es quedaran lligats a productes inferiors.209 L'impacte del codi obert en el debat de regulació de competència de DPI té potser dues vessants. Primer, no es dubta gens que la popularitat creixent del programari de codi obert i dels estàndards oberts associats hagi tornat a augmentar la competència en els mercats de programari. No hi ha cap empresa de programari que pugui dominar Internet com a plataforma de comunicació de facto. Per exemple, els intents de Microsoft per "estendre i abarcar" les seves extensions estàndards privatives a Internet (pàgines web i correu electrònic) sovint han fallat. És força interessant veure que Microsoft ja ha utilitzat el creixement de la popularitat del codi obert com un argument defensiu en les demandes de competència. 210 Segon, i força paradoxalment, es pot argumentar que el codi obert pot disminuir la competència a la llarga. Si el codi obert en el sentit defensat per la Free Software Foundation esdevé estàndard en dominis d'aplicació específica, podrien quedar limitades les possibilitats de llicència privativa i al final treure de circulació les empreses existents de programari privatiu . Per exemple, SCO ha utilitzat aquests arguments en el cas contra IBM: si Linux esdevé un estàndard Unix de facto, potser no hi haurà mercats per a les llicències privatives d'Unix en el futur.211 3.5 Resum: Justificació econòmica de les llicències obertes Hi ha com a mínim tres tipus de raonaments que dónen suport a la idea de les llicències de programari obert en lloc del privatiu. Si considerem el programari com: 1.Una obra amb copyright, llavors els forts efectes de la xarxa i l'objectiu de particiáció en el mercat donen suport a l'obertura. La capacitat d'utilitzar discriminació de preu dóna suport a la idea de més drets a certs grups d'usuaris. A més, a banda de les quotes de la llicència per copiar i distribuir, hi ha altres alternatives sostenibles econòmicament per generar ingressos. 2.Un producte de sistema, per la qual cosa la compatibilitat és un fort argument per a l'obertura. Tot i així, moltes vegades n'hi ha prou amb interfícies obertes per a la compatibilitat i el codi obert no aporta cap benefici addicional en aquest sentit. També un desig d'immobilització i de dependència de camí porta a la no compatibilitat. 3.Una innovació, per la qual cosa el caràcter acumulatiu i col·laboratiu dels invents donen suport a la idea d'un procés d'innovació obert. La protecció exclusiva de la propietat intel·lectual és només una de les alternatives per apropiar-se de la innovació a més del temps de gestació, la millora contínua i el personal qualificat. Per exemple, les patents de programari han demostrat ser, a la pràctica, més un bé estratègic car que no pas una eina d'apropiació. En conjunt, les teories econòmiques de la xarxes, dels copyrights i les patents donen èmfasi a un plantejament estratègic d'una decisió sobre llicència de programari. Les empreses de programari necessiten considerar factors contextuals addicionals en les llicències de propietat intel·lectual i no limitar el seu pensament a la qüestió tradicional del preu. Per simplificar la imatge, es podria argumentar que en gran part, la teoria econòmica que hi ha al darrere de la llicència de codi obert és només una altra encarnació de la "teoria econòmica d'Internet" de finals dels noranta. Del que no hi ha dubte és que l'exclusivitat incondicional no té futur a Internet. Tanmateix, per tenir èxit comercialment potser no es pot "seguir la llibertat" fins al final, costi el que costi. 212 4 La propietat intel·lectual i els seus malcontentaments Aquest capítol tracta l'evolució de la protecció legal i tècnica del programari. Alguns comentaristes han criticat que l'expansió continuada de diferents lleis de propietat intel·lectual de programari que se solapen ha implicat que la llei ara estigui considerablement desequilibrada. Acabem el capítol repassant les proves i discutint les possibilitats d'equilibri particular de les lleis de propietat intel·lectual mitjançant el codi obert. 4.1 Repte de la protecció del programari Des de l'emergència dels ordinadors després de la II Guerra Mundial, hi ha hagut una intensa discussió acadèmica sobre l'estat legal del programari. Les principals alternatives de copyright i de patents ja s'estudiaven amb profunditat als anys seixanta.213 4.1.1 Inicis de la discussió i pràctica Primeres patents. La primera forma de propietat intel·lectual explícita atorgada al programari va ser probablement la patent.214 A Alemanya, ja al 1957, dos informàtics van patentar el que constituïria un algoritme de programari. 215Als Estats Units, també es va començar a fer més pressió a l'Oficina de Patents perquè s'acceptessin patents de programari.216 L' Applied Data Research's (ADR) fou la primera empresa en obtenir una patent de programari el 1968 d'importància comercial.217 Altres empreses van seguir l'exemple d'ADR.218 Un altre sol.licitant de les primeres patents comercials va ser Whitlow Computer Systems, el qual va poder patentar un tret de tria ocult en el Sistema/360.219 Whitlow també va competir amb els paquets de programari d'IBM. El fundador de la companyia, Duane Whitlow, més tard explicava: "Sabia que era patentable perquè Marty Goetz havia començat a anar per aquest camí. Havíem trobat una instrucció a l'ordinador del Sistema/360 que significava una millora espectacular d'execució. Encara que hi havia altres aspectes significatius inclosos en la patent, sabia que aquest aspecte era una fita important que va fixar la metodologia patentable.220 Aquesta primera pràctica de patents va tenir una parada temporal als anys setanta. Ni els tribunals ni les oficines de patents van acceptar les patents com a forma legal de protegir el programari al llarg de la dècada.221 En arribar els ordinadors personals i fer-se populars a finals dels setanta, el volum de programari desenvolupat va incrementar enormement i van aparèixer noves empreses a la indústria. Patentar no era ben bé una opció en un període de reestructuració tan ràpida. Copyright. Tot i que les patents dominaven el debat en el sector, el primer registre de copyright als EUA es va fer el 1964.222 La necessitat d'aclarir l'estat legal del programari continuava creixent, especialment quan els mercats massius estaven apunt de formar-se a finals dels 70. Les companyies van començar a desenvolupar els contractes "shrink-wrap" ens els paquets de programari perquè no era clar si els copyrights de codi objecte no literal eren vàlids. 223 Els problemes de copyright es van il·lustrar en el cas Data Cash Systems contra JS&A Group, una empresa va perdre una demanda per copyright contra un competidor que havia venut el seu joc d'ordinador sense autorització.224 El competidor havia copiat literalment el codi objecte des d'un mòdul físic del joc, després el va tornar a empaquetar i el va distribuir comercialment. El tribunal de primera instància va decidir el 1979 que el copyright no cobria el "codi objecte". A més, el tribunal d'apel·lació va dictaminar que el joc no estava sota cap copyright ja que no duia l'avís de copyright; hi havia un avís en el manual, però cap al mòdul del joc. Pràctica escèptica. Malgrat el debat acalorat, moltes empreses de programari no estaven preocupades per l'estat poc clar de la protecció legal del programari. Un bon exemple és la conclusió d'un estudi de la indústria als anys 70, on un centenar d'empreses de programari contestaven qüestions sobre el context legal de les llicències de programari: "Moltes empreses contemplaven que no els preocupava la protecció legal del programari; moltes van optar per no respondre la pregunta sobre el sistema de protecció legal preferit. Les que van respondre, van mostrar una forta preferència per la restricció contractual a través del secret de fabricació sobre les patents o el copyright. ... només una petita minoria (el 4 %) dels que van contestar, van dir que havien abandonat el desenvolupament d'un programa per manca de protecció."225 Així, l'interès inicial per la protecció de la propietat intel·lectual del programari va ser en general acadèmica i burocràtica. En aquella època no hi havia cap empresa de programari amb llicència de propietat intel·lectual. 4.1.2 Proposta de l'OMPI L'Organització Mundial de la Propietat Intel·lectual, fundada el 1967, va començar a preparar provisions per a la protecció internacional dels programes informàtics a començaments dels setanta.226 L'obra es va acabar el 1978. En comptes de proposar esmenes directes a les convencions de patents i drets d'autor, l'OMPI va redactar un model de llei basat en un plantejament sui generis. La motivació era que el programari requeria un tipus específic de regulació de la propietat intel·lectual, que no encaixava adequadament amb les lleis de copyright i de patents. 227 Substancialment, les provisions del model deien que: Les noves regulacions només complementarien les lleis de copyright i de patents i no substituïrien cap protecció de propietat intel·lectual que ja s'hagués donat al programari. En general, cal adoptar un plantejament de copyright pel que fa als drets protegits (que només cobreixen la còpia literal però no la creació independent). Seguint els principis de la llei de patents, també s'hauria de protegir l'ús comercial del programari, tant si inclou la còpia com si no. També seguint els principis de la llei de patents, el període de protecció s'hauria de limitar a vint anys. S'hauria de considerar un sistema de registre opcional per encoratjar la disseminació i la divulgació de programari. Les provisions explicaven a més en un esperit utilitari general que:228 "El principal objectiu de la protecció atorgada és no permetre que els propietaris es beneficiïn d'un període de drets exclusius com a recompensa per la creació i divulgació de programari, sinó simplement encoratjar la creació i la disseminació de programari i prevenir la mala apropiació dels resultats de la feina d'una altra persona..." Malgrat aquestes bones intencions, les provisions model no es van implementar com a legislacions nacionals. Un altre intent per preparar una nova convenció internacional en la protecció legal dels programes informàtics tingué lloc el 1983.229 En comptes d'això, simplement es van fer esmenes a les lleis de copyright perquè incloguessin el programari com una nova categoria entre altres obres literals i artístiques. El període limitat proposat i el sistema de registre opcional no van obtenir suficient suport en la regulació internacional de la propietat intel·lectual de programari.230 4.2 El copyright i els seus límits Durant els anys 80, es van rectificar les lleis de copyright arreu del món per tal d'incloure els programes informàtics com una altra categoria de les obres protegides. L'anomenat debat d'interoperabilitat va definir més detalladament els drets legals dels usuaris de programari. Es pot argumentar que el copyright del programari és, actualment, una àrea legal resolta sense cap desenvolupament legal radical a la vista. 4.2.1 El programari entra a la llei del copyright Un punt decisiu per al copyright va ser quan la Comissió Nacional dels EUA sobre Els Nous Usos Tecnològics de les Obres amb Copyright (CONTU) va recomanar en el seu informe del 1978 aplicar només copyright al programari: "S'hauria de rectificar la nova llei de copyright per: 1) fer explícit que els programes d'informàtica, tenint en compte que representen una creació original de l'autor, són objecte de copyright; 2) aplicar a tots els usos informàtics dels programes amb copyright amb la supressió de la actual secció 117; i 3) assegurar que els posseïdors legals de còpies de programes informàtics puguin usar i adaptar aquestes còpies per al seu ús." Estats Units va ser el primer país que va introduir un decret específic de copyright de programari el 1980; després d'aquest decret, la còpia no autoritzada, la distribució i la modificació dels programes informàtics es considera il·legal per ser una infracció de copyright. Altres països s'hi van afegir i aviat es va preferir, a nivell universal, el copyright en lloc d'altres formes de propietat intel·lectual. Per exemple, una reunió de l'OMPI el 1985 va destacar:231 "...un gran nombre de participants s'han mostrat a favor de la protecció del copyright dels programes informàtics; la patentabilitat dels programes informàtics per se s'ha descartat de la llei de gairebé tots els països... el copyright, en el seu desenvolupament, ha demostrat ser suficientment flexible per expandir-lo a obres tècniques." Des de finals dels anys 70, amb l'emergència dels mercats massius de programari, també les llicències de programari (shrink-wrap) van començar a parlar de manera explícita del copyright i la majoria de les empreses hi van confiar com a principal mitjà legal per assegurar el model de llicències. 4.2.2 El debat de la interoperabilitat Qüestió i arguments. Aviat es van posar a prova els límits del copyright de programari amb l'anomenat debat d'interoperabilitat. La qüestió era si els elements no literals com la interfície es podien registrar amb copyright i si es permetia l'enginyeria inversa. Molts productes capdavanters de programari als anys 80 tenien interfícies interoperables i el costum de l'enginyeria inversa en general es considerava perfectament legal. Per exemple, l'MS-DOS es va dissenyar per ser fins a cert punt interoperable amb el popular sistema operatiu de microordinadors CP/M de l'època. De fet, l'MS-DOS es va escriure perquè hi havia demanda d'un sistema operatiu simple que funcionés en els nous processadors 8086 i Digital Research, el desenvolupador del CP/M, encara treballava en el CP/M 86 sense saber quan estaria disponible. I així, el 1981, una petita empresa anomenada Seattle Software Works va decidir elaborar-ne un. Les ordres i la interfície de programació de l'MS-DOS es van dissenyar de manera que s'assemblessin força al CP/M i també va ser possible traduir les aplicacions del CP/M perquè funcionessin amb MS-DOS.232 Digital Research mai no va iniciar cap acció judicial contra els desenvolupadors d'MS-DOS ni tampoc contra Microsoft.233 Band i Katoh van identificar tres grups de pressió en el debat d'interoperabilitat:234 1.Ultraproteccionistes que creien que el programari es pot registrar per a copyright i que s'hauria de protegir amb copyright tant les interfícies com l'enginyeria inversa. Els seus arguments destacaven, per exemple, la necessitat de coherència lògica en la llei del copyright, la teoria d'incentius ex ante i el paper central de la indústria del programari en l'economia nacional dels EUA. 2.Aquells que defensaven una visió equilibrada, és a dir que en general acceptaven el copyright del programari, però que estaven en contra de l'enginyeria inversa i la protecció de la interfície en particular. L'argument econòmic bàsic va ser que si es concedia copyright a una interfície d'un producte de programari estàndard de facto, llavors el poder de monopoli també s'estendria als mercats de programari compatible. En general, el copyright d'una interfície causaria més incompatibilitat a les xarxes i menys beneficis socials.235 3.Els defensors d'un copyright mínim bàsicament estaven en contra de tota la idea de copyright de programari, així com de l'enginyeria inversa i de la protecció d'interfícies. Aquest grup el dirigia Richard Stallman i es basava en arguments ideològics i ètics. Stallman no va tenir massa influència en aquest debat, sinó que va servir com a objectiu fàcil dels ultraproteccionistes que van intentar col·locar-lo amb els defensors d'una visió equilibrada. Europa. A Europa el debat es va centrar en el procés oral de la proposada directiva del copyright de programari.236 Hi va haver dues parts més o menys igualment fortes que lluitaven entre si -un clar contrast amb els EUA on els partidaris de la interoperabilitat tenien molt menys suport del sector. A Europa, una sèrie d'empreses dominants dels EUA en aquella època (Microsoft, IBM, Apple, Lotus, etc.) van establir el Software Action Group for Europe (SAGE) de caire ultraproteccionista, que pretenia aconseguir una llei al més estricta possible per reduir la competència europea. Feien pressió per afegir interfícies d'usuari sota l'àmbit del copyright i, el que potser és més important és que intentaven prohibir totalment l'enginyeria inversa. Per fer front a aquesta amenaça, moltes empreses europees (Amstrad, Bull, Olivetti i Fujitsu del Japó) van formar el Comitè Europeu per Sistemes Interoperables (ECIS), que defensava una postura més equilibrada. Aquest darrer grup també va rebre cert suport del món acadèmic. 237 Al final, la Comissió Europea es va posar de part de SAGE i van elaborar una proposta, que hauria fet gairebé impossible la creació d'un programari interoperable. No obstant, aquí no va acabar tot, ja que el Parlament Europeu va decidir donar suport a ECIS. El Parlament va adoptar un conjunt substancial d'esmenes per a la directiva proposada, incloent-n'hi tres de clau que tenien a veure amb les qüestions d'interfície i enginyeria inversa. Al text directiu final acceptat el 1991, les interfícies no estaven protegides per copyright i es permetia l'enginyeria inversa per a la interoperabilitat Estats Units. Als EUA, el debat es va resoldre als jutjats just després que s'acceptés a Europa la directiva de programari. El primer cas important va ser Computer Associates contra Altai, que es va decidir el 1992, quan es tractava d'un component que permetia la interoperabilitat de programari en diferents sistemes de maquinari. El programador d'Altai havia copiat originalment gairebé el 30 % del codi font de Computer Associate, però quan Altai se'n va adonar, el va reescriure. Computer Associates va continuar argumentant que el component reescrit infringia també el seu copyright . Les dues parts va rebre suport d'altres empreses i diversos grups de pressió del sector. Les grans empreses d'IT d'aquella època, entre elles IBM, DEC, Microsoft, Lotus, WordPerfect i Apple, van donar suport a una visió ultraproteccionista. El seu grup de pressió anomenat Software Publishing Association (SPA) va defensar Computer Associates. Tanmateix, el grup d'SPA no estava unit. Borland, Novell i Compaq, antic membre d'SPA, van fer explícit el seu desacord. L'American Committee for Interoperable Systems (ACIS), que incloïa empreses menys conegudes com Storage Technology, AT&T Global Information Solutions, Amdahl, i Broderbund Software, van donar suport a Altai i tenien una visió més equilibrada.238 A Computer Associates contra Altai, el jutjat va rebutjar una sentència anterior, que declarava que els elements no literals com l'estructura, la seqüència i l'organització d'un programa informàtic generalment quedarien protegits pel copyright.239 En canvi, el tribunal va passar a declarar que el copyright no hauria de protegir àrees on les idees es fusionen amb expressió. Afirmava que els programadors tenien menys varietat de disseny en: "(1) Especificacions mecàniques de l'ordinador en el que hauria de funcionar un programa en particular; (2) Els requeriments de compatibilitat d'altres programes amb què es dissenya un programa per pugui funcionar conjuntament; (3) els estàndards de disseny dels fabricants informàtics; (4) demandes de la indústria que se serveix; i (5) una pràctica de programació acceptada àmpliament per la indústria informàtica".240 Per tant, el tribunal bàsicament va dictaminar que aquesta interoperabilitat no està protegida per copyright. Un altre cas central va ser Lotus contra Borland, decidit el 1995, i que va concloure a favor de Borland i en contra del copyright per interfícies. Lotus havia declarat que Borland va infringir el copyright dels fulls de càlcul 1-2-3 de Lotus en copiar la major part de l'estructura del seu sistema de menú. En primera instància, la decisió va anar a favor de Lotus però després d'una reclamació, un circuit federal va dictaminar a favor de Borland. El tribunal va destacar que la qüestió era sobre un"mètode d'operació" i va declarar: "Les opcions expressives de com anomenar els termes d'instrucció i com organitzar-los no canvien per art de màgia la jerarquia de les instruccions del menú no protegides per copyright en un assumpte protegit per copyright" -el Tribunal Suprem dels EUA va agafar finalment el cas però no va ser capaç de prendre una decisió: El vot estava dividit 4-4 i la primera decisió va ser la final. 4.2.3 Abast actual del copyright informàtic Què pot tenir copyright. Actualment el copyright protegeix qualsevol programa informàtic original com a obra literal tan si és amb codi font o forma de codi objecte. Per exemple, d'acord amb la directiva del copyright de programari, "Els estats membres han de protegir els programes informàtics, així com treballs literaris dins dels propòsits del Conveni de Berna per a la Protecció de les Obres Artístiques i Literàries". Només l'expressió pràctica original està protegida pel copyright; els elements no literals, idees i la funcionalitat del programa queda fora del copyright. Altrament, el copyright protegeix el programa com un tot i, per tant construeix una base legal natural per a la llicència. Còpia i drets de distribució. L'essència del copyright és donar a l'autor un dret exclusiu per a la còpia i distribució de l'obra.241 Dins del context d'un programa informàtic, normalment no ha estat productiu intentar definir una diferència entre copiar i distribuir ja que la distribució normalment inclou copiar (per tant, la distribució és una subcategoria de la còpia). Malgrat tot, moltes llicències de codi obert estableixen un límit. Permeten copiar però en restringeixen la distribució. I el motiu és que copiar pot ser en alguns casos necessari per utilitzar el programari i el codi obert no restringeix específicament el simple funcionament del programari. A més, s'ha de destacar que el copyright no protegeix l'ús de programes en general. Les lleis acostumen a relaxar-se en els drets exclusius de còpia i distribució. Normalment, les còpies de seguretat i les versions d'execució necessàries estan permeses. A més, tot i que de manera molt més controvertida, podria ser legal distribuir una còpia del programari obtinguda legalment a un nou usuari d'acord amb la doctrina de la primera venda.242 Dret de modificació. El dret de modificar un programa és potser el més important i controvertit en moltes llicències de codi obert.243 Algunes llicències col·loquen la restricció no a la còpia o a la distribució del programa en sí, sinó simplement a la distribució de les modificacions. La norma general és que qualsevol que vulgui modificar una obra, necessita el permís del titular del copyright. En el cas del programari, el modificador i l'autor original acostumen a compartir el dret d'un codi font modificat.244 En el desenvolupament del codi obert, el tema crucial normalment és saber si cert mètode d'usar els programes existents com a base d'un de nou s'hauria de considerar una modificació del ja existent (i subjecte al control de l'autor original) o la creació d'un treball nou completament diferent. Drets morals. Finalment, els drets d'autor inclouen els anomenats components morals, entre els quals els més importants i acceptats universalment són atribució i reputació.245 Atribució significa que l'autor té el dret que se li reconegui l'autoria. Així doncs, treure el nom de l'autor d'una obra seria infringir el dret d'atribució. La reputació significa, de manera molt general, que l'obra no pot ser modificada, alterada o usada de cap manera que pogués perjudicar la reputació de l'autor.246 Per exemple, una modificació intencionada per reduir la qualitat d'un programari de codi obert conegut amb molts errors de programació afegits podrien infringir aquest dret.247 Responsabilitat legal. Encara que les normes de responsabilitat legal del copyright no han estat harmonitzades amb la llei fonamental dels els acords internacionals, l'estàndard de responsabilitat legal és de manera uniforme responsabilitat legal estricta. Això vol dir que el titular del copyright té una causa per acció contra qualsevol que infringeixi aquest dret sense tenir en compte si la infracció ha estat intencionada o no i, ni tan sols, si prové d'una empresa o d'individus. La intencionalitat i l'interès econòmic pot ser que només afectin la quantitat de danys i la compensació adjudicada al titular del copyright.248 4.3 El retorn de les patents Després del debat sobre interoperabilitat no tothom va acceptar que la protecció legal del programari fos una àrea legal resolta; el copyright només havia mostrat els seus límits. Alguns acadèmics van proposar la reconsideració del plantejament sui generi però mai no van arribar a proposar cap normativa real.249 En canvi, l'ús creixent de les patents va acabar dominant el debat sobre regulació de la propietat intel·lectual de programari 4.3.1 L'exemple dels EUA Tot sovint es creu que el cas del Tribunal Suprem dels EUA Diamond contra Diehr va provocar el 1981 l'inici d'una creixent concessió de patents de programari als Estats Units. En aquest cas, el judici va dictaminar que:250 "Una demanda pel tema en qüestió reglamentària no esdevé irreglamentària pel simple fet que utilitzi una fórmula matemàtica, un programa informàtic, o un ordinador digital." Tal com hem destacat, hi havia una sèrie de patents de programari atorgades abans d'aquest cas en particular, però els casos judicials anteriors no les havien considerat vàlides. Després del cas Diamond, es considerava de manera més general que el programari era patentable tot i que el cas va deixar alguns punts oberts a interpretació. És clar que si l'invent només consistia en un algoritme matemàtic, no era patentable. Malgrat tot, casos judicials posteriors han deixat de banda els problemes d'interpretació abstracta a favor d'una patentabilitat de programari més extensiva.251 Per tant, el 1996, la USPTO va publicar unes directrius més liberals per a l'examinació i atorgament de patents de programari. Les pautes bàsicament deien que s'havia de determinar l'utilitat d'un invent com un tot amb una valoració detallada per veure si l'invent es basa únicament en un algoritme matemàtic abstracte:252 "El personal de l'Oficina ja no començarà el reconeixement determinant si una demanda recita un "algoritme matemàtic". En canvi, revisaran l'especificació completa, incloent-hi la descripció detallada de l'invent, qualsevol símbol que s'hagi revelat, les demandes i qualsevol utilitat específica que s'hagin declarat per a l'invent." La patentabilitat de programari va rebre respostes de tot tipus des del sector de programari dels EUA. En una audiència pública el 1994, empreses com Oracle, Adobe i Autodesk es van oposar a la patentabilitat mentre que IBM, Microsoft o SUN hi estaven a favor, o bé incondicionalment, o bé proposant millores per augmentar la qualitat de les patents. 253Poc després cap a finals dels noranta, quan ja era normal una patentabilitat de programari més extensiva, les empreses es van posar a adoptar posicions públiques més favorables envers les patents i van començar a omplir les seves pròpies carteres de patents. 254 4.3.2 Europa segueix El Conveni Europeu de Patents i la seva pràctica d'interpretació. A l'altra banda de l'oceà, les patents de programari es van quedar més temps a la perifèria. El Conveni Europeu de Patents es va signar el 1973 i declarava que els programes informàtics no eren patentables "com a tals". D'una banda, hi havia la necessitat de claredat legal però, per l'altra, es considerava important que no es perjudiqués el desenvolupament d'una nova indústria per unes definicions massa estrictes i la denegació categòrica de les patents de programari. 255Les primeres pautes de reconeixement de l'Oficina de Patents Europea del 1978 no regulaven les patents de programari però declaraven amb cautela: "Un programa informàtic pot tenir molts formats, per exemple, un algoritme, un diagrama de flux o una sèrie d'instruccions codificades que poden ser gravades en cinta o altres mitjans de gravació, i es pot considerar un cas particular d'un mètode matemàtic ... o d'una presentació o informació... Si la contribució a l'art conegut està únicament en un programa informàtic, llavors l'assumpte no és patentable sigui quina sigui la manera en què s'hagi presentat en la petició. Per exemple, la petició per un ordinador caracteritzat per tenir el seu programa particular guardat a la memòria, o per un procés per fer funcionar un ordinador sota el control del programa presentaria les mateixes objeccions que una petició pel programa per se o pel programa un cop gravat en una cinta magnètica." Seguint les reformes introduïdes als Estats Units durant els anys 80, l'Oficina Europea de Patents va començar a acceptar d'una manera més oberta sol·licituds per a patents de programari. L'any 1986, i de manera similar al cas de Diamond contra Diehr, l'EOP va dictaminar que es podia patentar qualsevol aplicació de tipus industrial introduïda en un programa informàtic, així com el maquinari necesari per al seu funcionament, fins i tot en el cas que la modificació només tingués efecte sobre el programa informàtic en qüestió. 256De manera molt semblant a com havia succeït a In Re Alappat , l'EPO va anar encara més enllà l'any 1998 i va advertir:257 ”...a la patent es podrà atorgar no solament en el cas d'una invenció on una aplicació informàtica que gestioni un procés industrial o funcionament d'un producte mecànic determinat mitjançant un ordinador, sinó també en qualsevol cas on un programa informàtic determinat sigui l'únic mitjà, o un dels mitjans necessaris, per obtenir un resultat tècnic determinat... com per exemple un cop s'hagi assolit el resultat desitjat mitjançant el funcionament normal de l'ordinador sota la influència del programa en qüestió." En altres paraules, el "resultat tècnic" necessari per a qualsevol millora introduïda mitjançant un ordinador no requeria cap entorn maquinari. Amb aquesta decisió, no és difícil imaginar que el programari "com a tal" sigui efectivament patentable, en contra del que l’EPC diu literalment. Com a mínim queda palès que, a la pràctica, les patents de programari mai no han estat prohibides a Europa i, a més, que la pràctica de concedir patents no té diferències fonamentals amb la dels Estats Units. Debat polític recent Durant una conferència diplomàtica celebrada a finals de l'any 2000, es va considerar que havia arribat el moment de definir el codi de conducta de l'EPO i eliminar-ne el llenguatge del tipus "com a tal". Per a sorpresa de molts, aquest tipus de llenguatge no va ésser eliminat durant la conferència. Els programadors independents, algunes empreses de programari i els defensors entusiastes del programari lliure van organitzar-se per lluitar en contra del canvi i, finalment, van aconseguir convèncer la majoria dels membres de l'EPC que refusessin la proposta.258 La Comissió Europea, mentrestant, ja havia començat a preparar el terreny per a l'harmonització de les legislacions nacionals referents a les patents de programari.259 Després d'un període de consultes, la Comissió va publicar una proposta de directiva l'any 2002 amb la qual pretenia clarificar que el programari era evidentment patentable a Europa però de manera limitada.260 A continuació hi va haver un debat públic intens que va involucrar activistes a favor del codi obert, altres individus i empreses petites de programari que s'oposaven a qualsevol mesura referent a la patentabilitat del programari. Moltes empreses importants de programari i de telecomunicacions, així com els advocats especialitzats en patents i d'altres especialistes en propietat intel·lectual, al contrari, van recolzar de forma pràcticament incondicional la patentabilitat dels programes informàtics. Es van encarregar una sèrie d'estudis per examinar els possibles costos i beneficis en matèria pública derivats de la introducció de les patents de programes informàtics.261 Els qui s'oposaven a aquesta mesura van sortir victoriosos durant la primera lectura de la proposta de la directiva que va tenir lloc al Parlament l'any 2003 i s'hi van votar esmenes substancials. Es va clarificar, per exemple, que qualsevol operació mitjançant programari destinada a facilitar la interoperabilitat del sistema, no constituïria en cap cas un delicte de violació de la patent. D'igual manera, tampoc el processament de dades mai no podria ser considerat com a constitutiu d'un delicte de violació de la patent. A més, també va establir que "el processament, manipulació, i presentació d'informació no pertanyen a cap camp tècnic, encara que s'utilitzin aparells tècnics amb tal finalitat". Els vents, no obstant, van canviar de rumb ràpidament ja que el Consell de ministres va afavorir l'any 2004 el lobby propatents. Va eliminar pràcticament tots els canvis introduïts pel Parlament i va modificar la directiva amb la finalitat d'acceptar clarament els mecanismes que l'EPO havia fet servir des dels anys noranta. En el moment de la redacció d'aquesta publicació, la directiva es troba encara pendent que el Parlament en faci una segona lectura. És possible que s'hi produeixin canvis. El debat mantingut a nivell europeu ha diferit en molts aspectes del que s'ha donat als Estats Units. Als Estats Units, les crítiques envers la patentabilitat s'han concentrat en aspectes relacionats amb qüestions d'innovació i d'inventiva i no en la limitació categòrica de la patentabilitat dels programes informàtics (pròpies del tipus del llenguatge "com a tal"). Els aspectes relacionats amb l'ús de les patents, com la normativa de competència, límitacions en la responsabilitat legal, i interpretacions de les peticions de patent, s'han convertit, a la llarga, en qüestions molt més rellevants que no pas els criteris de patentabilitat. És possible que, un cop hagi finalitzat el procés de ratificació de la directiva, el debat a nivell europeu torni a anar a cavall del dels Estats Units i passi a criticar el sistema de patents en la seva totalitat. 4.3.3 Normativa internacional Les pressió exercida pels Estats Units i vàries organitzacions de comerç ha forçat molts països d'arreu del món a establir lleis sobre patents d'acord amb la realitat, que proporcionin, per exemple, protecció legal per a les innovacions en matèria farmacèutica. El programari ha vingut a continuació. Els crítics sostenen que els mercats de programari es diferencien significantment dels farmacèutics. Atès que el desenvolupament de programari no acostuma a ser intensiu en inversió financera, fins i tot les empreses del països en vies de desenvolupament poden convertir-se en desenvolupadors destacats. Això ens du a preguntar-nos: quina possibilitat hi ha que cada país tingui una normativa específica en relació a les patents de programari? Els acords sobre els Drets de la Propietat Intel·lectual Relacionats amb el Comerç (Treaty on Trade Related Aspects of Intellectual Property Rights, TRIPS) signat el 1994 com a part de les negociacions de la Ronda d'Uruguai de l’Organització Mundial del Comerç (OMC), estableixen un nombre limitat de requisits per al desenvolupament de lleis nacionals sobre patents. L'Article 27 del Tractat estableix que: "... es podran atorgar patents a aquelles invencions de productes o processos en qualsevol camp tecnològic sempre que siguin noves, impliquin un procés creatiu i siguin susceptibles d'aplicació industrial". S'ha debatut freqüentment si l'aplicació de l'article 27 depèn de l'acceptació, per part de tots els països, de les patents de programari.262 No sembla que hi hagi res en la formulació de l'article que posi límit a la protecció de la patent del programari. No és senzill, no obstant, fer una interpretació detallada d'aquest article. Es pot tornar al punt de partida i preguntar-se sobre com es pot definir una invenció de programari. De fet, es pot inventar el programari? Són les invencions de programari susceptibles de tenir "aplicació industrial"? Evidentment, el TRIPS es pot utilitzar com a argument per ampliar la protecció de les patents de programari i, tot i això, encara deixa prou espai per a un bon debat sobre política econòmica que tingui en consideració els interessos de la indústria local de programari així com els dels consumidors. La patentabilitat de programari tan pot ser d'abast ampli com limitat. Als Estats Units, com a exemple extrem, el camp de les invencions patentables s'ha anat estenent gradualment des del programari fins a incloure "pràctiques de negoci" i altres idees encara més abstractes. 4.3.4 Abast actual de les patents de programari Patentabilitat. Només poden ser patentades aquelles invencions que siguin noves, impliquin un procés creatiu i siguin susceptibles d'aplicació industrial. A Europa, les invencions han de tenir en compte, a més, les seves repercussions tècniques. Com és habitual en aquestes definicions legals, els criteris de patentabilitat estan oberts a tantes interpretacions com lectors.263 La llei de patents dels EUA no menciona aplicacions de programari ni programes informàtics. El Conveni Europeu de Patents sí que ho fa però, com hem esmentat anteriorment, no limita categòricament a la pràctica la patentabilitat del programari.264 S'ha estès la creença que l'Oficina Europea de Patents ha acceptat milers de patents, que poden ser interpretades com a "pures" patents de programari. 265 Tot i que hi hagi moltes similituds entre els criteris de patentabilitat emprats als Estats Units i a Europa, també hi ha algunes diferències. Per això, és pertinent que es tingui en compte que les patents dels Estats Units no tenen validesa legal a Europa i viceversa. Per tant, si les invencions creades a partir de programari són més fàcilment patentables als Estats Units, aquestes només haurien de tenir validesa als mercats dels EUA. Així mateix, les implicacions de les patents per al desenvolupament del codi obert haurien de tenir una dimensió local. Drets i excepcions. La possessió d'una patent atorga a l'innovador un dret exclusiu sobre l'ús comercial de la seva creació. Així doncs, per exemple, no està permesa la fabricació, el màrqueting o la venda d'un producte que inclogui, o utilitzi de manera indirecta, la invenció patentada. A la pràctica doncs, la patent cobreix una sèrie d'activitats molt més àmplia que no pas el copyright. L'abast legal precís d'una determinada patent depèn de les afirmacions (o més exactament de la seva) que es facin a la sol·licitud de patent. Les lleis de patents també acostumen a incloure un gran nombre d'excepcions sobre l'ús no comercial o destinat a la recerca, així com del que se'n pugui haver fet anteriorment. Aquest darrera excepció implica que qualsevol innovador anterior que no hagi sol·licitat cap patent, podrà seguir fent ús de la seva innovació sense preocupar-se del que estableixi la llicència, encara que, no li estarà permès ampliar-ne l'ús comercial. Responsabilitat legal. Com succeeix amb el copyright, el nivell estàndard de responsabilitat legal per violar una patent és de caire estricte. Una diferencia clau, però, és el fet que els drets derivats de la patent només poden aplicar-se sobre l'ús comercial de la innovació, i per això la infracció no comercial i individual de la patent pot quedar exempta de responsabilitat legal. 266 La quantitat a pagar en concepte de compensació per la infracció dependrà de la intencionalitat o no intencionalitat de l'infractor. 4.4 Protecció tècnica Tant en el cas del copyright com en el de les patents, els problemes derivats de la seva aplicació pràctica han donat lloc a l'establiment de mercats per als diversos sistemes d'autoprotecció tècnica. A pesar de les esperances posades i de les recents iniciatives, les mesures adoptades en referència a la protecció contra el plagi encara no han estat capaces d'oferir solucions a l'aplicació legal pràctica de les lleis referents a la propietat intel·lectual. 4.4.1 Primers sistemes de protecció de còpia Es van desenvolupar diferents mètodes tècnics per imposar restriccions sobre l'ús del programari just després que es comencessin a formar els primers mercats empresarials de productes de programari.267 Més tard, amb el desenvolupament dels mercats massius de programari als anys 80, els productors de programari van començar a utilitzar de manera extensiva els diversos mecanismes de protecció contra còpia per tal d'evitar les còpies il·legals.268 Moltes de les primeres tècniques per a la protecció contra còpia es basaven en trucs realitzats amb el maquinari. Per exemple, el popular programa de full de càlcul Lotus 1-2-3 feia servir el següent sistema: " Per poder utlitzar-lo, el programa requeria que l'usuari executés l'arxiu 123.EXE on s'hi incloïa la informació de l'usuari. No obstant, aquest mètode d'inicialització només es podia dur a terme en el disc de sistema original. Resulta que el disc de sistema conté una pista formatada a tal efecte que ha de ser present a fi de poder dur a terme la inicialització (aquesta pista és esborrada pel programa d'instal·lació un cop s'ha inicialitzat el disc, el que fa el que el procés sigui irreversible."269 Els sistemes de protecció contra còpia no van solventar, no obstant, el problema del pirateig de copyright. En canvi, els compradors de programari es van molestar perquè els sistemes de protecció contra còpia posaven en perill la funcionalitat del programa.270 Per exemple, quan es va estendre l'ús del disc dur i els sistemes de protecció contra còpia impedien la instal·lació de programari en el disc dur, les proteccions contra còpia també impedien les còpies de seguretat. "D'aquesta manera va nèixer el programari d'eliminació de sistemes de protecció contra còpia que tenia com a objectiu original permetre als propietaris de programari legal fer còpies de seguretat legals dels seus programes. En una època on qualsevol processador de textos, full de càlcul, o qualsevol altre programa informàtic costava 495$ o més, comprar una altra còpia quan algun dels discs originals es feia malbé era massa costós i molts refusaven pagar a les empreses de programari imports de fins a 25$ PER CADA DISC de recanvi. Preferien comprar un producte menys costós."271 Al final, cap de les iniciatives impulsades en relació a la protecció contra còpia, ja fossin aplicades al maquinari o al programari, no va tenir prou èxit com per convertir-se en l'estàndard. El paper dels sistemes de protecció contra còpia va ésser revalorat per aquesta raó i moltes de les grans empreses de programari van decidir no fer-ne servir cap. 272 Com que els mercats de sistemes de protecció contra còpia havien desaparegut molt abans dels anys noranta, la indústria del programari va haver de començar a tolerar un cert nivell de còpia il·legal. 4.4.2 Legislació antipirateria Un cop més, la legislació es quedava enrere dels desenvolupaments esdevinguts en els mercats. Un cas del 1988 va establir que els sistemes de protecció contra còpia no gaudien de cap protecció legal als Estats Units. 273No obstant, ja al 1991 la directiva europea sobre productes informàtics va adoptar un nou criteri legal que establia que és il·legal eludir les proteccions de còpies tècniques.274 Els Estats Units van seguir l'any 1998 amb la implementació del Digital Millennium Copyright Act.275 Aquesta darrera llei en especial estava vinculada a l'arribada d'una certa dèria en la indústria dels mitjans de comunicació per la protecció contra còpia. 276 Amb la nova designació de "gestió de drets digitals", es van introduir els sistemes de protecció contra còpia en els diferents formats, des dels discos de CD i DVD fins a vídeos i jocs distribuïts digitalment. En alguns casos, aquests sistemes de protecció contra còpia també han estat fracassos, com en el cas dels sistemes de protecció contra còpia dels anys vuitanta. Un bon exemple és el sistema de protecció contra còpia utilitzat en els CD a principis dels 2000 que a la pràctica qualsevol usuari podia eludir. Atès que aquests sistemes de protecció només van contribuir a dificultar l'audició dels CD per part dels compradors de música, les empreses discogràfiques van haver de deixar d'utilitzar-los. Les proteccions contra còpia de DVD han tingut una vida més llarga tot i que aquests formats ja comencen a tenir maneres d'eludir proteccions amb programes fàcilment aconseguibles. 4.4.3 És efectiva la protecció tècnica? Una qüestió bàsica i compartida per tots els sistemes de protecció contra còpia és saber de qui és el comportament que aquests sistemes poden controlar. Sembla ser que diferents grups d'usuaris tenen capacitats i interessos diferents a l'hora d'eludir sistemes.277 Els sistemes basats en programari potser funcionen contra els usuaris normals, podríem dir. Però els usuaris amb drets d'administrador, aquells que són capaços de configurar els seus ordinadors i aparells de reproducció digital més enllà dels manuals, sempre podran trobar cracks a Internet. La legislació que prohibeix l'ús i distribució d'aquests tipus de programes cracks no ha tingut un efecte significant en la seva disponibilitat. Finalment, aquelles invencions que funcionen en un entorn de maquinari, poden fer que el sistema deixi for a de joc els usuaris amb poders d'administrador.278 Però fins ara sempre hi ha hagut crackers professionals que, de fet, han competit entre ells per tal de provar qui és el primer en eludir els darrers sistemes de protecció contra còpia ja sigui en entorn de maquinari o programari.279 Taula 6. Capacitats dels usuaris i sistemes tècnics de protecció contra còpia 4.4.4 La promesa dels sistemes de confiança A pesar d'aquest malaurada història, encara n'hi ha que pensen que els sistemes de protecció contra còpia tornaran i s'imposaran algun dia. Un dels arguments està basat en la idea de la informàtica fiable (trusted computing), que planteja que en el futur tots els ordinadors personals disposaran d'un sistema de seguretat basat en l'entorn maquinari que permetrà, entre altres funcions, la protecció contra còpia. Aquest és l'argument que proposen els membres del Trusted Computing Group (que inclou IBM, HP, Microsoft, SUN, Sony, Intel and AMD), i al que s'han oposat amb molta força aquells activistes d'Internet que fan campanya en favor dels drets de l'usuari i de la privadesa personal. 280 Un altre argument diu que, en el futur, les creixents prestacions ofertes pels aparells portàtils i consoles de joc amb programari integrat, rebaixaran de manera substancial la participació de mercat dels PC d'ús general. Una preocupació dels desenvolupadors de codi obert és el fet que si qualsevol de les propostes d'informàtica fiable es convertís en l'estàndard, significaria que els usuaris ja no podrien tenir accés il·limitat al seu propi sistema. Seria possible construir sistemes de protecció contra còpia que fossin efectius tant entre els grups d'usuaris normals com amb els que tenen poders administratius. Aquest tipus de sistema de confiança podria, a més, requerir a la pràctica que el programari en qüestió hagués de ser validat per tercers, els quals podrien no preferir el codi obert. 281 4.5 Estan desequilibrades les lleis de propietat intel·lectual? Es podria dir que la contínua expansió de les diverses lleis de propietat intel·lectual de programari que se solapen entre elles, implica que la llei està avui dia desequilibrada. Però, és aquest realment el cas? Pot ser que el codi obert equilibri aquesta tendència expansiva? 4.5.1 Principi d'equilibri Interessos en conflicte. Un dels principis fonamentals que regeix les lleis de propietat intel·lectual és l'objectiu d'equilibrar els interessos dels propietaris de drets i el públic en general. D'una banda, l'existència d'un poder de monopoli absolut amb drets exclusius i il·limitats molt probablement restringiria l'accés a la cultura i acabaria amb qualsevol d'innovació. De l'altra, l'existència de drets exclusius limitats podria justificar-se amb principis utilitaris (segons la teoria d'incentius) i filosòficomorals (el dret d'un individu a gaudir de la seva creació personal). Domini públic contra regulació. Des d'una perspectiva pràctica, la protecció de la propietat intel·lectual pot interpretar-se com a arbitrària ja que, en cas de no existir lleis de copyright o patent, qualsevol informació o coneixement podria ser lliurement replicat, desenvolupat o utilitzat per qualsevol. Així mateix, la pròpia natura del programari com a forma d'informació digital replicable fa que sigui impossible de controlar-ne la còpia a menys que hi hagi una regulació explícita. Per això, qualsevol aspecte o parts dels productes de programari on no arriba la regulació de la propietat intel·lectual queden efectivament lliures per al seu ús per a qualsevol altre propòsit. En efecte, ni el copyright, ni la patent, ni qualsevol altre dret de propietat intel·lectual cobreix els aspectes del programari en la seva totalitat. Per exemple, el copyright no s'aplica a aquelles parts del codi obert que tinguin una sola aplicació pràctica, no cobreix els aspectes funcionals d'un producte de programari vigent i, a més, el mateix copyright inclou excepcions per usos particulars d'obres que d'altra manera estan regides pel copyright. Les patents estan limitades només a aquelles parts del programari que introdueixin una innovació, típicament un algoritme en codi font o altres subparts evidentment separables del producte de programari sencer. També hi ha excepcions en el cas de les patents. 4.5.2 Tendència d'expansió Equilibri implicit. Des d'una perspectiva històrica, les lleis sobre la propietat intel·lectual han anat sempre per darrere dels desenvolupaments tecnològics. Això mateix ha passat amb el programari. Fins als anys setanta, les qüestions legals referides al desenvolupament de programari eren rarament tingudes en consideració, ni tan sols per les empreses més grans del sector.282 En els primers mercats corporatius, on cada usuari signava un contracte apart, i les possibilitats dels usuaris de copiar el programari i beneficiar-se'n de la còpia eren limitades, la forma legal preferida (en cas de ser necessària) per protegir els secrets del programari era la llei del secret comercial. En aquells moments no era encara prou clar si el copyright i les patents eren d'alguna manera aplicables al programari. És important, no obstant, tenir en compte que la indústria va assolir de manera força eficaç l'objectiu de la llei de propietat intel·lectual de crear, sense necesitat de cap regulació legal explícita, nous productes i innovacions beneficiosos tant per a la societat com per als creadors i innovadors individuals. Regulació explícita. La llei del copyright va ser explícitament revisada des de principis dels anys vuitanta per incorporar-hi els productes de programari al detall. Econòmicament parlant, els rendibles mercats massius de programari dels anys vuitanta requerien diferents mitjans de protecció legal, i els models de copyright com el del llibre i el disc van ser molt útils en aquest sentit. El tema de les patents va tornar al punt de mira als noranta quan els límits del copyright es van fer evidents. Ara, la majoria d'empreses importants de programari han adoptat normativa a favor de les patents i han començat a fer les seves pròpies carteres. La Taula 7, a continuació, resumeix els diferents mètodes de protecció emprats en productes de programari en la història del sector. Taula 7. Formes diferents de protecció legal del programari en la història del sector. Alguns dels esdeveniments en matèria de copyright i normativa de patents en la història del sector es resumeixen en la següent cronologia: Figura 11. Evolució del copyright i les patents en la història del sector. El desenvolupament legal en matèria de copyright i patents de programari ha estat poc evident. De fet, la indústria ha experimentat batalles polítiques difícils en quasi bé tots el desenvolupaments legals rellevants, des de l'excepció per qüestió d'interoperabilitat en el copyright, fins al debat més recent sobre l’aplicabilitat i cobertura de les patents de programari. En tot cas, es pot afirmar que la base del copyright de programari és força estable i equilibrada. S'ha d'admetre, no obstant, que actualment les patents s'estan debatent acaloradament. Tot i que el paper de les patents està cobrant força, el seu futur és encara incert. A més d'això, la majoria de les propostes alternatives sobre copyright i patents, des dels sistemes de protecció sui generis fins a la protecció tècnica contra còpia, no han donat el fruit esperat. Està l'equilibri en perill? Alguns comentaristes sostenen que aquest cicle d'expansió ha posat en perill l'equilibri d'interessos que hi ha darrere de les lleis de propietat intel·lectual.283 L'abast dels diversos tipus de drets de propietat intel·lectual s'ha expandit continuadament i arriba a cobrir nous i valuosos aspectes del programari enfortint d'aquesta manera el poder relatiu d'aquells qui poden adquirir i fer ús dels drets. Qualsevol problema potencial es veu multiplicat per l'efecte combinat dels diferents drets. El programari, avui dia, no solament està cobert pel copyright i les patents, sinó també per les lleis de secret comercial, de protecció tècnica, els contractes i les marques comercials. El resultat negatiu d'aquesta tendència envers la protecció és que el copyright i les patents, entre d'altres drets, a la pràctica sovint se solapen. 284 Aquest solapament pot contribuir a més a la fragmentació del problema i ser causa d'immobilitzacions anti-commons gens efectives. Un usuari podria requerir una llicència de múltiples titulars de llicencies i no d'un de sol. Això, òbviament, fa que l'atorgament de llicències sigui més difícil i costós. Com veurem més endavant, aquests solapaments també comporten un risc important pel que fa a les llicències de codi obert.285 L'usuari pot confiar durant més temps en què el programari amb llicència cobreixi tots els possibles drets de propietat intel·lectual, simplement perquè és molt possible que algun tercer desconegut posseeixi, per exemple una patent que cobreixi el funcionament essencial del programari. 4.5.3 El codi obert com a força d'equilibri? El codi obert va entrar en el desenvolupament de normativa legal amb el canvi de mil·leni. Com a mínim, en teoria, el codi obert ofereix un equilibri notable envers els efectes dels drets de propietat intel·lectual. El codi obert enforteix el paper dels autors individuals i usuaris de programari, per sobre dels del propietari tradicional de la propietat intel·lectual i del que concedeix la llicència privativa. Això, no obstant, només fa referència a la forma com s'usen, a la pràctica, els drets de propietat intel·lectual. Els defensors de la normativa de codi obert s'han adonat que les institucions legals formals són molt més difícils d'influenciar que les normes informals de caràcter social i ètic. La primera gran batalla en la qual els defensors d'aquesta normativa han tingut una influència real és en la controvèrsia a Europa en matèria de patents de programari on no està del tot clar que hi prevalguin els seus arguments.286 El codi obert ha portat novament un cert equilibri al debat sobre l'atorgament de patents, i ha significat un contraargument creïble per a aquells que proposen una patentabilitat extensiva a l'estil dels EUA. No s'ha perdut l'esperança que la llei de patents de programari quedi finalment fixada i equilibrada, com ja ho està en gran mesura el copyright de programari. En un àmbit més general i global de la normativa de propietat intel·lectual, és l'Organització Mundial de la Propietat Intel·lectual qui té la paraula. Ha estat criticada per voler forçar amb la seva agenda un principi d'a priori on "com més protecció, millor", sense haver realitzat cap anàlisi econòmica o estudi empíric de la realitat.287 De fet l'OMPI ja va estar a punt d'organitzar una reunió l'any 2003 per debatre el codi obert i els seus efectes sobre la propietat intel·lectual. No obstant, la reunió va ser cancel·lada per pressions de la BSA i l'USPTO. Un representant de l'USPTO va fer públicament un comentari prou revelador en dir que:288 "Mantenir una reunió amb l'objectiu de desacreditar o eliminar aquests drets ens sembla contrari als objectius de l'OMPI" L'any 2004, alguns grups de consumidors i de la societat civil que feien campanya a favor del codi obert entre d'altres, van aconseguir incloure perspectives alternatives en l'ordre del dia de l'OMPI des d'un nou front: aliant-se amb els interessos dels països en vies de desenvolupament. La seva proposta, acceptada per l'OMPI per a una anàlisi més exhaustiva, essencialment va concloure que: 289 "Una visió que fomenti els beneficis absoluts de les mesures de protecció de la propietat intel·lectual sense tenir en compte les preocupacions que puguin existir en matèria de polítiques públiques debilita la credibilitat del sistema de propietat intel·lectual." 4.6 Reflexions finals: Perspectiva oberta sobre la propietat intel·lectual Com ja hem vist, les lleis de propietat intel·lectual han evolucionat fins a cobrir els productes de programari en el més mínim detall. Avui dia, el copyright, les patents i els sistemes de protecció tècnica s'apliquen per tal de regir l'ús dels productes de programari. Però són necessàries aquestes lleis? Aquesta és una pregunta crucial que encara no té resposta. El fet és que el programari tenia llicències abans que existissin copyrights o patents de programari. Així doncs, a la pràctica, l'aplicació de les lleis de propietat intel·lectual no ha tingut un efecte funest sobre la qüestió de les llicències de programari. No obstant, cal vigilar de no confondre copyright i patents. Es pot dir que la funció de les patents en la indústria del programari no ha estat, en primer lloc, la de permetre l'atorgament de llicències. Les patents atorguen als propietaris dels drets la potestat d'excloure altres d'usar el programari. El copyright, a l'inrevés, no garanteix al propietari, a la pràctica, massa poder per excloure d'altres, ja que el copyright només cobreix el codi, i el codi sempre pot ser reprogramat per cobrir la mateixa funció desitjada. No obstant, el copyright permet un cert control sobre la reutilització del codi font. Alguns models d'atorgament de llicències de codi obert es basen en la possibilitat de controlar i fer acomplir el reciclatge. La diferència entre el poder d'excloure i l'opció de controlar el reciclatge del codi font és notable. El primer, basat en les patents, s'aplica a qualsevol producte de programari encara que es tracti de creacions independents. En aquest sentit es considera que les patents van en contra dels principis del codi obert, ja que poden aturar la creació de nous treballs independents. La darrera noció de reciclatge controlat, no obstant, s'ajusta als principis del codi obert. Es pot requerir la publicació del codi font en primer lloc, i aplicar-lo després als derivats directes del codi original. D'aquesta manera, el copyright fa valer els principis del codi obert. De fet, el codi obert està desenvolupant el copyright cap a l'idea original del droit d'auteur.290 El concepte de còpia està desestimat ja que en la retòrica del codi obert el problema de còpia és vist com una cosa del segle XVI. Els drets d'autors, tal com es van desenvolupar originalment a la França del segle XVIII anaven en contra dels propietaris de la premsa escrita que controlaven la reimpressió de còpies. Les impremtes comercials del segle XX -els fabricants de programari, les companyies discogràfiques i similars- van reinventar el concepte de copyright i els drets personals d'autor van acabar als peus de pàgina. Una forma d'entendre el codi obert és veure'l com a promotor dels ideals originals sobre els drets inalienables de l'autor a controlar la integritat i paternitat de les seves creacions personals. Al mateix temps, el codi obert també pretén debilitar el paper de les patents. És per aquesta raó que l'impacte del codi obert sobre la propietat intel·lectual no és gens clar: mentre que alguns aspectes han estat clarament atacats, altres s'han revivificat. 5 Les llicències de codi obert com a mecanismes alternatius de governança Aquest capítol analitza com les llicències de codi obert es basen en les lleis de propietat intel·lectual i reflecteixen les explicacions exposades per la teoria econòmica. S'han categoritzat les llicències i se n'ha analitzat més la funcionalitat. S'han identificat qüestions d'interpretació oberta de la indústria del programari. Finalment, el capítol acaba amb una discussió de contingut obert sobre la manera com les tècniques de llicències de codi obert s'han adoptat per ús en altres obres d'art fora del programari informàtic. 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:291 L'ús lliure, entenent-se que no es permetin restriccions discriminatòries de cap tipus en, per exemple, l'ús comercial, el nombre d'usuaris, o el maquinari.292 Còpia i distribució sense cànons donant a entendre que els honoraris per llicències no són un model comercial viable293 Modificació sense cap cànon.294 No obstant és possible incloure altres condicions sobre les modificacions com el requeriment de publicar totes les modificacions Un codi font obert fàcilment aconseguible, (però no necessàriament gratuït), que és el requeriment pràctic per poder fer modificacions.295 En conseqüència, el secret de fabricació no és una possible mesura per controlar el desenvolupament i la innovació. 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.296 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.297 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.298 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.299 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. 300 É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.301 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. 302 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:303 Condició de reciprocitat estàndard significa que s'han de respectar les condicions de distribució del codi font. Aquests tipus de llicències habitualment s'anomenen llicències copyleft. Si el codi font es desenvolupa encara més, no es podran canviar les condicions de la llicència ni es podrà tancar el codi font. No obstant, si es combina el codi font amb un altre codi font per fer un nou producte, l'obligació de reciprocitat estàndard no tindrà efecte sobre aquesta nova creació. La condició de reciprocitat forta amplia la condició de reciprocitat estàndard: Fins i tot les adaptacions i les obres derivades han de conservar intactes les condicions de la llicència. Aquestes llicències es poden descriure com a copyleft fort o, segons com s'analitzin, com a causants d'un "efecte viral".304 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 corporativa va 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.305 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.306 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.307 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: 1.Obres derivades: Quin tipus d'obligació de reciprocitat té la llicència, en cas de tenir-ne? 2.Patents: Com tracta la llicència les patents de programari? 3.Compatibilitat: És la llicència compatible amb altres llicències? 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.308 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".309 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. 5.2 GNU GPL i reciprocitat forta 5.2.1 Obres derivades en la llei de copyright 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,310 i en alguna forma inclou una part de l'obra amb copyright.311 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". 312En 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.313 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.314 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. 315D'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. 5.2.2 Obres derivades i la GPL 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:316 "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.317 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. 318 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.319 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. 320Per 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. 321 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.322 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...".323 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.324 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.325 El 2003, Torvalds també va explicar el següent:326 "- 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.327 Ò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).328 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".329 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.330- Més endavant, tornem a tractar el problema de l'obligació d'ús de xarxa amb la Llicència de Programari Obert. 5.2.3 Les patents i la GPL 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. 5.2.4 GPL i compatibilitat de llicència 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".331 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. 332 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.333 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:334 "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"335 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. 5.2.5 Altres Llicències amb Reciprocitat Forta 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.336 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.337. 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".338 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 patent es 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ó).339 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.340 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.341 "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.342 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.343 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):344 "... 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.345 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. 5.3 GNU LGPL i reciprocitat estàndard 5.3.1 Funcionalitat LGPL La GNU LGPL (Llicència Pública General Menor) és diferent que la GPL en funcionalitat. En primer lloc, té només l'obligació de reciprocitat estàndard. Això significa que les modificacions directes del propi programari LGPL han de redistribuir-se conforme a la LGPL (o GPL), però les combinacions de programari de LGPL amb altres programaris poden distribuir-se fins i tot amb condicions de llicències privatives. La llicència està adreçada especialment a les biblioteques de programació. A la condició 6 s'explica el següent: "... també pots combinar o vincular una "obra que utilitza la Biblioteca" amb la Biblioteca per produir una obra que contingui parts de la Biblioteca, i distribuir aquesta obra d'acord amb les condicions que vulguis". Sembla que l'única condició necessària per a enllaçar és que els usuaris sempre puguin modificar la biblioteca. Per tant, el codi font d'una biblioteca basada en una llicència LGPL ha de tenir instruccions disponibles, per separat, que expliquin com reenllaçar la biblioteca amb el programa principal.346 A la pràctica, l'arquitectura d'un programa principal de font tancada pot necessitar un nou disseny per poder reenllaçar amb el codi font LGPL independentment del programa principal. Altrament, la LGPL es pot comparar amb la GPL quant a la seva funcionalitat. La clàusula de patent és semblant i, en general, el llenguatge de la llicència és una còpia quasi exacta de la GPL. Per tant, no es necessari mencionar altres característiques. En termes generals, les llicències amb obligacions de reciprocitat estàndard són més compatibles que aquelles altament recíproques, encara que no estan exemptes de problemes. Si el codi LGPL està vinculat a un treball més extens, les condicions de la llicència del treball esmentat no tindran cap obligació amb la LGPL i, a més, les llicències seran compatibles. Tanmateix, quan un component extern està vinculat a una obra feta amb LGPL, la LGPL serà clarament incompatible amb l'altra llicència si aquesta no permet que la LGPL l'anul·li. A la pràctica, quan es dóna la provisió de reciprocitat, la LGPL és tan incompatible com la GPL: A més, la LGPL ha evolucionat per a adaptar-se millor als criteris del seu desenvolupador, la Free Software Foundation. La primera versió de la LGPL (llicència pública general de biblioteques), el 1991, es recomanava per a totes les biblioteques de programació. El 1999, quan la Free Software Foundation va desaconsellar el seu ús degut a les limitacions de reciprocitat, en va sorgir una nova versió. Richard Stallman va explicar el motiu pel qual es va canviar el nom de la llicència pel de llicència pública general menor:347 "Establir quina és la millor llicència per a una biblioteca determinada és una qüestió d'estratègia i depèn de cada situació. [...] Ara estem intentant que més biblioteques integrin la GPL ordinària. [...] L'ús d'aquest tipus de GPL per part de les biblioteques suposa un avantatge per als desenvolupadors de programari lliure sobre els de programari privatiu: l'accés a una biblioteca que els desenvolupadors privatius no tenen. [...] Quan una biblioteca proporciona una capacitat important i única [...], mitjançant la GPL i limita el seu ús als programes lliures, llavors contribueix que la nostra comunitat faci un gran pas endavant [...] Els projectes universitaris es poden veure influenciats amb facilitat; avui en dia, a mesura que les empreses es plantegin fer el programari lliure, fins i tot alguns projectes comercials podrien experimentar aquesta influència." Malgrat que les intencions de Stallman són comprensibles, poden afectar l'ús de les llicències GNU dins de la indústria del programari en general. L'ús generalitzat de llicències GNU podria significar que, en el futur, les condicions de les llicències canviïn per tal de reflectir els objectius de la Free Software Foundation, la qual cosa no s'adiu amb la indústria pel que fa a la propietat intel·lectual i el negoci del programari. Sens dubte molts usuaris corporatius han redactat llicències recíproques específiques per a la seves empreses. 5.3.2 Altres llicències amb reciprocitat estàndard GPL amb excepció de biblioteca. Com que a la pràctica els enllaços amb LGPL poden ser problemàtics, la FSF té una plantilla d'excepció per a afegir-la a la GPL, que permet tota mena de situacions d'enllaç (tant dinàmiques com estàtiques) sense cap obligació. Això es va publicar per primera vegada al projecte Guile. L'excepció s'usa ara de forma més generalitzada, per exemple al projecte GNU Crypto, com es veu a continuació: "Com a excepció especial, els titulars de copyright d'aquesta biblioteca et permeten enllaçar-la amb mòduls independents per tal de produir un executable, malgrat les condicions de la llicència d'aquests mòduls independents. També et permeten copiar i distribuir l'executable resultant d'acord amb les teves necessitats, sempre que respectis els termes i condicions de la llicència de cada mòdul independent vinculat. Un mòdul independent és aquell que no deriva d'aquesta biblioteca ni es basa en ella. Si modifiques aquesta biblioteca, pots fer extensiva l'excepció a la teva versió, però no hi estàs pas obligats. Si no ho vols fer, només has d'esborrar aquesta condició de la teva versió. En resum, les biblioteques d'enllaç sota GPL amb aquest tipus d'excepció no obligaran ningú a continuar amb GPL La funcionalitat d'aquest tipus de GPL esmenat és semblant a la de la LGPL sense alguns dels problemes d'interpretació Sembla que la variabilitat de llicència no és sempre una bona idea, sobretot si les llicències esdevenen massa complexes. Llicència pública Mozilla. La llicència Mozilla es va crear el 1998 i, en principi, pretenia controlar la distribució del navegador d'Internet de codi obert del Netscape. La podríem descriure com la primera llicència corporativa de codi obert. La MPL inclou una provisió de reciprocitat estàndard en el punt 3.2: «Qualsevol modificació que creïs o contribueixis a fer haurà d'estar disponible en format de codi obert d'acord amb les condicions d'aquesta llicència.» Aquest requisit no afecta les obres derivades i no constitueix una obligació de reciprocitat elevada. El punt 3.7 estableix que: «Pots crear un treball ampliat combinant un codi de protecció amb un altre codi que no compleixi les condicions d'aquesta llicència i pots distribuir-ho com a producte individual. En aquest cas, t'has d'assegurar que el codi de protecció reuneix els requisits d'aquesta llicència.» Una obra ampliada es defineix de la manera següent: «treball que combina un codi de protecció o parts d'aquest amb un codi que no compleix les condicions d'aquesta llicència.» La MPL disposa d'una llicència de patent explícita. En ella, els col·laboradors hi han acordat atorgar als usuaris llicències il·limitades de les seves patents que integrin tot el codi font. La MPL també té una clàusula de defensa de la patent en el punt 8, la qual és, de nou, més completa que la de la GPL. El que pretén és la creació d'una cartera protectora de copyrights independent de la del programari de la MPL. Si el titular d'una patent de tercers emprèn accions legals contra els autors del programa, llavors tots els drets potencialment atorgats al propietari de la patent, quant al programari, es cancel·laran com succeeix amb la Llicència Pública Comuna. En cas que el titular de la patent volgués reconsiderar la situació, disposaria de 60 dies per tal de, o bé retirar la demanda o bé pagar el cànon de la llicència. La MPL torna a tenir problemes d'incompatibilitat greus. Per a ser exactes, la incompatibilitat només es dóna quan el codi font s'integra literalment i s'aplica la provisió de reciprocitat. En aquest cas, la llicència seria incompatible, per exemple, amb totes les llicències que hem analitzat fins ara. GPL, OSL, CPL i LGPL. La incompatibilitat va ser una de les raons per registrar de nou tot el codi font Mozilla amb un projecte de llicència múltiple el 2001:348 «No està clar si es podria demandar amb èxit un desenvolupador per usurpació del copyright amb motiu de les incompatibilitats de llicència observades. Tanmateix, vam decidir registrar de nou el codi Mozilla per tal de contrarestar les incompatibilitats de llicència observades a la GPL i la LGPL. Vam prendre aquesta decisió per eliminar qualsevol incertesa relativa a aquesta qüestió i per resoldre els dubtes dels desenvolupadors que volien utilitzar el codi Mozilla en aplicacions amb un codi prèviament registrat amb GPL o LGPL.» Una decisió com aquesta no ha estat fàcil de portar a la pràctica, perquè el projecte encara tenia molts col·laboradors externs. Després de tres anys, la concessió de la nova llicència encara està en procés.349 D'altra banda, l'exemple del nou registre de Mozilla reflecteix els costos de les incompatibilitats de llicència i la importància de controlar la propietat del drets i prendre decisions de concessió de llicència sostenibles. 5.4. BSD i les llicències permissives 5.4.1. La funcionalitat de BSD 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ó.350 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.351 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.352 Que la llicència superi els quinze anys potser hi té alguna cosa a veure. 5.4.2 Altres llicències permissives 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:353 «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.»354 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. 5.5 Excursió: Llicències de continguts oberts de Creative Commons 5.5.1 Antecedents En els darrers anys, els principis bàsics de les llicències de codi obert també s'han adaptat a unes altres obres amb copyright apart dels programes informàtics. Per tradició, les llicències d'obres artístiques com ara la música i la pintura (els continguts, en definitiva) han estat dirigides per societats que acumulen copyrights. No obstant això, els autors individuals poden distribuir els seus treballs per Internet directament als usuaris. De la mateixa manera, les expectatives dels usuaris de copiar, modificar i distribuir treballs per Internet poden ser molt diferents de les del món físic. Això ha donat una oportunitat per a les noves iniciatives de registre de llicències. És difícil calcular la popularitat de les diverses llicències de contingut obert, perquè s'utilitzen des de fa molt poc. Sembla evident, tanmateix, que la quantitat de projectes de contingut obert d'alta qualitat augmenta ràpidament.355 La iniciativa amb registre de llicència més popular fins ara ha estat Creative Commons (CC).356 El projecte CC va començar el 2001 com a iniciativa per regularitzar les condicions més liberals de la llicència quant a contingut. Oficialment, CC és una empresa sense ànim de lucre amb seu a Massachusetts que té uns quants empleats treballant a la Universitat de Stanford, a Califòrnia, i una quantitat innumerable de voluntaris que contribueixen al projecte a través d'Internet. Les principals universitats dels Estats Units defensen des d'aleshores CC amb el professor de dret de la universitat de Stanford, Lawrence Lessig, com a figura destacada.357 Les primeres versions de les llicències es van publicar pel desembre de 2002 i les noves versions actualitzades 2.0 pel maig de 2004. El nombre de pàgines web i de continguts que utilitzen llicències CC a Internet està augmentant.x358 Aquest apartat tracta breument les característiques principals de les llicències CC i l'organització del seu projecte. Hi trobem moltes similituds, però també diferències evidents amb el codi obert. L'anàlisi següent intenta determinar alguns dels límits quan els principis de codi obert es generalitzen fora del terreny de la indústria del programari. 5.5.2 La funcionalitat de Creative Commons A la pràctica, CC funciona com a servei d'Internet per a la creació de llicències amb copyright quant a contingut. Els usuaris seleccionen uns quants paràmetres i, llavors, poden accedir a les llicències més adequades. Les llicències tenen tres apartats: 1) descripció dels drets tècnics, 2) text detallat de les llicències legals i 3) breu explicació del que vol dir la llicència. Hi ha una bona quantitat disponible de llicències CC diferents. Per tant, els treballs publicats estan enllaçats amb la llicència seleccionada que es localitza a la pàgina web de CC. Condicions de la llicència. Totes les llicències CC tenen una estructura semblant que inclou condicions comunes per a totes les llicències i les condicions específiques seleccionades. En termes generals, totes les llicències CC autoritzen la còpia, distribució i representació i projecció públiques del treball sense pagar cap mena de cànon de llicència. Dit d'una altra manera, les llicències donen drets als usuaris sense cap obligació. Els treballs sota CC poden ser usats, copiats i, fins i tot, distribuïts sense autoritzacions addicionals ni cànon de llicència. A més, les condicions comunes de CC estableixen que les llicències no han d'interferir amb els drets d'ús adequat (com ara citacions, ús privat, etc.), primera venda o llibertat d'expressió. A més, les condicions comunes estableixen que els treballs no es poden usar amb sistemes digitals de gestió dels drets, ja que poden limitar alguns dels drets atorgats en les llicències com, per exemple, l'ús adequat, la primera venda o la llibertat d'expressió. A més de les condicions comunes, totes les llicències CC poden integrar una o més de les condicions específiques intercanviables que limiten fins a cert punt l'ús d'aquests treballs. Figura 16. Condicions possibles amb logotips afins en les llicències CC. Addicionalment, pensem que hi ha moltes llicències CC específiques i s'espera que el nombre vagi en augment. En aquesta breu digressió, només podem examinar-ne de manera resumida algunes de les més interessants.359«Domini públic» i «copyright del fundador» proposen un venciment més curt pel copyright: el domini públic caducaria immediatament i el copyright del fundador als catorze anys.360 Les llicències de programari de codi obert més populars, GNU GPL i LGPL, estan disponibles a Creative Commons com a CC-GPL i CC-LGPL. Tècnicament, aquestes llicències externes estan enllaçades amb la pàgina web de la Free Software Foundation, i CC només afegeix al treball símbols CC, el resum de la llicència i la descripció tècnica dels drets. Comparació amb el codi obert. Malgrat que CC i el contingut obert en general tenen molt a veure amb el codi obert, també existeixen algunes diferències. Per exemple, els mateixos autors de programari han redactat moltes llicències famoses de codi obert. Han codificat la cultura de compartició actual dels programadors informàtics i, per això, no ha estat gaire necessari aplicar les llicències de codi obert. Al seu lloc, CC ha efectuat una aproximació vertical descendent estricta. Es va fundar una entitat específicament per preparar i promoure les llicències amb molta cura.361 Això pot afectar a la interpretació de la llicència: no hi existeix, al menys de moment, cap tipus de normes comunitàries com en el cas de les llicències de codi obert.362 També és interessant destacar que la major part de les llicències CC estan explícitament en contra de la definició de codi obert quant a la restricció, per exemple, de l'ús comercial de les obres.363 5.5.3 Assignació de riscos i garanties Ja hem mencionat abans que la llicència de programari obert es diferencia d'altres llicències de codi obert en què ofereix una garantia contra la vulneració de la propietat intel·lectual. Les primeres versions de llicències CC també inclouen una clàusula que trasllada la responsabilitat de les reclamacions de la propietat intel·lectual de tercers sobre el llicenciador original. I estipulen que: «Si el que concedeix la llicència divulga el treball de manera pública, llavors, representa i garanteix que [...] 1) Ha inclòs en el treball tots els drets necessaris per garantir els drets de la llicència [...] sense que hagis de pagar cap cànon [...] 2) El treball no vulnera el copyright, les marques registrades, els drets de publicitat, els drets legals comuns ni cap altre dret de terceres parts. I tampoc no constitueix difamació, violació de la intimitat ni cap altre dany a tercers.» Els qui es beneficien d'aquesta mena de clàusula de garantia són, per exemple, els diversos intermediaris i proveïdors que poden utilitzar els treballs registrats i distribuir-los més endavant amb menys riscos. Si es vulneren el drets de terceres parts, l'autor és responsable en última instància d'aquesta violació. Desgraciadament, una clàusula de garantia així no és a prova de bales. Si l'autor és desconegut o insolvent, el pes de la responsabilitat de tercers caurà pràcticament sobre tots els autors i usuaris que siguin demandats. Això pot resultar molt injust, sobretot pels usuaris i autors que actuïn de bona fe. Sota sistemes de registre lliure, aquests no demanen cànons de llicència per les còpies, però continuen sent responsables de les vulneracions del copyright. La garantia de la propietat intel·lectual es va eliminar de les versions 2.0 després de rebre crítiques dures per part dels que concedeixen llicències.364 No obstant això, l'origen del problema rau en les normes de responsabilitat de les lleis del copyright, no pas en les llicències. La responsabilitat imprevisible és un dels factors que pot retardar el desenvolupament de projectes a gran escala tant de contingut obert com de codi obert. El risc de responsabilitat per vulnerar la propietat intel·lectual de tercers augmenta a mesura que es distribueix el codi o contingut font. Això dificulta que s'iniciïn projectes oberts que involucrin molts participants i titulars potencials de drets, com ara les pel·lícules obertes. (Continuarem la discussió sobre responsabilitats en el proper capítol.) 5.5.4 Internacionalització i formalitats La visió de l'adaptació. Creative Commons és la primera iniciativa de llicència oberta i la més gran, que inclou tant el contingut obert com el codi obert, i que pretén una internacionalització de la llicència. Els directius de CC, que provenen principalment de la comunitat legal acadèmica dels EUA, pensen que els textos de la llicència s'han de traduir als idiomes de cada país i adaptar a les jurisdiccions nacionals. Un dels motius que recolzen la internacionalització és que una llicència en anglès basada en un text legal sobre copyright als EUA podria no ser vàlida en uns altres països. Per altra part, un dels inconvenients de les adaptacions nacionals són les possibles inconsistències. De fet, una comparació ràpida revela que, a la pràctica, hi poden haver diferències substancials. 365Evidentment, el projecte CC concedeix una llibertat considerable a cada equip nacional encarregat de la internacionalització. Molts d'ells, encara que no tots, sostenen explícitament que la llicència hauria d'interpretar-se com un contracte.366 Algunes de les traduccions inclouen canvis terminològics evidents; per exemple, en lloc de distribució, parlen de posar-ho a l'abast del públic. En molts casos, les definicions es treuen de les lleis nacionals del copyright. En la major part de les adaptacions, es busca un ús adequat per ajustar-se a les lleis europees del copyright, les quals inclouen normalment una llarga llista tancada amb les limitacions del drets d'exclusivitat.367 En algunes adaptacions, encara que no en totes, s'afegeix una referència explícita al dret de les bases de dades. Només unes poques llicències prenen en consideració explícitament l'assumpte dels drets morals.368 Compres a través del Fòrum. La internacionalització mitjançant la traducció i les adaptacions legals aconsegueixen que les llicències siguin més comprensibles i vàlides legalment en més jurisdiccions. Tanmateix, aquesta visió també presenta inconvenients clars. Quant a la part pràctica, la facilitat d'ús i la interoperabilitat de les llicències poden ressentir-se perquè els usuaris han de tractar amb moltes versions de llicències escrites en diferents idiomes i amb terminologia també diferent. Quant a la part legal, les llicències CC estipulen que: «Només podreu distribuir, projectar, representar o representar digitalment en públic una obra derivada, si és sota les condicions d'aquesta llicència, d'una versió posterior d'aquesta llicència amb els seus mateixos elements o d'una llicència virtual de la Creative Commons que també contingui els mateixos elements» Tenint en compte tot això, qualsevol pot entrar a la pàgina web de CC i registrar l'obra amb una llicència CC adaptada i traduïda, per exemple, al finlandès. Segons les condicions mencionades abans, això no significa que una obra es pugui utilitzar a Alemanya amb la versió finlandesa de la llicència. Per tant, l'autor no pot controlar quina versió de les llicències escollirà l'usuari. Al final, els usuaris tenen la possibilitat de comprar en un fòrum dins d'un projecte de registre de llicència de contingut obert internacionalitzat, exactament com en el món real. Comparació amb el codi obert. No obstant això, es pot dubtar de si la internacionalització de la llicència mitjançant la traducció i l'adaptació legal podria ser decisiva en l'èxit real dels registres de llicència oberts. La llicència de programari de codi obert més popular, la GNU GPL, s'utilitza des de 1989 per tot el món sense que s'hagi conegut cap cas legal on la llicència, o una part d'ella, s'hagi considerat no vàlida.369 La conclusió és que les llicències CC també es poden aplicar en totes les jurisdiccions. Al menys de moment, la conducta real dels usuaris ha tingut més pes que les interpretacions legals i les valoracions del risc. 5.5.5 Reflexions finals El temps ha demostrat que els primers pronòstics d'extinció del copyright a Internet eren exagerats. 370La llei del copyright, en lloc de col·lapsar-se, s'ha complementat amb altres concessions de llicències liberals a Internet. En certa mesura, la llei del copyright s'ha fixat per mèrits propis.371 No obstant això, encara resten molts reptes legals quant al problema de la responsabilitat estricta que imposa la llei del copyright. I això, possiblement, serà el punt més complicat. A llarg termini, si Creative Commons i d'altres models de concessió de llicències obertes aconsegueixen més suport per part de la indústria dels mitjans de comunicació que els envolta, aquesta llei podria canviar. (Reprendrem aquest tema al final del pròxim capítol.) També ens queda el repte de l'actitud, de la creació de comunitats i de la infraestructura tècnica necessària. Dirigir un gran projecte de concessió de llicències de contingut obert requereix suport comunitari. El model directiu de Creative Commons, basat en una estructura vertical descendent, podria ser el punt feble per què alguns autors es desanimessin. A més, encara no és freqüent que s'annexin les descripcions dels drets a les obres publicades a Internet, i la majoria d'usuaris no llegeixen textos complicats de llicències. Només l'educació i el temps ens diran si la gent finalment adopta els reptes de la concessió de llicències de contingut obert, de la mateixa forma que els desenvolupadors de programari han adoptat les llicències de codi obert. 5.6 Resum Competència entre les normes de concessió de llicències en evolució És obvi que es crearan llicències noves de codi obert, de la mateixa manera que s'actualitzaran algunes versions antigues. També podríem afirmar que, amb el temps, la concessió de llicències de codi obert ha atret les empreses i moltes llicències han evolucionat per atendre les necessitats de la indústria del programari. En general, ara les llicències informen amb detall de l'existència de patents de programari. Els límits de els obres derivades han estat adaptades a les noves necessitats de programari que el mercat demana. No sols la tendència comercial, sinó també les llicències GNU amb càrrega ideològica han sobreviscut i han constatat que tenen un lloc als mercats. Ja no es parla de la GPL com si fos un càncer per a la indústria. Però malgrat l'evolució evident dels components i de les tècniques de registre de llicències, la seva funcionalitat, com s'explica en aquest apartat, no ha evolucionat tan ràpidament. Cada llicència es pot classificar fàcilment en grups ben definits. El quadre següent resumeix les característiques funcionals de les llicències més populars des de la perspectiva de còpia, distribució i modificació (obres derivades), que hem presentat fins ara. Taula 9. Funcionalitat del copyright en els diferents tipus de llicència Pel que fa a d'altres característiques importants de les llicències, podem concloure que: Tan sols les llicències de codi obert més recents, creades per a la indústria, tenen autorització explícita de patent i marca registrada, a més de condicions de cancel·lació. Per tant, suposem que les llicències, en el futur, continuaran incloent aquestes condicions explícites. Sempre que s'han proposat provisions de garantia intel·lectual, s'han hagut de retirar tot seguit a causa de la desaprovació generalitzada de la comunitat. Totes les llicències inclouen condicions explícites d'atribució, i algunes, fins i tot, incorporen també condicions de reputació. D'aquesta forma, s'imposen els components morals del copyright. Quan s'inicia un projecte de programari nou, les llicències competeixen. Aquesta situació de competitivitat té implicacions tant positives com negatives. D'una banda, tenir opcions de llicència potencia la varietat de projectes individuals de codi obert. Com hem vist abans, els projectes poden tenir objectius ètics, tècnics i comercials diferents; per tant, les condicions de les llicències podrien satisfer-ne els aspectes més puntuals. D'altra banda, la competitivitat junt amb el fet que moltes llicències de codi obert siguin, a la pràctica, incompatibles entre elles pot fer que, a la llarga, s'iniciïn altres projectes de codi obert, que no es podran beneficiar dels esforços de desenvolupament que s'han dut a terme en altres projectes. En resum, això pot tenir efectes negatius en el model d'innovació oberta que s'ha identificat amb l'èxit del desenvolupament del codi obert. El desenvolupament de l'Open Source Definition adreçada cap a una norma de compatibilitat amb la cooperació dels autors de llicències podria ser una solució a llarg termini als problemes de compatibilitat.372 6 Defensa amb codi obert Gestió del risc d'usurpació i patents Tot ús de codi obert en un entorn empresarial inclou riscos legals. En aquest capítol expliquem com els riscos d'infracció de les patents de programari i de la propietat intel·lectual es poden gestionar a nivell d'empresa individual i de regulació social. Comencem per les alternatives més generals de la gestió de riscos d'infracció de drets de propietat intel·lectual en el desenvolupament del codi obert. A partir d'aquí, la discussió s'extén fins al problema social de les patents de programari especialment en el context de la normativa europea. 6.1 Com fer front al risc d'usurpació dels DPI? 6.1.1 Antecedents A continuació analitzarem alternatives defensives de gestió dels drets per a desenvolupadors de codi obert. Recentment hi ha hagut un gran debat al voltant de les demandes que SCO ha interposat contra una gran quantitat d'usuaris de Linux. Possiblement aquestes demandes siguin el millor exemple per comprendre com els drets de propietat intel·lectual es poden utilitzar, en teoria, com una eina estratègica en contra dels usuaris de programari particular. El codi obert, i en general la metodologia de desenvolupament de programari basada en components distribuïts, subratlla els riscos d'un copyright potencial de tercers i de les usurpacions de patents. Tot i que el cas de SCO no és un bon exemple d'ofensiva fructuosa dels drets de propietat intel·lectual, perquè SCO no ha pogut demostrar-ne la usurpació, ha aconseguit que moltes empreses es replantegin les seves estratègies de defensa de la propietat intel·lectual. També es molt probable que algunes empreses hagin ocultat drets fàcilment verificables als productes de codi obert existents, la qual cosa pot resultar problemàtica en el futur. Per exemple, un informe filtrat de Hewlett Packard mostra fins a quin punt una gran empresa informàtica considera greu el risc potencial de demandes d'usurpació de patent contra el codi obert. 373 El marc teòric d'aquest apartat es basa principalment en les teories econòmiques de responsabilitat civil del producte, 374assegurança de responsabilitat 375i estratègia de patent.376. Des d'un punt de vista pràctic, intentem construir un marc de progrés per gestionar aquesta mena de riscs en el desenvolupament de codi obert. També posem a prova aquest marc presentant proves basades en pràctiques reals de gestió de riscs obtingudes en informes de mercat, entrevistes i estadístiques de patent d'accés públic. D'acord amb la nostra anàlisi de gestió de riscs, diferenciem tres tipus d'organitzacions que desenvolupen codi obert: Empreses IT, empreses de codi obert i projectes comunitaris. Quan parlem d'empresa IT, ens referim a les grans empreses que ofereixen molts productes al mercat del maquinari i programari, tot incloent un interès i una participació significatives en el programari de codi obert. Les empreses IT típiques són, per exemple, Apple, HP i IBM, però també Microsoft, perquè es presenta com una mena d'alternativa al codi obert. En el cas de les empreses de codi obert, ens referim a qualsevol petita o mitjana empresa que desenvolupi o comercialitzi productes de programari basats en components de codi obert. En aquest sentit, les empreses pioneres son aquelles que s'han format al voltant de productes molt coneguts de codi obert, com ara Red Hat Inc. (GNU/Linux) i MySQL AB (MySQL) Per últim, quan parlem de projectes comunitaris de codi obert ens referim a projectes de desenvolupament de codi obert sense cap objectiu comercial, però amb molta rellevància, com per exemple Linux o Apache. Estructurem aquest apartat de la manera següent. En primer lloc, analitzem l'origen del copyright potencial de tercers i de la usurpació de patents en el programari de codi obert. Considerem aquests fets com a accidents vers els usuaris, els quals han estat provocats per les accions del titular dels drets. A continuació presentem quatre alternatives defensives de gestió de riscs: 1) assignació de responsabilitats en les llicències de programari, 2) assegurança de responsabilitat, 3) adquisició de patents i 4) elusió de risc. I per comprovar la rellevància del marc, es repassa la normativa actual de gestió de riscs. Així doncs, observem que les estratègies de gestió de riscs de les empreses IT ja establertes, les de les empreses pioneres de codi obert i les dels projectes comunitaris de codi obert es diferencien les unes de les altres. Òbviament, una estratègia òptima depèn del risc d'usurpació real, que pot canviar de forma significativa segons els diferents tipus de desenvolupadors. Per últim, el capítol conclou amb una reflexió sobre les implicacions de la gestió de riscs i de la normativa de registre de llicències a llarg termini. 6.1.2 Natura de les usurpacions dels DPI per tercers Usurpacions com a accidents. En la figura següent podem observar les relacions bàsiques entre les parts implicades en un cas d'usurpació. Figura 17. Cadena de desenvolupadors i usurpació dels drets de propietat intellectual. Suposem que tenim un producte de codi obert i que el Desenvolupador 1 (actuant de bona fe) hi afegeix una contribució que vulnera els drets de propietat intel·lectual del titular del copyright o de la patent. Llavors, tots els desenvolupadors posteriors, des del Desenvolupador 2 fins al Desenvolupador x, en serien responsables legalment segons estableixen les lleis de copyright i de patents, fins i tot si desconeixien que el programari infringia un dret de tercers. Els desenvolupadors vulneraran el copyright si, per exemple, copien, modifiquen i distribueixen la contribució al codi font que ha estat usurpada. També vulneraran les patents si, per exemple, fabriquen, venen i utilitzen comercialment les invencions patentades incorporades a la contribució usurpada. En definitiva, aquestes usurpacions directes de la propietat intel·lectual estan sotmeses a una normativa estricta de responsabilitat civil. En primer lloc, considerem que la situació d'un desenvolupador individual vers els usuaris (qualsevol desenvolupador posterior o usuari final) és analògica a l'establiment de la responsabilitat civil del producte. Per tant, analitzarem primer la vulneració dels drets de propietat intel·lectual com a l'accident resultant d'un fet extern negatiu per a tots els desenvolupadors de codi obert i els seus usuaris. La pregunta ara és, basant-nos en el tractat de Calabresi sobre l'economia de la llei d'accidents, quin és el cost d'aquests accidents i què poden fer els desenvolupadors de codi obert per minimitzar-los des de la cadena de desenvolupadors? 377 En segon lloc, obrim la «caixa negra» de les demandes per usurpació i ens preguntem com es podria orientar el risc d'usurpació cap a la causa de l'accident, es a dir, el titular dels drets de propietat intel·lectual. Aleshores, la pregunta seria: de quins mitjans disposa el desenvolupador individual per protegir-se d'accions no desitjades per part dels titulars dels drets de propietat intel·lectual? Bé, abans de la nostra anàlisi sobre les alternatives de gestió de riscs, pensem que cal una explicació detallada sobre l'origen de la usurpació dels drets de propietat intel·lectual com a accidents. El que volem demostrar és que és difícil evitar les usurpacions ex ante, i per tant l'analogia de l'accident és pertinent. Copyright. Podem parlar de dos tipus d'usurpació del copyright. El primer d'ells es dóna quan es copia el codi font d'una manera que no permet la llei del copyright i el segon quan no es compleixen les condicions de la llicència.378 Les usurpacions es poden donar tant en components de producció pròpia com de terceres parts. És evident que, en el segon cas, els problemes són més difícils d'identificar. La còpia literal del codi font es pot evitar, en certa mesura, per endavant. No obstant això, el requisit és tenir a l'abast el codi font que suposadament ha estat copiat, que no sol ser el cas. Ni tan sols l'anàlisi tècnica de la còpia del codi font va gaire més enllà. Hi ha limitacions clares, per exemple, a l'hora d'identificar la còpia de l'estructura. Les usurpacions de les condicions de la llicència també es poden evitar per endavant, amb algunes limitacions. Un requisit previ és que totes les llicències d'un producte concret es puguin llistar des d'arxius externs, codi font, etc. A més, les llicències conegudes poden ser avaluades per les possibles reserves de drets a tercers i d'altres condicions no estàndards. Desafortunadament, la interpretació de les condicions de la llicència pot ser confusa, especialment si han estat escrites pels autors individuals del programa. Com ja hem apuntat, no hi ha un acord a l'hora d'interpretar moltes de les llicències estàndard de codi obert. No és gens sorprenent, que la Free Software Foundation s'enfronti, fora dels tribunals, a més de cinquanta violacions de la llicència CNU GPL cada any, i calcula que cada vegada passa més. 379 De tot el que hem vist fins ara es desprèn que un desenvolupador o usuari de programari de codi obert que utilitzi components de tercers té molt pocs mitjans per evitar els riscs d'usurpació de copyright per endavant. Si el codi font de component no es troba completament disponible, serà impossible avaluar el risc. En teoria, la disponibilitat de la font ajuda a l'anàlisi d'usurpació, segons el que hem vist fins ara, però en tots els casos el procés és car, laboriós i força incomplet. En realitat, la disponibilitat del codi font també pot augmentar el risc d'usurpació, perquè facilita la identificació de les usurpacions als propietaris dels drets ofensius. Patents. A banda del copyright, també podríem trobar patents ocultes, que no es coneixen fins que el programari no és popular. El risc d'usurpació de patents creix amb l'àrea geogràfica de mercat i, òbviament, és molt més gran als mercats dels Estats Units. És difícil de calcular, però, el risc real de les usurpacions de patents. Evidentment, molts dels components de programari de codi obert que s'utilitzen habitualment violen les patents. Per exemple, Open Source Risk Management Inc., que ven assegurances per a DPI, afirma que el nucli Linux podria violar quasi tres-centes patents diferents. (Anteriorment havien declarat que Linux no infringia els copyrights.) 380 Com ja hem comentat, la identificació i l'avaluació del risc d'usurpació de patent és, a la pràctica, quasi impossible. Com que la majoria de les demandes de patent no inclouen el codi font, és impossible fer-ne una recerca tècnica que es basi en les dades de patent i el codi obert disponibles. A la pràctica, només es podria evitar la usurpació de les patents molt conegudes i fer un seguiment de la cartera de patents dels competidors directes. Tanmateix, fins i tot seguir el ritme dels competidors pot resultar desorbitadament costós i difícil a causa del dinamisme de la indústria del programari. De fet, s'han atorgat milers de patents de programari arreu del món. Seria poc realista demanar que fins i tot les grans empreses informàtiques sàpiguen amb precisió si els seus productes ampliats violen cap patent de tercers. Però, per definició, les grans empreses tenen mitjans millors per defensar-se de les possibles demandes d'usurpació. De fet, és habitual que tinguin carteres de patents que es poden utilitzar de forma estratègica per a reconvencions i llicències per dependència. Les empreses petites de codi obert, que no tenen grans carteres de patents, necessiten unes altres opcions de defensa. En resum, fins i tot els desenvolupadors i els usuaris prudents, amb independència de la seva envergadura, tenen més limitades les possibilitats d'evitar una usurpació de patent que de copyright. Bàsicament, el risc és major per als desenvolupadors de productes amb una quota de mercat més gran. Paradoxalment, també existeixen desenvolupadors i programes que, potser, són més beneficiosos per a la societat. De nou, el codi obert no ajuda a la defensa, sinó que augmenta el risc d'usurpació, ja que els propietaris de les patents poden identificar les vulneracions més fàcilment. 6.1.3 Alternatives per afrontar els riscs Clàusules d'exempció de responsabilitat de les llicències i garanties. D'acord amb el principi d'evitar costos de la manera més barata, els costos dels accidents s'haurien d'assignar a qui els pugui evitar amb costos relativament més baixos.381 Per exemple, si suposem que el desenvolupador és qui coneix millor els riscs implícits en el seu programari, aleshores també hauria d'assumir la major part dels riscs dels accidents que es derivin de l'ús. El fet de tenir part de responsabilitat, encara que no excessiva, fa que les inversions en el desenvolupament de productes nous augmenti, i també la qualitat global del producte.382 En el desenvolupament de programari, però, la normativa de responsabilitat civil estàndard ha estat caveat emptor, és a dir, el desenvolupador posterior o l'usuari final n'és responsable. La normativa de responsabilitat civil pot no ser econòmicament eficient, si l'usuari té costos de transacció importants a l'hora de determinar el nivell real del risc d'usurpació. En molts casos, aquesta informació ni tan sols es troba a l'abast. Però hi ha un aspecte positiu, la responsabilitat de l'usuari pot augmentar la competitivitat si els usuaris són més prudents a l'hora de trobar els productes més segurs, perquè no hi ha cap producte que es pugui considerar per ell mateix menys arriscat. A més, en alguns casos els usuaris poden determinar millor els riscs reals, cas per cas, si disposen d'informació més completa sobre com s'utilitzarà el programari (Ex.: internament, per al públic).383 Històricament, les limitacions de responsabilitat civil eren necessàries en el cas de les llicències de programari, principalment perquè els desenvolupadors volien evitar els riscs de qualsevol dany causat per errors tècnics o virus. L'argument que s'adduïa normalment era que és realment impossible crear programes complexes a prova de virus.384 A més, com que les còpies dels programes són idèntiques entre elles, qualsevol error es multiplica i la càrrega de responsabilitat potencial del desenvolupador també s'incrementa. Per tant, el fet d'exigir una responsabilitat més estricta implicarà l'augment significatiu del preu del programari, sense cap increment de la qualitat (cap funcionalitat nova, simplement menys virus). Les llicències de codi obert no ofereixen cap tipus de garantia en cas d'errors de programació o virus. Aquests riscs es traslladen dels desenvolupadors originals als desenvolupadors posteriors i als usuaris finals. Les llicències de codi obert més populars també limiten la responsabilitat del desenvolupador pel que fa a errors legals, entre els quals s'inclouen les usurpacions de copyright i de patent fins al límit màxim permès per la llei. La diferenciació entre errors tècnics i legals no és molt comuna en les llicències de codi obert. Com ja hem comentat en el capítol anterior, la llicència oberta de programari inclou una clàusula de garantia d'usurpació més específica (indemnització), que confereix més responsabilitat als desenvolupadors originals. A la pràctica, això significa que si un desenvolupador de codi obert posterior pretén protegir-se dels riscs de propietat intel·lectual que van en contra del desenvolupador original, no caldrà negociar cap clàusula d'indemnització addicional. Aquesta clàusula només serà efectiva quan el desenvolupador original tingui recursos per defensar l'usuari als tribunals. En cas que no es conegui el desenvolupador original o que sigui insolvent, la clàusula no tindrà cap efecte. Això ens porta a analitzar l'alternativa de l'assegurança a tercers. Assegurança addicional. Independentment de l'assignació de responsabilitats, l'assegurança podríem dir que és una alternativa desitjable des del punt de vista social i polític.385 Quan la compensació màxima ja ha estat acordada, l'assegurança és podria utilitzar com a limitació de la responsabilitat de la llicència i de les obligacions contractuals. Si els desenvolupadors tenen la responsabilitat, només assumirien el risc del pagament en el cas d'una usurpació demostrada. Els usuaris participarien en el pagament de la quota de l'assegurança, ja que el preu del programari s'incrementaria lleugerament. Una opció extrema seria l'establiment d'un sistema públic d'assegurances semblant a l'utilitzat pels automobilistes. Això, però, implicaria costos administratius molt alts i, òbviament, el desenvolupament de programari hauria d'estar regulat per normatives governamentals. I fins i tot alguns mètodes de desenvolupament es prohibirien.386 Si els comparem amb la clàusula de limitació de responsabilitat d'una llicència, els costos d'assegurança serien més alts i possiblement no estarien a l'abast dels desenvolupadors que no pertanyessin a una comunitat comercial. En teoria, l'assegurança seria una elecció racional des del punt de vista econòmic, perquè els accidents són poc freqüents i difícils de calcular. Tanmateix, quan l'accident es produís, els resultats podrien ser devastadors, pel que fa a l'aspecte econòmic. L'assegurança també és una forma de posar preu, objectivament, al risc d'usurpació dels drets de propietat intel·lectual en els mercats. A la pràctica, però, fixar un preu és problemàtic. Com que els casos d'usurpació de patents, per exemple, són poc freqüents, hi ha pocs precedents com per a fixar un preu sensat per a les assegurances dels drets de propietat intel·lectual. Un altre problema és que els desenvolupadors tenen més informació sobre els riscs que les asseguradores, a les quals els costa molt accedir a aquesta informació. Ens trobem amb un mercat nou i, per tant, les asseguradores també limiten la seva responsabilitat. Això fa que sigui impossible aconseguir una assegurança que cobreixi tots els tipus de riscs de DPI en tots els mercats possibles. Això podria ser una raó: per exemple, l'assegurança de responsabilitat de litigis de patent no ha estat una opció, bàsicament perquè la demanda d'aquest tipus d'assegurances és baixa. Malgrat tot, hi ha algunes proves que indiquen un possible augment de l'oferta.387 La teoria econòmica suggereix que si l'assegurança de responsabilitat civil no és universalment aplicable, els processos de reclamació s'haurien de limitar. 388Si, contràriament, les qüestions de litigi augmenten, els mercats esdevenen ineficients i caldrà trobar una altra alternativa per a la gestió dels riscos: iniciar la carrera de les patents. Posicionament estratègic de cara a la carrera de patents. Són molts els economistes que han comparat l'obtenció de patents amb una carrera armamentística en la qual els agents del mercat s'afanyen a patentar tant com sigui possible. El resultat ha estat un considerable "embolic de patents", els efectes del qual són amplificats per la naturalesa seqüencial i acumulativa del desenvolupament de programari.389 Les conseqüències d'aquest embolic de patents sobre la innovació i la concessió de llicències no estan prou clares, però hi ha qui considera que poden ser negatives.390 En aquest context, el desenvolupador té, deixant de banda la possibilitat d'autopatentar-se constantment, bàsicament tres opcions: (1) aconseguir una cartera de patents adient mitjançant fusions i adquisicions, (2) comprar la quantitat necessària de patents als competidors o (3) obtenir la llicència de les patents requerides directament o a través d'un consorci de patents. 391Naturalment, el desenvolupador pot decidir també no fer res i fer front a la situació només si s'arriba a produir. Aquestes opcions són factibles per a les grans empreses informàtiques, que sovint fan servir un dels mètodes esmentats per assolir o mantenir la seva posició en les diferents àrees del desenvolupament de programari. Val a dir, però, que les primeres dues opcions normalment són molt cares i ni tan sols teòricament estan a l'abast dels desenvolupadors de codi obert més habituals. L'últim cas és més comú, però resulta bastant inviable per a la majoria de desenvolupadors de codi obert, que han escollit llicències de tipus GPL GNU. El motiu és evident: si fa servir GPL, el titular de la llicència n'haurà d'obtenir més per a cada ús futur, encara que sigui d'obres derivades. Els consorcis de patents normalment no ofereixen aquest tipus de llicències, si més no per defecte. Però, realment són una amenaça les patents? Un dels arguments habituals és que, per ella mateixa, una reclamació per violació no implica necessàriament que el codi obert no pugui fer-se servir. Segons algunes estimacions, als Estats Units només un 1,5 % del total de patents acaba sent qüestió de litigi, i només un 0,1 % arriba finalment a judici.392 A més , fins a un 46 % de tots els litigis sobre patents que arriben a judici són considerats invàlids en última instància.393 Si tenim en compte també que les parts demandades amb més potencial d'arribar a judici tenen les seves pròpies patents per tal de defensar-se (llicències creuades i contrajudicis), potser sí que ignorar completament la carrera de les patents sigui una estratègia raonable per a les empreses més petites o els projectes comunitaris. Evitar riscos. Finalment, també hi ha la possibilitat d'intentar evitar els riscos dels DPI tant com sigui possible. Dintre del procés de desenvolupament, les polítiques d'avaluació de riscos poden millorar-se tot emprant cessions formals de copyright, per escrit, realitzant recerques prèvies de patents o subscrivint assegurances per als desenvolupadors participants. En qualsevol cas, l'estratègia "d'evitar tots els riscos costi el que costi" no serà mai efectiva perquè, com ja hem esmentat, molts riscos de violació simplement no es poden evitar amb anticipació. A més, si els productes de codi obert arriben a convertir-se en l'estàndard, com ja ha succeït per exemple amb la tecnologia d'Internet, els intents d'evitar riscos seran ineficaços des d'un punt de vista social. Una estratègia "ambiental" a llarg termini per evitar riscos seria influir sobre les polítiques de drets per tal de limitar l'abast dels DPI. Aquest tipus de lobbisme normalment actua mitjançant grups de pressió industrials o bé oferint ajuda a activistes de base. Des d'un punt de vista econòmic sembla assenyat invertir en aquestes iniciatives sempre que els beneficis marginals (en aquest cas un menor risc de DPI) superin els costos marginals. 394Però les coses no són tan fàcils. Primer, perquè el sistema polític de vegades es resisteix a fer servir el lobbisme, el resultat del qual és difícil de predir. Però, a més, en el cas dels DPI els oponents acostumen a ser prou forts i podrien neutralitzar qualsevol esforç. Resum. La Taula 10 mostra l'abast, l'efectivitat i els costos de les alternatives de gestió de riscos analitzades fins ara. Taula 10. Comparació de les diferents opcions de defensa dels DPI per part dels desenvolupadors de codi obert. Les clàusules d'exempció de responsabilitat es poden incloure fàcilment en la llicència, però això no protegeix el desenvolupador del titular dels drets de propietat intel·lectual. Les assegurances són relativament més efectives i poden, si més no en teoria, protegir els desenvolupadors davant dels concessionaris i dels titulars dels drets. A la pràctica, però, el mercat de les assegurances de responsabilitat de DPI encara no està prou consolidat. Patentar es considera una opció de gestió de riscos molt efectiva, malgrat que el seu cost és, sens dubte, superior al de qualsevol altra alternativa. A més, el risc real de violació de les patents és qüestionable. Finalment, s'hauria de jutjar si l'opció d'evitar riscos és racional davant la pèrdua de beneficis derivada de la utilització de programari arriscat i la pèrdua de recursos que comporten els lobbies polítics a llarg termini. 6.1.4 Pràctiques reals de gestió Per tal d'entendre les pràctiques de gestió actuals s'ha recopilat informació qualitativa a partir de notes de premsa, entrevistes a Internet i estadístiques sobre patents. Com ja s'ha apuntat, els desenvolupadors de codi obert s'han dividit en tres categories: (1) grans empreses informàtiques que venen "solucions" i grans instal·lacions de codi obert, (2) petites empreses pioneres de codi obert que normalment ofereixen un producte innovador amb codi font obert i (3) projectes de codi obert comunitaris, sense el recolzament d'una empresa. A continuació analitzarem les pràctiques de gestió de riscos dels tres tipus d'organització esmentats envers els usuaris (costos dels accidents) i terceres parts (causes dels accidents). El nostre objectiu és comprovar de forma preliminar si el marc teòric és factible. Empreses informàtiques. Quan l'empresa de programari, amb seu a Utah, SCO va afirmar durant la primavera del 2003 que Linux infringeix el seu dret de propietat intel·lectual, les grans empreses informàtiques que venen i recolzen els sistemes Linux no van respondre immediatament. De seguida, però, durant la tardor del 2003, Hewlett-Packard va obrir un nou escenari en oferir una garantia limitada als seus clients.395 Novell i Red Hat van ser els següents, a començaments del 2004.396 D'aquesta manera, la garantia sobre la propietat intel·lectual esdevé una mena de negoci de garanties addicionals per a les grans empreses d'informàtica. Aquestes garanties, però, no són perfectes: HP només indemnitza les reclamacions (sobre drets d'autor i patents) relacionades amb SCO, Novell limita les indemnitzacions a les reclamacions per violació de drets d'autor i Red Hat només es compromet a substituir els components causants de la infracció sense costos addicionals per a l'usuari.D'altra banda, segons un estudi recent, la majoria d'usuaris corporatius de Linux no han mostrat interès per aquests programes.397 Sembla evident, doncs, que aquestes polítiques de garantia només reflecteixen el comportament de les empreses informàtiques amb aversió al risc davant de les violacions dels drets de propietat intel·lectual. Algunes empreses informàtiques s'han afegit als Open Source Development Labs per crear un fons comú per a la defensa jurídica dels usuaris finals de Linux. Aquest fons no està vinculat a la distribució de Linux per part de cap empresa concreta, sinó que només dóna suport als usuaris finals en cas de litigi amb SCO, la qual cosa limita considerablement el seu abast. 398 La Figura 18 i la Taula 11, més avall, reflecteixen la tendència respecte de les patents adoptada per algunes grans empreses i també la mida aproximada de la seva cartera de patents: 399 Figura 18. Patents concedides als Estats Units entre 1984 i 2004. Font: USPTO. Taula 11. Número total de patents concedides als Estats Units des de l'any 1984 fins a començaments d'agost del 2004. Font: USPTO.400 Les conegudes empreses promotores del codi obert IBM i HP són les que tenen les carteres de patents més grans, tot i que la majoria de les seves patents daten de finals dels anys noranta. Moltes de les patents prèvies només cobreixen el maquinari. Val la pena precisar que, tot i que les sol·licituds de patents han augmentat de forma generalitzada en els últims anys, Apple Computer n'ha aconseguit un número significativament menor al de fa cinc anys. També és interessant observar que el total de patents de Novell no arriba a les 500 i que Red Hat, que hauria de considerar-se una empresa de codi lliure, va obtenir la seva primera patent el 2004. I, malgrat tot, aquestes dues empreses confien en oferir assegurances DPI als seus clients Linux. Sembla prou clar que el número de patents s'incrementarà en el futur. Per exemple, Microsoft ha anunciat que sol·licitarà més de 3.000 patents, la qual cosa farà que multipliqui el seu ritme actual unes quantes vegades.401 La intenció evident és assolir el nivell d'IBM i HP. Això no obstant, sembla que no hi ha risc imminent de reclamacions per violació de patents per part dels principals propietaris d'aquestes. Primer, perquè tots ells han subscrit una política de defensa mútua. IBM ha assegurat que només farà servir les seves patents per protegir-se davant de possibles litigis per casos de codi obert. Per exemple, quan SCO va demandar IBM per violacions dels drets sobre Linux, IBM va presentar una contrademanda basada en tres violacions de patents.402 A més HP s'ha compromès amb el codi obert per una banda i ha preparat la seva defensa davant d'una possible guerra de patents per una altra.403 Fins i tot Microsoft ha dit públicament que només vol explorar les possibilitats de llicència, sense intenció d'atacar.404 En segon lloc, algunes empreses ja han començat a oferir patents sense drets d'autor perquè puguin fer-les servir els desenvolupadors de codi obert. El gener de 2005 IBM va fer una donació de 500 patents als desenvolupadors de codi obert, a continuació SUN en va concedir 1.200 més quan va anunciar Solaris i, segons les últimes notícies, Computer Associates s'ho està plantejant.405 Empreses de codi obert. No deixa de ser interessant que moltes empreses de codi obert ofereixin àmplies garanties pels seus productes. Pel que fa a les violacions dels drets d'autor, les garanties semblen justificades, ja que la reescriptura del codi font és un fet habitual.406 A més, sembla poc probable que aquestes empreses infringeixin les llicències de codi obert perquè, en principi, són les que millor coneixen aquest tipus de llicències. En el cas de les patents de tercers, però, el risc de violació és més difícil d'avaluar. Segons un estudi recent encarregat per la UE, les assegurances contra la violació de les patents s'han convertit en una eina de defensa viable per a les petites i mitjanes empreses europees. Tot i això, l'oferta i les condicions d'aquestes assegurances varien considerablement d'un país a l'altre i, a la pràctica, és possible que no cobreixin possibles litigis als Estats Units, el cas més rellevant. Al Estats Units, el mercat assegurador de les violacions de patents està encara menys desenvolupat. 407 Red Hat va ser la primera empresa de codi obert que va anunciar públicament que presentava patents per a la seva defensa el 2002.408 Una de les lliçons que es poden extreure de la carrera de les patents és que es necessiten anys per aconseguir una cartera de patents creïble a partir de sol·licituds. Red Hat no va obtenir la seva primera patent fins al 2004, quatre anys després de la data de sol·licitud. A més, fer servir les patents és relativament més costós en el cas de les petites empreses perquè solen ser objecte de litigis més sovint que no pas les empreses que disposen de grans carteres de patents. 409 No és d'estranyar, doncs, que moltes empreses de codi obert s'oposin a les patents de forma contundent a nivell de normativa.410 Projectes comunitaris. La millor opció per als projectes comunitaris continua sent deixar intactes les clàusules d'exempció de responsabilitat i evitar les tecnologies patentades o privatives sempre que sigui raonablement possible. Com a mesura pràctica, per exemple, recentment s'ha modificat el procediment de desenvolupament de Linux per tal de documentar millor la procedència del codi font i els subsegüents canvis introduïts. L'objectiu és evitar incerteses legals en el futur. Actualment tots els desenvolupadors de Linux han d'omplir un document on declaren que, segons la informació de què disposen, el nou codi font és obra seva, que no l'han copiat de ningú i que es permet la distribució GNU GPL de Linux.411 Caldria esmentar, però, que aquesta "garantia" no té cap mena d'efecte legal. Entre els activistes del codi obert i del programari lliure fa temps que circula la idea de crear un consorci de patents per al programari GPL. Richard Stallman, per exemple, ha donat el seu suport a la iniciativa, però fins ara la Free Software Foundation no ha fet cap pas formal cap a la creació d'aquest "consorci de patents GNU". 412 La comunitat de desenvolupadors de codi obert també fa campanya obertament en contra de l'aplicació d'una legislació sobre la propietat intel·lectual més estricta. Molts desenvolupadors han advertit que les patents de programari i el creixent control privatiu són una amenaça per al funcionament del model de codi obert. Aquest tema s'analitza amb més profunditat a l'apartat següent. 6.1.5 Reflexions finals L'ús d'extenses clàusules d'exempció de responsabilitat encara és la pràctica més habitual entre els desenvolupadors de codi obert. Hem pogut comprovar, però, que les empreses informàtiques i les de codi obert han començat a vendre garanties de responsabilitat als seus usuaris. El negoci creixent de les garanties demostra que l'existència de més dades sobre la gestió de riscos seria positiva tant per als desenvolupadors com per als directors de les empreses. L'alternativa de les assegurances continua sent, en bona mesura, un terreny inexplorat. Les empreses de codi obert només estan lleugerament (però sembla que cada cop més) interessades en les iniciatives d'assegurança defensiva. És possible, però, que el principal repte siguin els projectes comunitaris no comercials, que actualment no es beneficien directament de les costoses assegurances. Les estratègies de defensa davant de les violacions de patents s'haurien d'estudiar amb més profunditat. És evident que les grans empreses informàtiques han aconseguit grans carteres, normalment d'uns quants milers de patents, en els últims deu anys. Han anunciat públicament que només les faran servir per defensar-se del codi obert. També les empreses de codi obert estudien la possibilitat de fer servir les patents com a defensa. Tot i que una política de defensa mútua seria acceptada per quasi totes les empreses, no hem trobat indicis d'aliances defensives concretes sobre DPI entre els desenvolupadors de codi obert. Potser els consorcis de patents han estat una opció passada per alt. Si es creessin consorcis integrats per totes les parts, també pels desenvolupadors de codi obert no comercials, molt probablement es reduïrien els costos socials dels riscos de violació de patents. D'altra banda, la importància de les patents de codi obert requereix un estudi empíric més exhaustiu. Per exemple, la documentació de l'anomenada gestió del capital intel·lectual destaca la importància de les patents, especialment com a font d'ingressos en concepte de llicència i com a via per tenir accés a les novetats dels altres.413 Contràriament, però, sembla més adient analitzar les patents del programari de codi obert com a riscos que no pas com a oportunitats, tot i que també hem observat que els costos dels riscos de violació de patents podrien no ser tan alts com es creu. Per resumir, doncs, a més de l'establiment de la responsabilitat inter partes, la subscripció d'assegurances per part de tercers i l'obtenció de llicències, la gestió dels riscos del codi obert comprèn també evitar tant com sigui possible els riscos i, fins i tot, la influència política sobre la creació de lleis de propietat intel·lectual. Tal i com va indicar Calabresi en la seva anàlisi dels accidents, es pot dir que la gestió òptima dels riscos DPI consisteix, per a cada tipus d'organització, en una barreja de les alternatives disponibles. 6.2 Els problemes de les patents i les possibles polítiques per resoldre-ho414 6.2.1 Antecedents Es podria argumentar que el programari de codi obert és el sector més innovador i de creixement més ràpid de la indústria actual de programari. Molts desenvolupadors en solitari i petites empreses han advertit, però, que les patents de programari (que inicialment pretenien fomentar la innovació) amenacen el funcionament del model de codi obert. 415 La recent campanya política encetada per la proposta de directiva sobre patents de programari de la UE ha augmentat les pors que la distribució de programes de codi obert sigui especialment vulnerable a les patents.416 Alguns desenvolupadors de codi obert prou coneguts, com ara Linus Torvalds, han expressat en públic opinions crítiques sobre les patents de programari en general i sobre la proposta de directiva en particular.417 Les crítiques s'han centrat bàsicament en els aspectes econòmics: l'augment progressiu de les patents pot arribar a posar en perill la innovació.418 A continuació, analitzarem alguns suggeriments sobre com solucionar el problema de les patents i el desenvolupament de codi obert: els consorcis de patents per als desenvolupadors de codi obert, apropar el procés de desenvolupament i el d'obtenció de patents, solucionar el problema de les patents trivials i introduir noves excepcions a la responsabilitat derivada de la llei de patents. Acabem aquest apartat argumentant que, en cas de conflicte entre patents i desenvolupament de codi obert, el primer que caldria fer és millorar el sistema legal. Caldria evitar que el desenvolupament de codi obert, en tant que metodologia, se sotmetés a unes regles abstractes legals que possiblement no coincidirien amb la realitat pròpia del desenvolupament de programari. Així doncs, potser la política d'excepcions a les responsabilitats ofereix la millor alternativa per a totes les parts. 6.2.2 Llicències de codi obert i risc de violació de patents Primer ens endinsarem en la problemàtica de les patents des del punt de vista de les llicències de codi obert. Com ja hem vist anteriorment, moltes d'aquestes llicències, entre elles GNU GPL, CPL, LGPL, MPL i Apache, incorporen un mecanisme de finalització que impedeix desenvolupar programari que requereixi cap mena de pagament en concepte de llicència de patents de terceres parts. Naturalment, no totes les llicències de codi obert tenen aquestes clàusules referents a les patents. Per exemple, les conegudes llicències BSD no en tenen. Malgrat tot, com ja hem comentat, les clàusules de finalització de patents cada cop són més habituals. Deixant de banda si realment són pràctiques o no, sembla prou clar que el desenvolupament de codi obert es complica quan existeixen moltes més patents sobre programari. També hem esmentat que el principal repte de les patents sobre programari rau en el fet que el risc de violació és difícil d'avaluar i de gestionar ex ante. És cert que, estadísticament, els casos de violació de patents són escassos, que moltes patents es consideren nul·les i que una simple reclamació per violació no activa la clàusula de finalització, per exemple en el cas de GNU GPL.419 A la pràctica, no obstant, un projecte de codi obert que s'enfronti a una reclamació per violació per part d'una empresa fefaent possiblement hauria de deixar-se córrer només perquè determinar quin és el risc real suposaria massa temps i diners. Però, a més dels desenvolupadors, també els usuaris de codi obert s'exposen al risc de violació de patents. Les llicències de codi obert no ajuden en realitat perquè normalment traslladen el risc de violació dels drets de la propietat intel·lectual als usuaris. Com podem, doncs, reaccionar a la pràctica davant d'un cas de reclamació per violació de patents? Primer s'ha d'aturar l'ús de la invenció. Segon, caldria analitzar la patent per determinar si s'hauria de negociar una llicència o reescriure la invenció tot evitant la patent. Aquesta pot semblar l'opció més segura des d'un punt de vista legal, però possiblement es requereixin recursos i motivació addicionals per tornar a "inventar la roda". Les llicències també poden ser problemàtiques: la llicència de les patents hauria de ser pràcticament gratuïta a causa de les clàusules incloses en les llicències de codi obert (per exemple l'esmentada clàusula 7 de GPL) i perquè la majoria de desenvolupadors en solitari i projectes no comercials no es poden permetre, per començar, abonar cap cànon. Quants propietaris de patents ho acceptarien, això? Finalment, és difícil discutir perquè cal comprar una llicència per a una invenció que en molts casos ni tan sols es podrà utilitzar (les patents no tenen codi font). 6.2.3 Procés de desenvolupament des de la perspectiva de les patents Des del punt de vista de les patents, el codi obert i el programari lliure són conceptes ambigus. Al cap i a la fi, existeixen projectes de desenvolupament de codi obert tant comercials com no comercials, Alguns projectes estan coordinats per una entitat jurídica, i altres per grups informals de desenvolupadors. 420 Un aspecte comú al desenvolupament de codi obert és la transparència i la naturalesa acumulativa del procés. Com a conseqüència: Tot el codi font (també les invencions potencials de programari) és públic i es debat des del principi; no hi ha fases secretes i tampoc es fa recerca sobre possibles patents abans de la seva publicació. El codi desenvolupat es distribueix; és a dir, el número de participants és, en principi, il·limitat, i la seva identitat pot ser anònima El desenvolupament té caràcter acumulatiu i les contribucions normalment es limiten a una part o a una funció específica del programa. A més, és possible que els desenvolupadors inicials abandonin un projecte i que posteriorment el continuïn uns altres. En el procés de desenvolupament poden participar simultàniament persones i entitats. La jerarquia i organització del procés de desenvolupament poden no ser evidents des de fora. Normalment, els projectes de codi obert no requereixen grans recursos per ser tècnicament eficients. A més, un projecte exitós pot fer-se més notori i augmentar el número d'usuaris sense grans esforços de màrqueting comercial. A partir de la breu descripció anterior podem trobar múltiples motius pels quals el sistema de patents no encaixa en absolut amb el procés de desenvolupament de codi obert. Els principals problemes que se solen esmentar són els següents: Les violacions de les patents del codi obert són relativament fàcils de detectar i demostrar La manca de recursos no permet fer recerques de patents existents ni defensar-se legalment en cas de violacions basades en patents trivials La filosofia i l'ètica característiques del programari lliure s'oposen frontalment a l'ús de patents sobre cap mena de desenvolupament de programari Pot considerar-se que la publicació del codi font a Internet es produeix a totes les jurisdiccions i, per tant, infringeix potencialment patents de tot el món Els desenvolupadors de programari privatiu podrien fer la competència als de codi obert amb les reclamacions de violació de patents; si les seves patents es consideren vàlides i els desenvolupadors de codi obert han d'obtenir llicències, no existeix garantia a les clàusules d'aquests contractes de llicència privats entre la comunitat de desenvolupament de codi obert i l'empresa de programari comercial Cal recordar que el desenvolupament de codi obert ha funcionat adequadament fins ara i ha donat lloc a innovacions sense que ningú hagi sol·licitat o concedit llicències. No és l'objectiu d'aquest estudi valorar si el sistema de patents funciona correctament amb el desenvolupament de programari en general. Tot i això, s'ha de tenir ben present que les conseqüències negatives potencials que un sistema de patents ineficient i ineficaç tindria sobre el desenvolupament de codi obert són considerablement més greus que no pas a altres activitats d'innovació. 6.2.4 Debat sobre polítiques de codi obert i patents Com hem vist, fa anys que es produeix un debat polític crític amb les patents de programari. 421Els detractors de les patents (normalment desenvolupadors de codi obert en solitari, activistes de diversa procedència i petites empreses) han aconseguit una notorietat considerable amb uns recursos comparativament inferiors als dels agents favorables a les patents. El debat té actualment una gran rellevància a la UE, on s'han publicat diversos informes i estudis de consultors sobre aquest tema. 422Aquestes són algunes de les solucions suggerides en els estudis i informes: Solucionar el problema de les patents trivials (Bakels) Crear un consorci de patents per a la comunitat de desenvolupament de codi obert (Pbt Consultants) Adaptar el mètode de desenvolupament per tal que inclogui la recerca de patents existents (Nichols) Exempcions de responsabilitat especials per als desenvolupadors de codi obert (Blind et al) A continuació analitzarem una per una aquestes propostes des del punt de vista dels desenvolupadors de codi obert. Per començar, la solució del problema de les patents trivials possiblement no ajudi en absolut. La majoria del codi obert pot considerar-se genèric, però existeixen alguns grans projectes l'objectiu dels quals és produir nous avenços cabdals (sistemes operatius, bases de dades, etc.) D'altra banda, els experts semblen assumir amb optimisme que el sistema de patents funciona adequadament pel que fa al desenvolupament de programari i que, en cas contrari, la solució és senzilla. Però, com ja s'ha comentat abans en aquest mateix estudi, no és gens clar que les patents fomentin realment la innovació en la indústria del programari. Més aviat, el sistema de patents beneficiaria les estratègies de màrqueting, finançament, resolució de litigis i globals de les empreses més grans.423 Les recomanacions que pretenen que els desenvolupadors de codi obert utilitzin el sistema de patents s'enfronten a problemes encara més fonamentals. En primer lloc, perquè moltes llicències de codi obert no donen valor a les patents, sinó que bàsicament demanen que totes les patents relacionades amb programes de codi obert tinguin llicències a l'abast de qualsevol persona de manera gratuïta. És pràcticament impossible canviar aquest principi tan ben definit a totes les llicències que tinguin un component fortament ètic. 424En segon lloc, encara que sigui des d'un punt de vista teòric, un gran consorci de patents que només admetés "desenvolupadors de codi obert" podria considerar-se contrari a la llei de la competència. Perquè un consorci de patents pugui arribar a funcionar en el camp del codi obert hauria d'acceptar empreses entre els seus membres, persones i fins i tot desenvolupadors anònims, a més de desenvolupadors de programari tant lliure com privatiu. Però, a més, adaptar el desenvolupament de programari al model que fonamenta la llei de patents pot arribar a funcionar en les empreses més grans, però difícilment pot adaptar-se a la naturalesa informal i a la distribució pròpies del model del programari de codi obert. Tampoc no es pot deixar de banda el fet que fins i tot les empreses més grans necessiten ajuda externa en qüestió de patents.425 Finalment, tal com proposen Blind et al., en el futur s'hauria de valorar si l'ús no comercial del programari de codi obert hauria d'estar exempt de les reclamacions de les patents, encara que es produeixin en un context comercial. Aquesta aproximació té dos avantatges evidents: Primer, seria una normativa social generalment acceptada. Segon, i potser més important encara, el desenvolupament de codi obert, en tant que metodologia, no hauria d'adaptar-se a les regles abstractes del dret, que poden ser molt diferents de la realitat de la programació. En comptes d'això, les lleis s'adaptarien seguint un mètode de desenvolupament alternatiu. 6.2.5 Exempció de responsabilitat en el cas del codi obert? Pensem en termes pràctics per un moment. Els desenvolupadors en solitari i les petites empreses tenen bons arguments per demostrar que el model de desenvolupament de codi obert pateix a causa de les patents. Aquests arguments tenen arrels molt més profundes que no pas l'actual debat públic al voltant de la directiva proposada i van més enllà de la pròpia directiva. Atès que el codi obert és una part indispensable i creixent de la indústria del programari actual, trobar una solució satisfactòria a les preocupacions dels detractors de les patents beneficiaria tots els participants, també les grans empreses informàtiques. Raonar que el sistema de les patents funcionarà en el futur i impulsarà la innovació en la indústria del programari no dóna resposta al seu problema. És una qüestió de models enfrontats: el del desenvolupament i concessió de llicències de codi obert i el que es construeix sobre el model de desenvolupament i concessió de llicències propi de les patents. Quines propostes es poden fer per ajudar els afectats per les patents? Des del punt de vista de la normativa social, afegir noves exempcions a una nova llei sembla ser la millor resposta possible. Malauradament, el debat polític a la UE ha avançat i retrocedit sense donar una resposta clara a les preocupacions del partidaris del codi obert. Actualment, l'estratègia de l'exempció està en perill.426 Finalment, es planteja una conjectura: què passaria si l'opció de les exempcions acabés imposant-se finalment? Curiosament, Blind et al argumenten que si es plantegés una exempció de responsabilitat per al codi obert, l'acord TRIPS s'hauria de revisar de forma semblant. En aquest punt es podria comparar la posició dels partidaris del codi obert amb la dels països en procés de desenvolupament. Tant els uns com els altres gaudeixen d'una propietat intel·lectual general (codi font i coneixement cultural indígena) que les multinacionals intenten reclamar com a propietat privada seva. La diferència rau en què els defensors del codi obert treballen principalment en el món desenvolupat i el seu poder econòmic i polític relatiu pot arribar a ser molt més gran que el dels països en desenvolupament del tercer món. De fet, els partidaris del codi obert s'han acabat convertint en importants contendents d'aquesta lluita per la propietat de l'economia del coneixement. 427 6.3 Conclusió: Les lleis sobre drets de propietat intel·lectual són millorables Què es podria fer de cara al futur que limités els costos socials de la violació dels DPI per part dels desenvolupadors de codi obert? Des d'un punt de vista empresarial val la pena tenir en compte l'opció de l'assegurança. El preu anual de l'assegurança reflecteix el preu real de les patents de programari. A més, poden desenvolupar-se altres tècniques de gestió de riscos a altres nivells, des de la integritat del codi font fins a les activitats polítiques. Des d'un punt de vista social, però, la qüestió no és tan clara. Pel que fa a les patents, alguns optimistes com Jaffe i Lerner asseguren que els problemes més evidents poden solucionar-se millorant les característiques de les patents i desincentivant els nocius litigis per qüestió de patents. Altres opinions, però, són més escèptiques, sobretot si no s'accepta de bon començament l'argument que el sistema de patents serveix també per a les innovacions de programari. Una solució més radical consistiria en modificar la forma en què la llei de patents tracta la propietat. El primer pas seria incloure excepcions que limitin l'abast de la llei de patents. A llarg termini, es podria continuar argumentant, les normatives sobre responsabilitat en matèria de propietat intel·lectual podrien revisar-se. La mera existència d'accidents socials indesitjables , tal i com els hem anomenat, és conseqüència de l'estricta normativa sobre responsabilitat que s'aplica en el cas de les violacions previstes a les lleis de propietat intel·lectual. En concret, podríem fer esment a l'aplicació del principi de negligència a les situacions en què els desenvolupadors no poden, en realitat, saber si el seu programari viola drets de propietat intel·lectual de terceres parts. De fet, una reforma com la que es planteja no es desviaria radicalment de la llei actual. Per exemple, durant la implantació de la Directiva de Copyright de la Unió Europea a Finlàndia es va fer constar que qualsevol persona que es descarregui material amb copyright d'Internet no tindrà responsabilitat si no sabia, basant-se en el principi de negligència, que el material infringia els drets.428 7 Us ofensiu del codi obert: Alguns casos pràctics sobre llicències En aquest capítol estudiarem de quina manera les llicències de codi obert s'han fet servir ofensivament en el marc d'una estratègia comercial adaptada als canvis del mercat. El primer cas tracta els mercats de programari de sistema operatiu i com les alternatives de codi obert han canviat l'estructura del mercat existent durant els últims anys. El segon dels exemples descriu un model de llicència específic per al codi obert anomenat llicència doble i analitza el cas d'algunes empreses noves que s'han beneficiat de fer-lo servir. 7.1 Llicències de codi obert per obtenir guanys 7.1.1 Possibilitats d'establir preus per als productes El model del codi obert limita, però no impedeix, les possibilitats de posar preu al programari. Naturalment, com ja s'ha comentat, existeixen sistemes indirectes que poden fer-se servir per posar preu al material protegit per copyright.429 Aquests mecanismes indirectes són especialment adequats en el cas de les empreses de serveis de programari. Establir llicències per a un gran nombre d'usuaris de codi obert no és possible actualment a causa del requisit de treballar sense "cànon" que estableix l'Open Source Definition. Malgrat això, amb una mica d'imaginació, es poden trobar-se solucions directes per posar preu, com ara: 1.Primera compra. La llicència només esdevé efectiva quan es distribueix la primera còpia del programa en qüestió. D'aquesta manera seria possible establir un pagament per a la primera distribució. Aquest model es fa servir, per exemple, en els projectes de programari fets a mida. 2.Pagar per fer-ne ús a través d'una xarxa. Com que les llicències de codi obert només s'apliquen a la distribució del programari i no a l'ús del programari en si, qualsevol programa de codi obert modificat que pugui fer-se servir a través d'una xarxa pot mantenir-se en secret, limitat a un ús intern. Aquest model seria vàlid en el cas del programari que es pot utilitzar a través d'Internet, per exemple els motors de cerca o els mercats en línia.430 3.Llicències dobles. Fa possible que el titular del copyright pugui treure al mercat el mateix paquet de programari amb contractes de llicència diferents. Els usuaris que no vulguin estar limitats per una llicència de codi obert poden comprar-ne una altra de privativa. Aquesta opció és atractiva per al programari integrat especialment amb aplicacions comercials. Afegir la possibilitat d'adquirir llicències privatives a un producte de codi obert bàsic seria una altra alternativa dintre d'aquest mateix model. A més del copyright, també es possible establir un preu basant-se en altres drets de propietat intel·lectual. Les marques comercials i les llicències de patents poden mantenir-se, però sense oblidar que complir els requisits de còpia i distribució lliures característics del codi obert pot limitar substancialment la possibilitat de fer-les servir de forma efectiva. A la pràctica, per exemple, una marca comercial podria ser més útil donant suport als models de llicència indirectes i evitant fins a cert punt la ramificació del programari.431 7.1.2 Com controlar el desenvolupament? El codi obert també és un repte des del punt de vista de la coordinació del desenvolupament del programari, un requisit normalment necessari a l'hora d'establir un preu. El desenvolupament, però, no es pot fer mitjançant el copyright o l'obligació de mantenir en secret el codi font. Cal fer servir aquí mètodes alternatius que s'adaptin a les innovacions de programari. Per poder controlar el desenvolupament es requereix un projecte marcadament tècnic que deixi la porta oberta perquè puguin participar els programadors més qualificats. Sempre hi ha la possibilitat d'establir rutes diferents en un mateix projecte si alguns programadors o usuaris no estan satisfets, per exemple, amb la direcció tècnica, la gestió o fins i tot els aspectes relatius a les llicències d'un projecte concret. 432 Són molts els desenvolupadors que consideren com a part fonamental de la filosofia del codi obert que les llicències permetin el desenvolupament de productes en competència (ramificacions), tot i que només es considera una resposta en última instància al bloqueig del desenvolupament.433 Per a les empreses que treballen en entorns típics de codi obert, com ara la infraestructura d'Internet, evitar la ramificació és una qüestió crucial per a la seva viabilitat comercial. Un exemple n'és SSH Communications Security Corp, una iniciativa empresarial finesa que apareixia l'any 2000 a l'últim lloc de la llista de les punt.com a la borsa d'Hèlsinki, amb un creixement molt ràpid. SSH es remunta a principis dels anys noranta, quan Tatu Ylönen va desenvolupar un protocol segur intèrpret d'ordres anomenat SSH que va acabar convertint-se en un estàndard de facto d'Internet.434 Les clàusules de la llicència del primer SSH són característiques del codi obert, en afirmar: "Per la meva part, el codi que he desenvolupat per a aquest programa pot fer-se servir lliurement per a qualsevol finalitat." El 1995 Ylönen va crear una empresa per tal de comercialitzar l'SSH i va canviar les condicions de la llicència, que va passar a ser privativa. Mai més no va treure cap una nova versió d'SSH amb llicència de codi obert. Més endavant, com que la demanda de l'SSH no parava de créixer, va sortir una ramificació de codi obert. Tot i que les condicions de llicència d'SSH Communication Security Corp eren més flexibles per als usuaris no comercials (per exemple universitats), no ho van ser prou per als entusiastes del programari lliure que volien integrar l'SSH als seus projectes sense pagar drets d'autor o altres cànons de propietat intel·lectual. El projecte OpenBSD va aconseguir els codis font inicials subjectes a clàusules menys estrictes i va treure una ramificació anomenada OpenSSH a finals de l'any 1999.435 El projecte va reescriure totes les parts d'SSH subjectes a llicències de tercers o que violaven potencialment patents de programari i lleis de control d'exportació criptogràfica.436 OpenSSH conclou la seva pàgina d'introducció fent una afirmació prou reveladora: "SSH. Per fi completament lliure." OpenSSH va trigar un any a fer-se més popular que SSH. A començaments de l'any 2001 SSH Communication Security Corp va amenaçar d'iniciar un litigi pel nom comercial per tal d'obligar el projecte a canviar de nom.437 Actualment la versió comercial d'SSH coexisteix amb una altra de codi lliure, però SSH Communication Security Corp no controla el desenvolupament de la versió lliure, que ja ha superat l'èxit de la versió original comercialitzada. La versió comercial ha patit una greu retallada de la seva quota de mercat: Figura 19. Ús d'SSH als servidors d'Internet. 438 7.2 Estudi de cas 1: Les llicències lliures i el programari dels sistemes operatius 439 El primer dels estudis de cas que estudiarem descriu de quina manera afecten alguns tipus de llicència de codi obert la competència en el mercat dels sistemes operatius dels microordinadors. Compararem les polítiques de llicència dels sistemes operatius Microsoft Windows, Apple Os X i GNU/Linux. Argumentarem perquè creiem que el programari lliure i de codi obert han estat els factors de canvi més significatius en els mercats de sistemes operatius per a microordinadors en els últims anys i com ha estat possible que entrin nous agents en un mercat relativament tancat fins al punt de canviar el model comercial dels que ja hi eren. I tot això sense una estratègia de codi obert comuna, sinó simplement mitjançant l'adaptació del codi obert en l'estratègia de cada plataforma d'una o altra manera. 7.2.1 Introducció El programari dels sistemes operatius va esdevenir un producte independent del maquinari a la dècada dels anys setanta. Els primers sistemes operatius interoperables coneguts van ser els sistemes Unix d'AT&T l'any 1971. No obstant, als anys setanta i vuitanta els sistemes Unix no s'oferien per a microordinadors. Els primers microordinadors de finals dels anys setanta incorporaven els seus propis sistemes privatius. 440 A començaments dels vuitanta existien, bàsicament, dos tipus de sistemes operatius per a microordinadors al mercat: els controlats pels fabricants de maquinari, com ara Apple, Commodore i Atari, i els nous mercats no controlats basats en l'estàndard de maquinari PC. El fet que el maquinari dels PC fos obert implicava que, en principi, cap fabricant no podia controlar en solitari el programari del sistema operatiu. De seguida, però, van esdevenir estàndards de facto dels PC els sistemes operatius de Microsoft, primerament Microsoft Disk Operating System (MS-DOS) i posteriorment Microsoft Windows. La informàtica evolucionava i s'obria camí, però el monopoli de Microsoft sobre el sistema operatiu del maquinari PC només era qüestionat de tant en tant amb la introducció de, per exemple, interfícies gràfiques d'usuari i funcions de xarxa. Però Microsoft va resistir. A finals dels anys noranta els sistemes Unix compatibles van començar a oferir-se finalment amb els PC. Linux i algunes variants de Berkeley Software Distribution (BSD) combinades amb programari de sistemes GNU van començar a tenir més acceptació en el maquinari PC més econòmic i els servidors d'Internet. Segons West and Dedrick, aquesta nova tendència creixent envers el codi obert va estar motivada per la necessitat d'obtenir implementacions Unix barates i lliures, l'extensió d'una filosofia diferent del concepte de propietat del programari i el creixement d'Internet com a plataforma de desenvolupament i màrqueting.441 A més, els sistemes privatius Unix dels ordinadors centrals i les estacions de treball van simplificar-se per tal d'adaptar-los al maquinari més econòmic. A principis del nou mil·leni la competència dels sistemes operatius en el mercat havia tornat a canviar. Microsoft Windows encara és líder, però ha de competir, especialment en el mercat dels ordinadors de taula, amb el nou Apple OS X basat en un nucli compatible amb Unix de codi obert. En el mercat dels servidors, la competència es va produir entre distintes variacions d'implementacions Unix lliures molt desenvolupades (GNU/Linux principalment, però també diferents variants de la BSD). Microsoft, líder del mercat, ha estat atacat per totes dues bandes, a través de productes de programari de codi obert o parcialment obert. L'estudi de cas que explicarem a continuació s'estructura de la següent manera. Primer estudiarem de forma general l'estat actual del mercat dels sistemes operatius dels microordinadors. A continuació analitzarem des d'una perspectiva històrica el desenvolupament dels diferents models de llicència dels sistemes operatius i la seva influència sobre els models d'empresa de Microsoft Windows, Apple OS X i GNU/Linux.442 També demostrarem que l'estratègia del sistemes de codi obert no ha estat unitària, sinó que els diferents actors del mercat l'han adaptat a les seves estratègies de sistemes operatius d'una manera o una altra. Com a conclusió de l'estudi, argumentarem que el programari lliure i els components de codi obert han tingut un enorme impacte en el mercat dels sistemes operatius dels microordinadors en els últims anys. 7.2.2 Perspectiva general del mercat La taula següent mostra les característiques dels diferents sistemes operatius disponibles a començaments de l'any 2000. Taula 12. Competència entre els diferents sistemes operatius per a microordinadors a començaments de l'any 2000. Val la pena comentar alguns aspectes de la taula. En primer lloc, les estimacions de les quotes de mercat s'han de considerar amb reserves. Es basen en l'ús d'equips de taula i indiquen només la popularitat del sistema operatiu en qüestió en aquest tipus d'ordinadors. No són un bon indicador de la grandària total i la vàlua del mercat dels sistemes operatius, format tant per ordinadors de taula com per servidors.443 En segon lloc, no existeix una única font d'ingressos. En aquest sentit, es podria descriure acuradament Microsoft com a empresa de programari tradicional que obté el gruix dels seus ingressos amb la venda de llicències. Per la seva part, Apple encara funciona amb el model de sistema operatiu controlat pel maquinari: OS X només funciona amb el maquinari d'Apple i, per poder fer-lo servir, s'ha d'adquirir primer un dels seus ordinadors. Finalment, els sistemes GNU/Linux gairebé mai no es venen per separat, sinó que se solen instal·lar en grans infrastructures informàtiques. En aquest cas, els ingressos es generen indirectament, per exemple a través de serveis i assistència.444 7.2.3 Marc d'estudi Per conèixer millor l'impacte de les llicències de codi obert i de programari lliure en la competència dels sistemes operatius s'han analitzat detalladament els models de llicència emprats pels tres sistemes operatius principals. L'estudi es va dur a terme recopilant primerament informació sobre el mercat dels sistemes operatius a partir de la literatura especialitzada, les pàgines web dels venedors i entrevistes fetes a experts disponibles a Internet. A continuació, s'ha contrastat aquesta informació amb la teoria econòmica adient. Cada sistema operatiu s'analitza des de tres perspectives diferents: rerefons històric, model de llicències i impacte en la competència. La primera qüestió té a veure amb l'estructuració característica de la llicència i la titularitat del programari del sistema operatiu. Les tres opcions existents són la llicència privativa (hi ha un propietari), la recíproca (ningú no és propietari) i la permissiva (tothom és propietari). GNU GPL és un cas típic de llicència recíproca, mentre BSD i Apple Public Source License són més aviat permissius. La taula 13 és un resum de les opcions de llicència emprades als diferents nivells dels sistemes. Aquestes opcions de llicència i les seves implicacions s'expliquen més endavant en detall, juntament amb cada sistema operatiu. Taula 13. Principals opcions de llicència a diferents nivells lògics dels sistemes operatius. En segon lloc estudiarem diferents alternatives de model comercial. Els venedors dels sistemes operatius poden beneficiar-se de l'estratègia dels components a través del programari privatiu integrat, com ara interfícies d'usuari, maquinari i sistemes operatius. També poden prendre part del mercat dels productes i serveis complementaris, incloent-hi la participació en comunitats de codi obert. Partim de la base que les possibilitats del model comercial depenen, per exemple, del tipus de llicència escollit o de si el sistema operatiu competeix en el mercat dels ordinadors de taula o bé dels servidors i les empreses. En tercer lloc, analitzarem l'entorn competitiu de cada sistema operatiu. De quina manera han establert els venedors de sistemes operatius els seus trets diferenciadors? Quins són els seus avantatges competitius? Ens interessa especialment de quina manera ha afectat el codi obert l'entorn competitiu i si s'ha fet servir com a eina competitiva. 7.2.4 Microsoft Windows Rerefons històric. La primera versió de Microsoft Disk Operating System (MS-DOS) va sortir al mercat amb els sistemes IBM PC de l'any 1981. La primera versió de Microsoft Windows (inicialment només era una extensió en forma d'interfície gràfica de l'usuari de l'MS-DOS) va ser anunciada el 1983 i llançada al mercat el 1985. Des del primer moment, el sistema operatiu de Microsoft s'ha comercialitzat com a programari amb llicència. El preu de producte de consum assignat se situa entre un 5 i un 10 % del preu total d'un ordinador PC domèstic.445 A mesura que les interfícies gràfiques d'usuari s'anaven convertint en l'estàndard, Microsoft ja havia aconseguit consolidar l'MS-DOS en els sistemes PC. Els seus principals competidors, com ara l'OS/2 d'IBM, Graphical Environment Manager (GEM) de Digital Research o GeoWorks (GEOS) de Berkeley Softworks van desaparèixer a la dècada dels noranta. Tot i que és possible que els productes competidors fossin tecnològicament més avançats en aquell moment en comparació amb Windows, tots eren més o menys incompatibles amb els programes d'MS-DOS. IBM va ser qui va oferir més resistència amb el seu OS/2. Al principi tenia també el suport de Microsoft, però mai no va atènyer la popularitat suficient per atraure els desenvolupadors d'aplicacions, que treballaven per a un mercat Windows en creixement. Model de llicències i codi obert. El model de llicència de Microsoft ha anat desenvolupant-se al llarg del temps. Des del començament, Microsoft ha estat la força motriu de les llicències de programari al mercat de masses. L'empresa ha estat pionera de la introducció de llicències d'usuari final econòmiques i relativament senzilles en el programari comercial. Posteriorment ha creat diferents estratègies i criteris de preus. Les seves llicències es vinculen al programari en si (número de còpies), als grups d'usuaris (estudiants, ús domèstic) o al maquinari (vendes OEM). La progressiva universalització del programari ha fet que Microsoft integri altres aplicacions d'oficina, Internet i multimèdia al seu sistema operatiu. Des d'una perspectiva econòmica, Microsoft ha estat un cas paradigmàtic de com fer servir la xarxa per beneficiar-se d'uns ingressos creixents i crear una barrera inexpugnable per als venedors.446 No es estrany, doncs, que les autoritats antimonopoli hagin seguit de prop les pràctiques d'integració i llicència de Microsoft i l’empresa hagi estat l'objectiu de nombrosos litigis infructuosos.447 Recentment, l'empresa ha canviat efectivament el seu model de llicència empresarial, d'un model de llicències no contínues a un de cànons de renovació anuals. Aquesta "Assegurança de Programari Microsoft" va introduir els cicles de llicència de 3 anys. La crítica diu que l'empresa utilitza la seva força de bloqueig per forçar els usuaris a actualitzar els seus sistemes més sovint del que realment es necessita.448 A més, Microsoft ha obert, fins a cert punt, el codi font Windows als seus clients. Els clients més importants i especialment els governs són escèptics en quant a la utilització dels productes, el codi font dels quals no poden inspeccionar per tal de trobar errors de seguretat i possibles portes secretes. Per tant, Microsoft ha introduït la "Shared Source Initiative", (Iniciativa de Font Compartida), que ha obert el codi font de Windows de cara a inspeccions sota acords estrictes de no divulgació. A diferència d'un codi obert normal, als usuaris no se'ls permet fer cap canvi al codi font o utilitzar-ho per als seus propis productes.449 Microsoft ha suavitzat subseqüentment els termes de llicència de part dels seus productes. Per exemple, la Llicència de Font Compartida per al Kit d'inici de Microsoft ASP.NET gairebé s'avindria a la definició de codi obert, donat que els usuaris poden crear obres derivades i distribuir-les mentre mantinguin l'acord de llicència original intacte. No obstant, una restricció important és que no es permet als usuaris barrejar el codi font amb altres codis sota una llicència recíproca de codi obert:450 "No es permet combinar o distribuir el Programari amb cap altre programari que tingui llicència sota els termes que miren de requerir que el Programari (o qualsevol propietat intel·lectual en ell) sigui proveït en forma de codi font, amb llicència a tercers per permetre la creació o distribució d'obres derivades, o distribuïdes gratuïtament". En general, la postura de Microsoft sobre el codi obert ha canviat considerablement Actualment, la postura de l’empresa sobre el codi obert és encara d'alguna manera crítica i de rebuig però no totalment oposada:451 ".... El principal benefici del model OSS és que permet a qualsevol programador fer avançar les idees del desenvolupador original, permetent l'aparició de "comunitats" globals de programadors que contribueixen a importants projectes d'OSS. Un altre benefici obvi és que hi ha un cost molt petit o cap cost en l'obtenció del programari de codi obert, tot i que la formació, servei o despeses de manteniment poden ser més elevades durant la vida útil del programari. El principal inconvenient de l'OSS és que no hi ha cap entitat que pugui ser considerada responsable de les contribucions individuals d'un exèrcit dispers de programadors. També existeix la possibilitat que una versió d'un programa OSS no funcioni totalment o parcial amb altres versions. A més, no queda clar si el model d'OSS és sostenible per a les empreses de programari a llarg termini." No obstant, Microsoft encara marca una estricta diferència entre GNU GPL i altres llicències de codi obert. L'empresa ha utilitzat recursos considerables per al lobbisme contra l'ús del GNU GPL per part de governs i investigadors finançats públicament, argumentant que la GPL amenaça "l'ecosistema del programari".452 Mentre el codi obert reforci i complementi el negoci dels productes Microsoft i no amenaci el negoci de les llicències sobre la seva propietat intel·lectual, aquesta sembla una política racional d'acord amb la teoria econòmica. Impacte sobre la competència. A causa de la seva posició dominant en el mercat (especialment en el dels ordinadors), és lògic suposar que Microsoft només pot perdre quota de mercat. Així doncs, els seus moviments competitius en mercats de sistemes operatius són més o menys defensius. Per exemple, l'adopció dels programes de font compartida limitada és clarament enfocada a contrarestar l'amenaça que representa el codi obert. Microsoft també ha fet servir altres estratègies. L'infame "Document Halloween", una nota interna de Microsoft sobre el codi obert que va sortir a la llum, mostra un punt de vista interessant (tot i que acolorit) de les seves opcions.453 Primer, Microsoft pot utilitzar tot el seu poder de mercat per tal de desviar els estàndards cap a l'ús de components privatius. Aquest comportament s'anomena sovint "estendre i abraçar" Un exemple ben documentat d'aquesta estratègia és el protocol Kerberos, al qual Microsoft va fer canvis molt subtils per tal d'impedir que els servidors Unix interactuessin amb clients de Windows.454 Per suposat, aquesta estratègia dóna per fet que Microsoft controla actualment algun component essencial del sistema operatiu que pot ser canviat sense notificar als competidors. La segona possible estratègia és l'ús agressiu dels drets de propietat intel·lectual i especialment de les patents de programari. No obstant, cal observar que les empreses amb grans carteres de patents, IBM inclosa, que té la cartera de patents més gran de totes, tenen ara un gran interès comercial en GNU/Linux. Aquestes empreses molt probablement farien front a qualsevol moviment per part de Microsoft contra GNU/Linux amb càrrecs similars o més grans encara de violació de patents. Com ja s'ha dit en el capítol anterior, algunes de les grans empreses, IBM inclosa, ja han compromès algunes de les seves patents amb desenvolupadors de codi obert. Microsoft també ha invertit en informàtica fiable.455 La informàtica fiable protegeix els arxius amb l'autenticació del maquinari, d'aquesta manera, en principi, és possible controlar tot allò que els usuaris instal·len en els seus sistemes. Com ja s'ha dit abans en aquest llibre, la informàtica fiable és una amenaça potencial per als desenvolupadors de codi obert, encara que fins ara cap dels suposats riscos s'ha fet realitat.456 De fet, tot i que Microsoft teòricament podria actuar contra el codi obert de moltes maneres, qualsevol moviment en aquest sentit podria arriba a ser contraproduent. Els usuaris no volen limitar-se a un sol venedor si tenen altres alternatives. A mesura que el producte de codi obert va obtenint un major suport per part de la indústria, es fa pràcticament impossible per a una empresa intentar apartar el codi obert dels mercats. Així doncs, Microsoft ha anat canviant lentament i de ser un espectador crític ha passat a ser un participant cautelós.457 7.2.5 Apple OS X Rerefons històric. Apple Macintosh tenia una posició forta en el mercat de microordinadors als anys 80. No obstant, als anys 90 l'empresa va tenir problemes, en gran part causats per la seva antiquada tecnologia de sistema operatiu. Després de revisar les possibilitats, Apple va adquirir NeXT, una empresa encapçalada pel cofundador d'Apple, Steve Jobs. Sota el lideratge de Jobs, a finals dels 90 es va desenvolupar una sistema operatiu completament nou anomenat Mac OS X.458 En resum, Apple OS X es pot descriure com una versió més desenvolupada dels sistema operatiu NeXTStep de NeXT amb una nova interfície gràfica d'usuari i compatibilitat amb l'antic programari de Mac. El nucli de l'OS X i altres parts importants - seguint el disseny de NeXTStep - es basen en el de la BSD d'Unix i són de codi obert. La BSD per si mateix no ha estat mai un sistema operatiu popular però el seu patrimoni perdura. El 1993, BSD va ser connectat al maquinari barat d'Intel per William Jolitz, i posteriorment tres projectes separats - FreeBSD, NetBSD i OpenBSD - es van crear per continuar amb el desenvolupament de la BSD. No obstant, el Mac OS X d'Apple és, de totes, la primera implementació popular de BSD per a microordinadors.459 Model de llicències i codi obert. La interfície de l'usuari i moltes altres eines del sistema relacionades amb la tecnologia OS X són privatives. Així doncs, el paquet de sistema operatiu OS X complet té una llicència similar a Microsoft Windows. No hi ha requeriments de llicència per a les aplicacions que funcionen amb Mac OS X. Una cultura tradicional del programari de Mac potser ha afavorit llicències privatives tals com la del programari de prova per a programes d'aficionats. No obstant, OS X ha proporcionat accés al sistema per a molts dels programadors de codi obert GNU/Linux A causa de la llicència BSD, Apple ha pogut rellicenciar tot el nucli Mac OS X sota els seus propis termes. El nucli, anomenat Darwin, utilitza la Llicència de Font Pública Apple, que és acceptada com a llicència de programari lliure per la Free Software Foundation. El seu plantejament ha estat mantenir el codi font del nucli obert i tenir bons contactes amb la comunitat del codi obert. Per exemple, Apple ha contractat desenvolupadors clau incloent Jordan Hubbart, que és un dels fundadors de FreeBSD i va ser un membre essencial del grup de desenvolupament durant molt temps. En aquests moments, Apple diu que utilitza FreeBSD com a sistema operatiu de referència. Apple també posa les seves modificacions a disposició de la comunitat fins i tot quan la llicència no ho requereix. D'acord amb la secció de FAQ de Darwin, la raó és la següent:460 "Tot i que les llicencies BSD no requereixen que les empreses publiquin les seves fonts, les bases de codi divergents són molt difícils de mantenir. Creiem que el model de codi obert és la forma més efectiva de desenvolupament per a certs tipus de programari. Ajuntant la nostra experiència amb la comunitat de desenvolupament de codi obert, esperem millorar la qualitat, rendiment i el conjunt de funcions del nostre programari". Impacte sobre la competència. Teòricament, el plantejament d'Apple agafa el millor de cada model. El Darwin de codi obert i les bones relacions amb la comunitat van fer possible que Apple atragués les grans xarxes de comunitats al voltant de diferents variants de BSD. La bona interoperativitat amb Unix va permetre també la facilitat de connexió des d'abundants grups d'aplicacions de servidor. El codi obert ha ajudat als venedors de maquinari a connectar les seves unitats de disc a Apple. Tanmateix, Apple ha treballat en col·laboració amb Microsoft i la majoria dels estàndards privatius controlats per Microsoft són suportats per OS X (formats d'arxiu, extensions d'Internet). Per acabar, però potser és el més important, Apple tenia el control de la interfície d'usuari OS X, cosa que li va permetre diferenciar el producte de la resta de variants d'Unix.461 Malauradament, la realitat del mercat ha malbaratat d'alguna manera el plantejament d'Apple. Encara que Darwin hagi estat connectat a un maquinari Intel, sense la interfície d'usuari és més o menys inútil. Això ha limitat la base de desenvolupadors al nucli d'usuaris de Macintosh, que ja tenien el maquinari d'Apple. Això explica també per què Darwin no ha tingut un èxit similar al que va assolir Linux. També és important observar que Apple no es pot beneficiar directament del desenvolupament de Linux perquè no és possible afegir programari de GPL a Darwin. 7.2.6 Distribucions GNU/Linux Rerefons històric. Les històries de GNU i Linux ara ja són ben conegudes i fàcilment accessibles a Internet. D'una banda, tenim Richard Stallman, Free Software Foundation i GNU GPL, implementat per primer cop el 1989. D'altre banda tenim Linus Torvalds and Linux. Torvalds havia començat a desenvolupar el seu nou sistema operatiu el 1991. Linux va ser la primera implementació d'Unix pensada per a microordinadors. El 1992, Torvalds va decidir demanar llicència Linux sota GNU GPL, i subseqüentment tot el codi font escrit per nombroses contribucions al nucli de Linux va quedar sota aquella llicència. La majoria d'eines de sistema de Linux es van agafar del projecte GNU i d'altres fonts, BSD inclosa. Linux es va convertir en el nucli del nou sistema operatiu. Més tard, la Free Software Foundation i Stallman han exigit que el sistema operatiu complet basat en els components principals del projecte GNU s'anomeni GNU/Linux. Tot i que tècnicament potser sigui pertinent, la premsa comercial fins ara no ha fet cas del desig de Stallman. En aquesta tesi, no obstant, seguim la recomanació de Stallman per tal d'emfasitzar les diferències en els components d'un sistema operatiu (nucli, interfície d'usuari, eines de sistema, etc...). Model de llicències i codi obert. La majoria del programari en les distribucions de GNU/Linux tenen llicència GNU GPL. La patent especifica que el programari s'ha de poder copiar, distribuir i modificar lliurement. A més, el codi font ha de ser obert i disponible pràcticament de manera gratuïta. No es permet l'ús del copyright GNU GPL en els treballs derivats (tal i com la llei ho defineix) sota qualsevol altre llicència que no sigui GNU GPL. Malauradament, la interpretació del punt anterior queda bastant oberta. GNU/Linux inclou també un programari de sistema essencial llicenciat sota altres termes. La Free Software Foundation ha utilitzat, per exemple, altres termes de llicència per als seus compiladors de programació de llenguatge. La idea és que qualsevol programa nou creat en GNU/Linux - essent potser un derivat del compilador, parlant en termes tècnics- no queda automàticament sota GNU GPL. La interpretació actual del GNU GPL i obres derivades és que les aplicacions privatives i les eines del sistema es poden desenvolupar, gestionar i fins i tot vendre amb llicències privatives per a Linux. No obstant, la norma és que ha de ser possible executar qualsevol aplicació d'aquestes característiques de manera separada (utilitzant només mòduls d'execució dinàmics) d'altres programes, incloent-hi el nucli.462 Una part important de GNU/Linux són les interfícies d'usuari basades en el sistema de finestres X11. X11 té llicència amb termes liberals similars a BSD, però les interfícies gràfiques d'usuari més populars, KDE i Gnome incloses, tenen GNU GPL. Els grans problemes del seu desenvolupament han estat la poca facilitat d'ús i la manca de codi obert GUI. Desenvolupar un component important de sistema operatiu de programari lliure des de zero ha resultat ser un projecte que demana temps. Impacte sobre la competència. En certa manera, el GNU/Linux no és un producte a punt per ser utilitzat. És un conjunt d'eines indiferenciades i components que es pot utilitzar com a tal o ser adaptat per a diferents necessitats. Hi ha moltes empreses que distribueixen o d'alguna manera utilitzen GNU/Linux sota diferents models comercials, tals com Red Hat i Novell per a ordinadors de taula i servidors, i MontaVista per a sistemes incrustats. Les grans empreses de programari, IBM, Oracle i SUN incloses, recolzen el desenvolupament de Linux i l'utilitzen per vendre el seu programari privatiu d'aplicació empresarial que funciona amb Linux.463 Per exemple, SUN declara a la seva pàgina web: "Set productes de Sun ONE són disponibles avui en dia en Linux -Application server, Directory server, Web server, Active Server Pages, Studio, Grid Engine i Message Queue- i ja existeixen plans per a llençar més en un futur proper." En certa manera, GNU/Linux funciona com una xarxa oberta que proporciona oportunitats a les empreses que venen productes relacionats i interoperables o serveis als propis membres de la xarxa. Per tant, potser es més apropiat no considerar GNU/Linux com a competidor directe de Microsoft Windows o Apple Mac OS X. Primer, les distribucions GNU/Linux tenen una quota de mercat mínima entre els usuaris d'ordinadors. A més, Microsoft ha dubtat en donar suport a Linux, i els problemes d'interoperabilitat amb el sistema operatiu dominant han fet que sigui difícil accedir al mercat dels consumidors. En segon lloc, els subministradors d'aplicacions per a empreses s'apoderen d'una gran quota de mercat en els servidors, fent servir GNU/Linux com a plataforma independent i barata per a les seves aplicacions. Aquestes aplicacions poden funcionar també en diferents sistemes operatius, incloent el dels subministradors (per exemple IBM AIX i SUN Solaris) 7.2.7 Reflexions finals Des d'una perspectiva històrica, sembla clar que els darrers anys la llicència del codi obert ha canviat els mercats de programari de sistema operatiu. El fet és que avui les principals alternatives de sistema operatiu són en totalitat o parcialment Unix o Microsoft Windows. Deu anys enrere, Microsoft havia assolit el monopoli de facto dels sistemes operatius de microordinadors, amb tan sols Apple Macintosh que el seguia de molt enrere. Avui dia, Apple i el nou competidor GNU/Linux tenen una posició més forta gracies als mètodes de desenvolupament de codi obert i el ràpid creixement d'Internet i de la informàtica en xarxa. No obstant, sembla que no existeix una estratègia de sistema operatiu de codi obert que satisfaci a tothom. El model de desenvolupament de comunitat oberta va garantir un ràpid creixement de GNU/Linux. Qualsevol pot descarregar, modificar i distribuir el codi font de tot el sistema operatiu de manera gratuïta. Per comparar, el Mac OS X d'Apple només té un nucli de codi obert amb un model de desenvolupament controlat per Apple. Les altres parts del sistema operatiu, inclosa la interfície d'usuari, són privatives i tot el sistema és de pagament.. Finalment, la resposta de Microsoft al codi obert ha estat la seva iniciativa de font compartida, a bastament discutida. Alguns usuaris institucionals d'importància han obtingut accés limitat a veure parts del codi font de Windows sota acords específics de font compartida. Bàsicament, Microsoft encara creu en el model de desenvolupament i llicència totalment privatiu. Per tant, pot ser difícil comprendre de quina manera funciona el codi obert en tant que eina competitiva. Encara queda molt per estudiar. Les poques dades que hem presentat en aquesta secció poden ser resumides de la següent manera: El codi obert i el programari lliure han demostrat ser una poderosa manera de normativitzar i estabilitzar noves tecnologies de sistemes operatius i de competir contra els poders establerts del mercat. Pel que fa al mercat dels ordinadors, el seu impacte ha estat limitat principalment a causa dels problemes de compatibilitat i ús (els venedors de sistemes operatius són captius). En els mercats dels servidors i d'aplicacions per a empreses han tingut més èxit, basat en els avantatges de la tecnologia independent estandarditzada i d'altres funcions tècniques (la captivitat dels agents és menor). Els components privatius són encara un gran factor competitiu, i encara queden grans àrees del mercat en ordinadors (per exemple interfície d'usuari) i servidors (per exemple aplicacions d'empresa), sense gran impacte del codi obert, d'on els venedors de productes privatius poden generar ingressos. 7.3 Estudi de cas 2: Llicència dual i programari incrustat 464 Hem observat en els capítols anteriors que els desenvolupadors a vegades obtenen una llicència dual per als seus projectes a causa de la incompatibilitat de llicències. En aquesta secció, analitzem com la llicència dual es pot utilitzar com a model comercial. L'evolució i funcionalitat del model de llicència dual s'explica a través de tres casos pràctics: Sleepycat Software Inc, TrollTech AS, i MySQL AB. Cadascuna d'aquestes empreses és una nova empresa de codi obert que ha estat capaç de construir una gestió profitosa basada en el model de llicències. Al final de la secció es parla dels requeriments legals, les implicacions econòmiques i les limitacions pràctiques de la llicència dual. 7.3.1 Com funciona la llicència dual? La llicència dual barreja els models de codi obert i d'empresa privativa. La dualitat significa que el model combina el mecanisme de distribució de programari lliure amb el sistema comercial tradicional de productes de programari. Tècnicament tan sols hi ha un producte genèric, però amb dues llicències: Una per a la distribució lliure i ús lliure, i l'altra per a altres usos (privatius). El model de llicència dual difereix del model de programari lliure pur de diverses maneres. En primer lloc, la comunitat de desenvolupament no té el poder de desenvolupament per iniciar productes competidors (ramificacions). El copyright i el control del desenvolupament del producte principal queden en mans d'un agent únic: el desenvolupador original. Per tal de poder obtenir llicència del producte amb uns termes diferents dels de codi obert es requereix tenir la propietat completa de tots els drets del producte. En segon lloc, els usuaris de la llicència lliure tenen l'opció d'obtenir una llicència privativa. Si un producte de programari amb obligació de reciprocitat - com per exemple, el terme 2b) del GNU GPL - s'incrusta dins d'un altre producte, llavors el producte combinat hauria de ser distribuït també gratuïtament. Una llicència privativa pot alliberar l'usuari d'aquesta restricció. D'aquesta manera, les empreses de productes de tercers també esdevenen possibles. Des de la perspectiva de l'usuari, la llicència dual es pot descriure com indiscriminant. La figura 20 descriu el model de llicència dual amb més detall. Figura 20. Corrents de llicència d'un producte genèric en un model de llicència dual simplificat. Anem a mirar la figura 1 de baix a dalt. A la part baixa hi ha usuaris de programari dividits en dos segments. El programari amb llicència dual (producte genèric) és llicenciat amb obligació de reciprocitat al primer segment d'usuaris anomenat "usuaris de codi obert", i amb llicència comercial al segment dels altres usuaris anomenat "clients". La fletxa que va dels usuaris de codi obert als clients, indica que quan els usuaris de codi obert difonen l'ús del programari, tendeixen a arribar als límits de l'ús gratuït. Per exemple, els problemes de reciprocitat, suport comercial, requeriments de garantia o raons similars poden convèncer-los de comprar una llicència comercial (privativa). Sobre producte genèric hi ha dos segments de desenvolupadors. A l'esquerra es troba la comunitat de desenvolupadors de codi obert, que pot oferir solucions a errors i contribucions al codi, amb els drets de copyright en poder dels desenvolupadors del producte principal. A la dreta hi apareixen els socis de desenvolupament comercial, que desenvolupen els components essencials del producte genèric; aquests poden transferir el copyright del component o donar llicència (potser l'opció més corrent) als desenvolupadors principals. 7.3.2 Marc d'estudi Tres empreses de codi obert que utilitzen el model de llicència dual van ser seleccionades per una anàlisi més detallada: Sleepycat Software Inc, TrollTech AS, i MySQL AB. Aquestes empreses van ser seleccionades principalment perquè són les primeres usuàries duradores, conegudes i reeixides, del model de llicència dual.465 L'estudi es va realitzar recollint informació de les pàgines web de les empreses, amb referències a entrevistes amb executius disponibles a Internet i fent les preguntes complementàries directament als executius de les empreses. La presentació de cada empresa es divideix en tres parts: Antecedents històrics, model de llicència i eficiència del model. La primera qüestió és com les empreses han arribat al model de llicència dual. Resulta que cap de les empreses va començar amb un model de llicència dual. El concepte ha evolucionat amb el temps, i tant Internet com els mercats de codi obert (especialment aquells basats en Linux) han madurat. La segona qüestió és com funciona el model de llicència dual en cada cas. Quines llicències utilitzen les empreses i per quines raons? Aquí observem que, mentre les empreses potser utilitzen diferents llicències de programari lliure, totes elles tenen en comú una estricta obligació de reciprocitat. Finalment, considerem l'eficàcia del model de llicència dual en cada cas. Com es beneficien les empreses de l'ús lliure del seu programari, en comparació al model de publicació tradicional del programari? Han detectat les empreses cap problema de pirateria? Com gestionen els drets legals dels productes que tenen? Taula 14. Alguns atributs dels productes de codi obert estudiats. 7.3.3 Sleepycat Software Inc. Antecedents. Sleepycat Software Inc. desenvolupa i comercialitza BerkeleyDB (BDB). El producte és un sistema de base de dades incrustat que s'executa en diverses plataformes La primera versió de la BDB va ser escrita per Keith Bostic i Margo Seltzer el 1991. Va ser llançada sota llicència de BSD formant part de la distribució de BSD Unix, de la Universitat de Califòrnia, a Berkeley. BDB va ser distribuïda lliurement a través d'Internet, i en poc temps molts projectes, tant privatius com de codi obert, van començar a utilitzar el producte. Els termes de llicència de la BSD permetien àmplies possibilitats d'adopció del producte, fins i tot en projectes comercials, sense haver de pagar uns cànons als propietaris del copyright. A mesura que el producte va anar assolint més interès comercial, els programadors van decidir establir l'empresa Sleepycat Software Inc. com a propietària del copyright i desenvolupar més el producte. La següent versió va afegir funcionalitat tècnica i va ser encara més valuosa comercialment. La llicència Sleepycat es va atorgar el 1997. Des d'aleshores, BDB ha estat llicenciada sota dos models diferents.466 Model de llicència. El lloc web de Sleepycat declara respecte la seva política de llicència:467 "La llicència de codi obert de Sleepycat permet utilitzar Berkeley DB gratuïtament, amb l'única condició que si s'utilitza aquest programa en una aplicació que es vol redistribuir, el codi complet d'aquesta aplicació ha d'estar disponible i ser redistribuïble sota unes condicions raonables. Si no es vol donar a conèixer el codi font de l'aplicació, s'ha de comprar la llicència de Sleepycat Software." El director executiu de Sleepycat, Michael Olsen, ha descrit la utilització de la llicència privativa durant una entrevista:468 "Si una empresa vol redistribuir Berkeley DB com una part d'un producte privatiu, haurà de venir a Sleepycat i pagar-nos uns honoraris a canvi d'uns termes de llicència diferents. En tal cas, signarem un acord de llicència bastant convencional, autoritzant l'ús i la redistribució en codi binari, sense obligar-los a publicar la font." Efectivitat del model. El desenvolupament de BDB és dirigit des de dins de l'empresa. Totes les contribucions externes són afegides al producte genèric per desenvolupadors de l'empresa. Òbviament, el desenvolupament d'un motor de base de dades complex requereix entendre el funcionament en la seva totalitat. El desenvolupament de característiques afegides és difícil. Per això, l'opinió dels usuaris és útil sobretot a l'hora d'identificar problemes i proposar noves característiques. És possible canviar d'una llicència Sleepycat a una GNU GPL, però de moment sembla que no hi ha cap motiu immediat per fer-ho, ja que la llicència Sleepycat ha estat àmpliament acceptada per la comunitat partidària del programari lliure. La majoria dels ingressos de Sleepycat (al voltant del 75 %) provenen de la venda de llicències, i la resta són pels serveis. El lloc web de Sleepycat només promou la venda de llicències, cosa que és el seu canal principal de màrqueting directe. No es fa un seguiment de l'ús sota llicència gratuïta. Si es detecta un incompliment de la llicència, l'usuari haurà d'adquirir una llicència privativa o bé deixar d'utilitzar el producte.469 7.3.4 MySQL AB Antecedents. El producte de MySQL AB és un sistema de gestió d'una base de dades relacional. En un principi estava pensat com a servidor web, però ara s'ofereix també com a sistema de gestió de base de dades, i concretament per a usuaris de bases de dades incrustades. El desenvolupament va ser iniciat el 1996 per Michael Wide-nius i David Axmark, i el primer llançament important a Internet va ser el 1996. Des del principi, MySQL va ser comercialitzat sota els seus propis termes de llicència. (MySQL 1995) Aquesta permetia la distribució lliure i limitada i l'ús del producte amb una obligació de reciprocitat forta amb sistemes basats en Unix, Linux inclòs. Amb Windows, el model de llicència era de programari de prova, limitant la distribució i l'ús gratuït del producte. El seu model de negoci era essencialment de llicència dual en sistemes operatius basats en Unix i privativa en Windows. Com que la versió basada en Linux va esdevenir molt popular a Internet, la llicència gratuïta va ser canviada a GNU GPL per a totes les plataformes l'any 2000. Després d'això, el model de llicència ha estat només dual. El canvi de llicència va limitar l'àmbit de venda de llicències privatives, però també va fer que encara més usuaris s'interessessin pel producte. Finalment, el 2001 es va fundar la societat MySQL AB per tal de tenir la titularitat del copyright del programari de la base de dades amb els seus socis.470 Model de llicència. El copyright del producte es ven tant sota llicència GNU GPL com privativa. Els productes que inclouen la versió GPL s'han d'aquirir amb llicència GPL. La web de MySQL explica així la seva política de llicències:471 "Tant si el vostre programari s'ha adquirit sota Free Software License compatible amb GPL d'acord amb la definició de la Free Software Foundation, com si ho és sota l'aprovada per l'OSI, aleshores utilitzeu la nostra versió amb llicència GPL. Si d'alguna manera distribuïu una aplicació privativa i no esteu donant llicències i distribuint el vostre codi font sota GPL, heu d'adquirir una llicència comercial de MySQL. Si no n'esteu segurs, us recomanem que compreu les nostres llicències comercials de preus més econòmics. Efectivitat del model. El desenvolupament és dirigit per l'empresa. Com en el cas de Sleepycat, el producte és molt complex, i difícilment pot ser desenvolupat per tercers. L'any 2001, una altre empresa va intentar una ramificació, però va fracassar per no ser capaç de controlar el desenvolupament de programari.472 Els desenvolupadors de l'empresa comproven i reescriuen totes les contribucions per tal de no diluir la propietat del copyright del producte. Actualment, MySQL inclou un component principal desenvolupat per un tercer.473 L'empresa calcula que tenen menys problemes amb usuaris autònoms que amb empreses de programari privatiu; l'únic cas que ha acabat als tribunals ha estat amb la ramificació. Avui dia, MySQL AB obté més ingressos per vendes de llicències privatives que per altres conceptes, com marques i serveis. Els ingressos principals semblen provenir d'usuaris comercials incrustats. 474Per tal de comparar, l'ús als lloc web, mercat al qual anava dirigit inicialment el producte, sembla que funciona després del canvi de sistema de llicència com a eina de màrqueting per a l'ús en productes incrustats. 7.3.5 TrollTech AS Antecedents. El producte principal de TrollTech AS es diu Qt, i consisteix bàsicament en biblioteques de programació d'interfícies d'usuaris gràfiques. Qt pot ser utilitzat per a desenvolupar aplicacions gràfiques multiplataforma. Com a resultat d'això, els productes desenvolupats van afegir la funcionalitat de les biblioteques Qt. El desenvolupament de Qt va començar el 1992, i l'empresa va ser fundada el 1994 per Haavard Nord i Eirik Eng. El 1996, es va llançar Qt amb una llicència de codi obert bastant restringida, que no permetia la lliure distribució de modificacions i, per tant, conservava el control total de Troll Tech sobre el desenvolupament. En qualsevol cas, a causa de la disponibilitat del codi font, es va seleccionar Qt per utilitzar-lo en KDE, el qual va convertir-se ràpidament en un entorn d'escriptori lliure molt popular per als sistemes Unix i Linux. Mentre la seva popularitat I importància creixien amb KDE, la pressió de la comunitat del programari lliure per què permetessin la redistribució de les modificacions augmentava. El 1998, es va canviar la llicència a QPL, llicència recíproca pròpia de Troll Tech. QPL permet la distribució de modificacions com a pedaços independents. L'any 2000, Qt va ser finalment llançat també sota GNU GPL, permetent la distribució gratuïta de les modificacions del programari sencer. El llançament del GPL va ser també aplaçat per l'escepticisme dels fundadors envers el codi obert. 475 Model de llicència. El model de llicència de Qt és en essència el mateix que en el cas dels dos productes descrits anteriorment. Qt és venut sota llicències GPL, QPL i llicència privativa. Els productes fets amb les versions GPL o QPL han d'utilitzar la mateixa llicència gratuïta. El lloc web de Troll Tech afirma:476 "Segons el principi del "Quid Pro Quo", si preteneu obtenir un avantatge comercial amb la no distribució de la vostra aplicació sota llicència de codi obert, heu d'adquirir un nombre apropiat de llicències comercials de TrollTech. Si compreu llicències comercials, no teniu l'obligació de publicar el vostre codi font. Efectivitat del model. El desenvolupament es coordina a l'empresa. Abans de la introducció del QPL, els termes de llicència de Troll Tech garantien el control total de l'empresa sobre el desenvolupament. En qualsevol cas, actualment Qt conté alguns codis que no són propietat de Troll Tech AS, sinó que es distribueix sota una llicència molt permissiva per part de tercers. 477Des de la perspectiva de les llicències, la introducció de GPL inclou la possibilitat de ramificacions, però a la pràctica sembla que ha estat una excel·lent acció de màrqueting.478 Els ingressos de Troll Tech provenen de llicències privatives. Qt es comercialitza mitjançant una combinació de vendes directes, distribuïdors i socis estratègics. El paper de la versió gratuïta és fonamentalment el de fer créixer la base d'usuaris i comercialitzar el producte en l'entorn KDE.479 7.3.6 Quan té sentit la llicència dual? Llicències i temes de propietat intel·lectual. En qualsevol exemple de llicència dual, la llicència de codi obert inclou una obligació de reciprocitat forta. Com ja hem apuntat, la forta reciprocitat (també anomenada copyleft) vol dir que fins i tot les adaptacions i derivacions han de mantenir intactes els termes de la llicència. En altres paraules, si el codi font és inicialment distribuït gratuïtament, ningú no pot cobrar pel codi font en cap adaptació posterior. Les llicències de GNU GPL i Sleepycat són ambdues acceptades com a forma de copyleft per la Free Software Foundation.480 Encara que QPL no compleix la definició estricta que fa del copyleft la comunitat, de fet actua de la mateixa manera. Lerner i Tirole han argumentat que els productes de codi obert dirigits als desenvolupadors tendeixen a tenir llicències permissives.481 El model presentat en aquest cas pràctic contradiu la seva afirmació: En un model de llicència dual, l'empresa de programari utilitza una llicència recíproca altament restrictiva en un producte pensat específicament per ser utilitzat per desenvolupadors per a ús incrustat. Una possible explicació per aquesta contradicció és que el conjunt de dades estudiat per Lerner i Tirole consistia principalment en projectes no comercials a Sourceforge. Un altre requisit legal fonamental pel model de llicència dual és que l'empresa de programari tingui drets irrefutables sobre el producte de programari pel qual vol llicència dual. La propietat dels drets és bàsica perquè permet a l'empresa posar preu al seu programari, canviar la seva política de llicència i distribuir el programari sota diferents llicències. Un dels principals riscos d'utilitzar llicències de codi obert radica en el fet que la llicència pot diluir la propietat i fins i tot eliminar la possibilitat de llicència dual. Per això, la propietat dels drets s'ha de gestionar amb molt de compte. A qui ha escrit un nou programa o n'ha reescrit un de vell se li atorga el copyright de l'obra en exclusiva. De totes maneres, quan hi ha múltiples autors, la propietat del copyright també s'ha de repartir. Sota una obligació de reciprocitat forta, un procés de desenvolupament totalment obert i repartit sense una suficient definició dels drets no és apte per a cap empresa que pretengui fer vendes de llicència directa amb llicència dual. No ha d'existir cap obligació oculta en les contribucions al codi per part de tercers. Qüestions econòmiques. La llicència dual depèn també de diverses implicacions econòmiques a tenir en compte. En primer lloc, ha d'haver-hi una base de clients suficientment gran per al producte. Aquí, la llicència recíproca permet efectes de xarxa típics dels productes d'informació: el valor del producte per a l'usuari individual depèn del nombre d'usuaris que té. Amb la disponibilitat gratuïta i la distribució eficaç del producte a través d'Internet, no hi ha gaire limitacions al creixement exponencial de la base d'usuaris. En particular, el programari que depèn de components distribuïts per separat i que interactuen directament té un efecte de xarxa molt fort. Shy i Thisse han demostrat que quan els efectes de xarxa són forts, la còpia i distribució il·limitada del producte de programari porta a un equilibri en un paràmetre simplificat entre els competidors que no cooperen.482 En segon lloc, l'efectivitat de la llicència dual depèn de la discriminació de preus. Una empresa de programari que gestioni tots els drets sobre el producte pot concedir llicències segons la demanda del mercat.483 Per exemple, el nostre cas pràctic demostra que si hi ha una demanda pels productes tant individuals com incrustats, aleshores la llicència dual pot ser un model econòmicament viable. També cal dir que, en el cas del llicència dual, les polítiques de llicència (no les característiques del producte) són fetes a mida. Només aquells usuaris que s'aprofitin directament de l'ús del programari han de pagar per la llicència, i per als altres usuaris el pagament és més o menys opcional. En tercer lloc, sembla que no hi han requisits importants per a la protecció del copyright. Les poques dades que tenim ens indiquen que els usuaris corporatius a qui es demana que comprin una llicència privativa ho fan. També l'evidència empírica mostra que les còpies il·legals de programari, en general, han disminuït durant el període 1995-2000, pel que fa al mercat de programari.484 L'opció de llicència de codi obert pot enfortir aquesta tendència. Mentre el model tradicional de llicència de copyright es veu encara afectat per un gran nombre d'usuaris no autoritzats, la concessió gratuïta de llicències promou per contra l'ús lliure del programari per part de la majoria d'usuaris que igualment no pagarien res per la llicència. Cal esmentar que per a algú que incrusta un producte gratuït en un de comercial, la compra d'una llicència no li durà a plantejar les qüestions ètiques i filosòfiques que sí es plantejaria amb la protecció del programari tradicional i la tolerància zero. En comptes d'això, la llicència dual és una resposta a la qüestió econòmica de com ha de protegir la seva obra el propietari del copyright. Finalment, els casos pràctics han demostrat que la companyia, com a organització, ha de creure en el model de llicència recíproca. Al principi pot semblar poc intuïtiu, però si el producte té, per exemple, tant usuaris individuals com incrustats, aleshores la forta reciprocitat pot funcionar. A més, la llicència GNU GPL sembla ser una eina de màrqueting viable per a la llicència dual. TrollTech no estava convençuda que la llicència GNU GPL li permetés continuar les vendes de les llicències privatives fins que no ho va provar. Apart d'això, van rebre cada vegada més atenció mediàtica i acceptació política. MySQL va tenir una experiència gairebé similar. 7.4 Reflexions finals Aquest capítol ha utilitzat els esquemes econòmics i legals per tal d'analitzar diferents estratègies de llicència mitjançant casos pràctics. A la primera part, hem vist estratègies de llicència en mercats de sistemes operatius. A la segona part, hem vist la llicència dual com a nova estratègia empresarial. L’impacte de la llicència de codi obert ha quedat particularment clar en el cas dels mercats de sistemes operatius. El codi obert ha obligat els titulars a canviar les seves estratègies de llicència ja que l'exemple de Linux els ha obligat a lluitar per als desenvolupadors i a respondre a les necessitats i inquietuds en augment dels clients. Avui dia, tots els grans desenvolupadors de programari de sistema operatiu utilitzen models de llicència de codi obert almenys en parts dels seus productes. La llicència dual (atorgant llicència a productes tècnicament idèntics tant amb llicències privatives com de codi obert) sembla un model viable per a un tipus específic de noves empreses informàtiques. En qualsevol cas, el model de llicència dual no fa miracles. Hem identificat diversos requisits i limitacions organitzatives, legals i econòmiques que podrien limitar la utilització del model. Les limitacions generals dels casos pràctics també mereixen atenció. Els nostres casos pràctics eren pocs en nombre i debatien qualitativament sobretot empreses d'èxit. Per exemple, durant el procés de selecció d'empreses no se'n va trobar cap que fos un cas d'èxit en aplicacions individuals d'usuari final. Les estratègies de llicència de codi obert semblen funcionar millor per a productes tècnics dirigits a desenvolupadors, més que a usuaris finals. Els sistemes operatius i les bases de dades són exactament aquest tipus de producte. 8 Conclusions 8.1 L’expansió del codi obert El codi obert ha format part de la indústria del programari des dels seus inicis. La idea de codi obert es va amagar durant els vuitanta i principis dels noranta quan el desenvolupament i les condicions de mercat afavorien el desenvolupament centralitzat i tancat i l'acord de llicència privativa. Als anys noranta, finalment l'entorn va canviar. Hem identificat una sèrie d'explicacions sobre el naixement del codi obert en la indústria del programari. Des d'una perspectiva tècnica, el ràpid creixement d'Internet, la tendència vers els PC barats i la necessitat de mètodes de desenvolupament més flexibles han recolzat el codi obert. Des d'una perspectiva empresarial, el codi obert ofereix a les empreses noves la possibilitat de canviar l'estructura actual del mercat i les regles del joc. El codi obert també ha alterat les estratègies de mercat dels implicats. Des d'una perspectiva de política social, el codi obert ha estat definit com una eina per a assolir més democràcia, accés a informació i igualtat social a mesura que el rol del programari en la societat continua augmentant. En qualsevol cas, el codi obert continua essent motiu de controvèrsia. No hi ha cap comunitat de codi obert única sinó múltiples veus individuals que provenen de la cultura dels hackers. Les idees més d'esquerres i liberals tenen el seu origen en els anys setanta. Entre els desenvolupadors de programari, Free Software Foundation i els seus seguidors volen que el programari sigui lliure del control de les corporacions, mentre que Open Source Initiative i altres pragmàtics només pensen que el codi obert és el camí més eficient per a la innovació. La indústria del programari també ha debatut, des de ja fa uns anys, els avantatges i inconvenients del codi obert. Algunes companyies, sobretot Microsoft, han criticat obertament els principis del codi obert per ser contraris a la propietat intel·lectual. Altres recolzen obertament el desenvolupament del codi obert, només si beneficia la seva estratègia. Després de la fundació d'Open Source Initiative el 1998, el programari de codi obert, el seu desenvolupament i les seves llicències han tingut més adeptes en el ?món empresarial. Líders d'opinió ideològica com Richard Stallman s'han posat una mica al marge i han desviat l'atenció del desenvolupament de programari cap a temes de política social més generals. 8.2 Impacte sobre les pràctiques llicenciadores El periodista Robin "Roblimo" Miller descriu així l'estat de la polèmica de les llicències a principis del 2005:485 "Un article de NewsForge sobre llicències de programari o patents de programari fa dos anys atrauria entre 20.000 i 40.000 lectors i podria portar a una discussió Slashdot amb 500 comentaris, dels quals 150 serien rellevants. Avui, malgrat que el programari de codi obert és més àmpliament utilitzat, el nombre de lectors d'articles relacionats amb les llicències és normalment de menys de 5.000 (amb contades excepcions), i les discussions Slashdot sobre el tema són més reduïdes i tenen menys rellevància. No puc donar-vos estadístiques d'altres webs de notícies tecnològiques, però us puc assegurar que, pel que he llegit en llistes de correu electrònic de periodistes especialitzats en IT, l'interès en la llicència de programari decreix constantment." La disminució de l'interès en notícies relacionades amb el codi obert (i en els temes relacionats amb la llicència de programari en general) suggereix que la indústria del programari ja ha aprés de què va això del codi obert. Després de tot, l'augment en l'ús del codi obert no ha canviat d'un dia per a l'altre les pràctiques de llicència en tota la indústria. Quan la llicència de codi obert ha canviat de debò les pràctiques de llicència, ha estat durant un llarg període de temps i en mercats determinats com són els d'infraestructures d'Internet i dels sistemes operatius. Des d'una perspectiva legal, l'ús de plantilles de llicències normativitzades i relativament simples podria, en principi, significar menys problemes legals. Per exemple, en projectes conjunts de desenvolupament de programari, l'ús de llicències de codi obert « neutrals » podria aportar un equilibri en els interessos de tots els participants, estalviant-los temps i diners. En qualsevol cas, el problema es troba en els detalls. Vistes de prop, les llicències de codi obert no són exemptes de riscos legals, llenguatge ambigu i implicacions econòmiques incertes. La pregunta central de l'obligació recíproca (copyleft) no s'ha resolt, i la qüestió sembla ser específica de la llicència. Les llicències tenen diferents plantejaments envers les patents de programari. Per exemple, moltes llicències no accepten cap cànon per patent. A més, moltes llicències de codi obert no accepten ni tan sols la coexistència d'altres llicències de codi obert que siguin compatibles entre elles. Encara que el nombre de llicències de codi obert és ja de més de 50, essent la majoria d'elles còpies confuses de les altres, hi ha només unes poques llicències realment populars. Malgrat tota la confusió i incertesa, les idees originals de les pràctiques de llicència simples, comprensibles i justes encara és vigent. A tall de comparació, cada producte de programari privatiu comporta, de forma característica, la seva pròpia i única llicència, amb els seus problemes únics i riscos únics. Els problemes de llicència de 1000 productes de codi obert són per tant més barats i més fàcils de gestionar que els de 1000 productes privatius. Des d'una perspectiva econòmica, les llicències semblen comportar implicacions fonamentals. Si els cànons de les llicències directes, tant les basades en copyright com en patents, no es cobren, com pot generar ingressos creixents una empresa de programari? Les llicències de codi obert "canibalitzen" els mercats de llicències privatives ? Potser ho fan en principi, però a la pràctica les forces del mercat ja s'adapten. Les restriccions dels DPI només són una de les formes de cobrar pel programari. Com s'ha esmentat en el primer capítol, el programari es ven cada cop més com un servei sota acords de llarg termini. Naturalment, també les subscripcions es poden basar en les lleis del copyright i les patents. Malgrat tot, si es combina el manteniment, el suport i altres "serveis", llavors els cànons de propietat intel·lectual i les llicències de programari ja no són tan importants. A més, hem estat testimonis de la creació d'empreses de codi obert que han utilitzat llicències de codi obert com a eina de màrqueting per als seus productes privatius. Per acabar, la llicència de codi obert no s'hauria de veure com un dilema excloent, sinó com un complement a les pràctiques existents de llicències privatives en la indústria del programari. 8.3 Impacte en la gestió de la propietat intel·lectual Quan inicialment es va atorgar la protecció de la propietat intel·lectual als productes de programari a principis dels anys vuitanta, el propòsit era evitar l'oportunisme i protegir els nous mercats massius de programari. El sistema de copyright del programari aviat es va equilibrar per si sol. Les propostes més extremades de sistemes de protecció contra les còpies no va arribar a les forces del mercat, i la capacitat de registrar el copyright d'interfícies va ser denegada pels jutges i legisladors. Al mateix temps, el sistema de propietat intel·lectual va continuar la seva expansió en tots els altres àmbits: les patents de programari van créixer ràpidament durant els anys noranta. Els experts legals continuen debatent si el copyright, les patents i altres règims de protecció legal s'han d'aplicar als programes informàtics. Un dels arguments teòrics per a la protecció dels aspectes no literals del programari és que el copyright del programari és incomplet i, per tant, insuficient. L'argument explica que el copyright no protegeix el que de debò té valor del programari. Per exemple, Samuelson et al van explicar el 1994, després d'uns judicis sobre interfícies, que el copyright del programari havia tocat sostre, i que el programari necessitava una protecció sui generis, tal i com l'OMPI havia proposat ja a finals dels setanta adoptant més elements del sistema de patents al copyright.486 Arguments semblants en essència han estat repetits recentment per exemple Lessig.487 El principal punt feble que tenen en comú aquests arguments és el seu caràcter abstracte. És difícil demostrar pràcticament que els mercats de programari basats en copyrights no funcionen, o que els mercats funcionarien molt millor amb una protecció addicional de la propietat intel·lectual. La llicència de codi obert es basa essencialment en el copyright i provisions legals de contracte complementari. Qualsevol protecció addicional de la propietat intel·lectual o tècnica probablement només posaria en perill la funcionalitat del model. Per això es pot argumentar que el codi obert subratlla els efectes negatius de la constant expansió de la legislació dels drets de propietat intel·lectual i de l'exercici de tals drets. Especialment, l'increment de les patents ha fet augmentar el risc d'infracció en el desenvolupament de programari. Així, els riscos d'infracció de la propietat intel·lectual s'han de considerar més seriosament tant a nivell empresarial com comunitari. La realitat és que fins avui cap model empresarial de codi obert s'ha beneficiat de patents ni de l'expansió de la propietat intel·lectual. Les llicències mateixes són un pur formulisme legal. No obstant, s'ha canviat de parer sobre com utilitzar a la pràctica el copyright i els altres drets de propietat intel·lectual. S'han traspassat negocis basats en Internet al mercat massiu de programari. Han demostrat que molt sovint i contra tot pronòstic, té sentit donar els drets més exclusius al públic gratuïtament. Encara queden alguns reptes evidents. Mentre el valor de la propietat intel·lectual probablement s'incrementa amb motiu de la distribució gratuïta, l'apropiació també esdevé més complexa. Per tant, els aspectes empresarials més difícils per a qualsevol empresa de programari són la d'orientar-se en les llicències de codi obert sense perdre propostes comercials. 8.4 Impacte en la regulació comercial i estudi legal Aquest llibre ha demostrat com la indústria del programari ha començat a adoptar models de llicència de codi obert i ha canviat les seves propostes empresarials d'acord amb això. Les noves empreses han desafiat als titulars en àrees com el desenvolupament de programari, allà on era més impensable fa uns anys. De moment, els principis de les llicències de codi obert s'estan generalitzant a nombroses obres amb copyright i altres invents patentats. Hi ha una forta discussió i iniciatives que van des de la llibertat de continguts per a música i pel·lícules a l'accés lliure a materials educatius i científics. "Obert sigui el que sigui" sembla una mena de contrapoder en l'evolució vers una regulació comercial extensiva de la societat.488 Així, l'obertura equilibra la regulació comercial. Quan no hi havia una regulació tan extensa dels drets privats de cada objecte imaginable de la societat, simplement no hi havia necessitat d'equilibrar l'interès públic amb una antillicència explícita. Però avui pràcticament tota petita peça de programari, composicions musicals, imatges, descobriments científics i documents educatius, es troba sota drets més o menys exclusius i restrictius. Per diverses raons econòmiques, morals i de política social explicades en aquest estudi, sembla que hi ha una necessitat de sistemes explícits de llicència que reflecteixin l'equilibri original d'interessos amagats darrere els drets exclusius de copyright i patents, encara que sigui a l'ombra de la llei.489 En resum, els sistemes de llicència oberta han demostrat que la sobreregulació es pot establir sense intervenció de l'estat. D'aquesta manera, el codi obert posa més èmfasi en un estudi més material dels drets de propietat intel·lectual. Certament, el debat sobre les polítiques legals –amb una aportació significativa per part d'economistes, filòsofs, etc. – sobre els mèrits i inconvenients dels nous tractats i legislació de propietat intel·lectual és ja immens. Usualment, la qüestió és si caldria acceptar una proposada nova extensió a un determinat dret de propietat intel·lectual. L'estudi del codi obert i d'altres qüestions de llicències trasllada el centre d'atenció des d'aquests casos limítrofs ben bé cap al centre. Quan un nombre considerable de titulars de drets en una indústria determinada decideixen no fer valer els seus drets bàsics de propietat intel·lectual -basant-se en arguments econòmics i racionals- les premisses de la discussió sobre la normativa es veuen d'un altre color. Per què i com ho fan les empreses? Què significa això per al sistema de la propietat intel·lectual en conjunt? Aferrar-nos als drets de propietat intel·lectual atorgats pel govern en tot el seu abast és novament una qüestió rellevant tant per al desenvolupador de programari com per al legislador. ¿Pot tenir la recerca en llicències de codi obert cap impacte en la futura (des)regulació? Aquest llibre ha proposat per exemple reformes a les normes de responsabilitat legal de la propietat intel·lectual basada en les necessitats i el paper central dels desenvolupadors de codi obert en la societat en general. Aquí, cal destacar que la discussió política sobre codi obert i propietat intel·lectual és inherentment global atès que les polítiques de propietat intel·lectual són un dels aspectes clau en les negociacions de comerç mundial. Al capdavall, aquestes polítiques són obra humana. Un detall prometedor és que el nombre de parts implicades han incrementat la seva participació en els fòrums més rellevants. Per exemple, diversos grups d'interès no governamentals tenen una influència creixent en les negociacions de l'OMC i l'OMPI.490 I especialment organitzacions no governamentals que representen els interessos dels desenvolupadors de codi obert han proposat que es prengui més seriosament l'investigador acadèmic a l'hora d'establir noves polítiques i revisar-ne les antigues. Figures i Taules Figura 1. Ingressos totals de les 500 empreses de programari més importants dels EUA. 30 Figura 2. Participació en el mercat de servidors de web. 32 Figura 3. Principals components de programari per a servidors de web a començaments dels anys 2000. 32 Figura 4. Il·lustració dels models de llicència des de la perspectiva de la generació d'ingressos al llarg del temps. 41 Figura 5. Tres vies principals per distribuir productes de programari des del punt de vista del codi font. 44 Figura 6. Els beneficis del codi obert segons les entrevistes a gerents de tecnologies de la informació l'any 2004 53 Figura 7. Els reptes del codi obert segons les entrevistes a gerents de tecnologies de la informació l'any 2004 54 Figura 8. Funcions de cost diferents en la producció de béns d'informació. 65 Figura 9. Plantejament de components als productes de programari. 69 Figura 10. Un model d'innovació obert 90 Figura 11. Evolució del copyright i les patents en la història del sector. 122 Figura 12. Diferències funcionals entre les llicències de codi obert segons combinació i modificació. 134 Figura 13. Mètode d'abstracció-filtració-comparació. Figura 14. Una visió simplificada basada en components d'un programa informàtic. Figura 15. Obres derivades i mòduls de càrrega. Figura 16. Condicions possibles amb logotips afins en les llicències CC. 170 Figura 17. Cadena de desenvolupadors i usurpació dels drets de propietat intel·lectual. 181 Figura 18. Patents concedides als Estats Units entre 1984 i 2004. Font: USPTO. 191 Figura 19. Ús d'SSH als servidors d'Internet. 206 Figura 20. Corrents de llicència d'un producte genèric en un model de llicència dual simplificat. 222 Taula 1 Una taxonomia històrica de la indústria del programari 28 Taula 2. Models comercials genèrics de programari. 35 Taula 3. Restriccions típiques de llicències privatives. 41 Taula 4. Llicències de programari i ingressos per serveis d'algunes de les empreses de productes de programari més importants del món. 43 Taula 5. Els béns públics, com el programari lliure, són tant no excloïbles com no rivals. 67 Taula 6. Capacitats dels usuaris i sistemes tècnics de protecció contra còpia 119 Taula 7. Formes diferents de protecció legal del programari en la història del sector. 122 Taula 8. Llicències de codi obert més utilitzades en projectes emmagatzemats a Sourceforge. 137 Taula 9. Funcionalitat del copyright en els diferents tipus de llicència 177 Taula 10. Comparació de les diferents opcions de defensa dels DPI per part dels desenvolupadors de codi obert. 189 Taula 11. Número total de patents concedides als Estats Units des de l'any 1984 fins a començaments d'agost del 2004. Font: USPTO. 191 Taula 12. Competència entre els diferents sistemes operatius per a microordinadors a començaments de l'any 2000. 210 Taula 13. Principals opcions de llicència a diferents nivells lògics dels sistemes operatius. 211 Taula 14. Alguns atributs dels productes de codi obert estudiats. 224 Referències Nota: tots els enllaços a pàgines web es van comprovar i funcionaven a primers del 2005. Els anys en les fonts en línia es refereixen a la darrera modificació de la pàgina quan es va consultar. Es poden cercar les pàgines web històriques a l'Internet Archive, http://www.archive.org/ Articles, llibres i informes Alford, William P. (1995): To Steal a Book Is an Elegant Offense: Intellectual Property Law in Chinese Civilization, Stanford University Press. Allison, John R. i Lemley, Mark A. (1998): “Empirical Analysis of the Validity of Litigated Patents”, American Intellectual Property Law Association Quarterly Journal, volum 26, fascicle 3, pàg. 185-275. Applied Data Research (2003): Software Products Division Records 1959-1987, Charles Babbage Institute, University of Minnesota, Minneapolis. La descripció de la col·lecció està disponible a http://www.cbi.umn.edu/collections/inv/cbi00154.html Arora, Ashish i Fosfuri, Andrea i Gambardella, Alfonso (2004): Markets for Technology. The Economics of Innovation and Corporate Strategy. MIT Press. Arrow, Kenneth J. (1962): “Economic welfare and the allocation of resources for invention”, a Richard R. Nelson (ed.): The Rate and Direction of Inventive Activity. Princeton University Press, Princeton. Bakels, Reinier (2002): The Patentability of Computer Programmes, document de treball de la Direcció General per a la Recerca del Parlament Europeu, 2002 Band, Jonathan i Kato, Masanobu (1995): Interfaces on Trial. Intellectual Property and Interoperability in the Global Software Industry. Westview Press. Bednarek, Michael i Ineichen, Markus (2004): “Patent Pools as an Alternative to Patent Wars in Emergent Sectors”, Intellectual Property & Technology Law Journal, volum 16, fascicle 7. Beresford, Keith (2000): Patenting Software Under the European Patent Convention. Sweet & Maxwell. Berry, David M. (2004): “The contestation of code. A preliminary investigation into the discourse of the free/libre and open source movements”, Critical Discourse Studies, volum 1, fascicle 1, pàg. 65-89. Besen, Stanley M. (1987): New Technologies and Intellectual Property: An Economic Analysis. A Rand Note. Santa Monica, California. Besen, Stanley M. i Raskind, Leo J. (1991): “An Introduction to the Law and Economics of Intellectual Property”, Journal of Economic Perspectives, volum 5, fascicle 1, pàg. 3-27. Bessen, James i Maskin, Eric (2000): “Sequential Innovation, Patents, and Imitation”, document de treball. Bessen, James i Hunt, Robert M. (2003): “An Empirical Look at Software Patents”, document de treball #2003-17 del National Bureau of Economic Research Bessen, James (2004): “Patent Thickets: Strategic Patenting of Complex Technologies”, document de treball. Betterle, Richard S. i Davison-Jenkins, Dominic J (2001): “Coverage concepts for intellectual property”, Risk Management , volum 48, número 2, pàg. 17-21. Blind, Knut i Edler Jakob i Nack, Ralph i Strauss, Joseph: Mikro- und makroökonomische Implikationen der Patentierbarkeit von Softwareinnovationen, Bundesministerium für Wirtschaft und Technologi, 2001. Disponible a http://www.bmwi.de/Navigation/Service/bestellservice,did=21760.html Borenstein, Severin i Farrell Joseph i Jaffe, Adam B (1998): “Inside the Pin-Factory: Empirical Studies Augmented by Manager Interviews”, Journal of Industrial Economics, volum 46, número 2, pàg. 123-124 . Braunstein, Yale M. i Fisher, Dietrich M. i Ordover, Janusz A. i Baumol William J. (1979): “Economics of Property Rights as Applied to Computer Software and Data Bases. Overview of Issues”, a George P. Bush i Robert H. Dreyfuss (editors): Technology and Copyright. Edició revisada. Lomond Books, Mt. Airy, Maryland. Bride, Edward (2002): “CBI conference – “Unbundling history: The emergence of the software product””, IEEE Annals of the History of Computing, volum 24, fascicle 1, web extras, disponibles a http://www.computer.org/annals/articles/a1-2002/eands.htm Brooks, Frederik P. (1975): The Mythical Man-Month, Addison-Wesley. Calabresi, Guido (1970): The Costs of Accidents. A Legal and Economic Analysis. Yale University Press. Campbell-Kelly, Martin (2003): From Airline Reservations to Sonic the Hedgehog. A History of the Software Industry. MIT Press. Carr, Nicholas G. (2004): Does IT Matter? Information Technology and the Corrosion of Competitive Advantage. Harvard Business School Press. Castells, Manuel (1996): The Rise of the Network Society. Blackwell Publishers. Chávez, Andrea and Tornabene, Catherine and Wiederhold, Gio (1998): “Software Component Licensing. A Primer”, IEEE Software, volum 15, fascicle 5, pàg. 47-53. Chesbrough, Henry (2003): Open Innovation. The New Imperative for Creating and Profiting from Technology. Harvard Business School Press. Coase, Ronald H. (1937): “The Nature of the Firm”, Economica, Vol. 4, Núm. 16. pàg. 386-405. Conner, Kathleen Reavis i Rumelt, Richard P. (1991): “Software Piracy: An Analysis of Protection Strategies”, Management Science, volum 37, número 2, pàg. 125-139. CONTU (1978): Final Report of the National Commission on New Technological Uses of Copyrighted Works, juliol 31, 1978. Commerce Clearing House, Chicago. Cusumano, Michael A. (2004): The Business of Software. The Free Press. Daffara, Carlo i Carlo González-Barahona, Jesús M. (ed.) (2000): Free Software / Open Source: Information Society Opportunities for Europe? Working Group on Libre Software, Version 1.2., disponible a http://eu.conecta.it/paper/paper.html Dasgupta, Partha David Paul A. (1994): “Toward a new economics of science”, Research Policy, volum 23, pàg. 487-521. David, Paul A. i Greenstein, Shane (1990): “The Economics of Compatibility Standards: An Introduction to Recent Research”, Economics of Innovation and New Technology, volum 1, fascicle 1, pàg. 3-41. David, Paul A. i Foray, Dominique i Hall, Bronwyn H. i Kahin, Brian i Steinmueller, W. Edward: “Is there really a good economic rationale for an EU Directive on Software Patents?”, document de treball, 14 de juliol de 2003 Davis, Steven J. i MacCrisken, Jack i Murphy, Kevin M. (2001): “Economic Perspectives on Software Design: PC Operating Systems and Platfroms”, National Bureau of Economic Research Working Paper Series, document #8411, disponible a http://www.nber.org/papaers/w8141 Dietz, Adolf (1994): “The Artist’s Right of Integrity Under Copyright Law – A Comparative Perspective”, IIC, volum 25, número 2, pàg. 177-194. Dixit, Avinash K. (2004): Lawlessness and Economics. Alternative Modes of Governance. Princeton University Press. Dosi, Giovanni (1982): “Technological paradigms and technological trajectories”, Research Policy, volum 11, pàg. 147-162. Drahos, Peter i Braithwaite, John (2002): Information Feudalism. Who owns the knowledge economy? Earthscan. Dravis, Paul (2003): Open Source Software. Perspectives for Development. The Dravis Group. Dreier, Thomas (1991): “The Council Directive of 14 May on the Legal Protection of Computer Programs”, European Intellectual Property Review, volum 13, fascicle 9, pàg. 319-330. Drucker, Peter (1990): Managing the Non-Profit Organization. Principles and Practises. Harper Collins Publishers. Economides, Nicholas (1996): “The Economics of Networks”, International Journal of Industrial Organization, volum 14, número 6, pàg. 673-700. Ellickson, Robert C. (1991): Order without Law. Harvard University Press. Epple, Dennis i Raviv, Arthur (1978): ”Product Safety: Liability Rules, Market Structure, and Imperfect Information”, The American Economic Review, volum 68, fascicle 1. (Mar., 1978), pàg. 80-95. Epstein, Richard A. (1997): “Law and Economics: Its Glorious Past and Cloudy Future”, University of Chicago Law Review, pàg. 1167-1174. Farrell, Joseph i Monroe, Hunter K. i Saloner, Garth (1998): “The Vertical Organization of Industry: Systems Competition versus Components Competition”, Journal of Economics & Management Strategy, volum 7, fascicle 2, pàg. 143-182. Farrell, Joseph i Klemperer, Paul (2001): “Coordination and Lock-In: Competition with Switching Costs and Network Effects”, document de treball, http://emlab.berkeley.edu/users/farrell/ftp/lockin.pdf Feller, Joseph i Fitzgerald, Brian (2002), Understanding Open Source Software Development, Addison-Wesley. Ferhstman, Chaim i Gandal, Neil (2004): “The Determinants of Output Per Contributor in Open Source Projects: An Empirical Examination”, document de treball, http://ideas.repec.org/s/cpr/ceprdp.html Fink, Martin (2002): The Business of Linux and Open Source. Prentice Hall. Foray, Dominique (2004): Economics of Knowledge. MIT Press. Garzarelli, Giampaolo (2003): “Open Source Software and the Economics of Organization”, document de treball, http://opensource.mit.edu/papers/garzarelli.pdf Goldstein, Paul (2001): International Copyright, Oxford University Press. Gottinger, Hans-Werner (2003): Economies of Network Industries. Routledge. Grad, Burton (2002): “A Personal Recollection: IBM’s Unbundling of Software and Services”, IEEE Annals of the History of Computing, volum 24, fascicle 1, pàg. 64-71. Granstrand, Ove (1999): The Economics and Management of Intellectual Property. Edward Elgar. Grindley, Peter (1995): Standards, Strategy, and Policy. Oxford University Press. Guadamuz, Andrés (2004): “Viral contracts or unenforceable documents? Contractual validity of copyleft licenses”, European Intellectual Property Review, volum 26, fascicle 8, pàg. 331-339 Hahn, Rober W. (ed.) (2002): Government Policy Towards Open Source. AEI Brookings Center. Hardin, Garrett (1968): “The Tragedy of the Commons”, Science, volum 162, pàg. 1243-1248. Hart, Robert i Holmes, Peter i Reid, John: The Economic Impact of Patentability of Computer Programs, Informe per a la Comissió Europea per encàrrec de l'Intellectual Property Institute, Londres 2000. Disponible a http://europa.eu.int/comm/internal_market/en/indprop/comp/studyintro.htm Hayek, Friedrich A. (1945): “The Use of Knowledge in Society”, American Economic Review, volum 35, fascicle 4, pàg. 519-530. Heller, Michael A. (1998): “The Tragedy of the Anti-Commons: Property in the Transition from Marx to Markets”, Harvard Law Review, volum 111, fascicle 3, pàg. 621-688. Himanen, Pekka (2001): The Hacker Ethic and the Spirit of the Information Age. Random House. von Hippel, Eric (1988): Sources of Innovation. Oxford University Press. von Hippel, Eric (2002): “Open Source Projects as Horizontal Innovation Networks - By and For Users”, document de treball del MIT. Humprey, Watts S. (2002): “Software unbundling: a personal perspective”, IEEE Annals of the History of Computing, volum 24, fascicle 1, pàg. 59-63. Jaffe, Adam B. i Lerner, Josh (2004): Innovation and Its Discontents. Princeton University Press. Jaeger, Till i Metzger, Axel (2001): Open Source Software. Rechtliche Rahmenbedingungen der Freien Software. Verlag C.H. Beck. Janse, Christian (2003): ”Economic Effects of the New German Copyright Contract Law”, document de treball, disponible a http://ideas.repec.org/p/wpa/wuwple/0302003.html Johnsen, Torkil C. (1969): “Om patenterbarheden af EDB-programmer” (English Summary: On the Patentability of Computer Software), Nordiskt Immateriellt Rättskydd, volum 39, fascicle 2, pàg. 165-168. Katz, Michael i Shapiro, Carl (1985), “Network Externalities, Competition and Com-patibility,” American Economic Review, volum 75, fascicle 3, pàg. 424-440. Kelly, Kevin (1998): New Rules for the New Economy. Viking Press. Kelty, Christopher M. (2001): “Free Software/Free Science”, First Monday, volum 6, fascicle 12, disponible a http://www.firstmonday.org/issues/issue6_12/kelty/index.html Kenney, Martin (2000): “Introduction”, a Kenney, Martin (ed.): Understanding Silicon Valley, Stanford University Press, pàg. 1-12. Kitch, Edmund W. (1977): “The Nature and Function of the Patent System”, Journal of Law and Economics, volum 20, pàg. 265-290 Koktvedgaard, Mogens (1968): “Elektronisk databehandling. Immaterialretlige aspekter” (English Summary: Computers and the Law of Intellectual Property), Nordiskt Immateriellt Rättskydd, Volum 36, Issue 2, pàg. 139-151. Kuhn, Thomas (1962): The Structure of Scientific Revolutions. University of Chicago Press. Landes, William M. i Posner, Richard (1989): ”An Economic Analysis of Copyright Law”, Journal of Legal Studies, volum 18, fascicle 2, pàg. 325-363. Landes, William M. i Posner, Richard A. (2003): The Economic Structure of Intellectual Property Law, Harvard University Press. Lanjouw, Jean O. i Pakes, Ariel i Putnam, Jonathan (1998): ”How to Count Patents and Value Intellectual Property: The Uses of Patent Renewal and Application Data”, Journal of Industrial Economics, volum 46, fascicle 4, pàg. 405-432 Lanjouw, Jean O. i Schankermann, Mark (2001): “Characteristics of Patent Litigation: A Window on Competition”, RAND Journal of Economics, volum 32, fascicle 1, pàg. 129-51. Lanjouw, Jean O. and Schankermann, Mark (2004) “Protecting Intellectual Property Rights: Are Small Firms Handicapped? “ Journal of Law and Economics, volum 47, fascicle 1, pàg. 45-74. Lazonick, William (2003): “Understanding Innovative Enterprise: Towards the Integration of Economic Theory and Business History”, a Amatori, Franco i Jones, Geoffrey i Galambos, Louis (eds.): Business History around the World, Cambridge University Press, pàg. 31-61. Leibenstein, Harvey (1950): “Bandwagon, snob, and Veblen effects in the theory of consumers demand”, Quarterly Journal of Economics, volum 64, fascicle 2, pàg. 183-207. Lemley, Mark A. (2001): “Rational Ignorance at the Patent Office”, Northwestern University Law Review, volum 95, fascicle 4, pàg. 1497-1532. Lemley, Mark A. (2002): “Intellectual Property Rights And Standard-Setting Organizations”, California Law Review, volum 89, pàg. 1889-1980. Lemley, Mark A. i Shapiro, Carl (2004): “Probabilistic Patents”, document de treball. Lerner, Josh i Tirole, Jean (2002): “Some Simple Economics of Open Source”, Journal of Industrial Economics, volum 52, pàg. 197-23. Lerner, Josh i Tirole, Jean (2005), “The Scope of Open Source Licensing”, per publicar al Journal of Law, Economics and Organization. Lessig, Lawrence (2001): The Future of Ideas. Fate of the Commons in a Connected World. Random House. Lessig, Lawrence (2004): Free Culture. How Big Media Uses Law and Technology to Control Creativity. Penguin Books. Levin, Richard C. i Klevorick, Alvin K. i Nelson, Richard R. i Winter, Sidney (1987): “Appropriating the Returns from Industrial R&D”, Brookings Papers on Economic Activity, volum 3, pàg. 783-820. Liebowitz, Stan (1985): ”Copying and Indirect Appropriability: Photocopying of Journals”, Journal of Political Economy, volum 93, fascicle 5, pàg. 945-957. Liebowitz, Stan J. i Margolis, Stephen E. (2001): Winners, Losers & Microsoft. Competition and Antitrust in High Technology.Edició revisada. The Independent Institute. Liebowitz, Stan J. (2002): Re-Thinking the Network Economy. Amacom. Locke, John (1690): Second Treatise on Government, disponible per exemple a http://www.swan.ac.uk/poli/texts/locke/lockcont.htm Luckombe, Philip (1771): The History and Art of Printing. Reeditat el 1965 per Gregg Press Ltd, Londres. Machlup, Fritz (1958): “An Economic Review of the Patent System", estudi número 15 del Subcomitè de Patents, Marques i Copyrights del Comitè del Poder Judicial, Senat dels Estats Units, 85è Congrés, Segona Sessió (Washington, D.C). Machlup, Fritz (1962): “The Supply of Inventors and Innovations”, a Richard R. Nelson (editor): The Rate and Direction of Inventive Activity: Economic and Social Factors.Princeton University Press, Princeton. Mattei, Ugo (1997): Comparative Law and Economics. The University of Michigan Press. Matthews, Christopher May (2000): The Global Political Economy of Intellectual Property Rights, Routledge. McKean, Roland M. (1970): ”Products Liability: Implications of Some Changing Property Rights”, The Quarterly Journal of Economics, volum 84, fascicle 4, pàg. 611-626. McKusick, Marshall Kirk (1999): “Twenty Years of Berkeley Unix. From AT&T-Owned to Freely Redistributable”, a DiBona, Chris et al (editors) (1999): Open Sources: Voices from the Open Source Revolution, O’Reilly, pàg. 31-46. Melamed, Douglas i Stoeppelwerth, Ali M. (2002): “The CSU Case: Facts, Formalism And The Intersection Of Antitrust And Intellectual Property Law”, George Mason Law Review Menell, Peter S. (1989): “An Analysis of the Scope of Copyright Protection for Application Programs”, Stanford Law Review, volum 41, pàg. 1045-1104. Merges, Robert (2004): “A New Dynamism in the Public Domain”, University of Chicago Law Review, pàg. 183-203. Messerschmitt, David G. i Szyperski, Clemens (2003): Software Ecosystem. Understanding an Undispensable Technology and Industry. MIT Press. National Research Council (1991): Intellectual Property Rights Issues in Software. National Academy Press. Negroponte, Nicholas (1995): Being Digital. Knopf. Newcity, Michael A. (1978): Copyright Law in the Soviet Union. Praeger Publishers, Nova York. Nichols, Kenneth (1998): Inventing Software, Quorum Books. North, Douglass C. (1981): Structure and Change in Economic History. W.W. Norton & Company. Novos, Ian E.i Waldman, Michael (1986): “The Emergence of Copying Technologies: What Have We Learned?”, document de treball de l'UCLA, http://www.econ.ucla.edu/workingpapers/wp408.pdf OECD (2002): Report of the OECD Task Force on Software Measurement in the National Accounts. Organisation for Economics Co-operation and Development, Paris. Oksanen, Ville i Välimäki, Mikko (2002): “Transnational Advocacy Network Opposing DRM - Technical and Legal Challenge to Media Companies”, Journal of Media Management, volum 4, fascicle 3. O’Mahony, Siobhan (2003): “Guarding the Commons: How Community Managed Software Projects Protect Their Work”, Research Policy, volum 32, fascicle 7, pàg. 1179-1198. Osario, Carlos A. (2002): “A Contribution to the Understanding of Illegal Copying of Software”, document de treball del MIT, disponible a http://opensource.mit.edu/ Palmer, Tom G. (1989): ”Intellectual Property: A Non-Posnerian Law and Economics Approach”, Hamline Law Review, http://www.tomgpalmer.com/. Patterson, Lyman Ray (1968): Copyright in Historical Perspective, Vanderbilt University Press. PbT Consultants (2001): The Results of the European Commission Consultation Exercise on the Patentability of Computer Implemented Inventions, 2001 Posner, Richard (2002): Antitrust Law. 2a edició, The University of Chicago Press. Prasada, Ashutosh i Mahajan, Vijay (2003): “How many pirates should a software firm tolerate?”, International Journal of Research in Marketing, volum 20, fascicle 4 , pàg. 337-353 Puckett, Allen W. (1966): “The Limits of Copyright and Patent Protection for Computer Programs”, a Copyright Law Symposium Number Sixteen. Nathan Burkan Memorial Competition, patrocinada per l'American Society of Composers. Columbia University Press, Nova York 1968, pàg. 81-142. Pugh, Emerson W. (2002): “Origins of Software Unbundling”, IEEE Annals of the History of Computing, volum 24, fascicle 1, pàg. 59-63. Rahnasto, Ilkka (2003): Intellectual Property Rights, External Effects, and Anti-trust Law. Leveraging IPRs in the Communications Industry.Oxford University Press. Rajala, Risto i Rossi, Matti i Tuunainen, Virpi Kristiina i Korri, Santeri (2001): Software Business Models. A Framework for Analysing Software Industry. Technology Review 108/2001. Finnish National Technology Agency, http://www.tekes.fi. Raymond, Eric S. (2001): The Cathedral and the Bazaar, 2nd Edition, O’Reilly. Rehn, Alf (2001): Electronic Potlatch – a study on new technologies and primitive economic behaviors, Royal Institute of Technology, Estocolm. Riis, Thomas (1996): Ophavsret og Retsøkonomi. Immaterielle goder I kulturøkonomisk belysning. (With English summary) Gadjura. Rose, Carol M. (1986): “The Comedy of the Commons: Custom, Commerce, and Inherently Public Property”, University of Chicago Law Review, volum 53, fascicle 3, pàg. 711-781. Rosen, Lawrence E. (2004): Open Source Licensing: Software Freedom and Intellectual Property Law.Prentice Hall. Rushton, Michael (1998): “The Moral Rights of Artists: Droit Moral ou Droit Pécuniaire?”, Journal of Cultural Economics, pàg. 15-32 Samelson, K. i Bauer F. L. (1960): “Sequential formula translation”, Communications of the ACM, volum 3, fascicle 2, pàg. 76-83 Samuelson, Pamela i Davis, Randall i Kapor, Mitchell D. i Reichman J.H. (1994): “A Manifesto Concerning the Legal Protection of Computer Programs”, Columbia Law Review, volum 94, fascicle 8, pàg. 2308–2431. Sarath, Bharat (1991): ”Uncertain Litigation and Liability Insurance”, The RAND Journal of Economics, volum 22, fascicle 2, pàg. 218-231. Schumpeter, Joseph (1942): Capitalism, Socialism and Democracy. Harper & Brothers. Shavell, Steven (1982): ”On Liability and Insurance”, The Bell Journal of Economics, volum 13, fascicle 1., pàg. 120-132. Shapiro, Carl (1989): “The Theory of Business Strategy”, The RAND Journal of Economics, volum 20, fascicle1, pàg. 125-137. Shapiro, Carl i Varian, Hal R. (1998): Information Rules. A Strategic Guide to the Network Economy. Harvard Business School Press. Shapiro, Carl (2001): ”Navigating the Patent Thicket: Cross Licenses, Patent Pools, and Standard Setting,” a Jaffe, Adam i Lerner, Joshua i Stern, Scott (editors): Innovation Policy and the Economy, MIT Press. St. Laurent, Andrew (2004): Understanding Open Source & Free Software Licensing. O´Reilly. Stallman, Richard (2002): Free Software, Free Society. Selected Essays by Richard M. Stallman, O’Reilly. Stille, Alexander (2002): Future of the Past. Picador. Shy, Oz and Thisse, Jacques (1999), “A Strategic Approach to Software Protection”, Journal of Economics and Management Strategy. volum 8, fascicle 2, pàg. 163-90. Shy, Oz (2001): The Economics of Network Industries. Cambridge University Press. Takeyama, Lisa (1994): “Distributing Experience Goods by Giving Them Away: Shareware – Some Stylized Facts and Estimates of Revenue and Profitability,” Economic Innovation and New Technology, volum 3, fascicle 2, pàg. 161-174. Takeyama, Lisa (1994b): “The Welfare Implications of Unauthorized Reproduction of Intellectual Property in the Presence of Demand Network Externalities”, The Journal of Industrial Economics, volum 42, fascicle 2, pàg. 155-166. Teece, David J. (1986): “Profiting from technological innovation: Implications for integration, collaboration, licensing and public policy”, Research Policy, volum 15, fascicle 6, pàg. 285-305. Teece, David J. (2000): Managing Intellectual Capital.Oxford University Press. Torrisi, Salvatore (1998): Industrial Organisation and Innovation. An International Study of the Software Industry.Edward Elgar. Torvalds, Linus, i Diamond, David (2001): Just for Fun. The Story of an Accidental Revolutionary. Harper Business. Tuomi, Ilkka (2002): Networks of Innovation. Oxford University Press. Tyler, Michael A. (1986): “The Extent of Software Piracy”, a Huband, Frank L. i Shelton, R. D. (editors) (1986): Protection of Computer Software. Law & Business Inc. Viscusi, W. Kip i Moore, Michael J. (1993): ”Product Liability, Research and Development, and Innovation”, The Journal of Political Economy, volum 101, fascicle 1, pàg. 161-184. Välimäki, Mikko (2003a): “Dual Licensing in Open Source Software Industry”, Systemes d´Information et Management, volum 8, fascicle 1, pàg. 63-75. Välimäki, Mikko (2003b): “From individuals to political institutions - The discourse on institutional change in free software and open source communities”, Mediumi, volum 2, fascicle 1, disponible a http://www.m-cult.net/mediumi/. Välimäki, Mikko (2004a): “Ajatuksia tekijänoikeuslainsäädännön uudistamiseksi” (In Finnish, with English summary titled “Some Thoughts on Copyright Law Reform”), Lakimies, volum 102, fascicle 2, pàg. 255-273. Välimäki, Mikko (2004b): “A Practical Approach to the Problem of Open Source and Software Patents”, European Intellectual Property Review, volum 26, fascicle 12. Välimäki, Mikko i Hietanen Herkko (2004): “The Challenges of Creative Commons Licensing”, Computer Law Review, volum 5, fascicle 6. Välimäki, Mikko i Oksanen, Ville (2005): “The Impact of Free and Open Source Licensing on Operating System Software Markets”, Telematics and Informatics, volum 22, fascicles 1-2, pàg. 97-110. Watt, Richard (2000): Copyright and Economic Theory, Edward Elgar. Williams, Sam (2002): Free as in Freedom. Richard Stallman’s Crusade for Free Software. O’Reilly. West, Joel i Dedrick, Jason (2001): “Open Source Standardization: The Rise of Linux in the Network Era,” Knowledge, Technology & Policy, volum 14, fascicle 2, pàg. 88-112. West, Joel (2003): “How open is open enough? Melding proprietary and open source platform strategies”, Research Policy, volum 32, pàg. 1259–1285. von Westrap, Falk (2003): Modeling Software Markets. Empirical Analysis, Network Simulations and Marketing Implications. Physica-Verlag. Notícies, entrevistes i recursos en línia Akerlof et al. (2002): Amici Curiae, Eldred v. Ashcroft, May 20th, 2002, disponible a http://eon.law.harvard.edu/openlaw/eldredvashcroft/supct/amici/economists.pdf. Anderson, Ross (2003): `Trusted Computing' Frequently Asked Questions - TC / TCG / LaGrande / NGSCB / Longhorn / Palladium / TCPA, versió 1.1, agost 2003, http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html Apache (2004): “Apache License v2.0 and GPL Compatibility”, disponible a http://www.apache.org/licenses/GPL-compatibility.html Apple (2003): Darwin FAQ, disponible a http://developer.apple.com/darwin/projects/darwin/faq.html Asami, Naoki (2001): “30th Anniversary Interview of Linus Torvalds”, Nikkei Electronics Online, disponible a http://ne.nikkeibp.co.jp/english/2001/30aniv/int2 Associated Press (1994): “Microsoft Loses Patent Suit”, Associated Press, 23 de febrer de 1994. Barlow, John Perry (1994): “The Economy of Ideas”, Wired 2.03 Barr, Joe (2004): ”HP memo forecasts MS patent attacks on free software”, NewsForge, 19 de juliol de 2004. Bigelow, Robert P (1970): “Contract Caveats”, Datamation, 1970, volum 16, número 11, pàg. 41-44. Boyle, James (2004): “Give me liberty and give me death?”, Financial Times, 21 d'octubre de 2004. Bowman, Lisa M. (2002): “Open-source Visionary: Proprietary software is not okay”, ZD Net AU, 10 de desembre de 2002, disponible a http://www.zdnet.com.au/newstech/os/story/0,2000024997,20270554,00.htm Broersma, Matthew (2002): “Eric Raymond: Why open source will rule”, ZD Net News, 29 de març 2002, disponible a http://zdnet.com.com/2100-1104-871366.html Brown, Glenn Otis (2004): “Announcing (and explaining) our new 2.0 licenses”, 25 de maig de 2004, http://creativecommons.org/weblog/entry/4216 Business Software Alliance (2004): First Annual BSA and IDC Global Software Piracy Study, disponible a http://www.bsa.org/ CJA Consultants (2003): Patent Litigation Insurance. A Study for the European Commission on possible insurance schemes against patent litigation risks. Final Report. Codewalkers (2002), entrevista a Michael Widenius, http://codewalkers.com/interviews/Monty_Widenius.html Cohen, Nancy (2003): “What’s GNU? GPL v3 and ASPs “, Open Magazine, http://www.open-mag.com/features/Vol_66/GNU/GNU.htm Computer Business Review (2005): “CA confirms plans for open source patent pledge”, 3 de març 2005, disponible a http://www.cbronline.com/article_news.asp?guid=DC531E86-85D0-42C4-A752-DFA5DA446142 Computer Hope (2003): “History of Microsoft Windows”, disponible a http://www.computerhope.com/history/windows.htm ComputerWire (2002): “Clock ticks on Microsoft's licensing – opposition remains “, The Register, 31 de juliol de 2002. http://www.theregister.co.uk/2002/07/31/clock_ticks_on_microsofts_licensing/ Conner, Doug (1998): “Father of DOS still having fun at Microsoft”, Microsoft Micronews, 10 d'abril de 1998. Disponible a http://www.patersontech.com/Dos/Micronews/paterson04_10_98.htm The Economist (2001): “Software Survey”, The Economist, 21 d'abril de 2001. The Economist (2004a): “Sir Bill and his dragons—past, present and future”, The Economist, 29 de gener de 2004 The Economist (2004b): “BRAIN SCAN. Unix's founding fathers.”, The Economist, 10 de juny de 2004. European Information Technology Observatory (2004): “Out of the tunnel: Western European and worldwide markets for Information Technology and Telecommunications (ICT) are picking up”, comunicat de premsa, 18 de febrer de 2004. Farber, Dan (2003): ”Unplugged: Mårten Mickos, CEO MySQL AB”, ZDNet Tech Update. Fichera, Richard (2004): ”Linux IP Litigation: Users Largely Unconcerned About SCO Suit, Indifferent To Indemnification”, Forrester Research, 14 de maig de 2004, resum disponible a http://www.forrester.com Ford, Nelson (2000): “The History of Shareware & PsL”, disponible a http://www.asp-shareware.org/users/history-of-shareware.asp Foundation for Free Information Infrastructure (2004): “The TRIPs Treaty and Software Patents”, http://swpat.ffii.org/analysis/trips/ Free Software Foundation (2002): “Free Software Foundation Announces Support of the Affero General Public License, the First Copyleft License for Web Services “, http://www.gnu.org/press/2002-03-19-Affero.html Free Software Foundation (2003): “BSD License Problem”, http://www.gnu.org/philosophy/bsd.html Free Software Foundation (2004): “Frequently Asked Questions about the GNU GPL”, disponible a http://www.gnu.org/licenses/gpl-faq.html Free Software Foundation (2004b), “Various Licenses and Comments about Them”, http://www.gnu.org/licenses/license-list.html Fremy, Philippe (2001), “Interview: Trolltech’s President Eirik Eng”, http://dot.kde.org/1001294012/ Fried, Ina (2004): ”Gates wants patent power”, News.com, 29 de juliol de 2004 Gates, William H. (1976): “An Open Letter to Hobbyists”, 3 de febrer de 1976, disponible per exemple a http://www.blinkenlights.com/classiccmp/gateswhine.html Geiber, Jason (2004): “Government Open Source Policies”, http://www.csis.org/tech/OpenSource/0408_ospolicies.pdf Google Zeitgeist (2004): http://www.google.com/press/zeitgeist/archive.html Greene, Thomas C. (2001): “Ballmer: “Linux is a cancer””, The Register, 2 de juny de 2001, http://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_cancer/ Hewlett-Packard (2003): ”HP indemnifies Linux customers against SCO lawsuit”, 24 de setembre de 2003, disponible a http://www.hp.com/ Hirsch, Phil (1966): “The Patent Office Examines Software”, Datamation, novembre de 1966, pàg. 79-81. Hirsch, Phil (1968): “CCPA Reconsiders Patent Decision and Prater & Wei Wait ´Er and Pray”, Datamation, abril de 1968, pàg. 174-175. Hirsch, Phil (1969): “Conference Considers Software Legal Issues and It’s Good News Two to One”, Datamation, novembre de 1969, pàg. 357-359. Howard, James (2001): “The BSD Family Tree”, Daemon News, disponible a http://www.daemonnews.org/200104/bsd_family.html Hubbard, Jordan (2003): ”A Brief History of FreeBSD”, disponible a http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/history.html Greant, Zak (2002), The Future of MySQL, presentació a la SD Expo 24.4.2002, San Jose, CA, EUA, http://www.mysql.com/information/presentations/index.html IBM (2002): Common Public License Frequently Asked Questions, http://www-106.ibm.com/developerworks/library/os-cplfaq.html, June 1, 2002 IBM (2005): “IBM Statement of Non-Assertion of Named Patents Against OSS”, disponible a http://www.ibm.com/ibm/licensing/patents/pledgedpatents.pdf IDC (2003): “IDC Says Microsoft Is Moving into Dominant Role in Server Operating Environments, Even as Linux Grows”, comunicat de premsa de l'IDC, 8 d'octubre de 2003. Initiative for Software Choice (Iniciativa per a l'Elecció de Programari, 2004): “Initiative for Software Choice – Key Messages”, http://www.softwarechoice.org/download_files/Key_ISC_messaging.pdf InnoDB (2004): “MySQL/InnoDB (= MySQL Pro) commercial licensing”, http://www.innodb.com/licenses.php Irlam, Gordon (1998): “Software Patents”, http://www.base.com/software-patents/software-patents.html Jo Foley, Mary (2004): “FlexWiki: Microsoft's Third Open Software Project”, eWeek, 28 de setembre de 2004, disponible a http://www.eweek.com/article2/0,1759,1657278,00.asp Kane, Margaret (2002): “W3C bows to royalty-free pressure”, News.com, 14 de novembre de, 2002. Kelly, J. S. (2000): “An interview with Richard Stallman”, LinuxWorld.com, 29 de març de 2000, http://www.itworld.com/Man/2687/LWD000329rms/ Kilgard, Ron et al (1995): Amicus curiae, Lotus v. Borland. Desembre de 1995. Disponible a http://www-swiss.ai.mit.edu/6805/articles/int-prop/lotus/law-prof-amicus.txt Krim, Jonathan (2003): “The Quiet War Over Open-Source”, Washington Post, 21 d'agost de 2003. LaMonica, Martin (2004): “Pandora's box for open source”, CNET News.com, 12 de febrer de 2004, disponible a http://zdnet.com.com/2100-1104-5157874.html Lawson, Stephen (2004): “Microsoft goes open source with WiX tool”, InfoWorld, 5 d'abril de 2004, http://www.infoworld.com/article/04/04/05/HNwintool_1.html The League for Programming Freedom (1991): Against Software Patents, 28 de febrer de 1991, disponible a http://lpf.ai.mit.edu/Patents/against-software-patents.html Leonard, Andrew (2000a): “BSD Unix: Power to the people, from the code”, Salon.com 16 de maig de 2000, disponible a http://dir.salon.com/tech/fsp/2000/05/16/chapter_2_part_one/index.html?pn=1 Leonard, Andrew (2000b): “License to be good”, Salon.com 22 de setembre de 2000, disponible a http://dir.salon.com/tech/col/leon/2000/09/22/licenses/index.html?pn=1 Livingston, Brad (2000): “Is Microsoft’s change in Kerberos security a form of ‘embrace, extend, extinguish’?“, InfoWorld, disponible a http://archive.infoworld.com/articles/op/xml/00/05/15/000515oplivingston.xml Majerus, Laura A. (2003): “Court Evaluates Meaning of “Derivative Work” in an Open Source License”, FindLaw.com. Malcolm, Jeremy (2003): “Problems in Open Source Licensing”, ponència presentada al congrés nacional sobre Linux a Austràlia, 24 de gener de 2003, disponible a http://www.ilaw.com.au/public/licencearticle.html Markham, Gervase (2004): “Relicensing help wanted”, 14 de juliol de 2004, http://weblogs.mozillazine.org/gerv/archives/005992.html McCue, Andy (2004): “Gartner: Re-negotiate software license deals now”, News.com, 23 de novembre de 2004. Metzger, Axel (2004): “Free Content Licenses under German Law”, xerrada donada al Wissenschaftskolleg, Berlín, 17 de juny de 2004, disponible a http://lists.ibiblio.org/pipermail/cc-de/2004-July/000015.html Microsoft (2003a): Microsoft Shared Source Initiative Frequently Asked Questions, disponible a http://www.microsoft.com/resources/sharedsource/Initiative/FAQ.mspx Microsoft (2003b): Shared Source Licensing Programs, disponible a http://www.microsoft.com/resources/sharedsource/Licensing/default.mspx Microsoft (2003c): Software Assurance, disponible a http://www.microsoft.com/licensing/programs/sa/ Moglen, Eben (2001a): Free Software Matters, Enforcing the GPL I, Linux User, disponible a http://emoglen.law.columbia.edu/publications/lu-12.html Moglen, Eben (2001b): Free Software Matters, Enforcing the GPL II, Linux User, disponible a http://emoglen.law.columbia.edu/publications/lu-13.html Morrison & Foerster (2000): “Diplomatic Conference Votes to Maintain Status Quo Regarding Software Patents in Europe Pending Issuance of a New Software Patent Directive by the European Union”, Legal Update, novembre 2000, disponible a http://www.mofo.com/news/updates/files/update152.html Mozilla Relicensing FAQ (2004): http://www.mozilla.org/MPL/relicensing-faq.html Mundie, Craig (2001): “The Commercial Software Model and Sustainable Innovation”, 16 de maig de 2001, disponible a http://www.microsoft.com/resources/sharedsource/Initiative/speeches/mundie_model.mspx MySQL (2001): “FAQ on MySQL vs. NuSphere Dispute”, 13.7.2001 http://www.mysql.com/news/article-75.html MySQL (2004a): “MySQL Licensing Policy”, http://www.mysql.com/company/legal/licensing/ MySQL (2004b): “FLOSS License Exception v0.2”, http://www.mysql.com/company/legal/licensing/foss-exception.html, 15 de juliol de 2004. Nature (2001): “Future e-access to the primary literature”, Nature, debat web, http://www.nature.com/nature/debates/e-access/ Netcraft (2004): Web Server Survey, disponible a http://news.netcraft.com/archives/web_server_survey.html Netscape (1998): “Netscape announces Mozilla.org, a dedicated team and web site supporting development of free client source code”, comunicat de premsa, 23 de febrer de 1998 Novell (2004): ”NovellSupports Enterprise Linux Customers With New Linux Indemnification Program”, 13 de gener de 2004, disponible a http://www.novell.com/ OneStat (2003a): “Search Engine Ratings”, comunicat de premsa, 12 de maig de 2003, http://www.onestat.com/html/aboutus_pressbox21.html http://www.onestat.com/html/aboutus_pressbox23.html OneStat (2003b): “Microsoft’s Windows dominates the OS market on the web according to OneStat.com”, comunicat de premsa, 24 de setembre de 2003, http://www.onestat.com/html/aboutus_pressbox24.html OneStat (2004): Microsoft's Internet Explorer global usage share is 93.9 percent according to OneStat.com”, comunicat de premsa, 28 de maig de 2004, http://www.onestat.com/html/aboutus_pressbox30.html Open Source Development Labs (2003): “Linux Legal Defense Fund FAQ”. Disponible a http://www.osdl.org/ Open Source Development Labs (2004): ”OSDL to Support Enhancements to Linux Kernel Development Process”, 24 de maig de 2004. Disponible a http://www.osdl.org/ Open Source Initiative (1999): “History of the OSI”, http://www.opensource.org/docs/history.php Open Source Risk Management (2004a): ”OSRM Certifies Linux Kernel Free of Copyright Infringement” 19 d'abril de 2004. Disponible a http://www.osriskmanagement.com/ Open Source Risk Management (2004b): ”Results of First-Ever Linux Patent Review Announced”, 2 d'agost de 2004. Disponible a http://www.osriskmanagement.com/ OpenSSH (2001): “SSH.COM Trademark Dispute”, http://www.openssh.org/ssh-dispute/ OpenSSH (2004): “Project History and Credits”, http://www.openssh.com/history.html Perens, Bruce (2002): “MS ‘Software Choice’ scheme a clever fraud”, The Register, 9 d'agost de 2002, http://www.theregister.co.uk/2002/08/09/ms_software_choice_scheme/ Pournelle, Jerry (1987): “Back to Work!”, BYTE, volum 12, número 4. Pournelle, Jerry (1988): “Computing at Chaos Manor Life after Las Vegas”, BYTE, volum 13, número 2. Proffitt, Brian (2004): “XFree86 License Causes Distros to Rethink Plans”, LinuxToday, 18 de febrer de 2004, http://linuxtoday.com/developer/2004021803026NWDTLL Ravicher, Dan (2002): “Software Derivative Work: A Circuit Dependent Deter-mination”, disponible a http://www.pbwt.com/Attorney/files/ravicher_1.pdf Raymond, Eric S. (2002): “Geeks with Guns!”, disponible a http://www.catb.org/~esr/geeks-with-guns/ Raymond, Eric S. i Landley Rob (2003): “OSI Position Paper on the SCO-vs.-IBM Complaint”, disponible a http://www.opensource.org/sco-vs-ibm.html, accessed 20 September 2003. Red Hat (2004a): ”Red Hat Announces Open Source Assurance to Safeguard Customer Investment”, 20 de gener de 2004, disponible a http://www.redhat.com/. Red Hat (2004b): ”Red Hat, Inc. Statement of Position and Our Promise on Software Patents”, disponible a http://www.redhat.com/legal/patent_policy.html Roblimo (2004): “Wikipedia Founder Jimmy Wales Responds”, Slashdot, 28 de juliol de 2004. Disponible a http://www.slashdot.org/ Rose, Dan (2004): “DOS® Abandonware Utilities -- Disk Copy-Protection Removal Software”, http://home.pmt.org/~drose/aw-dos-37.html Rosen, Lawrence (2001): “Naming Open-Source Software”, Linux Journal, 1 d'octubre de 2001 Rosen, Lawrence (2002): “Allocation of the Risks”, Linux Journal, 1 de setembre de 2002 Rosen, Lawrence (2004): “Patents in an open source world”, NewsForge, 27 de juliol de 2004 Salus, Peter H. (1994): “The history of Unix is as much about collaboration as it is about technology”, BYTE.com, novembre de 1994. Samuelson, Pamela et al (1995): Amicus curiae, Lotus v. Borland. Desembre de 1995. Disponible a http://www-swiss.ai.mit.edu/6805/articles/int-prop/lotus/law-prof-amicus.txt ScanSSH (2004): “SSH usage profiling”, http://www.openssh.org/usage/ Schneier, Bruce (2001): “The Futility of Digital Copy Prevention”, Crypto-Gram Newsletter, 15 de maig de 2001 http://www.schneier.com/crypto-gram-0105.html Shankland, Stephen (2004a): “MySQL addresses open-source license problem”, News.com, 12 de març de 2004. Shankland, Stephen (2004b): ”IBM pledges no patent attacks against Linux”, News.com, 4 d'agost de 2004. Singer, Michael (2004): “Apple Sees a Shift in Developer Profiles”, InternetNews, disponible a http://www.internetnews.com/ent-news/article.php/3335591 Sleepycat (2004): “Sleepycat Software Product Licensing “, http://www.sleepycat.com/download/licensinginfo.shtml Stallman, Richard (1986): Conferència al Kungliga Tekniska Högskolan (Institut Reial de Tecnologia), Estocolm, Suècia, 30 d'octubre de 1986, disponible a http://www.gnu.org/philosophy/stallman-kth.html Stallman, Richard (1999a): “Why you shouldn't use the Library GPL for your next library”, http://www.gnu.org/philosophy/why-not-lgpl.html Stallman, Richard (1999b): ”Saving Europe from Software Patents”, Linux Today, disponible a http://features.linuxtoday.com/news_story.php3?ltsn=1999-05-16-003-05-NW-LF Stapleton, Lisa (2004): “Stallman: Accusatory Report Deliberately Confuses”, Linux Insider 27 de maig de 2004, disponible a http://www.linuxinsider.com/story/34069.html Stone, Brad (2004): ”Nickels, Dimes, Billions”, Newsweek, a la web exclusivament, 2 d'agost de 2004 SUN (2005): “Sun Grants Global Open Source Community Access to More than 1,600 Patents”, 25 de gener de 2005, disponible a http://www.sun.com/smi/Press/sunflash/2005-01/sunflash.20050125.2.html Tai, Andy (2001): “The History of the GPL”, disponible a http://www.free-soft.org/gpl_history/ Talk, Chuck (2004): “An Interview with Matt Asay of Novell”, 31 de maig de 2004, http://rootprompt.org/article.php3?article=6940 Tomboy (1998): “Reinitializing Lotus 1-2-3 DOS versions 2.01, 2.3, and 3.1”, http://fravia.anticrack.de/123dos.htm Torvalds, Linux i Cox, Alan (2003): Carta oberta al Parlament Europeu, disponible a http://www.effi.org/patentit/patents_torvalds_cox.txt TrollTech (2003): “Licenses for Code Used in Qt” http://doc.trolltech.com/3.1/licenses.html TrollTech (2004): “Qt Open Source Edition Licensing”, http://www.trolltech.com/products/qt/opensource.html US vs. Microsoft (2003): United States v. Microsoft – Current Case, disponible a http://www.usdoj.gov/atr/cases/ms_index.htm Wheeler, David A. (2004): “Make Your Open Source Software GPL-Compatible. Or Else”, http://www.dwheeler.com/essays/gpl-compatible.html Zawinski, Jamie (2003): “Emacs Timeline”, disponible a http://www.jwz.org/doc/emacs-timeline.html Zimran, Ahmed (2001), “Interview with Sleepycat President and CEO Michael Olson”, http://www.winterspeak.com/columns/102901.html, 29.10.2001 Jurisprudència, documents oficials i llicències Casos – Estats Units Litigi entre Computer Associates International i Altai (Tribunal d'Apel·lació dels EUA, 2n Circuit, 22 de juny de 1992) Diamond contra Diehr (Tribunal Suprem dels EUA, 3 de març de 1981) Gottschalk v. Benson (Tribunal Suprem dels EUA, 20 de novembre de 1972) Litigi entre Litchfield i Spielberg (Tribunal d'Apel·lació dels EUA, 9è Circuit, 6 de juliol de 1984) Lotus Development Corp. v. Borland International Inc. (Tribunal d'Apel·lació dels EUA, 1r Circuit, 9 de març de 1995) In Re Alappat (Tribunal d'Apel·lació dels EUA, Circuit Federal, 29 de juliol de 1994) Parker v. Flook (Tribunal Suprem dels EUA, 22 de juny de 1978) Progress Software Corp. v. MySQL AB (obert al Jutjat de Districte dels EUA per al Districte de Massachusetts, 2002 – resolt el 7 de novembre de 2002). SCO Group v. International Business Machines, Inc. (obert al Jutjat de Districte dels EUA per al Districte d'Utah, 2003 – en curs i cobert exhaustivament per exemple a http://www.groklaw.net/) Stac Electronics v. Microsoft Corp. (obert al Jutjat de Districte dels EUA per al Districte Central de Califòrnia, 1993 – resolt el juny de 1994). United States v. Manzer (Tribunal d'Apel·lació dels EUA, 8è Circuit, 27 d'octubre de 1995) United States v. Microsoft (obert al Jutjat de Districte dels EUA per al Districte de Colúmbia, 1999 – cas resolt l'1 de novembre de 2002) Unix System Laboratories, Inc vs. Berkeley Software Design, Inc. (obert al Jutjat de Districte dels EUA per al Districte de Nova Jersey, 1992 – resolt el 4 de febrer de 1994). Vault Corp. v. Quaid Software Ltd. (Tribunal d'Apel·lació dels EUA, 5è Circuit, 22 de juny de 1988) Whelan Associates Inc. v. Jaslow Dental Laboratory, Inc., et al. (Tribunal d'Apel·lació dels EUA, 3r Circuit, 4 d'agost de 1986) Casos – Europa Oficina de Patents Europea, Sala de Recursos, T 0208/84, VICOM, 15 de juliol de 1986 Oficina de Patents Europea, Sala de Recursos, T 1173/97, IBM, 1 de juliol de 1998 Landgericht München I, 19 de maig de 2004. Disponible a http://www.jbb.de/urteil_lg_muenchen_gpl.pdf Tribunal Suprem de Finlàndia, KKO 1998:91, 21 d'agost de 1998 Tribunal Suprem de Finlàndia, KKO 2003:88, 10 de novembre de 2003 Documens oficials Conveni de Berna per a la Protecció de les Obres Artístiques i Literàries, Llei de París de 24 de juliol de 1971, esmenada el 28 de setembre de 1979 (Conveni de Berna) Conferència dels Estats Contractants per Revisar el Conveni Europeu de Patents de 1973 (Munic, 20-29 de novembre de 2000) (EPC 2000) Conveni sobre l'Atorgament de Patents Europees, de 5 d'octubre de 1973 (Conveni sobre la Patent Europea) Directiva del Consell 91/250/CEE de 14 de maig de 1991 sobre la Protecció legal dels programes d'ordinador (Software Copyright Directive) Directiva del Consell 93/13/CEE de 5 d'abril de 1993 sobre condicions abusives en els contractes de consum (Consumer Contract Directive) Directiva 99/44/CE del Parlament Europeu i del Consell de 25 de maig de 1999 sobre certs aspectes de la venda de béns de consum i garanties associades (Consumer Goods and Guarantees Directive) Examination Guidelines for Computer-Related Inventions, 28 de febrer de 1996 (US Software Patent Guidelines) Guidelines for Examination in the European Patent Office. Efectiu a partir de l'1 de juny de 1978. Guidelines for Examination in the European Patent Office. Edició de desembre de 2003. Memoràndum del Comitè Jurídic Constitucional del Parlament Finlandès 7/2005, 10 de març de 2005 Conferència Diplomàtica de Munic per a l'establiement d'un sistema europeu per a l'atorgament de patents (Munic, del 10 de setembre al 5 d'octubre de 1973). Promoting Innovation Through Patents - Llibre Verd sobre la patent comunitària i el sistema de patents de patents a Europa, COM(97) 314, juny de 1997 Proposal for a directive of the European Parliament and of the Council on the patentability of computer-implemented inventions, Brussels, 20.02.2002, COM(2002) 92 final. (Software Patent Directive Proposal) WIPO Advisory Group of Governmental Experts on the Protection of Computer Programs, Ginebra, del 8 al 12 de març de 1971. Copyright, volum 7, fascicle 3, pàg. 35-40. WIPO Model provisions on the protection of computer software, Ginebra, 1978. (WIPO Sui Generis Proposal) WIPO Group of Experts on the Legal Protection of Computer Software (Ginebra, del 13 al 17 de juny de 1983), Copyright, Volum 19, Issue 9, 1983, pàg. 271-279 WIPO Group of Experts on the Copyright Aspects of the Protection of Computer Software, Ginebra, del 25 de febrer a l'1 de març de 1985. Copyright, volum 21, fascicle 4, pàg. 146-149. WIPO Proposal by Argentina and Brazil for the Establishment of a Development Agenda for WIPO, Ginebra, 24 d'agost de 2004. (WIPO Development Agenda Proposal) WTO Treaty on Trade Related Aspects of Intellectual Property Rights, Marroc, 15 d'abril de 1994 (TRIPS) Definicions i polítiques Contracte Social de Debian 1.1 (http://www.debian.org/social_contract.ca.html) La definició de Programari Lliure (http://www.gnu.org/philosophy/free-sw.ca.html) Open Source Definition (http://www.opensource.org/docs/definition.php) W3C Patent Policy (http://www.w3.org/Consortium/Patent-Policy/) Llicències (es poden trobar totes excepte la Llicència Unix a http://www.opensource.org/) Academic Free License Llicència Apache 2.0 Llicència artística Llicència BSD Common Public License (Llicència Pública Comuna) GNU General Public License (GPL, Llicència pública general) GNU Lesser General Public License (LGPL, Llicència Pública General Menor de GNU) Llicència MIT Mozilla Public License 1.1 (MPL, Llicència pública de Mozilla) Open Software License Qt Public License (QPL, Llicència pública de Qt) Llicència Sleepycat Llicència Unix (1974): “Software Agreement between Western Electric Company, Incorporated and Katholieke Universiteit effective as of 1st December 1974”. Disponible a http://cm.bell-labs.com/cm/cs/who/dmr/licenses/6thEdlicence.pdf Índex analític Adobe 136 Academic Free License 175 Advanced Micro Devices (AMD) 151 Affero Public License (Llicència pública Affero) 201 Amazon 200 Amdahl 129 Amstrad 128 Apache 2, 24, 30, 53, 83, 175, 203, 241 Llicència 175, 221-223, 265 Apple 2, 54, 57, 127-129, 175, 241, 258, 282 Darwin 296-297 Mac OS 27, 295-296, 300-301 Apple Public Source License 175, 287 Application Service Providing (ASP, proveïdor d'aplicacions) 199 Applied Data Research (ADR) 118 Artistic License (Llicència artística) 174-175, 223-224 Atari 282 AT&T 43-47, 50, 129, 282 Autodesk 136 Axmark, David 310 Ballmer, Steve 189 Band, Jonathan 126 Bakels, Reinier 269 Berkeley Software Design 46 Berkeley Software Distribution (BSD) 43- 47, 50, 52, 200, 219-220 FreeBSD 47, 200, 295-296 OpenBSD 47, 280, 295 NetBSD 47, 295 Llicència BSD 47, 219-221, 265, 287, 292, 319 Berkeley Softworks 289 GeoWorks 289 Besen, Stanley 89 Blind, Knuth 270 Borland 129-130 Braunstein, Yale M. 91 Broderbund Software 129 Bull 128 Business Software Alliance (BSA) 87-88, 159 BSD vegeu Berkeley Software Distribution Calabresi, Guido 243, 263 Caldera 50-51 Campbell-Kelly, Martin 19, 34 Chandler, Alfred D. 9 Chesbrough, Henry W. 108 Christensen, Clayton M. 9 codi obert estudi acadèmic del 14 beneficis i reptes 55-56 comunitat 61-63, 260 empreses 259 definició de 5 control de desenvolupament 278-281 bifurcació 280, 302-303, 311 llicències categoritzades 169-175 moviment vegeu comunitat llicències més populars 176-177 estratègia de preus 276-277 iniciatives públiques 67-68 codi tancat vegeu privatiu Coase, Ronald H. 108 Commodore 282 Common Public License (CPL, Llicència pública comuna) 175, 205-208, 210-211, 218, 223, 265 Compaq 129 compatibilitat definició de 76-79 compatibilitat amb la GPL 203 i fragmentació 79 entre llicències 115, 123, 159, 162-163 competència, legislació sobre investigació antimonopoli d'IBM 22 i propietat intel·lectual 78-80 Computer Associates 259 CONTU (US National Commission on New Technological Uses of Copyrighted Works) 123 copyleft vegeu reciprocitat copyright mecanismes de compensació 65-67 Computer Associates v. Altai 129 obres derivades 92-93, 123-138, 162 economia 58-69 abast 91-93 primers copyrights de programari 84 teoria dels incentius 58-60 risc d'infracció 167-168 interoperabilitat, debat 87-91 responsabilitat 93 drets morals 93, 111-112, 114, 123, 162 modificació vegeu obres derivades límits òptims 62-65 propostes de reforma 67-69 directiva sobre copyright de programari 89-90 Creative Commons 213, 225-235 Davis, Randall 183 Dedrick, Jason 283 Defense Advanced Research Projects Agency (DARPA) 44 derivades, obres vegeu copyright Digital Equipment Corporation (DEC) 129 Digital Research 125-126, 289 CP/M 125 GEM 289 drets de propietat intel·lectual (DPI) vegeu també copyright i patents i polítiques sobre competència 78-80 equilibri de 105-110 definició de 3-4 infraccions com a accidents 166-165 riscs d'infracció 173-174, 178-179, 186-187 assegurança 170-171 dret i economia dels 10 gestió dels 3, 60, 178-179, 221-222 política social 3, 173-174, 180, 183-186, 222-224 Drucker, Peter 66 economia perspectiva de xarxa 7-8 Elecció de Programari 68 Electronic Frontier Foundation 62 Emacs 48-49 Eng, Eirik 312 Fabry, Bob 44 Fershtman, Chaim 177 Fink, Martin 61 Foray, Donique 110 Ford, Nelson 36 Forrester Research 55 Free Software Foundation 44, 47-49, 62, 66 114, 166, 173, 186-187, 214-215, 221, 229, 245, 261, 296-298, 311, 314, 320 Fujitsu 128 Gandal, Neil 177 Gates, Bill 57-58 Gnome 299 GNU/Linux vegeu Linux GNU excepció en la llicència del GCC (compilador de GNU) 192-193 excepció en la llicència de Crypto 216 Emacs 48-49 General Public License (GPL, Llicència pública general) 9, 34-36, 124-141, 147-150, 168, 172, 178, 180- 181, 202, 211-212, 214 Lesser General Public License (LGPL, Llicència pública general menor) 146-150, 180 llicències 119-120, 122 Manifest 33 Projecte 33, 41, 202 Goetz, Marty 119 Google 27, 200 Gosling, James 48 Gottinger, Hans W. 72 GPL vegeu GNU General Public License Guile 216 hacker 44, 50, 57-59, 320 Hayek, Friedrich A. 103 Hewlett-Packard (HP) 21, 37, 39, 104, 164-165, 174 176 història empresarial aproximació continuada 8-9 Hollerith, Herman 31-32 Hubbard, Jordan 295 Humprey, Watts S. 32 IBM 2, 20-21, 23-24, 29, 31-34, 50-51, 53-54, 57, 112, 114, 118, 129, 136, 151, 175, 206-207, 241, 257-259, 288-289, 293, 299-300 AIX 284, 300 OS/2 289 decisió de separació 31-35 IDC 27, 87 incompatibilitat vegeu compatibilitat indemnització 166, 223 indústria del programari estudi acadèmic de la 11 definició de 5 repàs històric 19-21 innovació en la 99-101 mercats regionals 21 dimensió de mercat 21-22 Intel 151 innovacions un model obert 75-78, 163 en la indústria informàtica 69-71 i patents 71-73 mitjans d'apropiació 74-75 interoperabilitat vegeu compatibilitat i copyright Jaeger, Till 169, 194 Jobs, Steve 295 Joy, Bill 44 K Desktop Environment (KDE) 299, 312-314 Katoh, Masanobu 126 Landes, William M. 89, 93 dret dret comparatiu 12-13 i economia 10-11, 14 Lemley, Mark A. 105 Leonard, Andrew 179 Lerner, Josh 177, 274 Lessig, Lawrence 226, 325 Levin, Richard C. 104 LGPL vegeu GNU Lesser General Public License (Llicència pública general menor GNU) Liebowitz, Stan 72, 90, 113 Linux 2, 13, 24, 27, 30, 43, 47, 50-54, 59, 62, 82-83, 114, 173, 196-198, 200, 239, 241, 245-246, 255-256, 258, 260-261, 283-284, 286, 293, 296-301, 306, 310, 312, 318 llei antimonopoli vegeu llei de la competència Llicència artística 174-175, 223-224 llicència dual 206-217 llicències vegeu també codi obert i privatiu programari definició de 4 i garanties 5, 123, 146, 158-159, 162, 169-170 Locke, John 85 Lotus 127, 129-130, 146 Mac vegeu Apple Machlup, Fritz 84, 102 Margolis, Stephen E. 72, 113 Massachusetts Institute of Technology (MIT) 47, 59 Llicència MIT 221 Mattei, Ugo 12 McKusick, Marshall Kirk 45 Metzger, Axel 169, 194 Microsoft 1, 14, 18-20, 25, 37, 40, 47, 73, 78-80, 89-90, 95, 104, 130-131, 165, 176, 192-194, 196-201, 218 i GPL 130-131, 198 i codi obert 198 MS/DOS 88, 192, 196 Office 20 Codi Compartit 197-198 Windows 18-20, 192-193, 196-200, 204- 205, 211 Miller, Robin 321 MIT vegeu Massachusetts Institute of Technology MontaVista 299 Mozilla 203 Llicència pública de Mozilla 217-219, 223 Mundie, Craig 1 MySQL 2, 17, 21, 120, 134-135, 137, 140- 141, 165, 206, 208, 211-212 negoci informàtic model de producte 20-21, 23, 26-28 model de servei 20-21, 27-28 definició de models 19-21 Netscape 1-2, 52-53, 175, 217 NewsForge 321 NeXT 295 NeXTStep 295 Nichols, Kenneth 270 Nord, Haavard 312 normes comunitàries vegeu normes socials normes socials 12-14, 167-168, 235 North, Douglass C. 61, 111 Novell 31, 47, 50-51, 129, 255-256, 258, 299 Olivetti 128 Olsen, Michael 308 O'Mahony, Siobhán 168 innovació oberta Open Software License (OSL, Llicència de programari obert) 121, 138, 144-146, 150, 170 Open Source Definition 4, 113-116, 137, 163, 188 Open Source Development Labs 175 Open Source Initiative 30, 36-37, 43-44, 113, 121, 211, 218 història de 36-37 Open Source Risk Management Inc. 245 OpenSSH 280 Oracle 21, 24, 53-54, 57, 136, 299 ordinador personal (PC) 14, 17, 24-25, 104-105, 192-193 O'Reilly, Tim 53, 200 Organització Mundial del Comerç (OMC) 142, 328 Treaty on Trade Related Aspects of Intellectual Property (TRIPS) 142-143, 273 Organització Mundial per a la Propietat Intel·lectual (OMPI) 121, 124, 159-160, 325, 328 proposta de llei de model informàtic 121-122 Pbt Consultants 269 patents i GPL 139-140 i innovació 71-73 i codi obert 123 i desenvolupament de programari 182-183 com a actius estratègics 73-74, 171-172 abast 99-101 primeres patents de programari 82-83 evolució històrica 94-98 risc d'usurpació 168-169, 185-186 normativa internacional 98-99 estadístiques 175-176 clàusules d'extinció 180-181 Perens, Bruce 53 Perl 24 PHP 24, 204 pirateria 88-89, 148 Plant, Arnold 87 Posner, Richard A. 89, 93, 113 Progress Software Corporation 195-196 Gemini 195-196 programari privatiu models de llicència 26-27, 189 distribució del codi font 29-30 protecció anticòpia vegeu protecció tècnica protecció tècnica 22-23, 101-105 legislació antipirateria 102-103 trusted computing 104-105, 199-200 programari de prova 35-36 domini públic Public Software Library (PsL) 37 Pugh, Emerson W. 31 Python 203 Q Public License (QPL) 213-214 Raskind, Leo 89 Ravicher, Dan 182 Raymond, Eric S. 1, 52, 60-62, 65-66, 96 reciprocitat (copyleft) història de la 34 definició de 117-119 estàndard 146-151 forta 124-146, 214 Red Hat 241, 255-256, 258, 260, 299 Riis, Thomas 89 Rosen, Lawrence E. 210-212 Samuelson, Pamela 325 SCO 47, 50-51, 239-240, 255-256, 258 Seattle Software Works 125 Seltzer, Margo 307 Shapiro, Carl 105 shareware (vegeu programari de prova) Shy, Oz 72, 316 Slashdot 321-322 Sleepycat Software 31, 303, 307-309, 311, 314 BerkeleyDB (BDB) 307-309 Llicència Sleepycat 176, 307-309, 314 Software Choice (vegeu Elecció de Programari) software copyright vegeu copyright patents de programari vegeu patents productes informàtics com a béns capitals 74 com a components de sistemes 76-77 com a béns d'informació 72-74 com a béns públics 75 captius 79-80 perspectiva d'economia de xarxa 72, 79-80, 278-279 Sony 151 Sourceforge 176-177, 315 SSH Communications Security 279 Stanford University 226 Stac Electronics 105 Stallman, Richard 47-50, 52, 59-60, 62-66, 127, 173, 214-215, 261, 297-298, 321 Tecnologia d'emmagatzematge 128 SUN Microsystems 136, 151, 175, 259, 299-300, 355 Llicència Pública de Sun 175 Sun Industry Standards Source License 175 Solaris 259, 300 Thisse, Jacques-Francois 316 Tirole, Jean 177, 315 Torrisi, Salvatore 23, 100 Torvalds, Linus 13, 50, 59-60, 64, 196-199, 264, 297-298 Trolltech 31, 303, 305, 312-313, 317 Qt 312-313 Universitat de Califòrnia (a Berkeley) 44-47, 59, 174, 283, 289, 307-308 Universitat d'Hèlsinki 59 Unix 26, 34-35, 43-48, 50-51, 59, 78, 114, 174, 197, 282-283, 293, 295, 297-298, 301, 307, 310, 312 Unix System Laboratories 46 Wall, Larry 223-224 Watson, Thomas J. Sr. i Jr. 32 West, Joel 283 Whitlow, Duane 118 Whitlow Computer Systems 118 Widenius, Michael 211 Windows vegeu Microsoft World Intellectual Property Organization (WIPO), vegeu Organització Mundial per a la Propietat Intel·lectual (OMPI) WordPerfect 129 X11 299 Yahoo 200 Ylönen, Tatu 279