I.-Introducción. La licencia de uso:

Si entendemos al software como un bien inmaterial sujeto a los derechos de propiedad intelectual, su autor, a los efectos de su explotación, tiene dos opciones básicas. O cede la titularidad de los derechos de económicos derivados de su condición de autor (cesión de derechos) o autoriza a los terceros el uso y goce del bien producido. En este caso nos encontraremos frente una licencia de uso.

La licencia de uso es el contrato por el cual titular de un software transfiere a la otra parte, la licenciataria, el uso y goce de sobre el programa.

Desde el punto de vista contractual, no implica la transmisión de un derecho ni produce el cambio de titularidad en forma total o parcial. El productor de software conserva las acciones derivadas de su titularidad, así como la facultad de otorgar a otros la explotación salvo que la hubiera otorgado con exclusividad[i] [2].

El contrato de licencia es un contrato innominado, dependiendo su contenido de las estipulaciones establecidas por las partes. Tradicionalmente, las mismas otorgan al usuario la posibilidad de utilizar el programa tal cual fue entregado, prohibiendo la modificación del mismo. Tales licencias se conocen como propietarias.

Históricamente, la introducción de las licencias propietarias se produce en la década de 1970. En dicho período, las empresas de informática comienzan a separar sus unidades de negocios según que las mismas se dediquen a la producción de software o hardware. Si con anterioridad los programas de computación se consideran accesorios a un contrato de desarrollo de un sistema, la evolución técnica hacia sistemas de menor costos y mayor difusión hizo que el software se obtuviera un valor económico por si mismo, el cual era necesario proteger para su comercialización. De esta forma, las licencias propietarias impedían la modificación y distribución de los programas por parte de los usuarios, asegurando al desarrollador la exclusividad de su explotación.

Sin embargo, nada impide que el autor del software lo licencie de forma tal que el propio usuario tenga la posibilidad de modificar el programa y redistribuir la nueva versión. Este tipo de licencia se conoce como licencia de Software Libre o de Código Abierto.

Debe tenerse en cuenta que el carácter gratuito o no de la licencia no es un elemento definitorio en la distinción. Una licencia puede prohibir la modificación del programa y sin embargo distribuirse en forma gratuita o mediante un pago de carácter voluntario. Tal es el caso del Freeware.

        Técnicamente, la posibilidad de modificación del programa se relaciona directamente con la posesión del código fuente. El concepto de código fuente y objeto se deriva de la forma en la cual se produce un programa de computadora. Habitualmente, el software se escribe en un lenguaje formalizado accesible para el programador, conocido como lenguaje de alto nivel[ii] [3]. Este lenguaje, si bien facilita el trabajo del informático, no puede ser entendido por la computadora, siendo necesaria su traducción. Esta tarea se realiza mediante un compilador, que toma el archivo con las instrucciones elaboradoras con el programador y lo convierte en un nuevo fichero, cuyo contenido es ejecutable por el ordenador pero ininteligible para el usuario. El primer archivo recibe el nombre de código fuente mientras que el segundo se denomina código objeto.

De lo expuesto surge claramente que, para modificar el programa original, el usuario necesita el archivo de código fuente, toda vez que el código objeto no permite su alteración por el usuario.

II.- Software Libre y Código Abierto Diferenciaciones ideológicas:

Si habitualmente se utiliza la expresión de software libre y código abierto como sinónimos, en verdad, ambos términos denotan concepciones técnicas, filosóficas y legales, que si bien son similares, presentan diferencias notables.

El término Software Libre tiene su origen en el manifiesto producido por Richard Stallman en el año 1986, conocido con el Manifiesto GNU[iii] [4]. En dicho texto desde el punto de vista técnico se planteaba la necesidad de desarrollar un sistema operativo alternativo al Unix[iv] [5]. Desde el punto del licenciamiento, Stallman introduce la licencia GPL, la cual plantea una inversión de los derechos del desarrollador a los efectos de asegurar la libertad de los usuarios la libertad para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software.

Detrás del manifiesto, el movimiento mantiene un componente ideológico bien determinado basado en la cooperación y la libertad de acceso a la información y el software, que lleva a negar toda restricción a la circulación de copias de productos intelectuales, en general y de los programas de computación en particular[v] [6]. Este presupuesto de libertad de acceso y conocimiento es fundamental para el movimiento y es el real significado de la expresión "Software Libre"[vi] [7] utilizada por los adherentes.

