Les licences open source permettent-elles la réutilisation du code ?
Cet article a été publié il y a 15 ans 9 mois 1 jour, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.Comme le disais Joan sur un commentaire tout récent : « C’est incroyable l’écho qu’à cette fausse idée selon laquelle un logiciel open source serait simplement un logiciel dont on peut lire les sources mais pas les modifier… ». Je vais donc tenter defaire ici un article didactique pour éclaircir ce point en essayant de ne pas trop rentrer dans les détails juridiques.
Tout d’abord, commençons par nous rapporter à la définition de l’open source donnée par l’OSI (Open Source Initiative). Il est indiqué en introduction :« Open source doesn’t just mean access to the source code » puis parmi les différentes conditions que doit respecter une licence open source :
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
En Français :
« Open Source » implique plus que la simple diffusion du code source.
3. Travaux dérivés.
La licence doit autoriser les modifications et les travaux dérivés, et leur distribution sous les mêmes conditions que celles qu’autorise la licence du programme original.
Source Traduction
La liste officielle des licences open source reconnue est donnée sur cette page. Vous retrouverez parmi celles-ci toutes les licences libres (au sens de la définition de la FSF). Ces dernières sont donc par voie de conséquence open source.
A la lecture de ces éléments, la réponse à la question de cet article est donc oui. Les licences open source ne permettent pas juste de consulter le code, elles permettent sa réutilisation.
J’avoue cependant me méfier et je n’exclus pas que certaines licences qualifiées d’open source recèlent un piège. Si vous connaissez un exemple concret merci de l’indiquer en commentaire.
Pour revenir au commentaire qui a motivé cet article, il n’est effectivement pas possible d’installer Gmail ou Twitter sur son propre serveur. Pourtant, Google, Facebook ou Twitter utilisent des briques sous licence open source pour construire leurs services web. Le code source final de cet assemblage lui n’est pas disponible.
Ceci est rendu possible par le fait que :
1- Ce sont des services web pas des logiciels distribués à des utilisateurs comme ceux que l’on peut installer sur son poste. L’obligation de redistribution des codes sources n’existe pas en général, d’où la création de l’AGPL pour essayer de combler cette faille.
2- Des licences comme Apache (la licence pas le serveur) permettent de placer sous la même licence ou sous les termes d’une autre licence une version modifiée du logiciel, donc éventuellement une licence non libre. Une exemple, le serveur Web Apache est utilisé (sous forme modifée) par IBM dans son serveur d’applications propriétaire WAS (WebSphere Application Server).
C’est vrai qu’il y a beaucoup de licences et qu’il peut-être facile de se perdre dans cette multiplicité. Dans les faits les licences GPL se partageaient 65% du « marché » de la licence open source en 2009.
Si je ne me trompe pas, un logiciel open source ne peut pas être non-libre, un logiciel non-libre à sources ouvertes étant appelé shared source par l’OSI.
Hello,
si on regarde la définition que donne l’OSI alors oui open source = modification autorisé mais dans la réalité il me semble me rappeler que .net par exemple est open source mais n’autorise pas les modification (entendons nous modification puis redistribution). Prenons exemple de .net le code source est accessible mais non-modifiable (licence microsoft shared source), le logiciel est donc open source mais pas au sens de l’OSI, mais bien au sens premier du terme.
Bonjour
Heureusement d’ailleurs que certaines licences permettent la libre réutilisation des codes sources sinon, elles n’aurait que peu d’intérêt. Tous les librairies techniques utilisées dans la plupart des projets informatiques (propriétaires ou pas) sont dans ce cas.
Cependant, selon les licences, il y a plus ou moins de restrictions : les différences s’entendent sur le droit de réutiliser les sources dans un contexte propriétaire (où on ne republie donc pas les sources).
– La licence GPL par exemple n’est pas dans ce cas, elle dispose d’un copyleft qui oblige toute modification à être republiée sous les mêmes conditions. Cette condition est d’ailleurs contagieuse, elle s’applique à l’ensemble du logiciel final.
– La licence LGPL est plus permissive et permet de réutiliser une librairie dans un développement propriétaire puisqu’elle n’est pas contagieuse : il ne sera nécessaire de publier que les modifications faites à la brique logicielle opensource.
Pour de plus amples informations sur les licences opensource, j’avais écris il y a plus de deux ans (pour le compte de mon employeur de l’époque) un livre blanc sur le sujet que j’avais publié à l’adresse : http://www.damiencuvillier.com/2008/04/23/licences-open-source/
Dans ce document, il y a notamment un schéma didactique qui aide à prise de décision quand il s’agit de choisir une licence pour un développement.
Le problème spécifique à l’OpenSource selon moi n’est pas ce qu’il autorise ou non mais plutot ce que l’OpenSource force à respecter ou non.
C’est paradoxal, mais un logiciel libre n’est libre que grâce à des règles imposées. Ce sont les quatres règles que l’on connaît tous. Etrange n’est ce pas ? Et pourtant ce sont ces quatre règles qui permettent le meilleur respect de chacun. Notamment de respecter le droit d’auteur ou plus exactement la paternité. En effet, ces règles ont un pouvoir d’équilibrage.
A contrario un logiciel OpenSource est si « libéré de toutes contraintes » qu’il est principalement impossible de forcer un développeur tiers reprenant le code
1/ de fournir ses propres sources donc garder les dérivés en opensource
2/ de respecter la paternité et de ne pas s’approprier du code
C’est en effet faux de croire qu’un logiciel OpenSource ne peut qu’être lu. Il peut être lu, modifié, redistribué, executé. Son défaut c’est de n’avoir aucune forme d’obligation envers l’origine.
Ca Apple l’a bien compris par exemple.
@Il Palazzo-sama si justement si un logiciel libre est open source la réciproque n’est pas vrai. Reportez-vous au tableau que j’avais fait à ce sujet
http://philippe.scoffoni.net/les-licences-open-source-libres-et-non-libres-tableau-recapitulatif/
La situation est loin d’être aussi simple
@Grummfy si on parle de ces licences
Toutes ne sont pas open source. J’entend reconnues par l’OSI. Seule
Microsoft Permissive License (Ms-PL) et Microsoft Reference License (Ms-RL) répondent aux critères de l’OSI. La Microsoft Community License (Ms-CL) n’est pas open source.
@Kevin Hinault C’est vrai que l’absence de viralité est à double tranchant. D’un coté elle encourage l’usage de ces librairies open source et potentiellement les contributions à ces dernières à la façon dont le fait Google en général. D’un autre coté, elle contribue à maintenir une part de propriétaire. Mais le Libre a-t-il vocation à faire disparaître le propriétaire ?
Je n’ai plus le lien sous la main, une personne avait pris le temps de comparer l’ensembles des licences dites libres (appsouvées par la FSF) et celles approuvées par l’OSI.
Résultat: une seule licence était dans une liste et pas dans l’autre. Il s’agissait du NASA Open Source Agreement. (uniquement OSI)
La raison est que l’on doit être l’auteur original des changements que l’on applique au code. Ce qui est inacceptable pour la FSF.
Ça date de plusieurs années donc il y a peut-être de nouvelles licences qui ont le cul entre deux chaises, mais pour l’écrasante majorité, un programme open source au sens OSI est un logiciel libre au sens FSF.
@grummfy: « open source mais pas au sens de l’OSI, mais bien au sens premier du terme »
Ben c’est quoi le sens premier du terme ? C’est quoi open ?
C’est justement le nœud du problème, tu pars du principe que dans la langue courante open = « droit de regard uniquement », ce qui est loin d’être évident.
La seule définition formelle qu’on a c’est celle de l’OSI, il faut la respecter, tout comme on respecte celle de « libre » au sens des 4 libertés, alors que ça ne coule pas de source.
@joan : « La seule définition formelle qu’on a c’est celle de l’OSI, il faut la respecter, tout comme on respecte celle de “libre” »
Je crois que c’est la seule façon de s’en sortir et de ne pas s’enliser dans de long débat autour de ces deux termes.
Philippe,
Si le propriétaire du copyright le souhaite il est tout à fait possible de publier du code en GPL et sous une licence propriétaire. C’est le cas de MySQL.
Par contre, une licence de type BSD autorise même des personnes non propriétaires du copyright à faire ceci, ou en termes pratiques à complètement fermer le code.
Si je ne me trompe pas (et d’après les commentaires que j’entend de la communauté PostGresql au Japon dont je suis proche) c’est une des raisons principales de la différence de déploiement et de dynamique de développement entre MySQL et PostGreSql.
Appelons un chat => un chat … sans marketing : « Open source » veut dire « source ouverte » et rien d’autre.
Par définition le code source est accessible (pour la nécessité d’éventuelle modification par exemple) et ceci sans évoquer le caractère libre ou propriétaire de la chose.
Après si une entité comme l’OSI souhaite alièner les mots, ça ne change pas la réalité de ces mots que ça plaise ou non 😉