p.2L’innovation, la création ou le développement reposent aujourd’hui, plus que jamais, sur une très large réutilisation des travaux de tiers. Dès lors, la question n’est plus de savoir qui détient les droits de propriété intellectuelle, mais simplement comment pouvoir les exercer ! Cette situation – une concentration de titulaires de droits exclusifs réunis pour l’exploitation d’une seule création – amplifie l’importance d’une bonne maîtrise tant des enjeux de propriété intellectuelle que des licences libres.

p.3Chaque nouveau projet se traduit par une multitude de relations contractuelles destinées à favoriser et sécuriser les collaborations composées d’une part croissante de contrats types fixant à priori et de façon intangible les conditions d’utilisation. À cet égard et puisqu’elles opèrent une cession de droits d’exploitation très large facilitant la réutilisation de leurs créations (au bénéfice seulement de ceux qui respectent le cadre qu’elles ont fixé), les licences libres et open source constituent une réponse optimum à cette recherche d’une innovation rapide et efficace. La liberté offerte est néanmoins conditionnée au respect de certaines conditions et obligations qui nécessitent une vigilance particulière (avec comme sanction l’action en contrefaçon). Ainsi, cette logique de mutualisation, génératrice d’importantes économies pour l’industrie, nécessite la mise en place d’une gestion spécifique, et notamment juridique, destinée à garantir le respect de l’ensemble des licences. Innover dans ce cadre juridique ouvert impose donc :

p.4Ces deux composantes doivent imprégner l’élaboration de bonnes pratiques au sein des projets, voire de politiques open source formalisées au sein des sociétés concernées.

p.5Ce dernier chapitre est celui le plus orienté « pratique » de l’ouvrage, répondant à la question « comment, concrètement, doit-on utiliser les licences libres ». Pour commencer, il convient d’admettre qu’il est encore habituel que les enjeux relatifs aux licences libres ne soient appréhendés que trop tardivement, par exemple lorsque la distribution de la création est d’ores et déjà programmée, ce qui abouti à des situations de concession peu satisfaisantes tant pour l’équipe juridique et que technique. Une réflexion en amont doit donc être systématiquement préférée, car même si chaque licence obéit à un mécanisme qui lui est propre, il est néanmoins possible de donner un certain nombre de recommandations quant à la mise sous licence libre (3.1) et la diffusion sous licence libre (3.2).

p.6Les projets doivent veiller à respecter l’ensemble des licences attachées aux composants qu’ils utilisent, notamment vis-à-vis du cadre juridique qu’elles imposent et ses conséquences quant au choix et l’ajout d’une licence (3.1.1) et du formalisme qui leur est attaché (3.1.2).

p.7Une bonne connaissance des licences est la condition nécessaire à l’appréhension du cadre juridique qu’elles induisent. Cette appréhension permet alors de prendre toute mesure liée aux contraintes issues des choix des composants. C’est en agissant avec méthode que l’on choisit la licence (3.1.1.1) et que l’on s’assure du respect des conditions nécessaires à l’ajout d’une licence libre (3.1.1.2).

p.8Le choix initial de la licence est fondamental : en termes de marketing afin d’interpeller des communautés déjà existantes ; en termes stratégiques, car le modèle économique développé autour du logiciel peut en dépendre ; et enfin en termes juridiques puisque l’ouverture du projet peut engendrer l’arrivée de contributions pour lesquelles le titulaire initial ne pourra pas unilatéralement changer de licence. Une licence adaptée au logiciel et aux attentes de la société facilitera la structuration de la collaboration future, cette dernière n’étant alors concentrée que sur l’optimisation et la mutualisation dans le développement et l’exploitation du logiciel (les licences assurent, elles, les cessions de droits de propriété intellectuelle nécessaires). Le choix de la licence peut aussi avoir pour objectif d’ouvrir ou de former des pistes de collaboration avec des sociétés concurrentes : on parle alors de coopétition, pour traduire l’idée d’une coopération entre des entreprises potentiellement concurrentes qui gagnent toutes au développement du Libre.

p.9Plusieurs démarches doivent être décrites : la création d’une nouvelle licence (3.1.1.1.a), ou le choix d’une ou plusieurs licence(s) existante(s), éventuellement adaptée(s) au logiciel (3.1.1.1.b).

p.10S’épargnant tout choix, il peut être tentant de s’orienter vers la rédaction d’une licence spécifique, particulièrement lorsque les projets et structures impliquées sont importants.

p.11Néanmoins, avant de se lancer dans cet exercice, il est nécessaire de mesurer l’intérêt et les inconvénients de cette solution, généralement motivée par une volonté de créer un pot commun « encadré » ou de créer une licence « mieux adaptée » aux besoins. En effet, ces préoccupations emportent aussi un certain nombre de désavantages qu’il peut-être préférable d’éviter.

p.12S’il s’agit de sectoriser afin de ne pas risquer la récupération par un projet ou une entreprise concurrents, l’effet n’est pas garanti (compte tenu des libertés conférées par la licence) et les inconvénients sont non négligeables : la manne de composants open source tiers devient indisponible (en effet, plus la licence est spécifique et plus la compatibilité sera difficile à atteindre) et il sera alors plus difficile d’intéresser les tiers aux projets (et il n’est pas possible d’ajouter une compatibilité en faveur d’autres licences sans entrer en contradiction avec cet objectif de réservation – mieux vaut revoir complètement sa position que d’aboutir à la situation hybride qui consisterait à ajouter in extremis une telle compatibilité).

p.13S’il s’agit, de manière tout à fait légitime, d’une volonté de créer une nouvelle licence optimisée pour la création (et son auteur), cet effort peut aussi s’avérer contre-productif : il fait courir le risque que la licence contienne des failles non existantes (ou résolues) dans d’autres licences, et demande, outre sa rédaction, la mise en œuvre d’un travail de communication, d’interprétation et d’assistance dans la compréhension de cette licence, ce qui est, une nouvelle fois, une activité coûteuse en temps et en énergie¹. En effet, la rédaction d’une licence est un projet ambitieux. Il n’est pas rare que les nouvelles versions de licences prennent un ou deux ans avant d’être terminées. Un tel projet fait appel à des compétences particulières. Il est ainsi généralement plus sûr d’utiliser une licence largement répandue chez des grands groupes tels IBM, HP, Microsoft, Sun, Oracle, Google, etc.. Le seul aspect positif est la potentielle compatibilité avec la licence utilisée comme canevas, avantage bien faible compte tenu des autres solutions assurant une même compatibilité.

p.14Ainsi, la rédaction d’une nouvelle licence open source, si elle peut dans certains cas (limités) se justifier, ne doit pas être une solution « par défaut », mais au contraire le fruit d’une réflexion globale qui ne peut faire l’économie d’une sélection en amont d’une ou plusieurs licences « modèles ». Elle devra par ailleurs être le fruit de professionnels, aptes à intégrer les contraintes de sécurité juridique face à l’écosystème existant du Libre et de l’open source.

p.15L’aspect politique pouvant, à lui seul, être la justification d’un tel choix, il est alors nécessaire de rappeler les éléments qui précèdent afin que les risques soient clairement identifiés (un mauvais choix en la matière pourra annuler l’intégralité des avantages qu’apporterait l’ouverture du projet).

p.16Plutôt que de « réinventer la roue », il est généralement conseillé d’utiliser une ou plusieurs licences existantes.

p.17Le choix d’une licence est une juste combinaison de stratégie et de tactique.

