miércoles, 30 de mayo de 2012

¿Estás en la nube? Las consecuencias que probablemente no sabías...

El “cloud computing” o “computación en la nube” es la prestación de servicios de carácter informático a través de internet, compartiendo determinados recursos que se encuentran en distintos emplazamientos. El término cloud o nube hace referencia, a través de una metáfora visual, a internet.


Aunque en ocasiones no seamos conscientes, en nuestro día a día utilizamos algún servicio de cloud, por ejemplo Picasa o Gmail podrían considerarse casos de cloud computing como Software as a Service.


Hay distintos servicios de cloud computing, la clasificación más habitual distingue entre:
  • Infrastructure as a Service (IaaS): un servicio de infraestructura a través de internet (por ejemplo un servidor). Relevante sobre todo para las empresas.
  • Platform as a Service (PaaS): una plataforma, es decir, una infaestructura con un sistema operativo. Relevante sobre todo para programadores informáticos para el desarrollo de aplicaciones.
  • Software as a Service (SaaS): incluye infraestructura, plataforma y aplicaciones.

También existen distintos tipos de cloud:
  • Public Cloud: toda la infraestructura del servicio se comparte de manera que los costes son reducidos.
  • Private Cloud: se implanta para el usuario (habitualmente una empresa) de manera exclusiva, lo que le permite un mayor control sobre aspectos como la seguridad de los datos.
  • Hybrid Cloud: una combinación del public y private cloud.
  • Community Cloud: se comparte una o más clouds entre empresas con intereses parecidos.

Las mayores ventajas del cloud computing (en sentido amplio) son la posibilidad de acceder a la información o al servicio que se requiere desde cualquier lugar donde tengamos acceso a internet, y la concentración para las empresas en su actividad principal sin tener que destinar tantos recursos al departamento informático (entendiendo recursos tanto humanos como monetarios).

Hoy nos vamos a centrar en la public cloud, donde las principales ventajas (además de las mencionadas) radican en el bajo coste monetario para el usuario y en la facilidad de la contratación. Estas dos ventajas son especialmente diferenciadoras respecto a un contrato de “IT outsourcing” o contrato de externalización de servicios informáticos. En un contrato de IT ousourcing generalmente el coste será mayor que el de una public cloud y la contratación constituye un proceso complejo y largo de negociaciones entre las partes (para otra ocasión queda un post sobre dicho proceso).

Sin embargo no todo son ventajas en el ámbito del public cloud. Los términos y condiciones de los contratos, habitualmente en formato click-wrap agreements (contratos que aparecen en la pantalla cuando por ejemplo vamos a instalar un software y donde tenemos que pulsar el botón aceptar para poder continuar con la instalación) son standard (no negociados individualmente) y suelen incluir algunos “riesgos” que deberían de ser valorados por los usuarios.

Las principales desventajas que plantea el cloud computing residen en cuatro ámbitos de riesgo:
  • Obligación o no de mantener un determinado nivel de calidad en la prestación del servicio.
  • La integridad, confidencialidad y seguridad de los datos. En las condiciones standard es bastante habitual incluir una limitación y exclusión de la responsabilidad por parte del prestador de servicios de cloud. Esta limitación suele redactarse de tal manera que el proveedor del servicio de cloud no se responsabiliza por la pérdida o la corrupción de los datos. Si bien, dada la arquitectura redundante de los centros de datos se reduce la gravedad de dicho riesgo.
  • La migración a un nuevo servidor de cloud. Imaginemos que queremos contratar una nueva empresa que nos preste el servicio de cloud computing. ¿Cómo de fácil será trasladar la información de una a otra? Por lo general la migración resulta, a día de hoy, complicada y problemática, especialmente para las empresas que manejen una gran cantidad de información a través del servicio de cloud.
  • La protección de datos. ¿Quién es el encargado del tratamiento (probablemente el proveedor de servicios) y quién el responsible del fichero (probablemente el usuario)? ya que la responsabilidad de uno y otro es diferente. ¿Se toman las suficientes medidas de seguridad para cumplir con la legislación vigente en materia de proteción de datos? ¿Dónde se encuentran los datos?

Por no leer las condiciones de los contratos nos podemos llevar, a posteriori, una sorpresa no demasiado agradable. Si bien, los riesgos que señalamos aquí no constituyen un rechazo al cloud computing, si no todo lo contrario, pues creemos en el futuro de este tipo de servicios y desde IP Sandwich lo que buscamos con éste post es informar al usuario de los puntos críticos que han de llamar su atención y que debe de valorar a la hora de elegir un servicio de cloud.

jueves, 17 de mayo de 2012

¿Se pueden patentar los genes?

En líneas generales, los requisitos para que se conceda una patente son los siguientes: que se trate de una invención, que exista novedad y actividad inventiva, y que tenga una aplicación industrial.

