Header Ads Widget

Ticker

6/recent/ticker-posts

Lo que significa la publicación de patente GraphQL para la industria de las API


 GraphQL ha impulsado gran parte de la conversación en torno al diseño web de API moderno y, por una buena razón, es potente, extensible y muy útil para aplicaciones de alta consulta de datos. La capacidad de solicitar datos en un formato predeterminado y conocible, y la capacidad de recopilar puntos finales en un solo punto externo, ha convertido a GraphQL en algo que impulsa algunos proyectos bastante grandes.

Desafortunadamente, depender de un formato casi ubicuo viene con un aspecto negativo: cuando se realiza un cambio en GraphQL, sus efectos son amplios y significativos. Esto se puede ver en los problemas recientes relacionados con la licencia de patentes de GraphQL y las disputas que han surgido: un simple cambio de formato de licencia y la comprensión resultante (y en algunos casos, malentendidos) en la comunidad ha enviado ondas de choque a través del panorama API.

Hoy, vamos a hablar sobre algunos supuestos problemas relacionados con el lanzamiento de la patente GraphQL para proporcionar contexto y un poco de claridad. Echaremos un vistazo a si el problema de la licencia GraphQL es tan importante como se pensó al principio, y más concretamente, lo que el esquema de patentes recientemente lanzado de GraphQL significa realmente para la mayoría de los proveedores.

Antecedentes de GraphQL

Para aquellos que no saben qué es GraphQL, se puede resumir en términos generales como un lenguaje de consulta de capa de aplicación. GraphQL interpreta cadenas del cliente y devuelve datos de una manera predefinida, predecible y comprensible. Esta es una explicación muy breve y resumida de lo que hace GraphQL, pero hay mucho más que lo hace especial: para un resumen más completo, consulte nuestro artículo sobre los beneficios potenciales de la adopción de GraphQL .

Lo que es más importante para esta discusión es cómo se creó GraphQL . Después de que el desarrollo interno comenzara en 2012 en Facebook, GraphQL se lanzó públicamente en 2015 , ofreciendo una alternativa a las arquitecturas dominantes del espacio API, especialmente REST .

GraphQL se desarrolló inicialmente para ayuda a hacer frente a los retos de Facebook en ir a buscar datos específicos de su colección de servicios sin introducir la hinchazón y la complejidad. Al permitir que el cliente defina el formato de datos esperado, Facebook, a través de GraphQL, pudo diseñar una metodología para entregar datos de una manera más utilizable y eficiente.

Esta facilidad de uso y eficiencia resultó muy atractiva para muchos de los primeros usuarios. Empresas como Pinterest, GitHub y Shopify rápidamente comenzaron a usar GraphQL al por mayor o en parte. Sin embargo, durante la prisa por adoptar GraphQL, surgieron preguntas sin resolver que surgieron de la creación de GraphQL. No había un lenguaje de licencia en el comunicado público, ni información sobre si el lenguaje estaba patentado o no, y si eran posibles ramificaciones legales o no. Muchas preguntas quedaron sin respuesta.

También sobre la legalidad de las API: Oracle Vs. Google: Cómo proteger una API de inconvenientes legales

Los desarrolladores expresan preocupación

En septiembre de 2017 , GitLab congeló oficialmente su proyecto GraphQL debido a estas preocupaciones. En una publicación sobre temas de GitLab, el director senior de asuntos legales Jamie Hurewitz declaró que la licencia BSD + Patents, que Facebook había adoptado para tratar de aliviar las preocupaciones sobre patentes, era preocupante.

“Si permitiéramos esta licencia, podría dar lugar a posibles conflictos futuros con el software con licencia de Apache. Además, podríamos estar perjudicando los derechos futuros de nuestros clientes. Esencialmente, este no es realmente un producto de código abierto basado en las implicaciones de la licencia. Si bien no hay pago en efectivo, el pago se realiza en forma de renuncia a derechos futuros ".

La licencia que se había insertado en la versión GraphQL permitía el uso de GraphQL bajo ciertos términos que quita su licencia para usar GraphQL bajo los siguientes términos:

