Header Ads Widget

Ticker

6/recent/ticker-posts

Oracle vs. Google: Cómo proteger una API de inconvenientes legales


 En el último par de años, Oracle ha estado buscando $ 8.8 mil millones en daños y perjuicios por Google uso ‘s de Java en Android. Si ha echado un vistazo a cualquier sitio web de tecnología o la sección de finanzas de un periódico en los últimos años, es muy probable que ya lo sepa.

Pero esperemos un segundo. Java es un lenguaje de programación y no una API. Entonces, ¿qué tiene que ver todo esto con las API? En los casos generales de Oracle que busca el pago atrasado por Java SE, no mucho.

En este caso específico, sin embargo, Siri Mårtensson de Delphi Law Firm describe cómo Google realmente “usó parte de la API de Java en Android. Oracle vio esto como una infracción de su API ". De buenas a primeras, surge una gran pregunta: ¿fue este comportamiento deshonesto, quizás incluso ilegal, por parte de Google o una falla por parte de Oracle para describir adecuadamente los términos de uso de esta API?

Y lo más importante, dado este precedente, ¿es necesario que todos los desarrolladores de API busquen formas de proteger sus API de un posible uso indebido? A continuación, analizaremos la estrategia legal, las patentes y la protección de derechos de autor, así como las opciones que tienen los proveedores con respecto al código abierto.

Google vs Oracle: Seguimiento del caso

Antes de entrar en las implicaciones legales de este fallo de caso para los proveedores de API, primero veamos algunos hechos que son clave para el caso, como se describe en la presentación de Mårtensson:

  • En mayo de 2012 , el Tribunal de Distrito dictamina que las API no pueden tener derechos de autor, ya que se refieren a un método o función, y no son elegibles para la protección de derechos de autor. Oracle apela de inmediato.
  • En mayo de 2014 , el Tribunal de Apelaciones dictamina que la "estructura, secuencia y organización" de una API puede tener derechos de autor. El caso se devuelve al Tribunal de Distrito.
  • En mayo de 2016 , el Tribunal de Distrito determinó que el uso de la API de Java en Android por parte de Google se incluye en el título de uso legítimo. Oracle intenta apelar, pero se niega la apelación.

Dado que la decisión del año pasado podría tener importantes repercusiones en el espacio de las API, parecía el momento adecuado para observar más de cerca el panorama legal actual de la construcción y el trabajo con API.

Vea a Siri Mårtensson de Delphi Law Firm presente en las API nórdicas:

¿Tú hiciste esto? Yo hice esto

Hay un meme humorístico en línea que se refiere a aquellos en la web que presentan contenido original (OC) como si fuera suyo; esto les parecerá demasiado cierto a aquellos que han encontrado reposters en sus vidas en línea.

Debido a que se pueden usar para ofrecer información y estadísticas detalladas, lo que a menudo les da el poder de imitar el comportamiento de otras aplicaciones, es fácil ver el potencial de mal uso de las API. No es difícil, por ejemplo, imaginar a alguien pagando para usar una API poderosa, aplicando ingeniería inversa y cambiando la apariencia de la interfaz de su aplicación principal y presentándola como un nuevo producto.

Esto es enormemente problemático ya que no necesariamente violan los términos de uso de la API ... si el desarrollador de la API se ha molestado siquiera en definir estos términos de una manera significativa. En otros casos de infracción , una amenaza de cese y desistimiento / demanda normalmente sería suficiente para disuadir al imitador. Desafortunadamente, eso puede no ser tan simple cuando se trata de API.

API y jurados no tecnológicos

Los casos que se llevan a juicio pueden, como en el caso de Google Vs Oracle , involucrar a un jurado. Las API pueden estar ganando fuerza gracias a Internet de las cosas y otros productos orientados al consumidor, pero aún es justo decir que la mayoría del público en general tiene poca idea de cómo funcionan realmente las API. Como tal, ¿cómo se puede confiar en los legos para dictar el resultado de los casos que dependen del minucioso funcionamiento técnico de las API?

Mårtensson destaca los esfuerzos de Astrachan para aclarar esto al jurado en este caso de la siguiente manera:

