¿Se impondrán los códigos abiertos?

Revista Nº 6 Ene.-Mar. 2005

por Jane Kaufman Winn 

1. Introducción

El software de código abierto ha atraído una atención considerable en los últimos años, por tratarse de una alternativa de bajo costo con respecto al software desarrollado y licenciado por las compañías privadas. A pesar de haber existido por décadas, solo recientemente ha emergido como una alternativa viable respecto de los programas convencionales.

En algunos mercados, el software de código abierto es actualmente predominante. Por ejemplo, durante el año 2004 el software de servidor de Apache Web tuvo el 74% del mercado global de programas para servidores, muy por encima de Microsoft, quien tuvo el 21% y cuyo liderazgo ha mantenido por muchos años(1). Al compararlo con el software convencional, el de código abierto tiene algunos beneficios obvios: (i) muchos programas de código abierto se distribuyen sin cargo al usuario final y (ii) un precio de cero es evidentemente más bajo que el precio de cualquier software convencional.

Adicionalmente, los usuarios finales de programas de código abierto tienen la autoridad para efectuar cambios al software, al proporcionarles la información requerida para hacerlo —una característica que atrae a los usuarios finales más sofisticados—. Sin embargo, el precio de una licencia es solamente parte del costo de utilización de un programa, de manera que el bajo precio inicial de un software de código abierto no puede reflejar el costo real de su utilización efectiva.

Puede que los licenciatarios de este tipo de programas no reciban asistencia si surgen problemas en su utilización, salvo que hayan pactado la compra de la prestación de estos servicios. Es así como por ejemplo, los usuarios pueden tener la opción de tener copias del sistema operativo del código abierto de Linux, distribuido por Red Hat, su mayor distribuidor, con el propósito de recibir asistencia, en vez de descargar sus copias en cualquier lugar sin tener que pagar por ellas. De esta manera, cuando se contabiliza el precio de tales servicios, el costo general de la utilización del software de código abierto puede no ser la ganga que aparenta ser.

En años recientes, muchos negocios y gobiernos han adoptado los programas de código abierto por una serie de razones, dentro de las cuales está la frustración que han tenido con las prácticas de licenciamiento de los desarrolladores de software convencional o con la calidad de algunos productos del mismo. Por su parte, los proponentes de programas de código abierto creen generalmente que sus productos son menos costosos de poner en funcionamiento, incluso cuando incluyen los costos de asistencia, porque piensan que el proceso abierto y participativo utilizado para desarrollar su software trae como resultado la realización de productos de mejor calidad.

Aunque estos argumentos son discutidos arduamente por los desarrolladores de programas convencionales, la popularidad cada vez mayor del software de código abierto ha dado origen a nuevas presiones competitivas sobre los desarrolladores de programas comerciales(2). Sin embargo, un costo en la utilización de software de código abierto, que no todos los licenciatarios tienen en cuenta, es el riesgo de la responsabilidad que existe por utilizar “códigos de código abierto” que infrinjan derechos de autor o patentes de terceros. Este riesgo tendría un mayor desarrollo en el futuro, cuando se dé a conocer el fallo del litigio que actualmente tiene lugar en los Estados Unidos y que involucra reclamos competitivos basados en el código fuente para el sistema operativo Linux(3).

Mientras para muchos observadores este juicio no tiene ningún sustento, pues creen que será resuelto finalmente a favor de los desarrolladores de código abierto y de los usuarios, el pleito ha llevado sin embargo a que usuarios potenciales de estos programas calculen de una manera diferente los costos relativos del código abierto frente a los del software convencional. Adicionalmente, ciertas organizaciones que en alguna oportunidad consideraron que los programas de código abierto eran una fuente valiosa para ayudarlos a desarrollar su propio software, para de esta manera conseguir sus propios objetivos internos, actualmente reconsideran su valor al existir la posibilidad de que este se pueda distribuir a otras sin ningún impedimento.

La distribución de software que incluye elementos de códigos de código abierto puede estar sujeta a restricciones onerosas, como el deber de revelar el código fuente siempre que el nuevo programa sea distribuido y hacer copias del nuevo software y permitir su disponibilidad sin cargo alguno(4). Para que esta clase de programas pueda tener éxito como una alternativa comercialmente viable frente al software convencional se requiere desarrollar técnicas más efectivas para el manejo de los riesgos en la utilización de los productos desarrollados a través de un proceso de colaboración en gran escala.

Adicionalmente, las organizaciones individuales deberán desarrollar políticas y procesos para asegurarse de que en su utilización se cumplen todos los términos y condiciones de cualquier producto de código abierto. Si nuevos sistemas para la administración de esta clase de software pueden ser desarrollados, se logrará asegurar su éxito comercial. Sin perjuicio de lo anterior, el movimiento de fuentes abiertas desde sus raíces llegará aún más allá, esto es, como si se tratara de una actividad política populista.

2. ¿Qué es lo abierto en los códigos abiertos?

El software de código abierto y el convencional difieren en las disposiciones de los contratos de licencia que son utilizados para su distribución a los usuarios finales, así como en aquellos términos prácticos que son importantes para los administradores de sistemas de cómputo y sus desarrolladores. Algunas de estas diferencias prácticas surgen de las discrepancias que existen entre los códigos fuente del programa —los cuales son incluidos por los programadores, pueden ser leídos y editados por los seres humanos y no pueden ser procesados por los computadores sin modificación— y los códigos de objeto o de máquina —que son ejecutados por los computadores pero que generalmente no pueden ser leídos o modificados por los seres humanos—.

El código fuente es incluido por los programadores utilizando diferentes lenguajes de programación como Java, C, Cobol o Pascal y luego se corren a través de un “compilador”, que es un programa de software especial que convierte los textos de los códigos fuente en códigos de objeto ejecutables por una máquina. Si un usuario final solo tiene acceso a la versión de código de objeto de un programa de software, al mismo le será difícil e incluso imposible hacerle cambios.