p.18En termes stratégiques, le choix de la licence doit traduire les intérêts juridiques, techniques et commerciaux du projet (voire de la société). Par ailleurs, il doit intégrer les contraintes issues de la réutilisation de créations tierces, sous licence open source ou non.

p.19Il est nécessaire d’adopter la licence la plus adaptée à son projet en se concentrant sur ses obligations, son étendue, son élément déclencheur et éventuellement la compatibilité qu’elle organise. Il convient donc, dans un premier temps, de réaliser un«  cahier des charges et des besoins » et de dresser un inventaire des licences qui répondent, en totalité ou en partie, aux attentes. Dans un second temps, il peut être utile d’estimer l’intérêt des licences au regard du contexte : est-ce important d’utiliser une licence largement connue et testée ? Doit-on s’inspirer des choix opérés par des projets concurrents analogues ? Ces réponses ne peuvent être données qu’au cas par cas, en fonction de l’examen et de l’approche choisie. Incontestablement, une licence disposant d’une large notoriété participe avantageusement à la communication qui suivra la libération de la création. En revanche, le choix d’une licence similaire à un projet concurrent est un pari dont il faut bien mesurer les aléas : les contributions pouvant librement circuler d’un projet à l’autre, celui qui réunit la meilleure communauté risque de l’emporter et de détourner à son profit les contributeurs de son concurrent ; à l’inverse, bénéficier de l’expérience et de l’expertise déployée par une société concurrente peut s’avérer être un choix judicieux.

p.20Une fois sélectionnée la licence (ou un nombre limité de licences), il est nécessaire de faire preuve de tactique de sorte à peaufiner l’usage fait de la licence afin de s’assurer qu’elle réponde en tout point aux objectifs de l’auteur ou du projet. La seule existence de plusieurs centaines de licences laisse présager un nombre tout aussi grand de situations particulières les ayant justifiées. Il faut néanmoins rester vigilant au phénomène d’incompatibilité que cette multiplication a favorisé (cf. supra). Cette tactique peut prendre la forme d’interprétations ou d’exceptions.

p.21En cas de clauses imprécises ou équivoques, il peut être utile de préciser le sens attendu, voire de désigner une personne tierce – un médiateur ou proxy – comme source d’interprétation. Cela confère une portée précise à la licence, qui tient les parties et le juge. C’est cette technique, dite de l’« interprétation » qu’utilisa Linus Torvalds sur le noyau Linux².

p.22L’usage des exceptions est une autre technique plus radicale qui consiste à modifier une licence préexistante en ajoutant, dans une clause jointe à la licence (ou insérée dans les en-têtes des fichiers), une spécificité qui déroge aux termes initiaux avec pour effet de rendre la licence finale plus ou moins contraignante. Cela permet, par exemple, de réduire efficacement la portée d’un copyleft, en lui fixant une étendue différente, en excluant plusieurs logiciels ou une catégorie entière de logiciels (plusieurs exceptions peuvent d’ailleurs être attachées à des parties différentes d’un logiciel³). Il est à noter qu’en l’absence de stipulation contraire, une clause additionnelle qui ne fait « qu’ajouter des droits » pourra être supprimée par tout licencié au moment de la redistribution d’une copie de cette création⁴.

p.23La maîtrise de plus en plus fine de la pratique contractuelle liée aux licences open source conduit aujourd’hui à conseiller une pratique réfléchie et adaptée de ces exceptions et interprétations. Les premières confèrent plus de souplesse aux licences⁵, les secondes assurent une plus grande sécurité juridique. Un bon usage de celles-ci peut permettre de prévoir et de résoudre a priori la plupart des situations préjudiciables (obligations particulières du licencié, problèmes d’incompatibilité, failles au sein des licences, etc.).

p.24On parle de multilicence lorsqu’une seule et même création est simultanément disponible sous différentes licences : qu’elles soient toutes open source ou qu’au moins l’une d’elles le soit. On ne parle plus de « double licence » lorsque la licence open source n’est qu’une option au côté de licences propriétaires classiques. Multiplier les licences permet généralement d’associer leurs avantages : assurer une compatibilité au bénéfice de plusieurs licences, bénéficier de la renommée de l’une, consolider la cession de droits, etc.

p.25Contrairement à ce que beaucoup semblent croire, il s’agit d’une technique simple et efficace :

p.26C’est donc une solution qui, utilisée à bon escient par les auteurs, peut permettre optimiser la diffusion des créations et faciliter les contributions. Enfin, les motivations ne sont pas uniquement d’ordre juridique et il est possible de constater des situations où l’une des licences « contenant » déjà la seconde, la réunion des deux ne confère ainsi aucune prérogative spéciale au licencié⁸. Inutile juridiquement, mais utile en termes de communication…

p.27Pour finir, ce mécanisme n’est pérenne dans son application sur un projet qu’autant que l’ensemble des contributions se fasse a minima sous licence multiple (quitte à ce que celles qui ne le seraient pas soient réécrites), ou licence permettant ces licences multiples (par exemple des licences du type MIT ou BSD).

p.28L’ajout d’une licence libre à une création peut être du fait volontaire d’une personne physique ou morale qui diffuse l’œuvre (par exemple en application d’une politique globale à l’échelle de son entreprise ou du projet, etc.) ou par application des contraintes d’une licence (clause dite copyleft) qui imposerait l’extension des termes à d’autres composants (généralement du fait de leur combinaison ou d’une relation d’utilisation).

p.29Quel que soit le contexte, celui qui diffuse une création selon les termes d’une licence open source doit veiller à être en capacité de le faire. Il ne s’agit pas ici de savoir s’il a la capacité d’opérer sur le marché, mais de savoir si cela se fait en conformité avec les différents droits de propriété intellectuelle qui peuvent porter sur la création – les licences libres n’étant en effet que des outils juridiques dont l’effectivité repose sur la possession de droits de propriété intellectuelle suffisants. Deux statuts peuvent exister :

p.30Finalement, un tel ajout est peu complexe vis-à-vis des créations que l’on contrôle personnellement (3.1.1.2.a), mais il en va autrement en présence de créations tierces soumises au respect de licences particulières (3.1.1.2.b).

p.31Le titulaire des droits peut être le créateur originaire (ou son employeur si l’œuvre est créée « dans l’exercice de ses fonctions ou d’après les instructions de son employeur »⁹) ou une personne qui se serait fait céder l’intégralité des droits (par exemple le bénéficiaire de la création dans le cadre d’un contrat de commande lorsqu’une telle répartition des droits est prévue). On ne saurait trop conseiller à une personne morale (société, association, etc.) de vérifier les droits qu’elle détient (par contrat, dévolution automatique ou du fait de ses propres démarches en cas de dépôts de brevet, marques, etc.).

p.32Le titulaire des droits va ainsi user de ses prérogatives patrimoniales¹⁰ afin d’organiser le partage de ses droits gracieusement¹¹ au profit de détenteur de support ou de l’utilisateur de la création sur laquelle porte la licence. Cette cession non-exclusive n’empêche aucune autre exploitation ultérieure :

p.38Le second statut, celui de cessionnaire d’une licence, est régi par contrat et est généralement assorti d’un certain nombre de conditions : qu’il s’agisse d’une autre licence open source ou d’une cession limitée (il peut, par exemple, ne disposer que du droit de céder les droits, sans possibilité d’en jouir lui-même).

