Nuevos términos del servicio y políticas de desarrollo en YouTube API Services
Introducción
Google nos obsequió con 6 meses de gracia al notificar a los desarrolladores que usan YouTube API Services que el próximo 10 de febrero de 2017 se hará efectiva una nueva política de desarrollo y términos del servicio.
A diferencia de la anterior actualización en los términos del servicio, que iba más orientada al contenido de los videos que se monitarizaban, los cambios parecen centrarse en el continente, es decir, en cómo integramos nuestras aplicaciones con el servicio, cómo de transparentes somos, nuestra política de privacidad y cómo la integramos con la del servicio, etc.
El coste de adoptar este nuevo acuerdo dependerá de lo previsores que fuimos en la integración, pues como desarrolladores solo tenemos dos opciones: adaptarnos o perderla.
Documentación oficial
A continuación mostramos un pequeño índice del documento oficial en el que Google anunciaba la nueva política de desarrollo y términos del servicio de YouTube API Services:
Índice del post
Siguiendo el índice del propio documento oficial, vamos a ir punto por punto analizando las implicaciones.
Entre los distintos ToS, las diferencias son meramente legales adaptadas a cada región. Por tanto, por cuestiones prácticas, nos vamos a quedar con el análisis de:
- Term of Services - EMEA - Spanish
- Developer policies
- Required Minimum Functionality
- Subject API Services
- Branding Guidelines
Term of Services (EMEA) - ES
En este documento, más bien denso y lleno de parafernalia legal, se definen algunos de los términos empleados en todos los apartados, así como los actores principales que llegan al ‘acuerdo’.
También se definen muchos aspectos burocráticos como los referentes al cumplmiento de la legislación, la limitación de responsabilidad, la atribución, confidencialidad o las posibles consecuencias (a mí personalmente, me llama especialmente la atención el apartado indemnización).
Si bien se trata del documento en sí que debemos aceptar, nos han hecho el gran favor de sacar de aquí las partes comunes y que nos interesan como desarrolladores que trabajamos con esta API.
Volviendo al apartado definiciones, nos vamos a quedar con:
"Cliente de API: se refiere a un sitio web o aplicación de software (incluida una aplicación móvil) desarrollada por ti que accede o utiliza los Servicios API de YouTube”
Es decir, nosotros, los desarrolladores que estamos aceptando tácitamente estos Términos del Servicio (ToS en adelante) al hacer uso de la API.
Developer Policies
Aquí empieza lo bueno (imagino que los abogados disfrutarán con el apartado anterior, pero yo estoy muy lejos de ello...). Está subdividido a su vez en cuatro apartados:
Los dos primeros establecen el marco general del resto del apartado indicando qué es lo que se va a describir y algunos aspectos básicos como ser honestos o respetar la privacidad del usuario.
El apartado YouTube API Services es, asimismo, el más interesante desde el punto de vista de los cambios que se deberán llevar a cabo en nuestras integraciones.
Required Minimum Functionality
Este documento define los mínimos requerimientos funcionales de cualquier ‘Cliente API’ que haga uso de YouTube API services.
Asimismo, se divide en:
En estos apartados se regulariza el uso de todas estas funcionalidades especificando dimensiones y relación de aspecto del reproductor, y ahondando en las "Políticas de desarrollo generales" como la necesidad de uso de algunos de los metadatos en las operaciones de subida y/o edición de vídeos, comentarios o respuestas a comentarios.
Por otra parte, también se recuerda que no está permitido superponer ningún tipo de contenido por encima del reproductor embebido.
Subject API Services
Este documento es el encargado de establecer los rangos de adaptación por parte de los desarrolladores de YouTube API services y por parte de los API clients haciendo especial hincapié en que las APIs o funcionalidades en desuso (concretamente YouTube Data API, v2 , y los reproductores basados en Flash y JavaScript), dejarán de ser soportadas y deben sustituirse por las nuevas versiones o alternativas.
Branding Guidelines
En este documento se facilitan ciertos recursos para usar por los distintos API Clients dependiendo del nivel en el que nos integremos, así como recomendaciones respecto a su uso.
Conclusiones
Se distiguen dos grandes grupos de portales que hacen uso de YouTube API Services: uploaders y consumers. Asimismo, vamos a diferenciar los que solo se integran con YouTube API Services de los que lo hacen, además, con otros servicios:
-
Uploaders: Portales que se encargan de subir vídeos a través de YouTube API Services a YouTube.
-
Multi-uploaders: Uploaders que usan otras APIs que permiten subirlo a otros sistemas.
-
Consumers: Páginas que muestran contenido de YouTube ya sea como parte central o accesoria al propio contenido e interactúan con el mismo a través del player y/o a través de la propia API.
-
Multi-consumers: Consumers que usan otros sistemas competidores de YouTube.
Cambios comunes
Opciones de privacidad
Todos los requisitos de este tipo son comprensibles y los deberíamos haber tenido en cuenta al integrar cualquier portal con esta API.
Básicamente nos obliga a facilitar:
-
Un enlace a la página de privacidad de YouTube dentro de las políticas de privacidad de nuestro portal (http://www.google.com/policies/privacy).
-
Un enlace a la página de administración de permisos de Google (https://security.google.com/settings/security/permissions).
Por otra parte, nos obligan a facilitar un mecanismo para la revocación de permisos de nuestra aplicación desde la misma:
"Every API Client must provide a clearly explained and easy way for users to revoke any authorization consent they have provided to an API Client to access YouTube API Services."
Almacenamiento de claves
En este apartado nos obligan a hacer una gestión coherente de los tokens / privacidad que guardemos. ¿Qué quiere decir esto? Pues que si nos revocan, los eliminemos; si el usuario nos dice que no quiere facilitarnos su correo, no lo facilitemos; etc.
Si quieres saber más de este proceso puedes leer más información en mi propio post Cómo usar una API de Google con autenticación a través de OAuth2.
Uploaders
Este tipo de portales son los que, a priori, deberían requerir menores cambios. Además, todos están relacionados con dos puntos específicos: la privacidad del usuario y evitar el menosprecio de la API de YouTube respecto de otras APIs.
Multi-uploaders
En este apartado entran en juego terceras partes o competidores de YouTube. En caso de que tu plataforma solo esté integrada con YouTube (y con nadie más) a la hora de subir vídeos, te lo puedes saltar.
Upload
En caso contrario… bueno, personalmente me parece el punto más controvertido del documento. Literalmente, lo que dice es:
“API Clients that offer features sourced from multiple services and platforms should offer feature parity to the extent that it exists across those sources, providing user choice. When API Clients include features that are supported on YouTube and on other platforms, API Clients must not consistently present YouTube features in a detrimental way (e.g., by only providing those features from other platforms).”
Es decir, si tenemos dos integraciones que se encargan de subir vídeos a través de distintas APIs, digamos:
-
YouTube
-
Dailymotion
Debemos ser coherentes haciendo uso de toda la API de YouTube, siempre que hagamos lo propio con el resto. Siguiendo el mismo ejemplo de la documentación:
“For example, suppose an API Client allows users to upload videos to YouTube and three other platforms, and all of those platforms support the ability to upload captions. If the API Client also supports caption uploading, then it must support that feature for YouTube.”
Si permitimos la subida de captions a Dailymotion, también debemos permitirlo a YouTube.
Comentarios
Si nuestro portal hace uso de la edición de comentarios:
“For example, an API Client enables users to add comments about videos to multiple platforms, including YouTube. Each platform uses a different name to refer to the comment text. So, if the API Client labels the field "Feedback" in its comment form, it needs to clearly indicate that that value corresponds to the comment text on YouTube.”
From YouTube Developer Policies
Por tanto, tendremos que especificar claramente qué comentarios van a YouTube.
Consumers
En cuanto a este tipo de portales, tal vez sea el cambio o conjunto de requerimientos más drástico, aunque, probablemente, también el más coherente.
Control de operaciones: el usuario como máximo actor
El principio que impera, sobre todo, es el darle el control al usuario, es decir, prohíbe específicamente todas las operaciones que:
-
Obliguen al usuario a hacer algo para disfrutar de contenidos de YouTube sin que esto sea un requisito en YouTube mismo (likes, suscripciones, shares...)
-
Players múltiples o carga en background simultánea.
También se prohíbe el premiar al usuario por hacer alguna operación relacionada con vídeos o canales de YouTube:
“API Clients must not offer or provide incentives, rewards, or other compensation to users for engaging with YouTube Applications (directly or indirectly) by performing actions like viewing content, liking content, sharing content, subscribing to channels, adding comments. For example, API Clients must not offer features or services that trade video views for a fee or that trade video views in return for other YouTube-related or non-YouTube-related actions.”
From YouTube Developer Policies
Tampoco podremos programar triggers para estas operaciones sin permiso específico del usuario:
“misuse YouTube API Services or engage in abusive behaviors related to those Services. For example, you must not automate or trigger views, uploads, comments, likes, dislikes, or other actions without the user's prior specific and express consent;”
From YouTube Developer Policies
En la línea del apartado anterior, si nuestro portal integra varios competidores de YouTube o portales similares a través de distintas APIs, deberemos ser claros en cuanto a qué datos vienen o van hacia YouTube:
“For example, an API Client enables users to add comments about videos to multiple platforms, including YouTube. Each platform uses a different name to refer to the comment text. So, if the API Client labels the field "Feedback" in its comment form, it needs to clearly indicate that that value corresponds to the comment text on YouTube.”
From YouTube Developer Policies
Uso comercial de los servicios de YouTube
Y por último, no podremos tapar la publicidad propia de YouTube ni incluir publicidad en nuestro portal que no esté debidamente justificada con el resto del contenido:
“sell advertising, subscriptions, sponsorships, or promotions on any page or screen that contains YouTube audiovisual content unless other content or material not obtained from YouTube appears on the same page and offers enough independent value to justify such sales if the YouTube audiovisual content were removed.”
From YouTube Developer Policies
Tampoco podremos manipular el player (añadiendo eventos sobre el mismo que realicen operaciones en nombre del usuario):
“You must not use mouseovers or touch events on a YouTube player to initiate any action on the user's behalf, such as opening a window or subscribing to a channel.”
From Required Minimum Functionality
Agregación
Otro punto a tener en cuenta en cuanto a las restricciones de privacidad es la no agregación de datos de distintos propietarios.
“You may only aggregate API Data relating to YouTube channels that are under the same content owner as recognized by YouTube pursuant to content licensing agreement(s) between YouTube and such content owner, and such aggregated API Data must only be viewable by that content owner.”
From YouTube Developer Policies
¿Qué quiere decir esto? Pues que varios usuarios dan permiso a través de la API a la recuperación de datos de sus propios canales, estos sólo deben ser visibles para este usuario y no para cualquier otro.
Multi-consumers
Además de ser aplicable todos los casos de los consumers, en caso de permitir la edición de comentarios también tendremos que tener en cuenta el apartado comentarios.
Agregación
En este caso, también nos obliga a respetar los atributos de YouTube Data API por encima de cualquier cálculo sobre los mismos.
“Your API Clients must not replace API Data with similar, independently calculated data. For example, when displaying the number of likes for a video, your API Client must use the number retrieved from the API Data. You must not replace the number in the API Data with the number of times users of your API Client liked that video.”
From YouTube Developer Policies
Es decir, si tenemos un contador de likes que incluye a varias fuentes (ya sea en nuestro portal o en otros proveedores), no debemos mostrarlo de forma que se pueda malinterpretar como el contador de likes del vídeo en YouTube.
Actualización de los datos
En el apartado Handling YouTube Data and Content de las políticas de desarrollo se determinan algunos aspectos a tener en cuenta en cuanto al almacenamiento de datos provenientes de la API de YouTube.
"Note that even though an API Client may store this data for more than 30 days, the Client must still ensure every 30 days that it is still authorized by the user to access that data."
From YouTube Developer Policies
Es decir, cualquier dato que almacenemos procedente de las APIs de YouTube deberemos de programar su actualización cada 30 días como máximo.
¿Te ha gustado este contenido? Lee más posts de Alejandro Díaz.
