Inici » Llibres » L'expansió de les llicències de codi obert » Us ofensiu del codi obert: Alguns casos pràctics sobre llicències » Llicències de codi obert per obtenir guanys

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

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

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

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. [5] 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 factod'Internet. [6] 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. [7]

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

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

.^1. Vegeu la secció 3.2.5

.^2. Tot i que algunes llicències de codi obert recents miren, de forma explícita, d'impedir l'ús d'aquest model.

.^3. Rosen (2001).

.^4. Un exemple recent va ser el projecte Xfree86, una implementació de programari lliure del sistema de finestres X (un component clau dels sistemes operatius basats en Unix, entre els quals hi ha Linux), que va canviar la seva política de llicències per una altra de més restrictiva a començaments del 2004. De seguida va aparèixer una ramificació (X.org) que va prendre la iniciativa amb el desenvolupament. Vegeu Wheeler (2004).

.^5. Per exemple, Raymond (2001) explica que "les bifurcacions en els grans projectes no són habituals i sempre van acompanyades d'un canvi de nom i d'una gran dosi d'autojustificació pública. Sembla evident que en aquests casos (...) els promotors de les ramificacions tenien la impressió que anaven en contra d'una norma comunitària prou establerta."

.^6. L'SSH, a més, es va estandarditzar a través de l'IETF.

.^7. La pàgina web del projecte diu: "OpenSSH és una derivació de la versió original lliure ssh 1.2.12 de Tatu Ylönen. Aquesta versió va ser la darrera que era prou lliure per poder ser reutilitzada en el nostre projecte".

.^8. La llicència SSH inicial feia al·lusió a dues patents (anomenades RSA i IDEA).

.^9. Vegeu OpenSSH (2001). Ylönen va fer, a més, un comentari poc afortunat: "El programari lliure acostuma a ser bo, però normalment no és acceptable per als sistemes crítics d'ús comercial (i penso que la situació no canviarà durant molts anys)." La resposta de la comunitat a Ylönen i la seva empresa no va ser pas, evidentment, positiva.

.^10. Vegeu ScanSSH (2004) per consultar les últimes estadístiques d'utilització d'SSH. Deixo en mans del lector les especulacions sobre què hauria passat si l'empresa hagués decidit mantenir de bon començament el seu suport al desenvolupament de la versió de codi obert i hagués evitat l'aparició d'una ramificació.