Guía del derecho y el software de fuentes abiertas. Alfonso López Murcia alfonso@um.es Universidad de Murcia

Transcripción

1 Guía del derecho y el software de fuentes abiertas Alfonso López Murcia alfonso@um.es Universidad de Murcia

2 GUIA DEL DERECHO Y EL SOFTWARE DE FUENTES ABIERTAS Versión de diciembre de 2009 Esta presentación se distribuye bajo licencia Creative Commons 3.0 Reconocimiento-No comercial-compartir disponible en Este documento está disponible en

3 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.

4 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.

5 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.

6 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.

7

8 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.

9 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.

10 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.

11 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.

12 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.

13 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).

14 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.

15 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.

16 Entender las licencias Licencias - TiraEcol

17 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.

18 Clasificación del software

19 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.

20 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.

21 Mapa conceptual FLOSS w i k i p e d i a

22 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.

23 Clasificación licencias SFA Clasificación según el grado de copyleft

24 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.

25 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.

26

27 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.

28 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.

29 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.

30 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.

31 Modernización GPLv2 La GPLv2 fue creada en A finales de 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.

32 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.

33 Compatibilidad de licencias GPLv2 es compatible con GPLv3 si permite GPLv2 o cualquier licencia posterior

34 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.

35 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.

36 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.

37 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.

38 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.

39 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.

40 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).

41 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.

42 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).

43 Conocer tipo licencia Podemos verlo en wikipedia.

44 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.

45 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).

46 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). 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. wikipedia

47 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.

48 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.

49 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.

50 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.

51 Empresas y organizaciones Adaptado de presentación Peter Carbone.

52 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.

53 Niveles 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).

54 Niveles 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.

55 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.

56 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.

57 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.

58 Mapa conceptual SFA

59 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.

60 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.

61 Caso 1 Proyecto básico (I) El software es de nueva creación y no integra ningún componente de terceros.

62 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.

63 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.

64 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.

65 Caso 2 Proyecto complejo (I) Integra componentes de SFA de terceros.

66 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.

67 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).

68 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.

69 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.

70 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.

71 Caso 3 Proyecto maduro (I)

72 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.

73 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.

74 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).

75 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.

76 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).

77 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.

78 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.

79 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).

80 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.

81 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.

82 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).

83 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?

84 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.

85 Arquitectura solución SFA

86 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.

87 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.

88 Que se puede hacer o no Licencia Puede GPL u otra con copyleft fuerte Distribuir su solución al cliente bajo la misma licencia, proporcionándole el código fuente. Puede cobrar por el producto o servicio, soporte y mantenimiento. 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. Mixta (copyleft suave, como LGPL, MPL, CDDL, OSL, etc.) El integrador puede cobrar por licencia (por una extensión propietaria agregada al producto original, por ejemplo), mientras que el SFA originario deberá distribuirse bajo la misma licencia. Puede cobrar la implementación, soporte y mantenimiento. No puede Cederlo al cliente bajo términos mas restrictivos. Vender licencias.

89 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 ).

90 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.

91 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.

92 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.

93 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.

94 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.

95 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.

96 GRACIAS POR SU ATENCIÓN PREGUNTAS?