Le terme « logiciel source » est un terme générique qui englobe de nombreuses réalités, allant des expérimentations menées par des étudiants jusqu'aux produits industriels sur lesquels s'appuie l'infrastructure de l'Internet. C'est en 1997, afin de faire changer d'avis les personnes qui, jusque-là, rejetaient ce type de logiciel qu'un groupe de leaders de la communauté du logiciel libre a essayé de trouver un moyen de promouvoir les idées qui entouraient le logiciel libre, dont les débuts remontaient aux années quatre-vingt. Ils étaient conscients du fait que le message anticommercial de la Free software foundation (FSF) n'encourageait pas au développement du logiciel libre, et en étaient arrivés à la conclusion qu'une action marketing était nécessaire pour s'affranchir du mot « free » utilisée par la FSF. C'est de cette réflexion qu'est issu le terme Open Source, ou open source software (OSS) (encadré I). Un ensemble de règles ont été rédigées à cette occasion qui décrivent les conditions nécessaires pour qu'un logiciel puisse être qualifié d'open source (cf le site www.opensource.org ). Aujourd'hui, l'acronyme Floss (Free/libre and open source software) fait référence aux deux types de logiciels dont le code source est accessible publiquement.

Il est clair qu'aujourd'hui il est impossible d'ignorer le phénomène Floss puisque chaque personne qui utilise un ordinateur se sert de logiciels open source. Au sein de l'infrastructure Internet, là où les premières réussites de ces logiciels sont apparues, les infrastructures des serveurs des noms de domaine sont par exemple générées par le logiciel Bind. Parallèlement, les serveurs Apache équipent aujourd'hui plus de deux tiers des serveurs web à travers le monde et la plupart d'entre eux sont équipés d'une variante Floss d'Unix, comme Linux, FreeBSD ou OpenBSD.

Côté outils de développement, un des projets les plus importants du monde open source est le GCC, le compilateur C sous licence GNU qui, au cours du temps, est devenu un compilateur générique pour de nombreux langages et cibles matérielles. Il est par exemple à la base de GNAT, un compilateur Ada très répandu. Plus récemment, le marché des environnements de développement (IDE) a vu apparaître de sérieux concurrents open source parmi lesquels on trouve NetBeans, un environnement de développement Java, et bien entendu Eclipse. Enfin, du côté de la bureautique, le Floss est aussi apparu avec par exemple l'outil de navigation Mozilla Firefox, la suite OpenOffice ou encore les environnements graphiques Gnome et KDE pour Linux.

Une des premières choses à considérer lorsque l'on évoque l'Open Source est la licence. Il en existe de nombreuses, approuvées par l'Open source initiative, qui spécifient le cadre d'utilisation du logiciel. Ces licences peuvent être classées par le niveau de contraintes qu'elles imposent aux exploitations commerciales (tableau p. 45)

