Aspectos Legales del Software de Fuentes Abiertas

Aspectos Legales del Software de
Fuentes Abiertas

Marcos Blanco Galán
Coordinador de Certificación y Calidad del Software.
Centro de Excelencia de Software Libre José de Espronceda.

25.11.2009

Aspectos Legales del Software de Fuentes Abiertas

¿Qué es CENATIC?

Centro Nacional de Referencia de Aplicación de las Tecnologías de la
Información y la Comunicación (TIC) basadas en fuentes abiertas.

Fundación Pública Estatal constituida por el Ministerio de Industria, Turismo y
Comercio, a través de Red.es y con el apoyo de la Junta de Extremadura.

Objetivo:
Fomento y difusión de las TIC de fuentes abiertas en todos los ámbito de la sociedad.

- Asesoramiento jurídico y técnico a administraciones públicas y empresas.
- Certificación: Estudio de viabilidad técnico-financiera para certificaciones HESP.
- Observatorio nacional: Vigilancia tecnológica, casos de éxito, etc.
- Capacitación: Cursos, actuaciones divulgativas, detección de necesidades formativas.
- Proyectos: Validación DNI electrónico, Visor ODF para dispositivos móviles...
- Difusión y comunicación: Publicación de informes y estudios.
- Cooperación con otras entidades.

URL: http://www.cenatic.es


¿Qué es la CRUE?

Conferencia de Rectores de Universidades Españolas.

Asociación sin ánimo de lucro formada por universidades públicas y privadas
españolas. (50 universidades públicas y 24 privadas actualmente)

Objetivo:
Fomentar la colaboración entre universidades españolas, extranjeras e instituciones.

URL: http://www.crue.org


En este curso también colaborán:

● Universidad de Extremadura
● CIRL (Centro Internacional de Referencia Linux)
● CESEX-CESJE (Centro de Excelencia de Software Libre José de Espronceda)


“GUÍA DEL DERECHO Y EL SOFTWARE
DE FUENTES ABIERTAS”
http://cirl.unex.es/downloads/cenatic-alsfa09.pdf


Contenido del curso

1. INTRODUCCIÓN

2. LAS LICENCIAS DE SOFTWARE DE FUENTES ABIERTAS

3. LAS LICENCIAS DE SFA EN LA PRÁCTICA

4. LOS DERECHOS DE AUTOR

5. OTRAS NORMAS APLICABLES


1. Introducción


1. INTRODUCCIÓN

OBJETIVO:

Presentar, con un enfoque generalista, los principales aspectos jurídicos del SFA.

DESTINATARIOS:

Personas, empresas y entidades en todos los sectores que participen en la creación,
integración y uso de software de fuentes abiertas.

Particularizando según el lugar donde nos encontramos:

Estudiantes, investigadores y profesores universitarios que, desarrollando
software en un marco institucional educativo o de manera independiente, tienen
previsto utilizar o liberar software bajo licencia de fuentes abierta.


1. INTRODUCCIÓN
SOFTWARE DE FUENTES ABIERTAS

Antes de continuar definiremos y aclararemos tres conceptos relacionados entre sí:

● Software de fuentes abiertas
● Software libre
● Copyleft

¿Qué es el software de fuentes abiertas (SFA)?

Aquél que se distribuye bajo una licencia de fuentes abiertas. Una licencia de SFA
es garantiza las “libertades del software” y cumple con las directrices establecidas
por la OSI (Open Source Initiative).


1. INTRODUCCIÓN

Las libertades del software (software libre):

Libertad 0: Libertad de usar el programa, con cualquier propósito.

Libertad 1: Libertad de estudiar el funcionamiento del programa y poder adaptarlo.

Libertad 2: Libertad de distribuir copias.

Libertad 3: Libertad de mejorar el programa y hacer públicas las mejoras.

Las libertades 1 y 3 implican la necesidad de acceder al código fuente.


1. INTRODUCCIÓN

Los 10 criterios de la OSI (Open Source Definition):