Esta postura ha levantado críticas desde sectores económicos más tradicionales, los que entienden que los presupuestos de Stallman se contraponen a los preceptos económicos básicos y al propio derecho del desarrollador de obtener un beneficio económico de su labor[vii] [8]. Ello ha llevado a una reticencia por parte de las empresas a adoptar los principios del movimiento.

Parcialmente en respuesta a esta reserva, en 1997, Eric Raymond publica un ensayo titulado "La Catedral y el Bazar"[viii] [9], en el que analiza los procesos de desarrollo tradicionales, basados en la concentración de las responsabilidades en un grupo reducido de desarrolladores, en contraposición con el modelo implementado en el desarrollo del kernel[ix] [10] Linux, en la que comunidad de usuarios participa activamente en la detección de errores y elaboración de soluciones. Este último aparece como un nuevo de paradigma de desarrollo, que logra resultados en situaciones donde los métodos tradicionales fracasan[x] [11].

Del análisis de ambos textos, surge una diferencia sustancial entre las posturas de sus autores. Raymond plantea la necesidad de libertad de acceso al código fuente por parte de la comunidad, no ya desde el punto de vista político sino como garantía de la elaboración de software de alta calidad[xi] [12].

        Al mismo tiempo, el proceso de evaluación y solución propugnado tiene por condición esencial la participación de la mayor cantidad de personas posibles. Para ello, es imperativo que las barreras establecidas por el autor del software frente a los usuarios se mantengan en un mínimo. Estas consideraciones llevaron a Raymond a mantener una actitud crítica respecto de la licencia GPL, a la que encuentra demasiado restrictiva[xii] [13].

Desde el punto de vista de las definiciones, Raymond prefiere la utilización del término "open source software", expresión que denota un mayor énfasis técnico que la terminología empleada por Stallman[xiii] [14].

            III.- El software Libre: las licencias GPL y sus variaciones.

De ambas posturas ideológicas, el Software Libre aparece como la más estructurada desde el punto de vista contractual. La licencia GPL se ha convertido en la más popular forma de licenciamiento y ha evolucionado con el tiempo, encontrándose en la actualidad en su tercera versión[xiv] [15].

Tal como han manifestado sus autores, la licencia tiene por objeto habilitar a los usuarios a las siguientes libertades básicas:

1. De usar el programa
2. De estudiar cómo funciona el programa, y adaptarlo a las necesidades de usuario.
3. De distribuir copias.
4. De mejorar el programa y hacer públicas las mejoras.[xv] [16].

Formalmente, se divide en tres elementos bien diferenciados: Un preámbulo, que expone los principios del movimiento, los términos y condiciones y un apéndice que instruye a los desarrolladores sobre como incorporar a sus programas la licencia GPL.

El preámbulo funciona como una introducción, y deja en claro las intenciones de los términosfree software y copyleft. En tal sentido, se explicita que el término free[xvi] [17] se relaciona con la libertad concedida al usuario para distribuir y modificar el programa y no  por el carácter gratuito del mismo. Al mismo tiempo, establece el concepto de copyleft, como aquellas restricciones en cabeza del usuario creadas con el fin de asegurar la libre distribución de los programas licenciados.

III.a.- Términos y Condiciones de la GPL version 3

Ámbito de aplicación

El ámbito de aplicación de la licencia debe ser definido en un doble sentido. Desde el punto de la aceptación, es necesario analizar cuales son las acciones que implican la conformidad con la misma. En segundo lugar, debe precisarse cuáles son los componentes de cada distribución que la licencia cubre.

En principio general, la aceptación de la licencia se produce con la distribución del programa, ya sea en forma original o habiendo producido un trabajo derivado del mismo. Debe tenerse en cuenta que los usuarios no se encuentran obligados a aceptar la licencia para los casos en que su interacción con el programa distribuido se limite a la utilización del mismo o cuando la modificación del mismo no derive en una nueva distribución.

Excepcionalmente, la licencia permite la entrega material del programa a terceros siempre y cuando los mismos actúen por órdenes y en beneficio exclusivo del usuario. En realidad, en tal caso no es posible hablar de distribución, toda vez que los terceros funcionan jurídicamente como una extensión del usuario original, quien los dirige en su propio interés.

