Épisode 16 : Bonnes pratiques pour l’utilisation des logiciels libres

Maya Urbanowicz: Vous écoutez Voix de la PI canadienne, un balado où nous discutons de propriété intellectuelle avec des professionnels et des intervenants du Canada et d'ailleurs. Vous êtes entrepreneur, artiste, inventeur ou simplement curieux ? Vous allez découvrir des problèmes concrets et des solutions concrètes ayant trait au fonctionnement des marques de commerce, des brevets, du droit d'auteur, des dessins industriels et des secrets commerciaux dans la vie de tous les jours. Je m'appelle Maya Urbanowicz et je suis votre animatrice d'aujourd'hui.

Les points de vue et les opinions exprimés dans les balados sur ce site web sont ceux des balados diffuseurs et ne reflètent pas nécessairement la politique ou la position officielle de l'OPIC. Si vous considérez un logiciel libre pour votre prochain projet de codage, alors cet épisode est pour vous. Les logiciels libres, aussi connus en anglais comme étant open source, peuvent être un excellent outil pour accroitre votre production de codage et peuvent même être utilisés comme un moyen pour faire de l'argent, mais cela vient avec un ensemble de critères et une licence et vous devez être conscient des deux, puisqu'ils vont déterminer exactement ce qui va arriver avec ce que vous faites avec le logiciel libre.

Parce que même si le code est le vôtre, sous les droits d'auteurs, vous devez possiblement le partager sans frais, sans aucune limitation. Dans cet épisode qui sera un peu plus long que d'habitude, Jules Gaudin, avocat et expert en PI au cabinet Robic à Montréal, expliquera ce qu'on entend exactement par logiciel libre et certaines des considérations clés, embûches et meilleures pratiques pour les utilisateurs, ainsi que les fournisseurs de logiciels libres. Jules, c'est un grand plaisir de vous avoir dans notre balado aujourd'hui, bienvenu.

Jules Gaudin: Merci beaucoup de m'accueillir.

Maya: Il y a beaucoup à apprendre dans ce domaine, mais avant de commencer, pouvez-vous nous parler un peu de vous et du style de travail que vous faites dans le domaine des distributions libres ou open source.

Jules: Bien sûr. Comme vous l'avez mentionné, je suis avocat en propriété intellectuelle et droit des technologies, des sujets vastes où j'ai l'occasion d'assister des clients un peu sur tout ce qui concerne la technologie, que ce soit de la réglementation, du licensing ou ce genre de questions. À ce titre, vu que j'ai quand-même un petit peu d'expérience dans le domaine, j'assiste aussi beaucoup sur tout ce qui est relatif au logiciel libre et ouvert, l'open source. Ça va notamment aider à la création de politiques et de documents internes, pour s'assurer qu'on a eu des bonnes pratiques en lien avec l'open source. Aussi, l'examen des différents éléments open source qu'on utilise dans des solutions propriétaires et les effets des licences qui y sont associées, pour s'assurer que tout est correct et bien respecté.

Des fois, c'est simplement venir présenter et soulever le sujet et les questions qu'il faudrait se poser lorsqu'on veut commencer à utiliser de l'open source ou que l'on veut commencer à distribuer des solutions commerciales avec de l'open source.

Maya: Vous parlez de licences et de distribution libre. Je crois que tout commence à s'éclaircir, que nous parlons de distribution libre comme un outil d'affaire et d'un produit. Pouvez-vous nous expliquer ce qu'est exactement le domaine des distributions libres ?

Jules: Oui, bien sûr. Plutôt que d'avoir une définition statique de ce qu'est l'open source, je préfère en général qu'on s'appuie sur la liste de critères qui a été mise en place par l'Open Source Initiative. C'est des critères qui nous donnent un peu les indices sur ce que serait une licence open source, une licence de distribution libre. Le premier critère, puis peut-être le plus important et celui qui a tendance à intéresser les gens, c'est la libre distribution.

Une telle licence, elle doit s'assurer qu'il n'y ait aucune restriction pour vendre, redonner le logiciel en tant que composant d'un logiciel plus global ou à titre de logiciel pour lui-même. On ne doit pas exiger que la personne qui est en train de redistribuer le logiciel qu'on a ainsi licencié, elle soit obligée de fournir des redevances ou d'autres frais pour une telle vente. Il faut aussi qu'on s'oblige à inclure le code source du logiciel qu'on a ainsi licencié. Ça doit permettre de s'assurer d'avoir une distribution qui est la plus complète possible.

Si jamais on ne distribue pas directement le logiciel ou l'élément concerné sous un format code source, c'est en général recommandé de s'assurer d'avoir un moyen publicisé d'obtenir le code source, que ce soit à travers un formulaire, que ce soit à travers d'un lien de téléchargement. Ensuite, le troisième critère, c'est de s'assurer qu'on puisse autoriser les modifications et les œuvres dérivées sur l'élément qu'on a ainsi licencié. C'est-à-dire que la personne qui télécharge le logiciel open source doit pouvoir le modifier et redistribuer cette version modifiée selon les termes de la licence originale, on en discutera un peu après.

Le quatrième critère, c'est de s'assurer de maintenir l'intégrité du code source qui est proposé par les auteurs. Des fois, c'est possible de venir restreindre la distribution du code source sous une forme modifiée uniquement, notamment pour s'assurer qu'il y a une version officielle du logiciel et que toutes les versions subséquentes qui soient des versions modifiées, soient des versions homebrew, qui auront un nom spécifique, mais l'idée, c'est qu'on veut s'assurer que les auteurs soient reconnus pour le travail qu'ils ont fourni et qu'on respecte un peu les limites qu'ils mettent en place à propos de l'utilisation du code source.