1. Redistribución libre: Gratuita o no, software completo o componentes.

2. Código fuente: De forma conjunta o separada, pero fácilmente accesible.

3. Obras derivadas: Posibilidad de modificación, permite distribución bajo la misma
licencia que el software original.

4. Integridad del código fuente del autor: Los obras derivadas a partir del código
fuente original pueden requerir ser renombradas o modificar el número de versión.

5. No discriminación con respecto a personas o grupos.

6. No discriminación con respecto a sectores de actividad.


1. INTRODUCCIÓN

Los 10 criterios de la OSI (Open Source Definition):

7. Distribución de la licencia: Al entregar el software se ceden automáticamente los
derechos asociados al programa.

8. La licencia no tiene que ser específica de un producto: Los derechos asociados
al programa extraído de un producto mayor no deben depender de éste.

9. La licencia no debe limitar a otro software: No deben imponerse restricciones
sobre otro software que se distribuya conjuntamente.

10. Licencia neutra respecto a la tecnología: La licencia ha de ser independiente de
una tecnología o interfaz particular.


1. INTRODUCCIÓN
SOFTWARE DE FUENTES ABIERTAS. LICENCIAS

● Las libertades del software son expresadas de varias maneras jurídicamente.

● Las particularidades dan origen a cerca de 70 licencias de SFA reconocidas por OSI.

http://www.opensource.org/licenses/alphabetical

● En general, suele hacerse distinción de licencias SFA “con” o “sin” copyleft.


1. INTRODUCCIÓN
SOFTWARE DE FUENTES ABIERTAS: EL COPYLEFT

PLANTEAMIENTO DEL PROBLEMA:

● Según las libertades del software, sería posible incluir SFA en otro software y
redistribuir el resultado bajo licencia restrictiva o “cerrada”.

● Este tipo de acciones priva al usuario de las libertades originalmente cedidas.

Las licencias de SFA con copyleft van más allá, obligando al licenciatario a:

Utilizar la misma licencia libre del software original en la redistribución
del software original y modificaciones.

Proporcionar u ofrecer acceso al código fuente a todos los usuarios.

Copyleft dice NO! a las licencias privativas.


1. INTRODUCCIÓN
LICENCIAS LIBRES Vs. LICENCIAS DE FUENTES ABIERTAS

● Diferencias de carácter filosófico:

Software Libre: “Todo el software debería de ser libre, tengo derecho a saber
qué está haciendo mi máquina” (visión moral)
Libertades sin restricción, las limitaciones son inmorales.

Open Source: “El software es mejor si su código es abierto” (visión práctica)
Promueve la calidad, seguridad, evolución, creatividad...

● Jurídicamente, los términos licencia “libre” y de “fuentes abiertas” son sinónimos.

● Para incluir ambas ideas en un único concepto: FOSS / FLOSS.


1. INTRODUCCIÓN
LOS EFECTOS DEL SFA

El impacto del SFA a nivel jurídico y práctico es muy importante. La posibilidad de usar
software bajo una licencia SFA y ejercer los derechos concedidos permite:

● Descargar aplicaciones de internet libremente y habitualmente de forma gratuita.
● Realizar una instalación para probar y evaluar el software, sin ningún compromiso.
● Modificarlo para adaptarlo a nuestras necesidades (o contratar a alguien que lo haga).
● Integrarlo en nuestro negocio, en cuantos equipos necesitemos, actualizarlo, etc.
● Distribuirlo en el formato que elijamos para que otros también puedan beneficiarse.


1. INTRODUCCIÓN
LOS EFECTOS DEL SFA

No hay que negociar una licencia con un vendedor, establecer
contratos de soporte exclusivos o calcular los equipos o usuarios que
van a utilizar el software en cuestión.


1. INTRODUCCIÓN
LOS EFECTOS DEL SFA

Consecuencias indirectas del uso de SFA:

● Reutilización de componentes o aplicación completa.

● Independencia de proveedores, favorece la competencia.

● Creación de comunidades a través de difusión masiva en la red.

