Gérer des licences différentes

Gérer des licences différentes Harmonie mar 13/06/2017 - 16:20

L'élément déclencheur des licences

L'élément déclencheur est l'action provoquée par le licencié qui le soumettra aux obligations prévues par la licence accompagnant l'œuvre.

Pour la majeure partie des licences libres, l'élément déclencheur est la distribution.

Ainsi, la situation est assez simple pour la plupart des œuvres « classiques ». L'élément déclencheur est une communication directe (par représentation) ou indirecte (par reproduction) de l'œuvre par le distributeur de celle-ci. La situation est différente en matière de logiciel, puisqu'il est possible de ne communiquer que la fonction du logiciel sans distribuer l'objet soumis au droit d'auteur (le code objet ou le code source).

Par ce biais, et puisque le droit d'utiliser le logiciel est délivré totalement et sans contrepartie (c'est-à-dire sans respecter la licence), l'utilisateur d'un logiciel soumis à une licence libre contraignante (type GNU GPL) peut parfaitement se dispenser de communiquer le code source du logiciel qu'il utilise en interne pour fournir les services aux utilisateurs. (Puisqu'il ne distribue pas directement le logiciel à l'utilisateur, il ne déclenche pas la licence.)

De nombreuses critiques avaient amenées la FSF à concevoir collaborativement l'Affero GPL, voire même de projeter d'inclure cette spécificité dans la GNU GPL v3. Néanmoins, cette idée ne fut pas retenue.

Certaines licences s'acquittent parfaitement de ce mode d'utilisation. L'Open Software License (OSL), par exemple, assimile l'utilisation en réseau à une distribution en soumettant ainsi cette utilisation à une obligation de livrer le code source à la communauté...

Voici donc le premier élément à prendre en considération pour percevoir les obligations auxquelles nous sommes contraints.

La portée d'une licence et ses limites

La portée de la licence est en fait l'étendue délimitant l'œuvre, ou les œuvres, soumise(s) aux contraintes de la licence.

Le caractère « copyleft » figure donc parmi ces contraintes puisqu'il s'agit plus précisément de l'obligation de redistribuer sous la même licence. En présence de licence ayant une étendue/portée très large, le caractère copyleft de la licence augmente le risque de se trouver dans un cas de superposition de plusieurs licences différentes, (en cas de combinaison de projets libres notamment).

Cette portée varie en fonction des licences, voire parfois des différentes législations qui ont parfois des spécificités relatives au droit d'auteur. Ainsi en France, l'œuvre composite et l'œuvre dérivée délimitent l'étendue du contrôle que possède un auteur sur son œuvre.

Cette question est d'autant plus complexe car les logiciels libres sont souvent composés de plusieurs briques logicielles, qui peuvent avoir des licences différentes. Dans un logiciel, il y a plusieurs fichiers différents. ( Anecdote : une des bonnes pratiques du Libre consiste à faire en sorte qu'il n'y ait qu'une seule licence par fichier pour simplifier le travail.)

Le logiciel va être liée à une (ou plusieurs) bibliothèque logicielle. L'étendue de la licence va notamment permettre de savoir si les bibliothèques liées au logiciel sont comprises ou non dans la portée de la licence.

Lorsqu'un projet comprend deux logiciels relativement indépendants mais fonctionnant de concert sous deux licences  « contraignantes » différentes, les obligations de ces deux licences « contraignantes » se superposent lorsque leur code est mêlé. Dans un contexte de superposition ou de confusion, la recherche d'une compatibilité entre ces différentes licences doit être faite.

Des contraintes provoquées par la collision entre licences libres

Une étendue spécifique est propre à chaque licence : celle-ci peut parfois couvrir des briques logicielles elles-mêmes couvertes par d'autres licences. Le licencié se trouve alors devant une situation la distribution doit être compatible avec toutes les obligations de chacune d'entre elles.

