Ejemplo: Por ejemplo, aunque no haya ninguna decisión judicial al respecto, Eben Moglen, abogado de la FSF, ha comentado que varias veces ha tenido que amenazar con acciones legales (fundamentadas en el derecho de la propiedad intelectual) a empresas que habían “privatizado” código bajo licencia GPL.

Consideremos, por ejemplo, las dos características principales del software libre, las libertades de uso y el efecto copyleft.

1) En relación con las libertades de uso, el marco legal permite a los titulares definir los derechos de explotación de la obra protegida. En lugar de restringir los usos del licenciante como lo hace la mayoría de las licencias propietarias, la licencia libre los amplía al máximo permitido.

2) Respecto al copyleft, el autor de una obra derivada puede crearla únicamente porque el titular de la obra original en que se basa se lo permite, bajo ciertas condiciones. Si estas condiciones –por ejemplo, la de distribuir la obra derivada bajo la misma licencia– no se cumplen, la licencia original se resuelve y la obra derivada es una violación de los derechos originales. Por ello, se ha dicho que el copyleft es legal como cláusula resolutoria.

Por lo tanto, no hay contradicción ni oposición entre los derechos de autor legislados y los derechos bajo una licencia libre. Es más, se puede argumentar que en tanto que una licencia libre respete las excepciones y los usos permitidos del usuario bajo este marco legal, se ajusta más al derecho que muchas licencias propietarias

“El software libre no tiene titulares o propietarios u obliga a ceder sus derechos de autor”
No hay nada más equivocado desde el punto de vista legal. El marco jurídico de la propiedad intelectual confiere derechos de autor automáticamente a los creadores del software (o, en algunas circunstancias, a las empresas contratantes de los creadores). Casi la única obligación compartida por todas las licencias libres es la de mantener los avisos de titularidad de los creadores iniciales del software (el famoso Copyright Notice). Y, como lo indica E. Moglen de la FSF, estos titulares de los derechos actuarán con fuerza para defenderlos.

Estos derechos se pueden ceder, pero únicamente con el consentimiento explícito del autor (con la excepción de los derechos morales sobre el software, en países dónde estén reconocidos, los cuales no se pueden ceder). Por lo tanto, las licencias no pueden quitar la tituaridad del software a sus creadores. Algunas licencias libres obligan a distribuir o publicar el código fuente de obras nuevas, que se consideran modificaciones u obras derivadas de software original, pero no a ceder el código o los derechos del titular sobre éste.

“No se puede hacer un uso comercial del software libre”
Otra creencia equivocada: como hemos visto, no hay límites sobre el uso del software libre, solamente algunas condiciones sobre su modificación y distribución posterior. Las licencias libres no afectan a los usuarios finales. No obstante, es cierto que algunas licencias cuya clasificación es “lingüísticamente” similar a las de software libre -freeware y shareware- prohíben el uso comercial de las versiones gratuitas. Estas licencias no se consideran ni abiertas ni libres (por ejemplo, a menudo el software de este tipo no se distribuye con el código fuente).

“El software libre y el software propietario son incompatibles”
Otro mito es que una licencia libre (y por lo tanto, el software libre) es incompatible con una licencia y el software propietario, ejecutados en un mismo sistema o plataforma informática. Si esto fuera cierto, ninguna aplicación propietario, como las bases de datos de Oracle o las aplicaciones de IBM, podría ejecutarse sobre Linux, OpenBSD o los servidores web Apache. Y viceversa, aplicaciones libres como MySQL no podrían ejecutarse sobre sistemas operativos propietarios como UNIX, Solaris de Oracle o AIX de IBM. Justamente, por ejemplo, Samba existe para relacionar aplicaciones libres y el SO Windows en un mismo sistema o red. Lo que sí que puede suscitar incompatibilidades es la integración o mezcla de software con copyleft y software propietario, lo que comentaremos a continuación.

“No se puede integrar o mezclar código libre y código propietario”
Esta afirmación sostiene que el código libre (en general) no puede mezclarse o integrarse con código propietario en una misma aplicación, sin afectar a dicho código propietario y, por lo tanto, sin violar las condiciones de uso de éste. Una manera más fuerte para expresar esto es afirmar que el software libre, y el código bajo GPL en particular, es “vírico” e “infecta” a otras aplicaciones: cualquier aplicación que integre código GPL vuelve a ser código bajo GPL. Esta afirmación es parcialmente falsa.

Hay que tomar en cuenta los aspectos siguientes:

a) Integración por el usuario final: desde el punto de vista del programa libre, las licencias no restringen sus usos con otras aplicaciones propietarias. La posibilidad de modificación es una condición de ser libre y no hay restricciones sobre su uso. Y es por ello que se ha de distribuir el código fuente con el código objeto o ponerlo a disposición del destinatario. Sin embargo, cualquier integración de código libre (A) con un software propietario (B) podrá ser considerada como una modificación de los dos software en cuestión (¡y realizable únicamente si uno tiene el código fuente de B!). Esto es permitido por la licencia libre del software (A). Sin embargo, dependiendo de las restricciones contenidas en la licencia propietaria (B), dicha modificación puede constituir una infracción de la misma. Esto no es un problema del software libre, sino de la licencia de software propietario.

b) Integración por un intermediario: donde sí que puede haber restricciones relativas a la integración de software de distintos tipos, ya sea libre, abierto o propietario, es respecto de su distribución posterior. Sobre todo, la condición de copyleft robusto de las licencia de tipo GPL prohíbe la “integración” de código bajo la GPL con código propietario en una distribución posterior bajo licencia propietaria, una práctica que se ha llamado la “privatización” del software libre. Esta restricción se aplica a cualquier distribución propietaria del código objeto (sin adjuntar el código fuente) o con condiciones incompatibles con la licencia GPL. Hay ciertas licencias libres que contienen cláusulas que tratan de permitir esta integración, como la LGPL o la MPL en algunas circunstancias, que veremos en el apartado siguiente.

En este sentido, la cuestión de si uno puede integrar un software libre con cualquier otro para su distribución posterior, depende de la forma en que esto se realice. El tratamiento del resultado de esta integración, lo que se considera una “obra derivada”, es complejo y lo estudiaremos a continuación, en el análisis de la condición de copyleft robusto en la licencia GPL y los derechos otorgados en la LGPL.

Asimismo, en cuanto al código bajo licencia propietaria, hay que tener en cuenta los derechos del usuario que descompila el programa con el fin de su interoperabilidad con otro (que puede ser libre) y lo modifica por necesidades legítimas del usuario (para cuyo uso el software se adquirió) y, eventualmente, para la corrección de errores (por ejemplo, si se produce un error cuando interactúa con un software libre)

“Todo el software libre es igual, bajo los términos de la GPL”
Ya hemos comentado que hay variaciones sustanciales entre las licencias libres y veremos a continuación el detalle de estas diferencias. Habría que ser mucho más cuidadoso en el uso del término software libre, así como distinguir a menudo entre licencias libres propiamente dichas (en la interpretación de FSF), licencias abiertas y licencias que no son ni libres ni abiertas. Es importante manejar con claridad los términos código abierto, persistencia y copyleft, que son característicos de estas licencias libres.

“Las licencias libres obligan a publicar sus modificaciones particulares”
Esta es una de las ideas falsas más propagadas sobre el funcionamiento de las licencias libres. Consideremos otra vez la posición de los usuarios finales e intermedios (desarrolladores de programas para terceros):

a) Usuarios finales: la mayoría de las licencias libres no obligan a los usuarios ni a distribuir sus modificaciones o adaptaciones de software libre (obras derivadas, en lenguaje legal), ni a publicarlas o contribuir con ellas al desarrollo de la aplicación modificada. Algunas licencias requieren esto último sólo en relación con correcciones o modificaciones del código central o núcleo del programa. Como veremos, estas obligaciones no se aplican a elementos adicionales agregados al núcleo o a cualquier extensión de la aplicación. Por lo tanto, los usuarios finales no tienen que publicar sus obras basadas en software libre.

b) Los profesionales y las empresas desarrolladores de programas: las personas que desarrollan para clientes tampoco tienen que distribuir al público o a los autores originales cualquier modificación de un software libre, pero sí que tienen que respetar la licencia libre original, muchas de las cuales obligan a proveer el código fuente a los usuarios/clientes destinatarios o, si sólo se distribuye el código objeto, ofrecer el código fuente a cualquier tercero (la GPL) o al destinatario (la MPL). Éste es uno de los requisitos para utilizar software libre y abierto.

“Nadie es responsable por el software libre, ni tiene garantía”
Hay que admitir que esto es cierto, bajo las licencias actuales de software libre, aunque haya dudas legales sobre la efectividad de las Clásulas de negación de garantía y de responsabilidad. Esto ya se ha comentado con respecto al marco jurídico en la Union Europea. El mito, en realidad, consiste en pensar que los licenciantes propietarios aceptan mayor nivel de responsabilidad. Hemos visto que la licencia típica de software propietario también intenta limitar la responsabilidad del licenciante (autor o distribuidor), muchas veces al precio pagado por la aplicación o una suma similar.

Con los sistemas de distribución virtual en Internet, se podría argumentar también que es difícil identificar a los licenciantes y con ello recurrir a alguna indemnización. Muchos sitios de distribución de software libre, como Sourceforge, no son los titulares licenciantes, ni siquiera distribuidores “oficiales”. No obstante, en algunos casos, como el de la FSF o en casos de negocios basados en la distribución de paquetes de software libre como Red Hat o Suse, hay una entidad legal identificable contra quien se podría intentar una acción por daños y perjuicios, si fuera necesario. Además, la obligación de mantener el aviso de autoría (copyright notice) permite identificar a los autores de cualquier componente deficiente, aunque no son necesariamente los que hayan distribuido el programa al perjudicado.

El mismo argumento se aplica a las garantías. Las licencias libres en sí mismas no ofrecen garantías, pero tampoco son de mucha utilidad las de las licencias propietarias. Como se ha visto, muchas veces su garantía contractual está limitada, por ejemplo, a la devolución del precio de compra en caso de una avería, dentro de un límite de 90 días, sin garantizar el funcionamiento adecuado de las aplicaciones.

Por un lado, hay que considerar las garantías obligatorias por ley, que se aplican a software libre y propietario. Por otro lado, las licencias libres permiten a los distribuidores de software libre agregar cláusulas de garantía (con contraprestación económica o no), lo que se hace con muchos paquetes de distribución comercial.

Fuente: La Biblia del Software Libre