Los desarrolladores del software convencional generalmente le dan a su código fuente el carácter de secreto comercial(5) y limitan estrictamente el acceso, suministrando códigos objeto exclusivamente a los licenciatarios como parte de su estrategia para fortalecer la protección a la propiedad intelectual de sus productos. Esto tiene como consecuencia que se les limita la posibilidad de introducir modificaciones a sus productos y, de esta manera, los competidores tendrán mayores dificultades para crear otros.

Pero no todo el software es desarrollado y distribuido utilizando el modelo convencional de fuente cerrada. Las innovaciones en los programas de código abierto permiten la distribución de códigos fuente que pueden ser leídos por los seres humanos, junto con versiones ejecutables de código de objeto. Adicionalmente, los licenciatarios de software de código abierto tienen autoridad general para copiar y distribuir el código fuente original y para modificarlo —derechos que normalmente no son atribuidos a quienes licencian programas convencionales—, siempre que las copias o versiones modificadas sean también distribuidas igualmente a través de una licencia de código abierto.

El modelo de esta clase de programas enfatiza la apertura tanto para el desarrollo como para la distribución del software, lo cual trae como resultado disponer de una gran comunidad de desarrolladores y usuarios finales, quienes son capaces de participar en su mejoramiento continuado y en su mayor evolución. La participación de la comunidad global de programadores es una de las principales características del código abierto, pero puede también ser un obstáculo(6).

El proceso abierto y participativo a través del cual se han desarrollado muchos programas de código abierto hace difícil tener certeza de que el código fuente no incluye copias no autorizadas del código fuente protegido por derechos de autor, cuyos propietarios no escogieron participar en un proyecto de código abierto. Un software de estas características es normalmente distribuido sin ningún tipo de garantías, por lo que el usuario final debe correr el riesgo de que algunos de los códigos convencionales puedan encontrar un lugar en el proyecto de código abierto.

Por su parte, los programadores que incorporan elementos de códigos abiertos en sus programas se pueden sorprender al enterarse de lo significantes que son las limitaciones que las licencias de estos productos imponen en la distribución de cualquier programa que incluya cualquier elemento de este tipo. Estas limitaciones reflejan el deseo que tiene la comunidad de código abierto para evitar que los frutos de su trabajo se conviertan en productos convencionales.

En efecto, si los licenciatarios de software de código abierto pudieran convertir su código en convencional los autores originales podrían verse obligados a pagar honorarios para utilizar los productos basados en su propio trabajo e impedir el acceso al código fuente, evitando con ello el estudio de las modificaciones de los diseños originales. El requisito de que cualquier software que incluya elementos de código abierto deba también ser distribuido como un programa de código abierto es lo que lleva al argumento esgrimido por algunos de los desarrolladores del software convencional, en el sentido de que las licencias para estos productos son “virales”.

Mientras que los desarrolladores de programas sofisticados de tiempo atrás han entendido los costos y beneficios en la distribución de sus productos a través de licencias de código abierto o convencionales, hay cada vez más desarrolladores de programas menos sofisticados. En efecto, se trata de organizaciones que primero desarrollan el software para sus propios intereses internos y en una segunda etapa, por un cambio en el plan de negocios, deciden distribuir su producto a terceros. Estos desarrolladores menos sofisticados pueden llegar a concluir que el costo en la utilización de programas de código abierto es mayor que el originalmente calculado.

3. El desarrollo de códigos abiertos

Respecto del software de código abierto no existe una sola licencia autorizada, sino más bien una serie de contratos de licencia con estructuras y objetivos similares, pero con términos y condiciones variables, bajo los cuales se distribuyen tales permisos.

El movimiento de esta clase de programas fue fundado por Richard Stallman en 1984, con el establecimiento del sistema GNU(7), el cual se expandió en 1985 cuando se creó la Fundación del Software Libre (FSF)(8). Stallman creó la licencia pública general del GNU (GPL), la primera de fuentes abiertas y asignó el término “copyleft” para describir el software distribuido bajo la GPL. Este personaje es un dedicado y carismático programador, cuya visión personal ha tenido gran influencia en la percepción pública del software de código abierto por más de una década.

Sin embargo, en la medida en que el enorme potencial comercial de estos programas se ha hecho más claro, su visión politizada se ha visto eclipsada rápidamente por las ideas pragmáticas más modestas de la nueva generación de proponentes de software de código abierto. Este movimiento se ubica en medio de una sucesión de crisis, en la proporción en que los líderes más moderados ganan legitimidad ante los ojos de muchos usuarios de estos sistemas.

El sociólogo alemán Max Weber identificó los tres “tipos ideales” de autoridad, que pueden ser reconocidos como legítimos por los miembros de diferentes sociedades. De acuerdo con el autor, existen tres tipos puros de autoridad legítima. La validez de sus argumentos a favor de la legitimidad puede basarse en lo siguiente:

a) Bases racionales. Las cuales descansan sobre la creencia en la “legalidad” de los patrones de las reglas normativas y el derecho de aquellos elevados a la autoridad bajo dichas reglas para emitir órdenes —autoridad legal—.

b) Bases convencionales. Estas descansan en la creencia establecida sobre la santidad de tradiciones inmemorables y la legitimidad del estatus de aquellos que ejercen autoridad bajo ellos —autoridad convencional—.

c) Bases carismáticas. Descansan en la devoción hacia la santidad específica y excepcional, heroísmo o carácter ejemplar de una persona individual y de los patrones normativos o el orden revelados u ordenados por él —autoridad carismática—(9).