Ensuite, on a des concepts, je dirais plus philosophiques en matière d'open source. Il faut s'assurer qu'il n'y ait pas de discrimination contre des personnes ou des groupes. On ne doit pas dire, certaines personnes ne peuvent pas utiliser mon logiciel ou mon élément. Tout le monde doit pouvoir l'utiliser, y accéder et le modifier comme il le souhaite. De la même manière, il ne faut pas qu'il y ait de discrimination contre un domaine d'activité.

On ne doit pas empêcher quelqu'un d'utiliser le programme dans un domaine spécifique. Ainsi, par exemple, je propose une intelligence artificielle qui reconnait des images, je ne peux pas si je veux utiliser une licence open source selon les critères de l'OSI, je ne peux pas commencer à dire que vous ne pouvez pas l'utiliser dans un réseau social, par exemple. Il faut aussi qu'on vienne déterminer le droit attaché aux logiciels quand il est redistribué. Est-ce qu'on redistribue sous cette même licence, comme on le disait ? Est-ce qu'on a la possibilité de le redistribuer sous une autre licence, même une licence propriétaire ?

Dans tous les cas, il faut s'assurer en général que les gens n'aient pas à signer trop de documents de licences nécessaires. Il faut que la licence ne soit aussi pas spécifique à un produit. Il ne faut pas que l'utilisation du logiciel dépende de l'appartenance de l'élément à une distribution un peu plus globale et particulière. La licence ne doit pas restreindre d'autres logiciels. On ne doit pas imposer des restrictions sur d'autres logiciels qui seraient distribués en même temps que cet élément sous licence open source, par exemple, pour forcer que tous les logiciels distribués ensemble soient sous cette même licence open source.

Enfin, et ça, c'est peut-être plus lointain aujourd'hui, même si on commence à voir apparaître la question, il faut s'assurer que la licence, elle soit neutre sur le plan technologique. Il ne faut pas qu'elle vienne à l'encontre d'une technologie spécifique ou d'une interface, par exemple, empêcher toujours une discrimination contre un domaine d'activité ou contre une utilisation quelconque. C'est un peu les critères qu'on voit apparaître. Bien sûr, pour les gens qui sont peut-être plus familiers, il y a tout de suite des licences qui, avec ces critères-là, ne sont pas de l'open source, mais c'est un peu les éléments d'indices pour essayer de déterminer le champ d'action de la distribution de logiciels libres et ouverts.

Maya: Ce n'est pas aussi simple qu'on le pense, mais en même temps, nous savons que les logiciels libres sont quand même utilisés dans un contexte commercial. Est-ce que les créateurs de logiciels libres peuvent vraiment faire de l'argent avec leur logiciel ?

Jules: C'est tout à fait possible de faire de l'argent, de faire des revenus avec un logiciel libre. On a plusieurs options. D'abord, ce qu'il faut bien noter, c'est qu'en général, les licences open source, elles n'empêchent pas de vendre un logiciel libre. C'est tout à fait possible de demander un montant pour accéder à un logiciel libre. Par contre, ce qui se passe, c'est que pour que la licence soit vraiment une licence open source, il faudra proposer le code source du logiciel, laisser les utilisateurs venir modifier le logiciel et aussi venir le redistribuer, que ce soit tel quel ou modifié.

De manière générale, ça ne paraît pas être la manière la plus efficace de faire du profit avec l'open source. Si on se tourne vers d'autres exemples, on peut prendre, par exemple, des sociétés qui sont très rentables, comme Red Hat ou Oracle, dont toutes les solutions reposent un peu sur l'offre de solutions en open source. En fait, plutôt que de vendre les logiciels eux-mêmes ou les solutions technologiques qu'ils proposent, ils vendent tout ce qui est les services liés aux solutions qui seraient autrement disponibles gratuitement.

Que ce soit des services de support, des services de formation, c'est aussi possible de payer pour obtenir des plugins ou des fonctionnalités qui seraient spécifiques à votre société ou à vos besoins. De la même manière alternative. Maintenant, ce qu'on voit de plus en plus apparaître en matière de logiciels open source, c'est d'offrir la solution par le biais d'un SaaS, donc, d'un software as a Service. Les logiciels à travers une solution où cette fois-ci, c'est le logiciel en tant que tel qui est distribué sous une licence open source.

Il peut être utilisé par n'importe qui pour mettre en place sa propre plate-forme SaaS, mais si vous êtes suffisamment important, en général, les utilisateurs préféreront plutôt s'appuyer sur vous qui avez créé cette solution que vous distribuez gratuitement, pour s'assurer que quand ils vont y accéder, quand ils vont pouvoir l'utiliser, elle repose sur une expertise et une bonne gestion technique et de support, pour s'assurer que tout fonctionne correctement et que les services soient à la hauteur de leurs attentes.