En el post de hoy nos vamos a centrar en el último punto, concretamente en las particularidades de las secuencias parciales o totales de los genes.

Para ello, retrocedemos al año 2001 cuando se publicó en Science y en Nature (por Celera Genomics y el Consorcio Público-Proyecto Genoma Humano, respectivamente) la secuencia completo del genoma humano, lo cual ha supuesto uno de los mayores hitos de la historia de la ciencia. Los objetivos que se perseguían cuando se inició este proyecto eran por un lado, conocer la posición de todos los nucleótidos en el genoma, y por otro lado, localizar los genes (mapeo genético) en cada uno de los cromosomas. Las implicaciones de este descubrimiento suponen avanzar en el estudio de enfermedades genéticas y poder desarrollar los nuevos tratamientos, terapias o métodos de diagnóstico.

Se sabe que existen aproximadamente 30.000 genes en el genoma humano. ¿Sería apropiado patentar cada uno de los genes? ¿Cumplen las secuencias parciales y totales de los genes los tres requisitos de patentabilidad?

En este sentido, los criterios de novedad y actividad inventiva son fácilmente demostrables, sin embargo, es el de aplicación industrial (Art. 57 European Patent Convention) el que ha de analizarse cuidadosamente. En el caso de Europa, la European Patent Office (EPO), ha dejado claro cual es el rumbo que hay que seguir en estos casos.

Es en la Parte C, Chapter-IV, punto 5.4 de los Guidelines for Examination (Abril 2010), donde se aclara que, para que se concedan patentes que incluyen secuencias parciales o totales de genes, es necesario que se indique la aplicación industrial de la misma. Aquellos supuestos en los que no se indique la función de la secuencia, ésta no podrá considerarse una invención patentable, en el sentido del considerando 23 de la Directiva 98/44/CE (Considerando que una mera secuencia de ADN, sin indicación de función biológica alguna, no contiene enseñanzas de carácter técnico; que, por consiguiente, no constituye una invención patentable;). En los casos en los que la secuencia parcial o total del gen se use para obtener una proteína o parte de ella, es necesario especificar que proteína o parte de la misma se va a sintetizar, así como la función que pudiera desarrollar.

De esta forma, y aplicando también las Reglas 42.1.f (The description shall: indicate explicitly, when it is not obvious from the description or nature of the invention, the way in which the invention is industrially applicable.) y 29.3 (The industrial application of a sequence or a partial sequence of a gene must be disclosed in the patent application. ) del EPC, la EPO trata de dar solución a la patentabilidad de las secuencias genéticas (parciales o completas), que se derivan del conocimiento de la secuenciación del genoma humano.

sábado, 5 de mayo de 2012

El apasionante mundo de las ideas en el software.

El Tribunal de Justicia de la Unión Europea (TJUE) dictaba el 2 de mayo del 2012 una interesante sentencia en materia de software y propiedad intelectual. Hablamos del caso C-406/10 SAS Institute Inc v World Programming Ltd, que surge a raíz de la petición de decisión prejudicial por la High Court of Justice de Reino Unido.

SAS es una empresa de desarrollo de software que ha desarrollado el denominado “sistema SAS” a través del cual los usuarios pueden escribir y ejecutar sus propios programas de aplicación para la manipulación de datos. Estos programas de aplicación se escriben en un lenguaje que es propio del sistema SAS (lenguaje SAS).
Por su parte, la empresa demandada, World Programming Ltd (WPL) creó el denominado “World Programming System (WPS). La novedad de WPS es que era capaz de ejecutar programas de aplicación escritos en el lenguaje SAS. Los demandados habían desarrollado WPS de manera que la funcionalidad fuese lo más próxima al sistema SAS. En el proceso de creación de WPS se habían estudiado y analizado los manuales publicados de SAS que contienen la descripción del lenguaje SAS así como la funcionalidad del software SAS. Pero WPL no había accedido al código fuente de SAS ni había copiado el código ni tampoco el diseño estructural.

Es importante considerar como se crea un software. El programador escribe en lenguaje de alto nivel de programación (palabras y símbolos), lo que junto con sus comentarios da lugar al código fuente. Pero el ordenador no puede manejar este lenguaje, por lo que hay que traducirlo a un lenguaje que el ordenador entienda (código binario de 0s y 1s). Dicha traducción es la compilación, donde se pasa de lenguaje de programación a lenguaje de máquina, dando lugar al código objeto.

Para nuestro análisis jurídico podemos resumir las cuestiones prejudiciales planteadas al TJUE en: (i) ¿se encuentra protegida la funcionalidad de un software?
(ii) ¿se puede proteger un lenguaje de programación?
(iii) ¿al reproducir un lenguaje de programación en el software, estaríamos vulnerando el derecho de reproducción del lenguaje de programación?

