Guía

del derecho y el
software de fuentes
abiertas
Alfonso López Murcia
alfonso@um.es
Universidad de Murcia
GUIA DEL DERECHO Y EL SOFTWARE DE FUENTES ABIERTAS
Versión 1.0
10 de diciembre de 2009

Esta presentación se distribuye bajo

licencia Creative Commons 3.0
Reconocimiento-No comercial-Compartir
disponible en
http://creativecommons.org/licenses/by-nc-sa/3.0/es/

Este documento está

disponible en
http://www.um.es/atica/softla/
 Objetivos de la guía
Dar a conocer los aspectos jurídicos del
Software de Fuentes Abiertas (SFA) para
● Entender los derechos y obligaciones derivados
de las licencias y el derecho del SFA.
● Incentivar su desarrollo, adquisición, uso y
liberación.
● Asegurar que sus beneficios son explotados
correctamente.
● Eliminar reticencias por desconocimiento de las
cuestiones jurídicas.
Centrado en el derecho español. Pueden
existir similitudes a nivel europeo y mundial.
 Organización de la guía
Derechos de autor.
Licencias de software de fuentes abiertas.
Licencias de SFA en la práctica.
Aspectos jurídicos a tener en cuenta por
● Usuario individual.
● Empresas y organizaciones.
Proyectos de SFA.
Integrar SFA.
 Base legal
Con el fin de fomentar la creación de nuevas
obras (en este caso, de software), nuestro
marco jurídico ha reservado una serie de
derechos a los autores y titulares de las
mismas para que puedan controlar su
explotación y defenderlas de la apropiación o
uso ilegítimo por parte de terceros.
El Software de Fuentes Abiertas (SFA) cambia
radicalmente esta filosofía, respetando en
todo momento los derechos de autor. EL SFA
pretende ceder los derechos a todo el mundo
bajo ninguna o muy pocas condiciones para
que cualquiera pueda explotar el programa.
Protección de programas
Los programas de ordenador pueden
protegerse bajo cuatro figuras legales.
● Derecho de autor protege el código del programa
y su documentación preparatoria.
● La patente protege las funcionalidades y procesos
de un programa (capítulo 8 guía).
● El derecho de marcas concede un derecho
exclusivo y excluyente sobre una marca relativa a
un software (capítulo 8 guía).
● El secreto industrial protege la información
confidencial sobre creación del software, su
diseño o sus modelos de implementación y de
negocio que pueden tener un alto valor comercial.
http://gua30.files.wordpress.com/2008/04/cright.jpg
 Protección mediante
derecho de autor
El software y su documentación preparatoria
(documentos análisis, diagrama UML, etc).
● Se considera una obra intelectual.
● Está protegida por los derechos de autor. Ventajas:
– es automática (no necesita inscribirse en un registro).
– Es económica (si no hacen falta solicitudes, no hay tasas).
– Es internacional (por tratados internacionales).
Obras protegidas.
● Sistemas operativos, programas de uso general y
desarrollados a medida, compiladores, librerías,
entornos de desarrollo, servidores de aplicaciones
y web, etc.
Cobertura derechos de autor
Los derechos de autor cubren
● el código fuente y objeto.
● La imágenes, iconos, gráficos, etc.
● Los guiones o scripts de compilación e instalación.
● Documentación preparatoria (diseños, diagramas,
especificaciones, modelos de datos, etc).
● Documentación técnica y manual de instalación.
● Versiones sucesivas de un programa.
● Cualquier modificación (obras derivadas).
● La estructura y contenidos de la bases de datos.
 Derechos morales y de
explotación
Los derechos de autor incluyen
● Derechos morales (irrenunciables e intransmisibles).
– Autoría, integridad, divulgación y en qué forma, modificar la obra
respetando los derechos adquiridos por terceros, retirar la obra
previa indemnización a terceros con derechos de explotación.
● Derechos de explotación.
– Explotación de la obra en cualquier forma y, en especial
● la reproducción del programa. Copia total o parcial.
● La transformación, como traducción, adaptación, arreglo o cualquier
otra transformación. El resultado es una obra derivada.
● La distribución del programa en un medio físico a un tercero.
● La comunicación pública (acceso a la obra sin previa distribución de
ejemplares), por ejemplo “colgar en Internet”.
Transcurrido 70 años desde la muerte del autor el
programa pasa a ser de dominio público.
Autor y titular del software
El titular originario de los derechos de autor
sobre el software, coinciden en principio, con
el autor o grupo de autores que lo crearon.
El titular debe identificarse en el aviso de
copyright, establece las condiciones de
distribución (licencia) y tiene los derechos
morales.
Excepciones en los derechos de explotación:
● software creado bajo una relación laboral por
trabajadores asalariados, salvo pacto contrario.
Por tanto corresponde al empresario.
● El software creado como obra colectiva bajo la
iniciativa y coordinación de un editor.
Ejemplos obras colectivas
La fundación Apache es el editor y titular de
los derechos del proyecto Apache. Ello sin
perjuicio de que la fundación exija que cada
contribuidor firme una cesión de derechos
para una mayor seguridad legal.
Un grupo de investigadores universitarios, en
el cual el IP, empleado de la universidad
inicie el proyecto y coordine la labor de sus
compañeros y el resultado sea publicado por
la misma universidad. En este caso el IP es
titular de los derechos del software como
obra colectiva.
 Tipos de obras