● Modelo de negocios basado en servicios (soporte, customización, formación...)

● Colaboración entre usuarios finales y entre desarrolladores.


1. INTRODUCCIÓN
LOS EFECTOS DEL SFA. EL CONCEPTO DE 'COMUNIDAD'

Conjunto de personas y organizaciones que participan en la creación, distribución y
uso del Software de Fuentes Abiertas.

Ejemplos: Debian, KDE-Hispano, Ubuntu-es, MySQL-Hispano, Morfeo, ASOLIF...


2. Licencias SFA


2. LICENCIAS SFA
LA LICENCIA DE SOFTWARE

Según el Derecho español, una licencia de software es:

El contrato por el cual un programa autoriza al licenciatario a utilizarlo*,
cediéndole los derechos necesarios para este uso.

EULA (End User License Agreement)
CLUF (Contrato de Licencia de Usuario Final )

La licencia software tiene una doble función:

● Asegurar los derechos de los usuarios (autorizaciones).

● Reservar y proteger los derechos del titular.

* Concepto muy amplio: Instalación, uso, parametrización, adaptación, distribución...


2. LICENCIAS SFA
LA LICENCIA DE SOFTWARE


2. LICENCIAS SFA
LICENCIAS NO LIBRES O PRIVATIVAS

Una licencia software privativa de usuario final concede, básicamente, el derecho a
la instalación del software en el ordenador del usuario y su ejecución, de acuerdo
con determinadas condiciones y restricciones.

● Obligaciones:
Pago de derechos de licencia, prohibición de copia, modificación, redistribución,
descompilación, ingeniería inversa...

● Restricciones:
Número de procesadores (cores), usuarios conectados simultáneamente, número
de BBDDs accedidas, cantidad de datos procesados, distribuidor exclusivo...

Podría decirse que existen tantas licencias no libres como programas propietarios.


2. LICENCIAS SFA

Dentro de las licencias no libres o privativas encontramos:

Freeware

- Suele permitir el uso gratuito del programa.
- Permite copiar y distribuir, pero no acceder al código ni modificarlo.
- El software suele proveer funcionalidad completa.
- El software puede contener publicidad (adware).

Ejemplos: MSN Messenger Plus Live
ImgBurn


2. LICENCIAS SFA

Dentro de las licencias no libres o privativas encontramos:

Shareware

- Suele permitir el uso gratuito del programa.
- Permite copiar y distribuir, pero no acceder al código ni modificarlo.
- El software suele incorporar limitaciones funcionales o de tiempo de uso .
- Una aplicación shareware habitualmente es conocida como 'demo'.
- El software puede contener publicidad (adware).

Ejemplos: Kaspersky Antivirus
WinRAR


2. LICENCIAS SFA
TIPOS DE LICENCIAS SFA


2. LICENCIAS SFA

Los licencias SFA también pueden tener en cuenta otros aspectos que los autores
han considerado importantes:

● Prohibición del uso del nombre del titular para promover el software.
Ejemplo: Apache Software License

● El alcance de las licencias de patente.
Ejemplo: MPL, CPL, GPLv3

● El derecho aplicable y la jurisdicción competente para resolver conflictos.
Ejemplo: MPL, GPLv3

● Delimitación de derechos/obligaciones e indemnizaciones.
Ejemplo: Eclipse Public License


2. LICENCIAS SFA

Los licencias SFA también pueden tener en cuenta otros aspectos que los autores
han considerado importantes:

● Aspectos sobre la forma de distribuir el software o sus modificaciones, ej: parches.
Ejemplo: QtPL

● Los avisos sobre estas modificaciones.
Ejemplo: MPL, GPL

● El acceso al código fuente mediante sistemas remotos.
Ejemplo: OSL, CDDL, Affero GPL


2. LICENCIAS SFA
LICENCIAS PERMISIVAS (sin copyleft)

Originalmente, la mayoría de este tipo de licencias proceden de:

- Investigaciones.
- Trabajos universitarios financiados por el gobierno (EEUU).