Cela s'avère parfois impossible, puisque l’on n’est pas en mesure de respecter les différentes licences, et cela aura pour conséquence d’interdire la redistribution du tout (étant donné que pour redistribuer, il faut respecter toutes les licences).

Ces questions se posent surtout en présence de licences de type copyleft puisque l’obligation de distribution sous ces licences devient problématique en cas d’intégration d’autres briques de codes sous d’autres licences dans un même projet.

L'idée à retenir est que le licencié ne doit pouvoir distribuer que  :

→ s'il ne concède pas plus de droits que ce que les licences lui permettent ;

→ s'il répond à l'ensemble des obligations que les licences comprennent.

Il s'agit donc d'un équilibre entre les droits et les obligations octroyés par les licences utilisées.

Lorsque les licences semblent irrémédiablement inconciliables, la solution consiste à contacter directement les auteurs pour leur suggérer de changer ou modifier leur licence afin de permettre cette utilisation. Cette approche peut toutefois être considérée comme plus complexe et contre-productive, car elle est moins adaptée aux particularismes du Libre (en particulier lors d'une multiplicité des auteurs) en créant des exceptions allant à l'encontre même du principe de contrat-type de licence libre.

En revanche, ce dialogue avec les auteurs élargit le champ d'application de la licence visée et donc éventuellement de débloquer d'autres situations futures lors de l'élaboration de logiciels tiers similaires ou complémentaires.

L’accumulation des licences, une gêne à la distribution de l'œuvre

L'accumulation de licences emporte un alourdissement des contraintes pesant sur le licencié en risquant la diffusion du tout. Notamment lorsque les diverses licences interdisent très largement l'utilisation de certains termes, ou s'immiscent dans la publicité qui serait faite autour du logiciel, etc. .

Un travail préliminaire permet de visualiser l'ensemble des contraintes et d'adapter son exploitation des logiciels en fonction. Néanmoins, il peut être nécessaire de contacter les auteurs (par échange d'e-mails par exemple) pour minimiser ou atténuer certaines conditions très contraignantes.

L’accumulation de licences et le multilicenciement ne sont pas des termes synonymes.

En cas de multilicenciement l’auteur laisse à l’utilisateur le choix entre différentes licences prédéterminées pour faciliter la diffusion de son travail ; l’utilisateur sélectionnera la licence la plus adaptée à son projet parmi celles proposées.

Publier sous plusieurs licences évacue certains problèmes de compatibilités entre licences, justement en laissant un choix de licence à respecter.

Compatibilités de licences

Compatibilités de licences Harmonie mar 13/06/2017 - 16:29

Qu’est ce qu’une incompatibilité ?

Pour bien comprendre ce qu’est la compatibilité, un préalable est de comprendre les cas où on se trouve face à une incompatibilité de licence.

L’incompatibilité entre deux licences survient lorsque qu’il est impossible de remplir toutes les obligations qu’imposent les licences auxquelles sont soumises l’œuvre.

Par exemple, en présence de plusieurs licences sous lesquelles les différentes briques de code sont distribuées, et doivent être fusionnées pour pouvoir être distribuées à leur tour dans un projet logiciel plus grand.

Le licencié se trouve dans une situation où il ne peut pas respecter les deux — ou plusieurs autres — licences en même temps.

Étant donné que le licencié n’arrive pas à remplir l’ensemble de ses obligations, cela aura pour conséquence de rendre impossible la distribution du code ainsi fusionné.

Le multilicenciement peut être une solution pour évacuer les problèmes d’incompatibilité entre licences en laissant le choix au licencié de choisir la licence qu’il devra respecter pour pouvoir utiliser l’œuvre.

Certaines licences comportent des clauses de compatibilité expresse avec d’autres licences pour éviter ces problèmes.

La compatibilité une voie à sens unique


On pourrait définir la compatibilité comme étant la caractéristique qu’ont deux licences (ou plus) sous lesquelles du code est distribué, à pouvoir être réunies ensemble, en vue d’être distribuées dans une création logicielle plus grande.

Mais cette définition ne prend pas en compte le résultat de la combinaison des contributions sous les différentes licences et revient à donner une fausse image de réciprocité.

La compatibilité des licences libres est donc habituellement un chemin à sens unique.

Par exemple, la licence BSD est compatible avec la GPL, au sens où du code distribué sous licence BSD pourra être ajouté à un programme distribué sous GPL. Mais la GPL n’est pas compatible avec la BSD, un code sous GPL ne pourra pas être ajouté à un programme distribué sous BSD.

Il arrive parfois que des licences soient réciproquement compatibles, mais ce n’est pas le cas général. (La BSD est compatible avec la MIT, et la MIT est compatible avec la BSD.)

La compatibilité entre licences qui se superposent

Dans une situation de chevauchement des licences, une compatibilité doit être recherchée, puisque le licencié est aussi bien contraint à l'une qu'à l'autre des licences. Deux compatibilités existent, la première se trouve à la lecture des licences, et la seconde à leur examen.

La compatibilité expresse

De plus en plus les rédacteurs de licences libres viennent à prendre conscience que leur licence n'est ni la seule, ni même l'unique licence libre légitime. Fleurissent alors les clauses de compatibilité expresses qui permettent de relicencier l'œuvre soumise sous plusieurs autres licences.

Le relicenciement peut être inconditionné, ou soumis à la présence d'autres licences.

Ce qui est notamment le cas de  l'EUPL : « Clause de compatibilité : Si le Licencié distribue ou communique des Œuvres Dérivées ou des copies de celles-ci basées à la fois sur l'Œuvre Originale et sur une autre œuvre concédée en licence selon les termes d'une Licence Compatible, la Distribution et/ou Communication peut se faire sous les termes de cette Licence Compatible ».

La compatibilité logique

Deux principes gouvernent la compatibilité entre licences, et contrats :

  • on ne peut donner plus de droits que l'on en possède (ainsi, une personne qui passe du statut de licencié à celui de concédant, tire ses droits de la première licence et est donc limité par celle-ci).
  • on ne peut pas contraindre à moins d'obligations que ce à quoi on est contraint nous même

En dehors des cas de licence copyleft (qui imposent la redistribution sous la même licence, et donc qui confèrent des droits identiques), il est toujours possible de ne conférer qu'une partie des droits dont on dispose.

Si l’on ne transmet pas tous les droits, le nouveau licencié aura alors des droits moins étendus sur l’œuvre modifiée que ce que la personne redistribuant l’œuvre n’en possédait sur l’œuvre d’origine.

D'un point de vue juridique, la condition de compatibilité est atteinte si l'ensemble des droits accordés par la licence absorbante B est inclus dans l'ensemble des droits conférés par la licence compatible A et que l'ensemble des obligations imposées par la licence compatible A est inclus dans l'ensemble des obligations imposées par la licence absorbante B.

Avec ces idées en tête, il suffit de lire attentivement les diverses licences pour retrouver les divergences et les accointances.

Tableau de compatibilité entre licences

Tableau de compatibilité entre licences Harmonie mer 23/08/2017 - 16:01
tableau de compatibilité entre licences

Les solutions possibles afin d'éviter les incompatibilités

Les solutions possibles afin d'éviter les incompatibilités Harmonie mar 13/06/2017 - 16:44

Que l'on veuille distribuer son logiciel sous une licence libre ou que l'on cherche simplement à respecter les termes de licences auxquelles nous sommes soumis, différents critères « techniques » doivent être pris en considération :

Les briques logicielles : est-ce que le logiciel est destiné à être utilisé par d'autres logiciels, ou peut-il l'être ?

Utilisation par le réseau : est-ce que le logiciel est destiné à être utilisé comme un service — c'est-à-dire que ses fonctionnalités sont distribuées par le réseau sans que le logiciel le soit lui-même ?

En répondant à ces questions, il peut arriver que plusieurs licences se chevauchent sans possibilité de les respecter toutes en même temps, l'incompatibilité des licences engendre alors une interdiction de de distribution voire de simple mise à dispositin de l'ensemble. Heureusement, une panoplie de solutions existe pour éviter ces situations bloquantes.

Les multilicences

Les multilicences Harmonie mar 13/06/2017 - 16:51

Cet article répond à des questions qui furent posées sur le multilicenciement et tente de tracer rapidement les grands axes de ce mécanisme. Il est issu en grande partie de l'étude juridique de Benjamin Jean portant sur la compatibilité entre contrats, et d'autres articles qui furent rédigés en leur temps sur la compatibilité entre la LAL et la CC-By-SA.

Le multi-, ou dual-, licenciement est l'une des solutions fréquemment avancées pour résoudre les conflits absurdes, et abscons, d'incompatibilités qui surgissent de toute part au sein des communautés du Libre (des licences copyleft identiques dans leur effet, imposent la redistribution de l’œuvre dérivée sous cette même licence et sont alors incompatibles elles, ce qui est contre productif).

Comment fonctionne le multilicenciement ?

Contrairement à ce que beaucoup semblent croire, le multilicenciement se trouve être une technique simple et efficace. Il consiste pour le titulaire des droits à consentir plusieurs licences non exclusives sur une même œuvre : technique habituelle au sein des licences classiques que rien n'interdit de transposer aux licences libres afin de les cumuler ou de les rendre alternatives.

À quoi ça sert ?

Le licencié aura alors le choix parmi les licences proposées par le donneur de licence, celui-ci pourra utiliser ses droits en conformité avec l’une ou l’autre des licences.

Plusieurs avantages peuvent être mis en avant :

- Le contenu sous licence est dès lors compatible avec la totalité des licences qui lui sont adjointes, (Le contenu d'une œuvre sous triple licence peut ainsi valablement être repris et inséré dans une œuvre sous licence simple, double ou triple.) auxquelles se rajoutent les licences avec lesquelles elles sont déjà elles-mêmes compatibles. Une faille existe cependant : si des contributions lui sont apportées sous une seule des licences, alors l'œuvre nouvelle devra limiter à cette seule licence. Ainsi, un tel mécanisme n'est viable qu'autant que l'ensemble des contributions se fasse sous licence multiple, quitte à ce que le donneur de licence s'inspire d'éventuelles contributions ultérieures pour les réécrire lui-même dans son œuvre. En dépit de cette relative précarité, le dispositif de multilicenciement assure une meilleure compatibilité que l’usage d’une seule licence.

- Le licencié dispose de beaucoup plus de droits dès lors qu'ils sont conférés par au moins l’une des licences. (Il faudra se conformer aux obligations de la licence qui les accordent pour disposer des « droits supplémentaires » en question.) En quelque sorte, le multilicenciement permet d'ajouter une liberté au licencié qui est celle du choix de la licence à laquelle il se soumet, même si ce choix est limité.

- Le multilicenciement permet de limiter le copyleft global qui s'applique à l'œuvre. Le licencié peut utiliser tout droit compris dans l'une au moins des licences, ce sont les dispositions de la licence la plus permissive qui l'emportent.

- Si l'une des licences devait être annulée par une juridiction nationale, le licencié pourrait toujours revendiquer les droits conférés par l'une des autres licences proposées.

Pour finir, cette stratégie — à laquelle certains pouvaient préférer une licence très permissive comme la licence BSD — a l'avantage de cumuler copyleft et compatibilité.

Quand est-ce utile ?

Le multilicenciement est un remède qui peut être utilisé à bon escient par les auteurs afin de pallier les discordes entre les différentes communautés, en versant ainsi — toujours sous licences copyleft — dans divers pots communs.

Mais les doubles licences sont particulièrement intéressantes lorsqu'il s'agit de limiter par la même occasion la portée de l’une des licences : une double licence MPL/GNU GPL permet d'appliquer les deux licences, ou l'une au choix, dans les limites d'un copyleft standard. Par exemple, la double licence GFDL/LAL est un bon choix lorsque l'œuvre concernée est autre chose qu'une simple documentation de logiciel et qu'elle a vocation à être utilisée conjointement avec d'autres œuvres sous licences différentes (la GFDL disposant d'un copyleft fort, calqué sur la rédaction de la GNU GPL).

Quand est-ce inutile ?

Par soucis de compatibilité, certains développeurs ont tendance à cumuler les licences pour un même projet. Mais les licences multiples ne sont véritablement utiles que si elles permettent d'associer plusieurs licences qui sont originairement incompatibles.

Dans le cas contraire, la licence compatible « contenant » déjà la seconde licence, la réunion des deux ne confère ainsi aucune prérogative spéciale au licencié : la réunion d'un ensemble avec un autre qui lui est inclus est égale au premier ensemble.

L'atout des licences multiples est en revanche indéniable lorsqu'il s'applique à plusieurs licences incompatibles tendant au même but. Les communautés peuvent alors ajouter leur force pour développer un logiciel en commun, le travail de l'une profitant à l'autre : c'est en quelque sorte un retour aux sources du libre, en construisant des ponts pour relier deux communautés qui se sont éloignées.

N'y a t'il pas d'autres solutions ?

Pour l'instant : non. En choisissant une licence copyleft, l'auteur peut être certain que la licence sera incompatible avec une autre ; en choisissant une licence permissive, l'auteur s'assure d'une relative compatibilité, mais sans que soit pour autant garantie la liberté de son œuvre.

Exemples de multilicenciement

Exemples de multilicenciement Harmonie mer 23/08/2017 - 16:26

Les exemples sont nombreux dans l'histoire du Libre, et quelques-uns seulement furent cités, mais il est possible de citer — à notre échelle — la double licence que nous fûmes amenés à conseiller.

DéKiBulle< est un logiciel « modulaire » en ce qu'il emprunte ces fonctionnalités à diverses autres briques logicielles, toutes sous des licences différentes (Apache, GNU GPL, etc.). Ces licences étaient manifestement incompatibles et aucune issue ne pouvait ressortir des contrats. La première phase fut donc de contacter l'auteur de la brique sous GNU GPL afin de lui proposer une exception sur son logiciel, ou une nouvelle licence avec un copyleft moins fort. La seconde étape fut de trouver une licence qui permet de maximiser la réutilisation, la distribution, et les contributions au logiciel libéré. Une licence avec un copyleft standard semblait donc nécessaire. Les possibilités sont alors multiples, et il fallait faire un choix : afin d'ouvrir un maximum de portes et d'en fermer un minimum, nous choisîmes la double licence CeCILL-C/GNU LGPL. La LGPL était un passage obligé pour ouvrir à un maximum de contributions, la CeCILL-C était l'assurance d'une licence très facilement compréhensible (elle est très inspirée de la MPL), un copyleft parfaitement défini, et la certitude d'une conformité à la loi française.

Dans ce cas précis, le choix d'une double licence CeCILL-C/GNU GPL aurait été sans conséquence en matière de droits accordés à l'utilisateur : la CeCILL-C étant la plus permissive des licences évoquées, elle définit la portée du copyleft aux dépens de la GNU GPL. L'utilisation de la GNU LGPL en lieu et place de la GNU GPL assure toutefois la compatibilité avec une licence supplémentaire — GNU LGPL/GNU GPL/CeCILL-C/CeCILL.

Pour conclure, le choix d'une double licence peut être nécessaire dans certaines situations, comme il peut être volontaire dans le but d'ouvrir un maximum de potentialités à son œuvre.

Le mécanisme de multilicence concerne-t-il uniquement les licences libres ?

Le mécanisme de multilicence concerne-t-il uniquement les licences libres ? Harmonie mer 23/08/2017 - 16:27

Non, bien sûr : différent, mais impossible à passer sous silence, le cumul de licences FLOS et non-FLOS tend à se multiplier grâce au succès remporté par quelques grandes entreprises conceptrices de logiciels.

La technique consiste à allier les atouts des licences libres pour permettre le développement des logiciels, tout en proposant aussi des licences commerciales à ceux qui désirent dépasser les limitations et obligations des licences FLOS. Raisons pour lesquelles les licences FLOS choisies sont assez contraignantes pour les licenciés.

Trois sociétés illustrent tout à fait le propos : MySQL , Sleepycat Software Inc. et TrollTech AS. MySQL AB est passée de la GNU LGPL à la GNU GPL. Loin d'être neutre, ce changement de licence revient à imposer à tout programme auparavant non soumis à la GNU LGPL de se soumettre à la GNU GPL s'il désire bénéficier des versions postérieures. Dès lors, les titulaires de logiciels propriétaires acquirent des licences commerciales pour échapper à la réciprocité. D'un autre côté, la licence envisage une exception spéciale à la GNU GPL : l'exception FLOSS, qui permet aux autres logiciels FLOS (les licences sont listées dans l'exception) de se lier au programme sans avoir à passer en GNU GPL, ce qui aurait posé problème dans le cas de licences incompatibles. Bénéficiant d'un produit libre, la communauté FLOS permet le débogage du logiciel, ainsi que la soumission de contributions, intégralement réécrites par MySQL. Titulaire de l'ensemble des droits sur son œuvre, elle peut conserver la double licence, et de cette façon les partisans de systèmes propriétaires bénéficient, mais pas indûment — car sous forme de licence commerciale, permettant de financer d'autres contributions — d'un logiciel performant.

Sleepycat Software Inc. développe pour sa part Berkley DB (BSB), sous une licence spécifique qui ne permet son usage libre que si les logiciels l'utilisant distribuent aussi leur code source. L'utilisation de la double licence GNU GPL/QPL pour la bibliothèque TrollTech AS ne nécessite pas plus de développement, le fonctionnement étant toujours le même. Dans les deux cas, l'alternative reste de souscrire à une licence commerciale afin de s'affranchir des conditions de la licence libre dans un cadre propriétaire.

L'interprétation : l’usage de définitions

L'interprétation : l’usage de définitions Harmonie lun 07/08/2017 - 14:08

S'il est souvent plus simple de choisir la licence qui correspond au type de développement ou déploiement que l'on désire pour son logiciel, il peut aussi être opportun d'adapter une licence à ses attentes : en interprétant celle-ci (lorsqu'elle laisse place à interprétation), ou en ajoutant une exception, lorsque nécessaire.

Attention : ce mécanisme est particulièrement utile lorsqu'il consiste à conférer plus de droit, mais inversement désastreux lorsqu'utilisé dans l'autre sens pour limiter les droits puisqu'il fait perdre toute compatibilité à la nouvelle licence ainsi modifiée.

L'interprétation : l’usage de définitions, est une méthode sujette à caution, il ne peut y avoir d'interprétation d'une licence que dès lors qu'il y a source d'interprétation…

La licence ne pourra et ne devra être interprétée que si elle présente des éléments flous, ou peu clairs.

Il faut toujours garder à l’esprit que si la licence a des termes approximatifs, elle sera toujours interprétée en faveur du licencié.

La technique de l’interprétation permet de lever toute insécurité juridique en donnant expressément le sens qu'il faut donner aux termes litigieux. Il est inutile — voire déconseillé — de définir un terme qui n’a pas besoin de l’être.

Si l’on interprétait des termes alors qu’il n’y aurait pas lieu à interprétation, le licencié se trouverait face à une contradiction au sein du contrat qui le lie au concédant, situation qui risque de lui profiter in fine (et donc éventuellement d’aller à l'encontre de la volonté du concédant). En effet, la règle favorable à la personne qui se trouve devoir respecter deux termes contradictoires est habituellement retenue, annulant alors tous les effets recherchés par l'interprétation mise en place par le concédant.

Il faut reconnaître qu'une telle conséquence ne serait réellement dommageable au concédant que dans l'hypothèse où l'interprétation était restrictive, et non dans le cas contraire. Dans le cas où elle conférerait en effet plus de droits, elle prévaudrait naturellement, étant plus favorable au licencié (dans ce cas précis, la règle la plus favorable au licencié serait celle édictée par le concédant).

Le meilleur exemple de cette technique est l'interprétation< utilisée par Linus Torvalds< pour l'utilisation de la GNU GPL< sur le noyau Linux :

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it.

L'usage de licences copyleft ayant une étendue limitée (weak copyleft)

L'usage de licences copyleft ayant une étendue limitée (weak copyleft) Harmonie lun 07/08/2017 - 09:46

Parmi celles-ci, il faut distinguer celles qui permettent expressément cette utilisation de celles qui n'en ont que la conséquence.

Certaines licences copylefts permettent l’utilisation du logiciel sans étendre la licence pour autant.

La licence la plus symbolique dans ce genre est la GNU Lesser General Public License< (GNU LGPL) : elle ressemble en tout point à la GNU GPL<, à l'exception qu'elle permet expressément à un logiciel qui l'utilise de ne pas étendre la licence au logiciel utilisant (cf nouvelle LGPL<). Ainsi, seul le logiciel utilisé reste obligatoirement libre, et la liberté qui lui est attachée est indéniablement pérenne.

Le problème de ce type de licence est qu'elles ne définissent que l'on doit entendre par le terme d'« utilisation » et que, de fait, beaucoup de logiciels sont liés avec d'autres logiciels sous GNU LGPL< sans être réellement « utilisés », mais plus pour étendre la licence de ces derniers. Dans un tel cas de figure, une application stricte de la licence revient à accorder à celle-ci une étendue qui correspond à celle de la GNU GPL<.

Les licences modulaires sont finalement plus simples à utiliser.

L'utilisation en tant que service

L'utilisation en tant que service Harmonie lun 07/08/2017 - 14:12

De plus en plus de logiciels ont vocation à être installés sur une seule machine, le serveur, afin que quiconque puisse l'utiliser via Internet. C'est ce que l'on appelle « Architecture orientée services » (en Anglais, "Service Oriented Architecture", SOA), ou bien « Fournisseur de service d'application » (en Anglais, "Application Service Provider", ASP). Dans une telle situation, le problème vient du fait que presque toutes les licences ne deviennent contraignantes qu'au moment où le logiciel est distribué, or il ne l'est pas lorsque seules ses fonctionnalités sont accessibles à l'utilisateur : en effet, l'objet de la protection, code source, objet, etc., reste sur le serveur, et donc les modifications apportées aussi.

Partant de ce constat, beaucoup d'entreprises ont pu se servir de ce que l'on a nommé « l'ASP loophole» pour utiliser à profusion des logiciels libres qu'elles ont modifiés sans jamais en redistribuer les sources. D'autres, comme Affero, décidèrent au contraire qu'elles voulaient que la pérennité de la GNU GPL s'étende lors de l'utilisation par le réseau. Plusieurs solutions furent envisagées, les plus populaires restant le choix de l'Affero GPL et de l'OSL.

L'Affero General Public License et l'interaction par réseau distant (« Remote Network Interaction »)

L'idée fondatrice de l'Affero GPL est de se baser sur une GNU GPL suffisamment modifiée pour appréhender l'utilisation par le réseau, mais suffisamment proche de sa grande sœur pour lui rester compatible. Elle lui est donc en tout point identique, à l'exception près que si un licencié modifie le logiciel, il doit donner accès au code aux utilisateurs du service afférent (article 13).

Ainsi, la clause rajoutée a le bénéfice de la souplesse (je n'ai pas à distribuer ainsi un logiciel non modifié — ce qui ne serait de toute façon pas forcément utile), aux dépens d'un risque de contrefaçon : son absence d'automaticité pourrait inciter les développeurs à nier leur modification (ou les considérer comme indépendantes et séparées du programme) afin de ne pas avoir à distribuer le logiciel modifié. Cette contrefaçon serait en plus indécelable puisqu'elle ne pourrait être attestée qu'au moment de la distribution...

La solution retenue par l'Open Software License

Auparavant, et beaucoup plus simplement, Lawrence Rosen avait ingénieusement assimilé dans l'écriture de l'Open Software License la mise à disposition par le réseau ("external deployement") en une distribution. Ainsi, autant la distribution du logiciel que sa mise à disposition par le réseau induisent l'application de la licence, et donc l'obligation de distribuer le code source aux côtés de la licence et des droits afférents. D'autres licences reprirent ensuite cette idée, telle l'APL.

La situation des logiciels destinés à être utilisés par un autre logiciel

La situation des logiciels destinés à être utilisés par un autre logiciel Harmonie lun 07/08/2017 - 09:25

Tout logiciel libre peut-être utilisé par d'autres logiciels, libres ou non, selon sa licence.

Néanmoins, certaines licences nécessitent que le logiciel utilisateur soit lui-même soumis à cette même licence. Cette transmission forcée de la licence est appelée copyleft. Et si cette contrainte peut être délibérée, (voire conseillée pour des raisons philosophiques,) afin de « forcer » la liberté des logiciels tiers, il a une répercussion très négative lorsque lesdits logiciels tiers sont déjà sous une licence libre dont les termes ne sont pas compatibles (ou bien si plusieurs briques sous des licences copyleft non compatibles sont réunies dans un même logiciel tiers).

Les logiciels libres étant réputés pour leur modularité, il fallut trouver des licences qui leur correspondent. Ainsi, plusieurs licences permettent au logiciel sur lequel elles portent d'être utilisé sans contraintes par d'autres, comme la LGPL ou la licence MPL.

Globalement, il faut mieux éviter l'utilisation de licence à strong copyleft au profit de licence à weak copyleft ou permissive pour les situations où les logiciels sont destinés à être utilisés par d'autres pour éviter la superposition de licences.

NB: le nom original de LGPL était Library GNU Public License, puisqu'elle était explicitement faite pour les bibliothèques logicielles, avant d'être renommée Lesser GNU Public License.

La technique de l'exception

La technique de l'exception Harmonie lun 07/08/2017 - 14:12

L'idée de l'exception est bien de modifier la licence de base, en ajoutant dans une clause distribuée avec la licence (ou inscrite dans les en-têtes) qui déroge aux termes de la licence de base.

Ici, à la différence de l'interprétation, cette clause additionnelle peut être supprimée lors d'une redistribution si elle confère plus de droits au licencié, en l'absence de stipulation contraire.

La clause additionnelle ne pourra pas être supprimée si elle impose des obligations supplémentaires (faisant de ce tout une nouvelle licence incompatible avec la licence de base).

Les licences modulaires

Les licences modulaires Harmonie lun 07/08/2017 - 14:07

Les premières licences modulaires apparues sont probablement la NPL (non libre) et la MPL, utilisées respectivement par Netscape et Firefox. Contrairement aux licences précédentes permettant l'utilisation, ces licences ont l'énorme avantage d'envisager une étendue « objective » des termes des licences.

Ainsi, celle-ci est le plus souvent limitée aux seuls fichiers contenant du code sous ladite licence. Pour l'exemple, tout fichier contenant du code sous MPL devra lui-même être licencié sous licence MPL (le critère est identique pour la licence française CeCILL-C, ou d'autres licences calquées sur la MPL comme la Nokia Public License).

En pratique l'utilisation de ce type de licences facilite énormément le développement de logiciels modulaire, mais multiplie aussi le nombre de licences qui peuvent porter au final sur un seul logiciel.