“La licencia [de patente] otorgada… terminará… si usted… inicia directa o indirectamente, o tiene un interés financiero directo en, cualquier Afirmación de Patente: (i) contra Facebook… (ii) contra cualquier parte si dicha Afirmación de Patente surge… de cualquier software ... de Facebook ... o (iii) contra cualquier parte relacionada con el Software ".

En otras palabras, los desarrolladores eran libres de usar GraphQL, siempre y cuando nunca desafiaran a Facebook por la infracción de patentes de cualquier cosa construida en su sistema por Facebook. Los problemas no resueltos causaron indignación entre los programadores . Fue muy importante para la comunidad de usuarios de GraphQL y llevó a muchos desarrolladores a retirarse de Facebook y su nueva patente.

El desarrollador y abogado Dennis Walsh discutió posteriormente este tema en un extenso análisis en Medium , en el que postuló que “ si Facebook quiere hacer valer estas patentes es asunto de los instintos y la tradición. No creo que Facebook haya litigado nunca una patente de manera ofensiva, pero el potencial de litigio es más que teórico: es muy real si eligen ese camino ". Estaba claro que para desarrolladores como Walsh, la idea de tener una licencia de GraphQL siempre que no intentara patentar o proteger sus propios procesos y desarrollos era problemática.

El 30 de agosto, el co-inventor de GraphQL en Facebook, Lee Byron, abordó las preocupaciones sobre GitHub y declaró que estaba "al tanto" del problema de las patentes y que se estaba trabajando en él. Él afirmó:

“Traeré esto a la atención de nuestro consejo legal por su sugerencia sobre cómo resolver este problema. ¡Definitivamente queremos asegurarnos de que la comunidad tenga todos los derechos necesarios para poder usar GraphQL! Me aseguraré de que obtengamos una resolución rápida ".

Finalmente, el 26 de septiembre de 2017, Facebook renovó la licencia de GraphQL bajo una licencia OWFa 1.0 , otorgando una licencia perpetua a los usuarios de GraphQL. Si bien esto definitivamente mejora la situación, aliviando muchos de los problemas de los desarrolladores relacionados con el problema, todavía puede haber algún motivo de preocupación.

Lea también: Cumplimiento de las nuevas y estrictas normas de la UE sobre protección de datos

Fuera de la sartén…

Sin embargo, todavía hay algunos motivos de preocupación en torno al nuevo esquema de licencias. Facebook ha adoptado ampliamente la licencia del MIT , que no incluye expresamente una concesión de patente. Se expresó cierta preocupación, como la del fundador de RedMonk, Stephen O'Grady , de que la adopción del MIT en lugar de la licencia de Apache, que dio una situación de patentes más clara a los desarrolladores, generó nuevas preocupaciones:

“El problema es que al elegir este enfoque, Facebook no transmite con la licencia del MIT ninguna concesión de patentes como lo harían con Apache. Si Facebook tiene patentes que se leen en React, en otras palabras, los usuarios de ese software no reciben una licencia explícita a través del MIT, solo una licencia implícita no probada ".

Para O'Grady, esto esencialmente significa que Facebook ha resuelto un problema de patente al introducir un segundo.

Muchos de estos problemas son los que deben probarse para ser confirmados; en otras palabras, hasta que Facebook no presente una demanda por infracción de patente, la mayoría de las preocupaciones son simplemente conjeturas . Aun así, el hecho es que esto sigue siendo, para algunos, un desarrollo preocupante . Este es ciertamente un artefacto del mundo del desarrollo de API en su conjunto, y es algo que tendrá que ser probado, examinado, desaprobado y reconstruido a medida que pasa el tiempo.

Las patentes en los Estados Unidos se imaginaron originalmente durante una época en la que la reproducción podía llevar meses a un gran costo para el creador. Las patentes se establecieron para " promover el progreso de la ciencia y las artes útiles " de acuerdo con su llamado constitucional . En ese momento, la idea de desarrollar rápidamente un estándar de código abierto y bifurcar estos proyectos en subdesarrollos adicionales era simplemente imposible de imaginar y, como tal, la aplicación de patentes al mundo web moderno está resultando en una complejidad significativa.

¿Son desproporcionadas las preocupaciones legales de GraphQL?

