Les logiciels libres, une économie coopérative

10.5 Les projets concrets

10.5.1 Albatross Display

FIGURE 10.1 - Aperçu d'Albatross Display. Source: Albatross, Albatross Display, 2014, http://www.al batross.aero/projects/projects-list/project-details.php?p=NA==&s=TGVhcm5Nb3Jl, consulté le 8 avril 2014

Albatross Display* est une interface humain-machine (HMI) de contrôle aérien (ATC) développée par la communauté Albatross. Il s'agit donc d'une interface graphique pour visualiser la position et la direction des avions en temps réel. La version professionnelle de cet OSS a été choisie en 2011 par Slovenia Control* comme logiciel ATC afin de pouvoir avoir, plus facilement, une influence directe sur l'adaptation du produit à leurs besoins.

63

10.5.2 NoGoZone

FIGURE 10.2 - Aperçu de la fenêtre de vitesse et d'altitude avec conflits. Source: Source Forge, NoGo-Zone, 2014, http://sourceforge.net/projects/nogozone/, consulté le 8 avril 2014

NoGoZone* est un outil permettant aux contrôleurs aériens de résoudre les conflits de trajectoires et ainsi éviter des collisions entre aéronefs. Cet algorithme a été développé dans les années 1990 à EUROCONTROL et est devenu un projet Open Source en 2007 en tant que mise en pratique du projet OSIFE.

10.6 La création d'un projet OSS

Dans cette section, je vais étudier comment mettre sur pied un projet Open Source, principalement dans le monde de l'ATM, en me basant sur les études réalisées à ce sujet, notamment l'étude SPOSS.

Avant toute chose, il paraît évident qu'il faut mettre sur pied les fondements du projet, le délimiter et déterminer comment il va être géré. Dans le monde libre, il existe plusieurs manières de gérer la propriété du logiciel. Ce logiciel peut notamment être la propriété d'une société privée, d'une société publique, d'une organisation Open Source ou d'une communauté d'utilisateurs. Le cas d'une société privée existe déjà puisque c'est le cas de la communauté Albatross, qui est en fait un projet de Skysoft-ATM. Comme je vous l'ai déjà expliqué, ce modèle est peu efficace. La possession du projet par une communauté d'utilisateurs serait problématique dans le cas de l'ATM pour plusieurs raisons. D'abord, ce type de communauté est peu stable et est sujette à une fragmentation du projet, ce qui serait l'opposé de l'objectif recherché. De plus, l'ATM ne pourrait disposer d'une communauté très large étant donné le nombre réduit d'utilisateurs dans ce secteur. Les projets dirigés par des associations Open Source sont souvent efficaces mais, encore une fois, le secteur ATM est trop particulier et les fondations libres n'auraient ni la motivation,

64

ni les compétences de diriger un tel projet. Restent donc les sociétés publiques. Il est inconcevable de penser à un organisme public national car cela augmenterait encore la fragmentation de l'ATM international. Il faut donc un organisme plus global, mais pas trop. En effet, faire appel à un organisme mondial serait irréaliste étant donné que les besoins actuels en matière d'ATM ne sont pas les mêmes partout dans le monde et qu'il n'existe, de toute manière, aucun organisme capable de gérer l'ATM au niveau mondial. C'est donc à l'échelle continentale qu'il faudrait regarder, et c'est là qu'intervient l'agence. Cet organisme européen est, d'après moi, extrêmement bien placé pour superviser un projet libre d'ATM visant à une harmonisation du secteur. Même si EUROCONTROL n'a pas pour vocation de réaliser des bénéfices par l'édition et la distribution de logiciel, il est de l'intérêt de l'agence de voir les meilleurs logiciels être développés aux prix les plus bas.

