El documento aborda la diferencia entre software libre y software de código fuente abierto, destacando sus respectivas licencias y libertades fundamentales. Se examinan diversas licencias, incluyendo GPL, BSD y LGPL, y se discuten sus características, implicaciones y el proceso de elección de licencias para proyectos de software. Además, se resalta la importancia de la propiedad intelectual y los derechos de autor en el contexto del software y su protección legal.

1. Seminario COM
COM strategy on open source software
community and licensing
Boadilla del Monte, Marzo 2014
Materiales: http://goo.gl/n5HFsi
© Javier Soriano

2. Introducción
© Javier Soriano

3. DIAPOSITIVA 3
Software Libre y Software de código fuente abierto
© Javier Soriano
n Software Libre (Free Software, FSF, 1984)
n “Free as in freedom”: Énfasis en lo
filosófico, ético y político del movimiento
n Licencias tipo GPL (víricas, con “copyleft”)
n Software de código fuente abierto (Open
Source Software –OSS, OSI, 1998)
n Perspectiva más pragmática y orientada al
mundo empresarial
n Se adopta la OSD (surge de las “Debian
Free Software Guidelines”)
n Licencias tipo BSD (académicas,
permisivas)
n Elemento unificador: Las cuatro libertades del
software enunciadas por la Free Software
Foundation
n Separan lo que es libre de lo que no lo es y
sirven de herramienta de análisis unificador
de las licencias de software libre
n Más de 70 licencias certificadas OSI

4. DIAPOSITIVA 4
Las libertades fundamentales del software
© Javier Soriano
n Software libre o de código fuente abierto: aquel en el que el autor cede una
serie de libertades básicas al usuario “licenciatario” en el marco de un
acuerdo de concesión de licencia:
n Ejecutar y utilizar el programa, para cualquier propósito;
n Estudiar el funcionamiento del programa, y adaptar su código a
necesidades específicas;
n Redistribuir copias;
n Modificar el programa, y poner sus mejoras a disposición del público,
para beneficio de toda la comunidad
Free Software Foundation
n Uso, copia, modificación, distribución [y acceso al código fuente]

5. DIAPOSITIVA 5
Definiciones
© Javier Soriano
n Software de código fuente abierto: sus términos de distribución cumplen los
criterios de
n Distribución libre;
n Inclusión del código fuente;
n Permitir modificaciones y trabajos derivados en las mismas condiciones que el
software original;
n Integridad del código fuente del autor, pudiendo requerir que los trabajos
derivados tengan distinto nombre o versión;
n No discriminación a personas o grupos;
n Sin uso restringido a campo de actividad;
n Los derechos otorgados a un programa serán válidos para todo el software
redistribuido sin imponer condiciones complementarias;
n La licencia no debe ser específica para un producto determinado;
n La licencia no debe poner restricciones a otro producto que se distribuya junto
con el software licenciado;
n La licencia debe ser tecnológicamente neutral

6. DIAPOSITIVA 6
Definiciones
© Javier Soriano
n Propiedad intelectual: Derechos de autor o copyright: sistema de protección
proporcionado por las leyes vigentes en la mayoría de los países para los autores de
creaciones humanas originales incluyendo obras literarias (incl. software),
dramáticas, musicales, artísticas e intelectuales, tanto publicadas como pendientes
de publicar
n Confieren al autor o titular del software el derecho a realizar o autorizar a
terceros [mediante licencia] la reproducción o uso (instalar y ejecutar), la copia,
la modificación y la distribución y comunicación pública (subir a Internet) del
software
n Propiedad industrial: Sistema legal que protege el uso o la explotación de signos
distintivos que identifiquen productos o empresas (marcas), de las invenciones
(patentes) y de la información confidencial con valor económico (secretos
industriales)
n Patente: conjunto de derechos exclusivos garantizados por un gobierno o autoridad al
inventor de un nuevo producto (material o inmaterial) susceptible de ser explotado
industrialmente para el bien del solicitante por un periodo de tiempo limitado
n Hasta hace poco el software sólo estaba protegido por derechos de autor y no por
patentes. Esto ha cambiado recientemente

7. DIAPOSITIVA 7
Definiciones
© Javier Soriano
n Licencia: contrato entre el desarrollador o el titular de un software sometido a propiedad
intelectual y a derechos de autor y el usuario, en el cual se definen con precisión los
derechos y deberes de ambas partes. Es el desarrollador, o aquél a quien éste haya
cedido los derechos de explotación, quien elige la licencia según la cual distribuye el
software
n Es el instrumento legal que autoriza la explotación del software por terceros.
n Permite además al autor reservarse los derechos que no se ceden e imponer y
otorgar al usuario otras obligaciones y derechos no necesariamente vinculados con
los derechos de autor (confidencialidad, limitaciones de garantías, etc.)
n Licencia libre: aquella que respeta las cuatro libertades del software, permitiendo así
su uso, distribución, modificación, y el acceso al código fuente del mismo
n CLA (Contributor License Agreement): Define los términos bajos los cuales se
contribuye la propiedad intelectual a un proyecto (asignación de copyright, otorgamiento
de licencia irrevocable de uso, acuerdo sobre la licencia a usar). Útil para defensa ante
disputas de copyright, relicenciamiento,

8. DIAPOSITIVA 8
Definiciones
© Javier Soriano
n Software de dominio público (“unlicense”): aquél que no está protegido con
copyright
n Software con “copyleft”: software libre cuyos términos de distribución no
permiten a los redistribuidores agregar ninguna restricción adicional cuando lo
redistribuyen o modifican, o sea, la versión modificada debe ser también libre
n Software semi-libre: aquél que no es libre, pero viene con autorización de
usar, copiar, distribuir y modificar para particulares sin fines de lucro
n Freeware: se usa comúnmente para programas que permiten la redistribución
pero no la modificación (y su código fuente no está disponible)
n Shareware: software con autorización de redistribuir copias, pero debe pagarse
cargo por licencia de uso continuado
n Software privativo: aquél cuyo uso, redistribución o modificación están
prohibidos o necesitan una autorización
n Software comercial: el desarrollado por una empresa que pretende ganar
dinero por su uso

9. DIAPOSITIVA 9
Tipos de licencias
© Javier Soriano
n Permisivas – tipo BSD: permiten que otras versiones posteriores puedan tener otros tipos de
licencias, tanto BSD o GPL o incluso propietarias
n Más atractivas para la industria del software. Otorgan más libertades a los desarrolladores
n Obligan a mantener exclusivamente el aviso de autoría (copyright) [derechos morales] y la
negación de garantías y de responsabilidad (disclaimer)
n Con copyleft robusto – tipo GPL: aplica el concepto de “copyleft”, obligando a que toda
redistribución del software (de la propia aplicación, de las nuevas versiones mejoradas de la
aplicación –obra derivada, y de éste integrado en otro software más amplio) sea siempre libre y
licenciada bajo las mismas condiciones de GPL (vírica)
n Menos atractiva para la industria del software. Otorgan más libertades a los usuarios
n Aceptada por operadores informáticos más centrados en el equipo físico y en los servicios
n Con copyleft limitado – tipo MPL o LGPL:
n Mantienen las obligaciones de copyleft para el núcleo del programa distribuido pero
permiten a su vez su integración en obras con otras licencias
n Aplican licencias dobles al código fuente y a los ejecutables, obligando a informar al autor
original de los fuentes modificados (que seguirán estando en abierto por efecto del
“copyleft”) y permitiendo licenciar los binarios como propietarios (se prohíbe su
redistribución a través de una sencilla reproducción del medio)

10. DIAPOSITIVA 10
Tipos de licencias
© Javier Soriano
n Con copyleft limitado – tipo MPL o LGPL:
n Niveles:
n A nivel de módulo
n A nivel de fichero
n A nivel de interfaz de librería
n Ayudan a “productizar” un código OSS mediante la adición de componentes privativos y la
venta de licencias para estas partes privativas
n “Unlicense” (dominio público)

11. DIAPOSITIVA 11
Tipos de licencias
© Javier Soriano
http://ec.europa.eu/idabc/servlets/Doc1d95.pdf?id=2007

12. DIAPOSITIVA 12
Tipos de licencias
© Javier Soriano
Licencia 2014 %
GNU GPL v2 114.573 58,02%
GNU Library/Lesser GPL v2 19.309 9,77%
GNU GPL v3 16.581 8,39%
BSD 15.175 7,68%
Apache License v2 7.324 3,7%
MIT 6.494 3,28%
Academic Free License 4.024 2,03%
GNU Library/Lesser GPL v3 2.867 1,45%
Artistic License 2.068 1,04%
Mozilla Public License v1.1 1.777 0,9%
Apache Software License 1.668 0,84%
Common Public License v1 1.573 0,79%
Open Software License v3 1.532 0,77%
Eclipse Public License 1.338 0,67%
Affero GNU Public License 1.156 0,58%
SourceForge.net, 70.364 proyectos (Feb. 2005)
SourceForge.net, 197.459 proyectos (Feb. 2014)
Licencia 2005 2014
GPL 66,1% 61,4%
LGPL 10,9% 10,3%
BSD 6,9% 7,7%
Otras con certificado OSI 12,1% 13,3%
Resto (dominio público,
propietarias, etc.)
4,0% 7,3%

13. DIAPOSITIVA 13
Tipos de licencias
© Javier Soriano
n ¿Qué software de terceras partes incluye tu proyecto?¿qué licencias tiene?
n ¿A quién va dirigido tu proyecto?
n ¿Qué tipo de contribuciones esperas?¿incluye organizaciones comerciales?
n ¿Qué uso futuro esperas hacer de él?
n ¿Requerirás en un futuro crear una versión privativa del mismo que incluya las
contribuciones recibidas del exterior?
n ¿Tienes previsto añadir funcionalidades como código privativo?
n ¿Esperas que en un futuro tu código se incorpore a un sistema mayor?
n ¿Por qué liberas tu proyecto?
n ¿porque necesitas que otros proyectos lo utilicen para hacer compatible tu hardware?
n ¿porque quieres influir en la adopción de un estándar?
n ¿Puede ofrecerse como un servicio (aaS) desde la nube o utilizando un modelo de computación
basado en servidor?
n ¿Es tu proyecto una librería?
n ¿Existen otras soluciones privativas ampliamente utilizadas (por software privativo)?
n ¿Te preocupan las patentes de software y sus posibles efectos?

14. DIAPOSITIVA 14
Elección de la licencia
© Javier Soriano
Trabajo original Trabajo derivado
Licencia ¿Se obliga
a distribuir
el código
fuente?
Se distribuye
sólo el
ejecutable –
¿precio libre?
Se distribuye
tanto el
código fuente
como el
ejecutable –
¿precio libre?
¿Se tiene
que
distribuir
bajo la
misma
licencia?
¿Debe
distribuirse el
código
fuente?
¿Debe
incluir un
aviso de
copyright?
¿Debe
incluir
documentac
ión?
GPL v2 SI NO SI SI SI SI SI
LGPL
v2.1
SI NO SI SI, si está
basado en
una librería
NO, si está
enlazado a
una librería
SI, si está
basado en una
librería
NO, si está
enlazado a
una librería
SI SI
BSD NO SI SI NO NO SI NO
MIT NO SI SI NO NO SI NO
Artistic SI No aplicable –
Debe distribuir
los fuentes
NO NO NO NO SI

15. DIAPOSITIVA 15
Características de las principales licencias
© Javier Soriano

16. DIAPOSITIVA 16
Licenciamiento dual
© Javier Soriano
n Implica la liberación del software bajo una licencia con copyleft estricto (e.g.
GPL) al mismo tiempo que se hace disponible una versión bajo una licencia
alternativa que permite a los usuarios que no deseen ligarse a GPL pagar
por una versión sin copyleft
n Esta segunda licencia adicional sin copyleft requiere del acuerdo de todos
los colaboradores o la posesión de toda la propiedad intelectual sobre el
código
n Introduce una sobrecarga administrativa importante
n ¿Estarán interesados los clientes en pagar por el derecho a producir
productos derivados sin copyleft?

17. DIAPOSITIVA 17
Licenciamiento de elementos no software
© Javier Soriano
n Si el proyecto incluye otros elementos diferentes del código fuente con
propiedad intelectual, tales como imágenes, sonidos, documentación o
bases de datos, piense en utilizar licencias más apropiadas como:
n Creative Commons: http://creativecommons.org/choose/
n Open Data Commons: http://opendatacommons.org/licenses/
n Public Domain Dedication and License (PDDL) — “Public Domain
for data/databases”
n Attribution License (ODC-By) — “Attribution for data/databases”
n Open Database License (ODC-ODbL) — “Attribution Share-Alike
for data/databases”

18. DIAPOSITIVA 18
Apache
© Javier Soriano

19. DIAPOSITIVA 19
GPL
© Javier Soriano

20. DIAPOSITIVA 20
Affero GPL
© Javier Soriano

21. DIAPOSITIVA 21
LGPL
© Javier Soriano

22. DIAPOSITIVA 22
MIT
© Javier Soriano

23. DIAPOSITIVA 23
Artistic
© Javier Soriano

24. DIAPOSITIVA 24
BSD
© Javier Soriano

25. DIAPOSITIVA 25
Eclipse
© Javier Soriano

26. DIAPOSITIVA 26
Mozilla
© Javier Soriano

27. DIAPOSITIVA 27
No License
© Javier Soriano

28. DIAPOSITIVA 28
Public Domain Dedication
© Javier Soriano

29. Derechos de autor y copyright
© Javier Soriano

30. DIAPOSITIVA 30
Definiciones
© Javier Soriano
n Derechos de Autor: Expresión jurídica que describe los derechos concedidos a los
creadores por sus obras originales. El sistema del derecho anglosajón usa el término
copyright
n Derechos de explotación (reproducción o uso, copia, modificación, distribución,
difusión)
n Derechos morales (no considerados en el copyright, menos “personalista” y más
colectivista o centrado en la creación)
n El software está sometido a derechos de autor (Berna) al considerarse en la categoría
“documentos de referencia” (obra literaria). Las bases de datos también
n La protección por derechos de autor tiene incidencia sobre la forma, el continente, la
expresión de la idea creativa, pero no sobre el contenido (la idea).
n Ni el material de inspiración (hechos, fechas, etc.) ni las ideas son protegidas por los
derechos de autor
n El concepto de obra elegible incluye los programas informáticos en cuanto a
su código, descripción técnica del proyecto y materiales de apoyo, pero no sus
algoritmos
n Sólo protege el programa en cuanto bien inmaterial, independientemente del
soporte en el que se fije el mismo

31. DIAPOSITIVA 31
Objeto de protección en el software
© Javier Soriano
n El programa de ordenador
n La documentación preparatoria
n Los manuales de uso y la documentación técnica de apoyo
n El código fuente
n El código objeto
n La arquitectura del programa, que incluye diagramas de flujo, modelos de
datos, diagramas en UML, etc.
n Las interfaces, incluyendo elementos gráficos, sonidos, tipografías y otros
elementos audiovisuales
n Las bases de datos

32. DIAPOSITIVA 32
Objetivos
© Javier Soriano
n Recompensar la creatividad
n Estimular la innovación
n Contribuir al desarrollo económico
n Salvaguardar el interés público

33. DIAPOSITIVA 33
Ventajas
© Javier Soriano
n Automatismo: El derecho de autor nace por el mero hecho de la
creación original. No se requiere novedad
n Simplicidad: La protección de una obra no requiere inscripción en
registros, cumplimiento de formalidades ni examen previo de
adecuación
n Economía: La protección no requiere importantes inversiones
económicas
n Cobertura: La protección se extiende a la documentación
accesoria (diseños, modelos de datos, manuales, etc.)
n Internacionalización: La protección se otorga, en virtud de
tratados internacionales, prácticamente a nivel mundial y de manera
muy armonizada

34. DIAPOSITIVA 34
Requisitos para la protección
© Javier Soriano
n Creación humana, fruto del intelecto del autor y consecuencia de su
actividad
n Expresada en cualquier medio o soporte tangible o intangible [del
cual pueda ser percibido, reproducido o de otra manera
comunicado, bien directamente o con ayuda de una máquina o
dispositivo]
n Original (diferente de novedosa), fruto de un esfuerzo personalizado
(que no sea copia de otras obras)
n Puede requerirse una “huella de la personalidad” o determinado
nivel de creatividad

35. DIAPOSITIVA 35
Autores y titulares de derechos
© Javier Soriano
n Obra en colaboración (cotitularidad o “joint ownership” en el sistema de copyright), resultado
unitario de la colaboración de varios autores
n Los derechos sobre la misma corresponden a todos ellos en la proporción que determinen (cada
autor es titular de su aportación y del conjunto de la obra). La explotación es conjunta
n La divulgación y la modificación de la obra requiere el consentimiento de TODOS los autores
n Admite explotación separada por aportaciones siempre que no se cause perjuicio a la explotación
común
n Obra colectiva, creada por iniciativa y bajo la coordinación de una persona física o jurídica, que
la edita y divulga bajo su nombre y que se considera su autor
n Programa creado por asalariados en el seno de una relación laboral materializada
n Si es en el ejercicio de sus funciones que le han sido confiadas y siguiendo las instrucciones de su
empleador, la titularidad de los derechos económicos correspondientes corresponderán,
exclusivamente, al empresario, salvo pacto en contrario
n En los sistemas continentales, persiste la titularidad de los derechos morales
n Obra creada por encargo
n No regulada en España (ni en la Directiva de la UE)
n La jurisprudencia establece que, salvo pacto en contrario, no existirá transmisión de derechos. En
EEUU es al contrario (work-for-hire)