Dicho esto, hay la misma cantidad de expertos que sugieren que el problema se ha exagerado en gran medida . La terminación de una patente debido a procedimientos legales es común en algunos espacios y, de hecho, se ha practicado mediante políticas aplicadas a monstruos como el códec WebM de Google. Tales rescisiones de patentes, denominadas “disposiciones de rescisión defensivas”, son en gran parte comunes en las implementaciones empresariales y, en muchos casos, aún no se han descubierto de manera significativa en un procedimiento legal.

También debe tenerse en cuenta que la disposición de terminación defensiva como se indica en la documentación GraphQL de Facebook no fue tan extrema como algunas otras. La licencia pública de Mozilla, por ejemplo, no solo elimina su licencia de patente en respuesta a impugnaciones legales, sino también su licencia de derechos de autor; sin la licencia de derechos de autor, aunque puede perder la licencia de patente, en teoría podría seguir usando el código. . Sin embargo, con la terminación de los derechos de autor, estaría legalmente obligado a dejar de usar su código derivado por completo.

Obviamente, ese es un tipo de terminación de licencia mucho más extremo, pero el problema sigue siendo el tema principal de las discusiones de muchas personas al adoptar GraphQL.

Más de este escritor: Diseño de pautas de uso de API para clientes de bot

Aceite y agua

Si bien algunos han intentado conectar algún tipo de propósito nefasto con los problemas de patentes en cuestión, la verdad es que lo que estamos presenciando es una colisión del espíritu de código abierto con la realidad corporativa . Facebook es una corporación y, como tal, es de esperar que hagan todo lo posible para velar por sus mejores intereses. Este es un hecho lamentable del mundo empresarial, especialmente para una empresa que cotiza en bolsa.

Por otro lado, tenemos una filosofía de código abierto; la idea de que el código debe compartirse, desarrollarse, perfeccionarse y ampliarse, con una protección mínima, si es que la hay, aplicada a la base del código fundamental. Si bien esto, en teoría, beneficia a todos, lo que resulta en una mayor seguridad, un código más refinado y una adopción más amplia, el hecho es que una corporación como Facebook probablemente encontraría este tipo de enfoque peligroso considerando cuántas de sus funciones principales son impulsadas por el base de código que se está patentando.

Quizás la razón más clara de gran parte de esta preocupación es el hecho de que la intención no se puede comunicar realmente en la jerga legal de patentes: si Facebook usaría o no un acuerdo de patente como un medio para atacar a los desarrolladores es una conversación completamente diferente de si la licencia de patente actual, tal como está actualmente, sería aceptable para la mayoría de los desarrolladores. Desafortunadamente, los dos temas se están fusionando, lo que lleva al tema en cuestión.

Reflexiones finales sobre cuestiones legales de GraphQL

Entonces, ¿qué significa todo esto para el espacio API ? Es fácil asignar intenciones nefastas a Facebook, pero la realidad es que Facebook es una empresa pública, como lo son ahora muchas empresas de la comunidad API. Esto significa que tienen ciertas preocupaciones que deben abordar y ciertas expectativas con respecto al uso de sus aplicaciones y código base.

Dicho esto, sofocar las implementaciones de código abierto es un problema importante, y aunque eso no es lo que está sucediendo en este caso, las reacciones de algunos proveedores a la renovación de la licencia (como eliminar GraphQL por temor a posibles problemas legales) es comprensible. Esa debería ser la conclusión de todo esto: si bien existen preocupaciones sobre las licencias de patentes dentro del lenguaje de licencias GraphQL, gran parte del temor se basa en conjeturas , y si la posibilidad de una preocupación futura es lo suficientemente significativa como para preocupar a una organización, deberían considerar alejarse de GraphQL y adoptar una alternativa más compatible con el código abierto y con licencia gratuita.

Si no tiene la intención de crear algo que se monetice, o el nuevo esquema de renovación de licencias propuesto es una mitigación aceptable, entonces, por supuesto, continúe usando GraphQL. Si aún teme los posibles problemas en el futuro, asegúrese de que su API pueda comportarse durante un tiempo sin GraphQL o cualquier funcionalidad derivada de GraphQL. Para aquellos que se encuentran en algún lugar indeciso, tengan en cuenta que hasta que no se tomen medidas judiciales, estos temores son todas conjeturas.

Publicar un comentario

0 Comentarios