052.1 Lección 1

El software libre y de código abierto existe desde hace bastante tiempo y los términos a menudo se ven juntos. Sin embargo, existe cierta discrepancia entre lo que algunos declaran ser "software libre" y el significado formal de software libre, así como software de código abierto. Spoiler: “Código abierto” no significa simplemente que cualquiera pueda ver el código fuente; eso sería software “Fuente disponible”. El software libre y de código abierto es mucho más que eso. El software libre y de código abierto se contrasta con otros tipos que se consideran propietarios o de código cerrado porque no ofrecen todas las libertades analizadas en esta lección.

Quizás la definición de software libre más citada sea:

Analizaremos esa declaración en las siguientes secciones.

Por un lado, los desarrolladores pueden decidir simplemente renunciar a las recompensas y dificultades de vender su software y simplemente regalarlo sin compensación. En inglés este software es “gratuito” en el sentido de que nadie tiene que pagar por él, pero es gratuito sólo como la cerveza que se regala. Esta distribución gratuita no dice nada sobre otras condiciones de licencia y deja al usuario con la obligación de mirar siempre más de cerca: es posible que, por ejemplo, no se le hayan concedido los derechos necesarios para modificar o distribuir más el software.

Por otro lado, los desarrolladores pueden optar por hacer que su software sea “software libre” en el sentido de Stallman. Este término (adoptado en la década de 1980) se refiere a las libertades esenciales del usuario que se resumen a continuación:

El “software libre” en esta definición es defendido por la Free Software Foundation (FSF), que introdujo el término copyleft (que no tiene significado legal, pero presenta una consideración filosófica) que caracteriza la licencia de software libre.

A partir del movimiento del software libre, los defensores del código abierto surgieron a finales de los años 1990 como una forma de hacer que el software libre fuera más fácil de comprender y más popular entre las personas ajenas al movimiento. En 1998 se fundó una fundación sin fines de lucro, la Open Source Initiative (OSI), y Linus Torvalds, autor inicial del kernel de Linux, dio su apoyo al concepto. La Iniciativa de Código Abierto formalizó la Definición de Código Abierto para incluir los siguientes criterios:

La Free Software Foundation no respaldó el término “Código abierto” (Open Source en Inglés), insistiendo en que oculta el objetivo clave de la libertad. Así que si bien los defensores del software libre y del software de código abierto parecen perseguir y defender el mismo concepto, los movimientos tienen motivaciones distintas. Dicho de forma simplificada, los defensores del software libre enfatizan los derechos de los desarrolladores y usuarios, mientras que los defensores del código abierto priorizan el uso generalizado y el éxito del software.

Prácticamente todo el software libre se considera de código abierto, mientras que hay muchas licencias que se consideran de código abierto (aprobadas por OSI) pero que no son libres según la FSF.

Debido a que las diferencias entre código libre y código abierto se refieren a objetivos y motivaciones más que al contenido de las licencias, y dado que ambos términos siguen siendo de uso frecuente, muchos defensores se refieren a ambas definiciones juntas usando las frases software libre y de código abierto (FOSS) o free/libre y Open Source Software (FLOSS). El término “libre” se refiere a la libertad en muchas lenguas romances.

Además de las amplias categorías de software libre y software propietario, existe una variedad de otras estrategias de distribución. Algunas de estas estrategias son:

Primero y ante todo: Si no hay información de licencia disponible para un determinado archivo o proyecto de código fuente, no puede asumir que el archivo o proyecto carece de protección de derechos de autor. De hecho, ocurre todo lo contrario, al menos desde que la mayoría de las naciones del mundo firmaron el Convenio de Berna desde 1887.

En este tratado, las naciones firmantes acuerdan que una obra literaria o artística está protegida por derechos de autor tan pronto como existe (o en otras palabras, tan pronto como se “fija” en un soporte). Eso significa que un autor no tiene que registrarse ni solicitar derechos de autor. Todavía pueden hacerlo en algunos países, y el registro podría ser necesario para acciones de infracción en algunas jurisdicciones, incluido Estados Unidos.

Asimismo, los firmantes se comprometen a respetar los derechos de autor de cualquier autor de otro país firmante, que, a noviembre de 2022, ascendían a 181 de los 195 países del mundo.

Sin embargo, no todo lo que se ha creado está protegido por derechos de autor. Para calificarla como una obra protegida por derechos de autor, la creación debe satisfacer algunos criterios básicos: por ejemplo, los hechos y las ideas no pueden protegerse por derechos de autor, pero un texto que explica una idea puede protegerse si alcanza un cierto grado de originalidad. La medida de originalidad difiere en todo el mundo, pero en muchos casos, la barrera de protección es muy baja. Muchas jurisdicciones están considerando actualmente cuánta inteligencia artificial se puede utilizar para crear una obra que merezca originalidad y, por tanto, derechos de autor.