Con respecto al objeto de la licencia, alcanza a todo el programa distribuido, pero excluye a los complementos que, si bien pueden interrelacionarse con el software, no se encuentran incluidos en el mismo en su propio diseño. Sobre el tema volveremos al analizar la obligación impuesta por el punto IV de la licencia de entregar el código fuente.

Distribución del software

Uno de los derechos básicos que otorga la licencia es el de distribuir el programa siempre que se cumplan las condiciones establecidas en la misma. En tal sentido, se mantiene una neutralidad tecnológica respecto al método de transmisión, pudiendo hacerse tanto en forma digital como en soporte físico.

A dichos efectos, el punto 4 permite la distribución sin modificaciones del programa original siempre y cuando se cumplan las siguientes condiciones.

a.- Se deje establecido el copyright original del programa, estableciendo los autores del mismo.

b.- Se respete la forma de licenciamiento del programa a distribuir, así como las cláusulas adicionales permitidas por la GPL, si las hubiere.

c.- Se explicite la inexistencia de garantías establecida por el punto 15 de la licencia.

        d.- Se acompañe una copia de la licencia junto con el programa.

Debe tenerse en cuenta que el distribuidor se encuentra facultado para cobrar por la distribución de así considerarlo conveniente.  En tal sentido, la licencia no impone restricciones respecto a los montos o formas de pago que tal operatoria puede utilizar[xvii] [18], siempre que las mismas no limiten la posterior distribución del programa en los términos de la licencia [xviii] [19].

Es importante señalar que la distribución del programa otorga al tercero receptor una licencia por parte de los autores originales del programa y no del distribuidor. De esta forma, las acciones derivadas por el incumplimiento de las cláusulas contenidas  siempre permanecen en cabeza de los primeros, con prescindencia de la forma de adquisición del software[xix] [20] por parte del infractor.

            Modificación del software

            Otra de las libertades básicas de la licencia de software libre es el derecho de los licenciatarios para modificar el programa, adecuándolo a sus necesidades o simplemente optimizándolo. Esta actividad no genera efectos jurídicos de importancia mientras que la modificación no sea distribuida, tal como analizáramos en ocasión de tratar el tema de la aceptación.

            Sin embargo, si se opta por la distribución de un programa modificado, el licenciatario se encuentra sujeto a una serie de condiciones contempladas en el punto 5 de la licencia. En función de ello, es necesario que el trabajo modificado cumpla los siguientes requisitos:

1-      Debe establecerse claramente que el trabajo es una distribución modificada del original, estableciendo asimismo la fecha de modificación.

2-      Debe notificarse que el trabajo se encuentra distribuido bajo la licencia GPL, como asimismo debe explicitarse cualquier término adicional establecido.

3-      En el caso de la existencia de interfaces interactivas debe dejarse en claro los términos de licenciamiento en las mismas.

El programa modificado debe distribuirse como un todo bajo la licencia GPL, aún en los casos en que el mismo se encuentre compuesto por elementos que se hayan licenciado bajo términos diferentes. Excepcionalmente, y en los casos que los componentes se encuentren distribuidos en una compilación pero manteniendo su independencia funcional, los mismo pueden ser licenciados bajo términos diferentes.

            Desde el punto de vista del derecho de propiedad intelectual, la obra resultante constituye un trabajo derivado del original, en los términos del art. 4 inc. C de la ley 11.723. Una obra derivada puede ser definida como aquella que depende de un trabajo preexistente, concepto tradicionalmente aplicado a las traducciones o adaptaciones de obras literarias, así como a los resúmenes y extractos de obras científicas[xx] [21].

            Es el propio art. 4 el que condiciona a los autores de obras derivadas a solicitar la autorización del autor original[xxi] [22].  En el caso de la GPL, la autorización se encuentra contenida en el punto 6 de la licencia siempre sujeta a las condiciones establecidas en la misma.

Cumplido este requisito, el autor del trabajo modificado obtiene el derecho de autor sobre éste pero no una exclusividad: El art. 26 de la 11.723 establece que si bien el autor del trabajo modificado se encuentra protegido por la ley, ello no impide que otros terceros realicen sobre el trabajo original nuevas obras  derivadas. Asimismo debe tenerse en cuenta que los derechos se conceden exclusivamente sobre la nueva obra y no afectan los consagrados para el programa original.

Acceso al Código Fuente

En los términos de la licencia,  concepto de código fuente incluye aquellas instrucciones necesarias para generar, instalar y ejecutar el código objeto de un programa determinado. Sin embargo, no incluye las librerías del sistema ni utilidades externas al programa en sí, las que pueden estar vinculadas al mismo, pero no modificadas por este.

Un problema derivado de la nueva redacción de la licencia es utilización del término "bibliotecas compartidas", en particular las llamadas librerías dinámicas. Estas son archivos que contienen código que a menudo es usado por más de un programa simultáneamente, los cuales se limitan a llamar a las funciones de las mismas, sin incorporarlas a su texto. Atento su definición si bien funcionan interrelacionadas con el programa licenciado, son independientes del mismo y fue tradicionalmente debatido si la utilización de las mismas constituían un trabajo derivado en los términos de la GPL[xxii] [23].

La solución establecida por la GPL versión 3 resulta acorde con la postura de la FSF al respecto[xxiii] [24].  Así la licencia determina que se considerará a la biblioteca como parte del trabajo derivado en los casos en que el programa "se encuentre específicamente diseñado para funcionar" con dicha librería[xxiv] [25].

Por tanto aparece como necesario para mantener la independencia del software creado la existencia de librerías alternativas a la licenciada bajo GPL, de forma tal que las funciones de las misma se intercambiables[xxv] [26].

La forma de distribución del código fuente queda establecida en el punto 6 de la licencia y presenta algunas diferencias con la versión 2, las cuales, en lo fundamental, prevén circunstancias relacionadas con los cambios tecnológicos producidos entre ambas.

Como principio general, el código fuente debe estar disponible en los casos de distribución del ejecutable.

En los casos de trasmisiones de copias individuales, las mismas deben, en principio, acompañar el código fuente. Excepcionalmente, y solamente con fines no comerciales, es posible acompañar el código objeto con una oferta escrita de proporcionar el fuente correspondiente. 

En los casos de distribución digital, el acceso al fuente puede hacerse en el mismo servidor o uno distinto, siempre en cuando las condiciones de acceso sean similares a las utilizadas para distribuir el código objeto.

Una previsión incorporada por la versión 3 es la hipótesis de que el programa sea distribuido como parte de un producto comercial, el cual utilice el software licenciado para su funcionamiento. Esta previsión generó controversias atento la utilización del Linux en productos de consumo masivo, en particular la grabadora de televisión TiVo, los cuales impedían la modificación del programa de funcionamiento restringiendo la posibilidad de correr las versiones derivadas[xxvi] [27].

 En tal caso, el fabricante asume el compromiso de distribuir el código fuente, ya sea mediante la descarga de la versión digital en forma gratuita o el envío de un soporte físico, hipótesis en la que el distribuidor puede solicitar el pago de los gastos. Este compromiso debe extenderse por el plazo de tres años o mientras el distribuidor ofrezca soporte para el producto[xxvii] [28]. Dentro de esta previsión deben incluirse las distribuciones físicas del programa. 

Por último, en el caso de distribuciones peer to peer, es obligación de quien realiza la transmisión informar la forma en que se pueda tener acceso tanto en fuente como al objeto en los términos del párrafo anterior.

Copyleft: restricción de licenciamiento de las obras derivadas.

El copyleft es definido por la FSF como el método de lograr que un programa sea libre, requiriendo que todas sus distribuciones y trabajos derivados mantengan tal carácter[xxviii] [29].

Si tal como habíamos sostenido es necesaria la autorización del autor para la realización de una obra derivada, la misma puede ser otorgada sujeta a condiciones, en forma tal que su incumplimiento de conlleva la perdida de la venia conferida.

En el caso de la GPL, los derechos otorgados a los licenciatarios del programa original, quedan sujetos a la condición de que los mismos otorguen similares libertades al momento de la nueva distribución.

Por lo tanto un programa sujeto a Copyleft no puede modificarse ni distribuirse a menos que se haga bajo los términos y condiciones de la GPL, y cualquier modificación a los términos autorizados por esta última extinguirá los derechos surgidos de la licencia. Jurídicamente, funciona como una "condición resolutoria" que subordina la resolución de un derecho adquirido a un hecho incierto y futuro. [xxix] [30]

La existencia del copyleft marca la diferenciación sustancial entre los programas que se encuentran en el dominio público y aquellos sometidos a la licencia de software libre. En estos últimos siguen persistiendo los derechos de autor, que quedan en cabeza del licenciatario original, quien renuncia a los derechos de explotación económica exclusiva de lo creado, sujeto a la condición que los trabajos derivados realicen una similar resignación[xxx] [31]

