Inici » Llibres » L'expansió de les llicències de codi obert » Defensa amb codi obert. Gestió del risc d'usurpació i patents » Com fer front al risc d'usurpació dels DPI?

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. [1]

El marc teòric d'aquest apartat es basa principalment en les teories econòmiques de responsabilitat civil del producte, [2] assegurança de responsabilitat [3] i estratègia de patent. [4] . 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.

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 intel·lectual.

Suposem que tenim un producte de codi obert i que el Desenvolupador ₁ (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 ₂ 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'accidentresultant 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? [5]

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. [6] 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. [7]

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.) [8]

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.

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. [9] 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. [10] 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). [11]

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. [12] 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. [13] 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'assegurancessemblant 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. [14]

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. [15]

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. [16] Si, 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. [17] 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. [18]

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. [19] Naturalment, 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. [20] 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. [21] 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. [22] Però 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.

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. [23] Novell i Red Hat van ser els següents, a començaments del 2004. [24] 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. [25] 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. [26]

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: [27]

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. [28]

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. [29] 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. [30] 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. [31] Fins i tot Microsoft ha dit públicament que només vol explorar les possibilitats de llicència, sense intenció d'atacar. [32] 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. [33]

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. [34] 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. [35]

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. [36] 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. [37] No és d'estranyar, doncs, que moltes empreses de codi obert s'oposin a les patents de forma contundent a nivell de normativa. [38]

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. [39] 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". [40]

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.

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. [41] 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.

.^1. Vegeu Barr (2004), l'informe de juliol de 2002 on els directius de HP exposen que: «Microsoft està a punt d'iniciar accions legals contra la indústria per fer servir programari de codi obert que podria obligar-nos a no utilitzar certs productes populars de codi obert.»

.^2. P.e. McKean (1970), Calabresi (1970), Epple i Raviv (1978), Viscusi i Moore (1993)

.^3. P.e. Shavell (1982), Sarath (1991), Winter (1991).

.^4. P.e. Teece (2000), Shapiro (2001), Bessen (2004).

.^5. Vegeu Calabresi (1970).

.^6. De fet, les llicències es poden basar en uns altres drets a banda dels del copyright, però per als objectius d'aquest apartat en tenim prou amb les llicències basades únicament en el copyright.

.^7. Cohen (2003).

.^8. OSRM (2004a), OSRM (2004b).

.^9. Calabresi (1970), McKean (1970).

.^10. Viscusi i Moore (1993)

.^11. McKean (1970), Epple i Raviv (1978)

.^12. Exemple infame de Brooks (1975)

.^13. Shavell (1982).

.^14. McKean (1970)

.^15. Betterle and Davison-Jenkins (2001), CJA Consultants (2003).

.^16. Sarath (1991).

.^17. Vegeu Bessen (2004) per tenir-ne una visió general. El concepte de l'embolic de patents no és nou. Moltes altres tecnologies emergents han patit el mateix fenomen, per exemple els semiconductors (Lemley 2002) o les fotocopiadores (Melamed and Stoeppelwerth 2002).

.^18. Shapiro (2001), Bessen i Hunt (2003).

.^19. Vegeu e.g. Bednarek i Ineichen (2003).

.^20. Lanjouw i Schankermann (2001) i Lemley (2001)

.^21. Allison i Lemley (1998). Aquest fet ha portat Lemley i Shapiro (2004) a definir les patents com a drets de propietat no exclusius sinó, més aviat, "probabilístics", semblants a una butlleta de loteria.

.^22. Landes i Posner (2003).

.^23. HP (2003).

.^24. Novell (2004), Red Hat (2004)

.^25. Fichera (2004).

.^26. Open Source Development Labs (2003).

.^27. Les dades sobre les patents s'han obtingut de la base de dades en línia de l'oficina de patents i marques dels Estats Units (USPTO). Les dades de la figura corresponents a HP inclouen tant Hewlett-Packard com Compaq. Les dades engloben totes les patents, del tipus que siguin, concedides a les empreses en qüestió; la majoria de les atorgades en els últims anys podrien considerar-se "patents de programari".

.^28. El número de patents per les quals s'ha satisfet la quota anual i que formen part activa de les carteres de les empreses és, òbviament, menor (Lanjouw i Pakes 1998).

.^29. Fried (2004).

.^30. Shankland (2004b).

.^31. Barr (2004).

.^32. Stone (2004). Naturalment, cap d'aquestes afirmacions té validesa legal.

.^33. Vegeu IBM (2005), SUN (2005) i Computer Business Review (2005). Per ser exactes, el compromís de SUN es limita simplement als usuaris de la seva pròpia llicència de codi obert (incompatible) i el d'IBM a totes les llicències de codi obert acceptades per la Iniciativa de Codi Obert.

.^34. Välimäki (2003b).

.^35. CJA Consultants (2003).

.^36. Red Hat (2004b).

.^37. Lanjouw i Schankermann (2004).

.^38. P.e. Farber (2003)

.^39. OSDL (2004).

.^40. Kelly (2000).

.^41. Vegeu e.g. Teece (2000) i Glazer (1998).