Header Ads Widget

Ticker

6/recent/ticker-posts

API: ¿activos digitales o armas digitales?

  


¿Cuándo desobedecen las políticas de la plataforma para desarrolladores de API las leyes antimonopolio?

Nuestro jefe de estrategia empresarial me preguntó recientemente sobre los problemas de Facebook con sus API, políticas de privacidad de datos y demandas antimonopolio. Es un problema que está muy cerca de mi corazón y que atrae cada vez más la atención de las empresas, los profesionales de API, los expertos legales y los CxO que se preocupan por la gobernanza de datos y API en sus empresas.

El uso de API se está disparando y los “Términos de uso” (ToU) subyacentes que rigen el uso de esas API también evolucionan continuamente. Aunque los desarrolladores pueden realizar su mejor diligencia debida antes de usar API de terceros (que pueden formar las funcionalidades centrales de su aplicación), los proveedores de API pueden desconectarlos, citando el uso no compatible de sus API. Esto podría acabar con una aplicación y afectar negativamente la continuidad del negocio. No es de extrañar que gigantes como Google, LinkedIn, Twitter y otros cerraran varias startups en el pasado. Ver RouteBuilder , Pealk , Planes de Twitter , deprecations Instagram , y así sucesivamente.

Las razones para cerrar el uso de la API de un consumidor desarrollador podrían ser genuinas. Quizás violaron los ToU, las políticas o las leyes del país, lo que podría haber puesto en peligro la reputación del proveedor de API. ¿Pero también podría haber agendas ocultas? Por ejemplo, una aplicación podría utilizar inteligentemente las API de un proveedor en particular y suponer un riesgo comercial para ese proveedor. En esta situación, podemos esperar que un proveedor de API tome medidas para proteger sus intereses comerciales. Pero, ¿quién decide si esas acciones son justas y no están diseñadas para frenar la competencia, que puede invocar leyes antimonopolio?

La verdadera pregunta que quiero investigar aquí es: ¿las empresas están creando API como "Productos" para crear innovaciones técnicas? O, ¿podrían realmente diseñarse para colocar trampas que eventualmente puedan usarse para hundir futuras competiciones? En otras palabras: ¿podrían las empresas utilizar sus propias API como armas digitales?

Política de plataforma de desarrolladores en evolución de Facebook

El reportero de VentureBeat Chris O'Brien recientemente hizo una observación importante en su artículo relacionado con la demanda antimonopolio de Facebook : "Facebook comenzó a cambiar las reglas para castigar o recompensar específicamente a los desarrolladores".

El artículo de Chris despertó mi interés, pero ¿dónde está la evidencia de que Facebook está usando potencialmente sus API como armas para frenar la competencia? No soy un abogado para escudriñar las legalidades de la demanda antimonopolio de Facebook, pero como soy un científico informático, podría hacer un análisis de datos. Comencé a investigar la Política de plataforma (FPP) de Facebook que rige el uso de sus API por parte de su comunidad de desarrolladores. Facebook comenzó a abrir sus API (read comenzó a vender sus datos) de manera más agresiva alrededor de 2016-2017 (después de completar sus diez años de fundación). Recuerde el caso de Cambridge Analytica .

Supongamos que Facebook está cambiando sistemáticamente sus ToU. En ese caso, debe reflejarse en su FPP, que los desarrolladores deben cumplir al usar las API de Facebook para crear aplicaciones y funcionalidades. Empecé a cavar más profundo. No hace falta decir que rastrear y analizar el FPP de los últimos 15 años fue un desafío. Gracias a las formas innovadoras de mi equipo, han creado una herramienta que puede rastrear y analizar rápidamente los acuerdos legales (por ejemplo, API ToU y políticas). Usando esta herramienta, simplemente busqué cambios en FPP de 2016 a 2020. Vea la captura de pantalla de la herramienta, como se muestra en la Figura 1. Noté algo trivial pero un cambio interesante en FPP. Este cambio se debió a omisiones e inclusiones de dos políticas específicas:

  • No cree una aplicación cuyo objetivo principal sea redirigir a las personas fuera de Facebook .
  • No repliques la funcionalidad principal que Facebook ya ofrece.

Una captura de pantalla de la herramienta de análisis de acuerdos legales de TeejLab .

Ambas políticas deberían tener sentido para cualquier desarrollador que esté creando sus aplicaciones utilizando API / datos de Facebook. En particular, la segunda política es más interesante, que desalienta a los desarrolladores de infringir la propiedad intelectual (IP) de Facebook. A partir de 2019, Facebook tiene 1317 patentes . Ahora eso cubre una gran cantidad de terreno de IP potencialmente para construir muchas aplicaciones y funcionalidades interesantes utilizando conjuntos masivos de datos que son generados por las plataformas de Facebook, incluidas Instagram y Whatsapp.

Facebook claramente tiene políticas (bien establecidas en su Política de plataforma disponible en línea) que no permiten a los desarrolladores replicar las funcionalidades centrales de Facebook o crear aplicaciones que están diseñadas a propósito para redirigir a los usuarios de Facebook fuera de las plataformas de Facebook mencionadas anteriormente. Eso tiene mucho sentido. ¿Entonces, cuál es el problema aquí?

La parte intrigante aquí es que hasta el 27 de octubre de 2017, Facebook mantuvo claramente su política de " No replicar la funcionalidad principal que Facebook ya ofrece ". Pero, Facebook abandonó esa política específica desde el 7 de mayo de 2018 (o quizás incluso antes, ya que analicé solo un subconjunto de sus documentos en evolución disponibles públicamente en línea).

Aún más interesante es que Facebook mantuvo su otra política de " No cree una aplicación cuyo propósito principal sea redirigir a las personas fuera de Facebook " al menos hasta el 24 de enero de 2020. Ambas políticas anteriores no forman parte de la última versión de FPP ( que se actualizó por última vez el 26 de junio de 2020).

Razones detrás de los cambios en la política de la plataforma

¿Por qué Facebook querría que otros replicaran sus funcionalidades centrales? ¿O eliminaron estas políticas, especialmente en torno a la “replicación de funcionalidades”, simplemente porque no se pueden hacer cumplir debido a tantas innovaciones creadas con conjuntos de datos de Facebook? Quizás, también es difícil para Facebook definir "cuál es su funcionalidad principal", dado su alcance desde "votar" hasta "moda", "compras" en línea, etc.

¿Por qué Facebook mantendría estas políticas en épocas anteriores y las eliminaría ahora? ¿Realmente quieren que otros usen sus datos para crear características y funciones que podrían infringir su IP? No es muy difícil concebir que con más de 1000 patentes, no sea muy difícil para ellos citar violaciones de sus derechos de propiedad intelectual. Podrían proteger mucho esos derechos al mismo tiempo que niegan a los desarrolladores el acceso a sus API y datos. Eso también, después del hecho de que algunas aplicaciones ya pueden depender en gran medida de sus API y datos.

Ahora la pregunta es, ¿cuándo ataca Facebook? ¿Esperan hasta que aplicaciones específicas demuestren un modelo de negocio viable o rentable? ¿O atacan desde el principio? Por ejemplo, Facebook examina de forma rutinaria a las empresas que utilizan sus API y les niega el acceso a muchas. Sería prudente no hacer suposiciones, pero está claro que las empresas (y no solo Facebook) pueden ejercer estas opciones en su beneficio.

¿API Non-Compete ToU infringe la ley antimonopolio?

La Comisión Federal de Comercio (FTC) hizo algunas observaciones importantes en su demanda: "Para comunicarse con Facebook (es decir, enviar datos a Facebook Blue o recuperar datos de Facebook Blue), las aplicaciones de terceros deben utilizar las API de Facebook". (Facebook Blue es un término interno utilizado por Facebook para distinguir la plataforma "principal" de Facebook de Instagram y Whatsapp). Claramente, las API son el núcleo de esta demanda.

Chris señaló que: “A medida que la plataforma principal explotó con el tiempo, Facebook comenzó a cambiar las reglas para castigar o recompensar específicamente a los desarrolladores. Este era particularmente el caso si Facebook sentía que los desarrolladores de aplicaciones representaban una amenaza competitiva ". Chris también dio varios ejemplos de empresas que Facebook hundió, incluidas Color y Path . Según la demanda de la FTC, Facebook cerró su uso de API, lo que contribuyó al cierre de estas empresas. Aunque Facebook acusó a estas empresas de violar su política de "spam", no es difícil imaginar las verdaderas razones detrás de estos cierres. Desde entonces. Facebook ha avanzado para crear funciones breves basadas en videos (en las que Color se especializó) y otras funciones de redes sociales pequeñas basadas en la comunidad (queCamino especializado en).

Según el comunicado de prensa de la FTC del 9 de diciembre de 2020: “Facebook se ha comprometido en una estrategia sistemática, incluida la adquisición en 2012 de su rival emergente Instagram, la adquisición en 2014 de la aplicación de mensajería móvil WhatsApp y la imposición de condiciones anticompetitivas a los desarrolladores de software, para eliminar las amenazas a su monopolio." Ahí es donde despertó mi interés por recopilar algunas pruebas de los ToU de Facebook. Es posible que nunca sepamos cuáles son las estrategias de API subyacentes reales de Facebook, pero los cambios significativos de FPP indican la potencial armamentización de las API. O al menos, las empresas basadas en datos pueden tener ese poder como una opción si eligen ejercerlo. El ejemplo que di es Facebook, que ya está siendo investigado por incumplimiento de las leyes antimonopolio. Sin embargo, eso no significa que Facebook sea la única empresa que está utilizando sus API de forma deshonesta.

Quiero enfatizar que las API (y otras tecnologías similares) llegaron para quedarse. Sus beneficios superan con creces los riesgos comerciales y legales que destaqué anteriormente. No obstante, debemos realizar un seguimiento de los acuerdos y políticas que rigen el uso de API y datos a medida que podrían evolucionar, y cualquier ambigüedad en torno a su uso compatible podría ser perjudicial para las empresas. Eso es cierto no solo cuando las empresas consumen API, sino también cuando producen API con políticas ambiguas. De hecho, estas políticas de API podrían actuar como armas, pero como un arma de doble filo, que podría oscilar en ambos sentidos. Así que hagamos lo correcto y habilitemos las API para construir la próxima generación de innovaciones digitales de manera responsable.API: ¿activos digitales o armas digitales? 

Publicar un comentario

0 Comentarios