36. DIAPOSITIVA 36
Autores y titulares de derechos
© Javier Soriano
n Obras en colaboración
n Es esencial acordar entre los autores, tan pronto como sea posible, la
licencia y el régimen de explotación de la obra resultante
n Obras colectivas
n Los proyectos de desarrollo deben asegurarse de que cada autor-
contribuyente transfiera por escrito sus derechos, de manera exclusiva
o no, a la entidad coordinadora para que esta pueda administrar
correctamente los derechos de propiedad intelectual de la aplicación y,
en concreto, determinar el régimen de licencia, asegurar la defensa
ante infracciones, etc. (http://www.gnu.org/licenses/why-assign.en.html)
n Ejemplos: Mozilla.org, GNU dela FSF, Jboss, Jesper Reports,
OpenOffice.org, SugarCRM, etc.
n Condiciones de la FSF para cualquier contribución de más de 10
líneas de código, por las que deben transferir la titularidad del
código a la FSF (CLA)

37. DIAPOSITIVA 37
Obra original y obra derivada
© Javier Soriano
n Una obra derivada es aquella obra nueva que resulta de la transformación
de una obra preexistente, sin la colaboración del autor de esta última,
aunque sí con su autorización (para que sea lícita)
n Por modificación (agregación, eliminación o modificación de
elementos)
n Por integración en una obra mayor, derivada del componente
(dependiendo de la forma de integración)
n Por uso: no necesariamente incluye el simple uso o vinculación con la
obra original
n Una implementación del código fuente para otro hardware o dispositivo es
una obra derivada
n El software binario se entiende como una transformación del código fuente
n Dificultad para discernir entre obra derivada, obra en colaboración y obra
colectiva

38. DIAPOSITIVA 38
Prevención de conflictos de autoría
© Javier Soriano
n En relación con el proceso de creación de software libre
n “Conciencia de contribución”. Arriesgado
n Ausencia de reclamo por parte de los contribuyentes
n Gestión de la propiedad intelectual
n Acuerdo explícito sobre las condiciones de colaboración (la cesión
implícita de derechos no es válida legalmente)
n Acuerdo de cesión de derechos (CLA, contribution agreement)
n Exigencia de que las contribuciones se hagan bajo la licencia del
proyecto o bien una compatible
n En relación con el uso y la explotación del software libre
n Autorización, o no, de la creación de obras derivadas
n Control, o no, de la difusión y el uso de estas obras derivadas
(copyleft)

39. DIAPOSITIVA 39
Marco normativo
© Javier Soriano
n Convención de Berna (Organización Mundial de la Propiedad Intelectual, Naciones
Unidas, http://www.wipo.int)
n Convenio de la Unión de Berna para la Protección de Obras Literarias y Artísticas de
1886, con una última revisión de 1979
n Tres principios básicos: Trato nacional, automatismo y simplicidad, consideración de
los derechos morales (derecho a reclamar la autoría de la obra y a oponerse a
modificaciones de la misma aun cuando se hayan cedido los derechos, con la
consiguiente reparación de daños)
n Acuerdo sobre los Aspectos de los Derechos de la Propiedad Intelectual relacionados con
el Comercio de 1994 (Organización Mundial del Comercio, http://www.wto.org)
n Obliga a los estados signatarios a acatar las disposiciones de la Convención de
Berna, salvo los requisitos sobre derechos morales
n Protege los programas de ordenador como obras literarias, obligando a los estados
signatarios en este sentido aun cuando no sean signatarios de la Convención de
Berna
n Impone a los estados signatarios la obligación de conceder a los titulares de
derechos de autor sobre un programa de ordenador el derecho de autorizar o
prohibir el alquiler de sus productos

40. DIAPOSITIVA 40
Marco normativo
© Javier Soriano
n Dos nuevos tratados en 1996 en el marco de la OMPI para adaptar los derechos de autor
a la evolución de las tecnologías, principalmente a Internet
n Tratado de la OMPI sobre Derechos de Autor (6 marzo 2002)
n Se ocupa de la protección de los autores de obras literarias y artísticas,
incluyendo programas informáticos y bases de datos originales
n Aplicación de sus disposiciones:
n Directiva de Derechos de Autor en la UE
n Digital Millenium Copyright Act (DMCA) en los EEUU
n Tratado de la OMPI sobre Interpretación o Ejecución y Fonogramas

41. DIAPOSITIVA 41
Marco normativo
© Javier Soriano
n Directiva 91/250/CEE del Consejo, de 14 de mayo de 1991, relativa a la protección jurídica de
programas de ordenador, modificada por la Directiva 93/98/CEE del Consejo, de 29 de octubre de 1993
(la Directiva de Programas de Ordenador).
n Establece que los programas de ordenador se protegerán por los derechos de autor como obras
literarias, de acuerdo con la Convención de Berna.
n Directiva 2001/29/CE, de 22 de mayo de 2001, relativa a la armonización de determinados aspectos de
los derechos de autor y derechos afines a los derechos de autor en la sociedad de la información (la
Directiva de Derechos de Autor en la Sociedad de la Información)
n Pretende actualizar toda la normativa vigente, cumpliendo los compromisos asumidos en virtud
del Tratado de la OMPI sobre Derechos de Autor
n Amplía los conceptos de reproducción y de comunicación pública (que incluye ahora el derecho
de poner la obra a disposición del público)
n Directiva 2004/48/CE de 29 de abril de 2004, relativa al respeto de los derechos de propiedad
intelectual
n Tiene como objeto establecer las medidas, procedimientos y recursos necesarios para garantizar
el respeto de los derechos de propiedad intelectual
n España implementó la Directiva en 2006
n Las bases de datos encuentran su protección bajo un régimen especial de derechos similares a los de
autor, en la Directiva 96/9/CE, sobre la protección jurídica de las bases de datos

42. DIAPOSITIVA 42
Marco normativo español
© Javier Soriano
n El Código Civil español, en sus artículos 428 y 429, remite la regulación de
la propiedad intelectual a una ley especial (LPI), y declara la aplicación
supletoria de las reglas generales establecidas en el mismo sobre la
propiedad para lo que no está específicamente previsto en dicha ley
especial
n Ley de Propiedad Intelectual (LPI)
n Texto refundido fue aprobado por el Real Decreto Legislativo 1/1996,
de 12 de abril
n Modificado por la Ley 23/2006, de 7 de julio, que transpone la Directiva
2001/29/CE
n Normas reglamentarias de desarrollo
n Los programas de ordenador se regula en el artículo 95 y siguientes de la
LPI

43. Protección del software como propiedad
industrial: Patentes
© Javier Soriano

44. DIAPOSITIVA 44
Definición
© Javier Soriano
n Una patente es un derecho
dado por un Estado a un
inventor sobre su invención,
que permite a este último
excluir a terceras partes de
explotar su invención durante
un periodo de tiempo limitado

45. DIAPOSITIVA 45
Principales características
© Javier Soriano
n Las patentes son territoriales (el derecho de patente sólo
cubre el país que lo otorga).
n Duración: 20 años desde la solicitud
n Concesión: Nuevas e inventivas
n Da una protección más extensa que los derechos de autor:
protege las acciones generales que realiza el software,
independientemente de los detalles específicos y del código
fuente utilizado
n Es un derecho registral: Nace con la solicitud (registro) de la
patente, si no, no hay tal derecho
n Obliga a la divulgación de la invención (depósito legal)
n Subjetividad

46. DIAPOSITIVA 46
Patentes de software: Situación actual
© Javier Soriano
n Protección del software por el sistema de patentes (propiedad industrial) en
EEUU, de manera generalizada desde los inicios de los años noventa
n Se permiten las patentes de software como tal
n En los últimos años se está tendiendo a ser más estrictos en cuanto a
la protección de invenciones sin características técnicas
n Aparición de diversos conflictos jurisdiccionales sobre las patentes de
software
n Directiva Europea sobre patentes de software
n Sólo se admiten las patentes de software cuando éste se considera
como un producto adicional de una invención patentable
(mediante su ejecución se realiza un proceso que resuelve un
problema técnico) y sólo en esa medida el software es patentable (no
como tal)

47. DIAPOSITIVA 47
Definición
© Javier Soriano
http://webshop.ffii.org/

48. DIAPOSITIVA 48
Casos de estudio: Invenciones claramente admitidas
© Javier Soriano
n Programa que dirige las piezas de un
telar para manejar el hilo de una cierta
forma más rápida y con menos gasto
n Sistema de frenado ABS y programa que
lo gestiona (en verdad es un método)
n Programa que controla una bomba de
insulina

49. DIAPOSITIVA 49
Casos de estudio: Otras invenciones admitidas
© Javier Soriano
n Procedimiento para determinar una ruta óptima
de transmisión de datos en una red de datos
n Gestión del tráfico en redes de comunicación
n Detección de activación de un abonado en una
red de telefonía móvil
n Todas estas invenciones suponen la realización
de un determinado método con envío de
mensajes en determinados momentos, cálculos
criptográficos, activación de servidores, cálculos
de congestión, cálculos de tráfico y, sobre todo,
conllevan la resolución de un problema
técnico

50. DIAPOSITIVA 50
Casos de estudio: Ejemplos de reivindicaciones admitidas
© Javier Soriano
n ES2226562: Método para detectar la
activación de un abonado en una red, que
comprende:
n Generar y enviar un mensaje a un nodo
de registro de la red, incluyendo el
mensaje datos sobre […]
n Programa de ordenador, que comprende
instrucciones de programa para hacer que un
ordenador (procesador) lleve al cabo el
método de la reivindicación anterior cuando
el programa se ejecuta
n Procedimiento para determinar una ruta óptima de
transmisión de datos en una red de datos:
n Un primer abonado a la línea de transmisión
emite una notificación de búsqueda, unos
abonados a la red que pueden usarse como
estaciones de rutas de transmisión y reciben
esta notificación de búsqueda, miden las
intensidades de campo de recepción, añaden a
la notificación de búsqueda su propia marcación
y la intensidad de campo de recepción medida y
emiten de nuevo la notificación de búsqueda y
miden la intensidad de campo de recepción de
la notificación de búsqueda.
n Programa de ordenador, que comprende
instrucciones de programa para hacer que un
ordenador lleve al cabo el método de la reivindicación
anterior cuando el programa se ejecuta.

51. DIAPOSITIVA 51
Casos de estudio: Invenciones claramente excluidas
© Javier Soriano
n Software de procesado de datos
n Software de gestión de nóminas
n Software de métodos de negocio (e.g.
Cálculo del momento óptimo de
inversión por un valor en bolsa a partir
de un histórico y un cálculo de
estadísticas)
n Software de videojuegos
n Software de recomendación de
contenidos según un estudio de tus
preferencias personales, etc.

52. DIAPOSITIVA 52
Casos de estudio
© Javier Soriano

53. DIAPOSITIVA 53
Casos de estudio
© Javier Soriano

54. DIAPOSITIVA 54
Casos de estudio
© Javier Soriano

55. DIAPOSITIVA 55
Casos de estudio
© Javier Soriano
1. A method of controlling an electronic device with a touch-
sensitive display, comprising:
- detecting contact with the touch-sensitive display while the
device is in a user-interface lock state;
- moving an image corresponding to a user-interface unlock
state of the device in accordance with the contact;
- transitioning the device to the user-interface unlock state if
the detected contact corresponds to a predefined gesture;
and
- maintaining the device in the user-interface lock state if the
detected contact does not correspond to the predefined
gesture.

56. DIAPOSITIVA 56
Casos de estudio
© Javier Soriano

57. DIAPOSITIVA 57
¿Puede cualquier software ser objeto de patente?
© Javier Soriano
n NO se consideran invenciones (no se
pueden patentar):
n Descubrimientos (fórmulas,
propiedades, elementos, etc), teorías
científicas y métodos matemáticos
n Las obras literarias artísticas o
cualquier otra creación estética
n Formas de presentar informaciones
n Los planes, reglas y métodos para el
ejercicio de las actividades
intelectuales, para juegos o para
actividades económico-comerciales,
así como los programas para
ordenadores
Art. 52 (2) EPC (Europa) y Art.
4(4) Ley 11/1986 (España):

58. DIAPOSITIVA 58
¿Puede cualquier software ser objeto de patente?
© Javier Soriano
n (ES) Lo dispuesto en el apartado anterior
excluye la patentabilidad de las
invenciones mencionadas en el mismo
SOLAMENTE en la medida en que el
objeto para el que la patente se solicita
comprenda una de ellas.
n (EP) Lo dispuesto en el párrafo anterior
excluye la patentabilidad de los
elementos enumerados en el mismo
SOLAMENTE en la medida en que la
solicitud de patente europea o la patente
europea no se refiera más que a uno de
esos elementos considerados como
tales
Art. 52 (3) EPC y Art. 4(5) Ley
11/1986

59. DIAPOSITIVA 59
¿Puede cualquier software ser objeto de patente?
© Javier Soriano
n El software sólo es excluido si se refiere a
programas de ordenador como tales, es
decir, sin estar acompañados de alguna
invención o connotación inventiva (efecto o
carácter técnico)
n E.g. Una fórmula matemática está excluida
“per se”, pero no así un método para
optimizar el combustible gastado por un
trasbordador que para ello use esa fórmula
matemática.
n Una combinación de elementos patentables y
no patentables normalmente se admitirá,
pero puede requerirse que se elimine la parte
no patentable (o no se examinará) Art. 52 (3) EPC y Art. 4(5) Ley
11/1986

60. DIAPOSITIVA 60
¿Puede cualquier software ser objeto de patente?
© Javier Soriano
n Un programa de ordenador como tal no podrá
constituir una invención patentable
n No serán patentables las invenciones que utilizan
programas informáticos, expresados en código fuente,
en código objeto o en cualquier otra forma, que
implementan métodos para el ejercicio de actividades
económicas, matemáticos o de otro tipo y no producen
efectos técnicos, aparte de la normal interacción física
entre un programa y el ordenador, red o aparato
programable de otro tipo en que se ejecute
n Un programa de ordenador se puede patentar si es
parte de una invención que lo utiliza y que sí es
patentable por producir efectos técnicos (más allá de
la normal interacción física entre un programa y el
ordenador…)
n Se considera como un producto adicional de una
invención patentable y sólo en esa medida es
patentable
Directiva 11979/1/04 del 7 de marzo de
2005 del parlamento europeo
Directiva Europea de 20 de febrero de
2002 sobre “invenciones
implementadas en ordenador”

61. DIAPOSITIVA 61
¿Puede cualquier software ser objeto de patente?
© Javier Soriano
n Si el programa de ordenador es capaz,
cuando es ejecutado por un ordenador, de
producir un efecto técnico adicional (es decir,
aparte de los efectos físicos normales que se
producen cuando cualquier programa se
ejecuta en un ordenador), y constituye una
invención nueva e inventiva, el programa es
patentable
n El concepto de efecto técnico es ambiguo y a
veces no es tan fácil decidir si un programa
produce un efecto técnico adicional o no
n E.g. Poner en marcha y optimizar el
funcionamiento de una cadena de
producción
Guidelines C-IV, 2.3.6

62. DIAPOSITIVA 62
¿Puede cualquier software ser objeto de patente?
© Javier Soriano
n Se considera que un programa tiene un efecto
técnico si:
n Afecta al funcionamiento físico o técnico de
un dispositivo
n Procesa datos que son parámetros
operativos de un dispositivo y de cuyo
resultado depende el funcionamiento
técnico de dicho dispositivo
n Y en general, si resuelve un problema
técnico
n Por tanto siempre va ligado a un
proceso que resuelve un problema
técnico mediante su ejecución y debe
reivindicarse el proceso amén de
las reivindicaciones de programa
ligadas al proceso
Guidelines C-IV, 2.3.6

63. DIAPOSITIVA 63
¿Puede cualquier software ser objeto de patente?
© Javier Soriano
n ¿Qué se considera un problema técnico?
n Ahorro de recursos (ancho de
banda, energía, etc.),
n Aumentar/disminuir velocidad,
n Aumentar/disminuir precisión
n ¿Qué se considera un problema no
técnico?
n Apariencia estética,
n Apariencia visual
n Preferencias personales
Guidelines C-IV, 2.3.6

64. DIAPOSITIVA 64
Casos de estudio
© Javier Soriano
n Ejemplo 1: Se quiere proteger un
programa que calcula los impuestos que
tienen que pagarse basándose en los
ingresos y patrimonio
n No tiene ningún efecto técnico à No
se puede proteger como patente
n Pero sí se puede proteger como
propiedad intelectual, así que hay
que registrarlo
Guidelines C-IV, 2.3.6

65. DIAPOSITIVA 65
Casos de estudio
© Javier Soriano
n Ejemplo: Se desarrolla un método para el
enrutamiento óptimo de mensajes en redes
wireless
n Es patentable (si es nuevo e inventivo), por
lo que se puede obtener protección para el
método y para un programa que lleve a
cabo dicho método
n El programa en sí, también se puede
proteger por propiedad intelectual
n Si otros copian el programa, se puede
demandar por infracción de la patente y del
copyright
n Si alguien copia el método pero escribe un
programa distinto pata llevarlo a cabo, no
puedes protegerse con el copyright pero sí
con la patente
Guidelines C-IV, 2.3.6

66. DIAPOSITIVA 66
Casos de estudio
© Javier Soriano
n Un programa de ordenador que pone en
marcha una cadena de montaje
n Un programa que calcula a partir de unos
parámetros cogidos de un material la
resistencia de cierto material
n Un programa que calcula la velocidad a la
que tiene que ir cierto dispositivo o la
cantidad de combustible que necesita un
avión para hacer una trayectoria
determinada, a partir de datos de la
velocidad, trayecto, altura, velocidad del
viento, etc.
n Un programa que calcula la velocidad de
funcionamiento de cierta maquinaria para que
consuma el mínimo de energía.
Guidelines C-IV, 2.3.6

67. DIAPOSITIVA 67
Procedimientos
© Javier Soriano
n OEPM y EPO, distintas formas de actuar, mismos
resultados.
n OEPM: Análisis de la patentabilidad (del
carácter técnico) en el Examen formal (antes
del informe de búsqueda). Si no lo tiene
(software sin efecto técnico) se emite un
suspenso y se rechaza si no se corrigen los
problemas.
n EPO: Excepto en casos muy extremos, suele
hacer el informe de búsqueda y realiza el
examen de carácter técnico en el examen
(después del informe de búsqueda)
n Si no tiene características técnicas
(software sin efecto técnico) o, las
diferencias con los inventos anteriores
son características no técnicas, entonces
no tendrá actividad inventiva y se
rechaza.

68. DIAPOSITIVA 68
Licencias OSS y patentes
© Javier Soriano
n Si se libera código que incorpore patentes software (proceso embebido en
software) bajo una licencia OSS, entonces estará muy seguramente
otorgando derechos para usar la patente relevante (en conexión con ese
código) a cualquiera que elija usarlo, incluso cuando la licencia no lo diga
explícitamente (como paso necesario para “usar” el código licenciado)
n No obstante no podrá extender su funcionalidad para capturar otras
patentes software
n Apache v2 otorga de manera explícita los derechos de uso de patente
(de manera perpetua, universal, no-exclusiva, sin cargos ni regalías y
de manera irrevocable) necesarios para usar, adaptar y distribuir el
software licenciado que la incorpora
n Cláusula disuasoria de “patent retaliation”: Esencialmente establece que
cualquiera que emprenda una acción legal alegando que el software
licenciado incorpora una de sus patentes software perderá la licencia
obtenida para copiar, usar, adaptar y distribuir el código

69. Motivación económica del OSS
© Javier Soriano

70. DIAPOSITIVA 70© Javier Soriano
n “Las compañías deberían usar OSS para incrementar sus
comunidades de usuarios y construir un ecosistema en torno a sus
productos y servicios”
[Ron Goldman & Richard Gabriel “Innovation Happens Elsewhere”,
Morgan Kaufmann, 2005]

71. DIAPOSITIVA 71
Tipos de OSS
© Javier Soriano
n OSS liderado y gestionado por comunidades
n E.g. Apache Web server (httpd.apache.org)
n El control, el roadmap y la estrategia recae en los committers
n Foco en la “economía de la fuerza de trabajo” (voluntariado)
n Gratificación personal debida al incremento de reputación
n Demostración de capacidad técnica y perspectivas de mejora laboral
(E.g. Ranking de salarios de colaboradores en proyectos de la ASF)
n Satisfacción con el trabajo
n Reduce el problema de “lock-in” (en tecnología, roadmap, etc.)
n Asegura que los precios de soporte están sujetos a fuerzas de mercado y
no a una corporación

72. DIAPOSITIVA 72
Tipos de OSS
© Javier Soriano
n OSS comercial (liderado y gestionado por una empresa con ánimo de lucro)
n E.g. MySQL database (www.mysql.com)
n La empresa posee (copyright) y desarrolla el software (las contribuciones
externas tienen un propósito principal de “marketing”)
n Lo que se “vende” no es el software en sí, sino su provisión,
mantenimiento, soporte y el desarrollo de mejoras [privativas]
n Puede aprovechar algunos de los beneficios del OSS gestionado por
comunidades: rapidez de adopción, feedback de usuario rápido y gratuito
y, posiblemente, esfuerzo de desarrollo voluntario
n Ayuda a reducir la competencia “open source”

73. DIAPOSITIVA 73
Perspectiva del Integrador de Sistemas: Curva de Demanda de
Soluciones de TI
© Javier Soriano
Dirk Riehle, “The Economic Motivation of Open Source
Software: Stakeholder Perspectives”, IEEE Software
n Los Integradores de Sistemas
pueden cargar precios similares
a los clientes incluso si utilizan
OSS (la bajada en los costes del
software no se repercuten en los
clientes)
n Manteniendo estable la oferta y
la demanda, se puede hacer
más dinero en la parte de
provisión de servicios (punto
fuerte de los integradores de
sistemas) de la cadena de valor
si se bajan los costes del
software

74. DIAPOSITIVA 74
Perspectiva del Integrador de Sistemas: Márgenes de Venta y
número de clientes
© Javier Soriano
Dirk Riehle, “The Economic Motivation of Open Source
Software: Stakeholder Perspectives”, IEEE Software
n El OSS reduce el precio mínimo
para posibles ofertas
n (a) El límite inferior de precio
determina el número de clientes
conseguidos por el integrador de
sistemas
n (b) El cambio de software
privativo a OSS puede resultar
en más clientes y mayores
beneficios

75. DIAPOSITIVA 75
Perspectiva del Vendedor de Software
© Javier Soriano
Dirk Riehle, “The Economic Motivation of Open Source
Software: Stakeholder Perspectives”, IEEE Software
n En el negocio del software
privativo, la mayor parte de la
inversión en nuevo software
proviene del lanzamiento de la
primera copia. Con el aumento de
las copias vendidas se reduce el
coste por copia y se incrementan
los beneficios
n (a) y (c) muestran un coste medio
similar por “unidad” de software
privativo y OSS (aunque
compartido en este caso)
n (b) y (d) indican la relación entre
precio y número de “unidades”
vendidas para software privativo y
OSS (se vende su provisión,
mantenimiento, soporte y mejoras
privativas)

76. DIAPOSITIVA 76
Perspectiva del Vendedor de Software: “La Compañía de
Servicios Open Source”
© Javier Soriano
n Negocio open source exitoso: TAU vs TIDorb
n Proporciona servicios de soporte e implementación de primer nivel
n Servicios destinados a ayuda a integrar el producto open source en las
operaciones de TI del cliente
n Proporciona servicios de soporte, training y desarrollo de segundo nivel
n Servicios destinados a entrenar al personal de TI del cliente en el producto
open source o a solucionar un problema técnico
n Fortalezas de un negocio de servicios:
n Habilidad para reclutar y retener las personas adecuadas
n Habilidad para configurar y ejecutar procesos de servicio específicos de
manera confiable
n Habilidad para poner en juego el conocimiento de dominio experto y la
propiedad intelectual

77. DIAPOSITIVA 77
Perspectiva del Vendedor de Software: Puestos y promociones
en proyectos OSS
© Javier Soriano
(1) E. Raymond, “The Cathedral and the Bazaar”,
O’Reilly, 2001
n La promoción en OSS gestionado por
comunidades se basa en la
“meritocracia” (1)
n La promoción a “contributor” es implícita, al
aceptarse sus contribuciones por parte de
los “committers” de la comunidad
n La promoción a “committer” es explícita,
por votación entre los restantes
“committers” y en base a principios de
meritocracia
n A través de los “committers”:
n Se solucionan problemas más rápido
y mejor
n Se alinean mejor la estrategia de la
compañía y el proyecto OSS
n Se gana en imagen y se obtiene una
ventaja comercial (marketing)
n Se tiene mayor visibilidad y conexión
en/con la comunidad de usuarios

78. DIAPOSITIVA 78
Perspectiva del empleado
© Javier Soriano
n Los empleados se pueden reemplazar más fácilmente en entornos de OSS
comercial ya que generan menos conocimiento específico de la firma
n Al mismo tiempo, son más difíciles de retener gracias a la visibilidad que les
proporciona el esquema de “meritocracia” de las comunidades OSS
n Los esquemas de meritocracia suelen mantener reducido el grupo de
committers por cuestiones económicas
n La ventana de oportunidad es pequeña para aquellos que aspiran a convertirse
en committers en un proyecto OSS importante
n Invertir en un proyecto OSS es algo así como unirse a una startup
n Algunos proyectos esperan y exigen que sus committers tengan dedicación
plena al proyecto (e.g. Eclipse project)
n El OSS refuerza la tendencia a ver empleados que se convierten en “free
agents” ya que perciben que el valor de mercado está en el proyecto más que
en su empleador

79. Modelos y estrategias de negocio basadas
en software libre
© Javier Soriano

80. DIAPOSITIVA 80
Algunas estrategias OSS
© Javier Soriano
n Objetivos:
n Fomentar la innovación
n Crear valor de producto
n Atraer consumidores
n Generar ingresos

81. DIAPOSITIVA 81
Estrategia de optimización
© Javier Soriano
n “Ley de conservación de la modularidad” de Clayton Christensen
“When attractive profits disappear at one stage in the value chain because a
product becomes modular and commoditized, the opportunity to earn attractive
profits with proprietary products will usually emerge at an adjacent stage”
n Un nivel de una pila de software se hace “modular y conformable” permitiendo
”optimizar” los niveles adyacentes
n Los niveles “modulares y conformables” son “commodities” y como tales
no resultan rentables o sólo lo son de manera marginal como negocio
n Ejemplo: Linux à Su aparición sirvió para erosionar los márgenes de otros
vendedores de SSOOs
n Los ganadores bajo la ley de Christensen son los niveles interdependientes
adyacentes, en los que las aplicaciones se optimizan para conseguir un valor
añadido y un mayor beneficio potencial
n Ejemplo: Oracle y Electronic Arts à Versión Linux de su Oracle 9i Real
Application Cluster sobre servidores Linux x86 (“commodity”, menos
costosos que la solución basada en Solaris) à Mayor margen (Mainstay
Partners: ahorro de $2M, de los que $800K fueron ganancias para Oracle
y el resto ahorro para EA)

82. DIAPOSITIVA 82
Estrategia de optimización
© Javier Soriano
Fuente: F. Van der Linden, B. Lundell, P. Marttiin,
Commodification of Industrial Software, IEEE Software, 2009

83. DIAPOSITIVA 83
Estrategia de licencia dual
© Javier Soriano
n El uso gratuito conlleva algunas condiciones para prevenir que terceras partes puedan competir
con el OSS original, típicamente:
n Cualquier modificación que se distribuya debe hacer también públicas sus fuentes
n Las compañías no pueden usar la versión gratuita como un componente en ninguno de sus
productos o soluciones comercializadas
n Suele materializarse a través de dos licencias entre las que se puede escoger: Además de la
versión libre (normalmente distribuida bajo GPL) se ofrece una distribución comercial, sujeta a
tasas y con un mayor conjunto de funcionalidades y/o servicios
n Beneficios de ofrecer la licencia libre:
n Mayor visibilidad
n Adopción más rápida
n Genera menos reticencias que las prácticas asociadas a las licencias de prueba
n Posicionamiento competitivo más fuerte y con mejores defensas
n Mayor base de usuarios, que pueden encontrar errores, recomendar mejoras, etc.
n Ejemplo: MySQL
n Modelo por niveles: Cobra diferentes precios según el número de funcionalidades
n En Bitrock se obtienen beneficios de los servicios de mantenimiento y profesional gracias a
los usuarios que gana a través de su política de licenciamiento gratuito a determinados
proyectos OSS

84. DIAPOSITIVA 84
Estrategia de soporte
© Javier Soriano
n Según Culpepper “los ingresos provenientes de servicios de mantenimiento y consultoría se
incrementan en proporción relativa a los ingresos por licencias… una compañía software típica
tendrá el doble de ingresos por cada dólar de licencias”
Q1, 2004

85. DIAPOSITIVA 85
Estrategia de consultoría
© Javier Soriano
n ”Hace 30 años (dicho en 1999) cada departamento de TI en su país se
dedicaba a construir sus productos, y la industria del software creció en
torno a esa asunción… Ahora, el OSS sugiere un modelo de servicios
prácticamente puro, donde la funcionalidad básica no cuesta nada, y todo
el dinero se obtiene de la personalización” [Clay Shirky, 1999]
n A día de hoy:
n Los ingresos por licencias continúan cayendo y representan una
pequeña porción de la inversión en TI
n La consultoría y los servicios continúan creciendo
n Posibilidades para integradores de sistemas y “value-added resellers”:
n Integración de hardware, softwaree y mantenimiento
n Integración basada en middleware
n Formación y certificación

86. DIAPOSITIVA 86
Estrategia de patronazgo
© Javier Soriano
n Algunas compañías como IBM invierten dinero, energía, desarrolladores y código al
OSS con el fin de guiar la adopción de estándares y romper los mercados mas
afianzados
n Anticipa que un estándar de-facto y una comunidad de soporte convergerán en
torno a esa contribución
n Otros fabricantes de equipamiento OEM y proveedores de software han abrazado
también la estrategia de patronazgo
n También se utiliza el patronazgo para convertir en “commodity” un nivel particular de
la pila software, eliminando así competidores que están obteniendo ingresos de ese
nivel
n E.g. IBM y Linux à Objetivo eliminar las tasas de servidor de Microsoft
Windows y Sun/Oracle Solaris y facilitar el negocio en niveles superiores como
software de clustering, HA, provisionamiento, seguridad y gestión
n E.g. IBM y Apache http à Objetivo, eliminar el riesgo de monopolio por parte de
Microsoft. Apache paso del 50% al 70% del mercado

87. DIAPOSITIVA 87
Estrategia de patronazgo
© Javier Soriano
n Para que sea exitoso, el patronazgo debe implicar más que la mera contribución de
código. Debe asegurarse el liderazgo y la consistencia
n Mozilla es un claro ejemplo de proyecto que falló inicialmente en este sentido
n IBM abrió todas sus fuentes de Eclipse ($40M) y cambió el mercado de los IDE con
una propuesta de marco de trabajo estándar multiplataforma:
n Facilitó la integración de sus herramientas Rational
n Facilitó la formación en el entorno
n Convirtió en “commodity” el IDE y eso le permitió añadir valor en las
herramientas de nivel superior
n El riesgo está ahora en franquicias como Rational, Websphere, DB2 y Notes
n Sus inversiones en OSS del lado servidor ha convertido en “commodity” Sun/Oracle
Solaris y ha reducido el ritmo de adopción de servidores Microsoft en centros de
datos
n Aún no ha podido romper el monopolio de Microsoft Office

88. DIAPOSITIVA 88
La estrategia de software hospedado
© Javier Soriano
n “Los modelos basados en licencias y desarrollo se simplificarán
radicalmente. 2003 fue el año en el que vimos a un buen número de
compañías enfocar correctamente el modelo de proveedor de servicios:
compañías como Salesforce.com, eBay o Google están en el negocio del
software, pero no venden software, te permiten usarlo o rentarlo” [Scott
McNeely]
n Creciente importancia debido a la implantación del modelo SaaS
n Uso extensivo de software libre, incluso GPL

89. DIAPOSITIVA 89
La estrategia de software embebido
© Javier Soriano
n Los vendedores de hardware deben utilizar estándares y “commodities”,
incluyendo Linux, Android, etc. como estrategia de plataforma, y para subir
en la cadena de valor a través del desarrollo de nuevo software de valor
añadido

90. DIAPOSITIVA 90
Modelos de sostenibilidad para software propietario y OSS
comercial
© Javier Soriano
n Suscripción: Tasa por utilizar el
producto
n Venta de servicios de pago: soporte
básico, in-situ y premium
(resolución de problemas,
reparación depuración y
mantenimiento de sistemas o
aplicaciones)
n “Split-licensing”: Venta de una
licencia comercial a un cliente para
que utilice un producto licenciado
como libre
n Se recomienda integrar estos tres
modelos: 20% mín. de las
actividades se centran en “Split-
licensing”, 20% mín. se centra en
servicios, 60% máx. en suscripción)
Suscripción
Servicios “Split-licensing”
Encaje en el modelo de comercialización de IDC
(IDC, 2006)

91. Gobernanza de comunidad / ecosistema
© Javier Soriano

92. DIAPOSITIVA 92
Estrategia de gobernanza del COM
© Javier Soriano
n Figura legal que sustentará la gobernanza
n Estatutos: propósito, estructura organizativa y aspectos de funcionamiento
n Acuerdo de membresía: derechos y responsabilidades, circunstancias de terminación
n Política de propiedad intelectual
n Política de propiedad industrial: marcas registradas, patentes, secretos industriales
n Política de conformidad antimonopolio
n Modelos de registro, licenciamiento y distribución
n Proceso de desarrollo
n Modelo de contribución y CLA
n Ciclo de vida de los proyectos (incubación, etc.)
n Acuerdos de marca registrada/comercial
n Política de estándares y especificaciones
n Directrices para la revisión de dependencias de terceros
n Política de uso de herramientas propietarias
n Requisitos de usabilidad, interfaz, datos
n Otros elementos legales:
n Política de privacidad
n Términos y condiciones de uso del sitio web
n Infraestructura tecnológica ofrecida, servicios ofrecidos