A veces el software general como el SFA es la
composición o integración de varios
programas. La LPI establece dos figuras:
● obra compuesta formada por programas
independientes mediante copia y/o modificación.
● Obra derivada mediante modificación o adaptación.
En ambos casos los derechos pertenecen al
autor quien necesitará la correspondiente
autorización de los titulares de cada
componente para copiar y/o modificar los
programas. Esta autorización se consigue
mediante una licencia (en el caso de SFA de
licencias reconocidas es mas sencillo).
 Concepto de licencia
El titular de los derechos de explotación puede
cederlos a un tercero mediante una licencia.
La licencia puede imponer condiciones al
ejercicio de los derechos cedidos, ya sean
libremente pactadas entre las partes o
determinadas unilateralmente por el titular
(CLUF o EULA y en licencias de SFA).
Los derechos puede ser una
● cesión exclusiva.
● Cesión no exclusiva, donde el titular puede ceder
derechos sobre el software a terceros (SFA).
Si no se especifica lo contrario, la licencia se
presume no exclusiva.
 Organización de la guía
Derechos de autor.
Licencias de software de fuentes abiertas.
Licencias de SFA en la práctica.
Aspectos jurídicos a tener en cuenta por
● Usuario individual.
● Empresas y organizaciones.
Proyectos de SFA.
Integrar SFA.
Entender las licencias

Licencias - TiraEcol
 La licencia de software
Concepto
● Según el derecho español es el contrato por el cual
el titular de un programa autoriza al licenciatario a
utilizarlo, cediéndole los derechos necesarios para
este uso.
Doble función
● Reservar y proteger los derechos del titular:
– derechos no cedidos (como los derechos morales).
– Las condiciones a cumplir por el usuario.
● Asegurar los derechos del usuario (autorizaciones).
La licencia establece determinados derechos y
obligaciones entre las partes.
Clasificación del software
 Licencias privativas
Hay tantas como software propietario.
Cuando la licencia permite el uso del software
a un único usuario hablamos de Contrato de
Licencia de Usuario Final (CLUF o EULA por
sus siglas en inglés).
● Una licencia de CLUF concede, básicamente, el
derecho a instalar y ejecutar el software de
acuerdo con determinadas condiciones y
restricciones (pago de una licencia, prohibición
de copia, prohibición de modificación y
distribución y otras limitaciones de uso).
Licencias tipo freeware y shareware.
 Ejemplo de licencia
Licencia EULA de Adobe Reader:
● Esta licencia no le permite otorgar licencias ni distribuir
el software.
● Se puede hacer una copia de seguridad del software
siempre y cuando su copia de seguridad no se instale
ni utilice.
● No se puede integrar o utilizar Adobe Reader con ningún
otro programa de software, conector “plug-in” o
mejora.
● Prohibición de compilación inversa o modificación.
● Propiedad intelectual de Adobe. La estructura,
organización y código del software son secretos
comerciales. El software está protegido por las leyes
de derechos de autor de EEUU y de otros paises.
Mapa conceptual FLOSS

w
i
k
i
p
e
d
i
a
 Licencias de SFA
Un programa con licencia de SFA (FOSS y
FLOSS) ofrece al licenciatario:
● las cuatro libertades del SFA.
● Cumple las diez directrices de la “Definición de
Software de Fuentes Abiertas” (OSD en inglés)
de la Open Source Initiative (OSI).
Derechos otorgados por una licencia de SFA:
● instalar y ejecutar el programa sin limitaciones.
● Reproducir y transformar el programa.
● Distribuir y/o comunicar el programa.
Es aconsejable utilizar programas con licencias
conocidas y aceptadas por la comunidad.
Clasificación licencias SFA

Clasificación según el grado de copyleft

 Licencias permisivas
No imponen ninguna condición particular a la
redistribución del software, salvo
● mantener los avisos legales.
● Limitaciones de garantías y responsabilidades.
Permite integrar y redistribuir en aplicaciones
con otro tipo de licencia (SFA o propietario).
Algunas extraídas de la wikipedia:
● Berkeley Software Distribution (BSD).
● Massachusetts Institute of Technology (MIT).
● PHP License 3.0.
● Perl.
Apache Software License 2.0
Algunos derechos otorgados:
● reproducción, modificación, distribución y
comunicación pública.
Algunas obligaciones:
● Mantener una copia de la licencia, aviso de
titularidad y las exclusiones de garantías y
responsabilidades en el código fuente.
● A la hora de redistribuir se debe indicar la
modificación realizada y mantener el fichero
“notice.txt”.
La FSF considera que es incompatible con la
licencia GPL 2.0 pero compatible con GPL 3.0.
http://www.pzwart.wdka.hro.nl/mdr/research/lliang/open_content_guide
 Concepto de copyleft