p.39Les conditions peuvent être plus ou moins contraignantes, mais il faut garder à l’esprit qu’il est impossible de simplement « remplacer » une licence et, ainsi, que toute utilisation d’une nouvelle licence doit respecter celles préexistantes – c’est la raison pour laquelle on parle d’ajouter une licence « au surplus de celle(s) déjà existante(s) ».

p.40Ainsi, lorsque plusieurs licences nécessitent leur extension à un même composant, il convient de régler en amont les problèmes de compatibilité entre elles (la situation la plus simple étant lorsqu’une telle compatibilité est expressément assurée au sein de la licence) – en déterminant dans quelle mesure la distribution sous une licence spécifique respecte les autres licences – afin de vérifier ensuite que l’ajout est bien possible au regard de la licence d’origine.

p.41Il convient donc de déterminer les situations de superposition et, à défaut d’une compatibilité expresse, de vérifier l’existence d’une compatibilité logique entre les différentes licences (c’est-à-dire la possibilité de respecter l’une en utilisant l’autre, généralement parce qu’elle n’oblige pas moins et ne donne pas plus de droits). Cette problématique est relativement simple lorsque les licences font partie d’une même famille de licences¹², mais devient rapidement plus complexe lorsque les licences sont d’origines diverses. La dernière version de la GNU GPL (v. 3) s’appuie sur ce principe pour accueillir en son sein une souplesse et une modularité qui lui permettent d’assurer la compatibilité à l’égard de licences libres et open source auparavant incompatibles¹³ : en permettant, sur chaque nouvelle contribution, d’une part, l’ajout de permissions additionnelles et, d’autre part, l’ajustement par l’utilisation de certains termes supplétifs limitativement autorisés¹⁴.

p.42Néanmoins, il peut arriver dans certaines situations que les obligations soient contradictoires et inconciliables (impossibles à respecter simultanément), y compris en présence seulement de composants open source, on parle alors d’incompatibilité entre les licences : la création ainsi composée ne peut être exploitée en respectant cumulativement toutes les licences. Parfois, la lecture des licences peut permettre, matériellement¹⁵ ou techniquement, de résoudre certaines incompatibilités (par exemple dans l’hypothèse de certaines formes de distribution¹⁶, certains modes de distribution¹⁷ et certaines constructions de la création¹⁸). Mais de tels contournements compliquent la compréhension de la licence et ne sont généralement pas souhaitables – ou possibles – et, à défaut de solution à cette incompatibilité, il faudra renoncer à l’utilisation d’un composant (ce qui revient souvent à le réécrire), voire à la diffusion d’un ensemble de composants, ou encore se rapprocher de l’auteur (ou des auteurs¹⁹) de la création afin qu’il consente soit à une exception expresse²⁰ indiquant à quel logiciel il entend ne pas étendre sa licence²¹ (dans un fichier supplémentaire distribué avec le logiciel et sa licence), soit à l’utilisation d’une autre licence²².

p.44La maîtrise effective des éléments constitutifs de la création est essentielle dans les projets open source puisque ce n’est que lorsque l’utilisateur est matériellement en mesure d’en user que les droits cédés par la licence trouvent leur utilité²³ – rendant indispensable l’accès à un certain nombre d’éléments matériels (code source, documents préparatoires, scripts, etc.).

p.45Ainsi, au-delà de la simple cession de droits, les licences libres et open source contiennent généralement un ensemble de dispositifs pratiques qui ont pour fonctions principales d’assurer aux utilisateurs une bonne information (3.1.2.1) et une réception effective de la création (3.1.2.2). C’est sur leur fondement que la cour de Munich avait, courant 2007, rendu une décision en ce sens lors de l’affaire Welte vs. Skype Technologies SA, condamnant la société Skype qui n’incluait ni une copie de la GNU GPL ni le code source correspondant au binaire conformément au texte de la licence (Skype incluait néanmoins l’URL de celui-ci par l’intermédiaire d’un flyer).

p.46La reconnaissance par les pairs, ainsi que l’entretien d’une « image » liée à leurs activités créatrices (pour des raisons artistiques ou économiques), sont des éléments moteurs pour de nombreux individus. Les mentions légales, obligatoires, y pourvoient, mais sans indiquer précisément quelles sont les actions attendues et quel formalisme doit accompagner la réutilisation et la diffusion de leurs œuvres (les juges appréciant au regard des « usages du métier »).

p.47C’est ce manque – moins présent pour les œuvres non logicielles²⁴ – que comblent les contraintes des licences relatives au formalisme, sous la forme d’une série d’obligations qui assurent une bonne information quant à l’origine du code et des conditions de son exploitation auprès des utilisateurs. Ces obligations vont parfois plus loin que les simples mentions légales – telles les clauses dites « de publicité » qui s’étendent à tous les documents commerciaux publicitaires relatifs au logiciel qui les contient.

p.48Ainsi, il est possible de distinguer les obligations opérant une mise à disposition passive des informations légales (3.1.2.1.a) et celles contraignant à un affichage actif (3.1.2.1.b).

p.49Les informations légales (y compris le texte des licences) figurent dans les en-têtes des fichiers et (si nécessaire) dans des fichiers joints aux sources.

p.50De manière générale, tout fichier (comprenant du code sous licence libre ou non) devrait contenir un en-tête affichant les « mentions légales minimums » : c’est-à-dire rappelant le nom et la qualité du titulaire de droits, la date de la création (et éventuellement des ajouts), et les licences utilisées. Une mention excluant toute garantie est aussi à prévoir dans le cadre des licences libres. Elle peut être assez courte pour les petits fichiers, et reprendre l’intégralité de la clause d’exclusion de garantie de la licence utilisée pour les fichiers plus importants.

p.51Pour éviter d’alourdir inutilement le code distribué, toutes les mentions trop longues pour être insérées en l’état dans chaque en-tête peuvent être transférées dans des fichiers joints aux sources :

p.52Il s’agit ici de bon sens et de bonnes pratiques, les licences n’imposant généralement que des mentions « raisonnables »²⁶ de ces éléments, d’autres fichiers peuvent venir compléter cette liste : changelog.txt, legal.txt, export.txt, etc.

p.57Dépassant l’affichage classique des mentions légales, quelques licences demandent aux licenciés de s’assurer par un comportement actif que les utilisateurs auront bien connaissance des mentions légales, de la licence, etc.

p.58Ainsi peut-on regrouper les clauses qui ont pour vocation d’assurer :

p.59Il s’agit ici du code source correspondant (3.1.2.2.a), de la documentation (3.1.2.2.b) et tout autre élément utile pour l’appréhension de la création (3.1.2.2.c).

p.60De nombreuses licences définissent la notion de code source comme la forme de la création préférée pour faire des modifications sur celle-ci.

p.61Les licences vont dorénavant plus loin et la GNU GPL requiert la « source correspondante » du logiciel fourni en exécutable, défini comme étant « tout le code source nécessaire pour générer, installer et (pour une création exécutable) exécuter le code objet et modifier la création, y compris les scripts pour contrôler ces activités ». Les bibliothèques systèmes et autres éléments habituellement disponibles dans un environnement de développement sont cependant exclus pour des raisons pratiques.

p.62Le plus simple est généralement que la source accompagne le binaire (ou soit disponible sur le même serveur). Or, ce n’est cependant pas toujours possible ou souhaité et d’autres alternatives sont généralement proposées : telle l’offre de fournir les sources correspondantes à la demande (mais avec d’autres problématiques comme le délai raisonnable de cette communication des sources).

