En avant-propos, ce billet ne représente que ma démarche personnelle et mon humble point de vue sur l’utilisation des licences libres, correspondant forcément à ma façon d’agir, de faire, un point de vue duquel je suis volontiers prêt à discuter.
En matière de licence, pour tout ce qui ne concerne pas mes projets personnels, j’adopte complètement le point de vue de Zed Shaw, auteur du manuel de Python Learn Python The Hard Way et d’articles parfois polémiques (mais souvent intéressants), qui a écrit son point de vue sur le choix de la licence d’un logiciel par son auteur dans cet article et que je vais essentiellement résumer par cette citation :
I really don’t care what license people use on their software, it’s their software and bitching at them for the license they choose is offensive. They wrote it, put their blood and sweat into it, and you should be glad that you get the privilege of even seeing it.
(traduction approximative : Je me fiche complètement de la licence que les gens utilisent pour leur logiciel, c’est leur logiciel et dire du mal d’eux pour la licence qu’ils ont choisi est offensant. Ils l’ont écrit, ont sué sang et eau pour lui et vous devriez être content d’avoir le privilège de juste le voir)
En tant que programmeur du Logiciel Libre, je ne peux qu’adhérer à ce point de vue. Par contre, je peux décrire pourquoi dans quasiment tous mes projets je n’utilise – personnellement encore une fois – que la GPLv3 (General Public License version 3).
GPL vs BSD, une opposition classique au sein du Logiciel Libre
Éviter la fuite de code hors de la communauté
Rappelons quelques bases : tout le code écrit sous une licence permissive type BSD ou MIT restera dans la communauté du Libre. Par contre l’une des principales caractéristiques des licences permissives est la possibilité offerte de rendre privatrice une bifurcation (fork) d’une base de code au précédent sous une licence permissive. Très concrètement, il est autorisé de bifurquer un logiciel sous licence BSD ou MIT et d’en faire un logiciel privateur. Cet aspect est bien connu et parfois voulu des utilisateurs de ces licences, permettant toutes les utilisations possibles des bases de code sous ces licences. Le but recherché est d’attirer la plus large base possible d’utilisateurs et de contributeurs qui utiliseront et contribueront peut-être un jour à la base de code originale ou à ses dérivées.
FreeBSD, principal projet sous licence BSD
J’ai toujours été pour ma part gêné par cette caractéristique des licences permissives. Je l’assimile à une potentielle fuite de code hors de la communauté. En effet, un cas d’usage de ces licences va consister à bifurquer une base de code existante et à implémenter de nouvelles fonctionnalités à partir de cette base de code. Ces nouvelles fonctionnalités, développées au sein d’une base de code privatrice, n’alimenteront donc pas en retour la base de code communautaire, accessible publiquement, librement utilisable et modifiable.
Prenons un cas assez courant, les routeurs construits sur une base de code sous licence BSD (souvent FreeBSD et OpenBSD). Pour le dire franchement, la liste de ces produits est à tomber par terre. Et ça n’est bien sûr que l’extrême sommet de l’iceberg.
Ma position est donc au final que ces licences permissives, bien que facilitant l’appropriation d’un Logiciel Libre et assurant à l’individu le maximum de droits sur une base de code qu’il n’a pas écrite, desservent la communauté dans son ensemble en laissant optionnelle la réintégration à la base de code communautaire les éventuels développements survenus sur la bifurcation devenue privatrice, développements pourtant eux-mêmes basés sur cette base de code produite à l’origine par la communauté.
On peut se douter de la masse de produits privateurs réalisés à partir de logiciels sous licences permissives par l’important nombre de ceux qui sont connus
Une licence est fondée sur le droit, pas sur l’informatique
La GPLv3 et d’une manière générale perçue comme complexe par les informaticiens du Libre, ce qui représente un frein à son adoption. Inutile de le nier, elle l’est indubitablement pour quelqu’un de non-formé au droit (moi le premier). Le texte court et aisément compréhensible des licences BSD/MIT provoque souvent un phénomène d’adhésion, faisant que les licences BSD/MIT sont souvent préférées à la GPLv3. Mais cette brièveté cache des conséquences potentielles insoupçonnées, dont la plus importante a été décrite au chapitre précédent.
C’est à mon sens une grave erreur que de se référer à la brièveté d’une licence pour la percevoir comme « bonne ». Il est bon d’avoir le contrôle complet sur ce que l’on produit, mais la licence n’est pas une partie technique du programme, mais la définition juridique des droits que vous accordez à vos futurs utilisateurs et exploitants de votre code, le droit d’auteur vous donnant par défaut tous les droits sur la production de votre programme.
La licence évolue dans le monde du droit et le fait que vous soyez ou non capable de la lire ne devrait avoir dans les faits avoir que peu d’importance. Êtes-vous capable d’écrire vous-même le contrat de vente de votre maison ? Êtes-vous capable de percevoir et comprendre toutes les implications des conditions générales d’utilisation et de confidentialité des services en ligne que vous utilisez, comme celles de Facebook ou Gmail (désolé si vous n’êtes pas utilisateur de ces services, beaucoup le sont même chez les Libristes. J’utilise moi-même Twitter) ? La plupart du temps, vous n’êtes pas en capacité de le faire et vous devez vous appuyer sur un avocat pour étudier correctement un contrat. C’est absolument la même chose avec votre programme. Si vous souhaitez le défendre juridiquement de manière efficace, il vous faudra vous reposer sur le travail de professionnels du droit.
Eben Moglen, avocat conseil de la Free Software Foundation et président du Software Freedom Law Center.
Et c’est ici que la GPLv3 entre en jeu. Autant elle peut paraître effrayante par sa complexité, autant elle protégera juridiquement de manière efficace votre logiciel. Cette licence a su évoluer face aux attaques que le Logiciel Libre a subi, comme la Tivoisation. Cela est bien sûr valable si vous adhérez aux principes prônés par le créateur de cette licence, ce qui est mon cas dans le cadre de mes projets.
Une licence en accord avec sa démarche propre
Comme décrit en introduction, je pense qu’il faut accorder de l’importance à la licence qu’on choisit pour son logiciel afin de le protéger juridiquement, et par la même occasion protéger sa communauté d’utilisateurs et le travail produit par cette communauté.
Ce choix est également primordial pour s’assurer que le cadre d’utilisation dudit logiciel sera conforme à celui que désirait le créateur du projet. Dans mon cas, la GPLv3 accorde à chaque utilisateur du code les mêmes droits mais aussi les mêmes devoirs, à savoir reverser à la communauté le code modifié rendu public en conservant la même licence. Cela permet ainsi aux individus de se nourrir du travail de la communauté, et la communauté de bénéficier du travail des individus. Un cercle vertueux qui correspond à mon idéal personnel pour la communauté du Logiciel Libre.
Et vous ? Que pensez-vous du choix de la licence GPLv3 au lieu des licences plus permissives type BSD/MIT pour vos projets ? N’hésitez pas à réagir dans les commentaires.
Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.
