« Previous Page : Prochaines étapes

Table of Contents

Annexe A - Questions d’ordre juridique

• Propriété intellectuelle
• Gérer les obligations relatives aux licences
• Gestion des brevets
• Gestion des risques juridiques

Propriété intellectuelle

Licences

Avis

La plupart des licences de LL comprennent un avis d’exonération de garantie le plus exhaustif possible afin de veiller à ce qu’aucune garantie ne s’applique. Par exemple, la clause suivante de la deuxième version de la licence publique Mozilla (MPLv2) propose une version typique de cette modalité de la licence :

En vertu de la présente licence, les logiciels visés sont fournis « en l’état », sans aucune garantie explicite, implicite ou légale, ce qui comprend notamment toute garantie concernant l’absence de défectuosité, la qualité marchande, l’adaptation à un usage particulier ou l’absence de contrefaçon du logiciel visé. Vous assumez en totalité le risque lié à la qualité et au rendement du logiciel visé. Si le logiciel visé se révèle défectueux à quelque égard que ce soit, vous (et non un contributeur) devez assumer les coûts d’entretien, de réparation ou de correction nécessaires. Le présent avis de non-responsabilité constitue une part essentielle de la licence. La licence n’autorise aucune utilisation du logiciel visé, sauf en vertu du présent avis.

Comme on l’a montré, en plus de préciser que la licence est « sans aucune garantie », ces clauses prennent le plus souvent soin d’exclure toute garantie de « qualité marchande » ou d’« adaptation à un usage particulier ». Cela permet de clarifier et de veiller à ce que ces deux garanties ne s’appliquent pas, car certaines lois pourraient autrement les imposer en tant que conditions implicites d’un contrat ou d’une licence. Par exemple, lors de la vente de logiciels en Ontario, la Loi sur la vente d’objets impose des garanties implicites quant à la qualité marchande (article 13) et, dans certains cas, des garanties relatives à l’adaptation à un usage particulier (article 15). Toutefois, compte tenu des exclusions explicites dans les licences de LL typiques, ces garanties ne s’appliquent pas.