p.75La documentation d’un code et d’un logiciel (ou d’une création utilitaire qui sera ou non amenée à évoluer) est une condition nécessaire à sa bonne prise en main. Deux types de documentation peuvent être distribués :

p.76Enfin, dans l’hypothèse où certains composants pourraient être certifiés (ou simplement qualifiés, selon le secteur industriel), la problématique d’une mutualisation des coûts engendrés par cette certification peut venir s’ajouter aux réflexions sur l’open source : le matériel de certification pourra ainsi être librement communiqué (afin de favoriser la diffusion et utilisation du logiciel) ou, au contraire, être réservé à un groupe de sociétés afin de mutualiser le coût au sein d’une communauté d’utilisateurs. Ces problématiques sont très fortes dans des secteurs tels l’aéronautique, l’aérospatiale, le ferrovière, l’automobile, etc.

p.77 Le courant des licences libres, malgré sa jeunesse et sa relative complexité, a rapidement donné naissance à un nouveau système. Ainsi, c’est l’organisation des acteurs privés qui doit être examinée (3.2.1) avant de se pencher sur l’organisation relative à la diffusion du logiciel sous licence libre (3.2.2).

p.78 Par leur organisation, les acteurs privés ont dessiné un nouveau système dont il convient de présenter les acteurs (3.2.1.1) et les interactions qui le caractérisent (3.2.1.2)³³.

p.79 Les licences libres ne sont que des outils. Le corollaire est que tous les types de personnes (physiques ou morales, privées ou publiques, de tout secteur ou métier) les utilisent, avec une pluralité de motivations, mais au profit de la constitution d’un « pot commun » qui les réunit (chacun étant libre d’y verser comme d’y puiser). Les individus, les associations et autres organismes à but non lucratif ont souvent un rapport au Libre complexe qui mêle philosophie, idéologie, et des arguments plus raisonnés comme le coût ou l’indépendance qu’offrent les solutions logicielles libres. Tandis que les entreprises, neutres par essence³⁴, ainsi que les collectivités et administration adoptent le Libre par opportunité et pragmatisme (les logiciels libres assurant, outre une maîtrise des coûts, les avantages d’une grande flexibilité et d’un développement rapide).

p.80Parmi tous les courants et même s’il n’est peut-être pas le plus connu du grand public (le mouvement de l’Open Data est par exemple « très vendeur »), le secteur le plus avancé et structuré est incontestablement celui du logiciel : 50 % des entreprises interrogées par Gartner³⁵. ont adopté les logiciels libres dans le cadre de leur stratégie informatique. Ainsi, l’industrie du logiciel libre devrait représenter 10 % du marché de demandes en logiciels et services français d’ici 2 ans³⁶ (renforçant ainsi la compétitivité de la France en matière de développement de logiciels).

p.81 Les développements qui suivent seront donc dédiés au système qui caractérise le logiciel libre. On s’aperçoit que les frontières entre les différents acteurs (éditeurs des logiciels, intégrateurs, constructeurs et utilisateurs) sont beaucoup moins étanches que dans le secteur traditionnel du logiciel : les éditeurs intègrent de plus en plus de composants open source dans leurs logiciels, les intégrateurs peuvent prendre le rôle d’éditeur vis-à-vis de leur client (support de niveau 3, développement de nouvelles fonctionnalités, etc.) et les utilisateurs eux-mêmes se réunissent en « une communauté d’utilisateurs éditrice³⁷ ». Néanmoins, si on distingue les entreprises simples utilisatrices de composants open source de celles qui orientent leur modèle économique en rapport avec cet usage, et qu’on se concentre sur ces dernières seulement, on peut distinguer différents rôles : éditeurs (3.2.1.1.a), intégrateurs (3.2.1.1.b), constructeurs (3.2.1.1.c), grands utilisateurs clients (3.2.1.1.d), fondations et communautés (3.2.1.1.e) et centres de recherche (3.2.1.1.f).

p.82 Il s’agit ici de l’entreprise distribuant sous licence libre un logiciel qu’elle édite. De multiples adoptions de l’open source coexistent dans le monde de l’édition : en fonction de l’éditeur (et de son histoire), du type de produit édité et de ses utilisateurs. Le choix n’est pas systématique, mais les éditeurs qui souhaitent construire un modèle économique innovant, voire disruptif, ont besoin de s’appuyer sur une communautés, préexistante ou nouvellement créée, qui va jouer le rôle de soutènement (renforçant le logiciel, se substituant parfois à la société, et constituant une réserve de clients voire de salariés pour la société). À partir de là, le modèle économique de la société est généralement issu d’un équilibre entre ce qui est cédé et le contrôle, plus ou moins fort, conservé par l’éditeur (par un droit exclusif, sur la feuille de route, etc.). Se concentrant sur les seules pratiques juridiques sans que la liste soit exhaustive, les principaux mécanismes (librement combinables) sont l’usage du droit des marques, la proposition de licence commerciale complémentaire, la mise à disposition décalée ou encore le contrat.

p.83Le plus souvent, les éditeurs assurent 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. Cette faculté qu’offre le cumul de droits exclusifs concurrents sur un même objet a ici l’avantage de rendre quasi inexistant le coût d’entrée pour les utilisateurs, tout en assurant à l’éditeur principal 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 logiciel³⁹ – tandis que les structures non commerciales en font un usage plus modéré, équilibré, qui a principalement pour objectif de défendre l’image associée au logiciel⁴⁰. Le risque inhérent à ce type d’utilisation du droit des marques est que l’éditeur, trop mercantile, se mette à dos la communauté qui s’émancipe alors en enlevant toute allusion à la marque du logiciel et en reprenant à son compte les logiciels diffusés sous licence open source⁴¹. Aux États-Unis, les brevets sont aussi utilisés comme un levier supplémentaire permettant de convaincre les investisseurs et les clients (Novell en étant le meilleur exemple). On observe le même phénomène en Europe, même si l’utilisation des brevets parallèlement à une licence libre reste heureusement un comportement isolé et très critiquable.

p.84Par ailleurs, il est fréquent que les éditeurs ne fassent pas le choix exclusif de l’open source et développent de façon périphérique des offres commerciales en associant à la version libre des add-ons ou plug-ins (greffon) sous licence commerciale⁴². Dans le même esprit, il est possible de proposer le même logiciel sous une licence commerciale présentée comme alternative à la licence open source⁴³ ou de proposer un service autour d’une version non encore distribuée du logiciel (à noter néanmoins que ces deux solutions sont conditionnées au fait que la société détienne tous les droits sur le logiciel⁴⁴ ou que les licences des composants open source utilisés n’interdisent pas de telles utilisations ou distributions fermées). Dans ce second cas, il est possible de penser à un modèle du type free cloud telle que l’offre Drupal Garden de la société Acquia : un ou plusieurs services fournis sur la plate-forme de l’éditeur (par exemple création et hébergement d’un site) s’harmonisent avec la distribution open source du logiciel puisque l’utilisateur peut à tout moment exporter le code et le contenu générés pour les installer sur sa propre instance. Dans ces hypothèses, mixer licences open source et commerciales⁴⁵ permet divers montages dans lesquels les communautés continuent à trouver leur intérêt à utiliser et collaborer au développement du logiciel grâce à la licence open source, tandis que les utilisateurs professionnels préfèrent à terme opter pour une licence commerciale⁴⁶.

