El siguiente es un extracto del libro La biblia del software libre que pueden conseguirlo para bajar del siguiente link:
http://www.softwarelibre.net/la_biblia_de_software_libre
El libro es excelente para el que quiera estudiar. Se puede distribuir, modificar y copiar libremente ya que se encuentra bajo licencia GNU.
Me pareció muy interesante y profesional el modo de abordar el tema.
Es un poco largo pero vale la pena que se tomen el tiempo en leerlo.
“El copyleft está en contra o no respeta el derecho
de autor”
Este mito consiste en creer que el software libre (y las licencias aso-
ciadas) crea un nuevo marco de derecho de la propiedad intelectual,
el copyleft, “en vez de” el copyright. Al contrario, tal como lo ex-
plican todos los defensores del software libre, las licencias libres
se fundamentan directamente en el derecho de propiedad intelec-
tual vigente, ya sea el derecho de autor de estilo continental, sea
el copyright anglosajón. La FSF y otros autores del movimiento de
software libre usan sus derechos de autor otorgados por el marco
legal justamente para defender las libertades ofrecidas por sus li-
cencias.
Ejemplo
Por ejemplo, aunque no haya ninguna decisión judicial
al respecto, Eben Moglen, abogado de la FSF, ha co-
mentado que varias veces ha tenido que amenazar con
acciones legales (fundamentadas en el derecho de la
propiedad intelectual) a empresas que habían “privati-
zado” 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 prote-
gida. En lugar de restringir los usos del licenciante como lo hace
la mayoría de las licencias propietarias, la licencia libre los am-
plí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 ex-
cepciones 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 auto-
máticamente a los creadores del software (o, en algunas circunstan-
cias, a las empresas contratantes de los creadores). Casi la única
obligación compartida por todas las licencias libres es la de mante-
ner los avisos de titularidad de los creadores iniciales del software (el
famoso Copyright Notice). Y, como lo indica E. Moglen de la FSF, es-
tos titulares de los derechos actuarán con fuerza para defenderlos.
Estos derechos se pueden ceder, pero únicamente con el consenti-
miento 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 titu-
aridad del software a sus creadores. Algunas licencias libres obligan
a distribuir o publicar el código fuente de obras nuevas, que se con-
sideran 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 fina-
les. No obstante, es cierto que algunas licencias cuya clasficación es “lin-
güí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 ejem-
plo, Samba existe para relacionar aplicaciones libres y el SO Windows
en un mismo sistema o red. Lo que sí que puede suscitar incompati-
bilidades es la integración o mezcla de software con copyleft y soft-
ware 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 aplica-
ció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 particu-
lar, 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) po-
drá 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 li-
cencia propietaria (B), dicha modificación puede constituir una in-
fracció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 res-
tricciones 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 li-
cencia 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 licen-
cias libres que contienen cláusulas que tratan de permitir esta in-
tegració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 for-
ma en que esto se realice. El tratamiento del resultado de esta inte-
gració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 co-
pyleft robusto en la licencia GPL y los derechos otorgados en la LGPL.
Asimismo, en cuanto al código bajo licencia propietaria, hay que te-
ner 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 soft-
ware libre)
“Todo el software libre es igual, bajo los términos
de la GPL”
Ya hemos comentado que hay variaciones sustanciales entre las li-
cencias libres y veremos a continuación el detalle de estas diferen-
cias. 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 funciona-
miento 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 publicar-
las o contribuir con ellas al desarrollo de la aplicación modifica-
da. 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 exten-
sió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 progra-
mas: las personas que desarrollan para clientes tampoco tienen
que distribuir al público o a los autores originales cualquier mo-
dificació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 re-
quisitos 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 soft-
ware 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 propieta-
rios aceptan mayor nivel de responsabilidad. Hemos visto que la li-
cencia 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 argu-
mentar 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 man-
tener el aviso de autoría (copyright notice) permite identificar a los
autores de cualquier componente deficiente, aunque no son necesa-
riamente 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 licen-
cias 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.