“Es como la forma en que los usuarios de computadoras están acostumbrados a usar Control-P o Command-P como función de“ impresión ”en una computadora. ¿Qué pasaría si, de repente, Control-P o Comando-P significaran 'Pegar'? Si la API cambia, los usuarios de ese menú de archivos no podrán realizar las tareas ".

Es una analogía decente para explicar el papel de las API y la declaración de código, pero aún así podría confundir a los miembros del público en general que ni siquiera saben dónde encontrar los botones de Control o Comando en su teclado.

Relacionado: Cumplir con el nuevo y estricto reglamento de la UE sobre protección de datos

El problema del uso legítimo

La situación actual del caso Google Vs Oracle tiene un importante conjunto de repercusiones tanto para los desarrolladores de software que crean API como para quienes las consumen. Un artículo de Wired en 2014 resume claramente los problemas para los productores de API de la siguiente manera:

“Cuando una empresa contempla la posibilidad de ampliar sus capacidades y aprovechar nuevas oportunidades, tendrá que pensar: ¿voy a estar copiando, quizás inadvertidamente, la API de otra persona? ¿Debo pensar en alguna forma extraña y única en la que los desarrolladores deban llamar a mi servicio, para evitar ser demandados una vez que tenga éxito? "

Pero hay otro problema aquí, ya que los desarrolladores que son cautelosos sobre la copia de su IP pueden decidir cerrar las API o incluso descuidar abrirlas a partes externas en primer lugar. El uso legítimo es un término muy vago, y simplemente no hay garantía de que los desarrolladores de API puedan confiar en él para obtener servicios que ven como imitadores cerrados: un artículo para Chemical Innovation destaca exactamente lo engañosos que pueden ser los principios del uso legítimo.

Rutas para la protección legal de API

Entonces, ¿cuáles son las opciones para los desarrolladores de API que buscan proteger sus creaciones? Hay un par de rutas diferentes, y la buena noticia es que una de ellas casi no requiere esfuerzo adicional.

1. Patentes
Mårtensson afirma que “las patentes de métodos son bastante raras en Suecia. De hecho, las patentes de software son muy raras. En los EE. UU., Es mucho más fácil obtener una patente de software ". Sin embargo, eso no quiere decir que sean la opción correcta para todos.

Para seguir adelante con el patentamiento de software o una API, deberá hablar con un abogado de patentes y presentar la documentación correspondiente. Ese proceso puede ser costoso y llevar mucho tiempo, y no hay garantía de que la patente sea aprobada a menos que demuestre lo suficiente:

  • Utilidad , es decir, tiene un efecto técnico reproducible
  • Novedad , es decir, no conocida / publicada antes de la solicitud de patente
  • Inventiva , es decir, diferencias sustantivas con el status quo y no obvias para una persona capacitada

2. Protección de los derechos de autor

Esta es la ruta más probable para el software, incluidas las API. Pero Mårtensson ofrece el recordatorio de que “es importante que sepa que siempre es el formato el que está protegido. Una idea, función o método nunca puede estar sujeto a derechos de autor . Tienes que escribir algo, tiene que ser físico ".

Los derechos de autor surgen automáticamente en el momento de la creación a través de la persona que realmente escribe el código, pero en la mayoría de los casos el derecho se transfiere a la empresa si está escrito por un empleado a tiempo completo . Por supuesto, esto es un poco más complicado en el mundo de las startups, donde varios cofundadores y contratistas pueden estar trabajando en código simultáneamente. Mårtensson aclara una situación en particular, afirmando que "si contrata a un ingeniero fuera de su empresa, entonces necesita tener un acuerdo que diga que usted, como empresa, necesita los derechos del código".

Los derechos de autor se pueden dividir en un derecho económico : el “derecho exclusivo a decidir cómo se puede presentar, distribuir y exhibir la obra. Y si la obra es utilizada por otros, el autor tiene derecho a una compensación económica ”, y el derecho moral , que otorga el derecho a ser nombrado autor de la obra. También limita "cómo otros pueden modificar, desarrollar más, transferir y arrendar" el trabajo.

El hecho de que los derechos de autor se generen automáticamente , y el uso de la marca © ni siquiera es obligatorio para estar cubierto por ellos, probablemente sea una verdadera fuente de consuelo para los desarrolladores que están mucho más en casa jugando con los aspectos prácticos de las API que tienen precedentes legales.