p.85De façon assez similaire, certaines sociétés proposent des mises à jour plus simples et régulières à leurs clients (non immédiatement accessible aux utilisateurs de la version communautaire) : soit par une mise à disposition systématiquement décalée (de quelques mois ou quelques semaines) ; soit par une mise à disposition graduelle des mises à jour pour les clients (alors qu’elles seraient regroupées pour la version complémentaire). Ce décalage peut être matériel ou juridique (les mises à jour ne sont considérées comme divulguées qu’à compter d’une certaine période).

p.86 Enfin, certaines sociétés usent du droit des contrats afin de limiter accessoirement l’utilisateur dans les libertés que lui concède la licence open source : que ce soit lors de la vente de services aux utilisateurs qui souhaitent bénéficier du support et des mises à jour⁴⁷ ou dans les rapports entre distributeurs et revendeurs ⁴⁸. Les contrats sont aussi essentiels pour les logiciels orientés métiers demandant de concevoir plus finement la collaboration entre les différents industriels⁴⁹ : la licence open source n’étant alors plus qu’une partie du cadre contractuel (s’ils sont concurrents, une licence copyleft sera une condition sine qua non afin d’assurer une relative pérennité et équité dans le développement du logiciel) – un contrat de consortium complétant éventuellement tous les aspects non couverts par la licence (comité de direction, procédé de développement, prise en compte des orientations, marketing et communication, etc.)⁵⁰.

p.93De leur côté, les intégrateurs de logiciels libres et open source (ou de solutions partiellement composées de ceux-ci) subissent généralement plus les licences qu’ils ne les choisissent : leur seule préoccupation étant que les briques logicielles puissent aisément se combiner entre elles. Il n’y a donc pas d’usage du droit des marques à l’égard des produits, mais surtout une expertise approfondie des combinaisons de licences leur permettant de s’assurer de la faisabilité du projet et de s’engager sur ce point auprès de leurs clients et dans leurs contrats (les clients demandant aujourd’hui la garantie de telle compétence ainsi que la livraison de certaines études précises sur ces questions). Transférant généralement un logiciel qu’il n’a pas (à priori) lui-même développé, mais seulement adapté au besoin de son client, l’intégrateur est lui-même limité par sa qualité de licencié à l’égard des auteurs des logiciels libres sur lesquels il intervient, et, ne pouvant céder plus de droits qu’il n’en possède lui-même, il communiquera à ses clients cesdits logiciels sous leur licence open source d’origine (ou toute autre licence compatible).

p.94 En ce qui concerne leurs contributions spécifiques, les pratiques sont multiples, mais il semblerait finalement que le plus avantageux pour l’ensemble des parties soit que la titularité des droits soit conservée par celui qui maintient et édite le logiciel (généralement l’intégrateur). Ainsi celui-ci cède l’ensemble de ses développements sous licence libre au client et conserve la titularité des droits. Ce compromis reste fidèle au procédé de création open source dans lequel l’auteur reste titulaire de droits et cède sous licence open source de façon non exclusive, afin de permettre tant au client de mutualiser les résultats de la prestation, qu’à l’intégrateur de valoriser les travaux par tous moyens appropriés⁵⁴.

p.95 Concourant à la création d’une industrie réunissant innovations matérielles et logicielles, les constructeurs (tels HP, Intel, IBM ou Dell) embarquent de plus en plus de logiciels et se rapprochent à ce titre des différents projets de logiciels libres (et l’open cloud) – devenant de jour en jour des contributeurs majeurs dans les projets OS (Linux, Busybox, etc.) au point de faire de leurs contributions respectives des éléments différenciant.

p.96 En effet, de tels logiciels permettent, en plus d’écorner certains monopoles, de réduire le coût de développement, d’optimiser l’interaction entre les logiciels et leurs matériels (ou a minima d’assurer la compatibilité avec leur produit).

p.97 À l’instar des intégrateurs, les constructeurs sont généralement désireux d’une compatibilité maximum entre les licences des logiciels open source utilisés, même s’ils peuvent avoir intérêt à définir certaines politiques : favorables à certaines licences permissives (par exemple dans le secteur du mobile, avec la diffusion d’Android sous licence Apache) ; ou exemptes de certaines obligations (par exemple, de licences de brevets) qui seraient incompatibles avec leur politique plus vaste relative à la propriété intellectuelle.

p.98De nombreux secteurs sont concernés par une certification (ou qualification, cf. supra) de leur produit : l’open source est pour eux une solution qui permet de mutualiser les frais de développement tout en conservant le bénéfice personnel de la certification de leur version.

p.99 Contrairement aux logiciels traditionnels, les logiciels libres sont généralement accessibles à toutes catégories d’utilisateurs, dans les mêmes conditions. Ainsi, libre à chacun (individu, société, organisme à but non lucratif, collectivité ou État) de s’installer un forum (Phpbb), un wiki (Mediawiki), voire un Facebook-like (Elgg) ou un Youtube-like (Mediacore), etc.

p.100Les utilisateurs d’un projet open source sont particulièrement sensibles à la licence du projet : l’impact de cette dernière étant fonction de l’utilisation qu’ils en font (par exemple, si des services sont proposés sur la base de ces logiciels libres) voire de leur forme (société, GIE, association, etc.).

p.101 Lorsqu’il s’agit de sociétés « utilisatrices poussées », elles peuvent faire appel à des intégrateurs ou consultants pour mettre en place les solutions open source dans leur SI – ce qui les place dans une situation analogue aux utilisateurs standards, avec quelques spécificités relatives aux contrats passés avec ces prestataires. En l’absence de tels intermédiaires, il est aussi possible de se tourner vers des solutions d’assurance (telle l’offre américaine Open Source Risk Management proposée par la société OSRM).

p.102 Néanmoins, l’impact de l’utilisation des logiciels libres peut être lié à des politiques stratégique ou économique particulières : par exemple en cas d’externalisation quasi totale du support, maintenance, veille open source à partir d’un SI essentiellement composé de logiciels libres, ou, au contraire, lors de la mise en place d’une entité informatique interne qui gère le déploiement de solutions en logiciels libres au sein de toute la structure (avec une vraie logique de service et d’édition). Dans toutes ces situations, les utilisateurs veillent à ce que les développements réalisés pour leur compte soient ensuite mis à disposition du (et si possible intégrés dans) projet open source – gardant à l’esprit qu’il est généralement aussi cher de maintenir un composant logiciel dans la durée que de le faire développer.

p.103En plus des acteurs précédents, on retrouve plusieurs types de groupements sur lesquels s’appuient les projets libres et open source : ils sont commerciaux (tels les sociétés ou GIE) ou non (associations ou fondations), avec une personnalité morale ou non (association de fait – fréquent lors du lancement d’un projet – ou consortium), voire multiples (tel OpenOffice.org qui reposait sur l’association TeamEV, mais dont les droits de PI étaient gérés par Sun puis Oracle).

p.104 Les fondations et autres organisations à but non lucratif occupent une place prépondérante dans le système du Libre. Elles peuvent être classées en deux catégories⁵⁵ : celles qui concourent directement au développement d’un logiciel et celles qui y concourent indirectement.

p.105 Les premières sont productrices de code, de créations (qu’elles soient ou non titulaires de droits) :

p.106 Les secondes concourent indirectement au développement de projets (ne produisent pas de code per se) :