El copyleft usa el principio del copyright, pero le
da la vuelta para servir a lo opuesto de su
propósito: en lugar de ser un medio de privatizar
el software, se transforma en un medio para
mantener libre el software.
Con el copyleft damos a cualquiera permiso para
● ejecutar, copiar modificar y redistribuir el programa así
como sus versiones modificadas.
Para que el copyleft sea efectivo, las obras
derivadas distribuidas deben ser también libres.
Algunos detractores consideran el copyleft como
un virus.
Licencias con copyleft fuerte
Exigen el uso de la misma licencia para:
● cualquier redistribución del programa.
● Las modificaciones del programa.
● Los programas que lo usan o incorporan (por
ejemplo en forma de librerías).
● El licenciatario debe dar una copia del código
fuente u ofrecerle un medio para obtenerlo.
Sólo es obligatorio divulgar el código fuente
del programa o su modificación en el
momento de la redistribución.
Se impide la distribución de software con
copyleft en aplicaciones privativas.
Copyleft y servicios remotos
El efecto copyleft se activa en la redistribución
del software (la redistribución es voluntaria).
En los servicios de software remoto no hay
distribución del código, sino de sus
funcionalidades o usos.
Las entidades que ofrecen servicios basados
en software GPL (como Google y otros) no
están obligados a proporcionar el código.
La licencia Affero GPL (o AGPL) incluye la
obligación de de proporcionar una copia del
programa y el código fuente a usuarios
remotos.
 La GPLv2 o 2.0
Derechos otorgados:
● Reproducción, modificación y distribución del programa
en código fuente o binario.
Obligaciones:
● usar la misma licencia en caso de redistribución del
programa, modificación o integración con otro soft.
● No se permiten agregar restricciones adicionales en la
distribución del programa.
● Si se distribuye el binario, el código fuente debe estar
disponible.
No se permite enlazar mediante vínculos
dinámicos a otros programas salvo que se
aplique la GPLv2 al conjunto del software.
 Modernización GPLv2
La GPLv2 fue creada en 1.989.
A finales de 2.005 se empieza a trabajar en la
versión. Objetivos principales:
● Extender la validez internacional.
● Modernizar la licencia en el marco tecnológico.
● Flexibilizar (parcialmente) la licencia para hacerla
compatible con mas licencias.
● Evitar el uso de software libre en sistemas DRM
(efecto tivoización).
● Incluye cláusulas que defienden a la comunidad
de SFA del uso indebido de las patentes
software.
 La GPLv3
Derechos otorgados:
● A propagar el programa con o sin modificaciones y
de obras basadas en el mismo.
● Enlazar el programa con software bajo licencia
Affero GPL.
● Permite integrar software con restricciones
adicionales al software bajo la GPLv3.
Comentarios:
● El código fuente incluye los scripts para su
compilación y ejecución, así como cualquier API.
● El copyleft no se aplica a distribuciones entre
consultor-integrador y su cliente.
Compatibilidad de licencias

GPLv2 es compatible con GPLv3 si permite

“GPLv2 o cualquier licencia posterior”
 Lesser GPL (LGPL)
Es una licencia mixta o con copyleft suave.
Se creó para permitir que componentes bajo
esta licencia se enlazaran con programas de
otro tipo de licencia, de SFA o no libre.
Las cláusulas del copyleft son para el código
original y sus modificaciones, sin que esto a
otros programas que lo integren o lo utilicen
(por ejemplo una librería).
Esta licencia se usa para SFA de tipo
empresarial porque permite que otros
profesionales agreguen extensiones o módulos
para sus clientes bajo cualquier licencia.
Mozilla Public License
Derechos otorgados:
● Reproducción, modificación y distribución del programa
en código fuente o binario.
Obligaciones:
● mantener copia licencia,
aviso titularidad y
exclusión de garantías.
Otros:
● Se somete al derecho
californiano y tribunales
de Santa Clara
(California).
● No es compatible con
licencias copyleft fuerte.
 European Union
Public License (EUPL)
Redactada expresamente para la liberación de
software de la administración pública
europea y miembros UE.
Efecto copyleft suave.
La licencia se somete al derecho del proveedor
de software (o Bélgica para soft de la UE).
Es compatible con licencias permisivas y
mixtas (copyleft suave).
Si se combina con otras licencias, el resultado
se podrá distribuir bajo licencia del otro
software.
 Organización de la guía
Derechos de autor.
Licencias de software de fuentes abiertas.
Licencias de SFA en la práctica.
Aspectos jurídicos a tener en cuenta por
● Usuario individual.
● Empresas y organizaciones.
Proyectos de SFA.
Integrar SFA.
Compatibilidad licencias SFA
No hay ningún problema a la hora de integrar
y usar componentes de manera interna sin
distribución a terceros. Pero puede impedir la
redistribución de componentes bajo licencias
incompatibles integrados en un mismo
producto.
En el contexto del SFA, dos o mas licencias son
compatibles cuando se puede integrar el
código de un programa en otro bajo una
licencia distinta sin que la redistribución de la
obra resultante infrinja la licencia del
primero.
 Reglas de utilidad
