Florian Mueller consultor y analista sobre propiedad intelectual y asesor de la parte directiva de MySQL (antes de ser comprado por SUN), ha publicado en su actual blog FOSS Patents que Oracle defiende que el API de Java dispone de Copyright a pesar de su licencia.
Esto no es nuevo pero lo que llama la atención de esta defensa son algunos argumentos para considerar que un API es susceptible para infrigir un Copyright. Entre varias de las argumentaciones de Oracle, se indica que el “Derecho de autor protege los nombres de los paquetes, clases, interfaces, campos y otros elementos de la API de Java”. Una afirmación que puede traer problemas técnicos e incluso monopolios de servicios y funcionalidades.
La copia de nombres del API
Tenemos que decir que la Java Community Process es un órgano encargado de realizar las especificaciones (es decir los nombres) de como deben ser las implementaciones para la existencia de compatibilidad entre diferentes proveedores. De esta manera, podemos utilizar cualquier proveedor sin tener que cambiar nuestra aplicación.
En el caso de Oracle-Google la copia abarca: “los nombres de los 37 paquetes, 458 clases, 158 interfaces, métodos de 2.427, 893 campos, y otros elementos [...] no se realizó debido a la existencia de un lenguaje limitado.” Por otra parte, Oracle alega que Android no es una implementación de Java por lo que, bajo esas circunstancias, la utilización de estos nombres sería una violación del Copyright.
Problemas de interoperabilidad
La posibilidad de poner Copyright crearía un grave perjuicio práctico en lo referente a interoperabilidad o compatibilidad de diferentes fabricantes o empresas. Imaginemos el supuesto caso que contratamos para nuestra arquitectura SOA un proveedor para desarrollar los servicios en el servidor y otra empresa para desarrollar las implementaciones cliente.
Imaginemos que por no cumplir las expectativas deseamos contratar a otro proveedor en el servidor para que nos haga otra implementación más eficiente o con más calidad. Cambiar una de las partes del software conlleva a que todos los nombres que se utilizan desde el cliente deban ser los mismos para que el software cliente siga funcionando.
Sustitución de librerías
Otro caso que nos podemos encontrar es la utilización de unas librerías de la empresa X que hacen una funcionalidad, por ejemplo, crear un log. Un día concreto, la empresa es comprada por otra y esta decide subirnos el precio o cambiarnos las condiciones de uso, cuestión legalmente inviable salvo que desees estar al tanto de las actualizaciones en las que las nuevas versiones llevarían otras condiciones.
Como no estas de acuerdo, decides quitarte la librería y montar una tu mismo. Dado que la creación de logs se realiza desde multitud de sitios de una aplicación, si no pudieses crear estas clases con los mismos nombres, deberías modificar gran parte del código realizado por ti con todo lo que ello conlleva en tareas de refactorización. Es decir por no poder utilizar los nombres de un número pequeño de clases, debes cambiar mucho más código de lo que es la propia librería.
Volver a aprender las clases
Finalmente, se dispone de un problema adicional que tiene que ver con el aprendizaje. En la universidad, academia o lugar donde hemos aprendido Java, se nos ha enseñado el lenguaje tal y como es. Uno de los impedimentos de pasar un lenguaje a otro es que un mismo concepto se llame de maneras diferentes.
Cuando ocurre esto tenemos que ir buscando por Google frases del tipo “Equivalente de X en el lenguaje Y”. Esto hace que los primeros pasos sean más complicados. Una de las razones que Google argumentó para utilizar el lenguaje Java y nombres equivalentes en las primeras versiones de Android, fue que así atraían a más programadores que tenían conocimientos Java.
Conclusión
Finalmente, en mi opinión creo que se debería realizar una distinción entre lo que es una especificación y la implementación cuando se va contemplar el Copyright de cualquier API, librería o servicio. No poder utilizar una especificación (total o parcialmente) por estar sujeta a Copyright hace que esa especificación sea menos efectiva y puede ocasionar un monopolio en ciertos servicios.
Vía | FOSS Patents