La GPL (General public license) est la plus contraignante, car elle spécifie que les logiciels sous licence GPL doivent être redistribués avec leur code source et que les travaux dérivés (c'est-à-dire construits à base de logiciel GPL) doivent également avoir une licence GPL. C'est pourquoi cette licence est qualifiée de « virale » . Concrètement, cela signifie qu'aucun logiciel propriétaire ne peut être construit sous licence GPL.

Il existe cependant quelques manières de créer une valeur commerciale sur un logiciel GPL. Soit par l'utilisation de code GPL mais sans le redistribuer, ce qui implique une utilisation interne et la vente de services associés à ce logiciel. De nombreux sites de e-commerce font une telle utilisation des logiciels GPL. Soit par l'utilisation du « dual-licensing » . Il s'agit dans ce cas, pour une compagnie propriétaire du copyright d'un produit, de la possibilité de le distribuer sous licence GPL aux personnes qui en acceptent les contraintes, ou bien de le fournir dans une version commerciale pour toute autre utilisation. Ce dernier modèle est utilisé par exemple par MySQL avec le moteur de base de données éponyme, ou par AdaCore avec le compilateur Ada GNAT. La LGPL (Lesser general public license) est une version allégée ou amoindrie, selon le terme de la FSF, de la GPL. Elle en restreint la nature virale liée aux extensions du logiciel. Ainsi, un code sous licence LGPL peut être employé dans un logiciel propriétaire. Cependant, la licence est dotée d'une clause qui indique que les utilisateurs doivent pouvoir mettre à jour la partie sous licence LGPL, incluant la possibilité de réaliser la rétro-ingénierie du produit.

La MPL (Mozilla public license) et l' EPL (Eclipse public license), ont été écrites par deux entreprises, respectivement Nestcape et IBM, pour couvrir une partie des codes ouverts en open source. Ces licences n'appliquent pas de contraintes aux travaux dérivés qui peuvent être distribués sous n'importe quelle licence, y compris les licences commerciales non open source. Il implique cependant que toute modification du code source initial soit reversée au projet d'origine.

Les licences ASL (Apache software license) et BSD (Berkeley software distribution) permettent une utilisation illimitée et une modification du code source de base, mais requièrent de citer l'auteur original du code dans les travaux dérivés. Elles se prêtent à la commercialisation de logiciels et les projets qui les mettent en oeuvre reçoivent souvent des investissements industriels.

Au-delà de la nature des licences open source, un point important dans le cas de leur utilisation est la problématique des brevets. De nombreuses licences ont en effet des clauses qui protègent les utilisateurs d'une poursuite dans le cas d'un emploi de logiciel protégé par ces licences. La licence Apache, par exemple, spécifie que chaque contributeur au logiciel sous licence accorde à ces derniers un droit d'utilisation à vie, universelle et sans redevance. Pour faire en sorte que cette clause soit applicable, la plupart des groupes et organisations open source font signer aux contributeurs, avant leur apport, un « accord de contribution » . Celui-ci stipule que le contributeur peut décider des éléments qu'il souhaite livrer en open source, et accepte que la contribution soit redistribuée sous licence open source. Dans le cas où les contributions ont été financées par une société, le contributeur doit aussi signer un « accord de contribution d'entreprise » .

Il faut noter que contribuer à l'élaboration du code géré par une organisation open source ne signifie pas céder les droits d'auteur et le copyright, mais uniquement une licence qui permet d'exploiter le code. Les auteurs originaux conservent le copyright (dans certains pays comme la France, une cession de copyright est légalement impossible) et donc le droit de faire ce qu'ils veulent avec.

Un produit open source ne peut exister sans une communauté qui le supporte. D'une part, cette communauté s'occupe du produit et, d'autre part, elle développe un grand nombre d'activités périphériques qui dérivent du produit open source et qui consolident à la fois son développement et ses développeurs (figure 1).

A la base de cet écosystème, on trouve bien évidemment le logiciel open source lui-même. Il est le résultat d'un travail commun de tous les membres de l'écosystème. Un bon logiciel n'est pas seulement ce qui est nécessaire pour la réussite d'un projet. Par exemple, une des devises favorite de la fondation Apache est « la communauté est plus importante que le code » , ce qui signifie que, sans un groupe environnant vivant et sain, un logiciel, aussi bon qu'il soit, ne pourra survivre. Au-delà, on trouve les utilisateurs : ils sont indispensables. Sans utilisateurs, un projet n'existe pas. En premier lieu, ils téléchargent et mettent en oeuvre le projet, puis posent des questions sur les forums de discussion voire, pour certains, contribuent au projet en envoyant des corrections ou des évolutions de code. En second lieu, ils sont demandeurs de support, plus poussé que sur les forums, et participent ainsi au développement de relations commerciales classiques avec des experts, souvent employés par des compagnies sponsors. Ils peuvent également être intéressés par des extensions commerciales du logiciel open source qui leur permettent d'atteindre plus rapidement les objectifs de leur projet.

Les projets open source sont développés par des équipes géographiquement éparses, d'où l'importance dans le fonctionnement de l'écosystème des mailings lists et des forums, endroits virtuels où le projet prend vie. Le forum utilisateurs est l'endroit où chacun peut poser des questions, obtenir des réponses, fournies à la fois par des utilisateurs et des développeurs. En comparaison avec un support commercial, les utilisateurs du forum répondent gratuitement, et il est possible de rentrer directement en contact avec les développeurs. Cependant, ces structures ont leurs limites du fait de leur gratuité. En effet, les questions doivent être concises et précises, sinon l'analyse du problème demande trop d'efforts et prend trop de temps aux volontaires. Ce qui implique en retour que les utilisateurs du forum doivent eux-mêmes posséder des compétences techniques qui leur permettent d'analyser leur problème, et que des questions de nature large, relatives aux problématiques d'architecture par exemple, ne peuvent être posées. C'est à ce niveau que les entreprises sponsors entrent en jeu.

Les forums de développeurs sont l'endroit virtuel où le développement du projet open source se déroule. Les discussions relatives à la conception ont lieu sur ces forums, ce qui permet aux contributeurs de connaître l'avancement du projet, faire entendre leurs voix, proposer leurs idées, participer et finalement, après plusieurs contributions, devenir un membre de l'équipe de développement. La plupart des projets open source utilisent un mode de fonctionnement méritocratique : plus les personnes participent, plus elles obtiennent des droits sur le code source.

La nature des licences a aussi une influence sur la nature du groupe de développement : les licences autorisant une exploitation commerciale permettent par exemple aux entreprises de faire travailler des ingénieurs sur des projets open source. Il ne s'agit pas ici de philanthropie, mais d'une stratégie commerciale qui leur permet, à la fois, d'influer sur le cycle de développement du produit et de bénéficier d'une position privilégiée pour vendre des produits et services dérivés (encadré II).

Dernier élément mais pas des moindres, l'organisation qui héberge le projet. Celle-ci endosse plusieurs rôles. Le premier est lié à l'infrastructure du projet. En effet ce dernier a besoin d'un site web, d'un système de gestion, de mailings lists et de forums pour exister. L'organisation hôte fournit donc les ressources matérielles et la bande passante nécessaire aux besoins du projet. Le deuxième est de fournir un cadre légal aux travaux développés sous sa tutelle. Car la contribution et l'utilisation de code open source mènent inévitablement à la question des brevets. Que se passe-t-il par exemple si accidentellement j'enfreins un brevet avec mes contributions de code ? Quelles seront les conséquences pour les utilisateurs de ce code ? Le rôle de l'organisation est donc de protéger les utilisateurs et les contributeurs des questions juridiques, en endossant leurs responsabilités.

Le troisième rôle est lié aux activités de surveillance et d'arbitrage. En effet, comme dans tout projet collectif, les problèmes personnels et les conflits peuvent apparaître. Les nombreux contributeurs n'ayant aucune autorité les uns sur les autres, il est alors de la responsabilité de l'organisation de prendre des mesures appropriées lorsqu'une médiation a échoué.

Il y a six ans, Anyware Technologies a lancé une offre relative au développement d'applications web pour les systèmes d'information. Cette offre était construite sur des briques open source, mais à l'époque nous évitions de mentionner ce mot « open source » car cela donnait une image négative, évoquant un code de mauvaise qualité, écrit par des étudiants insomniaques ou des chercheurs académiques. Aujourd'hui, les choses ont fondamentalement changé. Indiquer que notre offre logicielle est basée sur des logiciels open source connus, sur lesquels nous intervenons au niveau du développement, est considéré comme une réelle valeur ajoutée par les utilisateurs. Il ne s'agit pas d'un effet de mode temporaire mais d'une tendance de fond. Car, actuellement, force est de constater que la plupart des logiciels d'infrastructure ou de middleware nécessaires à la mise en place d'un projet dans le secteur des systèmes d'information sont disponibles gratuitement. Pourquoi cette évolution ? En fait, face à la complexité grandissante des systèmes d'information, le besoin s'est fait sentir d'avoir à disposition une base de briques logicielles communes, interopérables et interchangeables. L'objectif étant d'éviter de réinventer la roue à chaque projet. On peut citer comme exemple de ces briques de base, un parser XML, un serveur web ou un moteur de workflow qui sont « seulement » des éléments de base pour l'implémentation d'une logique métier. Au-delà du développement de ces briques de base, les besoins en termes d'interopérabilité ont amené certains éditeurs à travailler ensemble sur la définition d'interfaces standard entre différentes couches de logiciels (encadré III), afin que des produits d'origines diverses puissent être assemblés simplement. Ce qui amène à la notion d'implantation (figure 2). Par exemple, le W3C (World wide web consortium), qui définit les standards du web, ne considère une spécification comme finalisée que lorsque celle-ci a deux implémentations, dont une open source, pour démontrer sa faisabilité. Une démarche qui assure que la spécification ne restera pas dans les mains d'un éditeur, et sera accessible par tous gratuitement afin de l'évaluer.

La même chose s'est produite pour la plate-forme Java. En effet, le JCP (Java community process), qui regroupe les entreprises et utilisateurs impliqués dans les produits basés sur Java, doit fournir une implantation de référence à chaque nouvelle spécification. La plupart de ces implémentations sont développées en tant que produit open source. Elles deviennent ensuite un logiciel accessible à tous, les entreprises pouvant alors construire des produits à forte valeur ajoutée à partir de cette implantation.

Autre phénomène qui pousse les éditeurs à passer en Open Source : la gestion de l'obsolescence. En effet, un logiciel est composé de plusieurs couches, qui vont du système d'exploitation jusqu'à des composants réutilisés qui fournissent des fonctionnalités complémentaires à la plate-forme, en passant par le langage de programmation et les librairies standard. Avec le temps, chacune de ces couches logicielles évolue ce qui amène à des recoupements de fonctionnalités (figure 3). Comment gérer cette obsolescence ?

Le recouvrement sur la couche open source est relativement simple à gérer : les composants open source obsolètes disparaissent après une période de transition car la communauté n'a plus d'intérêt pour ces éléments. Le recouvrement entre les composants open source et propriétaires est moins facile à gérer car, ici, il faut tenir compte des aspects tels que la propriété industrielle et les enjeux commerciaux associés. C'est une des raisons qui amène les éditeurs à contribuer au mouvement Open Source.

Trois grands types de réponse peuvent être apportés à ce problème de chevauchement. On peut l'ignorer. C'est probablement le pire choix, car le chevauchement continue à s'étendre et, à un moment donné, la solution open source va détruire le marché d'une solution entièrement propriétaire. On peut aussi remplacer la partie chevauchée par son équivalent open source. Cette solution peut être adoptée lorsque cette dernière est déjà mature et répandue. On peut enfin choisir une solution open source en y contribuant. Dans le domaine des systèmes d'information, de plus en plus d'éditeurs optent pour la troisième solution. Bien que, de prime abord, cela donne l'impression de donner des ressources et de céder de la propriété intellectuelle, en fait cela crée des conditions bénéfiques au produit propriétaire, qui devient un complément d'une commodité. De plus, cela donne à l'entreprise de l'influence pour l'évolution des composants open source, car ils peuvent être en adéquation avec les besoins des composants propriétaires qui composent la couche haute. Finalement, et c'est un point non négligeable, cela confère également à l'entreprise une visibilité accrue et des canaux de commercialisation complémentaires.

Enfin, pour des éditeurs propriétaires, faire le choix de l'Open Source est aussi un moyen de développer des éléments communs qui seront partagés par différentes entreprises évoluant dans le même secteur. On peut illustrer ce dernier point par la fondation Eclipse. En 2001, IBM a décidé en effet de passer en Open Source une grande partie de son IDE propriétaire, Websphere studio application developer, pour créer le projet open source Eclipse. Le raisonnement qui a poussé à faire ce choix est que les IDE modernes se rapportent plus à des fonctions très sophistiquées (gestion de projet, traçabilité, modélisation, simulation...) qu'à des fonctions de base, explorées et bien connues depuis des années, comme la gestion de fichiers, le lancement d'une compilation, etc. En quelques années, de nombreuses entreprises ont rejoint la Fondation Eclipse, la plupart étant des éditeurs d'IDE commerciaux qui travaillent sur une plate-forme commune, chacun conservant sa propre valeur ajoutée et sa gamme commerciale, basée sur cette même plate-forme.

Le logiciel open source est dorénavant un élément clé dans le secteur des systèmes d'information. Qu'en est-il du domaine des logiciels embarqués ? Le constat est qu'il est train d'y faire sa place. Il est déjà présent depuis quelques années avec le compilateur gcc, qui est utilisé dans de nombreux outils (par exemple le compilateur Ada GNAT).

Mais ce secteur de l'embarqué est très différent du système d'information, car les systèmes enfouis ont souvent besoin d'être fortement optimisés, voire dans certains cas d'être certifiés. C'est pourquoi, contrairement au système d'information, l'Open Source fait d'abord son apparition au niveau des outils plutôt qu'au niveau des composants fonctionnels (les runtime).

Ainsi, les éditeurs de système d'exploitation temps réel vendent principalement des licences runtime de leurs systèmes. Les outils sont alors fournis avec l'OS pour faciliter le développement mais ne constituent pas forcément des éléments différenciateurs sur le marché. Il y a quelques années, QNX a par exemple rejoint la fondation Eclipse pour y développer son environnement de développement C/C++. En faisant cela, la société a bénéficié de l'utilisation de nombreuses fonctionnalités fournies par la plate-forme, et a partagé ses ressources avec des acteurs intéressés par le support de ces langages de programmation dans Eclipse. Il y a près de trois ans, Wind River a également rejoint la fondation Eclipse. Les deux sociétés, bien que concurrentes, travaillent désormais ensemble sur une plate-forme commune.

Les logiciels embarqués ont souvent un cycle de vie beaucoup plus long qu'un logiciel de système d'information, et la maintenance peut être nécessaire pendant plusieurs années, voire même décennies. Les industriels doivent donc s'assurer de la pérennité des outils utilisés pour développer le logiciel. Or, cet aspect n'est pas forcément garanti par des outils propriétaires souvent commercialisés par de petites entreprises. Pour résoudre ce problème, on voit l'émergence de projets open source, à l'instar de Topcased, géré par Airbus et un ensemble d'entreprises, qui travaillent de concert sur le développement d'éléments communs et d'un ensemble d'outils pour la création de logiciels avioniques.

Topcased est un outil générique de modélisation, basé sur la plate-forme Eclipse. C'est actuellement un méta modeleur qui permet de définir le modèle d'un modèle, pour construire rapidement un éditeur graphique pour un modèle particulier. Le but de ce projet est de fournir des éditeurs pour tous les modèles intégrés au design d'un logiciel d'aviation. Sans les éléments open source fournis par Eclipse, le projet n'aurait jamais pu voir le jour.

Quand ils présentent le projet, les personnels d'Airbus se voient souvent demander : « si c'est open source, que se passe-t-il si Boeing décide de l'utiliser également ? » . Et la réponse est similaire à celle des éditeurs de logiciels commerciaux : la concurrence ne se fait pas sur les outils de modélisation, mais sur ce qu'on fait avec ces outils. Ainsi, seuls les modèles standard sont open source, les modèles spécifiques à Airbus restent propriétaires.

Pour les industriels, il est donc clair que les logiciels open source sont une opportunité, car ils permettent le partage de solides fondations et l'assurance d'une maintenabilité à long terme des logiciels. Pour les éditeurs, le risque est d'ignorer le phénomène Open Source, car à terme cela peut entraîner une chute de leurs ventes. Utiliser les logiciels open source, et y contribuer, est donc l'occasion pour ces éditeurs de fournir leur valeur ajoutée construite sur une base commune. Une des conséquences de ce virage est qu'il faut être conscient que les prestations commerciales s'orienteront plus vers les services que vers les licences.