p.107L’implication et l’utilisation des logiciels libres par les centres de recherche sont si importantes qu’il est impossible de ne pas considérer les centres de recherches⁵⁶ (et, dans une moindre mesure les universités⁵⁷) comme des acteurs à part entière du système que nous décrivons (notamment pour au regard de leur recherche à application industrielle).

p.108Leur apport est néanmoins limité aux domaines directement liés à leur activité de recherche et ils ne prennent ainsi qu’un rôle passif dans l’animation des communautés ou la proposition de services. Ainsi, et même si la situation semble évoluer, on s’aperçoit que leur action se limite aujourd’hui au stade qui précède la valorisation de leurs projets Open Source : cette dernière phase étant réalisée par des sociétés existantes, partenaires ou non, ou nouvellement créées (le transfert en faveur de spin off se multiplie).

p.109 Enfin, il est fréquent que l’intégrateur soit tenu de contribuer aux projets open source en fournissant les modifications réalisées pour le client : il s’agit là d’une sécurité tant pour le client qui s’assure ainsi que les versions ultérieures du projet intégreront ces développements (et qu’il n’aura ainsi pas à le payer une seconde fois) que pour l’intégrateur qui ne souhaite généralement pas endosser la responsabilité d’un éditeur.

p.110 Chaque relation mérite néanmoins un examen dédié : entre un projet et ses utilisateurs (3.2.1.2.a), entre un projet et ses contributeurs (3.2.1.2.b), entre le projet et les autres groupements (3.2.1.2.c) et entre les sociétés (3.2.1.2.d).

p.111 Les utilisateurs sont les premiers destinataires des logiciels. Ils contribuent généralement en livrant des retours sur leur expérience. Ils sont aussi souvent les premiers générateurs de valeur, le nombre d’utilisateurs d’un logiciel étant généralement un facteur multipliant la valeur du logiciel vis-à-vis de ceux qui ne l’utilisent pas encore. La licence utilisée sur l’œuvre logicielle est souvent le seul document les intéressant et, au sein de ce dernier, seuls les droits d’utilisation les concernent véritablement. Dans le cadre de certains projets, il arrive que des limitations s’ajoutent, en raison, par exemple, de composants commerciaux : l’utilisateur y consentira alors lors du téléchargement, de l’exécution ou de l’installation du logiciel.

p.112 Ces utilisateurs peuvent néanmoins devenir clients, contributeurs et/ou partenaires potentiels, voire concurrents du projet, et il est toujours utile de prévoir à leur attention des documents les informant de leurs droits et devoirs au terme de la licence, des conditions d’utilisation des marques, logos et noms du projet, voire, s’il y a lieu, du processus leur permettant de contribuer au projet (ainsi que la politique du projet en matière de propriété intellectuelle).

p.114Les caractères évolutifs et participatifs étant l’essence même du logiciel libre, il n’est pas exclu que certains contributeurs souhaitent apporter leur lot de développements (envisagés sur un mode projet, en constante amélioration).

p.115Dans la situation d’un éditeur (ou la communauté qui revêt ce rôle) déjà identifié sur le projet, il peut proposer plusieurs schémas de contribution qui conditionneront la reprise du code au sein du projet :

p.116Dès les premières contributions au projet, il devient nécessaire d’avoir une réflexion pointue sur la gestion de la propriété intellectuelle, donnant éventuellement naissance à une politique en la matière, que celle-ci soit très protectionniste ou au contraire très ouverte.

p.117La question de la détention des droits de propriété intellectuelle, de la « titularité », est d’une importance variable dans un projet open source. En fonction de la licence (surtout si cette dernière est copyleft) et du type de projets, la détention peut être cruciale en ce qu’elle confère un certain contrôle sur le projet (par exemple pour toutes les sociétés qui pratiquent les doubles licences, dit dual licensing). Cette détention peut au contraire être très faible lorsque la licence choisie est très ouverte, lorsque le projet est soumis aux licences de composants open source qu’il intègre, ou encore lorsque trop de contributeurs se partagent cette titularité.

p.118Pour remédier à cette division de la propriété, de nombreux projets recourent à des politiques de licences spécifiques, de cession de droits ou de « copropriété libre » (chaque copropriétaire pouvant exploiter librement les droits détenus) : par le biais de Contributor License Agreements, Copyright Assignment ou de Joint Copyright qui conditionnent généralement la possibilité pour un développeur de voir sa contribution être acceptée dans un projet ou, dans le cadre professionnel, pour un client qui souhaite que ses développements soient maintenus par le projet. C’est une politique que l’on retrouve à l’égard des salariés d’une société – qui sont aujourd’hui les principaux contributeurs, sur tout type de contenu⁵⁸.

p.119Inversement, afin de se prémunir face à un éventuel contrôle sur un logiciel libre du fait de la détention des droits par un ou plusieurs, certains peuvent chercher à bloquer l’exercice de ces prérogatives en imposant une convention de copropriété (ou d’indivision) qui lie les parties quant à l’exploitation conformément à la licence open source du projet⁵⁹.

p.120Il est ainsi fréquent que le nombre de contributeurs (et donc de titulaires de droits) dépasse la dizaine voire le millier. Leur anonymat ainsi que leur dispersion géographique sont parfois des obstacles infranchissables pour la suite du projet : l’absence de consentement d’un seul interdit toute décision concernant la création dans son ensemble et la seule échappatoire reste alors de supprimer les contributions pour lesquelles il manque cette autorisation.

p.121C’est pour cette raison que, très tôt, certains développeurs ou organismes, telle la FSF, ont mis en place des documents qui permettent aux contributeurs d’un projet soit de leur céder leur copyright – pour centraliser la prise de décision (notamment le changement de licence⁶⁰), la gestion, et la défense de l’œuvre – soit de leur consentir une licence très large. On parle de Copyright Assignement en présence d’un vrai transfert (cession exclusive) de droits, la structure devenant la seule et unique titulaire de droit. On parle de Contributor License Agreement lorsque le contrat opère une cession (non exclusive) très large au profit de la structure sans que le contributeur soit lui-même dessaisi de ses prérogatives. Ils sont généralement doublés d’un second document à destination des employeurs lorsque les contributions sont réalisées dans un cadre salarial. Chacun de ces contrats est rédigé en fonction de l’équilibre particulier du projet, de l’implication des contributeurs dans celui-ci et de la confiance dont bénéficie l’organisme collecteur.

p.122 Devant le constat de la multiplicité, de la diversité et de la complexité de ces documents, de nombreux industriels, professionnels et associations du libre ont formé un groupe de travail pour plancher sur la rédaction de documents types à destination des communautés et entreprises : leur épargnant un travail d’écriture en même temps qu’ils épargnent à leurs utilisateurs-contributeurs un travail de lecture (et de compréhension). Le projet Harmony, s’il permet de mutualiser les politiques auparavant éclatées⁶¹, ne résout néanmoins pas la difficulté du rapport que cela génère entre les parties, les uns voulant un engagement fort des contributeurs – notamment par le biais de clauses de responsabilité et de garantie –, les autres voulant un engagement fort des collecteurs – notamment quant à l’exploitation des contributions.

p.123Par ailleurs, ces contrats ne sont réellement fiables qu’en cas de certitude quant à l’identification du contributeur. C’est la raison pour laquelle la Free Software Foundation (mais Mozilla aussi) envoie un contrat papier qu’il convient de retourner signé. De même, l’Eclipse Foundation à mis en place un processus complet visant à sécuriser les relations entre les différents acteurs (Eclipse Legal Process).

p.124Il est très fréquent que les différents projets ou organisations se réunissent pour travailler de concert sur des projets communs : soit qu’ils aient des compétences ou expériences complémentaires, transverses (tels les aspects juridiques liés aux licences et aux brevets), soit qu’ils mettent en commun leurs forces pour le développement d’une solution plus vaste.

p.125 Une société éditrice de logiciels qui met en place son modèle commercial prend généralement en considération ses partenaires, ses concurrents et ses clients. Il est assez simple de séparer les uns des autres : la société est liée par contrat avec ses partenaires (distributeurs, revendeurs, etc.) et ses clients (contrats souvent négociés pour les premiers et imposés pour les seconds), et n’entretient que des relations contractuelles exceptionnelles avec ses concurrents.

p.126 Les licences libres modifient cet ordre puisqu’elles s’adressent autant aux individus – personnes physiques – qu’aux entreprises commerciales. Ainsi, les concurrents comme les partenaires pourront en revendiquer le bénéfice, leur permettant notamment d’utiliser ou de proposer des services autour des logiciels édités par un autre avec pour seule limite le respect de la licence libre du projet et éventuellement de la politique de marque.

p.127 On peut y voir un paradoxe puisque les partenaires risquent d’être « moins libres » que les concurrents, du fait de clauses supprimant le bénéfice de la licence, qui peuvent être comprises dans leurs engagements avec l’éditeur⁶².

p.128 On parle de fork lorsqu’une partie d’une communauté décide de s’éloigner du projet principal pour en développer une version différente. De manière générale, les forks préjudicient à tous : l’ancienne et la nouvelle communautés, les utilisateurs et les projets.

p.129 C’est la raison pour laquelle il est généralement conseillé d’augmenter l’investissement dans un projet plutôt que d’initier son propre projet⁶³.

p.133L’organisation de la diffusion est souvent la clé qui assure la pérennité d’un projet, sa stagnation ou son abandon. Malheureusement, il n’y a pas une organisation idéale, une structure parfaite, mais uniquement des cas d’espèce. Pour une entreprise, cela implique de se reposer sur un ensemble hétérogène de personnes au sein de l’entreprise qui perçoivent les enjeux de l’open source et qui s’assure du respect des licences.

p.134Ainsi, que ce soit pour ce seul projet ou pour une multitude, il est nécessaire d’entamer une telle réflexion et, une fois les besoins identifiés, d’organiser l’accompagnement – que ce soit en interne ou en externe⁶⁴.

p.135La mise en place d’une bonne gestion des licences libres passe nécessairement par une étude des enjeux pour la société et/ou le projet (3.2.2.1.a), la définition des besoins (3.2.2.1.b) et l’organisation de l’accompagnement (3.2.2.1.c).

p.136Quelles sont les sanctions juridiques, mais aussi commerciales ou marketing, susceptibles de découler du non-respect des licences libres ? De nombreuses sociétés, pourtant importantes, ont ainsi dû baisser l’échine face aux actions des communautés qui leur reprochaient l’absence de prise en compte des licences sur des composants utilisés (ce qui inclut BestBuy, Westinghouse et Cisco). Ajoutons que les titulaires de droits, généralement seuls aptes à faire respecter leur licence, ont tendance à les accompagner l’utilisation de leur logiciel open source).

p.137En effet, tout non-respect de licence emporte le risque de se voir qualifier de contrefacteur : tout usage n’entrant pas dans le cadre de la licence est un usage non autorisé et donc contrefaisant. Par ailleurs, en cas de violation, par certains usages de droits de propriété intellectuelle, ou plus fréquemment, du non-respect du formalisme de la licence, celle-ci sera généralement automatiquement résiliée et l’ancien licencié se trouvera rapidement contrefacteur pour tout usage de la création. Cela vaut pour l’entreprise mais aussi pour ses clients et partenaires qui redistribuent les logiciels« non conformes » (on perçoit d’ailleurs une telle prise de conscience en Asie).

p.138Au minimum (mais ce n’est pas toujours vrai), il est possible de considérer que lors de l’utilisation d’un composant open source sans modification, la simple redistribution (tel qu’il a été reçu) devrait suffire. Au contraire, une démarche plus lourde serait nécessaire en cas de modification. La solution la plus fiable est néanmoins de mettre en place un formalisme générique, construit sur le modèle de la licence la plus contraignante, de manière à ce que son respect suffise pour remplir les attentes classiques de l’ensemble des licences. Enfin, des procédures particulières peuvent être élaborées afin de prendre en compte les spécificités des utilisateurs (professionnels du métier ou non, de nationalité précise, etc.) ou du domaine d’exploitation (embarqué, SaaS, etc.).

p.139En fonction des enjeux, plusieurs besoins peuvent être identifiés :

p.140À ce stade, il s’agit de définir quelles sont les tâches qui peuvent être externalisées et quelles sont celles qui doivent être conservées en interne.

p.141Une externalisation totale semble difficile en raison de l’interpénétration des notions juridiques et techniques d’une part, et de la criticité de ces enjeux d’autre part. Tout au plus est-il possible de penser à l’intervention de tiers quant à l’audit initial (en cas de solution préexistante), à l’édiction d’une gouvernance, voire en préalable à toute distribution – pour le reste, une personne, voire une équipe interne, doit être référente afin de résoudre (ou transmettre à cette fin) les difficultés qui se présentent à elle et « infuser » les bonnes pratiques. Une solution intermédiaire pourrait être de rejoindre une structure plus grande (comme une fondation) qui permette de mutualiser une partie de la fonction.

p.142L’internalisation elle-même peut prendre différentes formes, qu’il s’agisse de créer une entité ad hoc (référent open source, comité open source, etc.) ou de modifier les structures existantes pour y intégrer ces besoins, notamment par l’intégration de règles générales, comme la définition de politique en matière de licences, la validation de paquets logiciels, etc.. De nombreux paramètres entrent dans cette équation, mais il est généralement conseillé, lorsque la taille le permet, de commencer par la mise en place d’entités autonomes, de sorte qu’elles s’éclipsent une fois la nouvelle culture infusée et les réflexes intégrés – au risque sinon de buter sur la résistance des collaborateurs (surtout dans le cas du passage d’une politique de licence traditionnelle à une politique ouverte : la longue domination du paradigme antérieur, engendrant de nombreux réflexes et habitudes profondément ancrées, peut entraîner le rejet irrationnel de ce mode alternatif d’édition).

p.143Quelle que soit l’organisation choisie, il est nécessaire que cet accompagnement s’appuie sur des relais locaux (scouts), des correspondants aptes à faire remonter et redescendre les informations utiles.

p.144À la fois structure de référence et structure inter-services, un tel organisme permet de mutualiser le travail d’accompagnement, de rationaliser les décisions, de définir des politiques globales et d’automatiser le traitement des questions. Par ailleurs, pour qu’une telle structure puisse être suivie d’effet, il est nécessaire qu’elle soit facilement joignable, qu’elle bénéficie d’un pouvoir décisionnel et, dans l’idéal, qu’elle soit suivie par un membre de la direction. Enfin, elle seule doit être consultée pour autoriser et décider de l’utilisation de briques logicielles sous licences libres et open source et de la diffusion sous de telles licences (quitte à ce que ses décisions soient avalisées par la direction).

