05) seoane, j., gonzález, j. m. robles, g. (2003). “aspectos legales”; “economía“y...

Introduccin al software libreEd. 2.0.1

37 / 200

Captulo 3

Aspectos legales

The licenses for most software are designed to take away your freedom to share and change it.

Las licencias de la mayora de los programas estn diseadas para quitarte la libertad de compartirlos y cambiarlos.

GNU General Public License, version 2

En este captulo se presentan los principales aspectos legales relacionados con el software libre. Para ponerlos en contexto, seempieza por una pequea introduccin a los conceptos ms bsicos de la propiedad intelectual e industrial, antes de exponer ladefinicin detallada de software libre, software de fuente abierta y otros conceptos relacionados. Se analizan tambin con ciertodetalle las licencias de software libre ms habituales y su impacto sobre los modelos de negocio (que se tratar con ms detalleen captulo 5) y los modelos de desarrollo.

3.1. Breve introduccin a la propiedad intelectual

El trmino propiedad intelectual tiene varias acepciones segn el contexto y quin lo utiliza. Hoy da se utiliza en muchos forospara agrupar distintos privilegios que se otorgan sobre bienes intangibles con valor econmico. Entre ellos podemos destacar losde copyright (derechos de autor) y similares, que protegen de la copia no autorizada los trabajos literarios o artsticos, programasde ordenador, recopilaciones de datos, diseos industriales, etc.; las marcas, que protegen smbolos; las indicaciones geogrficas,que protegen denominaciones de origen; los secretos industriales, que respaldan la ocultacin de informacin; y las patentes, queotorgan monopolios temporales sobre invenciones a cambio de desvelarlas. Sin embargo en muchas tradiciones legales, entreellas la hispana, se distingue entre la propiedad intelectual, que se refiere exclusivamente a los derechos de autor y la propiedadindustrial, que abarca las figuras restantes.

En cualquier caso, la legislacin que se aplica en todos estos aspectos es una de la ms coordinada en prcticamente todo elmundo. Por un lado la OMPI (Organizacin Mundial de la Propiedad Intelectual, WIPO segn sus siglas en ingls) promueveambos tipos de propiedad en todos sus aspectos. Por otro, el acuerdo TRIPS (aspectos comerciales de la propiedad intelectual)establece unos mnimos de proteccin y obliga a todos los pases miembros de la OMC (Organizacin Mundial del Comercio,WTO) a desarrollarlos en unos ciertos plazos que dependen del nivel de desarrollo del pas1.

La Declaracin Universal de los Derechos Humanos reconoce en su artculo 27 el derecho a que se protejan los intereses moralesy materiales que correspondan a cualquier persona por razn de las producciones cientficas, literarias o artsticas de que seanautores. Sin embargo, en muchos casos (y de forma habitual en el caso del software), este derecho suele ser transferido en laprctica a las empresas que emplean a los creadores o que comercializan sus creaciones. No obstante, la propiedad intelectualse justifica no slo por razones morales, sino tambin prcticas, para dar cumplimiento a otro derecho: el de la sociedad abeneficiarse de las creaciones, incentivndolas con beneficios y protegiendo las inversiones para la creacin, investigacin ydesarrollo. Para armonizar ambos derechos, la propiedad intelectual es temporal, caducando cuando ha cumplido su funcin depromocin.

Pero la caducidad no es la nica caracterstica que diferencia la propiedad intelectual de la ordinaria. Hoy da, los objetos de lamisma pueden copiarse fcil y econmicamente, sin prdida de calidad. La copia no perjudica a quien ya disfruta de lo copiado,

1El acuerdo TRIPS fue firmado por la presin de los pases industrializados (especialmente Estados Unidos y Japn).

lromanCuadro de texto05) Seoane, J.; Gonzlez, J. M. & Robles, G. (2003). Aspectos legales; Economa" & "Software libre y administraciones pblicas en Introduccin al software libre. Espaa: Creative Commons, pp. 37-46; 53-67 y 68-76.

lromanieu


38 / 200

al contrario que el robo, que s priva del objeto al poseedor original. La copia s puede perjudicar al propietario, ya que lepriva potencialmente de los ingresos de una venta. El control de la copia de intangibles es mucho ms complicado que el delrobo de bienes tangibles y puede llevarnos a una sociedad policial, que necesite controlar todas las copias de informacin, y auna gran inseguridad jurdica, porque aumentan las posibilidades de violacin accidental de derechos. Adems la creatividad esincremental: al crear siempre se copia algo, y la lnea divisoria entre la copia burda y la inspiracin es sutil.

Para profundizar ms en todo esto, en los siguientes apartados se repasan algunas de las categoras de la propiedad intelectual.En cualquier caso, se puede adelantar ya que el software libre propone un punto de equilibrio nuevo en este mbito, primandolos beneficios de la copia y la innovacin incremental frente al control exclusivo de una obra por su autor.

3.1.1. Derechos de autor

Los derechos de autor (copyright) protegen la expresin de un contenido, no el contenido en s mismo. Se desarrollaron pararecompensar a los autores de libros o de arte. Las obras protegidas pueden expresar ideas, conocimientos o mtodos librementeutilizables, pero se prohbe reproducirlas sin permiso, total o parcialmente, con o sin modificaciones. Esta proteccin es muy sen-cilla, ya que entra automticamente en vigor en el momento de publicacin de la obra con mbito casi universal. Modernamentese ha extendido a los programas de ordenador y (en algunas reas geogrficas) a recopilaciones de datos.

La ley de la propiedad intelectual (LPI), en Espaa, y leyes similares en otros pases, desarrolladas sobre la base del Conveniode Berna para la proteccin de trabajos literarios y artsticos de 1886, regulan los derechos de autor. Estos derechos se dividenen derechos morales y patrimoniales. Los primeros garantizan al autor el control sobre la divulgacin de su obra, con nombreo seudnimo, el reconocimiento de autora, el respeto a la integridad de la obra y el derecho de modificacin y retirada. Lossegundos le dan derecho a explotar econmicamente su obra y pueden ser cedidos total o parcialmente, de forma exclusiva o no,a un tercero. Los derechos morales son vitalicios o indefinidos, mientras que los patrimoniales tienen una duracin bastante larga(70 aos despus de de la muerte del autor, si es una persona fsica, en el caso de la ley espaola).

La cesin de derechos se especifica por un contrato denominado licencia. En el caso de programas privativos, stos generalmentese distribuyen por medio de licencias de uso no exclusivo que se entiende que se aceptan automticamente al abrir o instalarel producto. No es necesario pues firmar el contrato, ya que, en el caso de no aceptarlo el receptor, rigen automticamente losderechos por omisin de la ley, es decir, ninguno. Las licencias no pueden restringir algunos derechos que otorga la legislacinvigente, como el de hacer copias privadas de arte o msica, lo que permite regalar una copia de una grabacin a un amigo, peroeste derecho no es aplicable a los programas. Segn la LPI de 1996[77], modificada en 2006[79], de los programas siempre sepuede hacer una copia de seguridad, se pueden estudiar para hacer programas interoperables y se pueden corregir y adaptar anuestras necesidades (difcil, porque no solemos disponer de los fuentes). Estos derechos no pueden ser restringidos por licencias,aunque las leyes estn en proceso de revisin, en una tendencia aparentemente imparable a reducir los derechos de los usuarios.Las recopilaciones organizadas de obras o datos ajenos tambin estn sometidas a derechos de autor, si bien los trminos sondistintos y la duracin menor.

Las nuevas tecnologas de la informacin, y en especial la Red, han trastocado profundamente la proteccin de los derechos deautor, ya que las expresiones de contenidos son mucho ms fciles que copiar que los contenidos mismos. Y en el caso de losprogramas y algunas obras de arte (msica, imgenes, pelculas, e incluso literatura) funcionan automticamente en el ordenador,sin necesidad de un esfuerzo humano apreciable. En cambio los diseos o inventos hay que construirlos y, posiblemente ponerlosen produccin. Esta posibilidad de crear riqueza sin coste ha llevado a gran parte de la sociedad, en particular a los pases pobres,a duplicar programas sin pagar licencia, no existiendo una conciencia social que eso sea una mala accin (como s la suele habercon respecto al robo de bienes fsicos, por ejemplo). Por otro lado los fabricantes de programas, solos o en coalicin (por ejemplola BSA, Business Software Alliance) presionan fuertemente para que las licencias se paguen y los gobiernos persigan lo que seha dado en llamar piratera.

NotaEl trmino piratera se ha popularizado como sinnimo de violacin de cualquier forma de propiedad intelectual, especialmenteen el caso de la copia ilegal de programas, msica y pelculas. El trmino parece exagerado, y en el diccionario de la RealAcademia Espaola de la Lengua aparece como una acepcin en sentido figurado, ya que el trmino original se refiere a robocon violencia en el mar. Por ello Richard Stallman recomienda evitarla[212].

Precisamente para proteger los derechos de autor de aquellos contenidos con licencias privativas, nacen los llamados sistemasDRM (Digital Rights Management, gestin de derechos digitales), con fines de controlar el acceso y utilizacin de datos en

lromanieu


39 / 200

soporte digital o restringir su uso a ciertos dispositivos. El empleo de sistemas DRM es fuertemente criticado por muchossectores al tratar de proteger derechos de autor imponiendo restricciones ms all de las suficientes, por lo que algunos, comola Free Software Foundation, recomiendan interpretar las siglas como Digital Restrictions Management (gestin de restriccionesdigitales), tratando de evitar la utilizacin de la palabra derechos (en ingls, rights), al considerar que se privan excesivos derechosde los usuarios para lograr satisfacer los derechos de los autores.

3.1.2. Secreto comercial

Otro de los recursos que tienen las empresas para rentabilizar sus inversiones es el secreto comercial, protegido por las leyesde propiedad industrial, siempre que las empresas tomen las medidas suficientes para ocultar la informacin que no quierendesvelar. En el caso de productos qumicos o farmacuticos que requieran aprobacin gubernamental, el Estado se comprometea no desvelar los datos entregados que no sea obligatorio hacer pblicos.

Una de las aplicaciones del secreto comercial ms conocidas se encuentra en la industria del software propietario, que general-mente comercializa programas compilados sin dar acceso al cdigo fuente, para as impedir el desarrollo de programas derivados.

A primera vista parece que la proteccin del secreto comercial es perversa, ya que puede privar indefinidamente a la sociedadde conocimientos tiles. En cierto modo as lo entienden algunas legislaciones, permitiendo la ingeniera inversa para desarrollarproductos sustitutos, aunque la presin de las industrias ha conseguido que en muchos pases sta sea una actividad prohibida yen otros slo est permitida en aras de la compatibilidad.