Puisque je pense qu'EUROCONTROL est l'entreprise la mieux placée pour gérer un projet Open Source, il serait du devoir de l'agence de s'assurer que tout code source utilisé est bien en règle au niveau des droits de propriété intellectuelle. Ensuite, il faut déterminer un modèle commercial. Le modèle le mieux adapté, d'après les études réalisées pour EUROCONTROL, serait le modèle de double-licence. Selon ce modèle, une version du logiciel serait libre et l'autre serait une version propriétaire fournie avec les services en échange d'une cotisation annuelle, qui ne seraient pas des bénéfices mais un recouvrement des coûts d'investissements. C'est sur ce modèle que fonctionnent de nombreux projets Open Source à succès comme Red Hat.

Le modèle de double-licence repose sur l'existence d'une version libre du logiciel, accessible gratuitement et librement dans un but de développement - contrôlé par le responsable du projet - et de test, et d'une version propriétaire assemblée à partir du code source de la version libre par le distributeur du projet. Cette version doit absolument être suffisamment documentée et être parfaitement stable, ce qui implique qu'elle doit avoir été rigoureusement testée par la communauté et finalement approuvée par le responsable du projet. Cette version propriétaire peut alors être distribuée suivant un principe d'abonne-ment reprenant l'accès au logiciel, le support technique, la maintenance et les formations. Dans le cas d'EUROCONTROL, cet abonnement pourrait simplement être l'ensemble des cotisations versées par les différents États membres. La licence idéale pour appliquer ce modèle économique à EUROCONTROL serait la LGPL, forçant toute version du logiciel à rester libre tout en permettant l'utilisation du code source avec du code source propriétaire. Il serait donc possible d'utiliser ce code source libre au sein d'un logiciel propriétaire. En clair, nous aurions le schéma suivant:

-- EUROCONTROL conserve tous les droits intellectuels, dirige le projet et décide de la stratégie à adopter;

-- Les contributeurs approuvés du projet participent au développement du logiciel; -- La communauté développe le projet sous licence LGPL (partie publique de la forge);

-- Le produit, sous licence LGPL mais accompagné de conditions générales d'utili-sation, est testé et la documentation destinée aux utilisateurs est écrite (partie

65

restreinte de la forge);

-- EUROCONTROL distribue le produit sous forme d'exécutables accompagnés de la documentation.

Il peut être intéressant de remarquer qu'à l'heure actuelle, EUROCONTROL utilise déjà un schéma relativement similaire, tout en étant le seul contributeur au projet. Effectivement, EUROCONTROL fait appel à des interventions externes en laissant, dans certains cas, les utilisateurs du futur produit déterminer la stratégie, ou encore en utilisant ces utilisateurs pour tester les produits. Dans l'état actuel des choses, si ce modèle Open Source se mettait en place, EUROCONTROL serait le seul développeur, impliquant des coûts maximaux pour un projet libre. D'après les estimations réalisées lors de l'étude SPOSS, il faudrait compter € 100 000 pour créer une forge interne, € 50 000 pour ouvrir cette forge et € 20 000 par an pour soutenir cette forge. Ces coûts seraient toutefois compensés par les abonnements annuels payés par les utilisateurs des logiciels. De plus, comme pour tout projet libre, l'augmentation du nombre de fournisseurs permettrait de réaliser des économies grâce à une baisse des prix de vente et de maintenance.

En résumé, EUROCONTROL s'intéresse aux logiciels libres mais il reste encore une certaine méfiance vis-à-vis de ces logiciels et de ce modèle économique. L'utilisation de logiciels Open Source n'est pas un problème, les serveurs d'EUROCONTROL étant des serveurs Linux depuis de nombreuses années, mais le développement de logiciels suivant ce modèle ne fait toujours pas l'unanimité. Au site de Maastricht, s'occupant du contrôle aérien, Linux est très utilisé et, dans un rapport de 2008, l'agence concluait qu'il n'y avait pas de problèmes de sécurité liés à Linux, que le risque d'erreurs critiques lié à l'utilisa-tion de Linux sur plusieurs sous-systèmes était très faible, et que le niveau d'expertise concernant Linux était déjà très élevé au sein d'EUROCONTROL. Dès lors, le rapport recommandait au centre de Maastricht de limiter l'utilisation de versions "Entreprise" de Linux avec un support permanent et de profiter de l'expertise présente au sein de l'agence pour créer une cellule de support interne.