Por lo tanto la vulneración de alguna de las cláusulas analizadas anteriormente, como ser el acto de añadir nuevas restricciones no previstas, conlleva la revocación de la autorización conferida, la que deja de ampararle al licenciatario y su  trabajo derivado, el cual entonces resulta violatorio de los derechos del autor del trabajo original.

Cláusulas adicionales

Las cláusulas adicionales se encuentran reguladas en el punto VII y son una incorporación de la versión 3 de la GPL. Su objetivo es impedir la creación de otras restricciones distintas a las establecidas por la licencia. Dicha enumeración tiene un carácter restrictivo, por lo que solo se permiten las siguientes estipulaciones:

        1.- Establecer garantías diferentes a las establecidas en el punto 15 de la licencia.

        2.- Requerir la preservación de los avisos legales o de autoría contenidos en el programa.

        3.- Solicitar que las diferencias respecto a la versión original sean señaladas de forma apropiada en las versiones modificadas

4.- Limitar el uso de los nombres de los autores originales o licenciatarios para fines publicitarios.

5.- Negarse a otorgar derechos afectados por la legislación de marcas comerciales.

6.- Prever la Indemnización de los autores o licenciatarios por las distribuciones del programa por parte de terceros que incluyan cláusulas contractuales que impliquen responsabilidad para los primeros. 

La aplicación de las dichas cláusulas puede realizarse sobre todo el programa distribuido o sobre parte de él. En el primer caso, se entenderá que las cláusulas se encuentran incluidas en la licencia, mientras que en el segundo, las partes afectadas se consideraran independientes del programa principal, el que se seguirá rigiendo por lo estipulado por la licencia general.

Las Patentes de Software

La patente es un mecanismo de protección otorgado por el estado a un particular autor de una innovación tecnológica, por el cual se concede un derecho a la exclusividad a la explotación por un tiempo finito, a cambio de la publicidad del misma.

Estos derechos se otorgan por cada estado en particular y mantienen a la fecha un carácter marcadamente territorial. Cada estado tiene distintos estándares para otorgar cada patente, en particular en lo que respecta a la patentabilidad del software.

Tradicionalmente, el software como obra intelectual se encuentra protegido por las leyes de derecho de autor. En la República Argentina los programas de computadora fuente y objeto se encuentran incluidos dentro la enumeración del art. 1 de la ley 11.723. Del mismo modo, la ley 24.481, que regula las patentes de invención, excluye en su art. 6 al software como invención pasible de registro[xxxi] [32].

Sin embargo, algunos países han admitido el patentamiento de los procedimientos realizados mediante un computador, arguyendo que los mismos constituyen una innovación tecnológica similar a cualquier otro proceso industrial.

Debe tenerse en cuenta que a diferencia de los derechos de autor, la patente otorgada no protege el progama de computadora si  sino el método tendiente a la obtención del resultado, por ejemplo, la forma de compresión de los datos en un archivo de video. Consecuencia de ello, la posibilidad de un software alternativo que cumpla la misma funcionalidad sin recaer en la ingeniería inversa, seria igualmente violatoria de la patente otorgada, toda vez que realizaría el mismo proceso, con prescindencia de que se haya o no apropiado del código[xxxii] [33].

En Estados Unidos de América, el primer antecedente jurisprudencial de patentabilidad del software fue el caso "Gottschalk v. Benson" resuelto por la suprema corte de Justicia en el año 1972. En el año 1963, Bell Laboratories presentó un pedido de patente en favor de dos de sus empleados (Benson y Talbott) para la protección de un método de traducción de números expresados en código binario decimal a binario. La petición fue rechazada y el conflicto fue llevado hasta el maximo tribunal estadounidense, quien ratificó la negativa argumentando que el modelo propuesto no constituía un proceso sino simplemente un algoritmo matemático y no era suceptible de ser protegido por el derecho industrial[xxxiii] [34].