Sea perverso o no el secreto comercial, en muchos casos es mejor que una patente, ya que da una ventaja competitiva al quepone un producto en el mercado, mientras la competencia trata de imitarlo con ingeniera inversa. Cuanto ms sofisticado sea elproducto, ms costar a la competencia reproducirlo, mientras que si es trivial, lo copiar rpidamente. La imitacin con mejorasha sido fundamental para el desarrollo de las que hoy son superpotencias (Estados Unidos y Japn) y es muy importante para laindependencia econmica de los pases en desarrollo.

3.1.3. Patentes y modelos de utilidad

La alternativa al secreto comercial es la patente. A cambio de un monopolio de 17 a 25 aos y un determinado coste econmico,un invento es revelado pblicamente, de forma que sea fcilmente reproducible. Con ella se pretende promover la investigacinprivada, sin coste para el contribuyente y sin que el resultado se pierda. El poseedor de una patente puede decidir si permite aotros utilizarla y el precio que debe pagar por la licencia.

La doctrina oficial es que el sistema de patentes promueve la innovacin, pero cada vez ms se hacen or voces que afirman quela dificulta, ya sea porque opinan que el sistema est mal implementado, ya porque creen que es perverso en s mismo [194].

Lo que es considerado un invento ha ido variando con el tiempo, existiendo grandes presiones para ampliar la cobertura delsistema, incluyendo algoritmos, programas, modelos de negocio, sustancias naturales, genes y formas de vida, incluidas plantasy animales. TRIPS exige que el sistema de patentes no discrimine ningn mbito del saber. Las presiones de la OrganizacinMundial de la Propiedad Intelectual (OMPI o WIPO) pretenden eliminar la necesidad de que el invento tenga aplicacin indus-trial y tambin rebajar los estndares de inventiva exigibles en una patente. Estados Unidos est a la cabeza de los pases con unmnimo de exigencias sobre lo que es patentable, siendo adems el ms beligerante para que otros pases adopten sus estndares,sin acordarse que l mismo se neg a aceptar las patentes extranjeras cuando era un pas subdesarrollado.

Una vez obtenida una patente, los derechos del poseedor son independientes de la calidad del invento y del esfuerzo invertidoen obtenerlo. Dado el coste de mantenimiento de una patente y los costes de litigacin, solamente las grandes empresas puedenmantener y mantienen una amplia cartera de patentes que la sitan en una posicin que les permite ahogar cualquier competencia.Dada la facilidad para colocar patentes sobre soluciones triviales o de muy amplia aplicabilidad, pueden monopolizar para s unespacio muy amplio de actividad econmica.

Con patentes, muchas actividades, especialmente la programacin, se hacen extremadamente arriesgadas, ya que es muy fcilque en el desarrollo de un programa complicado se viole accidentalmente alguna patente. Cuando dos o ms empresas estninvestigando para resolver un problema, es muy probable que lleguen a una solucin similar casi al mismo tiempo, pero slo una(generalmente la de ms recursos) lograr patentar su invento, perdiendo las otras toda posibilidad de rentabilizar su inversin.Todo desarrollo tcnico complejo puede convertirse en una pesadilla si para cada una de las soluciones de sus partes es necesarioinvestigar si la solucin encontrada est patentada (o en trmite), para intentar obtener la licencia o para buscar una solucinalternativa. Este problema es especialmente grave en el software libre, donde las violaciones de patentes de algoritmos sonevidentes por simple inspeccin del cdigo. Aunque en Europa an es ilegal patentar un algoritmo, puede serlo en muy breveplazo, quiz cuando el lector lea estas lneas.

lromanieu


40 / 200

3.1.4. Marcas y logotipos registrados

Las marcas y logotipos son nombres y smbolos que representan un acervo de calidad (o una gran inversin en publicidad).No tienen gran importancia dentro del software libre, posiblemente porque tiene un coste registrarlas. As, solamente algunosnombres importantes, como Open Source (por Open Source Foundation), Debian (por Software in the Public Interest), GNOME(GNOME Foundation), GNU (Free Software Foundation), OpenOffice.org (por SUN) estn registrados, y slo en algunos pases.Sin embargo el no registro de nombres ha provocado problemas. Por ejemplo, en Estados Unidos (1996) y en Corea (1997) hahabido personas que han registrado el nombre Linux y han demandado dinero por su uso. La resolucin de estas disputas suponecostes legales y la necesidad de demostrar el uso del nombre anterior a la fecha del registro.

3.2. Licencias en el software libre

Legalmente hablando, la situacin de los programas libres respecto de los privativos no es muy diferente: tambin se distribuyenbajo licencia. Lo que que les diferencia es precisamente qu permite esa licencia. En el caso de las licencias de programas libres,que no restringen precisamente el uso, la redistribucin y la modificacin, lo que pueden imponer son condiciones a satisfacerprecisamente en caso de que se quiera redistribuir el programa. Por ejemplo, pueden exigir que se respeten las indicaciones deautora, o que se incluya el cdigo fuente si se quiere redistribuir el programa listo para ejecutar.

Aunque en esencia software libre y software propietario se diferencien en la licencia con la que los autores publican sus progra-mas, es importante hacer hincapi en que esta diferencia se refleja en condiciones de uso y redistribucin totalmente diferentes.Como se visto a lo largo de los ltimos aos, esto ha originado no slo mtodos de desarrollo totalmente diferentes, sino inclusoformas prcticamente opuestas (en muchos sentidos) de entender la informtica.

Las leyes sobre propiedad intelectual aseguran que en ausencia de permiso explcito no se puede hacer casi nada con una obra(en nuestro caso, un programa) que se recibe o se compra. Slo el autor (o el que posea los derechos de la obra) nos puede dar esepermiso. En cualquier caso, la propiedad de la obra no cambia por otorgar una licencia, ya que sta no supone transferencia depropiedad, sino solamente de derecho de uso y en algunos casos (obligados en el software libre), de distribucin y modificacin.Las licencias de software libre se diferencian de las privativas precisamente en que en lugar de restringir cuidadosamente lo que sepermite, otorgan ciertos permisos explcitos. Cuando recibes un programa libre puedes redistribuirlo o no, pero si lo redistribuyes,slo puedes hacerlo porque la licencia te lo permite. Pero para ello es preciso cumplir con la licencia... En definitiva, la licenciacontiene las normas de uso a las que han de atenerse usuarios, distribuidores, integradores y otras partes implicadas en el mundode la informtica.

Para comprender plenamente todos los entresijos legales que se van a presentar en este captulo (y que, sin duda, son muyimportantes para entender la naturaleza del software libre), tambin es necesario saber que cada nueva versin de un programaes considerada como una nueva obra. El autor tiene, otra vez, plena potestad para hacer con su obra lo que le apetezca, inclusodistribuirla con trminos y condiciones totalmente diferentes (o sea, una licencia diferente a la anterior). As, si el lector es autornico de un programa podr publicar una versin bajo una licencia de software libre y, si le apeteciere, otra posterior bajo unalicencia propietaria. En caso de existir ms autores, y que la nueva versin contenga cdigo cuya autora les corresponda y quese vaya a publicar bajo otras condiciones, todos ellos han de dar el visto bueno al cambio de licencia.

Un tema todava relativamente abierto es la licencia que se aplica a las contribuciones externas. Generalmente se supone que unapersona que contribuya al proyecto acepta de facto que su contribucin se ajuste a las condiciones especificadas por la licenciadel proyecto, aunque esto podra tener poco fundamento jurdico. La iniciativa de la Free Software Foundation de pedir mediantecarta (fsica) la cesin de todos los derechos de copyright a cualquiera que contribuya con ms de diez lneas de cdigo a unsubproyecto de GNU es una buena muestra de que en el mundo del software libre hay polticas ms estrictas con respecto deestas contribuciones.

Partiendo de todo lo dicho, vamos a centrarnos ya en el resto de este captulo en el anlisis de diversas licencias. Para poner encontexto este estudio, es preciso recordar que de ahora en adelante, cuando decimos que una licencia es de software libre, lodecimos en el sentido de que cumple las definiciones de software libre que se presentaron en seccin 1.1.1.

3.2.1. Tipos de licencias

La variedad de licencias libres es grande, aunque por razones prcticas la mayora de los proyectos utilizan un pequeo conjuntode cuatro o cinco. Por un lado muchos proyectos no quieren o no pueden dedicar recursos a disear una licencia propia. Por otra,la mayora de los usuarios prefieren referirse a una licencia ampliamente conocida que leerse y analizar licencias completas.

lromanieu


41 / 200

SugerenciaPuede ver recopiladas y comentadas tanto licencias consideradas libres como licencias consideradas no libres o libres peroincompatibles con la GPL desde el punto de vista de la FSF en [121]. El punto de vista filosficamente diferente de la OpenSource Initiative se refleja en su listado[181]. Pueden verse discrepancias en algunas licencias, como la Apple Public SourceLicense Ver. 1.2, considerada no libre por la FSF por la obligacin de publicar todos los cambios (aunque sean privados), noti-ficar a Apple de las redistribuciones, o por la posibilidad de revocacin unilateral. No obstante, la presin de esta clasificacinha hecho que Apple publique la versin 2.0 en Agosto de 2003, ya considerada libre por la FSF.

Es posible dividir las licencias de software libre en dos grandes familias. Una de ellas est compuesta por las licencias que noimponen condiciones especiales en la segunda redistribucin (esto es, que slo especifican que el software se puede redistribuiro modificar, pero no imponen condiciones especiales si se hace, lo que permite, por ejemplo, que alguien que reciba el progra-ma pueda despus redistribuirlo como software propietario): son las que llamaremos licencias permisivas. La otra familia, quedenominaremos licencias robustas (o licencias copyleft) incluye las que, al estilo de la GNU GPL, imponen condiciones en casode que se quiera redistribuir el software, condiciones que van en la lnea de forzar a que se sigan cumpliendo las condicionesde la licencia despus de la primera redistribucin. Mientras que el primer grupo hace nfasis en la libertad de quien recibe unprograma, ya que le permite hacer casi lo que quiera con l (en trminos de condiciones de futuras redistribuciones), el segundolo hace en la libertad de cualquiera que potencialmente pueda recibir algn da un trabajo derivado del programa (ya que obligaa que las sucesivas modificaciones y redistribuciones respeten los trminos de la licencia original).

