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

© Javier Soriano

Introducción

© Javier Soriano

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

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]

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

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

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,

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

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)

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)

DIAPOSITIVA 11

Tipos de licencias

© Javier Soriano

http://ec.europa.eu/idabc/servlets/Doc1d95.pdf?id=2007

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%

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?

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 documentació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

DIAPOSITIVA 15

Características de las principales licencias

© Javier Soriano

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?

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”

DIAPOSITIVA 18

Apache

© Javier Soriano

DIAPOSITIVA 19

GPL

© Javier Soriano

DIAPOSITIVA 20

Affero GPL

© Javier Soriano

DIAPOSITIVA 21

LGPL

© Javier Soriano

DIAPOSITIVA 22

MIT

© Javier Soriano

DIAPOSITIVA 23

Artistic

© Javier Soriano

DIAPOSITIVA 24

BSD

© Javier Soriano

DIAPOSITIVA 25

Eclipse

© Javier Soriano

DIAPOSITIVA 26

Mozilla

© Javier Soriano

DIAPOSITIVA 27

No License

© Javier Soriano

DIAPOSITIVA 28

Public Domain Dedication

© Javier Soriano

Derechos de autor y copyright

© Javier Soriano

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

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

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

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

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

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)

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)

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

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)

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

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

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

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

Protección del software como propiedad industrial: Patentes

© Javier Soriano

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

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

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)

DIAPOSITIVA 47

Definición

© Javier Soriano

http://webshop.ffii.org/

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

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

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.

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.

DIAPOSITIVA 52

Casos de estudio

© Javier Soriano

DIAPOSITIVA 53

Casos de estudio

© Javier Soriano

DIAPOSITIVA 54

Casos de estudio

© Javier Soriano

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.

DIAPOSITIVA 56

Casos de estudio

© Javier Soriano

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):

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

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

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”

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

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

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

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

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

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

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.

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

Motivación económica del OSS

© Javier Soriano

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]

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

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”

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

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

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)

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

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

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

Modelos y estrategias de negocio basadas en software libre

© Javier Soriano

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

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)

DIAPOSITIVA 82

Estrategia de optimización

© Javier Soriano

Fuente: F. Van der Linden, B. Lundell, P. Marttiin, Commodification of Industrial Software, IEEE Software, 2009

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

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

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

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

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

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

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

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)

Gobernanza de comunidad / ecosistema

© Javier Soriano

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