Si todos los componentes de una aplicación se
reciben y distribuyen bajo la misma licencia
no hay ninguna incompatibilidad.
La integración de componentes con licencias
permisivas en otros programas no debería ser
problemático.
El conflicto surge a la hora de distribuir
componentes bajo dos o mas licencias
copyleft.
La compatibilidad depende de la manera de
integrar los componentes y si dicha
integración constituye una transformación.
Ejemplos compatibilidad (I)
Licencias permisivas.
● Mezclar o integrar un componente bajo licencia
permisiva (BSD, MIT, Apache, etc) en un
programa bajo licencia copyleft (GPL, MPL, etc)
no debe suponer un problema, pues la licencia
con copyleft cumplirá con las pocas obligaciones
impuestas por la licencia permisiva.
Copyleft suave.
● Un software que usa librerías bajo licencia LGPL
puede ser distribuido bajo otras licencias como
Apache Software License o Mozilla Public Lic.
● LPGL tiene un pacto de compatibilidad con GPL (la
librería se convierte en GPL).
Ejemplos compatibilidad (II)
Copyleft fuerte.
● GPLv2 prohíbe restricciones adicionales. Por tanto
cualquier licencia que imponga nuevas
restricciones (por ejemplo condiciones en cuanto
al derecho aplicable, la prohibición de uso de
marcas, a indemnizaciones, etc.) será
incompatible con la GPLv2.
● El efecto copyleft de la GPL no se extiende a
programas distribuidos en un mismo soporte (por
ejemplo un CD/DVD).
● La Common Public License (CPL) impone el derecho
aplicable en el estado de Nueva York y las leyes
de propiedad intelectual de EEUU.
 Sourceforge
Licencias SFA en sourceforge.
BSD: tcl/tk, swig, flex.
MIT: Liferay (portal de gestión de contenidos),
WideStudio (IDE).
LGPL: Jboss AS (servidor aplicaciones J2EE).
Mozilla Public License 1.1: Pentaho.
CDDL (de SUN basada en MPL 1.1): NetBeans.
Openbravo Public License (MPL 1.1 modificada):
Openbravo (ERP).
GPL v2 (con linking exception) : Alfresco (ECM).
 Conocer tipo licencia
Podemos verlo en wikipedia.
Elegir licencia distribución (I)
Debe tomarse cuanto antes, pues determina:
● La compatibilidad con otras licencias.
No escribir una licencia nueva. Mejor
seleccionar una reconocida por la OSI.
Objetivos de la liberación:
● Filosóficos, entonces licencia permisiva.
● Solución comercial, entonces licencia mixta.
● Si es fruto de investigación universitaria,
entonces ver criterios de difusión del
conocimiento.
● Si es una iniciativa pública, buscar reutilización.
Elegir licencia distribución (II)
Compatibilidad entre componentes:
● Las licencias de los componentes de SFA
determinan la licencia del proyecto (ej. GONG).
Software a crear y distribución:
● Para usuario final: no suele modificarse, pero se
permite incluir componentes, extensiones, etc.
● Para un SO, un framework o middleware:
estudiamos condiciones de redistribución a
terceros.
● Librerías y componentes funcionales: para una
mayor difusión e integración. Puede servir una
licencia con copyleft suave (LGPL o GPL con la
excepción Classpath).
Elegir licencia distribución
(III)
Escoger mas de una licencia:
● Esquema de licencia dual o
múltiple.
● Licencias distintas para usuarios
y usos distintos (por ejemplo
alfresco). wikipedia
● Estrategia elegida por empresas
porque permite:
– Beneficiarse de los desarrollos y
avances del SFA.
– Obtener ingresos a partir de una
distribución del mismo software
bajo licencia propietaria y
comercial.
 Modelos licencia dual
Un software, dos licencias:
- una licencia libre gratuita para usos libres (normalmente GPL)
- Una licencia privativa y comercial (el modelo de negocio se basa
en estos ingresos).
Ejemplos: MySQL, Ghostscript, Trolltech, Jahia, Sleepycat, etc.

Dos programas, dos licencias:

- una versión básica bajo licencia libre y gratuita.
- Una versión mas completa bajo licencia privativa (para evitar
redistribuciones) y de pago (para obtener ingresos).
Ejemplos: SugarCRM, Jahia, etc.

Un software, una licencia (con opción a cambiar a otra licencia):

- la licencia permite el uso del software bajo otra/s licencia/s.
- La GPL permite al usuario elegir usar el software bajo la GPL.
Ejemplos: MPL, CeCILL, LGPL, EUPL.
 Cuestiones jurídicas
La cesión de derechos bajo licencia de SFA no
implica renuncia de derechos por parte del
titular.
El titular del SFA puede iniciar acciones legales
contra las personas que infrinjan la licencia.
Cuando una persona acepta las condiciones de
uso de un SFA se convierte en usuario y adquiere
el derecho a usarlo.
Las condiciones establecidas en la licencia de SFA
es válida entre las partes.
Se puede considerar el SFA como una donación
sin garantías pero con responsabilidades.
 Organización de la guía
Derechos de autor.
Licencias de software de fuentes abiertas.
Licencias de SFA en la práctica.
Aspectos jurídicos a tener en cuenta por
● Usuario individual.
● Empresas y organizaciones.
Proyectos de SFA.
Integrar SFA.
 Individuos y SFA
Los usuarios individuales del SFA gozan de
todos los derechos otorgados por sus
respectivas licencias:
● uso.
● Copia.
● Modificación para adaptarlo a nuestras necesidades
o a sistemas existentes
● Distribución y comunicación pública.
Normalmente no modifica ni distribuye. En
este caso, no le afectan las obligaciones del
copyleft.
Empresas y organizaciones

Adaptado de presentación Peter Carbone.

 Nivel 1 Usuario