La diferencia entre estos dos tipos de licencias ha sido (y es) tema de debate en la comunidad del software libre. En cualquiercaso, es conveniente recordar que todas ellas son licencias libres.

NotaEl trmino copyleft aplicado a una licencia, usado sobre todo por la Free Software Foundation para definir sus licencias, tieneimplicaciones similares a las del trmino licencia robusta, tal y como lo usamos en este texto.

3.2.2. Licencias permisivas

Las licencias permisivas, a veces tambin llamadas liberales o minimalistas, no imponen prcticamente ninguna condicin sobrequien recibe el software, y sin embargo le dan permiso de uso, redistribucin y modificacin. Este enfoque, desde un puntode vista, puede entenderse como la garanta de las mximas libertades para quien recibe un programa. Pero desde otro, puedeentenderse tambin como la mxima despreocupacin con respecto de que una vez recibido el programa por alguien, se sigangarantizando las mismas libertades cuando ese programa se redistribuye. De hecho, estas licencias tpicamente permiten que seredistribuya con licencia privativa un software cuyo autor distribuye con licencia permisiva.

Entre estas licencias, una de las ms conocidas es la licencia BSD, hasta el punto que en muchas ocasiones se refieren las licenciaspermisivas como licencias tipo BSD. La licencia BSD (Berkeley Software Distribution) tiene su origen en la publicacin deversiones de Unix realizadas por la universidad californiana de Berkeley, en EE.UU. La nica obligacin que exige es dar crditoa los autores, mientras que permite tanto la redistribucin binaria y la de los fuentes, aunque no obliga a ninguna de las dos enningn caso. Asimismo se da permiso para realizar modificaciones y ser integrada con otros programas casi sin restricciones.

NotaUna de las consecuencias prcticas de las licencias tipo BSD ha sido la difusin de estndares, ya que los desarrolladoresno encuentran ningn obstculo para realizar programas compatibles con una implementacin de referencia bajo este tipode licencia. De hecho, sta es una de las razones de la extraordinaria y rpida difusin de los protocolos de Internet y de lainterfaz de programacin basada en sockets, ya que la mayora de los desarrolladores comerciales deriv su realizacin de lade la Universidad de Berkeley.

Las licencias permisivas son bastante populares, y existe toda una familia con caractersticas similares a la BSD: XWindow,Tcl/Tk, Apache, etc. Histricamente estas licencias aparecieron debido a que el software correspondiente fue creado en univer-sidades con proyectos de investigacin financiados por el gobierno de los Estados Unidos. Estas universidades prescindan dela comercializacin de estos programas, asumiendo que ya haba sido pagado previamente por el Gobierno, y por tanto con losimpuestos de todos los contribuyentes, por lo que cualquier empresa o particular poda utilizar el software casi sin restricciones.

lromanieu


42 / 200

Como ya se ha comentado, a partir de un programa distribuido bajo una licencia permisiva pueda crearse otro (en realidad, unanueva versin) que sea privativo. Los crticos de las licencias BSD ven en esta caracterstica un peligro, ya que no se garantiza lalibertad de versiones futuras de los programas. Sus partidarios, por el contrario, ven en ella la mxima expresin de la libertad yargumentan que, a fin de cuentas, se puede hacer (casi) lo que se quiera con el software.

La mayora de las licencias permisivas son una copia calcada de la original de Berkeley, modificando todo lo referente a laautora. En algunos casos, como la licencia del proyecto Apache, incluyen alguna clusula adicional, como la imposibilidad dellamar las versiones redistribuidas de igual manera que el original. Todas suelen incluir, como la BSD, la prohibicin de usar elnombre del propietario de los derechos para promocionar productos derivados.

Asimismo, todas las licencias, sean de tipo BSD o no, incluyen una limitacin de garanta que es en realidad una negacinde garanta, necesaria para evitar demandas legales por garantas implcitas. Aunque se ha criticado mucho esta negacin degaranta en el software libre, es prctica habitual en el software propietario, que generalmente slo garantiza que el soporte escorrecto y el programa en cuestin se ejecuta.

Esquema resumen de la licencia BSDCopyright c el propietario. Todos los derechos reservados.Se permite la redistribucin en fuente y en binario con o sin modificacin, siempre que se cumplan las condiciones siguientes:

1. Las redistribuciones en fuente deben retener la nota de copyright y listar estas condiciones y la limitacin de garanta,

2. Las redistribuciones en binario deben reproducir la nota de copyright y listar estas condiciones y la limitacin de garantaen la documentacin.

3. Ni el nombre del propietario ni de los que han contribuido pueden usarse sin permiso para promocionar productosderivados de este programa.

ESTE PROGRAMA SE PROPORCIONA TAL CUAL, SIN GARANTAS EXPRESAS NI IMPLCITAS, TALES COMO SU APLI-CABILIDAD COMERCIAL O SU ADECUACIN PARA UN PROPSITO DETERMINADO. EN NINGN CASO EL PROPIE-TARIO SER RESPONSABLE DE NINGN DAO CAUSADO POR SU USO (INCLUYENDO PRDIDA DE DATOS, DEBENEFICIOS O INTERRUPCIN DE NEGOCIO).

A continuacin se describen brevemente algunas licencias permisivas:

Licencia de X Window versin 11 (X11) [73]

Es la licencia usada para la distribucin del sistema X Window, el sistema de ventanas ms ampliamente usado en el mundoUnix, y tambin en entornos GNU/Linux. Es una licencia muy similar a la licencia BSD, que permite redistribucin, uso ymodificacin prcticamente sin restricciones. A veces, esta licencia es llamada licencia MIT (con peligrosa poca precisin,porque el MIT ha usado otros tipos de licencias). Bajo esta licencia se distribuyen tambin trabajos derivados de X Windows,como XFree86.

Zope Public License 2.0 [76]

Esta licencia (habitualmente llamada ZPL) es usada para la distribucin de Zope (un servidor de aplicaciones) y otrosproductos relacionados. Es una licencia similar a la BSD, con el interesante detalle de prohibir expresamente el uso de marcasregistradas por Zope Corporation.

Licencia de Apache

Licencia bajo al que se distribuyen la mayor parte de los programas producidos por el proyecto Apache. Es similar a la licenciaBSD.

Hay algunos programas libres que no se distribuyen con una licencia especfica, sino que su autor los declara explcitamentepublic domain (en el dominio pblico, o del comn). La principal consecuencia de esta declaracin es que el autor renuncia atodos sus derechos sobre el programa, y por lo tanto puede modificarse, redistribuirse, usarse, etc. de cualquier manera. A efectosprcticos, es muy similar a que el programa est bajo una licencia tipo BSD.

lromanieu


43 / 200

3.2.3. Licencias robustas

3.2.3.1. La Licencia Pblica General de GNU (GNU GPL)

La Licencia Pblica General del proyecto GNU[118] (ms conocida por su acrnimo en ingls GPL), que mostramos traducidaen el apndice C, es con diferencia la licencia ms popular y conocida de todas las del mundo del software libre. Su autoracorresponde a la Free Software Foundation (promotora del proyecto GNU) y en un principio fue creada para ser la licencia detodo el software generado por la FSF. Sin embargo, su utilizacin ha ido ms all hasta convertirse en la licencia ms utilizada(por ejemplo, ms del 70% de los proyectos anunciados en FreshMeat estn licenciados bajo la GPL), incluso por proyectosbandera del mundo del software libre, como el ncleo Linux.

La licencia GPL es interesante desde el punto de vista legal porque hace un uso muy creativo de la legislacin de copyright,consiguiendo efectos prcticamente contrarios a los que se suponen de la aplicacin de esta legislacin: en lugar de limitarlos derechos de los usuarios, los garantiza. Por este motivo, en muchos casos se denomina a esta maniobra copyleft (juego depalabras en ingls que a veces se traduce como izquierdos de autor). Alguien, con una pizca de humor, lleg incluso a lanzar eleslogan copyleft, all rights reversed.

En lneas bsicas, la licencia GPL permite la redistribucin binaria y la del cdigo fuente, aunque en el caso de que redistribuyade manera binaria obliga a que tambin se pueda acceder a las fuentes. Asimismo, est permitido realizar modificaciones sinrestricciones. Sin embargo, slo se puede redistribuir cdigo licenciado bajo GPL de forma integrada con otro cdigo (porejemplo, mediante enlazado o linkado) si ste tiene una licencia compatible. Esto ha sido llamado efecto viral (aunque muchosconsideran esta denominacin como despectiva) de la GPL, ya que cdigo publicado una vez con esas condiciones nunca puedecambiar de condiciones.

NotaUna licencia es incompatible con la GPL cuando restringe alguno de los derechos que la GPL garantiza, ya sea explcitamentecontradiciendo alguna clusula, ya implcitamente, imponiendo alguna nueva. Por ejemplo, la licencia BSD actual es compati-ble, pero la de Apache, que exige que se mencione explcitamente en los materiales de propaganda que el trabajo combinadocontiene cdigo de todos y cada uno de los titulares de derechos, es incompatible. Esto no implica que no se puedan usarsimultneamente programas con ambas licencias, o incluso integrarlos. Slo supone que esos programas integrados no sepueden distribuir, pues es imposible cumplir simultneamente las condiciones de redistribucin de ambas.

La licencia GPL est pensada para asegurar la libertad del cdigo en todo momento, ya que un programa publicado y licenciadobajo sus condiciones nunca podr ser hecho privativo. Es ms, ni ese programa ni modificaciones al mismo pueden ser publicadascon una licencia diferente a la propia GPL. Como ya se ha dicho, los partidarios de las licencias tipo BSD ven en esta clusula unrecorte de la libertad, mientras que sus seguidores ven en ello una forma de asegurarse que ese software siempre va a ser libre.Por otro lado, se puede considerar que la licencia GPL maximiza las libertades de los usuarios, mientras que las tipo BSD lohacen para los desarrolladores. Ntese, sin embargo, que en el segundo caso estamos hablando de los desarrolladores en generaly no de los autores, ya que muchos autores consideran que la licencia GPL es ms beneficiosa para sus intereses, ya que obliga asus competidores a publicar sus modificaciones (mejoras, correcciones, etc.) en caso de que redistribuyan su software, mientrasque con una licencia tipo BSD ste no tiene por qu ser el caso.

En cuanto a la naturaleza contraria al copyright, esto se debe a que la filosofa que hay detrs de esta licencia (y detrs de la FreeSoftware Foundation) es que el software no debe tener propietarios [207]. Aunque es cierto que el software licenciado con la GPLtiene un autor, que es el que a fin de cuentas permite la aplicacin de la legislacin de copyright sobre su obra, las condicionesbajo las que publica su obra confieren a la misma tal carcter que podemos considerar que la propiedad del software correspondea quien lo tiene y no a quien lo ha creado.

Por supuesto, tambin incluye negaciones de garanta para proteger a los autores. Asimismo, y para proteger la buena fama delos autores originales, toda modificacin de un fichero fuente debe incluir una nota con la fecha y autor de cada modificacin.

La GPL contempla tambin a las patentes de software, exigiendo que si el cdigo lleva algoritmos patentados (como dijimos,algo legal y usual en Estados Unidos y prctica irregular en Europa), o se concede licencia de uso de la patente libre de tasas, ono se puede distribuir bajo la GPL.

La ltima versin de la licencia GPL, la segunda, se public en 1991 (aunque en el momento de escribir este texto est enavanzado proceso de preparacin la tercera). Precisamente para contemplar futuras versiones, la licencia recomienda licenciarbajo las condiciones de la segunda o de cualquier otra posterior publicada por la Free Software Foundation, cosa que hacen

lromanieu


44 / 200

muchos autores. Sin embargo otros, entre los que destaca Linus Torvalds (creador de Linux) publican su software slo bajo lascondiciones de la segunda versin de la GPL, buscando desmarcarse de las posibles evoluciones futuras de la Free SoftwareFoundation.

La versin tercera de la GPL [115] pretende actualizarla al escenario actual del software, principalmente en aspectos como pa-tentes, sistemas DRM (Digital Rights Management, gestin de derechos digitales) y otras limitaciones de la libertad del software.Por ejemplo, en el borrador disponible en el momento de escribir este texto (mayo de 2007), no permite que un fabricante dehardware bloquee la utilizacin de ciertos mdulos software si no presentan una firma digital que acredite una determinada au-tora. Un ejemplo de estas prcticas se da en los grabadores digitales de vdeo TiVo, que proporciona el cdigo fuente de todosu software (licenciado con GPLv2) al tiempo que no permiten que se utilicen modificaciones del cdigo en dicho hardware2.La licencia tampoco permite que el software obligue a la ejecucin en entorno prefijado, como ocurre cuando se prohibe lautilizacin de ncleos no firmados en distribuciones cuya poltica de seguridad as lo considere oportuno.

NotaHay varios puntos en la licencia GPLv3 que han despertado una cierta oposicin. Uno de los grupos de opositores estcompuesto por desarrolladores del ncleo Linux (entre ellos el propio Linus Torvalds). Consideran que el requisito de utilizacinde componentes software firmados permite otorgar ciertas caractersticas de seguridad imposibles de otra manera, al tiempoque su prohibicin explcita extendera la licencia al terreno del hardware. Adems, la limitacin establecida por el mecanismode firmas se dara nicamente en las plataformas hardware y software as diseadas, pudiendo modificarse el software parasu utilizacin en otro hardware. Con respecto de este punto, la FSF est a favor del empleo de mecanismos de firmas querecomienden la no utilizacin de componentes no firmados por motivos de seguridad, pero cree que la no prohibicin deaquellos mecanismos de firmas que imposibilitan la utilizacin de componentes no firmados podran dar lugar a escenarios enque no existiesen plataformas hardware o software en las que ejecutar dichas modificaciones del software, quedando en esecaso totalmente limitadas las libertades del software libre en lo que a modificacin del cdigo se refiere.

3.2.3.2. La Licencia Pblica General Menor de GNU (GNU LGPL)

La Licencia Pblica General Menor del proyecto GNU[119] (comnmente conocida por sus iniciales en ingls LGPL) es laotra licencia de la Free Software Foundation. Pensada en sus inicios para su uso en bibliotecas (la L en sus comienzos vena delibrary: biblioteca), fue modificada recientemente para ser considerada la hermana menor (lesser: menor) de la GPL.

La LGPL permite el uso de programas libres con software propietario. El programa en s se redistribuye como si estuviera bajola licencia GPL, pero se permite la integracin con cualquier otro software sin prcticamente limitaciones.

Como se puede ver, en un principio, esta licencia estaba orientada a las bibliotecas, de manera que se pudiera potenciar su usoy desarrollo sin tener los problemas de integracin que implica la GPL. Sin embargo, cuando se vio que el efecto buscado depopularizar las bibliotecas libres no se vea compensado por la generacin de programas libres, la Free Software Foundationdecidi el cambio de Library a Lesser y desaconsej su uso, salvo para condiciones muy puntuales y especiales. Hoy en da,existen muchos programas que no son bibliotecas licenciados bajo las condiciones de la LGPL. Por ejemplo, el navegadorMozilla o la suite de ofimtica OpenOffice.org estn licenciadas, entre otras, tambin bajo la LGPL.

NotaIgual que la GPL, la ltima versin publicada de la LGPL es la segunda, aunque ya hay borrador de la versin 3 [116]. Estanueva versin es ms corta que la anterior, dado que refiere todo su texto a GPLv3, destacando nicamente sus diferencias.

3.2.3.3. Otras licencias robustas

Otras licencias robustas que puede resultar interesante comentar son:

Licencia de Sleepycat [59]

Es la licencia bajo la que la empresa Sleepycat [60] distribuye sus programas (entre ellos el conocido Berkeley DB). Obliga aciertas condiciones siempre que se redistribuye el programa o trabajos derivados del programa. En particular, obliga a ofrecer2Este caso ha llegado incluso a sugerir la denominacin Tivoisation para varios otros similares que han surgido.

lromanieu


45 / 200

el cdigo fuente (incluidas las modificaciones, si se trata de un trabajo derivado), y a que la redistribucin imponga al receptorlas mismas condiciones. Aunque mucho ms corta que la GNU GPL, es muy similar a ella en sus efectos principales.

eCos License 2.0 [25]

Es la licencia bajo la que se distribuye eCos [24], un sistema operativo de tiempo real. Es una modificacin de la GNU GPLque no considera que el cdigo que se enlace con programas protegidos por ella queden sujetos a las clusulas de la GNU GPLsi se redistribuyen. Desde este punto de vista, sus efectos son similares a los de la GNU LGPL.

Affero General Public License [78]

Interesante modificacin de la GNU GPL que considera el caso de los programas que ofrecen servicios va web, o en general,va redes de ordenadores. Este tipo de programas plantean un problema desde el punto de vista de las licencias robustas.Como el uso del programa no implica haberlo recibido mediante una redistribucin, aunque el programa est licenciado, porejemplo, bajo la GNU GPL, alguien puede modificarlo y ofrecer un servicio en la red usndolo, sin redistribuirlo de ningunaforma, y por tanto sin estar obligado, por ejemplo, a distribuir el cdigo fuente. La Affero GPL tiene una clusula que obligaque, si el programa tiene un medio para proporcionar su cdigo fuente va web a quien lo use, no se pueda desactivar esacaracterstica. Esto significa que si el autor original incluye esa capacidad en el fuente, cualquier usuario puede obtenerlo,y adems esa redistribucin est sometida a las condiciones de la licencia. La Free Software Foundation est considerandoincluir provisiones similares en la versin 3 de su GNU GPL.

IBM Public License Version 1.0 [40]

Es una licencia que permite la redistribucin binaria de trabajos derivados slo si (entre otras condiciones) se preve algnmecanismo para que quien reciba el programa pueda recibir su cdigo fuente. La redistribucin del cdigo fuente se ha dehacer bajo la misma licencia. Adems, esta licencia es interesante por obligar al que redistribuye el programa con modifica-ciones a licenciar automtica y gratuitamente las patentes que puedan afectar a esas modificaciones, y que sean propiedad delredistribuidor, a quien reciba el programa.

Mozilla Public License 1.1 [49]

Ejemplo de licencia libre con origen en una empresa. Es una evolucin de la primera licencia libre que tuvo el NetscapeNavigator, y en su momento fue muy importante por ser la primera vez que una empresa muy conocida decidi distribuir unprograma bajo su propia licencia libre.

3.2.4. Distribucin bajo varias licencias

Hasta este punto se ha dado por supuesto que cada programa se distribuye bajo una nica licencia en la que se especificabanlas condiciones de uso y redistribucin. Sin embargo, un autor puede distribuir obras con distintas licencias. Para entenderlo,debemos tener en cuenta que cada publicacin es una nueva obra y que se puede dar el caso de que se distribuyan versiones queslo se difieren en la licencia. Como veremos, en la mayora de los casos, esto se traduce en que dependiendo de lo que el usuarioquiera hacer con el software, se encontrar con que tiene obedecer una licencia u otra.

Uno de los ejemplos ms conocidos de doble licencia es el de la biblioteca Qt, sobre la que se cimenta el entorno de escritorioKDE. Trolltech, una empresa afincada en Noruega distribua Qt con una licencia propietaria, aunque exima del pago a losprogramas que hicieran uso de la misma sin nimo de lucro. Por esta causa y por sus caractersticas tcnicas fue elegida amediados de la dcada de los noventa por el proyecto KDE, Esto supuso una ardua polmica con la Free Software Foundation,ya que KDE dejaba de ser entonces software libre en su conjunto, al depender de una biblioteca propietaria. Tras un largo debate(durante el cual apareci GNOME como competidor libre de KDE en el escritorio) Trolltech decidi utilizar el sistema de doblelicencia para su producto estrella: los programas bajo GPL podan hacer uso de una versin de Qt GPL, mientras que si sequera integrar con programas con licencias incompatibles con la GPL (por ejemplo, licencias privativas), deban comprarles unalicencia especial. Esta solucin satisfizo a todas las partes, y hoy da KDE es considerado software libre.

Otros ejemplos conocidos de licencia dual son StarOffice y OpenOffice.org, o Netscape Communicator y Mozilla. En amboscasos el primer producto es propietario, mientras que el segundo es una versin libre (generalmente bajo las condiciones devarias licencias libres). Aunque en un principio, los proyectos libres eran versiones limitadas de sus hermanos propietarios, conel tiempo han ido tomando su propio camino, por lo que a da de hoy tienen un grado de independencia bastante grande.

lromanieu


46 / 200

3.2.5. Documentacin de programas

La documentacin que viene con un programa es parte integrante del mismo, igual que los comentarios del cdigo fuente, comoreconoce, por ejemplo en Espaa, la Ley de Propiedad Intelectual. Dado este nivel de integracin, parece lgico que se le apliquenlas mismas libertades y evolucione de la misma manera que el programa: toda modificacin que se haga de un programa requiereun cambio simultneo y consistente en su documentacin.

La mayor parte de esta documentacin suele estar codificada como ficheros de texto sin formato, ya que se pretende que seauniversalmente accesible con un entorno de herramientas mnimo, y (en el caso de los programas libres) suele incluir una pequeaintroduccin al programa (README o LEEME), instrucciones de instalacin (INSTALL), alguna historia sobre la evolucinpasada y futura del programa (changelog y TODO), autora y condiciones de copia (AUTHORS y copyright o COPYING),as como las instrucciones de uso. Todas ellas, menos la autora y las condiciones de copia, deberan ser libremente modificablessegn el programa evoluciona. A la autora slo se le deberan aadir nombres y crditos, pero sin borrar nada, y las condicionesde copia slo deberan modificarse si estas mismas lo permiten.

Las instrucciones de uso suelen estar codificadas en formatos ms complejos, ya que suelen ser documentos ms largos y ricos. Elsoftware libre exige que esta documentacin pueda ser modificada fcilmente, lo que a su vez obliga a usar formatos denominadostransparentes, de especificacin conocida y procesables por herramientas libres, como son, adems del texto puro y limpio, elformato de pginas de manual de Unix, TexInfo, LaTeX o DocBook, sin perjuicio de distribuir tambin el resultado de transformaresos documentos fuente en formatos ms aptos para visualizar o imprimir, como HTML, PDF o RTF (formatos en general msopacos).

Sin embargo muchas veces se hace documentacin sobre programas por parte de terceros que no han intervenido en el desarrollo.A veces es documentacin de carcter didctico que facilita la instalacin y uso de un programa concreto (HOWTOs, COMOso recetarios), a veces es documentacin ms amplia, abarcando varios programas y su integracin, comparando soluciones,etc., ya sea en forma de tutorial o de referencia. A veces es una mera recopilacin de preguntas frecuentes con sus respuestas(FAQs o PUFs). Ejemplo notable es el Proyecto de Documentacin Linux [44]. En esta categora podemos tambin incluir otrosdocumentos tcnicos, no necesariamente sobre programas, ya sean las instrucciones para cablear una red local, construir unacocina solar, reparar un motor o seleccionar un proveedor de tornillos.

Estos documentos son algo intermedio entre la mera documentacin de programas y los artculos o libros muy tcnicos y prc-ticos. Sin menoscabo de la libertad de lectura, copia, modificacin y redistribucin, el autor puede querer verter opiniones queno desea que se tergiversen, o al menos que esas tergiversaciones no se le atribuyan. O puede querer que se conserven prrafos,como agradecimientos. O que necesariamente se modifiquen otros, como el ttulo. Aunque estas inquietudes pueden tambinmanifestarse con los programas en s mismos, no se han manifestado con tanta fuerza en el mundo del software libre como en elde la documentacin libre.

3.3. Resumen

En este captulo se han revisado los aspectos legales que rigen o tienen impacto sobre el software libre. stos forman parte bien delderecho de propiedad intelectual industrial, concebidos en principio para estimular la creatividad recompensando a los creadorespor un tiempo determinado. De todos ellos, el llamado copyright es el que ms afecta al software libre, y que convenientementeempleado sirve para asegurar su existencia, en forma de licencias libres.

Hemos podido ver la importancia que tienen las licencias dentro del mundo del software libre. Asimismo, hemos presentado lagran variedad de licencias existentes, su motivacin, sus repercusiones y sus ventajas e inconvenientes. En definitiva, podemosdecir que la GPL trata de maximizar las libertades que tiene el usuario del software, lo reciba directamente de su autor o no,mientras que las licencias tipo BSD lo que hacen es maximizar las libertades del modificador o redistribuidor.

A la vista de lo que se ha comentado en este captulo, se deduce que es muy importante decidir pronto qu licencia va a tener unproyecto y conocer detalladamente sus ventajas e inconvenientes, ya que una modificacin posterior suele ser muy difcil, sobretodo si el nmero de contribuciones externas es muy grande.

Para finalizar, queremos hacer hincapi en el hecho de que el software libre y el software propietario se diferencien de maneraestricta nica y exclusivamente en la licencia con la que se publican los programas. En prximos captulos veremos, sin embargo,que esta puntualizacin meramente legal puede tener consecuencias -o puede que no- en la manera en la que se desarrolla elsoftware, dando lugar a un nuevo modelo de desarrollo que se diferencie en mayor o menor medida, segn el caso, de losmtodos de desarrollos tradicionales utilizados en la industria del software.

lromanieu


53 / 200

Captulo 5

Economa

Res publica non dominetur.

Las cosas pblicas no tienen dueo (traduccin libre).

Aparecido en un anuncio de IBM sobre Linux, 2003

En este captulo se tratan algunos aspectos econmicos relacionados con el software libre. Se comienza mostrando cmo sefinancian los proyectos de software libre (cuando efectivamente se financian, ya que en muchos casos se desarrollan nicamentecon trabajo y recursos aportados voluntariamente). A continuacin se exponen los principales modelos de negocio que estnponiendo en prctica las empresas relacionadas directamente con el software libre. El captulo termina con un pequeo estudiosobre la relacin entre el software libre y los monopolios en la industria del software.

5.1. Financiacin de proyectos de software libre

El software libre se desarrolla de muchas formas distintas, y con mecanismos para conseguir recursos que varan muchsimode un caso a otro. Cada proyecto libre tiene su propia forma de financiarse, desde el que est formado completamente pordesarrolladores voluntarios y utiliza solamente recursos cedidos altruistamente, hasta el que es llevado a cabo por una empresaque factura el 100% de sus costes a una entidad interesada en el desarrollo correspondiente.

En esta seccin nos vamos a centrar en los proyectos donde hay financiacin externa, y no todo el trabajo realizado es voluntario.En estos casos, hay algn tipo de flujo de capital con origen externo al proyecto que se encarga de aportar recursos para su desa-rrollo. De esta manera, el software libre construido puede considerarse, de alguna forma, como un producto de esta financiacinexterna. Por ello es comn que sea esa fuente externa quien decide (al menos parcialmente) cmo y en qu se gastan los recursos.

En cierto sentido, esta financiacin externa para proyectos libres puede considerarse como un tipo de patrocinio, aunque estepatrocino no tiene por qu ser desinteresado (y habitualmente no lo es). En los siguientes apartados se comentan los tipos definanciacin externa ms habituales. Mientras el lector se dedique a ellos, conviene, no obstante, no olvidar que esta es slo unade formas como los proyectos que construyen software libre consiguen recursos. Hay otras, y entre ellas, la ms importante: eltrabajo de muchos desarrolladores voluntarios (como se discute en el captulo 4)

5.1.1. Financiacin pblica

Un tipo muy especial de financiacin de proyectos libres es la pblica. La entidad financiadora puede ser directamente ungobierno (local, regional, nacional o incluso supranacional) o una institucin pblica (por ejemplo, una fundacin). En estoscasos, la financiacin suele ser similar a la de los proyectos de investigacin y desarrollo, y de hecho es muy habitual queprovenga de entidades pblicas promotoras de I+D. Normalmente, la entidad financiadora no busca recuperar la inversin (oal menos no de forma directa), aunque suele tener objetivos claros (favorecer la creacin de tejido industrial e investigador,promover cierta tecnologa o cierto tipo de aplicaciones, etc.).

En la mayor parte de estos casos, no se encuentra explcitamente la financiacin de productos o servicios relacionados consoftware libre, sino que suelen ser el subproducto de un contrato con otros fines ms generales. Por ejemplo, la Comisin

lromanieu


54 / 200

Europea, dentro de sus programas de investigacin, financia proyectos orientados a mejorar la competitividad europea en ciertasreas. Algunos de estos proyectos tienen como parte de sus objetivos usar, mejorar y crear software libre en su mbito deinvestigacin (como herramienta para la investigacin, o como producto derivado de ella).

Las motivaciones para este tipo de financiacin son muy variadas, pero pueden destacarse las siguientes

Cientfica. Este es el caso ms habitual en proyectos de investigacin financiados con fondos pblicos. Aunque su objetivono es producir software, sino investigar en un determinado campo (relacionado o no con la informtica), es muy posible quepara ello sea preciso desarrollar programas que se usen como herramientas necesarias para alcanzar las metas del proyecto.Normalmente el proyecto no est interesado en comercializar estas herramientas, o incluso est activamente interesado en queotros grupos las utilicen y mejoren. En estos casos, es bastante habitual distribuirlos como software libre. En este caso, losrecursos que consigui el grupo que realiza la investigacin se dedicaron en parte a la produccin de este software, por lo quese puede decir que fue desarrollado con financiacin pblica.

Promocin de estndares. Tener una implementacin de referencia es una de las mejores formas de promover un estndar. Enmuchos casos eso supone tener programas que formen parte de esa implementacin (o si el estndar se refiere al campo delsoftware, que sean la implementacin ellos mismos). Para que la implementacin de referencia sea de utilidad en la promocindel estndar, es preciso que est disponible, al menos para comprobar interoperabilidad, para todos los que quieran desarrollarproductos que se acojan a ese estndar. Y en muchos casos, es conveniente tambin que los fabricantes puedan directamenteadaptar la implementacin de referencia para usarla en sus productos, si as lo desean. De esta manera se desarrollaron, porejemplo, muchos de los protocolos de Internet que hoy se han convertido en norma universal. En estos casos, la liberacin deesas implementaciones de referencia como software libre puede ayudar mucho en esa promocin. De nuevo, en estos casosel software libre es un subproducto, en este caso de la promocin del estndar. Y habitualmente, quien se encarga de estapromocin es una entidad pblica (aunque a veces es un consorcio privado).

Social. El software libre es una herramienta de gran inters en al creacin de la infraestructura bsica para la sociedad dela informacin. Las entidades interesadas en utilizar software libre para ayudar al acceso universal a esta sociedad de lainformacin pueden financiar proyectos relacionados con el software libre (normalmente proyectos de desarrollo de nuevasaplicaciones o de adaptacin de otras existentes.

NotaUn ejemplo de financiacin pblica con finalidad fundamentalmente social es el caso de LinEx, promovido por la Junta deExtremadura (Extremadura, Espaa) para promover la sociedad de la informacin fundamentalmente en lo que a alfabeti-zacin informtica se refiere. La Junta ha financiado el desarrollo de una distribucin basada en Debian para conseguir estefin. Otro caso similar es el de la financiacin por parte del gobierno alemn de desarrollos de GnuPG orientados a facilitarsu uso para los usuarios no experimentados, con la idea de favorecer el uso del correo seguro entre sus ciudadanos.

El desarrollo de GNATUn caso notorio de financiacin pblica para el desarrollo de software libre fue el del compilador GNAT. GNAT, compilador deAda, fue financiado por el proyecto Ada9X del Departamento de Defensa de EE.UU., con la idea de disponer de un compiladorde la nueva versin del lenguaje de programacin Ada (la que luego fue Ada95), cuyo uso trataba de promover en aquellapoca. Uno de las causas que se haban identificado en cuanto a la adopcin de la primera versin de Ada (Ada83) porlas empresas de software era la tarda disposicin de un compilador del lenguaje, y su alto precio cuando estuvo finalmentedisponible. Por ello, trataron de que no ocurriese lo mismo con Ada95, asegurndose de que hubiera un compilador de formaprcticamente simultnea con la publicacin del nuevo estndar del lenguaje.Para lograrlo, el proyecto Ada9X contrat un proyecto con un equipo de la Universidad de Nueva York (NYU), por un importeaproximado de 1 milln de USD, para la realizacin de una prueba de concepto de compilador de Ada95. Con esos fondos,y aprovechando de la existencia de GCC (el compilador de C de GNU, del que se aprovech la mayor parte del dorsal), elequipo de NYU construy efectivamente el primer compilador de Ada95, que liber bajo la GNU GPL. El compilador tuvo tantoxito que a la terminacin del proyecto parte de sus constructores fundaron una empresa (Ada Core Tecnologies) que desdeentonces se ha convertido en lder en el mercado de compiladores y herramientas de ayuda a la construccin de programasen Ada.Es notable cmo se puede ver en este proyecto la combinacin de elementos de investigacin (este proyecto avanz en elconocimiento sobre la construccin de frontales y de sistemas de tiempo de ejecucin para compiladores de lenguajes tipoAda) y de promocin de estndares (que era el objetivo ms claro de su financiador).

lromanieu


55 / 200

5.1.2. Financiacin privada sin nimo de lucro

Este es un tipo de financiacin con muchas caractersticas similares a las del caso anterior, donde la financiacin la realizan nor-malmente fundaciones u organizaciones no gubernamentales. La motivacin directa en estos casos suele ser producir softwarelibre para su uso en algn mbito que la entidad financiadora considera especialmente relevante, pero tambin puede encontrarsela motivacin indirecta de contribuir a resolver un problema (por ejemplo, una fundacin dedicada a promover la investigacinsobre una enfermedad puede financiar la construccin de un programa estadstico que ayude al anlisis de grupos de experimen-tacin donde se est estudiando esa enfermedad).

En general, tanto los motivos para realizar esta financiacin como sus mecanismos son muy similares a los de financiacinpblica, aunque naturalmente estn siempre marcados por los objetivos de la entidad que financia.

NotaProbablemente el caso paradigmtico de fundacin que promueve el desarrollo de software libre sea la Free Software Foun-dation (FSF). Desde mediados de la dcada de 1980 esta fundacin se dedica a la promocin del proyecto GNU, y a fomentaren general el desarrollo del software libre.Otro caso interesante, aunque en otro mbito bastante diferente, es la Open Bioinformatics Foundation. Entre los fines de estafundacin se encuentra la de promover el desarrollo de los programas informticos que son bsicos para investigacin encualquiera de las ramas de la bioinformtica. Y en general, realiza esta promocin financiando y ayudando a la construccinde programas libres.

5.1.3. Financiacin por quien necesita mejoras

Otro tipo de financiacin para el desarrollo de software libre, ya no tan altruista, es el que tiene lugar cuando alguien necesitamejoras en un producto libre. Por ejemplo, una empresa, para uso interno, necesita de cierta funcionalidad en un programa dado.O bien necesita que ciertos errores en un programa sean corregidos. En este tipo de casos, lo habitual es que la empresa encuestin contrate el desarrollo que necesita. Este desarrollo, muy habitualmente (bien porque lo impone la licencia del programamodificado, bien porque la empresa lo decide as) es software libre.

El caso de Corel y WineA finales de la dcada de 1990, Corel decidi portar sus productos a GNU/Linux. En el proceso de realizarlo, descubri queun programa libre diseado para facilitar la ejecucin de binarios para Windows en entornos Linux podra permitirle muchosahorros de desarrollo. Pero para ello era preciso mejorarlo, fundamentalmente aadindole la emulacin de cierta funcionalidadde Windows que usaban los programas de Corel.Para que se realizaran estas mejoras, Corel contrat a Macadamian, que contribuy con sus mejoras al proyecto Wine. Conello, tanto Corel como Wine salieron beneficiados.

5.1.4. Financiacin con beneficios relacionados

En este caso, lo que busca la entidad financiadora es conseguir beneficios en productos relacionados con el programa a cuyodesarrollo aporta recursos. Normalmente, en estos casos los beneficios que obtiene la empresa financiadora no son exclusivos, yaque otras pueden entrar tambin en el mercado de la venta de productos relacionados. Pero bien la cuota de mercado que tiene essuficiente como para que no le preocupe mucho repartir la tarta con otros, o bien tiene alguna ventaja competitiva clara.

Algunos ejemplos de productos relacionados con un software dado son:

Libros. La empresa en cuestin vende manuales, guas de uso, textos para cursos, etc. relacionados con el programa libre queayuda a financiar. Por supuesto otras empresas pueden vender tambin libros relacionados, pero normalmente el financiar elproyecto le dar acceso antes que a sus competidores a desarrolladores clave, o simplemente conseguir con ello una buenaimagen de cara a la comunidad de usuarios del programa en cuestin.

Hardware. Si una empresa financia el desarrollo de sistemas libres para cierto tipo de hardware puede dedicarse a vender conms facilidad ese tipo de hardware. De nuevo, al ser libre el software desarrollado, pueden aparecer competidores que vendan

lromanieu


56 / 200

aparatos del mismo tipo, usando esos desarrollos, pero sin colaborar a su financiacin. Pero incluso as, la empresa en cuestintiene varias ventajas sobre sus competidores, y una de ellas puede ser que su posicin como aportadora de recursos para elproyecto le permita influir para conseguir que los desarrollos que se realicen con ms prioridad sean los que ms le interesen.

CDs con programas. Probablemente el modelo de este tipo ms conocido es el de las empresas que financian ciertos desarrollosque luego aplican a su distribucin de software. Por ejemplo, tener un buen entorno de escritorio puede ayudar mucho a venderCDs con una cierta distribucin de GNU/Linux, y por tanto, financiar su desarrollo puede ser un buen negocio para quien losvende.

Es importante darse cuenta de que, para estar en este apartado, la financiacin en cuestin ha de hacerse con nimo de lucro, ypara ello la entidad financiadora ha de percibir algn beneficio posible en esta financiacin. En los casos reales, sin embargo,es habitual que haya siempre una combinacin de nimo de lucro y altruismo cuando una empresa aporta recursos para que serealice un programa libre del cual espera beneficiarse indirectamente.

NotaUn caso muy conocido de aporte de recursos a un proyecto, si bien de forma relativamente indirecta, es la ayuda que la editorialOReilly presta al desarrollo de Perl. Naturalmente, no es casualidad que esa editorial sea tambin una de las principaleseditoras sobre temas relacionados con Perl. En cualquier caso, es obvio que OReilly no tiene la exclusiva de la edicin delibros de ese tipo, y otras editoriales compiten en ese segmento de mercado, con diverso xito.VA Software (en sus comienzos VA Research, y ms tarde VA Linux) ha colaborado activamente en el desarrollo del ncleo deLinux. Con ello ha conseguido, entre otras cosas, colaborar a asegurar su continuidad, lo que era especialmente crtico paraella, de cara a sus clientes, cuando su principal negocio era vender equipos con GNU/Linux preinstalado.Red Hat ha financiado el desarrollo de muchos componentes de GNOME, con lo que ha conseguido fundamentalmentetener un entorno de escritorio para su distribucin, lo que ha contribuido a aumentar sus ventas. Como en otros casos, otrosfabricantes de distribuciones se han beneficiado de este desarrollo, aunque muchos de ellos no hayan colaborado con elproyecto GNOME en la misma medida que Red Hat (y no son pocos los que no han colaborado en nada). A pesar de ello, RedHat se beneficia de su contribucin a GNOME.

5.1.5. Financiacin como inversin interna

Hay empresas que, directamente como parte de su modelo de negocio, desarrollan software libre. Por ejemplo, una empresapuede decidir iniciar un nuevo proyecto libre en un mbito donde percibe que puede haber oportunidades de negocio, con la ideade rentabilizar posteriormente esta inversin. Este modelo podra considerarse una variante del anterior (financiacin indirecta),siendo los beneficios relacionados las ventajas que obtenga la empresa de la produccin del programa libre. Pero por ser eneste caso el producto libre en s mismo el que se espera que produzca los beneficios, parece conveniente abrir una clasificacinespecfica para estos casos.

Este tipo de financiacin da lugar a varios modelos de negocio. Cuando se analicen stos (seccin 5.2) se explicarn tambin lasventajas que normalmente obtiene una empresa de esta inversin en un proyecto, y qu mtodos suelen utilizarse para rentabili-zarla. Pero en cualquier caso, hay que destacar que en algunos casos, puede que el software en cuestin se desarrolle simplementepara satisfacer las necesidades de la propia empresa, y que slo despus se decida liberar, y quizs abrir una lnea de negociorelacionada con l.

lromanieu


57 / 200

NotaDigital Creations (hoy Zope Corporation) es uno de los casos ms conocidos de empresa que se dedica al desarrollo de sof-tware libre con la esperanza de rentabilizar su inversin. El proyecto libre en que ms est invirtiendo es Zope, un servidor deaplicaciones que est teniendo un cierto xito. Su historia con el software libre comenz cuando la entonces Digital Creationsbuscaba capital-riesgo para desarrollar su servidor de aplicaciones propietario, hacia 1998. Uno de los grupos interesadosen invertir en ellos (Opticality Ventures) les puso como condicin que el producto resultante deba ser libre, porque en casocontrario no vean cmo iba a poder conseguir una cuota de mercado significativa. Digital Creations se decidi por ese camino,y pocos meses despus anunciaba la primera versin de Zope (unos aos despus cambi su nombre). Hoy da Zope Cor-poration est especializada en ofrecer servicios de consultora, formacin y soporte para sistemas de gestin de contenidosbasados en Zope, y otros productos en los que sin duda Zope es la piedra angular.Ximian (antes Helix Code) es un caso bien conocido de desarrollo de aplicaciones libres en entorno empresarial. Muy ligadadesde sus orgenes al proyecto GNOME, Ximian ha producido sistemas software como Evolution (un gestor de informacinpersonal que tiene una funcionalidad relativamente similar a la ofrecida por MS Outlook), Red Carpet (un sistema fcil de usarpara la gestin de paquetera en un sistema operativo) y Mono (una implementacin de gran parte de .NET). La empresafue fundada en octubre de 1999, y atrajo a muchos desarrolladores de GNOME que pasaron a formar parte de sus desarro-lladores (en muchos casos, continuando su colaboracin con el proyecto GNOME). Ximian se posicion como una empresade ingeniera experta en adaptaciones de GNOME, en la construccin de aplicaciones basadas en GNOME, y en general enproporcionar servicios de desarrollo basados en software libre, especialmente de herramientas relacionadas con el entorno deescritorio. En agosto de 2003, Ximian fue adquirida por Novell.Cisco Enterprise Print System (CEPS) [17] es un sistema de gestin de impresin para organizaciones con gran cantidad deimpresoras. Fue desarrollado internamente en Cisco, para satisfacer sus propias necesidades, y liberado en el ao 2000 bajola GNU GPL. Es difcil estar seguro de los motivos que tuvo Cisco para hacer esto, pero es posible que tuviera que ver con labsqueda de contribuciones externas (informes de error, nuevos controladores, parches, etc.). En cualquier caso lo que estclaro es que, al no tener Cisco ningn plan para comercializar el producto, y no estar muy claro su mercado potencial, no tenamucho que perder con esta decisin.

5.1.6. Otros modos de financiacin

Hay otros modos de financiacin difciles de clasificar entre los anteriores. Entre ellos pueden destacarse, a modo de ejemplo,los siguientes:

Utilizacin de mercados para poner en contacto a desarrolladores y clientes. La idea que sostiene este modo de financiacin esque, sobre todo para pequeos desarrollos, es difcil que un cliente que lo desea pueda entrar en contacto con un desarrolladorque pueda acometerlo de forma eficiente. Para mejorar esta situacin, se postulan los mercados de desarrollo de software libre,donde los desarrolladores publicaran sus habilidades y los clientes los desarrollos que precisan. Una un desarrollador y uncliente se ponen de acuerdo, tenemos una situacin similar a la ya descrita como financiacin por quien necesita las mejoras(seccin 5.1.3).

SourceXchangeSourceXchange fue un ejemplo de mercado para poner en contacto a desarrolladores con sus clientes potenciales. Paraofrecer un proyecto, un cliente escriba una RFP (Request for Proposal, o Peticin de Propuesta), especificando qu desa-rrollo se necesita y cuntos recursos se est dispuesto a proporcionar para ese desarrollo. Estas RFP se publicaban en elsitio. Cuando un desarrollador vea una que le interesaba, haca una oferta para ella. Cuando un desarrollador y cliente seponan de acuerdo en los trminos del desarrollo, comenzaba un proyecto. Normalmente cada proyecto estaba supervisadopor un peer reviewer, un revisor, que se encargaba de asegurarse de que el desarrollador cumpla las especificaciones, queefectivamente estas tenan sentido, que aconsejaba sobre cmo llevar adelante el proyecto, etc. SourceXchange (propie-dad de la empresa CollabNet) se encargaba de ofrecer el sitio, garantizar la competencia de los revisores, asegurarse delpago en caso de que los proyectos se completasen, y ofrecer herramientas para el seguimiento del proyecto (servicios quefacturaba al cliente). El primer proyecto mediado por SourceXchange se termin en marzo de 2000, pero poco ms de unao despus, en abril de 2001, el sitio cerr.

Venta de bonos para financiar un proyecto. Esta idea de financiacin es similar a la de los mercados de bonos a los que acudenlas empresas, pero orientado al desarrollo de software libre. Tiene unas cuantas variantes, pero una de las ms conocidas

lromanieu


58 / 200

funciona como sigue. Cuando un desarrollador (individual o empresa) tiene idea de un nuevo programa o una mejora a unoexistente, lo escribe en forma de especificacin, estima el coste que tendra su desarrollo, y emite bonos para su construccin.Estos bonos tienen un valor que se ejecuta slo si el proyecto se termina finalmente. Cuando el desarrollador ha vendidosuficientes bonos, comienza el desarrollo, que va financiando con prstamos basados en ellos. Cuando termina el desarrollo, yse certifica por alguna tercera parte independiente que efectivamente lo realizado cumple las especificaciones, el desarrolladorejecuta los bonos que haba vendido, paga sus deudas, y lo que le queda son los beneficios que obtiene por el desarrollo.

Quin estara interesado en adquirir los mencionados bonos? Obviamente, los usuarios que desearan que ese nuevo programa,o esa mejora a uno ya existente, se realizaran. De alguna manera, este sistema de bonos permitira que las partes interesadasfijaran (siquiera parcialmente) las prioridades de los desarrolladores mediante la compra de bonos. Esto permitira tambin queno hiciese falta que una sola entidad asumiese los costes de desarrollo, sino que podran repartirse entre muchas (incluyendoindividuos), que adems slo tendran que pagar si finalmente el proyecto termina con xito. Un mecanismo muy similar aeste se propone, con mucho ms detalle, en [191].

NotaEl sistema de bonos descrito est basado en el Street Performer Protocol (protocolo del artista callejero) [152] [153], unmecanismo basado en el comercio electrnico diseado para facilitar la financiacin privada de trabajos de creacin libres.Resumiendo, quien est interesado en que se realice un determinado trabajo prometera formalmente pagar una ciertacantidad si el trabajo se realiza y es publicado libremente. Sus intenciones son buscar una nueva manera de financiartrabajos relativamente pequeos que queden a disposicin de todo el mundo, pero puede extenderse de muchas formas(los bonos para la construccin de software libre son una de ellas). Puede verse un pequeo caso de puesta en prctica deun derivado de este protocolo (el Rational Street Performer Protocol, protocolo racional del artista callejero [137]) en http://thecircle.org.au/funding_results.html, donde se aplica a la consecucin de fondos para la financiacinde parte de The Circle, un proyecto de software libre.

Cooperativas de desarrolladores. En este caso, los desarrolladores de software libre, en lugar de trabajar individualmente o parauna empresa, se renen en algn tipo de asociacin (normalmente similar a una cooperativa). Por lo dems, su funcionamientoes similar al de una empresa, matizado quizs por su compromiso tico con el software libre, que puede ser parte de susestatutos (aunque tambin una empresa puede hacer esto). En este tipo de organizaciones pueden darse combinaciones variadasde trabajo voluntario con trabajo remunerado. Un ejemplo de este tipo de organizacin es Free Developers.

Sistema de donaciones. Consiste en habilitar un mecanismo de pago al autor de un determinado software en la pgina webque alberga el proyecto. De esta forma, los usuarios interesados en que dicho proyecto contine publicando nuevas versionespueden apoyarlo econmicamente, realizando donaciones voluntarias a modo de financiacin para el desarrollador.

5.2. Modelos de negocio basados en software libre

Adems de los mecanismos de financiacin de los proyectos, ya tratados, otro aspecto muy relacionada con la economa quemerece la pena tratar es el de los modelos de negocio. Ya al hablar de estos mecanismos de financiacin se han mencionado depasada algunos, ahora en este apartado los describiremos de forma algo ms metdica.

En general, puede decirse que son muchos los modelos de negocio que se estn explorando alrededor del software libre, algunosms clsicos y otros ms innovadores. Hay que tener en cuenta que entre los modelos ms habituales en la industria del softwareno es fcil usar los basados en la venta de licencias de uso de programas producidos, pues en el mundo del software libre ese esun mecanismo de financiacin muy difcil de explotar. Sin embargo, s se pueden utilizar los basados en el servicio a terceros,con la ventaja de que sin ser necesariamente el productor de un programa puede darse soporte completo sobre l.

lromanieu


59 / 200

Venta de software libre a tanto por copiaEn el mundo del software libre es difcil cobrar licencias de uso, pero no imposible. En general, no hay nada en las definicionesde software libre que impida que una empresa cree un producto y slo lo distribuya a quien pague una cierta cantidad. Porejemplo, un determinado productor podra decidir distribuir su producto con una licencia libre, pero slo a quien le pague 1.000euros por copia (de forma similar a como se hace en el mundo clsico del software propietario).Sin embargo, aunque esto es tericamente posible, en la prctica es bastante difcil que suceda. Porque una vez que elproductor ha vendido la primera copia, quien la recibe puede estar motivado a tratar de recuperar su inversin vendiendo mscopias a menor precio (algo que no puede prohibir la licencia del programa, si ste es libre). En el ejemplo anterior, podratratar de vender 10 copias a 100 euros cada una, con lo que el producto le saldra gratis (y adems dificultara mucho que elproductor original vendiese otra copia a 1.000 euros, si el producto pude obtenerse legalmente por la dcima parte). Es fcildeducir cmo este proceso continuara en cascada hasta la venta de copias a un precio cercano al coste marginal de copia,que con las tecnologas actuales es prcticamente cero.An as, y teniendo en cuenta que el mecanismo descrito har que normalmente el productor no pueda poner un precio(especialmente un precio alto) al simple hecho de la redistribucin del programa, hay modelos de negocio que implcitamentehacen justamente eso. Un ejemplo es el de las distribuciones de GNU/Linux, que se venden por un precio muy bajo comparadocon sus competidores propietarios, pero superior (y normalmente claramente superior) al coste de copia (incluso cuando sepueden bajar libremente de Internet). Por supuesto en estos casos entran a jugar otros factores, como la imagen de marca o lacomodidad para el consumidor. Pero no es este el nico caso. Por lo tanto, ms que indicar que con software libre no se puedevender a tanto por copia, hay que tener en cuenta que es ms difcil de hacer, y probablemente se obtendr menos beneficio,pero que puede haber modelos basados justamente en eso.

Dadas estas limitaciones (y estas ventajas) desde hace unos aos se estn probando variantes de los modelos de negocio habitualesen la industria del software, a la vez que se buscan otros ms innovadores que explotar las posibilidades que ofrece el softwarelibre. Sin duda en los prximos aos veremos an ms experimentacin en este campo, y tambin tendremos ms informacinsobre qu modelos pueden funcionar bien, y en qu circunstancias.

En este apartado vamos a ofrecer una panormica de los que ms habitualmente nos encontramos hoy da, agrupados con laintencin de mostrar al lector lo que tienen de comn y lo que les diferencia, centrndonos en los modelos basados en el desarrolloy los servicios alrededor de un producto de software libre. Los ingresos en este caso provienen directamente de estas actividadesde desarrollo y servicios para el producto, pero no necesariamente implican desarrollo de nuevos productos. Cuando s se hacedesarrollo, estos modelos tienen como subproducto la financiacin de productos de software libre, por lo que son modelosespecialmente interesantes, y su impacto puede ser grande sobre el mundo del software libre en general.

En cualquier caso, y aunque aqu se ofrece una clasificacin relativamente clara, no hay que olvidar que casi todas las empresasusan en realidad combinaciones de los modelos que describimos, entre ellos y con otros ms tradicionales.

5.2.1. Mejor conocimiento

La empresa que utiliza este modelo de negocio trata de rentabilizar su conocimiento de un producto (o conjunto de productos)libres. Sus ingresos provendrn de clientes a los que vender servicios relacionados con ese conocimiento: desarrollos basados enel producto, modificaciones, adaptaciones, instalaciones e integraciones con otros. La ventaja competitiva de la empresa estar engran medida ligada al mejor conocimiento del producto: por ello estar especialmente bien situada si es la productora, o participaactivamente en el proyecto lo produce.

Esta es una de las razones por la que las empresas que utilizan este modelo suelen participar activamente en los proyectosrelacionados con el software sobre el que tratan de vender servicios: es una forma muy eficiente de obtener conocimiento sobrel, y lo que es ms importante, de que ese conocimiento sea reconocido. Desde luego, explicarle a un cliente que entre losempleados hay varios desarrolladores del proyecto que produce el software que, por ejemplo, se quiere modificar, puede ser unabuena garanta.

lromanieu


60 / 200

Relacin con los proyectos de desarrolloPor lo tanto, este tipo de empresas tiene un gran inters en dar la imagen de que poseen un buen conocimiento de determi-nados productos libres. Una interesante consecuencia de esto es que su apoyo a proyectos de software libre (por ejemplo,participando activamente en ellos, o permitiendo a sus empleados que lo hagan durante su jornada laboral) no es por lo tantoalgo meramente filantrpico. Por el contrario, puede ser uno de los activos ms rentables de la empresa, ya que sus clientes lovalorarn muy positivamente como una muestra clara de que conocen el producto en cuestin. Adems, de esta forma podrnseguir muy de cerca el desarrollo, tratando de asegurarse, por ejemplo, de que mejoras demandadas por sus clientes pasan aformar parte de producto desarrollado por el proyecto.Analizndolo desde un punto de vista ms general, esta es una situacin donde ambas partes, la empresa y el proyectode desarrollo, ganan de la colaboracin. El proyecto gana por el desarrollo realizado por la empresa, o porque algunos desus desarrolladores pasan a estar remunerados (siquiera parcialmente) por su trabajo en el proyecto. La empresa gana enconocimiento del producto, en imagen hacia sus clientes, y en una cierta influencia sobre el proyecto.

Los servicios que proporcionan este tipo de empresas pueden ser muy amplios, pero normalmente consisten en desarrollos amedida, adaptaciones o integraciones de los productos en los que son expertas, o bien servicios de consultora donde aconsejan asus clientes cmo utilizar mejor el producto en cuestin (especialmente si es complejo, o si su correcto funcionamiento es crticopara el cliente en cuestin).

EjemplosEjemplos de empresas que hasta cierto punto utilizan este modelo de negocio son las siguientes:

LinuxCare [45]. Fundada en 1996, proporcionaba en sus orgenes servicios de consultora y soporte para GNU/Linux ysoftware libre en EE.UU., y su plantilla estaba compuesta fundamentalmente por expertos en GNU/Linux. Sin embargo, en1992 cambi sus objetivos, y desde entonces se ha especializado en proporcionar servicios casi exclusivamente a Linuxejecutando sobre mquinas virtuales z/VM en grandes ordenadores de IBM. Su modelo de negocio ha cambiado tambin amejor conocimiento con limitaciones, al ofrecer como parte fundamental de sus servicios una aplicacin no libre, Levanta.

Alcove [3]. Fundada en 1997 en Francia, proporciona fundamentalmente servicios de consultora, consultara estratgica,soporte y desarrollo para software libre. Desde su fundacin, Alcove ha mantenido en plantilla a desarrolladores de variosproyectos libres, y ha tratado de rentabilizarlo en trminos de imagen. Tambin ha tratado de ofrecer una imagen, en general,de empresa vinculada a la comunidad de software libre, por ejemplo, colaborando con asociaciones de usuarios y dandopublicidad a sus colaboraciones con proyectos libres (por ejemplo, desde Alcove-Labs [4]).

5.2.2. Mejor conocimiento con limitaciones

Estos modelos son similares a los expuestos en el apartado anterior, pero tratando de limitar la competencia a que puedenverse sometidos. Mientras que en los modelos puros basados en el mejor conocimiento cualquiera puede, en principio, entrar encompetencia, ya que el software utilizado es el mismo (y libre), en este caso se trata de evitar esa situacin poniendo barreras a esacompetencia. Estas barreras suelen consistir en patentes o licencias propietarias, que normalmente afectan a una parte pequea(pero fundamental) del producto desarrollado. Por eso estos modelos pueden considerarse en realidad como mixtos, en el sentidoque estn a caballo entre el software libre y el propietario.

En muchos casos, la comunidad del software libre desarrolla su propia versin para ese componente, con lo que la ventajacompetitiva puede desaparecer, o incluso volverse en contra de la empresa en cuestin si su competidor libre se convierte en elestndar del mercado y es demandado por sus propios clientes.

lromanieu


61 / 200

EjemplosSon muchos los casos donde se usa este modelo de negocio, ya que es comn considerarlo como menos arriesgado que elde conocimiento puro. Sin embargo, las empresas que lo han usado han tenido evoluciones variadas. Algunas de ellas son:

Caldera [16]. La historia de Caldera es complicada. En sus inicios, cre su propia distribucin de GNU/Linux, orientada a lasempresas: Caldera OpenLinux. En 2001, compr la divisin de Unix de SCO, y en 2002 cambi su nombre a SCO Group.Su estrategia empresarial ha dado tantos vuelcos como su nombre, desde su total apoyo a Linux hasta sus demandas contraIBM y Red Hat en 2003, y su abandono de su propia distribucin. Pero en lo que se refiere a este apartado, el negociode Caldera, al menos hasta 2002, es un claro exponente del mejor conocimiento con limitaciones. Caldera trataba deexplotar su conocimiento de la plataforma GNU/Linux, pero limitando la competencia a que poda verse sometida mediantela inclusin de software propietario en su distribucin. Esto haca difcil a sus clientes cambiar de distribucin una vez quela haban adoptado, pues aunque las dems distribuciones de GNU/Linux incluan la parte libre de Caldera OpenLinux, noencontraban en ellas la parte propietaria.

Ximian [74]. Fundada en 1999 con el nombre de Helix Code por desarrolladores muy vinculados al proyecto GNOME, fueadquirida en agosto de 2003 por Novell. La mayor parte del software que ha desarrollado ha sido libre (en general, partede GNOME). Sin embargo, en un mbito muy concreto Ximian decidi licenciar un componente como software propietario:el Connector for Exchange. Este mdulo permite a uno de sus productos estrella, Evolution (un gestor de informacinpersonal que incluye correo electrnico, agenda, calendario, etc.) interactuar con servidores MS Exchange, muy utilizadosen grandes organizaciones. De esta manera trataba de competir ventajosamente con otras empresas que proporcionenservicios basados en GNOME, quizs con los productos desarrollados por la propia Ximian, que no podran interaccionartan fcilmente con Exchange. Salvo por este producto, el modelo de Ximian ha sido de mejor conocimiento, y tambinbasado en ser la fuente de un programa (ver ms adelante). En cualquier caso, este componente fue liberado en 2005.

5.2.3. Fuente de un producto libre

Este modelo es similar al basado en el mejor conocimiento, pero especializndolo de forma que la empresa que lo utiliza esproductora, de forma prcticamente ntegra, de un producto libre. Naturalmente, la ventaja competitiva aumenta al ser los desa-rrolladores del producto en cuestin, controlar su evolucin, y tenerlo antes que la competencia. Todo esto posiciona a la empresadesarrolladora en un lugar muy bueno de cara a los clientes que quieran servicios sobre ese programa. Adems, es un modelomuy interesante en trminos de imagen, ya que la empresa ha demostrado su potencial desarrollador con la creacin y manteni-miento de la aplicacin en cuestin, lo que puede ser muy interesante de cara a convencer a posibles cliente de sus capacidades.Igualmente proporciona muy buena imagen de cara a la comunidad del software libre en general, ya que reciben de la empresaun nuevo producto libre que pasa a formar parte del acervo comn.

EjemplosSon muchos los productos libres que comenzaron su desarrollo dentro de una empresa, y muy habitualmente ha continuadosiendo esa empresa quien ha guiado su desarrollo posterior. A modo de ejemplo, podemos citar los siguientes casos:

Ximian. Ya se mencionado cmo en parte ha usado el modelo de mejor conocimiento con limitaciones. Pero en general,Ximian ha seguido un claro modelo basado en ser la fuente de programas libres. Sus principales productos, como Evolutiono RedCarpet se han distribuido bajo licencias GPL. Sin embargo otros tambin importantes, como Mono, se distribuyenen gran parte bajo licencia MIT X11 o LGPL. En todos estos casos, Ximian los ha desarrollado casi en exclusiva desde elcomienzo. La empresa ha tratado de rentabilizar este desarrollo consiguiendo contratos para hacerlos evolucionar en ciertossentidos, para adaptarlos a las necesidades de sus clientes, y ofreciendo personalizacin y mantenimiento.

Zope Corporation [75]. En 1995 se funda Digital Creations, que desarrolla un producto propietario para la gestin de anun-cios clasificados va web. En 1997 recibi una inyeccin de capital por parte, entre otros, de una empresa de capital-riesgo,Opticality Ventures. Lo extrao (en aquella poca) de esta inversin es que como condicin le pusieron que distribuyeracomo software libre la evolucin de su producto, lo que ms adelante fue Zope, uno de los gestores de contenidos mspopulares en Internet. El modelo de negocio de la empresa desde entonces fue producir Zope y productos relacionadoscon l, y ofrecer servicios de adaptacin y mantenimiento para todos ellos. Zope Corporation ha sabido, adems, crear unadinmica comunidad de desarrolladores de software libre alrededor de sus productos, y colaborar activamente con ellos.

lromanieu

Introduccin

05) seoane, j., gonzález, j. m. robles, g. (2003). “aspectos legales”; “economía“y...

Documents