Las controversias actuales alrededor del movimiento de software de código abierto parecen ser un ejemplo de este proceso. Weber lo describe como “routinization of charisma”, pues el liderazgo del movimiento pasa de Richard Stallman, un líder carismático que rechaza la legitimidad de las organizaciones legales burocráticas, a otras tendencias, como open source initiative, las que están preparadas para trabajar dentro de esta forma de autoridad, con el propósito de conseguir sus objetivos.

El movimiento de software gratuito iniciado por Stallman y encuadrado en la GPL fue creado para retar el modelo convencional de desarrollo y distribución de programas. Su ataque al desarrollo del software convencional procede por lo menos en dos niveles: (i) uno, que consiste en un argumento sobre cómo mejorar la calidad del software en uso y (ii) un ataque a la idea del “individualismo posesivo”(10).

Enfrentar estos dos objetivos contribuye a que Stallman adquiera un estatus de líder carismático del movimiento de los programas de código abierto. Su falta de aceptación respecto de los beneficios comerciales de este software se puede separar de la mayor crítica política que contribuye a que su movimiento de gratuidad sea eclipsado por un movimiento más modesto de código abierto.

En términos de los tipos ideales de Weber, la autoridad convencional se encuentra en las sociedades tribales y monárquicas. La legitimidad del orden tradicional se basa en la creencia de que los poderes de control “han existido siempre”. En una sociedad gobernada por los mayores, los que están más familiarizados con las tradiciones sagradas gobiernan colectivamente. La descripción de Eric Raymond respecto del comportamiento y cultura de los hackers de computador sugiere en gran medida que los primeros días de la programación de sistemas en los Estados Unidos se caracterizaron por una cultura tribal con una forma de autoridad convencional(11).

Esta forma de autoridad informal y suelta parece haber sido reemplazada por la carismática ejercida por Stallman. Weber utilizó el término “carismático” para describir el estilo de liderazgo de individuos que creen que tienen el deber de ejercer autoridad y que tienen la capacidad de persuadir a otros para que los sigan. Es así como los líderes carismáticos en las sociedades convencionales incluyen profetas y chalanes; en las modernas, incluyen demagogos y líderes espirituales, como el Papa y el Dalai Lama.

El sociólogo alemán pudo describir el movimiento del software gratuito al decir que “el grupo corporativo que está sujeto a la autoridad carismática se basa en la forma emocional de la relación comunal”(12). La autoridad carismática se opone a lo vano y a la rutina y, como tal, es marcadamente diferente tanto de la forma convencional de autoridad que con frecuencia le antecede, como de la forma de autoridad legal burocrática que le sigue asiduamente.

Stallman articuló una fuerte justificación teórica y moral para el continuo crecimiento y desarrollo de la comunidad de código abierto, al establecer en 1984 la Fundación del Software Gratuito. Aunque no todos sus miembros pueden adherirse de lleno a cada elemento de la visión del fundador, tuvo éxito al darle a la comunidad de código abierto una conciencia propia y una dirección que no habría sido posible desarrollar si se hubiera mantenido una organización tribal.

Sin embargo, una clave de su autoridad carismática es el hecho de que combina un proyecto más modesto, básicamente cambiando lo que es considerado normal en el mundo del desarrollo del software, con un proyecto más grande que reta la idea de “propiedad intelectual”(13). Mientras que el rechazo radical del papel de los derechos de propiedad en una sociedad moderna, liberal y democrática, puede haber galvanizado muchos seguidores, dificulta para Stallman la institucionalización de sus puntos de vista. Su ambivalencia sobre las formas legales de autoridad por lo general merma la efectividad de la GPL como un formato de contrato y, además, ataca su viabilidad a largo plazo como un líder en la comunidad de desarrollo de programas informáticos.

Actualmente, el movimiento de software gratuito enfrenta un nuevo reto, el cual es descrito por Weber como la “rutinización del carisma”. La forma carismática de autoridad, por su naturaleza, es intensamente subjetiva y personal, de una manera que es ajena a la rutina. Si la forma carismática de autoridad ha de sobrevivir, se debe encontrar un mecanismo que perpetúe con predictibilidad la autoridad personal del líder carismático. Esto se puede conseguir con base en la búsqueda de otro individuo que tenga las mismas características carismáticas, que es el proceso como se escoge un nuevo Dalai Lama.

Por otra parte, un líder carismático puede nombrar a su sucesor o igualmente, el equipo de un líder de estas características puede elegir uno nuevo. Este es el mecanismo mediante el cual se elige a un nuevo Papa. Sin embargo, como lo anota Weber, “para que el carisma se pueda transformar en una estructura permanente de rutina, es necesario que su carácter antieconómico se altere”(14).

Lo que parece ocurrir en la comunidad del desarrollo de programas informáticos no es precisamente la rutinización del liderazgo carismático de Stallman sobre el movimiento del software gratuito. Por el contrario, se presenta la aparición de un liderazgo legal y burocrático del movimiento de código abierto, el cual finalmente ejercerá más influencia y tendrá un mayor impacto en la forma como se producen los programas.

Linus Towalds, autor de Linux, ejerce un estilo de liderazgo que se nutre tanto de la forma carismática como de la legal. Este se constituye en un puente entre los primeros días más radicales del movimiento del software gratuito y sus más moderadas manifestaciones, ejemplarizadas mediante la creación de organizaciones como Open Source Initiative —iniciativa de código abierto— (OSI)(15), Open Source Development Labs —laboratorios de desarrollo de código abierto— (OSDL)(16) y Open Source Risk Management —manejo del riesgo de código abierto— (OSRM)(17).

Por otra parte, Weber identificó las siguientes características de la forma de autoridad legal-burocrática. Veamos:

a) Organización continua de las funciones oficiales regidas por reglas.

b) Órganos de administración con esferas de competencia específicas.

c) Una organización jerárquica administrada por oficiales.

d) Separación de la propiedad de los recursos y administración de los mismos.