La propiedad intelectual protege el software considerándolo una obra literaria, tal y como recoge el artículo 1 de la Directiva de Software (Directiva 91/250). Dicho artículo establece en su apartado 2 que la protección abarca cualquier expresión de un software (con ello es claro que la protección abarca tanto el código fuente como el código objeto tal y como reconocía la sentencia del TJUE de 22 de diciembre de 2010 en el caso C-393/09). Estos elementos son los que podríamos calificar como “elementos literales del software”.
El problema que se plantea la sentencia va un paso más allá. Se introduce en el apasionante, debatido y examinado ámbito de la copia de los “elementos no literales”, es decir, qué ocurre si lo que el segundo software copia del primero no es el código escrito sino otra cosa. Y es que el mencionado artículo 1.2 de la Directiva de Software recoge que las ideas y principios de un programa de ordenador no están protegidos mediante derechos de autor.
Reduciendo a lo más simple el objeto del presente caso, estamos ante la aplicación de la doctrina de la dicotomía entre idea - expresión. Ésto significa que para resolver el caso, hay que plantearse si lo que busca protección es una idea o si es la expresión de una idea, ya que la propiedad intelectual protege la expresión de las ideas pero no las ideas en si mismas (como se recoge internacionalmente en el artículo 9.2 del tratado ADPIC o TRIPS en sus siglas en inglés).
Para llevar dicha doctrina a nuestro caso, hemos de señalar que los códigos fuente de dos programas de ordenador podrían no parecerse en nada (es decir no haber una copia del mismo) y sin embargo que ambos softwares cumplan la misma función. Función ha de entenderse en el sentido de que al dar el usuario una instrucción similar (input) se produzca un resultado similar en los dos softwares (output).
El TJUE decide, siguiendo la opinión del Abogado General, que ni la funcionalidad del software, ni el lenguaje de programación, constituyen expresión del programa de ordenador, y por tanto no han de estar protegidos por la protección que se confiere mediante propiedad intelectual a los programas de ordenador (es decir, mediante la Directiva del Software).
En lo que respecta a la funcionalidad, resulta coherente con la aplicación de la doctrina de la dicotomía entre idea-expresión. Si reducimos a lo más abstracto, simple y general un software, nos quedaríamos probablemente con la funcionalidad del mismo. Si protegiésemos dicha funcionalidad sería lo mismo que crear un monopolio sobre la idea, lo cual perjudicaría al progreso técnico y de desarrollo industrial tal y como el TJUE reconoce en la sentencia objeto de análisis en el párrafo 40. De esta manera, protegiendo sólo la expresión, y no la idea, se incentiva la creación de programas de ordenador con funciones similares o idénticas, siempre que no se produzca una copia de otro programa de ordenador.
Respecto al lenguaje de programación hay que hacer una matización. El TJUE establece en el párrafo 45 que ello “no obsta para que el lenguaje SAS y el formato de los archivos de datos de SAS Institute, como obras, puedan disfrutar de la protección de los derechos de autor con arreglo a la Directiva 2001/29, si constituyen una creación intelectual propia de su autor” refiriéndose el TJUE de nuevo al caso C-393/09.
Vemos entonces que el lenguaje de programación en lo que respecta a un software, no se encontraría protegido bajo el amparo que la Directiva de Software otorga, ya que no es la expresión de un programa. Si bien, el TJUE admite que la expresión de un lenguaje de programación, como por ejemplo un manual de programación para dicho lenguaje, quedaría protegido como obra literaria siempre que sea una creación intelectual propia de su autor (criterio de originalidad que hay que considerar conforme a la interpretación que establece el TJUE en su sentencia para el caso C-5/08, o también denominado “Caso Infopaq”). De ser ésta la interpretación, y llevándola a su lado más extremo, cuando un programador reprodujese en un software, una parte sustancial (atendiendo al criterio de originalidad mencionado) del lenguaje de programación que figure en el manual, se necesitaría al menos una licencia sobre el derecho de reproducción del citado manual de programación (lo que conlleva de facto la protección del lenguaje de programación).

Podemos llegar entonces a dos importantes conclusiones a través del presente caso:
1. La sentencia establece que no están protegidos bajo el régimen de propiedad intelectual para los programas de ordenador (Directiva de Software) la funcionalidad, ni el lenguaje de programación al no ser expresión del software.
2. Queda abierta la posibilidad (y algo indefinidos los límites y su alcance) de que se pueda proteger por propiedad intelectual (bajo la Directiva 2001/29 o Directiva de derecho de autor) de “manera indirecta” el lenguaje de programación como una obra literaria mediante por ejemplo un manual de programación de dicho lenguaje.


Licencia Creative Commons
El contenido del blog "IP Sandwich" se encuentra bajo una Licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported.