Qu’est-ce qu’une API ouverte pour le cloud computing ?

closeCet article a été publié il y a 14 ans 5 mois 11 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Lorsque l’on parle de service web, on en vient souvent rapidement à parler d’API (Application Programming Interface). Une API est le terme technique qui désigne une interface utilisable par un programme externe au service considéré. Ces interfaces constituent la base de ce que l’on peut appeler l’interopérabilité.

Les exemples ne manquent pas en la matière. Prenons le cas des services de micro-blogging Twitter et Identi.ca. Ceux-ci mettent à disposition des API qui permettent d’accéder aux données des utilisateurs (sous réserve d’une authentification bien sûr) ou encore de réaliser des opérations comme poster un message sur le service. Toujours pour illustrer le propos, j’utilise l’API d’Identi.ca pour poster mes messages directement depuis mon lecteur de flux RSS Newsbeuter.

Ces API’s sont liés à des conditions d’utilisation, Reuven Cohen nous en propose une classification :

  • les API « aveugles » dont on ne connaît pas les restrictions. Celle d’Amazon en est un bon exemple)
  • les API fermées, celles qui vous indiquent explicitement les limitations. Google App Engine est un bon exemple avec une licence d’utilisation extrêmement restrictive. La section 7.2 indique que : « Vous ne devez pas ( et vous ne devez permettre à qui que ce soit) : (a) de copier, modifier, créer une oeuvre dérivée, pratiquer de la rétro-ingénierie, dé-compiler ou tout autre tentative d’extraire le code source du logiciel Google App Engine ou quelque parti que ce soit sans autorisation explicite ». Une clause qui pourrait rendre des solutions comme AppScale qui est une implémentation open source  du Google AppEngine illégale selon les termes d’utilisation de Google.
  • les API « ouvertes »qui en général vous laissent faire ce que vous voulez du moment que vous respectez leur attribution. Rackspace, GoGrid et Sun sont les meilleurs exemples. Le principal défaut que présente ces API est que bien qu’il soit possible de les utiliser et des les « revisiter », vous pouvez être limité par l’utilisation d’un nom de société ou de marque, rendant alors la clause d’attribution potentiellement minée.

GoGrid par exemple a placé son API sous licence Creative Commons BY-SA et Sun pour son offre Sun Cloud sous CC-By. Au vu de cette classification, on voit qu’il ne suffit pas qu’un service Web dispose d’une API pour qu’il puisse clamer haut et fort son « ouverture ». Cette ouverture doit aussi s’exprimer par la licence qui l’accompagne. Un point de plus à ajouter au cahier des charges d’un service libre.

[Source]

Philippe Scoffoni

Je barbote dans la mare informatique depuis 30 ans (premier ordinateur à 16 ans, un ORIC ATMOS) et je travaille à mon compte au travers de ma société Open-DSI. J'accompagne les associations, TPE et PME dans leurs choix et dans la mise en oeuvre se solutions informatiques libres.

3 réponses

  1. Patcito dit :

    Les termes de la license AppEngine que tu cites sont ceux du service. Le SDK est sous license libre Apache: http://code.google.com/p/googleappengine/source/browse/trunk/python/LICENSE

    Il est donc legal de faire un clone de AppEngine, d’ailleurs Google est l’un des premiers sponsors de AppScale, regarde en bas de leur page, il est écrit:

    « AppScale is supported by Google and the National Science Foundation »

  2. Philippe dit :

    oui, tu as raison. Disons qu’il est quand même troublant de voir des clauses dans le service qui disent que tu n’as pas le droit de « créer une oeuvre dérivée » du service et d’avoir de l’autre coté un programme open source qui clone ce service. Même si google sponsorise ce dernier, tu ne trouves pas que c’est un peu incohérent ?

  3. Patcito dit :

    « rétro-ingénierie, dé-compiler ou tout autre tentative d’extraire le code source du logiciel Google App Engine ou quelque parti que ce soit sans autorisation explicite »

    Donc interdit de copier en faisant de la rétro-ingénierie directement depuis le service app engine. Mais ça n’interdit pas de le reproduire en utilisant le SDK, django et autres, ce qui est largement suffisant (et déjà fait).