e) Existencia de oficiales, con base en criterios objetivos de competencia.

f) Archivos escritos de los actos, decisiones y reglas administrativas(18).

Las organizaciones de estándares abiertos como OSI, OSDL y OSRM ejercen una autoridad legal burocrática, no solo porque aceptan la legitimidad fundamental de ideas de propiedad, contratos y mercados, sino porque su organización es fundamentalmente burocrática y no carismática.

Otros se han unido a Stallman en la idea de unir la práctica de un desarrollo de software de código abierto y su distribución con objetivos políticos y económicos. Lawrence Lessig ha relacionado la práctica de código abierto con la práctica democrática para afirmar que los ideales del movimiento de código abierto deben jugar un papel fundamental en el manejo de la tecnología en la sociedad moderna(19).

Yochai Benkler, por su parte, ha sugerido que los esfuerzos de colaboración a gran escala, los cuales han permitido producir programas de código abierto tan exitosos como los programas de servidores Linux o Apache Web, se constituyen en una alternativa para las compañías como una forma de organización empresarial(20). Sin embargo, pasará algún tiempo para que se sepa si el software de código abierto responderá a estas aspiraciones.

No obstante, en el corto plazo, muchos desarrolladores y licenciatarios estarán en la posibilidad de escoger entre productos de código abierto y los tradicionales. Por su parte, OSL, OSDEL y OSRM trabajan para asegurar que la opción por los primeros resulte y permanezca como una alternativa viable para un alto número de desarrolladores y licenciatarios, sin distinguir sus inclinaciones políticas.

4. Los términos de una licencia de código abierto

En primer lugar, se debe indicar que si bien GPL, promovida por la Fundación del Software Libre, puede ser la licencia de código abierto más famosa, no es la única(21).

Dos características críticas de esta clase de programas son las siguientes:

a) Acceso al código fuente para asegurar que los usuarios tengan la posibilidad de modificar, estudiar o mejorar las funciones del programa.

b) La licencia debe contener términos que le permitan redistribuir software modificado(22).

Algunas licencias de código abierto, como la GPL, imponen limitaciones importantes al derecho que tienen los licenciatarios respecto de distribuir programas de código abierto modificado para garantizar que todas las modificaciones del código fuente permanezcan abiertas y accesibles, mientras que otras no lo hacen.

Las principales características de la GPL son las siguientes:

a) Cualquier persona puede bajar, utilizar, modificar y distribuir el software.

b) Si se modifica el programa, las versiones modificadas deben también ser distribuidas bajo la licencia.

c) Todos los avisos de protección de derechos de autor y avisos de responsabilidad se deben incluir, siempre que se vayan a distribuir copias y todas las modificaciones deben estar claramente marcadas.

d) Todas las distribuciones deben incluir el código fuente en su integridad.

e) No existe garantía sobre el software.

f) Si los licenciatarios así lo desean, tienen libertad para cobrar una tarifa y adicionar una protección con las copias del programa. Esto siempre y cuando se cumplan las demás condiciones de la licencia.

El software desarrollado en el eje de FSF, incluido el sistema operativo Linux, se distribuye bajo la GPL. El FSF distingue más entre software gratuito y otros tipos de programas, que entre software de código abierto y convencional. Los usuarios del sistema gratuito tienen la libertad para correr el programa para cualquiera de los siguientes propósitos: (i) estudiar cómo funciona el sistema; (ii) redistribuir copias y (iii) modificar el programa y distribuir la versión modificada(23).

Muchas licencias que innegablemente son de código abierto no cumplen con el estándar de “software gratuito”, porque no imponen fuertes restricciones a los desarrollos posteriores requeridos para mantener la apertura del código fuente original, después de haber sido modificado.

Uno de los aspectos más complicados de determinar en la GPL es el de saber cuándo un programa nuevo es “derivado” de uno de código abierto sujeto a esa licencia y, por esa razón debe ser distribuido bajo los términos de la misma, al igual que cuando la relación entre el programa original de código abierto y el nuevo se atenúe tanto que no deba estar sujeto a ella(24).

El problema en este punto surge en parte por el lenguaje de la GPL, que no utiliza una licencia estándar de derechos de autor o de terminología de software(25). Este problema es particularmente agudo con los programas que comparten una biblioteca común. Para resolver esta cuestión se desarrolló una “GPL menor”. Sin embargo, el FSF recomienda que no se utilice, salvo que concurran circunstancias especiales(26).

Otra licencia popular de código abierto es la “Berkeley software distribution” (BSD), que aparece con la versión del sistema operacional UNIX, distribuido por Berkeley. Esta es mucho más simple que la GPL y sus principales características son las siguientes:

a) Cualquier persona puede bajar, modificar y distribuir este programa de cualquier manera.

b) Todos los derechos de autor y avisos de garantía deben mantenerse en el software.

c) No hay garantía sobre el programa.

Esta se constituye en un ejemplo de licencia de código abierto que no reúne un alto estándar de “software gratuito”. Un programador que utilice códigos fuente de un programa distribuido bajo la BSD tiene la opción de distribuir el software modificado como un programa de código abierto o de fuente cerrada(27).

5. Costos y beneficios del software de código abierto y del convencional

La manera como los desarrolladores y licenciatarios deben calcular los costos y beneficios relativos del programa de código abierto y del convencional ha sido objeto de considerable controversia. En el 2001 un estudio analizó los costos y beneficios del primero —conocido como software “comercial de contador” o COTS—, del segundo y del fabricado.

Al respecto encontró que para muchas aplicaciones el costo total de un negocio de utilización de software de código abierto podría ser más bajo que el costo total de productos convencionales competitivos(28). La investigación permitió deducir los siguientes beneficios para el modelo de desarrollo de código abierto, el cual incluye las contribuciones de una comunidad global de programadores:

a) La revisión crítica del código fuente puede resultar en códigos menos complejos, tan fácilmente legibles y modificables que llevan a una mayor calidad de la programación.

b) El acceso al código fuente permite la reutilización de códigos, lo que garantiza ahorro de tiempo en el desarrollo de proyectos subsecuentes.

c) El acceso al código fuente facilita la interacción de diferentes programas.

d) El apoyo de un software no está ligado al destino de un único distribuidor que puede elegir detener el apoyo a un programa, aun cuando haya todavía demanda de apoyo entre los usuarios.

e) La competencia de parte del código abierto puede presionar a los distribuidores del software convencional a ofrecer mejor términos, bien sea en el precio de las licencias o en el valor de los servicios de apoyo.

El estudio también destacó los siguientes costos por el uso de software de código abierto:

a) En caso de existir una gran cantidad de participantes que se sientan poco atraídos a trabajar en un proyecto particular de código abierto, la falta de revisión crítica de los códigos trae como consecuencia una menor calidad de la programación.

b) El apoyo es prestado por usuarios tecnológicamente sofisticados, el cual es menguado frente a los menos sofisticados. Esto puede implicar mayores costos de apoyo para algunos usuarios, en comparación con los productos convencionales, si se tiene en cuenta el entrenamiento de los empleados, así como los costos de consultoría y de personal.

c) Se presenta el riesgo de fragmentación de los proyectos de código abierto debido a una falta de estructura de control jerárquico para guiar el desarrollo.

No obstante, esta investigación no se refiere al riesgo de responsabilidad por violaciones de derechos de autor como uno de los costos asociados con el uso de software de código abierto. Adicionalmente, se centró en las necesidades de los usuarios finales que no distribuyen los programas que realizan y, por lo tanto, no analizó los factores que los desarrolladores de software deben tener en cuenta antes de incluir códigos de código abierto en sus propios programas.

Otro estudio de los costos y beneficios en la utilización del software de código abierto, efectuado en el 2004, analiza no solo el riesgo de responsabilidad por violación, sino además las implicaciones de negocio de las limitaciones a la distribución de software que incluya cualquier código fuente sujeto a los términos de la GPL(29). Este análisis señala que algunas organizaciones encontraron que una vez se realizan los gastos de apoyo, tales como el entrenamiento de empleados y las pruebas del programa, el costo del software de código abierto puede ser equivalente o incluso mayor que el costo de los programas convencionales, a pesar de que esto no es cierto para la mayoría de organizaciones participantes en el estudio.

Esta investigación se enfocó en un aspecto que no fue considerado por el estudio del 2001. En efecto, muchos licenciatarios sofisticados de programas son también desarrolladores y distribuidores de software. Para estas organizaciones, las políticas y procedimientos son necesarias para separar los códigos de código abierto de los convencionales y para determinar si los primeros deben ser incluidos en los programas desarrollados internamente, debido a las restricciones a una posterior distribución, mediante licencias como GPL(30).

Por ejemplo, si una compañía planea entregar programas de software a sus distribuidores o clientes para lograr que sus negocios sean más eficientes y los programadores de la empresa usan cualquier código fuente sujeto a la GPL, deberá suministrarles el código fuente junto con la versión ejecutable. Esta distribución les facilitará a sus competidores estudiar e incluso copiar sus sistemas con relación a sus distribuidores y clientes. Por otra parte, si la compañía desea mantener en secreto el código fuente para su software, entonces sus programadores deben dejar de usar en su desarrollo cualquier código fuente sujeto a los términos de la GPL.

6. Aspectos legales no resueltos por los códigos abiertos

Las licencias de código abierto representan una innovación sustancial en la normativa de licenciamiento de propiedad intelectual y, como resultado de lo anterior, la imposición de algunos de los términos de los acuerdos es incierta. Debido a que estas disposiciones se incluyen con el software de código abierto cuando este es distribuido, puede que no exista claridad acerca del momento en que se produce la oferta y la aceptación. Esto hace que pretender que estas licencias sean contratos resulte demasiado incierto.

La tendencia legal en Estados Unidos es que estos documentos son contratos, a pesar de que no existe claramente una oferta y una aceptación(31). Así que, por lo menos en lo que se refiere al ordenamiento de ese país y con base en los argumentos señalados, es cada vez menos previsible que una licencia de código abierto sea invalidada por una corte estadounidense.

Por otra parte, continúa siendo incierta la manera como un tribunal de ese país podría interpretar los términos de una licencia específica de código abierto. Esto resulta especialmente cierto para la GPL que es, además de una manifestación política, un contrato. Así que la interpretación de muchas de sus cláusulas bajo las leyes de derechos de autor de los Estados Unidos es, en el mejor de los casos, ambigua.

Mientras que Richard Stallman, el autor de esta licencia, puede tener opiniones claras con relación a su correcta interpretación, no resulta suficientemente claro que una corte de ese país encuentre que sus razonamientos sirven de guía para interpretar sus términos, de la misma manera que la intención de las partes en un contrato. En efecto, al interpretar el acuerdo, el comentario que explica la intención del redactor de un contrato modelo utilizado por las partes es una fuente que el tribunal puede tener en cuenta para interpretar sus verdaderas intenciones. La corte necesitará establecer cuál fue la motivación que llevó a determinar si se celebró un contrato y, si ello es así, cuál es el significado de sus disposiciones.

Es así como al interpretar la GPL el juzgador tenderá a revisar primero las intenciones de las partes en controversia y, solo como un tema secundario, cuál fue la intención del autor de la licencia en el contrato.

Si se llega a la conclusión que se celebró un contrato y que sin embargo las partes están en desacuerdo respecto de la interpretación de sus términos, entonces el juez deberá decidir cuáles son los términos del acuerdo. Si una parte ofrece pruebas para demostrar que su interpretación de las disposiciones contractuales es la misma ofrecida por el redactor del formato de convenio utilizado por los contratantes, entonces la intención de aquel será relevante en la búsqueda de un significado de los términos del acuerdo entre ellas.