Sólo debían protegerse los derechos morales de los autores (titularidad).

También son denominadas LICENCIAS ACADÉMICAS, y suelen llevar el nombre de
una universidad:

● MIT: Massachusetts Institute of Technology
● BSD: Berkeley Software Distribution


2. LICENCIAS SFA
LICENCIAS CON COPYLEFT FUERTE

● Exigen el uso de la misma licencia en redistribuciones y modificaciones.

● Exigen el uso de la misma licencia en los programas que lo utilizan (ej: librerías).

● En ocasiones, algunas personas se refieren a ellas como “víricas”.

● GPL es la licencia SFA con copyleft más fuerte conocida. (75% proyectos Sourceforge)

● Otras licencias con copyleft fuerte: Affero GPL, Sleepycat.

Objetivo principal:

El copyleft fuerte evita la privatización o cierre
de un software en aplicaciones privativas.


2. LICENCIAS SFA
LICENCIAS CON COPYLEFT FUERTE: SERVICIOS REMOTOS

Si tenemos en cuenta que...

● El copyleft sólo se activa con la redistribución del software.

● Los servicios de software remotos no distribuyen código, sólo funcionalidades.

Entonces...

→ Los proveedores que ofrecen servicios basados en software GPL
no están obligados a proporcionar el código a los usuarios finales.
(ej: Google)

Algunos piensan... ¿fallo de copyleft? ¿fallo de la licencia GPL?

Affero GPL (AGPL) es una variante de GPL que incluye la obligación de proporcionar también a los
usuarios remotos del software una copia del programa y su código fuente.


2. LICENCIAS SFA
LICENCIAS MIXTAS O CON COPYLEFT SUAVE

● La claúsula copyleft sólo afecta al código original.

● No afecta a otros programas que lo integren o utilicen como librería.

● Se pierde la característica “viral” del copyleft fuerte.

● El conjunto podría ser distribuido bajo una nueva licencia (privativa o libre)

Dos formas de diluir el copyleft:

● Permitiendo que el software sea usado como librería en programas con licencia distinta.
Ejemplo: LGPL (Lesser GPL)

● Permitiendo que el software sea incorporado en una obra mayor con licencia distinta.
Ejemplo: MPL, CDDL (Common Development and Distribution License)


2. LICENCIAS SFA
LICENCIAS MIXTAS O CON COPYLEFT SUAVE

Estas licencias son muy usadas en SFA de tipo empresarial porque:

Permiten a otros profesionales del sector (integradores) añadir
extensiones o módulos para sus clientes finales bajo cualquier licencia.

Ejemplos: - Openbravo (ERP, Planificación de recursos empresariales)
- Socialtext (Software proveedor de redes sociales y colaboración)
- Pentaho (Reporting empresarial, análisis de datos, workflow, cuadro de mandos)


2. LICENCIAS SFA
PRINCIPALES LICENCIAS DE SFA

A continuación, veremos las siguientes licencias:

● Berkeley Software Distribution (BSD) modificada: licencia permisiva.

● Apache Software Licence 2.0 (ASL 2.0): licencia permisiva.

● GNU General Public License (GPL v2 y v3): con copyleft fuerte.

● GNU Library o Lesser General Public License (LGPL v2 y v3): con copyleft suave, o mixta.

● Mozilla Public License 1.1 (MPL 1.1): con copyleft suave, o mixta.

● European Unión Public License 1.1 (EUPL 1.1): con copyleft suave, o mixta, explícitamente
compatible con ciertas licencias copyleft más usadas.


2. LICENCIAS SFA
PRINCIPALES LICENCIAS DE SFA: La licencia new-BSD

Berkeley Software Distribution modificada.
Surge en los años 80. Inicios del movimiento FOSS. Univ. de California, Berkeley.

● Es una de las licencias libres más permisivas.
● Uso del software sin límites.
● Redistribución de binarios y código fuente.
● Posible modificar el software e integrarlo en otros programas, incluso propietarios.
● Se debe mantener el aviso de titularidad.
● Se excluyen garantías y responsabilidades.
● No se hace referencia a patentes o marcas.