Peut-être, la troisième solution évidente, c'est tout ce qui est le parrainage sur GitHub. GitHub a mis en place assez récemment tout un système de parrainage où certains projets open source peuvent récolter des fonds, ce qui permet un peu à des gens qui se lancent dans l'open source de commencer à récolter des revenus. Le parrainage, ça peut être parrainé soit par des utilisateurs, soit par des plus grosses sociétés qui ont, des fois, intérêt à venir recommander ou inciter des projets à continuer sur le long terme. Peut-être pas la solution qui s'ouvre à tous dès le début, mais une solution alternative et qu'on voit de plus en plus apparaître, et des fois avec des projets qui ont acquis une bonne reconnaissance au cours par exemple des deux dernières années. Je pense que la pandémie a joué pour ça.

Après, je dirais qu'il y a des moyens plus indirects de faire des revenus avec de l'open source. Comme on le disait, il y a différents types de licences open source qui n'autorisent pas les mêmes choses. On a par exemple les licences permissives, qui sont un peu les licences qui vous permettent de tout faire avec le logiciel sans vous imposer des restrictions trop problématiques, notamment d'un point de vue commercial. Quand on utilise des éléments qui sont disponibles sous une licence dite permissive, ça peut permettre de le réintégrer dans une solution propriétaire, ce qui peut permettre de faire en fait du développement avec une forte valeur ajoutée où on est capable de réutiliser des éléments qui sont bien établis, qui ont été bien travaillés, qui sont reconnus des fois soit par ses propres développeurs ou des développeurs externes et donc, de réduire le coût de production du code et d'accélérer le développement, parce qu'on est capable de juste réinsérer quelque chose : une librairie à un élément de code, une fonctionnalité directement dans notre solution propriétaire, sans que ça vienne nous poser un peu je dirais les embuches.

Un autre moyen je dirais de faire des revenus, c'est d'utiliser les doubles licences, où cette fois-ci, on propose un même logiciel, mais sous deux licences différentes. Une version qui va être gratuite, mais sous une licence de logiciel libre, avec un mécanisme de réciprocité. L'idée, c'est de venir dire: « Si vous êtes un petit client ou si vous êtes un utilisateur unique et que vous voulez essayer notre logiciel, c'est une autre solution, vous pouvez la télécharger ». Vous n'avez pas besoin de nous payer des fonds. Par contre, si vous commencez à la modifier ou à autrement faire quoi que ce soit avec, il va falloir que vous redistribuez cette version-là à tout le monde et nous et non seulement à nous.

De la même manière, en parallèle à ça, vous fournissez aussi une version payante du logiciel, cette fois-ci sous une licence qui est propriétaire et qui donc, pourrait permettre à des clients plus important d'obtenir une licence qui leur permettrait d'utiliser le logiciel ou de le réintégrer même à leur propre solution ou à leur propre architecture, sans risquer que ça vienne contaminer leur code propriétaire avec justement ce mécanisme de copie-là, ce mécanisme de réciprocité.

On a aussi le modèle de code ouvert qui apparaît. De plus en plus, on a les solutions maintenant qui sont bien développées avec ça ou l'idée, c'est que la majorité du code est libre et distribuée sous une licence open source et où il y a juste une petite fraction de l'ensemble de la solution qui est sous une licence de code propriétaire, comme par exemple des modules ou des extensions. Du coup, ça permet à des développeurs externes de venir jouer avec leurs solutions et librement utiliser le logiciel dans d'autres projets open source, mais si jamais moi type de client, je sais qu'il y a certains modules qui vont être particulièrement intéressants pour mes services ou pour m'accompagner dans mon développement ; parce qu'il va falloir que je paye pour débloquer les fonctionnalités requises, parce que cette fois-ci, elles ne sont pas disponibles sous une licence open source. Il va falloir que j'obtienne une licence propriétaire.

Puis, peut-être le dernier moyen de générer du revenu, là c'est vraiment beaucoup plus indirect, c'est d'utiliser ça comme un outil économique indirect. C'est surtout les grandes entreprises qui font maintenant ce genre de chose depuis quelques années. On a Google avec Chromium et Android, Microsoft avec Kit Off, Facebook avec Uyat. L'idée, c'est de venir participer à l'écosystème open source notamment en proposant des solutions qui ont été développées je dirais au sein par leur équipe, et venir un peut démontrer leur technique, leur talent, leur expertise dans un domaine et permettre en fait à d'autres de venir au développement de ces solutions, et de rester un peu le leader dans un secteur.

L'exemple type, c'est par exemple Chromium de Google, reste l'architecture utilisée par beaucoup de navigateurs qu'on utilise aujourd'hui et même des navigateurs propriétaires, mais comme c'est disponible en open source et sous des licences qui ne sont pas forcément problématiques, c'est tout à fait possible de créer des solutions propriétaires à partir de ce niveau-là. Puis, outre le fait que ça permet un peu de venir se mettre de l'avant et rester un leader sur le marché et de venir guider et gérer un peu le développement logiciel avec cette méthode, ça peut aussi permettre parfois d'identifier des recrues potentielles ou même de s'assurer qu'elles soient formées sur nos produits, sur nos techniques, avant même que les recrues rejoignent nos équipes.

Parce que vu qu'elles vont s'impliquer, vu que ces personnes-là vont s'impliquer dans notre communauté, elles vont commencer à se familiariser avec notre code, à se familiariser avec nos méthodes de développement, peut-être la manière dont on commande le code. Quand on va les recruter, quand on va les rattraper dans nos équipes elles, seront déjà je dirais ready for action. Puis, peut-être le dernier point, très rapidement, c'est que quand on propose l'open source, c'est aussi mutualiser tout un tas de processus en matière de développement de code et notamment en matière d'innovation.

Ça permet aussi de créer un lien de confiance avec ses utilisateurs, parce qu'on vient démontrer, on vient ouvrir la porte sur nos codes et sur nos méthodes de développement et ça permet aussi de venir mutualiser la gestion de risque, parce que plutôt que d'être tout seul dans notre coin à s'assurer que notre code n'a pas d'erreur ou ne présente pas un risque de cybersécurité, on ouvre la porte à toutes les personnes de venir nous dire : « Hey. Attention à cette ligne ou attention à cette fonctionnalité. J'envisage un problème avec ça. »

Maya: Merci de nous avoir présenté toutes ces différentes options. Quand nous parlons de logiciel libre, il y a quand même une composante de titularité de propriété. En termes de droit de propriété intellectuelle, la distribution libre ou c'est quoi ?

Jules: C'est une très bonne question. En général, ce qu'il faut bien garder en tête, c'est que quand on crée un logiciel, quand on crée du code source, on a un droit d'auteur sur le code source qui a été créé. Si aujourd'hui, vous prenez votre code source, puis que vous créez un répertoire sur GitHub sans fournir de licence avec, vous avez rendu disponible votre code à tout le monde, tout le monde peut venir voir le code, ils peuvent l'examiner, mais c'est à peu près tout ce qu'ils peuvent faire parce qu'il n'y a pas de licence, ils ne peuvent pas l'utiliser.

Si vous voulez que les gens commencent à utiliser le code ou à utiliser le logiciel que vous êtes en train de distribuer, de mettre disponible à tout le monde, il faut s'assurer qu'il y a une licence qui y soit attachée, qu'ils vont venir dire, parce que ce que les utilisateurs peuvent faire ou ne pas faire avec votre logiciel. C'est un peu là que l'open source est arrivé d'un point de vue pratique en droit. Il y a toute une histoire vers laquelle on ne tendra pas, ça pourrait faire l'objet d'un autre podcast, je dirais, mais les licences open source, c'est un des moyens qui sont arrivés pour s'assurer qu'on donnait aux utilisateurs potentiels les droits nécessaires pour faire ce qu'ils avaient besoin de faire avec le logiciel, que ce soit de l'utiliser, de le distribuer, de l'installer.

A un moment donné, c'était même à intégrer dans certaines licences propriétaires très anciennes, comme je disais, il y a un composant historique. Vraiment, les licences open source, ce sont devenus un peu ces modèles de documents que tout le monde pouvait réutiliser pour s'assurer que quand vous êtes en train de distribuer votre solution, vous le distribuez avec les bonnes intentions. Est-ce que vous voulez laisser tout le monde, la possibilité de l'installer, mais pas forcément de le modifier ? Il y a des modèles de licences qui sont disponibles. Est-ce que vous pouvez laisser les gens faire ce qu'ils veulent avec, sans même s'assurer qu'ils vous donnent un quelconque crédit sur des solutions tierces qu'ils développeraient ? Vous avez l'option de le faire.

Puis des fois, ces enjeux-là, ça peut aller très loin. Par exemple, on a dans certaines licences open source je dirais un peu plus techniques, des fois même les questions de brevets qui sont évoquées, où on vient dire : « Vous pouvez réutiliser l'élément ou logiciel qui vous est ainsi proposé et breveter quelque chose de nouveau ou d'innovant, qui s'appuierait là-dessus. Il faudra juste nous laisser, au titulaire du droit d'auteur, une licence sur ce brevet pour que je puisse continuer de proposer ma solution en open source ».

Vraiment, l'idée au début de tout ça, c'est qu'il y a quelqu'un qui va créer du code source, sur lequel il y aura un droit d'auteur. Il va décider de le distribuer sous une licence, et s'il décide d'utiliser une licence open source, il y a toutes ces considérations qu'on est en train de discuter, qui sont en train de s'appliquer. C'est pour ça qu'en général, j'ai tendance à dire que l'open source, c'est important de s'assurer qu'on l'utilise correctement. Parfois, quand on regarde un peu les choses ou les pratiques qui se font, c'est là qu'on se rend compte que les gens ne font pas toutes les vérifications préalables nécessaires.

On a certaines personnes qui voient marqué open source, distribution libre, ouverte et ils disent : « C'est gratuit. Je peux l'utiliser sans trop se poser plus de questions ». Bien évidemment, c'est possible de l'utiliser dans ce contexte-là, mais il y a peut-être des mécanismes qui vont vous empêcher de commercialiser au mieux une solution ou voir même, de vous mettre dans une situation où vous ne respectez pas vos engagements contractuels avec certains clients ou fournisseurs de services qui vous interdisaient, par exemple, d'utiliser l'open source dans certaines fonctionnalités ou certains services que vous proposez.

L'open source, c'est un très bon outil, ça peut être extrêmement utile pour accélérer la production de code, il faut juste s'assurer de l'utiliser correctement. Comme je disais, on a des listes de licences open source reconnues, établies avec parfois des petits résumés qui sont disponibles, mais l'important, c'est de s'assurer de toujours lire la licence en tant que telle et s'assurer de bien lire ce qu'elle prévoit, parce que des fois, on retrouve des licences que je vais appeler artisanales, où on peut répondre à certains critères, mais c'est des gens qui sont venus, je dirais, mix and match plusieurs licences, où ils vont venir rajouter un peu leurs propres mots là-dessus.

Peut-être à ce niveau-là, la dernière distinction que j'aime bien faire et c'est pour ça que j'ai du mal à utiliser peut-être aujourd'hui le terme logiciel libre, c'est que les termes logiciel libre et open source n'ont pas vraiment la même définition. Un logiciel libre, il y a vraiment une volonté d'avoir une visée philosophique et politique, on choisit d'utiliser une licence open source, car on veut encourager la diffusion de connaissance. C'est vraiment en lien avec tous les critères qui ont été établis et préparés par Richard Stallman et la Free Software Foundation.

À l'inverse, de l'autre côté, on a l'open Source, où là, c'est plutôt une méthode de développement et distribution de logiciel ou d'élément où l'on choisit d'offrir le code source sous ces mécanismes pour diverses raisons, qu'on a évoquées, que ce soit la création d'une communauté autour d'un logiciel, le recrutement de candidats potentiels, ouvrir un peu son code à d'autres pour qu'on puisse mutualiser l'innovation.

Un logiciel libre est toujours open source, avec en général des mécanismes de réciprocité qu'on parlera probablement après, mais tout ce qui est open source n'est pas forcément un logiciel libre. Peut-être juste un point à garder en tête dans les discussions futures avec d'autres personnes du domaine.

Maya: On peut utiliser la distribution libre et on entend parler de cas où la propriété d'un logiciel libre devient un élément de confusion. Des gens ont utilisé le logiciel libre, ils ont développé plusieurs actifs à partir de celui-ci et ils peuvent être soumis à ce qui semble presque comme une infection de logiciel libre où l'utilisation d'un logiciel libre peut devenir un problème. On peut être en train d'utiliser une distribution libre qui a été quelque peu abandonnée du point de vue du support, en un sens. Je me demandais si vous pouvez nous parler de quelques pièges et de choses que nous devons surveiller si on pense utiliser un logiciel libre.

Jules: Je suis très favorable à l'open source. Il y a quand même quelques enjeux qu'il faut garder en tête. Peut-être le premier et le plus important, celui qui moi me touche le plus, c'est lié avec la propriété intellectuelle. Comme on l'a dit, les licences open source, elles sont là quand même pour venir permettre la distribution de droits d'auteur en général. Parfois, elles intègrent ce qu'on appelle un mécanisme de réciprocité. On parle parfois de copyleft, cherlike ou de contamination, comme on disait, et c'est souvent le principal souci à avoir quand on regarde un peu la licence qui est utilisée ou la licence qu'on envisage d'utiliser avec notre propre solution.

Un mécanisme de réciprocité, c'est un mécanisme qui vient prévoir que si j'utilise un élément qui est distribué sous une licence qui comporte ce mécanisme, j'ai donc droit de l'utiliser, j'ai le droit de le redistribuer. J'ai aussi le droit de le modifier et de le redistribuer sous cette version modifiée. Par contre, si jamais je commence à le redistribuer, cette version modifiée, si jamais je prends un logiciel et je réintègre des nouvelles fonctions, donc j'ai créé du code propriétaire sur lequel j'ai mon droit d'auteur et que maintenant je le propose à d'autres personnes, cette version modifiée, je ne peux pas utiliser une autre licence que la licence open source originale dans cette redistribution.

C'est-à-dire que je ne peux pas commencer à dire : « J'ai créé du code propriétaire, du code qui m'appartient. Je veux vous vendre ce code propriétaire. Vous êtes tenu à accepter la licence que je vous propose. » Non, je suis obligé d'utiliser la licence open source originale et de le proposer sous cette même licence. Ce qui vient fortement impacter la commercialisation que j'en avais. Ça, c'est la solution la moins problématique. La plus problématique et c'est pour ça, des fois, qu'on parle de contamination, c'est que je vais utiliser un élément, des lignes de code qui sont licenciées avec justement une licence avec un mécanisme de réciprocité. Je l'intègre à ma solution qui existe déjà et qui vit déjà et d'un seul coup, je continue de distribuer ma solution.

D'un seul coup, j'ai contaminé ma solution. Je lui ai injecté un virus. On va dire que dans le contexte actuel de pandémie, ça s'applique particulièrement. J'ai vraiment rendu malade mon code ou du coup, toute la solution que je vais commencer à distribuer est devenu en fait une œuvre dérivée de ce code open source. Du coup, toute ma solution, je devrais maintenant la distribuer sous cette même licence open source, même si je la proposais avant ça sous une licence propriétaire. D'un seul coup, ça devient fortement impacté par ma propriété intellectuelle, les modes de commercialisation que j'envisageais et je me retrouve dans une situation qui n'est pas forcément très enviable.

C'est pour ça que maintenant, depuis quelques années, on a certaines alternatives. Comme on disait, il y a les licences permissives qui n'en contiennent pas. Il y a les licences avec mécanisme de réciprocité et maintenant, on a les mécanismes de réciprocité faibles. On a la LGPL pour Lesser General Public License par exemple, où l'idée, c'est qu'on vient dire : « Si vous faites un lien entre cet élément open source qui a quand même un mécanisme de copyleft et votre code propriétaire, votre code propriétaire n'est pas contaminé, vous pouvez continuer de le distribuer sous une licence propriétaire. Il n'y a pas de problème. Il y a vraiment juste cet élément qui est licencé sur cette licence open source. Par contre, si vous voulez modifier cet élément directement et le redistribuer, là, à ce moment-là, il va falloir que vous le redistribuiez sous cette même licence open source. »

C'est vraiment un peu l'enjeu principal quand on envisage d'utiliser une licence open source en propriété intellectuelle. Après, comme on le disait, il y a d'autres enjeux qui peuvent apparaître. D'abord, on a certaines licences maintenant qui prévoient qu'il y ait des restrictions sur l'utilisation commerciale. Des fois, il y a certaines licences qui vont dire : « Vous ne pouvez pas utiliser cet élément, ce logiciel d'une manière commerciale. » Qu'est-ce que ça veut dire, utilisation commerciale ? Ça va aussi dépendre de la licence qu'on a en question. Des fois, on se retrouve un peu bloqué avec ce genre d'élément.

De la même manière, il y a certains éléments open source qui sont des fois abandonnés. On a des gens qui sont volontaires, qui sont bénévoles, qui contribuent à ces logiciels, à ces éléments et à leur maintien à jour. Si plus personne ne le fait, à un moment, on a certains éléments qui vont pourrir, et si on commence à les utiliser, peut-être qu'on est en train de se créer un risque de cybersécurité possible. Comme toujours, quand on commence à intégrer des éléments qui viennent de l'extérieur, c'est toujours le risque que présente l'élément le plus faible de notre chaîne je dirais qui pourrait créer un risque indirect pour nous comme pour les utilisateurs de notre solution.

Surtout que, un enjeu qui des fois se pose, c'est que quand on a une faille d'un élément open source, en général cette faille est très médiatisée. On a beaucoup de gens qui vont souligner qu'attention, il y a un danger avec cette librairie. Il y a un enjeu avec cet élément. Assurez-vous de faire les modifications, et si on ne fait pas les mises-à-jour nécessaires rapidement, on se met dans une situation où des tiers mal intentionnés pourraient tout à fait détecter que cette personne-là, présente un intérêt certain pour nos tentatives d'attaque et de cybersécurité. Un enjeu plus lointain, mais qui s'est posé là ces derniers temps, c'est le relicensing, relicenciement, je dirais en français, où cette fois-ci, c'est un distributeur d'un élément open source qui utilisait par exemple la licence open source A jusqu'à une certaine date, puis qui pour plusieurs raisons, des raisons c'est de mieux contrôler, par exemple, la distribution de son logiciel, va dire : « À partir de l'instant T, je vais maintenant utiliser la licence B sur toutes les nouvelles versions de mon logiciel. Jusqu'à la version 7.1. j'étais sous licence A, à partir de la version 7.2, je serai sous licence B.»

Des fois, changer de licence comme ça, ça peut nous mettre dans des situations problématiques où d'un seul coup, on passe d'une licence permissive à une licence avec des mécanismes de réciprocité, et donc si un peu mécaniquement, sans trop faire attention, on met à jour ces différences d'éléments open source, on peut se retrouver dans une situation où on a contaminé son code sans faire attention. Toujours bien s'assurer de vérifier comment les éléments sont combinés ensembles.

Des fois, ça peut même aller jusqu'à la création de fourche, où on a deux versions d'un même logiciel qui vont continuer à exister en parallèle. Ils n'auront pas forcément les mêmes fonctionnalités. Ils ne seront pas forcément sous les mêmes licences, et on se retrouve à devoir choisir entre la solution A prime ou la solution B prime, mais qui ont toutes les deux pour origine le logiciel ou l'élément A qu'on utilisait, des fois, avec peut-être des avantages d'un côté ou de l'autre.

Toujours un peu s'assurer de réfléchir à l'open source en amont. Si on est proactif, on peut éviter bien des problèmes, surtout les plus graves. Le gros problème, souvent avec l'open source, c'est qu'on commence à l'utiliser, on l'intègre, on ne se pose pas trop de questions, ça accélère le développement, ça nous permet de nous réduire nos coûts et d'être plus compétitifs, c'est en général lors d'un audit, d'une vérification préalable que là, on va nous dire : « Fournissez nous la liste des éléments open source que vous utilisez. » Là, on se rend compte que : « il y a plein d'éléments qui sont venus contaminer notre code. » On était censé offrir toute notre solution sous une licence open source, et là, ça peut avoir des conséquences directes et graves, assez importantes, comme si c'est une transaction, ça peut être la transaction qui est annulée, ça peut être une baisse de la valeur de nos actifs, si on se rend compte que le code propriétaire devrait être rendu disponible à tout le monde.

Ça peut même être des risques de poursuites pour des manquements contractuels. Ça peut être des clients qui nous abandonnent, une perte de confiance de clientèle. Puis aussi, ça peut être de la mauvaise presse. Quand on a son nom ou le nom de sa société qui apparait avec en gros : « Ne respecte pas les engagements en matière de l'open source», ça peut être des fois un dommage à sa réputation important.

Maya: Si vous parlez avec quelqu'un qui pense utiliser le logiciel libre, quelles seraient les considérations clés que vous partageriez avec cette personne ou une compagnie qui est en train de décider s'ils vont ou pas utiliser un logiciel libre ?

Jules: J'ai quatre recommandations en général que je fais, et qui sont assez pratiques, qui permettent un peu de guider la réflexion justement sur l'open source. D'être proactif. Peut-être le plus important, c'est de créer et d'établir une politique open source qui est une politique qui doit être adaptée à la réalité de notre entreprise. Notre manière de fonctionner. L'idée, ça va être d'examiner un peu les pratiques actuelles au sein de notre entreprise, pour s'assurer que ce que l'on est en train de prévoir et de mettre en place ne diverge pas trop. Est-ce que d'abord nos développeurs et nos équipes utilisent de l'open source ?

Si oui, comment ? Est-ce qu'ils font des vérifications préalables quelconques ? Est-ce qu'ils n'utilisent pas du tout de l'open source ? À ce niveau-là, on sera peut-être beaucoup plus libre de mettre en place les règles qu'on veut mettre. De la même manière, il faudrait aussi auditer les composants open source qu'on est déjà en train d'utiliser, que ce soit dans une solution propriétaire ou même des outils qu'on utilise, sans forcément les intégrer à nos propres solutions.

Ensuite, ça va être de venir sensibiliser les différentes parties prenantes au sein de notre société sur ces enjeux-là et surtout la politique qu'on va préparer pour s'assurer que les gens la respectent, la connaissent et qu'ils la mettent en place. C'est pour ça que de la même manière, j'encourage aussi la rédaction de politiques qui soient faciles à lire pour tout le monde et pas juste le département légal, parce que c'est un outil qui doit être pratique avant tout.

Dans certains cas, on arrive même à voir des politiques où on est capable de venir préapprouver certaines licences, je suis tout à fait confortable avec ces licences-là qui seront de licences permissives pour moi. Vous n'avez pas besoin de passer par un mécanisme quelconque. Ça, c'est ma deuxième recommandation qui va avec la première, c'est de mettre aussi en place un processus d'approbation qui soit simple, rapide et efficace, parce qu'une politique, ça ne peut pas couvrir toutes les situations possibles qui risquent d'apparaître quand on va commencer à utiliser l'open source ou à développer du code et donc, avoir un processus d'approbation. Ça permet de venir apporter des réponses qui soient appropriées, qui répondent à un contexte spécifique, quand on fait face par exemple à une nouvelle licence ou à une utilisation qu'on n'avait pas envisagée dans notre politique.

Ca permet aussi de créer un peu une jurisprudence interne sur l'open source ou peut-être qu'on est capable de se dire : « On n'a jamais autorisé cette licence C prime-là de toute notre vie, pourquoi d'un seul coup ça devrait devenir quelque chose qu'on va autoriser ? Est-ce qu'on a peut-être changé notre processus ou notre intégration et ça nous permet maintenant de l'autoriser ? » Un peu comme la politique. En général, ces processus d'approbation, il faut qu'ils soient vraiment simples, rapides et efficaces, sinon le gros risque, c'est qu'on voit toutes nos équipes de développeurs ne pas l'utiliser, parce que ça va ralentir leurs processus, ça va leur causer plus d'ennuis et--[rire]

Je dirais, oui, d'ennuis et de difficultés, que de simplement juste prendre la librairie, de la télécharger et la réintégrer. Il ne faut pas que ça soit vraiment de créer un nouvel obstacle dans le processus de développement. Ou pire encore, sinon on peut carrément se retrouver dans des situations où même si on a mis en place une politique, même si on a mis en place un processus d'approbation, il est tellement complexe où il demande tellement d'information, de documents ou de délais qu'on a des développeurs qui vont cacher leur utilisation de l'open source et là où on se retrouve dans des situations vraiment pas idéales, je dirais.

La troisième chose à faire qui va en parallèle, bien sûr, de tout ça, c'est qu'une fois qu'on a mis en place et qu'on a audité dans le cadre de la mise en place de notre politique tous nos éléments, c'est de créer un registre des différents éléments qui sont sous licence open source. Ça va nous permettre de vérifier plus tard dans le temps si jamais il y a une demande externe ou si jamais on veut faire une vérification pour un risque de sécurité.

Parce que, par exemple, on a une nouvelle faille qui a été détectée sur une librairie open source, si on a un registre qui est disponible et qui est rapidement prêt, on est capable de simplement faire une fonction de recherche, un Ctrl+F, pour juste identifier si on utilise la librairie en question ou pas et savoir s'il faut vite mettre à jour ou si on peut simplement souffler et passer la fin de semaine en paix, [rire] l'esprit tranquille.

C'est important que ce registre contienne toutes les informations pertinentes par élément, que ce soit le registre utilisé, où est-ce qu'on a obtenu un peu l'élément en question, la licence applicable, quelle version de l'élément du logiciel on est en train d'utiliser, la dernière fois qu'on l'a mis à jour, est-ce qu'on a fait des vérifications quelconques, quelle manière est-ce qu'il est intégré. Il faut vraiment que ce soit un registre qui soit vivant. Si jamais on rajoute d'autres éléments, si jamais on en supprime, si jamais on en met à jour, il faut s'assurer que les informations du registre soient aussi mises à jour.

Un des gros avantages, par exemple, de ce genre de chose, c'est d'éviter tous les enjeux quand on a un relicensing, quand c'est un relicenciement. Si par exemple, je savais que j'utilisais un élément et que cet élément va changer de licence, je peux vérifier la version que j'utilise, la licence applicable et me dire : « À partir de telle date, quand la nouvelle version sera disponible sous une nouvelle licence, j'arrêterai de l'utiliser, il va falloir que je change d'élément, que je trouve quelque chose d'équivalent qui soit sous une licence avec laquelle je sois plus confortable. »