p.145 Comme nous l’avons vu, les licences s’étendent graduellement à l’ensemble des droits de propriété intellectuelle. Une vigilance accrue s’observe donc chez les sociétés qui mixent une culture libre (open source) et propriétaire : l’enjeu est alors de délimiter très précisément (généralement par des politiques open source très soignées), voire de cloisonner, les portefeuilles de droits relatifs au projet afin de s’assurer que l’activité open source ne vienne pas impacter et dévaloriser certains droits de propriété intellectuelle qui restent très attractifs pour la société.

p.146 C’est ce type d’attention qui explique par exemple la renonciation au bénéfice de la dévolution légale de droits relative à certains développements qui doivent être reversés à des projets placés sous des licences trop contraignantes (au profit des salariés qui conservent ainsi leurs droits)⁶⁷. De la même façon, une responsabilité particulière pèse sur les services juridiques qui doivent s’assurer que les engagements contractuels avec les sous-traitants, fournisseurs, etc. soient bien respectés et maintenus lors de la diffusion sous licence libre et open source.

p.147 Pour une société, il arrive parfois qu’il soit plus simple, voire nécessaire, d’envisager un cession de droits au profit de projets qui assureront le maintient et l’intégration des différentes contributions. Dans cette solution, tant l’entreprise que le salarié seront généralement signataires d’un document de cession de droits au profit du projet. Il peut aussi être envisagé, lorsque la mission du salarié l’exige ou en raison du contrat particulier qui le lie à la société, que celle-ci lui délègue le pouvoir de mettre sous licences libres les contributions réalisées dans le cadre de ses missions salariales : le risque est faible pour l’entreprise lorsque celui-ci travaille dans un tel environnement, et cela lui permettra de sécuriser les contributions de son salarié vis-à-vis des communautés et des projets dans lesquels il intervient.

p.148De façon pragmatique, lorsque l’on exploite du contenu sous licence libre en entreprise ou ailleurs, il est nécessaire d’adapter la procédure de validation juridique et contractuelle, l’analyse devant être réalisée autant en amont des projets qu’en aval. Un travail est nécessaire dès en amont afin de déterminer la faisabilité juridique des propositions techniques et s’assurer que les engagements puissent être respectés (en gardant en tête le leitmotiv : « on ne peut donner plus de droits que l’on en possède », c’est d’ailleurs cette seule idée qui ressort des contentieux français ayant mis en jeu la GNU GPL). Enfin, une dernière étude juridique est nécessaire en aval pour confirmer le choix final de la licence et procéder, s’il y a lieu, aux ajustements contractuels en fonction du produit, des attentes et bien évidemment des licences en présence.

p.149Ainsi, ce travail ne peut être mené que conjointement entre l’équipe technique, seule apte à fournir les informations détaillées sur le logiciel, et l’équipe juridique. Les données brutes nécessaires à l’étude juridique sont : le détail des briques logicielles utilisées, leur(s) licence(s) respective(s) (comprenant leur version, et toute autre information influant sur ces licences : restriction, interprétation, exception, etc.), et enfin les interactions existantes entre chacune de ces briques (en pratique, un schéma). Un dialogue s’établit par la suite pour affiner les derniers détails, et de nombreuses navettes permettront de compléter l’analyse.

p.150D’une manière plus générale, le succès d’une politique active en faveur de l’open source repose sur une implication de l’ensemble des collaborateurs dans le processus de restructuration et une montée des compétences de ces derniers afin qu’ils comprennent et partagent ce nouveau paradigme : par l’organisation de formations, la rédaction et la mise à disposition des informations qui leurs sont utiles, l’organisation de leurs contributions au sein de chartes (contribution, développements, processus de validation, etc.).

p.151 Enfin, l’usage de certaines solutions logicielles peut simplifier, voire approfondir⁶⁸ cette mission, en automatisant l’audit de code⁶⁹ voire la gestion au quotidien de la base de code validée. Tous les outils ne sont pas équivalents, et tous n’ont pas vocation à être utilisés au même moment ou par les mêmes personnes (dans le cadre de due diligence, les audits demanderont ponctuellement l’utilisation d’outils très poussés, alors que la vérification automatique et journalière des développements réalisés pourra être plus superficielle).

p.152Enfin, le projet Software Package Data Exchange⁷⁰ (SPDX) a récemment introduit un format standard pour communiquer les éléments, les licences et droits d’auteur associés à un logiciel (et ainsi faciliter la prise de connaissance des obligations et le respect des licences). Ainsi, chaque société ayant réalisé ce travail d’audit pourra dorénavant accompagner la livraison de son logiciel d’un fichier SPDX qui recensera tous les composants utilisés et leur(s) licence(s).

p.153Comme vu précédemment, différents documents peuvent être mis en place pour accompagner l’organisation vis-à-vis des tiers et notamment pour donner un cadre formel à la collaboration (3.2.2.2.a), et la rédaction d’une politique en matière de marque précise à l’intention des tiers et des licenciés (3.2.2.2.b).

p.154Que le projet soit ouvert ou fermé, la mise en place d’un cadre propice à son développement et son exploitation nécessite une réflexion quant à l’organisation du groupement autour du projet et vis-à-vis des tiers.

p.155Tant que l’organisation du projet est suffisamment attractive pour motiver des contributions extérieures et qu’il répond aux contraintes des mainteneurs, il n’y a aucune raison de changer celle-ci.

p.156Si le projet souhaite s’ouvrir de manière à impliquer plus de contributeurs, plusieurs schémas peuvent être construits pour organiser les développements collaboratifs, avec leurs avantages et inconvénients (création d’une entité juridique distincte, mise en place d’un consortium, l’appui d’un partenaire leader – voire une absence délibérée). Notons que la mise en place d’un consortium est la solution la plus légère (généralement la première utilisée par les sociétés qui cherchent à collaborer en raison de la faiblesse de l’engagement), éventuel premier jalon d’une autonomisation quasi-systématique des projets dès lors qu’ils gagnent en contributeurs.

p.157Dans l’hypothèse de la libération d’un projet, il est préférable de structurer un minimum dès le début (donner simplement l’accès au code et le processus pour contribuer) quitte à mettre ensuite en place une organisation adaptée.

p.158 Enfin, la gouvernance des groupements est généralement découpée entre les aspects stratégiques, les aspects techniques et les aspects communication/sensibilisation (lien avec les utilisateurs et la communauté).

p.159Le droit des marques retrouve toute sa noblesse dans l’industrie de l’open source, puisqu’il reste bien souvent le meilleur garde-fou pour empêcher certains types d’exploitation d’un projet qui est pourtant librement disponible (notamment en termes d’image, mais aussi de comportement commercial). Néanmoins, il est parfois nécessaire de relativiser l’usage qui peut en être fait au regard des prérogatives qu’il confère à son titulaire, car la tentation est grande pour certains d’essayer de récupérer là un contrôle qu’ils ont abandonné en faisant le choix de l’open source.

p.160Ainsi, les politiques en matière de marque sont généralement des documents publics qui précisent quelles sont les marques détenues par le projet et les conditions de leur utilisation : une seule marque pouvant être utilisée différemment selon le contexte (lorsque la création est modifiée ou non) ou plusieurs marques pouvant être utilisées pour différencier les usages permis sur chacune (par exemple en autorisant seulement les partenaires à utiliser la marque figurative).

p.161Les meilleurs exemples existants, à cet égard, sont ceux des projets du type OpenOffice.org, LibreOffice, Firefox, Linux, etc. qui réunissent à la fois entreprises, associations et fondations, contributeurs individuels et grand public.