Sin embargo, dicho criterio fue modificado por la Corte de Apelaciones de Patentes en los casos"Freeman" y "Diehr". De la doctrina de ambos fallos surge que la interpretación de judicial del fallo Benson debe ser entendida en un sentido restrictivo, permitiendo no solo el patentamiento de invenciones en el sentido clasico del término que incorporen en su diseño programas de computadoras sino asimismo los algoritmos matematicos que constituyan procesos innovadores cuando estos constituyan una aplicación practica [xxxiv] [35]. Esta postura tuvo su consagración en el año 1994 en el caso Alappat[xxxv] [36], donde el tribunal federal de apelaciones admitió la posibilidad de patentar un procedimeinto de tratamiento de gráficos por computadora, poniendo fin a la discusión si los programas de computadores per se y con independencia  ser parte de un procedimiento de transformación del mundo fisico, podian ser objeto de patentes.

La aceptación de las patentes de software ha sido en los últimos años objeto de una fuerte polémica, no solo en los países que las han admitido sino incluso en aquellos en los que no[xxxvi] [37]. La mayoría de las objeciones se fundamentan en la concentración de  las licencias en cabeza de las grandes corporaciones, en detrimento de las Pymes y programadores independientes, los que se verían impedidos de ingresar en el mercado, atento los costos derivados del licenciamiento y los posibles riesgos judiciales.

La versión 3 de la GPL da recepción al problema en el punto 11, estableciendo una cesión de al patente expresa por parte de los licenciatarios. Puesto en términos simples significa que si un desarrollador distribuye un programa bajo los términos de la licencia, otorga a los receptores una licencia no exclusiva de todas las patentes que, respecto al programa, pudiera ser titular[xxxvii] [38].

En el mismo sentido, y en los casos en que el distribuidor haya celebrado un convenio de utilización de patentes que sean titularidad de un tercero deberá extender dicho beneficio a los usuarios posteriores o abstenerse de distribuir el trabajo derivado. Esta cláusula intenta evitar los acuerdos como el celebrado por las empresas Microsoft y Novell en el año 2006, el cual protege de los reclamos por infracción a la ley de patentes solo a la distribución de Linux realizada por la última empresa, sin que esta licencia se extienda al resto de las distribuciones del sistema operativo[xxxviii] [39].

Gestión de Derechos Digitales (DRM) y licencias GPL versión 3

Se denomina gestión de derechos digitales (DRM según su abreviatura en ingles) al conjunto de tecnologías que permiten restringir el uso de medios o contenidos digitales a aquellas actividades permitidas expresamente por el titular del copyright. Estas tecnologías pueden estar incluidas en el contenido mismo, en el sistema operativo o incluso en el hardware usado para su reproducción.

Técnicamente, los DRM utilizan dos sistemas para asegurar los contenidos. La primera es la restricción, consistente en aplicar un algoritmo criptográfico al contenido, evitando que los usuarios no autorizados accedan al mismo. El segundo es la aplicación de un "sello de agua"  al archivo de forma tal de poder comunicar al hardware que el contenido se encuentra protegido. Ambos casos son susceptibles de acceso no autorizado (hacking) con el fin de eliminar las limitaciones impuestas.

Es por ello que, desde el punto de vista legal, los impulsores de las tecnologías han insistido en la necesidad de penalizar los métodos que permitan evitar las restricciones establecidas por el DRM[xxxix] [40]. Es así que el tratado de la OMPI del año 1996. El acuerdo aconseja a los países signatarios a adoptar una protección jurídica "contra la neutralización (elusión) de medidas técnicas eficaces que son aplicadas por los autores en el marco del ejercicio de sus derechos en virtud del presente tratado o del Convenio de Berna y que, respecto de sus obras, restrinjan actos que no estén autorizados por los autores concernidos o permitidos por la ley"

Esta recomendación fue receptada por la mayoría de los países centrales, es así que la directiva comunitaria 2002/29/CE de mayo de 2002, que en su art. 6.1 que "los Estados miembros establecerán una protección jurídica adecuada contra la elusión de cualquier medida tecnológica efectiva, cometida por una persona a sabiendas, o teniendo motivos razonables para saber que persigue ese objetivo". Más adelante, el art. 6.3 de la misma directiva entiende por "medidas tecnológicas toda técnica, dispositivo o componente que, en su funcionamiento normal, esté destinado a impedir o restringir actos referidos a obras o prestaciones protegidas que no cuenten con la autorización del titular de los derechos de autor o de los derechos afines a los derechos de autor establecidos por ley". En similares términos la Digital Millennium Copyright Act del año 1998 prohibe la elusión de los métodos de control de contendios digitales en su titulo primero[xl] [41].