Acto seguido la corte preguntará si se puede esperar que la otra parte esté de acuerdo con la interpretación del formato hecha por el redactor respecto de los términos del contrato(32). Si la parte contra la cual se quiere oponer el contrato no acepta la interpretación del redactor del formato acerca del lenguaje del convenio, entonces el juez deberá determinar cuál es el significado objetivo de los términos del acuerdo y si las partes encontraron correcta tal interpretación(33). Es poco probable que una corte resuelva que las polémicas asociadas con la defensa por parte de Stallman del software gratuito suministren la mejor guía en relación con el significado objetivo de los términos de un contrato, incluso siendo este el autor de los términos del acuerdo.

En marzo del 2003, SCO —una pequeña compañía de software poco conocida— demandó a IBM, argumentando que esta se había apropiado indebidamente de algunos de sus códigos fuente convencionales para la utilización del sistema operativo Linux de código abierto(34). Esta demanda ha llamado la atención del público en la medida que cada vez se ha agrandado y vuelto más compleja, por cuanto la demandante ha utilizado el mismo argumento en contra de otras entidades y paradójicamente ha sido demandada, al tratar de terminar un litigio que en opinión de muchos carece de fundamento.

Una de las más importantes consecuencias de este proceso es que muchos usuarios nuevos y potenciales del software de código abierto reconsideran actualmente su análisis inicial respecto de los costos y beneficios de esta clase de programas.

El Grupo SCO es propietario de varios derechos de propiedad intelectual del sistema operativo UNIX. De 1995 al 2001 trabajó en un joint venture con un código de IBM llamado “Monterrey”, el cual tenía como propósito correr su sistema operativo en un nuevo procesador de 64 bits. Esta unión no tuvo éxito, por cuanto IBM decidió seguir adelante con la utilización de Linux y no de UNIX como sistema operativo. Antes de iniciar la serie de demandas que arguye que Linux violaba sus derechos, SCO estaba perdiendo mucho dinero(35).

Dado que Microsoft fue un instrumento para la presentación de SCO a los capitalistas aventureros que le dieron el dinero para pagar los costos del proceso(36), existe una gran especulación con relación a una posible conexión entre esas dos compañías. En la medida que los litigios de SCO hacen que aumente “el temor, la incertidumbre y la duda —fear, uncertainty and doubt— (FUD) entre los licenciatarios de software y que llevan a las empresas temerosas de los riesgos a mantenerse con productos de Microsoft por el temor a un pleito, se le está ayudando a esta empresa para que consiga un lento crecimiento de su competencia de código abierto”.

Como se mencionó, en marzo del 2003 SCO demandó a IBM. Su petición tuvo como fundamento una presunta apropiación indebida de secretos comerciales, competencia desleal, el incumplimiento de un contrato e interferir indebidamente con el negocio que tenía la demandante. Esta señaló que partes de su código UNIX han aparecido como código fuente de Linux y que tiene derecho a revocar la licencia de IBM sobre su versión de UNIX.

Desde afuera, muchos observadores son escépticos en relación con los méritos de las demandas de SCO(37). No obstante, otros han observado que las prácticas de análisis de los códigos de desarrollo de código abierto hacen que las demandas de esta compañía puedan proceder. IBM se defendió aduciendo que fue precisamente su demandante quien entregó el código Linux bajo una licencia de código abierto y contra argumentó que esta se encontraba violando sus patentes. Por su parte, Red Hat demandó a SCO en agosto del 2003 con la pretensión principal de que se declarara que Linux no le infringía a esta compañía ningún derecho de propiedad intelectual.

En diciembre del 2003, SCO envió cartas a las 1.500 grandes compañías que utilizan Linux, reclamándoles por presuntas violaciones y afirmando que deseaba proteger y hacer valer de manera agresiva sus derechos de propiedad intelectual. Después de que Novell le reclamara su propiedad sobre el código fuente en cuestión, SCO la demandó en enero del 2004.

Finalmente, en marzo del mismo año, demandó a Daimler Chrysler luego de haberse tomado un tiempo considerable en responder a su solicitud de confirmar que nunca había compartido su código con los desarrolladores de Linux. Sin embargo, esta demanda fue inadmitida en el mes de julio, cuando la demandante no fue capaz de demostrar que la respuesta tardía a su solicitud le causó perjuicios.

Durante todo el proceso SCO mostró poca evidencia para apoyar muchos de sus argumentos legales y fácticos más importantes, llevando a que una gran mayoría afirme que en este tipo de demandas es poco probable obtener un fallo positivo.

7. Conclusión

El software de código abierto se ha convertido en un serio competidor del convencional. Los licenciatarios comprenden los beneficios que este tiene, pero no resulta claro que entiendan igualmente bien cuáles son los costos de la utilización de códigos abiertos. No obstante, los costos de adquisición de esta clase de programas pueden ser bajos y algunos de estos productos son más estables y seguros que los tradicionales.

La estructura abierta y participativa de los proyectos de código abierto permite contribuir a acrecentar estas ventajas, ya que se benefician de los esfuerzos no compensados de un gran número de desarrolladores con inmensas capacidades. Aunque la falta de una estructura jerárquica en muchos proyectos de código abierto trae beneficios al aumentar el número de desarrolladores participantes, también trae consigo costos considerables, debido a la ausencia de una autoridad central encargada de las responsabilidades de administración de los derechos.