De nombreuses licences énoncent explicitement les garanties d’absence de contrefaçon (p. ex., la licence MPLv2, comme on l’a indiqué ci-dessus). Cet avis vise à exclure la doctrine américaine d’une garantie implicite d’absence de contrefaçon de l’article 2-312 de l’Uniform Commercial Code, qui garantit autrement que le logiciel ne viole pas le droit d’auteur d’un tiers. Par exemple, si un développeur de logiciel téléchargeait un élément de code dans un projet de LL et que cet élément provenait à l’origine d’un logiciel exclusif protégé par droit d’auteur, quiconque téléchargerait ou utiliserait le LL enfreindrait techniquement le droit d’auteur. En cas de poursuite pour une telle violation, la garantie d’absence de contrefaçon ferait en sorte que l’utilisateur n’aurait aucun recours contre les distributeurs ou les développeurs; l’utilisateur doit faire preuve de vigilance. Au Canada, même s’il n’existe pas de doctrine précise sur la garantie d’absence de contrefaçon, cette clause de licence présente un avis concernant les garanties de titre semblables (surtout lorsqu’elle est prise en compte conjointement avec un avis général sur le fait que la licence vient « sans aucune garantie » à l’article 13 de la Loi sur la vente d’objets. En plus des avis sur les garanties, presque toutes les licences comportent un avis de non-responsabilité. Par exemple, la licence MPLv2 indique ce qui suit :

Un contributeur, ou toute personne qui distribue le logiciel visé dans la mesure permise ci-dessus, ne peut en aucun cas et sous aucune théorie juridique, qu’elle découle d’un délit civil (y compris la négligence), être tenu responsable envers vous de tout dommage direct, indirect, particulier, accessoire ou consécutif de quelque nature, ce qui comprend notamment les dommages découlant de la perte de bénéfices, de la défection de clients, d’un arrêt de travail, d’une défaillance informatique, ou de toute autre perte ou tout autre dommage commercial, même si cette partie aurait dû être informée de la possibilité de tels dommages. Cette limitation de responsabilité ne s’applique pas à la responsabilité en cas de décès ou de préjudice corporel résultant de la négligence d’une telle partie dans la mesure où la loi en vigueur l’interdit. Certaines administrations ne permettent pas l’exclusion ou la limitation des dommages accessoires ou consécutifs; il est donc possible que cette exclusion ou limitation ne s’applique pas à vous.

Encore une fois, cet avertissement vise de façon générale à couvrir tous les motifs de responsabilité et tous les types de dommages possibles. Il en résulte que toute personne qui utilise un LL le fait à ses propres risques.

Étant donné que le contributeur (le gouvernement du Canada dans le cas présent) n’assume aucune responsabilité et n’offre aucune forme de garantie pour les contributions faites ou les produits obtenus, il doit également renoncer à toute forme de propriété réelle ou perçue liée au code ou au produit généré.

Ces avis sont courants dans la presque totalité des licences de LL, mais les concédants peuvent les modifier. Dans certains cas, une licence de LL permet au concédant de formuler d’autres avis. Par exemple, la licence MPLv2 permet au concédant de « prévoir d’autres avis d’exonération de garantie ou limitations de la responsabilité propres à une administration donnée ». Dans d’autres cas, un concédant peut faire le contraire et choisir d’offrir une garantie ou d’accepter une responsabilité, en supprimant l’effet de l’avis d’exonération de garantie. Par exemple, selon la licence MPLv2 « [v]ous pouvez choisir d’offrir et de facturer des frais pour la garantie, le soutien, l’indemnisation ou les obligations relatives à la responsabilité pour au moins un destinataire du logiciel visé ».

Obligations de notification

Comme les avis, une clause relative aux obligations de notification est la norme dans presque toutes les licences de LL. Il s’agit d’une obligation de reproduire le texte de la licence (directement ou par un hyperlien) chaque fois que l’œuvre autorisée est reproduite. Les obligations de notification exigent aussi d’habitude que les œuvres distribuées conservent les autres avis qui les accompagnent (p. ex., déclarations relatives au droit d’auteur, autres avis d’exonération de garantie ou de non-responsabilité, ou avis sur les brevets). Habituellement, les obligations de notification s’appliquent au moins à la distribution du code source, mais elles s’appliquent souvent aussi à la redistribution du code exécutable, selon la licence. À titre d’exemple, l’obligation de notification typique de la licence MPLv2 prévoit ce qui suit :

Vous ne pouvez pas supprimer ou modifier la teneur des avis de la licence (y compris l’avis de droit d’auteur, l’avis sur le brevet, les avis d’exonération de garantie ou les limitations de la responsabilité) contenue dans le code source du logiciel visé, sauf dans la mesure requise pour corriger des inexactitudes factuelles connues.

Obligations relatives au code source

Les licences réciproques comprennent habituellement une « obligation relative au code source » qui exige que toute œuvre distribuée par une personne comprenne le code source ou, à tout le moins, un lien vers ce code. Ainsi, le logiciel demeure dans un format que les utilisateurs en aval peuvent continuer de modifier. Sans une telle exigence, quelqu’un pourrait apporter des changements au logiciel en vertu d’une licence réciproque, mais seulement redistribuer le code exécutable. Cela ne permettrait plus à d’autres d’apporter d’autres changements ou de les réintégrer dans le projet initial.

Bien qu’une obligation relative au code source aille habituellement de pair avec une licence réciproque, il convient de prendre note que, dans certains cas, cette obligation peut seulement être rattachée au code original. Cet élément devient particulièrement important lorsqu’on utilise des bibliothèques de logiciels. Par exemple, les fournisseurs de logiciels exclusifs peuvent établir des liens vers des bibliothèques de LL qui sont visées par une licence publique GNU amoindrie, ainsi que les utiliser. Tant que le logiciel exclusif ne fait qu’établir des liens menant à ces bibliothèques, l’obligation réciproque ne s’applique pas. Le fournisseur n’est pas tenu de divulguer son propre code source. Toutefois, l’obligation relative au code source s’applique toujours aux bibliothèques elles-mêmes. Le fournisseur a l’obligation de redistribuer ou de fournir autrement le code source original de la bibliothèque avec le produit exclusif.

Dans certains cas, il n’est pas possible pour une personne de fournir directement le code source avec le code exécutable. Si l’on distribue un logiciel sur un disque compact ou un DVD, il peut être difficile d’inclure les deux, surtout si l’on tient compte du fait que le code source peut être beaucoup plus volumineux que le code exécutable. Pour cette raison, les licences sont habituellement souples quant à la façon dont il faut fournir le code source. Par exemple, la licence GPLv3 permet à une personne de fournir, au lieu du code source lui-même, une offre écrite de distribution du code source sur un disque compact distinct ou par l’entremise d’un serveur réseau. En cas de distribution du code exécutable par l’entremise d’Internet, une personne peut simplement fournir des instructions sur la façon de télécharger le code source à partir d’un autre serveur branché à Internet.

Licences réciproques

Une caractéristique distinctive et courante des LL a tendance à répartir les licences en deux catégories, soit celles ayant une obligation réciproque (aussi appelée « gauche d’auteur », « partage à l’identique » ou « héréditaire ») et celles qui n’en ont pas. Les licences de la catégorie réciproque stipulent que les modifications apportées au logiciel doivent également être visées par la même licence. Par conséquent, si une personne apporte un changement à un logiciel réciproque ou si elle inclut un code visé par une licence réciproque dans son propre logiciel, cette personne ne peut pas distribuer la nouvelle œuvre en tant que logiciel exclusif; elle doit seulement redistribuer le nouveau code avec la même licence de LL. La licence GPL, qui est la licence de gauche d’auteur la plus populaire, explique cette stipulation comme suit :

Pour protéger vos droits, nous devons empêcher les autres de vous les refuser ou de vous demander de les céder. Vous avez donc une certaine responsabilité si vous distribuez des copies du logiciel, ou si vous le modifiez, à savoir la responsabilité de respecter la liberté des autres. Par exemple, si vous distribuez des copies d’un tel programme, à titre gracieux ou contre rémunération, vous devez transmettre aux bénéficiaires les mêmes libertés que vous avez reçues. Vous devez veiller à ce qu’ils reçoivent eux aussi le code source ou qu’ils puissent l’obtenir.

Seules certaines licences de LL contiennent cette stipulation, alors que d’autres licences populaires, comme la licence MIT, la licence BSD et la licence Apache, ne l’ont pas. Les licences sans cette stipulation sont généralement appelées « licences permissives ». Dans ces cas, l’auteur des modifications n’est pas tenu d’assujettir ses modifications à la même licence, ni même à toute autre licence de LL. En général, l’auteur des modifications peut même utiliser et redistribuer le logiciel modifié en tant qu’application logicielle exclusive.

Cependant, différentes licences réciproques établissent des degrés variables de mise en application de cette obligation réciproque de distribution en vertu d’une même licence, ce qui vient brouiller la distinction entre ces types de licences. Il s’agit peut-être de l’aspect le plus déroutant des licences de LL et il mérite une attention particulière. Pour déterminer si une certaine activité comporte une obligation réciproque, il faut tenir compte (1) du type de distribution et (2) de l’ampleur de l’intégration avec le code original.

En ce qui concerne le type de distribution, les obligations réciproques ne s’appliquent qu’à certaines activités relatives à la « distribution ». En l’absence d’une telle distribution, les licences permettent presque toujours à une personne d’utiliser et de modifier un logiciel visé par une licence réciproque sans jamais publier son code. Par exemple, une entreprise peut modifier et personnaliser un logiciel en vertu d’une licence réciproque à des fins internes, et elle n’a pas besoin de partager ce logiciel ou le code source du logiciel. Toutefois, une « distribution » déclenche une obligation réciproque de distribution en vertu de la licence d’origine. Il existe deux types de déclencheurs courants dans les licences de LL :

• Distribution du code source ou exécutable : La distribution du logiciel, soit par Internet ou sur un support physique comme un disque compact, qu’il s’agisse de code source ou de code exécutable, est le déclencheur le plus courant d’une obligation réciproque. Par exemple, il s’agit du déclencheur prévu dans la licence GPL, très populaire.
• Accès sur un réseau informatique : Élément présent dans la licence publique générale GNU Affero, l’accès à un réseau informatique est un déclencheur beaucoup plus important large qui impose une obligation réciproque chaque fois que d’autres personnes accèdent au logiciel sous licence par l’entremise d’un réseau informatique. Ce déclencheur vise à englober les entreprises de services Web qui exploitent leurs plateformes à l’aide de LL; ces entreprises doivent mettre leur code source à la disposition des autres.

Même si le logiciel est distribué, les obligations réciproques ne s’étendent qu’à certaines modifications (selon la licence) :

• Œuvres dérivées : Comme le prévoit la licence GPL, ce type de clause réciproque stipule que l’obligation s’applique à toutes les « œuvres dérivées » (l’équivalent américain d’une « adaptation » en vertu de la Loi canadienne sur le droit d’auteur, probablement d’une portée semblable). La limite exacte de ce qui constitue une « œuvre dérivée » est chaudement débattue. Cependant, il est clair qu’une simple « collection » d’œuvres ne déclenche pas d’obligations réciproques.
• Collections : Fait référence à la distribution collective de nombreux programmes informatiques (p. ex., sur le même disque compact) qui, toutefois, n’interagissent pas étroitement entre eux.
• Œuvres dérivées avec autorisation de liaison : L’exemple le plus frappant de ce type de clause est celui que l’on trouve dans la licence publique générale GNU amoindrie (LGPL). Cette licence ressemble à la licence GPL, mais elle autorise explicitement une personne à lier son code de manière statique ou dynamique à une bibliothèque de programmes visés par une licence LGPL, sans déclencher d’obligation réciproque (en développement logiciel, le terme « liaison » comprend un couplage souple dans le cadre duquel un élément logiciel communique avec un d’autres logiciels et utilise leurs fonctions).
• Fichiers modifiés seulement : Propre à la licence publique Mozilla (MPL), ce type de clause n’impose que des obligations réciproques sur les fichiers modifiés. Si une œuvre dérivée contient des fichiers qui sont des versions modifiées de l’œuvre d’origine, ainsi que de nouveaux fichiers, seuls les fichiers originaux directement modifiés sont visés par l’obligation réciproque.

Les différences entre les diverses licences de l’ensemble populaire GNU illustrent comment le type de distribution et l’étendue de l’intégration interagissent pour déterminer dans quelles circonstances une obligation réciproque s’applique, comme le montre le tableau suivant.

	Œuvre dérivée de l’original.	Œuvre dérivée avec liens vers l’original seulement.	Collection, y compris l’original non modifié.
Distribution du code source ou du code d’objet.	GPLv3 : Oui LGPLv3 : Oui AGPLv3 : Oui	GPLv3 : Oui LGPLv3 : Non AGPLv3 : Oui	GPLv3 : Non LGPLv3 : Non AGPLv3 : Non
Fourniture d’un accès sur un réseau informatique.	GPLv3 : Non LGPLv3 : Non AGPLv3 : Oui	GPLv3 : Non LGPLv3 : Non AGPLv3 : Oui	GPLv3 : Non LGPLv3 : Non AGPLv3 : Non

Gérer les obligations relatives aux licences

Lorsque des obligations réciproques de licence s’appliquent, vous n’avez pas l’avantage de pouvoir choisir une licence. Lorsque vous distribuez le logiciel, votre code doit, dans la mesure précisée dans la licence réciproque, être assujetti à la même licence ou, lorsque la licence le permet, à une version ultérieure de la même licence. Dans un tel cas, lorsque vous faites face à une obligation de licence réciproque, il existe trois façons de vous y conformer :

1. Ne distribuez pas votre logiciel.
2. Accordez une licence à votre logiciel en vertu de la même licence (ou, lorsque la licence le permet, une licence compatible).
3. Refondez des parties de votre logiciel de façon à ce qu’il ne contienne pas de code ou de bibliothèque visés par une licence réciproque (ou, à tout le moins, veillez à ce que votre code ne s’intègre pas étroitement au code réciproque au point où il soit assujetti à l’obligation y afférente).

Les fournisseurs de logiciels propriétaires optent habituellement pour la troisième façon lorsqu’ils remarquent la présence d’un code réciproque, étant donné qu’ils doivent distribuer leur logiciel aux clients payants, mais qu’ils ne veulent habituellement pas ouvrir le reste de leur code source à d’autres personnes. Il est donc important que ces fournisseurs procèdent à une vérification de « diligence raisonnable » de leurs projets logiciels en veillant à ce que leur logiciel ne comporte pas de code de LL ou de bibliothèques assujettis à une obligation réciproque de licence.

De même, les organisations et les entreprises qui diffusent leur code en tant que LL devraient également effectuer des vérifications de diligence raisonnable. Bien qu’elles appliquent déjà une licence de LL, l’obligation réciproque de licence exige généralement que soit octroyée une licence au titre de la même licence. Par conséquent, la diffusion du code en vertu d’une autre licence de LL peut ne pas toujours être conforme. Il peut être nécessaire d’accorder deux licences à votre propre code en vertu de l’autre licence réciproque ou, comme dans le contexte des logiciels propriétaires, de veiller à ce que le logiciel ne comporte pas de code ou de bibliothèque qui fait que l’obligation réciproque entre en jeu. Bien que les obligations réciproques présentent l’ensemble de paramètres plus stricts, les organisations et les entreprises doivent également veiller à ce qu’elles respectent les autres conditions de la licence. Par exemple, elles doivent se conformer aux exigences relatives aux avis et aux obligations de distribution du code source original. Une vérification de diligence raisonnable permet de s’assurer de la présence de cette conformité.

Il existe deux méthodes générales pour effectuer une vérification de diligence raisonnable : la vérification de la provenance et la numérisation des codes.

Vérification de la provenance

La vérification de la provenance consiste à maintenir une piste de vérification minutieuse, c’est-à-dire que les développeurs tiennent des dossiers internes sur le code qui se trouve dans le projet, la façon dont ce code est utilisé et la licence qui s’applique à chaque élément. Certains développent des outils d’automatisation comme Maven (que les développeurs utilisent pour automatiser la compilation et le déploiement des codes) à des fins d’assistance de la fonctionnalité dans le but d’indiquer, de suivre et de signaler les licences dans un projet, pour ainsi faciliter et normalise la tenue de dossiers.

En examinant les dossiers de vérification interne, un expert en licences peut vérifier la conformité d’un projet, que ce soit lorsqu’un développeur ajoute un nouvel élément externe ou lors de la diffusion du logiciel (ou les deux). Une nouvelle analyse juridique du texte de la licence n’est pas requise pour chaque nouvelle bibliothèque importée dans un projet. Une fois qu’un gestionnaire de licence approuve l’utilisation d’une licence particulière dans le cadre d’un projet, les développeurs peuvent généralement utiliser en toute sécurité d’autres bibliothèques sous la même licence, pourvu qu’ils les utilisent de la même façon. Par exemple, une entreprise ou une organisation peut élaborer une politique à l’égard d’un projet qui accorde l’approbation automatique de licences permissives particulières, notamment BSD, MIT et Apache, approuve des licences réciproques faibles, notamment la LGPL au cas par cas, et approuve des licences réciproques fortes, notamment la GPL, mais uniquement après une analyse juridique attentive et exhaustive.

Analyse automatisée du code

Dans bien des cas, la vérification de la provenance devrait être suffisante pour les petits projets. Toutefois, cela peut se révéler peu pratique pour les grandes entreprises ou les grands projets. Une grande entreprise possède souvent des codes acquis d’autres parties ou des codes obtenus à la suite d’acquisitions et de fusions, qui peuvent ne pas faire l’objet d’une vérification de licence précise. Dans ce cas, il est préférable d’utiliser des outils de numérisation automatisée des codes qui font une recherche dans toute la base de codes pour déterminer les licences qui s’appliquent. Les utilitaires de numérisation automatisée des codes recherchent des fichiers texte et des commentaires de code intégrés qui peuvent identifier la licence applicable à un élément particulier du logiciel. Certains outils comparent même le code lui-même au code de LL d’un tiers connu.

Bien que ces outils puissent se révéler très utiles, il faut garder à l’esprit que les résultats ne donnent pas la certitude que le code source relève uniquement des licences déclarées, ni qu’il est libre de droits d’auteur ou de contrefaçon de brevet. L’une des limites inhérentes de la vérification a trait au fait qu’elle ne peut comparer le code source du client qu’à une vaste collection, mais non exhaustive, d’autres dépôts de codes sources. Il se peut qu’elle ne détecte pas le code source protégé par le droit d’auteur des fournisseurs de logiciels propriétaires ou le code source des petits projets de LL. Dans la mesure du possible, les entreprises et les organisations peuvent également réduire leurs risques et faciliter la tâche de vérification en utilisant les bibliothèques de logiciels d’organisations fiables qui ont déjà vérifié le code de la bibliothèque.

Gestion des brevets

Toutes les considérations juridiques relatives aux LL qui s’appliquent lorsque vous utilisez des LL s’appliquent également lorsque vous diffusez ceux-ci. L’absence d’avertissement et de garantie peut jouer en votre faveur dans le cas des logiciels que vous diffusez. L’absence d’un choix de tribune ou d’une clause de droit crée une incertitude juridique égale pour toutes les parties. En plus de ces questions juridiques, la diffusion de LL soulève des préoccupations liées aux brevets. En accordant une licence pour votre code en vertu d’une licence de LL, vous pouvez, implicitement ou explicitement, délivrer une licence pour les brevets que vous possédez si l’un des codes les concerne. Il est important de comprendre la nature et la portée des licences de brevet que vous accordez.

Portée de la licence de brevet

Le traitement des brevets varie considérablement d’une licence de LL à l’autre. Traditionnellement – comme on le constate encore dans le cas des licences permissives populaires telles que BSD et MIT – la licence de brevet est implicite : aucune mention relative à un brevet n’y apparaît. On y énonce plutôt que le droit d’utilisation du logiciel accorde implicitement l’autorisation au licencié d’« utiliser » tout brevet pertinent détenu par le concédant. Une licence implicite accorde certainement à d’autres le droit d’utiliser le code original tel qu’il a été distribué, y compris lorsqu’une telle utilisation tient compte d’un brevet détenu par le concédant. Toutefois, la portée d’une licence implicite devient moins claire lorsque les parties en aval modifient le code original. Lorsque les modifications touchent l’« utilisation » prévue du logiciel, la licence de brevet d’origine couvre-t-elle toujours une utilisation qui est différente de ce que la licence avait prévu à l’origine? Si une nouvelle utilisation contrevient à un brevet différent détenu par le concédant original, est-ce que l’octroi de droits étendus d’apporter des modifications va jusqu’à accorder une licence à cet autre brevet? Il est fort probable que la réponse à ces deux questions soit « non », c’est-à-dire que la concession implicite de brevet ne couvre souvent que les utilisations qui sont concernées par les contributions d’origine du concédant, mais pas les autres utilisations que pourraient comporter d’autres caractéristiques et modifications. La plupart des licences modernes de LL tentent d’accroître la clarté et la certitude juridique en rendant explicite cette limitation de la portée. Par exemple, la licence d’Apache version 2.0 prévoit ce qui suit :

Sous réserve des dispositions de la présente licence, chaque contributeur vous accorde par la présente une licence de brevet perpétuelle, de portée mondiale, non exclusive, exempte de frais et de redevances et irrévocable (sauf stipulation contraire à la présente section) pour l’exécution par ou pour vous, l’utilisation, l’offre d’aliénation, l’aliénation, l’importation ou la cession des travaux, étant précisé que ladite licence ne s’applique qu’aux revendications assujetties au régime de l’autorisation par lesdits contributeurs en raison de contrefaçons consécutives à leur seule contribution ou à la fois à leur contribution et aux travaux ayant fait l’objet de ladite contribution.

En vertu de cette clause, la licence de brevet ne s’applique qu’aux utilisations des logiciels applicables aux contributions existantes. Lorsque d’autres contributions en aval modifient l’utilisation du logiciel, la licence de brevet d’origine peut ne plus s’appliquer.

Bien qu’une licence de LL puisse accorder une licence de brevet plus étendue qui couvrirait les modifications en aval, aucune licence populaire n’adopte actuellement cette approche. Même la licence GPLv3, qui revendique une grande liberté, ne permet pas une telle concession. Étant donné le nombre presque illimité de façons dont des caractéristiques supplémentaires pourraient modifier l’utilisation typique d’une application logicielle, une licence aussi étendue est probablement insoutenable pour la plupart des entreprises qui gèrent un portefeuille de brevets.

Par conséquent, à titre de pratique exemplaire, vous devez, chaque fois que vous modifiez un LL, déterminer si les modifications visent l’utilisation du logiciel d’une manière qui pourrait faire appel à d’autres licences de brevet ou faisant en sorte que les licences de brevet existantes ne couvrent pas la nouvelle utilisation.

Clauses de résiliation de brevet et de représailles

De nombreuses licences de LL tentent de protéger le logiciel contre les poursuites pour contrefaçon de brevet en incluant des clauses de résiliation automatique. Ces clauses s’appliquent chaque fois qu’un titulaire de licence allègue qu’une partie du logiciel viole son brevet. Par exemple, la licence Apache version 2.0 énonce succinctement ce qui suit :

Lorsque vous entreprenez une procédure relative à un brevet contre une entité (notamment une demande entre défendeurs ou une demande reconventionnelle) faisant valoir que les travaux ou qu’une contribution intégrée dans les travaux constitue une contrefaçon de brevet directe ou une complicité de contrefaçon, alors toutes les licences de brevet qui vous ont été octroyées au titre de la présente licence à l’égard des travaux sera résiliée dès le moment où ladite procédure est entreprise.

Les éléments déclencheurs de la résiliation varient d’une licence à l’autre. Par exemple, contrairement à la licence Apache version 2.0, la version 2 de la licence publique Mozilla (MPLv2) permet explicitement aux parties de se défendre par des demandes reconventionnelles et des demandes entre défendeurs de contrefaçon de brevet, sans pour autant que ne soit mise en application la clause de résiliation.

Certaines licences comportent également des clauses de représailles étendues, c’est-à-dire une résiliation plus étendue des droits. La clause de résiliation du brevet de la version 2.0 d’Apache, énoncée ci-dessus, ne met fin qu’aux licences de brevet. Par contre, la MPLv2 met fin à tous les droits en vertu du droit d’auteur et du droit des brevets. Lorsque l’on est confronté à une procédure relative à la contrefaçon d’un brevet, qu’il s’agisse d’une action initiale ou d’une demande reconventionnelle, il est important d’évaluer soigneusement l’incidence que cela pourrait avoir sur tout LL que vous utilisez ou auquel vous contribuez.

Gestion des risques juridiques

Absence de garantie

Une garantie est une assurance donnée par un fournisseur qu’un produit fonctionnera comme promis et sans défaut. Une garantie peut aussi comporter l’assurance qu’un produit est exempt de contraintes juridiques, comme une propriété intellectuelle non autorisée qui peut appartenir à des tiers (c.-à-d. une garantie d’absence de contrefaçon). Selon les modalités de la garantie, lorsqu’un produit ne respecte pas les garanties, le client peut demander que le fournisseur répare le produit, le rembourse ou lui verse une compensation monétaire.

Compte tenu de l’absence typique de garantie dans une licence de LL, il devient plus impératif pour une entreprise ou une organisation gouvernementale d’obtenir des contrats de soutien externe. Une entreprise de services de soutien de LL qui connaît bien les logiciels peut aider à résoudre les problèmes et, surtout, à corriger directement les bogues qui surviennent.

Certaines entreprises de services de soutien contribuent également à atténuer les risques qui peuvent survenir en raison de l’absence d’une garantie d’absence de contrefaçon. Par exemple, Red Hat offre à ses clients le Red Hat Open Source Assurance Program et Canonical propose l’Ubuntu Advantage Assurance. Ces deux programmes offrent des services de remplacement de toute partie de leurs distributions Linux respectives (Red Hat et Ubuntu) qui porterait atteinte aux droits de propriété intellectuelle d’autres parties. De plus, ces programmes offrent également d’indemniser les clients contre toute poursuite intentée à la suite de telles violations de la propriété intellectuelle.

Avis de non-responsabilité et d’absence d’indemnisation

Lorsqu’une licence ou un contrat ne contient pas d’avis, le titulaire de permis peut habituellement tenir le concédant civilement responsable des pertes subies en raison de toute négligence dans la conception, la mise en œuvre ou la mise à l’essai du logiciel. En outre, quand un concédant accepte de verser une indemnisation au titulaire de la licence, si une autre partie (souvent un client du titulaire de la licence) intente une poursuite en dommages-intérêts et que la cause des dommages peut être associée au logiciel du titulaire de licence original, c’est le titulaire de la licence qui soit en définitive payer les dommages.

Toutefois, compte tenu de l’avis de non-responsabilité et d’absence d’indemnisation dans une licence de LL, les organisations et les entreprises ne peuvent pas transférer au fournisseur leurs risques en matière de responsabilité civile. L’avis de non-responsabilité signifie qu’il est généralement impossible d’obtenir une indemnisation auprès du fournisseur pour les dommages causés par des problèmes liés au logiciel. L’absence d’indemnisation signifie que si d’autres parties subissent des pertes en raison de problèmes liés à l’utilisation du logiciel, vous risquez d’être tenu responsable et vous ne pouvez pas transférer ce risque au fournisseur du logiciel original.

Dans l’ensemble, les clauses d’indemnisation des licences de logiciel exclusif fonctionnent de la même façon que l’assurance, c’est-à-dire qu’elles couvrent les pertes en cas de poursuite intentée par des tiers. Par conséquent, en ce qui concerne les LL, les entreprises et les organisations peuvent envisager l’assurance comme solution de rechange à une clause d’indemnisation. Au lieu que ce soit le fournisseur de logiciels qui contracte une assurance en responsabilité juridique, un assureur fait la même chose.

Aucun choix de droit ou d’instance

Il existe une autre différence que les utilisateurs de LL ne devraient pas oublier : les licences de LL comprennent rarement de clause de compétence législative ou de clause attributive de compétence. Les licences exclusives peuvent préciser que les tribunaux doivent interpréter la licence et résoudre les différends en vertu des lois d’un pays ou d’une juridiction en particulier (clause de compétence législative) et que les poursuites doivent être entendues par les tribunaux d’une juridiction en particulier (clause attributive de compétence). Lorsque ces règles ne sont pas précisées dans les licences de LL, les tribunaux appliquent des règles standard sur les conflits de lois pour déterminer la loi appropriée et la compétence pertinente dans un contexte particulier. Cette situation accentue l’incertitude quant à d’éventuelles poursuites nécessaires dans un pays étranger ou en vertu de lois inconnues, ce qui entraînerait des frais juridiques plus élevés.