Los sistemas de DRM han sido objeto de numerosas críticas. Desde el punto de vista de la privacidad, muchos de los sistemas requieren de los usuarios una identificación previa al acceso de los contenidos, excediendo de este modo el mero control de los derechos intelectuales y generando un perfil del propio usuario[xli] [42].

Asimismo, los desarrollos tienden a avanzar sobre los derechos de los propios usuarios consagrados por la legislación de propiedad intelectual. La mayoría de los sistemas restringen la capacidad técnica de migrar el contenido hacia otros ordenadores propiedad del mismo usuario, así como la utilización de otros sistemas operativos alternativos. De la misma forma, las soluciones adoptadas no discriminan respecto a las excepciones de acceso al material consagradas en la legislación como la utilización con fines didácticos o de investigación.

La versión 3 de la GPL regula los DRM en su punto 3. Al respecto, limita la aplicación del convenio OMPI del año 1996, así como otra legislación que en concordancia con este se dicte. Así, la distribución de un software bajo esta licencia implica la renuncia a la persecución de la elusión de los métodos de control de contenido establecidos en el software licenciado.

Esto reviste particular importancia en coordinación con el punto 6 de la licencia. Atento la obligación de permitir el acceso al código fuente e instalación de software modificado en los productos de consumo que incluyan software licenciado, los usuarios podrían eludir limitaciones de uso establecidas en los dispositivos sin que ello implique una violación a lo establecido por el acuerdo OMPI.

Compatibilidad con otras licencias GPL

La licencia GPL 3 no esta diseñada para reemplazar a las versiones anteriores, por lo que los distribuidores pueden optar por licenciar su código mediante la versión que deseen.

La mayoría de los programas licenciados bajo la versión 2 permiten a los usuarios la posibilidad de modificar los términos de licenciamiento, adoptando la versión 3 de así considerarlo conveniente. Sin embargo es de hacer notar que algunos proyectos limitan esta opción, obligando a permanecer bajo la licencia del año 1991. El caso más notable es el kernel Linux, cuyo autor, Linus Torvalds ha sido particularmente crítico de la nueva versión[xlii] [43]. Circunstancias ha llevado al fenómeno de que un mismo sistema operativo se encuentre distribuido mediante dos versiones diferentes de la misma licencia.

III.-b Otras Licencias GPL

Además de la GPL, la Free Software Fundation promueve otras dos licencias: La denominadaLesser General Public License (LGPL) y la Affero General Public License (AGPL).

Tal como analizáramos en oportunidad de tratar el tema del código fuente, la utilización de librerías dinámicas presenta un problema cuando estas se encuentran licenciadas bajo los términos de la GPL, ya que las mismas obligan al programa principal a aceptar estos términos de distribución[xliii] [44].

La licencia LGPL[xliv] [45] aporta una solución al permitir la distribución tanto de la librería como del programa principal bajo términos  independientes. Así, el punto 4 permite la distribución de un trabajo combinado que incluya librerías licenciadas junto con el programa principal, siempre y cuando se cumplan las siguientes condiciones.

1.- Se deje constancia de la existencia de las librerías y su forma de licenciamiento. Esta noticia debe repetirse en la interfaz de usuario en el caso de que la misma incluya notas de copyright.

2.- Acompañar la distribución con una copia de la licencia así como de la GPL.

Con respecto a la obligación de acompañar el código fuente, la licencia la obligación se satisface liberando la parte del código correspondiente a la librería incorporada, eximiendo al distribuidor de incluir el correspondiente del resto del trabajo combinado. Debe tenerse en cuenta que por fuente se entiende toda la información necesaria para modificar la librería e incorporarla al aplicativo principal.

La GNU Affero GPL (AGPL)[xlv] [46] es, en cambio, una licencia destinada a licenciar los programas que utilizan una estructura cliente servidor, típica de las aplicaciones que corren en una red de computadoras.

En términos de su estructura, la AGPL es similar a la GPL versión 3, con la inclusión de un párrafo como punto 13 de la licencia titulado Interacción con redes remotas. Allí se establece el derecho de los usuarios que interactúen mediante una red con el programa licenciado de obtener una copia del código fuente del mismo, la que debe ser puesta a disposición en un servidor libre de cargo alguno.

La compatibilidad de esta licencia con la GPL ha sido objeto de analisis. Si bien la misma es una licencia oficial de la Free Software Fundation, establece un conjunto de requisitos que la hacen incompatible con la versión 2 de la licencia principal.