Las empresas que consideran utilizar productos de programas de código abierto deben tener cuidado en cuanto a los gastos de apoyo, tales como las pruebas del software y el entrenamiento de los empleados que se pueden requerir para alcanzar una completa utilización de los mismos. Las compañías que no se limitan a ser usuarios finales de software, sino también desarrolladores y distribuidores, deben asumir políticas y procedimientos para asegurar que cumplen con las limitaciones impuestas en algunas licencias de código abierto respecto de la distribución de programas que contengan esa clase de elementos. Aunque los litigios recientes que involucran a Linux han aclarado muchos de los riesgos en la utilización de esta clase de programas, no se puede eliminar el código abierto como una alternativa comercial al software convencional.

El movimiento de código abierto se está alejando rápidamente de sus orígenes, primero como una práctica reiterada de la comunidad de hackers y, en segundo lugar, como una corriente política que reta las bases del derecho de propiedad intelectual. Organizaciones como Iniciativa de Código Abierto, Open Source Development Labs y Open Source Risk Management trabajan para remover los obstáculos que tiene un desarrollo comercial adicional de software de código abierto, preservando al mismo tiempo el convencional.

La sucesión en el liderazgo del movimiento de código abierto puede llevar a una forma para su licenciamiento más útil, menos escandalosa y más popular en el futuro próximo.

(1) Netcraft August 2004 web server survey. Texto disponible en la página: http://news.netcraft.com/archives/web_server_survey.html —consultada el 30 de agosto del 2004—. Información acerca del “apache web server software” está disponible en el sitio web de la Apache Software Foundation en: www.apache.org/ —consultado el 30 de agosto del 2004—.

(2) Wireless watch, software giants feel open source pressure. En: The Register, julio 2 del 2004, disponible en: www.theregister.co.uk/2004/07/02/open_source_pressure/ —consultado el 30 de agosto del 2004—.

(3) El litigio que envolvió a SCO, la cual reclamaba que partes del código fuente de Linux infringían sus copyrights, al igual que IBM, Red Hat, Daimler-Chrysler y otras compañías es discutido infra, en el numeral 6º de este escrito. Información acerca de los varios procesos iniciados por SCO y otros, basados en este tipo de reclamaciones se puede conseguir en internet. El sitio www.grokster.com registra todos los procesos y aboga por códigos abiertos —consultado el 30 de agosto del 2004—. Microsoft ha fijado white papers en su sitio web, en el que soporta su posición respecto de que el valor total de la propiedad de los productos de la compañía es equivalente o menor que el de los productos de códigos abiertos que se pueden conseguir en: www.microsoft.com/windowsserversystem/facts/default.mspx —consultado el 30 de agosto del 2004—. Un relato humorístico del litigio, basado en una analogía al programa de televisión los Dukes de Hazard está disponible en la dirección: www.arie.org/doh/ —consultada el 30 de agosto del 2004—.

(4) La licencia general pública del sistema operativo GNU, discutida infra en los numerales 3º y 4º, establece:

1. You may copy and distribute verbatim copies of the program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this license and to the absence of any warranty; and give any other recipients of the program a copy of this license along with the program.

You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.  

2. You may modify your copy or copies of the program or any portion of it, thus forming a work based on the program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this license…”.

El texto completo de la licencia está disponible en: www.gnu.org/licenses/gpl.html —consultada el 30 de agosto del 2004—.

(5) Los secretos comerciales son protegidos como propiedad intelectual según las leyes estadounidenses, siempre y cuando la información en cuestión tenga un valor económico al no ser conocida públicamente y se realicen esfuerzos razonables para mantener su privacidad. Véase, de manera general, la Uniform Trade Secrets Act §1(4), disponible en: www.law.upenn.edu/bll/ulc/fnact99/1980s/utsa85.htm —consultada el 30 de agosto del 2004—. Información sobre los antecedentes referente a esa normativa se encuentra en el sitio web de la National Conference of Commissioners for Uniform State Laws —www.nccusl.org—.

(6) Cuando los programadores son confrontados respecto de problemas en su software pueden intentar asumir la experiencia del usuario final de una manera más positiva y afirmar: “No es una falla, ¡es una cualidad!”. Véase, de manera general, Lubar, D. It’s not a bug, it’s a feature! Computer Wit and Wisdom, 1995.

(7) GNU es un acrónimo recursivo, por el cual se debe entender “Gnu’s Not Unix”. Stallman estableció este acrónimo como una alternativa al sistema operativo Unix, el cual se creía que había partido de una estructura abierta, cuando fue creado en 1969, a una más cerrada de propiedad en 1980, época para la cual había llegado a ser líder en sistemas operativos de workstations y servidores.

(8) Libre en este contexto se refiere a libertad —como en un “free speech”—, no respecto a precios —como en un “free lunch”—. Información acerca de la Free Software Foundation está disponible en la página: www.gnu.org —consultada el 30 de agosto del 2004—.

(9) Weber, M. The theory of social and economic organization. Traducción de Henderson, A.M. y Parsons, T., 1947, p. 328.

(10) Macpherson, C.B. The political theory of possessive individualism. Oxford University Press, 1962.

(11) Raymond, E.S. The cathedral and the bazaar. 1999.

(12) Weber, ob. cit., p. 360.

(13) Eben Moglen, general counsel de la Free Software Foundation y profesor de Columbia Law School, expuso este punto de manera más clara en enero del 2003 en The DotCommunist manifesto, al decir que una de las metas del movimiento de software libre era “la abolición de todas las formas de propiedad privada en las ideas”. Disponible en: http://emoglen.law.columbia.edu/publications/dcm.html. Stallman hace apreciaciones similares menos bruscas en ensayos como Why software should not have owners y Why software should be free”, disponibles en: www.gnu.org. Véase, por ejemplo, Stallman, R. Reject IP enforcement directive (“Even using the term ‘intellectual property’ is a point of weakness, because this is a propaganda term for those who aim to restrict the public”). Disponible en: www.gnu.org/philosophy/ipjustice.html.

(14) Weber, ob. cit., p. 369.