2. LICENCIAS SFA
PRINCIPALES LICENCIAS DE SFA: La licencia ASL 2.0

Apache Software License 2.0.
Utilizada para distribuir el software de la Fundación Apache (y otros programas).

● Licencia libre permisiva.
● Otorga derechos de uso, modificación y redistribución de fuentes y binarios.
● Se excluyen garantías y responsabilidades en la medida de la ley aplicable.
● Debe mantenerse una copia de la licencia en el código fuente.
● Deben indicarse las modificaciones realizadas en la obra original.
● No se hace referencia al derecho aplicable o jurisdicción competente.
● Compatible con la mayoría de licencias SFA.


2. LICENCIAS SFA
PRINCIPALES LICENCIAS DE SFA: La licencia GPL 2.0

GNU General Public License 2.0.
Su principal objetivo es garantizar las libertades del software y evitar su restricción.

● Licencia copyleft por antonomasia.
● Deben aparecer los avisos de titularidad.
● Las obras derivadas o integraciones aplicarán la misma licencia (copyleft fuerte).
● El binario debe distribuirse con los fuentes, o bien, estar accesible durante 3 años.
● Se excluyen garantías y responsabilidades en la medida de la ley aplicable.
● No se hace referencia a patentes, marcas ni derecho aplicable.
● Compatible con las licencias más permisivas: http://www.gnu.org/licenses/license-list.html#SoftwareLicenses


2. LICENCIAS SFA
PRINCIPALES LICENCIAS DE SFA: La licencia GPL 3.0

GNU General Public License 3.0.
Resultado de un proceso de revisión de la versión anterior (es más compleja).

Objetivos de la revisión:

● Adoptar un vocabulario no sujeto a interpretaciones jurídicas preexistentes.
● Actualización de referencias tecnológicas (ej: P2P para hacer accesible el código).
● Compatibilidad con nuevas licencias (ej: ASL 2.0)
● Responder a los sistemas DRM (Digital Rights Managements): El DRM no es una protección
tecnológica efectiva. (tivoización)
● Responder a las patentes de software: Permiso indefinido y gratuito para posibles patentes
que cubra el software. Licencia ilimitada de patente.


2. LICENCIAS SFA
PRINCIPALES LICENCIAS DE SFA: La licencia Lesser GPL

GNU Lesser GPL (LGPL).
Su objetivo es permitir enlazar componentes software con licencias distintas.

● Licencia copyleft suave, o mixta.
● Mismas libertades y restricciones que la licencia GPL.
● El copyleft (suave) afecta a la explotación de modificaciones.
● Permite enlazar incluso con licencias de software que no son SFA.
● Pérdida del miedo al copyleft (no es un copyleft fuerte).
● Licencia cómoda y atractiva para desarrolladores que integran software.


2. LICENCIAS SFA
PRINCIPALES LICENCIAS DE SFA: La licencia MPL 1.1

Mozilla Public License 1.1.
Creada en la liberación del navegador web Netscape en 1998.
Utilizado en productos Mozilla y muchas otras aplicaciones libres.

● Otorga licencia de patente.
● Deben aparcer los avisos de titularidad, exclusión de garantías y responsabilidades
en el código fuente.
● Al redistribuir el software deben indicarse las modificaciones realizadas.
● La licencia somete al derecho californiano y tribunales de Santa Clara (California).
● Permite “dual licensing” (empleo de dos licencias para parte o todo el software).


2. LICENCIAS SFA
PRINCIPALES LICENCIAS DE SFA: La licencia EUPL 1.1

European Union Public License 1.1.
Redactada expresamente para la liberación de software de la administración pública
europea y de los países miembros de la UE (2007). Copyleft similar a la OSL 3.0.
OSI certificó la licencia EUPL 1.1 como open source en febrero de 2009.

