L’atelier alternera présentation du projet, application de la solution à des scénarios conçus collaborativement, et intelligence collective pour envisager de nouveaux champs d’application de la technologie.

Avec Andra CHAKROUN, développeuse OpenFisca et LexImpact, Entrepreneur d’intérêt général.

Un brevet porte sur une invention brevetable relative à un produit ou à un procédé et sert à contrôler l’utilisation qui sera faite d’une invention. Contrairement au droit d'auteur, il n’est pas possible de “simplement” réécrire la fonctionnalité brevetée.

En France, comme en Europe, les brevets ne peuvent en principe pas porter sur des logiciels. Ce n’est cependant pas le cas aux États-Unis ou au Japon.

Les brevets logiciels sont très contestés et font l’objet de nombreux abus, parmi lesquels figurent notamment les patent trolls : il s’agit de sociétés dépourvues de département R et D (Recherche & Développement) qui vont acheter des brevets tiers afin de négocier des licences ou d’agir en justice.

Sous couvert de favoriser la diffusion de l’innovation, elles cherchent uniquement à maximiser le gain relatif à leurs actifs.

En réaction au système des patent trolls, certains acteurs industriels ont choisi de se regrouper pour former des groupements de brevets à titre défensif. IBM, Google, Red Hat, etc. sont à la tête d'initiatives collectives afin de défendre certains secteurs économiques.

De cette manière, ils se protègent mutuellement contre toute action en contrefaçon de leurs brevets respectifs et ont parfois vocation à favoriser l’innovation dans un domaine donné (comme en matière d’énergie pour Tesla).

Certains de ces groupements vont plus loin encore dans cette démarche, en promettant aux communautés Open Source de ne pas leur opposer leurs brevets.

Ainsi, L’Open Invention Network (OIN) - consortium composé d’industries de haute technologie - a conduit l’initiative nommée « Linux Defenders » qui a vocation d’aider à protéger les communautés de logiciels Open Source contre les dangers et attaques récurrentes en matière de brevets.

Le détenteur d’un brevet peut autoriser ceux qui le souhaitent à reproduire son invention. Ainsi, il est tout à fait possible pour le titulaire d’un brevet d’accorder une licence à quiconque souhaite l’utiliser dans le cadre d’un projet Open Source.

Certaines licences prévoient ainsi des clauses spécifiques en matière de brevets, comme la licence Apache ou la licence GPL.

En ce sens, la licence GPL version 2 contient une clause implicite empêchant toute société distribuant un logiciel sous cette licence de poursuivre ensuite les utilisateurs subséquents (ses propres utilisateurs, mais également les utilisateurs de ses utilisateurs) pour violation de brevets. La version 3 de la licence GNU GPL va encore plus loin, et inclut une clause explicite qui va étendre cette obligation de protection des brevets.

Le terme Inner Source a été inventé par Tim O’Reilly en 2001, pour désigner l’utilisation des techniques et mécanismes de l’Open Source au sein de l’organisation.

À travers la culture, les pratiques et la méthodologie telles qu'utilisés et appliqués dans les projets open source, elle s'appuie sur la collaboration, la transparence, le mérite, et l'autonomie au sein des entreprises. Ce dernier point, étant un élément crucial, rend l'application de l'innersourcing parfois compliquée tant elle demande une réforme complète de la culture et de la pensée du modèle de l'entreprise.

Cette collaboration est rendue possible par la transparence des processus, ceux-ci étant accessibles à l'ensemble des participants. Toutes les décisions, les discussions, ainsi que les étapes de la vie du projet doivent être mises à disposition de tous. Cela permet à ceux qui prennent le projet en cours d'avoir accès au même niveau d'information que ceux qui sont déjà présents depuis le début.

De même tous les outils doivent être accessibles. Cela permet de maintenir une culture et une co-création entre les équipes laissant place à un terrain fertile pour l'innovation au sein de l'entreprise. Cela favorise également un recrutement qualitatif en étant plus attractif et une fidélisation des talents en interne. Ce partage développe une amélioration de la base de connaissance des individus, une mise en commun des méthodologies et une modélisation des processus à travers les équipes ainsi qu'un "brain-storming" permanent appelant à une plus grande créativité.

Enfin, l'autonomisation des acteurs permet une meilleure priorisation des travaux par les équipes, le développeur travaille sur ce qu'il préfère, cela encourage la méritocratie (c.-à-d. une reconnaissance par rapport aux contributions réelles, les tâches de gestion s'en trouvent donc allégées). Cette responsabilisation rend l'entreprise attractive pour les employés présents et futurs. Prendre des responsabilités, c'est s'investir, rechercher les meilleures opportunités, être créatif, performant et se sentir plus en prise avec la tâche à accomplir, la rendant ainsi plus intéressante.

L'outil open source Bitergia permet d'analyser la communauté et les contributeurs rattachés à une entreprise. Il permet en effet de visualiser rapidement la localisation de ces contributeurs, le type de contribution apporté et savoir si les modèles open source sont utilisés.

Très proches du modèle open source et largement présentes dans l'innersourcing, les méthodes agiles représentent des pratiques de gouvernance de projet, se veulent plus pragmatiques que les méthodes traditionnelles et proviennent du manifeste agile rédigé en 2001.

Elles impliquent au maximum tous les acteurs autour du projet, y compris le client, et permettent une grande réactivité à ses demandes.

Les méthodes agiles reposent sur un cycle de développement (un cycle comporte un petit nombre de phases) et les cycles sont répétés autant de fois que l’on en a besoin, au fur et à mesure, afin de réadapter le projet en fonction de son avancement.

Le manifeste Agile pose 4 principes qui ne vont pas sans rappeler ceux de l’Open source :

• Les individus et leurs interactions, plus que les processus et les outils
• Des logiciels opérationnels, plus qu’une documentation exhaustive
• La collaboration avec les clients, plus que la négociation contractuelle
• L’adaptation au changement, plus que le suivi d’un plan

Pour ce qui est du lean, cette méthode vise à minimiser le gaspillage, avec une gestion “plus juste” des ressources.
À cet effet, le lean se fixe comme objectif d’éradiquer trois « démons » de l’organisation du travail :

• le Muda : tout ce qui est sans valeur
• le Muri : l’excès, la surcharge de travail engendrée par des processus non adaptés :
• le Mura : la variabilité, ou l’irrégularité

Un des gaspillages à éradiquer dans le lean est la non-utilisation des ressources intellectuelles du personnel, cela pouvant être évité en appliquant les principes de l’Open source : chaque personne souhaitant participer au projet est en mesure de le faire et n’est pas bridée pour des raisons irrationnelles.

L’éthique des méthodes agiles et du lean, et celle de l’Open source sont relativement similaires, on y retrouve d’ailleurs la communication et la collaboration comme clef de réussite du projet.

La principale source de similarité entre ces méthodes est l’accent qu’elles mettent sur le partage et l’évolution continuelle du projet.

Les notions d'interopérabilité, d'urbanisation des systèmes d'information, de format ouvert, de gestion de la donnée sont entièrement disjointes des notions de logiciels libres et open source, bien que fortement liées dans un contexte historique et culturel.

On observe une convergence naturelle entre les objectifs de l'interopérabilité et ceux de l'open source dans la réduction de la dépendance à un fournisseur particulier, ce que l'on appelle classiquement "vendor lock-in". Avec la sophistication croissante des systèmes d'information, les interactions avec les différentes composantes se sont développées. De plus, du point de vue des vendeurs de solutions la capacité qu'avaient leurs produits à n'interagir qu'entre eux était le moyen de conserver une clientèle captive et donc d'éliminer la concurrence sans avoir à rivaliser directement avec celle-ci.

Ces stratégies d'enfermement sont de fait opposées à une approche ouverte aussi bien au niveau philosophique (liberté des utilisateurs) que technique (ouverture du code). De plus, les solutions open source se sont développées en favorisant au maximum les interactions avec les solutions tierces. Elles sont également apparues comme solutions alternatives sur les marchés verrouillés par des acteurs dominants. Dans ce cadre, l'interopérabilité est un facteur crucial pour rendre leur adoption possible.

L'open source est venue apporter des cas d'application concrets aux principes théoriques de l'urbanisation des systèmes d'information, en proposant notamment des solutions techniquement et économiquement plus intéressantes.

Cela a permis de démontrer l'importance de concevoir des systèmes d'information correctement urbanisés, c'est-à-dire composés de briques fonctionnant harmonieusement entre elles, tout en étant indépendantes les unes des autres.

C'est d'ailleurs sur ce fondement que la gendarmerie a graduellement mis en œuvre des solutions open source au sein de son système d'information. En termes d'urbanisation et d'interopérabilité ces avancées ne profitent pas seulement aux solutions open sources, mais bien à toutes les solutions inscrites dans une pratique de standard ouvert, étant la plupart du temps des acteurs entrants innovants.

Cela a induit des évolutions techniques pour automatiser cette pratique et notamment la généralisation des outils de gestion des dépendances dans les différents langages (maven pour java, composer pour PHP, PIP pour Python, npm/yarn pour JavaScript, Cargo pour Rust, etc.).

Cela a aussi entraîné des évolutions organisationnelles pour gérer la présence massive de code tiers dans les développements réalisés au sein des organisations, en particulier du point de vue de la sécurité et de la légalité.

Comme on l'a vu précédemment, les licences Open Source confèrent des droits, mais également des devoirs à respecter au risque de graves conséquences.

Il est ainsi impératif d'intégrer la conformité à ces licences dans le processus des différentes étapes de la chaîne de développement.

On peut distinguer trois étapes principales dans ces processus de conformité :

• Identification des composants
• Validation des licences associées
• Exécution des obligations

La première étape consiste à déterminer les composants Open Source entrant dans la composition d'un développement ainsi que la ou les licences qui leur sont associées.

Si une politique spécifique est déjà en place au moment du développement, cela peut se faire de façon déclarative. Dans le cas de l'usage d'outils de gestion de dépendance, ceux de premier niveau sont facilement connus puisqu'ils sont déclarés explicitement, et l'outil permet de calculer automatiquement celles des niveaux suivants (c'est-à-dire les dépendances des dépendances, etc.).

Lorsque la phase d'identification se fait a posteriori, par exemple lorsque le code développé est récupéré d'une entité tierce ou en l'absence d'une politique interne de gestion des composants open source, elle peut être facilitée par certains outils : outil recherchant des textes de licences ou de mentions de droits d'auteur (du type Fossology), ou comparant le code analysé à une base d'empreintes des projets Open Source publics (Black Duck, Flexera, etc.).

Une fois l'ensemble des composants tiers et leurs licences respectives identifiées, il s'agit de valider leur compatibilité entre eux (certaines licences pouvant avoir des exigences contradictoires) et avec les objectifs de l'entreprise pour son développement : l'aspect le plus impactant est généralement le caractère copyleft de certaines licences parce qu'il a de fortes implications sur les modèles économiques possibles.

Une fois la liste des composants établis validée (on parle généralement de Bill of Material), il s'agit d'exécuter les obligations découlant des licences impliquées, que ce soit en matière de mentions de paternité (dans la documentation ou l'application elle-même) ou de mise à disposition de code source.

Encore une fois, cet effort contribue globalement à une meilleure qualité juridique et renforce l’organisation de l’entreprise.

Bien que l'intégralité des grands groupes considère avoir initié leur transition digitale, on se rend compte que la plupart n'en sont qu'au démarrage. Cette transformation étant à la fois une opportunité et une menace pour les entreprises, une incapacité de réagir avec rapidité face à cette évolution peut leur faire perdre l'avantage par rapport à leurs concurrents.

De plus en plus d'entreprises sont convaincues que l'innovation ouverte, fondée sur des mécanismes d'ouverture et de collaboration, doit jouer un rôle prépondérant dans l'accélération de leur transformation numérique.

En effet, le numérique permet aux entreprises de parler un langage commun qui les rend à même de faciliter leur mutualisation et de s'impliquer dans les projets qu'ils utilisent au quotidien en tant que contributeurs ou prescripteurs de ces logiciels. Sur le long terme, l'enjeu consistera pour tous les acteurs industriels et publics de miser ensemble sur des ressources leur permettant d'innover et pérenniser leur évolution digitale.

Plusieurs grands groupes ont notamment fait le choix stratégique d'opter pour l'Open Source comme levier de leur transformation numérique.

Par exemple, c'est le cas de la Société Générale par Françoise Mercadal-Delasalles, Directrice des Ressources et de l'Innovation : "L'Open source est un formidable accélérateur de notre stratégie de digitalisation de la banque".

Mais également celui du groupe Voyage SNCF Technologies par Gilles de Richemond, CEO : "Chez VSC Technologies, l'utilisation des produits Open Source fait partie de notre quotidien depuis l'origine et pour la grande majorité de nos besoins. Notre transformation ces quatre dernières années n'aurait jamais pu avoir lieu en dehors du monde open source".

Autrement dit, l'Open Source fait partie de leur quotidien.

Ensuite, on retrouve deux écosystèmes ayant vocation d'accompagner la transformation numérique de leurs acteurs : Open Law et La Fabrique des Mobilités. Ainsi, ces structures associatives permettent de favoriser le développement numérique au sein d'un écosystème en mettant à disposition des ressources ouvertes.

Comme expliqué en introduction, l’Open Source est désormais omniprésent, incontournable, ancré dans le paysage. Cela donne l’impression trompeuse d’une situation de stabilité, alors que le phénomène est encore jeune, et se renouvelle constamment, car le contexte technologique est très mouvant.

Au cours des dernières années, plusieurs incidents sont venus rappeler que tout n’était pas si stable.

L’exemple le plus marquant concerne OpenSSL, une bibliothèque logicielle permettant de sécuriser les échanges sur Internet. Cette brique fondamentale est utilisée par des milliers de produits, des millions de site Web et d’applications critiques, notamment dans le domaine bancaire et financier.

Cette bibliothèque a été affectée par une faille de sécurité majeure, surnommée Heartbleed, compromettant la sécurité de millions de transactions dans le monde entier.

L’analyse des causes de cette faille a mis en évidence les moyens dérisoires dont disposait le projet et l’absence de contribution des utilisateurs.

En réponse à cet incident, un ensemble d’entreprises grandes consommatrices de logiciels libres (Google, Intel, Bloomberg, etc.) ont lancé la Core Infrastructure Initiative, hébergée par la Linux Foundation afin de tirer les leçons de cet incident et de donner des moyens au projet OpenSSL, mais aussi à d’autres projets dans une situation similaire (OpenSSH, GnuPG, Linux Kernel Self Protection Project, etc.).

Le problème de manque de moyens affecte un périmètre bien plus large de logiciels et renvoie à la notion de “Le bus factor” aussi dit de « résistance à l’écrasement ». C’est-à-dire que la pérennité du projet repose sur un nombre limité de personnes et qu’un “simple” accident serait susceptible de compromettre gravement le projet.

Ce phénomène se retrouve autant au sein de projets communautaires que de projets industriels, et relève surtout de la question de la gouvernance.

À cela s’ajoute que la structure actuelle des développements fait que de nombreux projets dépendent de très nombreux « petits » projets. De fait, la santé des petits projets revêt aussi une importante majeure (c’est un cas rencontré par exemple dans le cadre de leftpad).

Ces éléments renforcent la prise de conscience progressive d’une nécessité de contribution directe ou indirecte par les utilisateurs finaux des projets (en choisissant ses prestataires selon leur participation effective aux communautés des projets Open Source).

Outre la pérennisation des outils qu’elles utilisent, ce type de contribution porte de nombreux avantages pour les entreprises qui en tirent une meilleure maîtrise et, plus généralement, tous les bénéfices de l’Open Source.

Pour les projets avec une gouvernance éditeur, une source de revenus peut être la vente de licences propriétaires. Cette vente peut porter :

• soit sur une version plus évoluée que le produit Open Source distribué (on oppose généralement une version “community” à une version “entreprise”),
• soit pour des produits complémentaires au produit Open Source (sous forme de module ou de greffon),
• soit pour le même produit que le produit Open Source, mais dégagé de certaines obligations liées à sa licence Open Source (comme la clause de Copyleft, exemple assez représentatif de MySQL).

Certains éditeurs peuvent également vendre des souscriptions ou des abonnements : du point de vue de l’utilisateur, cela ressemble beaucoup à la vente de licence, en revanche ce que paie l’utilisateur n’est pas lié à l’usage du code en tant que tel, mais pour son usage dans un contexte facilité : à la fois en termes de certifications (usage de la marque de l’éditeur) et technique (facilité de mise à jour, etc.). L’exemple le plus connu est ici celui de l’entreprise Red Hat.

Le modèle économique le plus volontiers associé à l’Open Source est la vente de service autour du logiciel :

• Cela peut se faire de façon classique : l’entreprise vend des prestations basées sur son expertise sur le logiciel : intégration, conseil, formation, support, etc.
• Plus récemment, cela peut aussi être le développement de services sous forme de plateforme SaaS basée sous le logiciel Open Source. Le client conserve la possibilité d’installer et d’administrer le logiciel sur son parc, mais l’utilisation directe du service hébergé chez un tiers peut être plus rentable pour lui. C’est notamment le cas de l’offre de service de la Société Aquia, à l’origine du célèbre logiciel Drupal.

Il est également fréquent que des acteurs financent le développement d’un logiciel Open Source, car celui-ci est nécessaire à leur activité métier, sans constituer un élément différenciateur en lui-même. La mutualisation que permet l’Open Source rend cette stratégie plus rentable qu’un développement interne.

D'autre part, il peut s’agir aussi bien de vente de matériel ou encore de services reposants sur du logiciel Open Source. De ce fait, les constructeurs de matériel (IBM, Intel, Huawei, etc.) et les géants du Web reposent tous énormément sur les logiciels Open Source, et sont des contributeurs importants à des projets communautaires majeurs ou eux même à l’origine de projets (Linux, Android, etc.).

En termes de financement alternatif, certains projets Open Source s’appuient sur des logiques de mécénat / donation ; ou encore de publicité.

Certains projets Open Source communautaires font appel aux dons de leurs utilisateurs pour financer leurs développements, soit de façon ponctuelle, soit de façon permanente. Pour que ce modèle puisse fonctionner de façon permanente, il est nécessaire que le projet soit dynamique et proche de ses utilisateurs. À noter que des projets comme Libre Office bénéficient à la fois d'un mécénat de particuliers et d'entreprises, voire d'États, bien que les dons individuels soient plus importants.

D'autres projets communautaires se financent uniquement sur la publicité : le logiciel libre étant susceptible de diffusion large et rapide il constitue un bon support pour embarquer des messages ou des services. Mozilla, par exemple, a des accords avec les moteurs de recherche lui ayant permis de financer une grande part du développement de Firefox.

Trouver son modèle économique libre n’est pas donc pas nécessairement aisé. Cependant, il faut noter que parfois la viabilité économique d’un projet passe par une forme Open Source communautaire et non par une entreprise privée, qu’elle soit propriétaire ou Open Source.

Par exemple, le projet Blender initialement propriétaire n’a trouvé sa viabilité économique qu’en passant sous forme de projet communautaire grâce à une implication totale dans cette direction : productions crowdfundées disponibles sous licences libres, etc.

En d'autres termes, cela peut être sous une multitude de formes se trouvant entre l'économie sociale et solidaire et des aspects plus associatifs.

En conclusion :

« Il n’y aura pas d’autre Red Hat ». C'est un sujet fréquemment évoqué. Certains exemples de rachats font rêver (comme celui de MySQL), et le succès de RedHat aussi, mais c'est une réussite liée à un contexte historique particulier et aujourd'hui l'Open Source tend plutôt à une répartition de la valeur au profit d'une multitude d'acteurs.

L’Open Source n’est pas adapté à créer une captation vers un acteur unique. En effet, une grande partie de la valeur créée est diffusée dans l’ensemble de l’économie numérique, et non concentrée dans un unique acteur. C’est cet aspect diffus qui rend l’Open Source si important d’un point de vue sociétal global.

Red Hat est souvent cité comme exemple de réussite, comme modèle, que l’on cherche à imiter ou à décliner à d’autres domaines que Linux. On a vu plusieurs sociétés se revendiquer « le RedHat de » (Open Stack, etc.) et le succès de RedHat est certes bien réel (l’entreprise réalise un CA de plus d’1 ,Md de $), néanmoins ce modèle s’appuie sur un contexte historique et technologique particulier et les nouveaux modèles amènent à favoriser des structures plus petites, agiles et complémentaires entre elles.

Parmi eux, les acteurs à but non lucratif jouent un rôle fondamental. Il en existe plusieurs types, qui répondent à des besoins différents et dont les leviers d’action varient.

Les fondations sont des acteurs clés de l’écosystème, garants du développement et de la pérennité de nombreux projets open source.

Elles interviennent à plusieurs niveaux, tout en ayant des spécificités propres en fonction des contextes et objectifs des projets qu’elles portent.

Parmi leurs actions, elles fournissent la puissance logistique, l’infrastructure et les outils nécessaires aux projets open source pour aboutir à la mise à disposition d’un produit fini. Inclusives, elles permettent ainsi à des acteurs de natures différentes de travailler ensemble.

De plus, elles coordonnent et animent le fonctionnement de la communauté, en mettant à disposition des membres des outils de discussion et de travail collaboratif, et en formalisant des règles de gouvernance collaboratives et transparentes encadrant les relations entre les parties prenantes.

Elles peuvent également sécuriser juridiquement et protéger le travail des contributeurs aux projets qu’elles hébergent, permettre de recevoir des dons et des ressources de personnes physiques et morales, ou encore, défendre les marques des projets.

Qui sont ces fondations ? Certaines fondations ou associations portent plusieurs projets logiciels en parallèle, comme la fondation Apache (qui développe des logiciels open source sous la licence Apache), la fondation Linux (qui a pour but de protéger et standardiser Linux), ou encore la fondation Eclipse (qui porte de multiples projets OS), etc.

D’autres fondations sont consacrées à un projet logiciel spécifique, ou à un ensemble restreint de logiciels. Ainsi, un projet comme Libre Office est géré par The Document Foundation, tout comme Mozilla, Open Stack, Gnome ou encore Drupal qui bénéficient chacun de leur propre fondation dédiée.

D’autres acteurs à but non lucratif – des associations et des fondations principalement – ont pour principal objectif de promouvoir le logiciel libre : elles définissent les principaux concepts qui fondent le logiciel libre et l’open source.

→ Parmi les plus anciennes et influentes figurent la Free Software Foundation, l’Open Source Initiative et le Software Freedom Law Center.

D’autres organisations vont plus loin, en veillant activement à l’application de ces principes. Ces organisations, comme la Software Freedom Conservancy, ou le Software in the Public Interest, mènent des actions en justice pour défendre les utilisateurs dont les libertés n’auraient pas été respectées, ou bien les contributeurs dont les licences de projets n'auraient pas été honorées.

Certains acteurs – principalement des associations – ont pour mission de faire évoluer les cadres juridiques et réglementaires qui favorisent l’usage des logiciels libres. En France, des associations comme l’April, Framasoft, l’AFUL sont particulièrement actives, tandis qu’au niveau européen, on remarque par exemple l’action de la Free Software Foundation Europe ayant également pour vocation de soutenir l'évolution du logiciel libre.

En parallèle, des associations professionnelles ont pour objectif de structurer la filière du logiciel libre comme le Conseil National du Logiciel Libre (CNLL) en France, l’Open Source Business Alliance qui est son homologue allemand, ou encore l’Adullact en France qui agit plus au niveau des collectivités locales et des administrations, notamment en matière de mutualisation des ressources.

Enfin, de plus en plus, des acteurs industriels - parfois concurrents - identifient l’intérêt de mutualiser, de mettre en commun leurs ressources et compétences afin d’accélérer collectivement le développement de projets Open Source.

Certains font le choix de créer une structure à but non lucratif pour porter et organiser leur action, comme l’alliance GENIVI dans le secteur des transports qui a pour objet de promouvoir l’adoption d’une plateforme d’infotainment (ou d'info divertissement) pour véhicule. C'est aussi le choix de OW2, association indépendante dédiée au développement d’une base de logiciels d’infrastructure, jouant un rôle similaire à la fondation Eclipse.

Il est ainsi possible d’évoquer les communautés, l'industrie du Logiciel Libre (au sens large) qui comprend Les bénéficiaires finaux (en tant que clients et prescripteurs de spécifications), ou encore les fondations.

Les acteurs privés

Les éditeurs Open Source sont des sociétés qui investissent dans le développement d’un produit logiciel qu’elles distribuent tout ou en partie sous une licence Open Source. On peut par exemple citer :

• RedHat (distribue une version GNU Linux),
• la PME française SensioLabs (à l'origine du framework Symfony),
• Alfresco, qui édite un système de gestion de contenus

On retrouve ensuite une autre catégorie d'entreprise : les "Pure Players", sociétés spécialisées dans un domaine particulier et contribuant à des projets Open Source communautaires :

• Collabora (UK, contributeurs à LibreOffice et LibreOffice Online),
• OSlandia (FR, contributeurs aux projets QGis et PostGIS),
• VideoLAbs (FR, contributeurs au logiciel VLC)

Pour compléter la liste des acteurs privés, on peut mentionner des sociétés de service spécialisées en Logiciel Libre. Elles jouent principalement un rôle d’intégrateur et d'interface avec le client et offrent aussi des guichets uniques de support sur de larges ensembles de composants Open Source. C'est notamment le cas de :

• Smile , Alter Way, Savoir Faire Linux, …

Des entreprise de Service Numérique généralistes jouent un rôle similaire, et éventuellement en partenariat avec des acteurs plus spécialisés :

• Cap Gemini, Atos, CGI, etc. :

Enfin, on retrouve des entreprises utilisatrices de logiciels libres dans tous les secteurs d’activité : le modèle de ce type de logiciel permet une fluidité entre le rôle d’utilisateur et de contributeur. On constate également que de plus en plus d’entreprises s’impliquent activement dans cette logique, soit pour contribuer à des projets Open Source, soit pour publier leurs propres développements. Cette tendance a commencé par les constructeurs de matériel avant de s'étendre à d'autres domaines. En France la Société Générale, la SNCF, EDF sont particulièrement actifs dans le domaine de l'OS.

Forges publiques

Une autre composante importante dans le domaine de l' Open Source est constituée des éditeurs de forges. Ce sont des plateformes mises à disposition des contributeurs afin de développer leur projet de manière collaborative. La plupart sont des acteurs privés, mais leur position les oblige à avoir une certaine loyauté dans leurs pratiques (c’est cette absence de loyauté qui a été reprochée à sourceforge).

Leur pérennité n’est pas forcément assurée (tel Google Code qui a fermé récemment) ce qui rend d’autant plus intéressant des projets tels que Gitlab (qui propose une version Open Source de son logiciel sur sa plateforme de forge publique).

À noter une nouvelle fois : le projet Software Heritage permet d’assurer une pérennité par l’archivage de tous les codes sources passés, présents et futurs transitant sur ces plateformes. C'est donc une mémoire colossale maintenue par un acteur français et soutenue par différents autres acteurs dans le monde entier.

Les acteurs à but non lucratif sont aussi très nombreux dans le paysage de l’Open Source, et jouent des rôles particulièrement structurants pour l’écosystème.

Ils prennent une dimension variable selon qu’ils portent sur un projet, qu’ils soient portés par une fondation ou encore qu’ils fassent partie d’un ensemble plus important soutenu par un consortium ou une fondation “parapluie”.

Leur rôle est tel qu’une vidéo propre leur est consacrée.

Cette possibilité représente à la fois un risque, car cela divise les ressources, mais c’est aussi une garantie d’indépendance voire une opportunité pour les contributeurs ou utilisateurs finaux qui ne trouvent pas d’autres issues, renforçant ainsi leur confiance dans le projet et leur implication.

Par exemple, suite au rachat de Sun par Oracle, nous avons pu assister au fork réussi du projet OpenOffice.org par la communauté sous le nom LibreOffice, ou encore le fork de MySQL par MariaDB. C'est également le cas du serveur d’intégration continue Hudson, forké en Jenkins, logiciel aujourd'hui massivement utilisé.

On retrouve également le logiciel de dessin vectoriel Inkscape, qui est un fork de Sodipodi suite à des difficultés à intégrer de nouvelles fonctionnalités dans le projet initial : in fine, Inkscape a connu un fort développement alors que la branche initiale s’est éteinte. Autrement dit, lorsque le projet n'est pas en capacité d'aller dans la direction voulue par la communauté, celle-ci s'en empare et l'amène où elle le souhaite.

D’autres forks peuvent avoir moins de succès (comme libAv, fork de FFMPEG) : dans ce cas cependant, le fork a eu un effet bénéfique sur le projet original en l’incitant à évoluer organisationnellement.

Lorsque l’éditeur d’un logiciel Open Source “dépasse” les contraintes jugées acceptables par la communauté (composée notamment de ses clients) des projets de forks peuvent ainsi être lancés à l’initiative de ces derniers pour reprendre le contrôle sur ce projet dans lequel ils ont investi.

C’est ainsi qu’un Fork du projet OpenAM a récemment été initié par les partenaires et clients de la Société Forgerock. On peut voir sur le site Time For A Fork l'intention et les réalisations de ces divers acteurs au profit d'une version entièrement OS du projet.

La gestion de la marque est en revanche un point particulièrement sensible : c’est cette notion qui a maintenu OpenOffice.org à flot, mais qui a également causé certains dégâts puisque Libre Office démontre un peu de mal à retrouver les connaissances et l'image dont bénéficiait son prédécesseur. Cela joue surtout pour les projets grand public. Par contraste, tout le monde a oublié Hudson et utilise maintenant Jenkins.

Il existe cependant des motifs largement répandus et des critères simples permettant de distinguer les projets.
Le premier critère pour appréhender le fonctionnement d’un projet Open Source est son type de gouvernance et on en distingue deux catégories principales : les projets avec une gouvernance de type éditeur et ceux avec une gouvernance communautaire.

Dans le cas d’une gouvernance éditeur, c’est une entité unique qui décide des orientations du projet, en termes de roadmap, d’intégration ou de contribution externe. La traduction dans les faits de ce type de gouvernance varie énormément en fonction des projets.

Du point de vue de l’utilisateur, une telle gouvernance offre l’avantage de la simplicité (l'acquisition et le support du produit s’intègrent de façon transparente dans les processus existants), mais peut limiter certains aspects propres à l’Open Source, que l’on retrouve dans les projets communautaires.

La gouvernance de type communautaire est celle qui vient le plus naturellement à l’esprit quand on parle de projets Open Source : elle peut être assurée au sein d’une entité à but non lucratif (Dans le contexte de l’Open Source, on parle généralement de « fondations »), ou être informelle, même pour des projets de grande envergure (c’est par exemple le cas de PostgreSQL ou Samba).

Les décisions sont le plus souvent issues de consensus ou de votes et reposent plutôt sur une idée de méritocratie, même si ce sujet fait débat.

Il faut noter que les positions de responsabilité ne sont pas souvent l’enjeu de rivalités fortes, car ce sont plus des positions de devoir que des positions de pouvoir.

On verra par exemple, le faible nombre de candidats au poste de leader pour un projet majeur comme le projet Debian.

Il y a généralement une approche plus horizontale que hiérarchique dans la prise de décision, en revanche l’organisation fonctionnelle du projet peut adopter un modèle hiérarchique pour des considérations techniques (le noyau Linux a une organisation pyramidale très structurée).

L’organisation d’un projet se fait également selon les différents types de contribution. Le principe de l’Open source est de permettre à plusieurs acteurs différents de collaborer à un même projet. Ces contributions peuvent s’effectuer à des niveaux très divers : code, rapport de bugs, documentation, localisation, support entre utilisateurs, etc.

Les utilisateurs simples font partie de la communauté. Ce sentiment d’appartenance permet d'augmenter la motivation à s’impliquer davantage, cela étant facilité par la gradation possible.

On distingue souvent différents niveaux d’implication dans le projet : on parlait initialement de « core contributeurs » faisant référence à une implication sur le cœur du code. On parle désormais davantage de mainteneurs, ce qui correspond plus à la réalité. En effet, ce qui compte dans l’implication, c’est surtout l’engagement dans la durée.

L’implication dans le projet se traduit généralement par des droits différents de modification : en effet, si tout le monde peut proposer des modifications leur intégration est forcément soumise à un certain nombre de contrôles.

Pour conclure, les mécanismes d’attributions de ces droits dépendent fortement du type de gouvernance du projet.

Les communautés, c’est comme les antibiotiques, ce n’est pas automatique.

La marque peut prendre plusieurs formes (un mot, un symbole, voire même une forme, une couleur ou un son), mais elle a toujours le même but : être reconnue par le consommateur.

Pour rappel, le droit de la propriété intellectuelle n’envisage pas un produit commercialisé comme un objet unique, mais comme une multitude d’objets juridiques distincts, protégés chacun par un droit de propriété intellectuelle différent et adapté.

Ainsi, un projet Open Source pourra être protégé à la fois par :

• Le droit d’auteur, pour le code source qui sera donc soumis sous licence OS;
• Le droit des brevets, pour les éventuels brevets qui auraient pu être déposés (même si, on l’a vu, les brevets en matière de logiciels ne sont en principe pas valable en Europe) ;
• La marque qui aura été associée au projet ;
• etc.

Tous ces droits sont totalement indépendants : le code d’un logiciel peut donc être « libre » (placé sous une licence Open Source), mais le titulaire de la marque peut empêcher son utilisation par d’autres, sans que soit remise en cause la qualité du logiciel Open Source.

Les éditeurs diffusant un logiciel en Open Source assurent souvent la protection de leur produit par l’usage complémentaire du droit des marques : le logiciel est librement diffusé sous licence Open Source, mais tout usage de la marque est soumis à autorisation.

L’éditeur est ainsi assuré d’obtenir un contrôle sur l’évolution, la distribution des copies et l’exploitation globale du logiciel.

Dans l’usage de ce droit, il est possible de distinguer les sociétés commerciales, qui ont tendance à en user de façon très agressive au point parfois de réduire les libertés concédées par la licence Open Source sur le produit, et les projets communautaires qui l'utilisent davantage en termes de protection qu'en termes de commercialisation (Mysql, Red Hat, Firefox, etc.).

Néanmoins, ces sociétés doivent faire attention à ne pas se mettre la communauté à dos. En effet, l'Open Source est basé sur le choix de la contribution de la communauté, mais dans cette situation on l'empêche de contribuer amenant parfois cette dernière à se détourner de l'éditeur initial.

De ce fait, la communauté peut créer ce que l’on appelle un « fork », c’est-à-dire un projet parallèle : la communauté va s’émanciper en cessant toute allusion à la marque et en reprenant à son compte les logiciels diffusés sous licence Open Source. Ceci peut ensuite avoir de lourdes conséquences pour le projet qui perdra un grand nombre de ses contributeurs.

En pratique, lorsqu’une œuvre est placée sous un tel statut, la création originale et les modifications qui lui sont faites sont soumises à cette licence, mais elle peut néanmoins se combiner avec d’autres créations elles-mêmes sous d’autres licences.

Autrement dit, au sens strict du droit d’auteur, toutes les œuvres dérivées (pensez “transformées”) de l’œuvre originale seront soumises à la licence initiale, tandis que les œuvres composites (pensez “combinaison de différentes oeuvres") pourront être soumises à d’autres.

La conséquence immédiate est que certaines fonctionnalités ou composants vont pouvoir être ajoutés sous leur propre licence.

À savoir : les licences à « copyleft faible » les plus connues sont les licences LGPL et MPL.

La première version de la licence GNU LGPL (GNU Library General Public License) a été publiée en 1991. Conçue pour être moins contraignante que la GPL, elle était destinée à certains programmes qui gagnaient à être diffusés et utilisés massivement en dépit d’un environnement non entièrement ouvert (contrairement à la GNU GPL qui se refuse à de telles cohabitations). Elle autorise expressément la liaison de logiciels non libres avec la bibliothèque diffusée sous cette licence.

Il s’agissait d’une stratégie destinée à favoriser l’immixtion de logiciels libres stratégiques dans l’écosystème de logiciels propriétaires, dans les situations où les contraintes de la GPL auraient eu des effets trop néfastes sur la diffusion des logiciels en question.

Une nouvelle version de la licence LGPL a été déployée en 1999 : la GNU Lesser General Public licence, avec par la suite une mise à jour effectuée en 2007.

La licence MPL (Mozilla Public License) a été créée pour la diffusion du code source du navigateur Netscape. La société souhaitait en effet favoriser la création de solutions – mêmes propriétaires – intégrant son logiciel, tout en s’assurant que les modifications apportées resteraient accessibles et disponibles.

Cette licence raisonne à l’échelle du fichier (et non pas de l’oeuvre tout entière) et demande à ce que tout fichier contenant du code sous licence MPL reste sous cette même licence. Elle a inspiré de nombreuses autres licences, telles les CDDL ou encore EPL, qui la complétèrent et adaptèrent quelques-unes de ses clauses (notamment le copyleft qui fonctionne par plug-in en matière de licence EPL).

La licence a été mise jour en 2012 et est considérée aujourd’hui comme l’une des licences copyleft les plus robustes et réceptives à l’écosystème industriel.

Richard Stallman, son auteur et également créateur du logiciel GNU Emacs, a décidé de lui associer en 1985 une licence spécifique, qui définissait avec précision le cadre permettant la réutilisation de la licence.

Surtout, elle imposait la conservation de la licence sur toutes les versions dérivées (ou contenant une partie) du logiciel. Il s’est ainsi servi de ses propres droits d’auteurs pour limiter toute réappropriation du logiciel par d’autres.

C’est la “naissance” du copyleft, share alike ou encore partage à l’identique.

De nombreuses licences copyleft furent ensuite rédigées par la FSF, en adaptant à chaque fois le texte aux logiciels ciblés, renforçant progressivement l’assise juridique des licences et garantissant plus de sécurité aux utilisateurs.

En 1989 a été publiée la licence générique du projet GNU : la GNU General Public License (GNU GPL), répondant ainsi à une volonté d’harmonisation des textes, ce qui eut l’effet d’accélérer la diffusion de la licence, devenant rapidement centrale dans le paysage du Libre.

S’appuyant sur les nombreux retours de la communauté croissante des hackers ayant adopté cette licence, une seconde version de la GNU GPL fut publiée en 1991 (introduisant pour la première fois une clause relative aux brevets).

Utilisée par de très nombreux projets open source, la licence GNU GPL a véritablement su s’imposer : les statistiques sur les licences la positionnent généralement en lice avec la licence MIT. Connue des développeurs, elle bénéficie d’une véritable communauté de confiance. Ce succès est l’aboutissement d’un processus continu d’adaptation aux évolutions des réalités économiques et juridiques des industries.

Ainsi, sa dernière version - GPL v3, sortit en 2007 - a fait l’objet de longs travaux collectifs lors d’une consultation publique ayant duré un an et demi.

Parmi les améliorations apportées par cette version, on peut citer une meilleure lisibilité de la licence et une protection renforcée contre les brevets logiciels. Autre nouveauté, la GPL v3 offre la possibilité à un tiers qui aurait violé la licence de revenir dans ses droits lorsqu’il cesse l’infraction.

Enfin, la GPL v3 bénéficie d’une meilleure compatibilité avec les autres licences libres, afin de permettre plus de coopération entre les projets Open Source.

Apparue la même année, la licence Affero GPL (identique à la GPL, à l’exception de son article 13) organise un mécanisme spécial permettant d’imposer au licencié de distribuer ses codes sources lorsqu’il modifie un composant soumis à cette licence et qu’il le fait interagir avec des tiers par le réseau.

En raison de leur simplicité de prise en main, de nombreuses nouvelles licences permissives apparurent durant les années 1990.

La plupart étaient des variations plus ou moins fidèles des licences publiées par le MIT et Berkeley, respectivement les licences MIT et BSD, mais d’autres se démarquèrent.

L’Apache Group, à l’origine du serveur web éponyme, mit ses développements sous une licence très libérale de type «This code is in the public domain, and give us credit» et adopta en 1995 une première version de la licence Apache s’inspirant de la licence BSD originale, avant de lancer une seconde version en 2004 qui lui était propre.

Le respect de la paternité de l’œuvre est souvent l’unique revendication des contributeurs passionnés, en règle générale les licences permissives imposent simplement la transmission de ces dernières et une mention des droits d’auteurs avec le logiciel.

La première version de la licence BSD (dite 4-clause BSD) contenait une clause qui devint rapidement polémique : tous les documents publicitaires mentionnant les caractéristiques ou l’utilisation de ce logiciel devaient afficher une mention concernant tous les auteurs. Parfois une centaine de mentions était obligatoire lors de la commercialisation d'un produit utilisant les composants sous ces licences permissives.

Il s’en est suivi des situations où le formalisme imposé était beaucoup trop lourd pour être raisonnable étant donné le nombre important de contributeurs et de composants utilisés.

Aujourd’hui les licences se sont adaptées pour éviter ces inconvénients, et ce type de clause reste marginale.

Un des objectifs des licences est d’être facilement utilisable pour permettre le partage de la connaissance, tout en étant un socle suffisamment contraignant pour pouvoir garantir le respect des droits des auteurs d’une part et la liberté des utilisateurs d’autre part.

Les licences permissives sont donc moins contraignantes que les licences de type copyleft. Le projet licencié et ses modifications intégrées à un projet plus vaste peuvent être distribués sous d’autres termes et sans le code source.

Les licences permissives comme les licences MIT, BSD et Apache supportent très bien la cohabitation avec d’autres licences. Pour ces raisons, l’utilisation de composants, dans ce contexte, intégrés dans des projets commerciaux est courante.

La majorité des produits de la firme Google est distribuée sous licence permissive, Android est essentiellement distribué sous licence Apache, à l’exception de certains composants bien isolés tel le noyau Linux.

Au départ il existait une seule licence par logiciel, et c'est uniquement en 1989, avec la GNU GPL, qu'on en a créé une pouvant être utilisé pour tout type de logiciel : c'est alors une rupture avec le mouvement précédent où l’on créait une licence par projet.

La limitation du nombre de licences permet de rendre les projets interopérables, d’harmoniser les cadres juridiques pour faciliter la réutilisation des contenus licenciés.

L'usage de standards fluidifie les échanges et interconnexions, ainsi que la gestion des droits et des obligations liées aux licences. Les utilisateurs ont moins d’efforts à fournir pour utiliser les projets libres étant donné qu’il y a moins de licences différentes à gérer.

Depuis cette vague de standardisation, les licences sont de plus en plus génériques, permettant ainsi de lutter contre la prolifération de nouvelles.

Initié par les industriels, le projet SPDX (qui a vocation à favoriser l’échange d’informations relatives aux composants et aux licences Open Source) a permis de pousser encore plus loin ce mouvement de standardisation, en créant un identifiant unique pour chaque licence.

Comme évoqué précédemment, il existe aujourd'hui deux types de licence : les copyleft et les permissives.

Les licences copyleft rendent persistantes les libertés consenties en obligeant les utilisateurs subséquents à concéder systématiquement les mêmes libertés.

Il est parfois dit des licences copyleft qu’elles “forcent” à la liberté pour que ces contributeurs subséquents restent titulaires de leurs droits et donc libres d'exploiter leurs contributions au projet. Il en résulte une relation de confiance qui sécurise et favorise les collaborations entre professionnels et particuliers.

À l'inverse, on parle de licence permissive lorsque seules les obligations de celui qui reçoit l'œuvre doivent être transmises, laissant le contributeur libre d'en ajouter d'autres lors du transfert aux utilisateurs ultérieurs (le logiciel redistribué perd souvent les libertés qui lui étaient attachées).

Elles sont souvent assimilées à des renonciations de droits du fait de leur proximité avec le statut de domaine public puisqu'elles n'imposent en règle générale que le respect de la paternité, autrement dit il est demandé de citer le nom de l'auteur d'une oeuvre lorsque vous êtes utilisateur sous licence permissive.

Elles sont notamment compatibles avec une redistribution commerciale (cf. MIT, BSD, Apache) --> cf. MAC OS X

À noter que les licences ne sont pas figées, elles évoluent en fonction des besoins des contributeurs des projets, en général pour gagner en précision et en qualité, ou recouvrir d’autres aspects même si leur rythme d’adaptation est sensiblement plus lent que celui des projets Open Source eux-mêmes.

Ressources :

• Option Libre, du bon usage des licences libres, Framasoft, coll. « Framabook », Paris, 2011, 307 pages, librement téléchargeable ; version papier : 20 euros.
• François Pellegrini et Sébastien Canevet, Droit des logiciels - Logiciels privatifs et logiciels libres, PUF (20 novembre 2013)
• Site du projet Veni, Vidi, Libri

Pour autant, le droit a pour vocation première d’organiser les relations sociales et ainsi de favoriser la collaboration. En proposant un cadre transparent et sécurisé, les outils juridiques renforcent la confiance des acteurs, leur permettant de coopérer efficacement.

Le droit est ainsi au cœur des projets Open Source, encadrant aussi bien la diffusion du logiciel que les relations entre les acteurs qui gravitent autour.

L’exemple des licences libres et open source est le plus parlant.

Concrètement, la licence libre est le contrat qui relie les contributeurs d’une communauté. Elles bouleversent la propriété intellectuelle sans toutefois la renverser : s’adaptant aux nouveaux usages du numérique, la propriété intellectuelle est ainsi la base sur laquelle se construit la collaboration.

Il faut bien comprendre que l'absence de licence Open Source associée à un projet empêche la réutilisation par les tiers et donc la collaboration.

Les licences ne sont ainsi et en réalité « que » des outils construits pour organiser un cadre de coopération entre tous les contributeurs et utilisateurs d'un projet. Pensées par le « bas », c’est-à-dire par les utilisateurs des logiciels, elles permettent d’organiser la collaboration entre plusieurs acteurs, parfois des milliers, qui partagent leurs droits sous la même licence.

Le cadre juridique qui porte le mouvement de l’Open Source ne peut que nous étonner par son succès et sa capacité à s’être imposé au fil du temps, en témoigne le nombre réduit de contentieux. Les licences libres rassurent, par les garanties qu’elles confèrent en matière de souplesse, de coût, de fiabilité, d’innovation, de pérennité.

Au sein des projets ouverts, au-delà des licences libres, d’autres documents spécifiques jouent des rôles structurants et organisent la collaboration.

Par exemple, de nombreuses communautés Open Source font signer aux contributeurs, à chaque contribution au projet, des documents spécifiques : les accords de contributions. Ces accords (CLA, CAA…) sont des textes qui encadrent juridiquement les contributions de tiers aux logiciels développés.

En effet, lorsqu'un contributeur souhaite proposer des éléments soumis à des droits de propriété intellectuelle (code, documentation) pour que ceux-ci soient intégrés dans un projet Open Source, il est nécessaire qu'il place sa contribution sous la ou les licences du projet et donc qu'il dispose des droits de propriété intellectuelle.

Il est ainsi courant que les mainteneurs du projet lui demandent de signer un document spécifique en attestant, et délimitant précisément les droits cédés par le contributeur sur la contribution qu’il soumet.

BREF : ces documents jouent un rôle déterminant pour instaurer et renforcer la confiance des parties prenantes d’un projet ouvert.

Ressources :

• Harmony Agreement
• CLA Hub
• Site du projet Veni, Vidi, Libri

Les droits de propriété intellectuelle se décomposent en différentes branches : d’un côté la propriété littéraire et artistique permettant la constitution de monopoles d’exploitation dès la création de l’objet de la protection (ex : œuvre de l’esprit protégée par un droit d'auteur), de l’autre côté la propriété industrielle qui repose sur l’obtention de titres après avoir suivi une procédure de dépôt auprès de l’INPI.

La propriété littéraire et artistique est composée:

• du droit d’auteur : l’auteur d’une œuvre de l’esprit (création de forme originale) dispose d’un monopole d’exploitation exclusif sur celle-ci. Il est titulaire de droits patrimoniaux (droit d’exploiter l’oeuvre) et d’un droit moral (droit au respect de son nom, sa qualité et son œuvre) ;
• des droits voisins : droit des artistes-interprètes, droit des producteurs de phonogrammes et de vidéogrammes. Ils ne sont pas ici détaillés, car ne concernent pas le logiciel
• du droit sui generis des bases de données : protège les investissements du producteur de la base de données qui a le droit d’interdire l’extraction de tout ou partie du contenu de la base.

La propriété industrielle :

• le droit des marques : la marque est un titre de propriété portant sur un signe distinctif (ex : logo, nom). La durée de protection est de 10 ans (renouvelable indéfiniment) ;
• le droit des brevets : le brevet est un titre de propriété portant sur une invention. La durée de protection est de 20 ans à compter du jour du dépôt. Une fois que le brevet est arrivé à son terme, l’invention est considérée comme étant dans le domaine public ;
• le droit des dessins et modèles : protège l’apparence d’un produit ou d’une partie de produit (textures, contours, couleurs, matériaux, formes, lignes etc.)
• On retrouve également d'autres droits non détaillés ici, car ne concernent pas le logiciel.

Dans ce cadre, le logiciel (entendu au sens strict : code source, code objet, documentation associée (cahier des charges, dossiers de spécifications fonctionnelles...) est protégé par le droit d’auteur. Toute reproduction, traduction, modification ou tout arrangement ne peut être réalisé sans l’accord préalable de l’auteur (sauf pour des raisons d’interopérabilité).

Le logiciel peut être commercialisé sous une marque, laquelle ne pourra pas être utilisée par un tiers dans la vie des affaires pour des produits identiques ou similaires, sans autorisation préalable du titulaire des droits.

Le logiciel peut faire l’objet d’un brevet ou intégrer un, ou des composants faisant eux-mêmes l’objet d’un brevet. Il est alors nécessaire d’obtenir l’accord préalable du titulaire des droits. Cependant, l’Office européen des brevets refuse de délivrer des brevets sur des logiciels (sauf en tant que business methods), à la différence des Etats-Unis où c’est une pratique courante.

A défaut d’autorisation, toute personne effectuant un acte relevant du monopole du titulaire des droits s’expose à une action en contrefaçon.

À ces droits de propriété intellectuelle s’ajoute la liberté contractuelle. Le droit des contrats (l’autorisation du titulaire des droits) se matérialise au travers de la conclusion d’un contrat de licence par lequel il concède un certain nombre de droits limitativement énumérés (tout ce qui n’a pas été concédé est considéré comme retenu). Ce contrat définit le périmètre des actes autorisés, toutes les actions se trouvant en dehors de ce périmètre sont considérées comme de la contrefaçon.

Ressources :

• Michel Vivant, Jean-Michel Bruguière, Droit d'auteur et droits voisins, Dalloz, Edition : 12/15 - 3e édition

Le code source est un texte qui représente les instructions de programme telles qu'elles ont été écrites par un programmeur. Le code source est écrit dans un langage de programmation permettant d’être compris par les humains.

Une fois le code source écrit, il permet de générer une représentation binaire d'une séquence d'instructions — code binaire ou code objet — exécutables par un microprocesseur servant d'interface avec la machine. Ce langage binaire est uniquement compréhensible par l’ordinateur qui va l’utiliser pour exécuter le programme. Ce code est donc le résultat de la compilation du code source.

La compilation est ainsi l’opération réalisée par un programme (le compilateur) consistant à transformer le code source écrit dans un langage de programmation, en un autre langage informatique : le langage cible.

Pour qu’il puisse être exploité par la machine, le compilateur traduit le code source en un langage machine. De façon marginale, certains langages n’ont pas besoin de passer par une étape de compilation afin d’être exécutés (on dira alors qu’ils sont interprétés via des machines virtuelles).

Un autre concept important à saisir concerne les liens dynamiques ou statiques qu'il peut y avoir entre les logiciels. Certaines licences libres et Open Source attachent une importance particulière aux relations qui lient chaque composant.

La simple « agrégation » est ainsi souvent opposée à la « combinaison de deux modules dans un seul programme » :

• La notion d’agrégation concerne classiquement la situation où plusieurs programmes sont côte à côte sur un même support (tel qu’un DVD, Disque dur ou encore une clé USB).
• Dans un cas de simple agrégation, il s'agit de programmes distincts et non de parties d'un même programme. Dans ce cas, si l'un des programmes est régi par une licence, cela n'a pas d'effet sur l'autre programme. Ce point est d’ailleurs l’un des critères de l’Open Source Definition. En ce sens, une licence allant au-delà de la simple agrégation ne peut être considérée comme Open Source.

À l’inverse, si les modules sont inclus dans un même fichier exécutable, ils sont indéniablement combinés dans un seul programme. Il en va de même si les modules sont conçus pour être exécutés par édition de liens, cela signifie presque à coup sûr une combinaison en un seul programme.

Il existe ainsi deux types de liens, les liens dynamiques et les liens statiques. Entre une liaison dynamique et une liaison statique, la différence se situe lors de la sollicitation de la bibliothèque par le programme utilisateur : en cas de liaison statique, le programme sera complété au moment de la compilation pour ne faire qu'un seul binaire ; en cas de liaison dynamique, le programme sera complété au moment de l’utilisation.

Par ailleurs, la notion de DRM (Mesures Techniques de Protection) concerne les protections techniques susceptibles d’être intégrées à une œuvre afin de limiter son utilisation à certains contextes. Par exemple, il peut s'agir de limiter le nombre d'utilisateur pour un logiciel donné sur certains types d'ordinateur, ou encore d'en limiter la durée d'utilisation.

De la même façon que ce qui fut appelé plus tard la “Tivoization”, en référence à la société Tivo qui avait limité son matériel afin qu’il ne puisse exécuter des versions modifiées par des tiers de sa version de Linux, ces pratiques sont très contestées dans le domaine du logiciel libre qui cherche à ouvrir le plus de champs d’action possibles aux potentiels contributeurs et utilisateurs.

Toute solution technique qui viendrait limiter la capacité d'amélioration du logiciel serait considérée comme contraire à l'esprit de la licence.

Pour finir, il est nécessaire de bien préciser les notions de distribution, d’usage par le réseau et d’API.
La notion de distribution correspond à la mise à disposition d’une copie de la création, logiciel ou autre, à un tiers. Elle peut être réalisée au travers d’un support matériel ou par le réseau, c'est-à-dire le transfert d'un fichier par internet.

Le Saas, pour “Software as a Service” désigne l’utilisation de logiciels faite sur les serveurs d’un opérateur sans que les logiciels ne soient distribués aux utilisateurs de ce service.

Précisons néanmoins que certains langages s’exécutent du côté du client, c’est-à-dire de l’internaute, et que le chargement de la page internet aura pour première conséquence le téléchargement puis l’exécution dudit code, on parle alors de distribution classique.

Enfin, les API sont des interfaces de programmation, des passerelles permettant à deux applications autonomes de dialoguer et d'échanger au travers d’un réseau, au travers de protocoles standards. S’il est bien sûr nécessaire de se conformer aux conditions d’utilisation de ces APIs, cela n’entraîne aucune conséquence en termes de licences Open Source.

Ressources :

• Page Wikipedia sur la Tivoisation
• Page Wikipedia sur les DRM
• Site du projet Veni, Vidi, Libri