Vraiment, l'idée, c'est d'avoir une image globale de l'open source dans notre entreprise et ça peut venir aussi encourager des développeurs à utiliser l'open source, parce que s'ils se rendent compte que d'autres équipes avec lesquelles ils ne travaillent pas ou d'autres collègues avec lesquels ils ne communiquent pas forcément sur ces questions-là l'utilisent, peut-être qu'ils vont se dire : « C'est une possibilité, c'est facile, il y a un registre, c'est clair, je peux me référer à des éléments qui sont déjà intégrés, qui ont été acceptés au sein de nos solutions, je peux aussi aller de l'avant avec ça. »

Enfin, le quatrième, puis ça, ça coule de source avec tout ce que je dis, je pense, c'est il faut s'assurer de mettre à jour les composants open source en conséquence. En open source, c'est l'utilisateur qui est responsable de la mise à jour, en général, ce n'est pas comme une solution propriétaire où on va avoir des mécanismes de push où on va avoir une notification qui va dire : « Attention, mise à jour disponible, veuillez mettre à jour, voilà les changements. » En général, c'est l'utilisateur qui doit s'assurer de venir vérifier s'il y a des nouvelles versions et ce genre de chose.

C'est important donc de mettre à jour pour corriger les risques cybersécurités ou pour s'assurer que même les éléments restent compatibles. Des fois, on a des changements de systèmes d'exploitation ou de fonctionnalités où si on ne met pas à jour, ça ne va plus fonctionner, donc s'assurer de toujours mettre à jour à ce niveau-là. Le pendant de tout ça, c'est s'assurer aussi que notre registre, on le maintienne à jour et donc si jamais je change un élément, je change de version, je viens juste m'assurer que mon registre corresponde à la réalité de la chose. Si jamais, on parle d'une vulnérabilité, ça nous permet de vérifier rapidement comme on le disait si on à risque de tout ça. Vraiment, mettre à jour, mais mettre à jour en conséquence, s'assurer comme on le disait qu'il n'y ait pas un relicenciement quelconque qui pourrait venir nous poser un enjeu sur le long terme.

Maya: Une dernière question. Où pouvons-nous en apprendre plus sur les logiciels libres ?

Jules: Je pense que maintenant, c'est un sujet qui est traité tellement par tout le monde qu'il y a beaucoup de ressources qui sont disponibles en ligne. Peut-être les plus simples pour commencer, c'est de regarder ceux qui sont proposés par les organisations qui font la promotion de l'utilisation des logiciels libres à Free Software Foundation FSF, l'OSI, tout genre d'organisations qui n'ont pas forcément les mêmes visées politiques ou philosophiques avec l'open Source, mais qui proposent quand même de la documentation sur les licences disponibles sur pourquoi utiliser l'open source sur les pièges des fois à éviter quand on est un développeur et qu'on veut proposer un logiciel open source.

L'alternative, si on sait un peu coder, c'est aussi ne pas hésiter à contribuer. La communauté, elle est toujours prête à ouvrir les bras à des personnes intéressées et des personnes volontaires. Je mentionnais si on sait coder, mais même si on ne sait pas coder, c'est tout à fait possible de venir aussi donner son avis sur certaines fonctionnalités ou sur certains aspects d'une distribution quelconque. Méfiez-vous tout de même de ce que vous trouvez en ligne. On a beaucoup des fois d'analyses sur les aspects légaux de l'open source qui n'ont pas été faites par des juristes, qui ont été faites par des développeurs.

Des fois, il y a des abus de langage où il y a certaines incompréhensions avec des mécanismes très précis du droit d'auteur. Dans tous les cas, bien s'assurer de lire les licences elles-mêmes. C'est aussi un bon moyen d'apprendre et de se rendre compte un peu que des fois le langage se répète ou des fois le langage a des justes petites différences. Un autre outil très important quand on tombe sur une licence qu'on n'est pas certain de comprendre, c'est de vérifier qu'il n'y ait pas une FAQ, questions-réponses. En général, les gens qui créent une nouvelle licence open source vont créer un peu ce document de questions-réponses pour expliquer quels étaient les objectifs visés ou du moins, leurs interprétations de certaines clauses ou de certains mécanismes.

Dans le pire des cas ; je ne devrais pas dire le pire. Sinon, j'avais donné une présentation en 2020 qui est disponible sur le site de ROBIC sur l'open source et les bonnes pratiques, où on reprend certains des éléments qu'on a discutés aujourd'hui.

Maya: Jules, ce fut un grand plaisir de vous parler aujourd'hui. Merci énormément d'avoir pris le temps de partager avec nous vos connaissances au sujet des logiciels libres et la distribution libre.

Jules: Merci beaucoup.

Maya: Vous venez d'écouter Voix de la PI Canadienne, un balado où nous parlons de propriété intellectuelle. Dans cet épisode Jules Gaudin, un avocat et expert en PI au cabinet ROBIC à Montréal nous a expliqué ce qu'on entend exactement par logiciel libre et nous a partagé des choses importantes à considérer si vous planifiez utiliser de la distribution libre. Si vous êtes curieux et vous voulez en apprendre plus sur ce sujet des licences de logiciels libres couramment utilisées, visitez le site web anglais choosealicense.com.

Si vous pensez lancer votre propre projet de distribution libre ou vous voulez contribuer à la communauté de distribution libre, vous pouvez trouver des guides et de l'information sur le site web anglais opensource.guide.