● Otorga derechos de uso, modificación, distribución, sublicencia, alquiler y préstamo
sobre el programa y obras derivadas, en forma de código fuente y binario.
● Otorga licencia de patente.
● Deben aparcer los avisos de titularidad y modificaciones realizadas.
● La licencia somete al derecho del proveedor del software.
● La distribución por medios telemáticos ha de implicar la aceptación con un 'clic'. El
proveedor está obligado a publicar la información legal.


3. Licencias de SFA
en la práctica


3. LICENCIAS DE SFA EN LA PRÁCTICA
COMPATIBILIDAD ENTRE LICENCIAS

● Las licencias SFA imponen distintas condiciones a la hora de explotar el software.

● Pueden aparecer incompatibilidades jurídicas entre licencias.

● Las incompatibilidades no suponen un problema en el desarrollo interno / pruebas.

● El verdadero problema aparece a la hora de distribuir el producto final.


ASPECTOS SOBRE LA COMPATIBILIDAD ENTRE LICENCIAS

1. Si todos los componentes de la aplicación se reciben y se distribuyen bajo la
misma licencia, no existe ningún problema.

2. La integración de componentes bajo licencias permisivas en otros programas no
debería ser un problema (incluso en software propietario).

3. El verdadero conflicto surge al integrar dos licencias con copyleft. Ambas
licencias exigirán el uso de la propia licencia para redistribuir el software.


SELECCIÓN DE UNA LICENCIA

● La selección de una licencia de distribución es una decisión muy importante.

● La elección debe tomarse cuanto antes mejor.

● La licencia adoptada determinará la compatibilidad con otras licencias.

● La licencia elegida dependerá de:

La posibilidad de integrar otros componentes en el producto.

Cuestiones estratégicas de comercialización.

● No es una tarea sencilla: casi 70 licencias de SFA (OSI).


SELECCIÓN DE UNA LICENCIA

Reflexión antes de elegir una licencia concreta:

¿Creamos una licencia específica para mi producto o puedo recurrir a una de las licencias
reconocidas por la OSI?
Las licencias SFA de OSI estandarizadas y muy extendidas. Estudio de integración más sencillo.

¿Cuáles son los objetivos de la liberación del software?
Ej: Filosóficos (“libertad”), vistas comerciales, resultado de investigación, iniciativa pública...

¿Qué tipo de software voy a crear?

Ej: Si se trata de un futuro componente, no será apropiado aplicar un copyleft fuerte.


ESCOGER MÁS DE UNA LICENCIA

Las licencias de SFA no son exclusivas, por lo que pueden usarse varias licencias
para un mismo software. Se denomina régimen de licencia dual.

Ejemplo:

● GPL a usuarios finales e intermediarios que distribuyen su software bajo licencias libres.

● Licencia propietaria a intermediarios o integradores que venden su software a usuarios finales
bajo este tipo de licencias


4. Los derechos de autor


INTRODUCCIÓN Y ORIGEN

- Inicialmente, el software no se comercializaba de manera independiente.

- Hardware y software se distribuían conjuntamente, como un único bien comercializado.

- Los avances tecnológicos dotaron al software de mayor relevancia respecto al hw.

- Necesidad de salvaguardar las inversiones necesarias en la creación del sofware.

Protección del Derecho de la propiedad intelectual


¿QUÉ SON LOS DERECHOS DE AUTOR?

Los derechos de autor controlan la explotación y defienden ante la apropiación
o uso ilegítimo por parte de terceras personas.

El software y la documentación preparatoria se consideran una obra “intelectual”
cubierta por los derechos de autor según la LPI (Ley de Propiedad Intelectual).

Esta ley concede al titular originario del software (normalmente el autor) el derecho a realizar y/o
autorizar a terceros la copia, modificación y (re)distribución del programa. Esta concesión exclusiva
permite a los titulares del software autorizar y delimitar el acceso, uso y explotación del software por
parte de terceros, a través de contratos o licencias.

Aprobación de la LPI: Real Decreto Legislativo 1/1996, de 12 de abril.


LPI Y LOS PROGRAMAS DE ORDENADOR