Si bien ciertamente puede ser beneficioso establecer los términos y condiciones de uso de su API, la conclusión es que muchas API están (al menos en cierta medida) protegidas legalmente tan pronto como se escribe su código.

3. Código abierto
Mårtensson insinúa el atractivo del código abierto en su charla cuando anima a los desarrolladores de API a considerar cómo su API agrega valor; ¿Son las funciones que permite la API o algo más?

Por ejemplo, si tiene una API que puede hacer cosas realmente interesantes, es posible que desee cobrar por su uso. Si se trata más de una expansión para su producto principal con cargo y requiere una licencia para este último, puede considerar convertirlo en código abierto y dejar que la gente se vuelva loca con él para alentar a más clientes potenciales.

Una licencia de código abierto como la licencia MIT impone muy pocas restricciones sobre el uso, la modificación y la redistribución de copias de software, pero hay muchas otras opciones que pueden ser más adecuadas, como:

  • Licencia Apache 2.0
  • Licencia BSD de 3 cláusulas "Nueva" o "Revisada"
  • Licencia BSD de 2 cláusulas “simplificada” o “FreeBSD”
  • Licencia pública general GNU (GPL)
  • Biblioteca GNU o licencia pública general "menor" (LGPL)
  • Licencia pública de Mozilla 2.0

Apache 2.0 , por ejemplo, adopta un enfoque liberal similar al del MIT, pero tiene algunas salvedades relacionadas con la redistribución. Hay una guía muy útil, aunque bastante densa, de los entresijos de las licencias de código abierto en Wikipedia .

Ciertamente, el código abierto puede ser un modelo de negocio viable (Git, Drupal, Python e incluso Wikipedia son solo algunos proyectos icónicos de código abierto), pero requiere un enfoque ligeramente diferente a los productos tradicionales "de pago". Su oferta principal podría terminar siendo un servicio paralelo a su API, o incluso la prestación de sus servicios como consultor para ayudar a las personas a construir sus propios proyectos.

No es de extrañar que el código abierto sea popular en el espacio de API, ya que efectivamente lo establece como el propietario de muchos servicios diferentes que se construyen en la parte posterior de su producto. Eso abre sus opciones al pensar en la monetización más adelante.

Lea también: Una guía humana para redactar la política de la plataforma API

Pensamientos finales:

Una observación que vale la pena hacer es que Google y Oracle son empresas muy grandes; este caso es Goliath Vs Goliath. En la mayoría de los casos, sería más probable que una empresa dispuesta a robar una API sea una empresa incipiente, mientras que las empresas que han llegado a la etapa de ofrecer una biblioteca API pública próspera serán más grandes y estarán más establecidas. Mårtensson reconoce que el costo legal de llevar un asunto como este a juicio podría ser un inhibidor para las pequeñas empresas:

“Terminar teniendo una demanda de una empresa más grande que dice que está infringiendo nuestra API o nuestros derechos puede llevar mucho tiempo, mucho dinero, tiempo y esfuerzo invertido. Incluso si terminas 'teniendo razón' al final, sigue siendo un gran riesgo ".

En muchos casos, la amenaza de una demanda por sí sola será suficiente para disuadir a las empresas más pequeñas de enfrentar una batalla legal prolongada. Por supuesto, la otra cara de esto es que las empresas más pequeñas deben prestar mucha atención a las formas en que utilizan las API para evitar enfrentarse a acciones legales.

¿Es Google Vs Oracle el último caso que veremos relacionado con el robo , percibido o no, de API ? Absolutamente no. Todavía hay mucha zona gris; este caso no es tan claro como podría haber sido; en los casos en que existe un daño obvio al mercado, es más probable que los casos se resuelvan rápidamente y que se decida a favor del acusado.

También debemos recordar que el caso es algo único en el sentido de que se trata de una API de Java que es parte del lenguaje de programación y, por lo tanto, del comportamiento del software en sí, en lugar de una API abierta en la web. Nos complace decir que la naturaleza del espacio de la API web ha sido históricamente muy inclusiva y abierta; ¡esperamos que la amenaza constante de batallas legales no cambie eso!

Publicar un comentario

0 Comentarios