1.a Usuario interesado.
● Uso: sustitución aplicaciones propietarias backoffice.
● Aspectos legales: EULA, ausencia de garantías y
limitaciones de responsabilidad, soporte de la
comunidad.
1.b Usuario avanzado.
● Uso: uso y adaptación del SFA para las aplicaciones
empresariales.
● Aspectos legales: exigir acceso al código fuente,
contratar servicios de soporte y mantenimiento,
licenciar versiones profesionales con garantías en
cuanto a propiedad intelectual y uso pacífico, en
los contratos exigir uso estándares abiertos.
 Niveles 2-3
2 Contribuidor.
● La empresa contribuye software al proyecto que
gestiona las aplicaciones que utiliza.
● Aspectos legales: cesión al proyecto de derechos
sobre las contribuciones, confidencialidad (del
software propio).
3 Sponsor.
● La empresa patrocina y contribuye recursos.
Obtiene información y ventajas del proyecto.
● Aspectos legales: participación en la gestión del
proyecto, confidencialidad (software del proyecto).
 Niveles 4-5
4 Colaborador.
● La empresa participa en la dirección del proyecto y
orienta su evolución a sus necesidades.
● Aspectos legales: gestión de propiedad y licencias
con respecto al proyecto libre.
5 Líder.
● La empresa lidera un proyecto liberado por ella.
● Aspectos legales: gestión de propiedad y licencias,
selección y uso de marcas, patentes. Formación
de los responsables técnicos para conocer los
aspectos jurídicos.
 El sector público
El sector público en España y Europa es
● un gran consumidor o usuario de software.
● Creador, directa o indirectamente, a través de
encargos y contratos públicos.
Las Administraciones Públicas españolas son
competentes para
● Adquirir y utilizar SFA.
● Obligar a que el software suministrado cumpla
estándares abiertos.
● Intercambiar SFA entre ellas.
● Liberar SFA de su titularidad a la comunidad.
 Marco actuación sector
público en España
Existen algunas disposiciones generales que
tienden a favorecer el uso de SFA en la AP, sin
ser específicas:
● Ley 11/2007 de 22 de junio de Acceso Electrónico de los
Ciudadanos a los Servicios Públicos:
– Se establecen medidas que, sin promover directamente el SFA,
facilitarán la reutilización de recursos informáticos entre
administraciones, la creación de repositorios y,
eventualmente, la liberación bajo licencias SFA.
● Ley 56/2007 de 28 de diciembre de Medidas de Impulso
de la Sociedad de la Información:
– La AP puede poner a disposición del público contenidos digitales
cuyos derechos de propiedad intelectual le pertenezcan bajo
licencias que permiten el estudio, copia y redistribución en los
mismos términos. No se habla de modificación.
 Organización de la guía
Derechos de autor.
Licencias de software de fuentes abiertas.
Licencias de SFA en la práctica.
Aspectos jurídicos a tener en cuenta por
● Usuario individual.
● Empresas y organizaciones.
Proyectos de SFA.
Integrar SFA.
Mapa conceptual SFA
 Proyectos SFA
Los proyectos de SFA deberían tener cuatro
objetivos jurídicos principales:
● Asegurar la titularidad de los derechos necesarios y
suficientes para poder liberar el software bajo
licencia SFA.
● Seleccionar una licencia de distribución que asegure
los objetivos del proyecto.
● Cumplir con las obligaciones establecidas en las
licencias sobre componentes de SFA integrados en
el software y evitar su incompatibilidad.
● Proteger la reputación del proyecto y la calidad de
su software.
 Casos proyectos SFA
Proyecto básico.
● Se libera un software de nueva creación.
Proyecto complejo.
● Se integra componentes de SFA de terceros.
Proyecto maduro.
● Se ha publicado el código y la comunidad empieza a
contribuir.
Forjas.
● Cenatic.
● Morfeo.
● RedIRIS.
Caso 1 Proyecto básico (I)
El software es de nueva creación y no integra
ningún componente de terceros.
Caso 1 Proyecto básico (II)
En el desarrollo.
● El editor debe garantizar la titularidad original del
software (titular o licenciante de los derechos del
software creado por otros).
● Derechos de autor:
– Creado internamente, serán de los autores o el empresario.
– Si son subcontratas, proveedores, becarios, etc. si no hay
cesión expresa y por escrito, la titularidad será de estas
personas y no de las entidades donde trabajan,
proporcionan servicios o estudian.
– En proyectos empresariales e institucionales el software
creado por personal fijo (profesores o investigadores), salvo
pacto contrario en su contrato laboral, será propiedad de la
entidad. Si el autor no es empleado, es titular y sus
derechos debe cederlos para explotar el software.
Caso 1 Proyecto básico (III)
En el desarrollo.
● Casos en los que no se tiene la titularidad:
– Un desarrollador del proyecto ha “cortado y pegado”
código desde Internet (snippets, scripts, etc.).
– El código es un software de un tercero bajo licencia
(privada o de SFA).
– Un desarrollador externo aporta código a un proyecto
siendo empleado de otra entidad, habiendo desarrollado
su tarea dentro de su propio marco laboral y sin
formalización de la cesión por parte de su empleador.
● Se resuelven con la gestión y cesión de derechos.
● Mantener confidencialidad:
– nuevo proceso o producto susceptible de ser patentado.
– Valor comercial de la información generada.
Caso 1 Proyecto básico (IV)
En la liberación/distribución.
● Selección de la licencia de SFA.
● Plataforma de distribución.
● El proyecto puede registrar un signo (denominativo o
gráfico) como marca para identificar y distribuir el
software y su origen.
– La iconografía está protegida, por ser obra gráfica.
– La marca protegerá la reputación (calidad) del software,
identificará su origen y generará valor, aumentando el
interés económico de un proyecto comercial de SFA.
● La distribución del software en Internet.
– Sujeta a las obligaciones legales que rigen los sitios y las
actividades en Internet y la LSSICE.
– Establecer un aviso legal, licencia SFA del software y reglas
de uso de marca.
Caso 2 Proyecto complejo (I)
Integra componentes de SFA de terceros.
Caso 2 Proyecto complejo (II)
Proyecto para ampliar, integrar o mejorar las
funcionalidades de un programa existente o
para incorporar funcionalidades a un software
propio. Ejemplos:
● Unas librerías de software.
● Una base de datos.
● Conjunto de subcomponentes (SO, BBDD, web).
Proyectos basados en software compuesto.
● Zimbra: integra apache, mysql, java y postfix.
Licencias Open Source Edition y Network Edition.
● Sakai, OpenGroupware, Pentaho.
Caso 2 Proyecto complejo (III)
Regla básica: el proyecto debe obtener los
derechos suficientes para poder
● Integrar el componente del SFA en el proyecto.
● Distribuir el proyecto a terceros.
Las licencias de SFA siempre conceden los
derechos suficientes para crear el software
del proyecto.
● Los derechos de copia y modificación permiten el
desarrollo y uso interno.
● El copyleft de la licencia entrante impone unas
obligaciones sobre el componente y en la licencia
saliente (debe ser compatible).
Caso 2 Proyecto complejo (IV)
El software GONG se ha creado sobre la base
de Alfresco CMS que se distribuye bajo
licencia GPL, pero con una excepción especial
(FLOSS exception). Así cumpliendo con el
efecto copyleft, la licencia de distribución de
GONG es la misma GPL, incluyendo la
excepción.
Caso 2 Proyecto complejo (V)
Redistribución de componentes de SFA
● Obligaciones sobre la redistribución.
– Mantener el aviso de los derechos originales (copyright
notice) y las cláusulas de exención de responsabilidades
(disclaimers).
– Incluir copia licencia del componente y fecha
modificaciones.
– Respetar la obligación o prohibición uso marca.
● Derechos de marca.
– A tener en cuenta el uso de marca de terceros, ya sea en la
interfaz gráfica, en la publicidad o documentación.
– Para usar la marca de un tercero será necesario obtener
una licencia por parte del titular. Para facilitarlo, algunas
publican “condiciones de uso establecidas”.
Política de marca expresa
Debian y logo Debian.
Gnome y logo Gnome.
Mysql
Java y logo Java.
Alfresco.
Apache.
Joomla!
Sakai y logo Sakai.
Ubuntu.
Caso 3 Proyecto maduro (I)
Caso 3 Proyecto maduro (II)
Contribución por vía
● directa: acuerdo sobre contribuciones.
● Indirecta: como componente de SFA de terceros.
Aspectos jurídicos en recepción contribuciones
● Averiguar origen.
● Cesión completa o licencia de uso.
● Acuerdo sobre contribuciones.
Forma de aportar código y garantizar derechos
● Realizar la aportación bajo licencia del proyecto o
licencia de SFA compatible.
● Ceder al proyecto los derechos del software
mediante un acuerdo de cesión.
Acuerdos de cesión de derechos
sobre contribuciones (I)
En algunos proyectos de SFA de carácter
empresarial que distribuyen software bajo
una licencia no libre se exige la firma de un
“acuerdo sobre contribuciones”
● Apache, MySQL, Alfresco, OpenOffice.org.
En el acuerdo de cesión de derechos
● Se establece la cesión irrevocable, exclusiva o no
exclusiva de todos los derechos de autor (y si es
posible, de patente) o un régimen de
cotitularidad.
● Suele incluir garantías en cuanto al origen de la
aportación y obligaciones de colaboración en caso
de tener que proteger el software.
Acuerdos de cesión de derechos
sobre contribuciones (II)
Ventajas:
● Da al proyecto la titularidad exclusiva de los
derechos.
● Permite hacer cambios de licencia de SFA (por
ejemplo de la licencia GPLv2 a GPLv3 o el cambio
de licencia de Xfree86 que motivó el reemplazo
por X.Org Server) sin tener que solicitar
autorización a los contribuidores.
● Distribuir el software en régimen de licencia dual.
● Perseguir a los infractores que explotan el software
violando su licencia de distribución (la
legitimación activa).
La liberación del software (I)
El proyecto puede liberar el software una vez:
● asegurados los derechos del software.
● Seleccionada la licencia de SFA para su distribución
● Elegido un nombre único y original.
Revisión legal.
● Revisar componentes, sus licencias y obligaciones.
● Incluir en la cabecera de los ficheros los avisos de
autoría y licencia del proyecto.
● Agregar en los ficheros modificados una anotación.
● Redactar un fichero licensing.txt con información
jurídica (componentes, licencias, avisos, etc).
● El binario va acompañado del código fuente.
La liberación del software (II)
Otros aspectos de la liberación.
● Asegurar el reconocimiento de los autores en la
sección “About” del programa (si la hay).
● Incluir un proceso de aceptación de licencia.
● Redactar una política de uso del nombre y, en su
caso, cualquier marca del proyecto.
● Solicitar el registro de la marca del proyecto.
● Establecer en la web del proyecto una sección con
información legal útil para los usuarios.
● Determinar la licencia para los contenidos de la web
y en particular su documentación.
● Averiguar si la web cumple con la ley (LSSICE y
LOPD).
 Ejemplo de liberación
(Netscape/Mozilla 1998)
Cuestiones jurídicas.
● Mas de 75 componentes de terceros
● Se basaba en componentes Java.
● Integraba software de cifrado (no liberable).
Resolución.
● Reunión con los titulares de los componentes de
terceros para solicitar autorización.
● Se eliminó la tecnología Java.
● Redacción licencia Netscape Public License, que
reserva derechos a Netscape. Los componentes
nuevos se liberan con licencia Mozilla Public
License, con copyleft suave. Fundación Mozilla.
 Ejemplo de liberación
(OpenBravo)
Cuestiones jurídicas.
● Uso de componentes de SFA bajo varias licencias.
● Selección de una licencia distribución compatible.
● Componentes de expertos externos y la comunidad.
● Registro y protección de marca Openbravo en
España y otros países.
Resolución.
● Verificación del código y compatibilidad licencias.
● Elección licencia MPL (copyleft suave). Obligación de
reconocer origen en cualquier obra derivada.
● Política para garantizar calidad técnica como legal.
 Ejemplo de liberación
(Campus)
Cuestiones jurídicas.
● Coordinación propiedad intelectual de mas de ocho
socios públicos y privados.
● Interrelación entre componentes, sistema central, Sakai
y Moodle (licencias incompatibles).
Resolución.
● Convenio entre socios para propiedad intelectual.
● Licencia principal GPL, pero se pueden
incorporar componentes bajo otras
licencias de manera modular a través
de un adaptador central (OKI bus).
 Organización de la guía
Derechos de autor.
Licencias de software de fuentes abiertas.
Licencias de SFA en la práctica.
Aspectos jurídicos a tener en cuenta por
● Usuario individual.
● Empresas y organizaciones.
Proyectos de SFA.
Integrar SFA.
 Ventajas SFA para el
consultor-integrador
Permite una solución de tipo empresarial.
Prestaciones de calidad a todos los niveles.
Libertad de integrar módulos o componentes
en una arquitectura mas compleja y
adaptarlo a las necesidades del usuario.
Modelos de empresas que prestan servicios.
● Servicio de implantación y soporte de sus propios
productos.
● Empresas independientes que unen componentes
de SFA para crear paquetes integrados.
● Integradores que diseñan soluciones complejas a
medida para sus clientes.
Beneficios para el proveedor
Modelo de negocio.

- Venta de servicios de integración y desarrollo (no de licencias).

- Servicios adicionales de soporte, mantenimiento y formación.
- Aplicación o extensión de garantías sobre el software.
- Normalmente proyectos medianos y grandes.

Modelo de gestión del desarrollo.

- Modular, con reutilización frecuente de componentes.

- Flexible, abierto a la comunidad.
- Control de calidad de SFA disponible.
- Conocimiento en profundidad de las tecnologías existentes.

Modelo de relación con el cliente.

- El cliente no depende de un único proveedor.

- El valor añadido reside en el servicio.
- Relación de larga duración (soporte, mantenimiento, versiones, etc).
- Gran diversidad de proyectos (comerciales, universitarios, etc).
 Beneficios para el cliente
Ventajas para el cliente.

- No paga licencias sobre componentes (servidores, bases de datos,

sistemas operativo, etc). El ahorro de costes se puede
transferir a mejorar el servicio.
- Independencia del proveedor:
* Acceso al código.
* Existencia de proveedores alternativos con conocimientos
sobre las tecnologías utilizadas.
* Posibilidad de mejorar internamente (si se dispone de un
departamento de TI).
- Longevidad de la solución en el tiempo (ciclo de vida y versiones).
- Libertad de difusión (reproducción y redistribución).

Otros impactos.

- ¿Qué obligaciones afectan a la redistribución?

- ¿Existen garantías sobre los componentes del SFA?
- ¿El proveedor reutilizará el código?
Posición consultor-integrador
La posición de un consultor-integrador es similar
a la de un proyecto de creación de SFA.
● Se desarrolla un producto a partir de varios programas
de fuentes abiertas para distribuirlo a una entidad o
persona bajo un contrato comercial.
● No será necesariamente liberado al público.
● Ejemplo: openTrends Solucions i Sistemes S.L.
Aspectos jurídicos a tener en cuenta
● Uso e integración de componentes SFA.
● Selección de una licencia de distribución (respetar
incompatibilidades y licencias de los componentes).
● Garantías y responsabilidades del producto.
Arquitectura solución SFA
Integración de software,
impacto del copyleft
Si se utilizan componentes bajo licencia GPL
afecta al programa y sus modificaciones. Pero
también a las obras que se basan en él.
Estudiar cada caso, teniendo en cuenta las
diferentes maneras de interrelacionar los
programas (enlaces estáticos, enlaces
dinámicos, interfaces web, etc).
Una aplicación que se ejecute en GNU/Linux o
se base en MySQL (ambos GPL) no debe
distribuirse necesariamente bajo GPL.
Si se integran drivers, librerías o módulos en el
SO a considerar integración y distribución.
 Biblioteca Qt
Usada por:
● Google Earth, KDE, Opera, Skype.
Desarrollada en 1992 por
Trolltech con licencia “Free Qt”.
Con la versión 2.0 licencia “Q
Public License”, pero no
compatible con GPL de KDE.
Actualmente tres licencias:
● GPL v2/v3 para SFA.
● LGPL para aplicaciones comerciales.
● Licencia de pago QPL para desarrollo
de aplicaciones comerciales.
 Que se puede hacer o no
Licencia Puede No puede

Distribuir su solución al cliente bajo la misma Cederlo al cliente

GPL u otra con licencia, proporcionándole el código fuente. bajo términos mas
copyleft fuerte Puede cobrar por el producto o servicio, restrictivos.
soporte y mantenimiento. Vender licencias.
Integrar estos componentes en programas mas
complejos y distribuir el resultado final bajo otra
Permisiva (BSD, licencia de SFA compatible y hasta bajo una
MIT, etc.) licencia no libre.
Puede cobrar la implementación, soporte y
mantenimiento.
El integrador puede cobrar por licencia (por una
Mixta (copyleft extensión propietaria agregada al producto
suave, como original, por ejemplo), mientras que el SFA
LGPL, MPL, originario deberá distribuirse bajo la misma
CDDL, OSL, licencia.
etc.) Puede cobrar la implementación, soporte y
mantenimiento.
Garantías y responsabilidades
El proveedor debe prestar atención a:
● garantías en relación con la distribución de SFA y
prestación de servicios.
● Responsabilidades que se deriven.
En el derecho español
● El cliente/usuario debe beneficiarse de unas garantías
mínimas legales relativas al producto o servicio.
● El proveedor responde por daños físicos causados por
el software y en casos de dolo o negligencia.
En EEUU las licencias de SFA suelen incluir
limitaciones de garantías y responsabilidades
(“disclaimers”).
 Contrato basado en SFA
El contrato entre el consultor-integrador y el usuario final
es el último elemento de la cadena de comercialización
de productos y servicios basados en SFA.
Puntos importantes a tener
en cuenta en el contrato (I)
Responsabilidad.
● La empresa integradora de SFA suele ser el único
responsable ante el cliente, ya es difícil exigir
responsabilidades a la comunidad del SFA.
● El proveedor debe definir el ámbito del proyecto y el
alcance del servicio prestado.
Propiedad intelectual.
● Respetar las licencias y su compatibilidad.
● Régimen de cesión de derechos.
● Pago de licencias (si las hay).
● Garantías respecto al cumplimiento.
● Derechos sobre software de nueva creación.
Puntos importantes a tener
en cuenta en el contrato (II)
Garantías.
● La solución entregada suele disponer de una garantía de
funcionamiento durante un tiempo.
● En soluciones con módulos de SFA el integrador puede
quedar obligado a extender la garantía sin percibir
remuneración. En este caso, el contrato debe
determinar los componentes cubiertos con la garantía,
período de la misma y condiciones para su ejecución.
Preservación de fuentes.
● El contrato no suele especificar las condiciones de
acceso al código fuente, sino el responsable de su
preservación.
● Establecer condiciones de migración a versiones nuevas.
Puntos importantes a tener
en cuenta en el contrato (III)
Mantenimiento y evolución del software de
SFA.
● Una de las características mas particulares de los
productos basados en SFA es que el cliente es
independiente de su proveedor.
● Con los derechos de explotación y el código fuente
en la mano se puede cambiar con mayor facilidad
de empresa integradora y mantener o evolucionar
la solución implantada con otro proveedor en el
caso de surgir algún problema o el proveedor deje
de prestar sus servicios.
● El mantenimiento y evolución del producto basado
en SFA suele ser abierto y flexible.
 Checklist GPL para
integradores
Antes de distribuir el SFA bajo la GPL se debe:
● Asegurar que todos los titulares de los componentes
han cedido sus derechos y permiten distribuirlos
junto con los componentes licenciados bajo GPL.
● Comprobar que los proveedores están obligados a
rectificar en caso de incumplimiento de las
condiciones o derechos establecidos.
● Verificar que dichos proveedores han proporcionado
todos los materiales necesarios para cumplir con
la GPL (código fuente, scripts, etc).
● Constatar que los demás componentes de la
aplicación, integrados en el SFA, tienen licencias
compatibles con la GPL.
 Checklist GPL para
vendedores
A la hora de distribuir el SFA bajo la GPL:
● Verificar que el paquete incluye una copia de cada
licencia de los componentes del SFA.
● Revisar que se han mantenido o puesto los avisos de
copyright de los titulares de los componentes.
● Ver si incluye cualquier aviso legal requerido.
● Examinar si el paquete incluye una copia del código
fuente de cualquier componente licenciado bajo la
GPL distribuido de forma binaria o, una oferta de
proporcionar dicho código fuente al usuario.
● Confirmar que la versión del código fuente es la correcta
y corresponde al código binario.
● Asegurar que incluye los scripts y otros elementos
necesarios para compilar e instalar el software.
GRACIAS POR SU
ATENCIÓN

¿PREGUNTAS?