La LPI incluye expresamente los “programas de ordenador” en la lista, no
exhaustiva, de obras protegidas. Esta ley los define de la siguiente manera:

“toda secuencia de instrucciones o indicaciones destinadas a ser utilizadas, directa o
indirectamente, en un sistema informático para realizar una función o una tarea o para
obtener un resultado determinado, cualquiera que fuere su forma de expresión y fijación. La
expresión 'programas de ordenador' comprenderá también su documentación preparatoria.”
(Artículo 96)


OBRAS PROTEGIDAS:

● Sistemas operativos
● Programas de uso general y programas desarrollados a medida.
● Compiladores, librerías, otros componentes de software, scripts, servlets.
● Motores de bases de datos.
● Entornos de desarrollo, runtimes.
● Servidores de aplicaciones.
● Instrucciones incorporadas en los chips (microcódigo, firmware).
● Programas que soportan las redes de telecomunicaciones (en routers, hubs, etc).


LOS DERECHOS DE AUTOR CUBREN:

● Código fuente y objeto.
● Imágenes, iconos, gráficos, etc. incluidos en el programa.
● Scripts de compilación e instalación.
● Documentación preparatoria: diagramas de diseño, especificaciones, listados, etc.
● Documentación técnica y manual de usuario.
● Versiones sucesivas de un programa.
● Modificaciones del original (obras derivadas).
● La estructura y contenido de bases de datos.


5. Otras normas
aplicables


EL DERECHO DE LA PROPIEDAD INDUSTRIAL

● Los derechos de autor protegen el código y documentación, pero no ideas y principios.
● Necesario proteger de la labor inventiva y creativa en un contexto industrial y económico.
● Se crean dos figuras jurídicas: la patente y la marca.

Las funcionalidades de un software podrían protegerse mediante la figura de la
patente, siempre que se consideren una invención y cumpla la condiciones establecidas en
la 'Ley de Patentes'. Las patentes están limitadas territorialmente (lugar donde se ha
registrado y concedido) y temporalmente (20 años).

La marca puede ser utilizada de forma exclusiva para identificar categorías de
productos y servicios. Ejemplos: Mozilla, Suse, Apache.


PATENTES DE SOFTWARE A NIVEL INTERNACIONAL

En los EEUU y algunas otras jurisdicciones como Japón y Australia, se permite
conceder patentes sobre “cualquier cosa inventiva y útil”, incluso el software, a
pesar de existir un gran debate entorno a la utilidad y legalidad de su patentabilidad.

En 2005, se intentó incorporar la patentabilidad del software en el marco jurídico de
la Unión Europea, con la fallida y rechazada Propuesta de Directiva sobre las
“Invenciones Implementadas por Ordenador”.

Puede ser peligroso incorporar las patentes de software en Europa


Enlaces de interés

● Guía de CENATIC sobre Aspectos Legales del SFA: http://cirl.unex.es/downloads/cenatic-alsfa09.pdf

● Legislación Informática en España: http://www.informatica-juridica.com/legislacion/espana.asp

● Free Software Foundation: http://www.fsf.org/

● Licencias compatibles y no compatibles con GPL: http://www.gnu.org/licenses/license-list.html

● Open Source Initiative: http://www.opensource.org/

● Ley de Propiedad Intelectual: http://www.mcu.es/propiedadInt/docs/RDLegislativo_1_1996.pdf

● Ley de Patentes de Invención: http://noticias.juridicas.com/base_datos/Admin/l11-1986.html


Gracias :)

Fuente: http://pillateunlinux.files.wordpress.com/2008/12/no-soft-privativo.png

El contenido de esta obra ha sido puesto a disposición del dominio público por su autor.

Aspectos Legales del Software de Fuentes Abiertas

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (6)

Similar a Aspectos Legales del Software de Fuentes Abiertas

Similar a Aspectos Legales del Software de Fuentes Abiertas (20)

Último

Último (20)

Aspectos Legales del Software de Fuentes Abiertas