La versión 3, en cambio, prevé en su punto 13 la expresa posibilidad de combinar código distribuido bajo esta licencia con programas sujetos a la AGPL. En tales casos, las previsiones de esta última se aplican a todo los programas distribuidos, con prescindencia de su régimen de licenciamiento. De esta forma, la utilización de software licenciado en los términos de la GPL en conjunción con código distribuido bajo licencia Affero, obliga al titular del servidor a poner a disposición de los usuarios remotos la totalidad del código fuente.

            IV.- Open Software Initiative: Programa de Certificación y Condiciones

            A diferencia de los propulsores del software libre, los miembros de la Open Source Initiative no promueven una licencia única sino un programa de certificación de licencias de terceros, las cuales deben cumplimentar los criterios establecidos por la inicitiva. Estos son:

1. Libre redistribución: la licencia no debe impedir a nadie la venta o entrega del software ni requerir derechos de autor u otros pagos por tal venta;

2. Código fuente: el programa debe incluir el código fuente, y la licencia permitir la distribución del programa tanto en su versión fuente como en su forma compilada;

3. Obras derivadas: la licencia debe permitir la realización de modificaciones u obras derivadas y su distribución bajo los mismos términos de la licencia original;

4. Integridad del código fuente del autor: la licencia puede impedir que el código fuente sea distribuido en su versión modificada sólo si permite la distribución de los "parches" (patch files) con el código fuente, con el propósito de modificar el programa en tiempo de construcción. Debe permitir la distribución de software sobre la base de código fuente modificado y puede exigir que las obras derivadas lleven un nombre o número de versión distinto al programa original;

5.  No discriminación contra persona o grupos de personas;

6.  No discriminación contra campos de aplicación: la licencia no puede, por ejemplo, impedir el uso del programa en negocios;

7.  Distribución de la licencia: las facultades concedidas deben ser aplicadas a todas las personas a quienes se redistribuya el programa, sin necesidad de obtener una licencia adicional;

8. No especificidad de la licencia con relación a un producto: los derechos aplicados a un programa no deben depender de la distribución particular de software de la que forma parte;

9. No restricción de la licencia con relación a otro software: la licencia no debe imponer restricciones sobre otro software que es distribuido junto con el licenciado. Por ejemplo, la licencia no debe insistir en que todos los demás programas distribuidos en el mismo medio deben ser software de fuente abierta;

10. Neutralidad tecnológica de la licencia: ninguna de sus estipulaciones puede estar basada en un tipo de tecnología determinado o estilo de interfaz.[xlvi] [47]

         Toda licencia que cumpla con las condiciones establecidas puede solicitar la certificación de la OSI, la que someterá el pedido a discusión pública, antes de tomar la decisión. En caso que el pedido sea aprobado, la licencia se incorporará al sitio web de la organización y podrá utilizar la marca Open Source Certified.

        El objetivo de la certificación es permitir diferenciar las licencias que son realmente open source, logrando una mayor previsibilidad respecto de los alcances de las mismas. En la actualidad aproximadamente el diez por ciento del software licenciado se hace bajo licencias certificadas, en particular bajo las licencias Apache 2.0 y BSD 2.0[xlvii] [48].

Una diferencia sustancial con la licencia GPL es la ausencia de Copyleft. En tal sentido, ni las condiciones de certificación ni  ninguna de las licencias mencionadas en el párrafo anterior prohíbe al autor de un trabajo modificado la distribución del software bajo una licencia que establezca mayores restricciones, habilitando por tanto la posibilidad de comercializar el producto resultante como software propietario.

V.- Conclusiones:

Los aspectos legales  de la distribución del software han ido evolucionando influenciados tanto por factores técnicos como económicos e incluso ideológicos.

La introducción de las licencias no propietarias plantea un cambio en los términos de la ecuación de negocios de los desarrolladores, imponiendo en énfasis en la provisión de servicios en detrimento de la percepción de los beneficios por la exclusividad de la explotación del trabajo intelectual.

En tal sentido, las modificaciones establecidas por la versión 3 de la licencia GPL actualizan el debate respecto de las restricciones al acceso de la información impuestas en beneficio de los titulares de derechos. La relación dialéctica entre la necesidad de asegurar la innovación tecnológica y el derecho de la sociedad ha obtener beneficios de la misma lleva a la generación de modelos contractuales como los analizados, lo cuales, lejos de ser permanentes, se encuentra en un constante estado de cambio.