Dependiendo de la jurisdicción, los programas de ordenador están protegidos por derechos de autor como obras literarias: es decir, los derechos de autor no se aplican a la idea o algoritmo, sino a su implementación en el código fuente.

Los derechos de autor otorgan al autor los derechos exclusivos (entre otros) para copiar, modificar, sublicenciar, distribuir y publicar la obra. La recepción de la obra es gratuita, por lo que no se necesita licencia para leer un libro o escuchar una canción en la radio, siempre que para ello no sea necesario realizar una copia permanente.

Debido a que los derechos de autor surgen sin necesidad de registro, cualquiera que quiera copiar, modificar, sublicenciar, distribuir o publicar la obra de otro autor debe obtener permiso primero. Aquí es donde entran en juego las licencias, como contratos entre el autor de una obra y una persona que quiere ejercer algunos de los derechos exclusivos del autor.

Las licencias FOSS se ofrecen a cualquier persona sin pagar ninguna tarifa. Cualquiera puede crear su propia licencia e intentar que la OSI o la FSF la aprueben. Pero se recomienda encarecidamente utilizar una licencia FOSS existente debido a su aceptación general y a la familiaridad que los usuarios de software expertos tienen con el contenido de la licencia y sus obligaciones. De hecho, sólo un bloque de las muchas licencias aprobadas por la FSF o la OSI son de uso común.

A diferencia del copyright, que no protege las ideas, las patentes protegen las invenciones (ideas) sin necesidad de que la idea esté fijada (todavía) en una máquina o proceso. Otra diferencia es que los inventores deben solicitar patentes explícitamente y registrarlas en la oficina de patentes del país donde buscan la protección.

Sin profundizar demasiado en la ley de patentes y sus requisitos, sólo señalaremos una cuestión muy central: la protección de una patente requiere (entre otros criterios) una idea con un determinado aspecto técnico. Históricamente, las ideas para una nueva receta de comida o un nuevo juego de mesa no califican para la protección de patente, mientras que las ideas para una nueva máquina de cocinar o una consola de juegos sí pueden calificar.

En el contexto de la programación informática, surge la cuestión de si el software podría estar sujeto a protección por patente. Esto depende tanto de la jurisdicción legal como de la aplicación particular: Por ejemplo, en Alemania los programas de ordenador como tales generalmente están excluidos de la protección de patentes. Sin embargo, si los programas se combinan con un objeto físico (por ejemplo, cuando el software controla el sistema de frenado automático de un automóvil), se puede solicitar protección mediante patente para la aplicación que incluye el elemento físico del freno y no el software como tal, y podría por lo tanto calificar.

En otras jurisdicciones, como Estados Unidos, se pueden conceder patentes para programas informáticos como tales, dependiendo de la evolución de la jurisprudencia.

Al conceder licencias de software libre se debe tener presente el concepto de protección de patentes. Algunas licencias (como la GPLv3) permiten patentes sobre el software FOSS al otorgar permiso explícito para el uso del software. Pero algunas licencias ni siquiera mencionan las patentes (como la licencia BSD-3-Clause) y otras las excluyen explícitamente (como las licencias Creative Commons). Sin embargo, en determinadas circunstancias, la concesión de patentes puede estar implícita en la licencia o puede leerse en la licencia.

Especialmente cuando se trata de software integrado, como el software en dispositivos de audio, se debe prestar especial atención a las patentes relacionadas con el software, ejemplo, mediante la realización de controles de patentes de los autores del software.

Como se mencionó anteriormente, las licencias son contratos entre el autor de una obra y alguien que quiere ejercer algunos de los derechos exclusivos del autor. Algunas de las licencias FOSS más extensas, como las Licencias Públicas Generales GNU versión 2 y versión 3, incluyen disposiciones para la rescisión del contrato. Las licencias de software libre siempre incluyen concesiones de derechos con respecto a las libertades centrales. Normalmente, los siguientes derechos se indican o se pueden leer en el texto de la licencia:

Los administradores de licencias son personas o, en muchos casos, organizaciones como la FSF que gestionan las versiones de las licencias. Por ejemplo, la sección 9 de GPLv2 declara que la FSF es la administradora de licencias:

Algunos administradores de licencias también publican preguntas frecuentes (FAQ) para ayudar a responder preguntas sobre las licencias. Estos pueden resultar útiles para iniciar una conversación entre el licenciatario y el licenciante.

Cuando un grupo de desarrolladores incorpora código en su propio trabajo del proyecto de otra persona, el resultado puede ser un trabajo derivado. Los detalles varían de un proyecto a otro y de una licencia a otra, y debido a que los detalles requieren cierta sofisticación en las técnicas de desarrollo de software, simplemente diremos que los desarrolladores deben asegurarse de incorporar el código de una manera que se ajuste a la licencia.

La cuestión más importante con respecto a las obras derivadas es que, para algunas licencias como la GPL, una obra derivada debe publicarse bajo la misma licencia. Estas licencias se denominan recíprocas.

El significado práctico inmediato de un requisito recíproco es que, si utiliza código GPL en su propio proyecto de manera que el suyo sea una derivación, debe revelar su código fuente y dejar que otros construyan productos a partir de el. Este requisito de licencia es muy deseado por algunos desarrolladores que quieren animar a más personas a utilizar licencias gratuitas. Sin embargo, la licencia reduce el atractivo de la GPL para algunos desarrolladores que potencialmente podrían utilizar código libre.

Muchas otras licencias gratuitas y de código abierto no imponen ese requisito. Estas tienden a denominarse licencias permisivas.

Si, en el momento de la distribución, no se cumplen las condiciones de la licencia (ejemplo, si el software con licencia GPLv3 distribuido como binario no va acompañado de una oferta de código fuente), se viola el contrato de licencia. Las consecuencias de las violaciones de licencia dependen de la licencia. La violación de la licencia GPLv3, puede dar lugar a la rescisión de la licencia. Cualquier acción adicional que requiera permiso del autor, ejemplo, distribución del software, entonces constituyen violaciones de derechos de autor.

Si una empresa incluye software con licencia GPLv3 en un producto y viola la licencia, se puede presentar un reclamo exigiendo a la empresa que retire sus productos. Las violaciones intencionales de los derechos de autor pueden incluso dar lugar a cargos penales.

Algunas licencias tienen cláusulas específicas que permiten al licenciatario corregir la infracción dentro de los 30 días posteriores a la notificación. Si la persona que distribuye el software logra cumplir con la licencia dentro de este período, se restablece la licencia.

Los grandes proyectos de software a menudo incluyen software bajo diferentes licencias, cada licencia especifica sus requisitos individuales. Estos proyectos pueden tropezar con obstáculos al utilizar software que requiere que su licencia se utilice en trabajos derivados. Esto se debe a que los términos de licencia de dichas licencias copyleft pueden diferir, haciéndolas incompatibles. Es posible que no sea posible publicar o distribuir un proyecto de software que integre componentes bajo diferentes licencias copyleft sin violar una de las licencias.

Algunas licencias copyleft enumeran explícitamente licencias compatibles, lo que facilita el uso de un componente con licencia copyleft bajo otra licencia copyleft.

La mayoría de las licencias permisivas son compatibles con otras licencias. Por ejemplo, los componentes con licencia MIT se pueden utilizar en un proyecto con licencia GPLv3 sin correr el riesgo de infringir la licencia. Sin embargo, un componente con licencia GPLv3 no siempre se puede utilizar en un proyecto con licencia MIT sin violar los términos de GPLv3. Por lo tanto, es posible que la compatibilidad no siempre funcione en ambos sentidos.

Antes de lanzar un proyecto de software al mercado, los desarrolladores y sus asesores legales deben realizar una verificación exhaustiva de la compatibilidad de las licencias para evitar infracciones de las mismas. La gestión del cumplimiento del código abierto debe integrarse en las primeras etapas de un proceso de desarrollo de software para evitar retrasos en la distribución del software, por ejemplo, problemas de incompatibilidad de licencias. Busque minuciosamente en el código fuente las licencias aplicables (utilizando herramientas de escaneo de software) y verifique si se cumplen todas las condiciones de la licencia.

Algunos programas pueden estar disponibles bajo varias licencias. Por ejemplo, un licenciante puede optar por una licencia dual para su proyecto tanto con una licencia copyleft como la GPLv3 como con una licencia propietaria. La licencia de propiedad podría ser necesaria, si el posible licenciatario incorpora el código en su propio producto de propiedad. Cada desarrollador determina si puede cumplir con las condiciones de la GPLv3 o si debe obtener la licencia propietaria, y lo más probable es que implique una tarifa de licencia.

Como se señaló anteriormente, algunos programas pueden incluir componentes bajo varias licencias con diferentes condiciones de licencia. Aunque la mayoría de las licencias no suelen causar incompatibilidad, diferentes licencias pueden tener diferentes requisitos para diferentes partes del software.