(15) Información acerca de OSI está disponible en: www.opensource.org/ —consultado el 30 de agosto del 2004—.

(16) Información acerca de OSDL está disponible en: www.osdl.org/ —consultado el 30 de agosto del 2004—.

(17) Información acerca de OSRM está disponible en: www.osriskmanagement.com/ —consultado el 30 de agosto del 2004—.

(18) Weber, ob. cit., pp. 330-332.

(19) Véase, por ejemplo, Lessig, L. Open source and open societies: values of Internet governance. En: 74 Chi.-Kent. L. Rev. 1405, 1999. Estas ideas también son examinadas en Lessig, L. Code and other laws of cyberspace 6-8, 1999 y The future of ideas: the fate of the commons in a connected world 26, 2001.

(20) Benkler, Y. Coase’s penguin, or, Linux and the nature of the firm. En: 112 Yale L.J. 369, 2002. Véase también McGowan, D. Legal implications of open source software, 2001. U. Ill. L. Rev. 241, 2001.

(21) La OSI mantiene una lista de todas las licencias de códigos abiertos que han sido revisadas y aprobadas, las cuales están disponibles en: www.opensource.org/licenses/ —consultada el 30 de agosto del 2004—.

(22) President’s Information Technical Advisory Committee. Report to the President of the United States:developing open source software to advance high end computing. Octubre del 2000, p. 2. Disponible en: www.hpcc.gov/pitac/ —consultado el 30 de agosto del 2004—.

(23) Free Software Foundation. The free software definition. Disponible en: www.gnu.org/philosophy/free-sw.html —consultada el 30 de agosto del 2004—.

(24) Lesser GPL. Disponible en: www.gnu.org/copyleft/lesser.html —consultado el 30 de agosto del 2004—.

(25) Gomulkiewicz, R.W. De-bugging open source software licensing. En: 64 U. Pitt. L. Rev. 75, 2002, p. 88.

(26) Stallman, R. Why you shouldn’t use the library GPL for your next library. 1999. Disponible en: www.gnu.org/licenses/why-not-lgpl.html —consultada el 30 de agosto del 2004—.

(27) Gomulkiewicz, R.W. De-Bugging Open Source Software Licensing, cit., p. 93.

(28) Kenwood, C.A. MITRE report: a business case study of open source software. Julio del 2001. Disponible en: www.mitre.org/work/tech_papers/tech_papers_01/kenwood_software/kenwood_software.pdf —consultada el 30 de agosto del 2004—.

(29) Giera, J. y Brown, A. The costs and risks of open source. Forrester Research, abril del 2004. Este documento está disponible para ser descargado del sitio web de Microsoft sin costo en: www.microsoft.com/windowsserversystem/facts/default.mspx —consultada el 30 de agosto del 2004—. Desde el sitio web de Forrester, el informe está disponible solo para la venta por 349 dólares.

(30) Levi, S.D. y Woodard, A. Open source software: how to use it and control it in the corporate environment. En: The Computer Lawyer, agosto del 2004. Disponible en Lexis Legal News —consultada el 30 de agosto del 2004—.

(31) Véase generalmente, Kunz, C.L.; DelDuca, M.F.; Thayer, H. Y Dubrow, J. Click-through agreements: strategies for avoiding disputes on validity of assent. En: 57 Bus. Law. 401, 2001. El artículo es un informe del Working Group on Electronic Contracting Practices dentro del Electronic Commerce Subcommittee del Cyberspace Committee.

(32) Esto es conocido en el derecho estadounidense como “la teoría objetiva del contrato”. Véase Restatement (second) of contracts, §2(1) —A promise is a manifestation of intention to act or to refrain from acting in a specified way, “so made as to justify a promisee in understanding that a commitment has been made” (comillas fuera del texto)—.

(33) Como explicó el juez Learned Hand: “A contract has, strictly speaking, nothing to do with the personal, or individual, intent of the parties. A contract is an obligation attached by the mere force of law to certain acts of the parties, usually words, which ordinarily accompany and represent a known intent”. Caso Hotchkiss v. National City Bank, 200 F. 287, 293-94 (S.D.N.Y. 1911).

(34) La demanda de SCO está disponible en: www.groklaw.net, página que contiene información acerca de todos los aspectos de sus reclamaciones litigiosas acerca de que los elementos del sistema operativo de Linux infringen sus derechos. Información adicional acerca del caso puede ser consultada en la página web de la Corte del Distrito de Utah —Docket Nº 2:03CV00294 (D Utah)—. Disponible en: www.utd.uscourts.gov/documents/ibm.html.

(35) En los Estados Unidos algunas compañías persiguen litigiosamente, de manera infundada y agresiva, presuntas violaciones a los derechos de propiedad intelectual con el propósito de obtener arreglos de demandados que prefieren no correr riesgos. Véase, generalmente, Meurer, M. Controlling opportunistic and anti-competitive intellectual property litigation. En: 44 B.C. L. Rev 509, 2003.

(36) Shankland, S. Investment firm confirms Microsoft link to SCO. En: News.com, marzo 11 del 2004. Disponible en: http://news.com.com/Investment+firm+confirms+Microsoft+ link+to+SCO/2100-7344_3-5172426.html —consultada el 30 de agosto del 2004—.

(37) Shankland, S. SCO sues Big Blue over Unix, Linux. En: News.com, marzo 6 del 2003: “Analysts saw the move as a desperate one for SCO, a company that hasn’t been profitable in its current incarnation. ‘It’s a fairly end-of-life move for the stockholders and managers of that company,’ said Jonathan Eunice, an Illuminata analyst. ‘Really what beat SCO is not any problem with what IBM did; it’s what the market decided. This is a way of salvaging value out of the SCO franchise they can’t get by winning in the marketplace”. Disponible en: http://news.com.com/2100-1016_3-991464.html?tag=st_rn.