VVL :: Le Blog sur les Licences Libres, Open Source, et leur diffusion - Tag - LGPL

Analyse de la LGPL v3 et examen approfondi des « Combined Libraries »

Mben — Thu, 05 Feb 2009 01:51:00 +0100

Sortant d’une période dense – et donc, relativement calme pour le blog – et avant d’en débuter une autre tout aussi épuisante, je prends le temps de publier le résultat de quelques échanges avec un collègue et ami très présent dans le milieu du logiciel libre en Belgique.

La réflexion concernait la portée qu’il convenait de reconnaître à l’article 5 de la GNU LGPL v3^[1] – anciennement article 7 de la GNU LGPL v2.1^[2] :

5. Bibliothèques combinées.

Vous pouvez placer des services de bibliothèque, lorsqu’ils constituent un travail basé sur la « Bibliothèque », côte à côte dans une bibliothèque unique avec d’autres services de bibliothèque qui ne sont pas des Applications et ne sont pas couverts par cette licence ; vous pouvez acheminer cette bibliothèque ainsi combinée selon les termes de votre choix à la condition de procéder ainsi :

* accompagner cette bibliothèque combinée par un travail identique basé sur la « Bibliothèque », non combiné avec d’autres services de bibliothèque et acheminé sous le régime de cette licence.

* accompagner la bibliothèque combinée d’une note indiquant qu’elle est en partie basée sur la « Bibliothèque » et précisant où trouver l’exemplaire non combiné de ce travail.^[3]

Après lecture de cet article, qui autorise la création de « bibliothèques combinées », nous cherchions à savoir s’il avait pour conséquence de réduire la portée du copyleft de la licence (comme le fait l’autorisation expresse d’utiliser la bibliothèque sous LGPL) ou s’il avait pour seuls objectifs de traiter une question technique de redistribution et d’identification de travaux sous LGPL.

Ayant profité de ces échanges pour récapituler brièvement les finalités des différentes clauses de la LGPL v3 et faire un point sur ce qui est compris dans l’expression “work based on”, je vais à nouveau m’y pencher avant de répondre à la question — ces développements viendront plus tard compléter la page du wiki relative à la LGPL.

Notes

[1] « 5. Combined Libraries. You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License. b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. »

[2] « 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things:a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. ».

[3] D’après une rapide traduction réalisée par la DAJ (Direction de l’Action Juridique) pour le Ministère des Finances et mise en ligne sur le site du ministère de la Culture. Il s’agit d’un document de travail, qui va notamment être repris et peut-être harmonisé par le groupe de traducteurs et juristes œuvrant sur la traduction de la GNU GPL v3.

Un récapitulatif sur la LGPLv3

Voyons pour commencer le principe de fonctionnement de la GNU LGPL, une synthèse des stipulations de la licence et, enfin, l’examen plus précis des trois types de combinaisons qu’autorise expressément la GNU LGPL.

I- Principe :

La GNU LGPL v3 est une « exception » à la GNU GPLv3 : c’est-à-dire qu’elle apporte un lot de permissions additionnelles afin d’atténuer la portée ou les effets de cette dernière^[1].
Conséquence :
- Par défaut, on applique la GPLv3 ;
- Mais dès lors que l’on se trouve dans l’une des situations posées par la LGPLv3, on applique le « régime dérogatoire » spécialement prévu (c’est le mécanisme fondamental : si la LGPL autorise une quelconque exploitation/utilisation, nul besoin de se tourner vers le reste des stipulations de la GPL) – néanmoins, comme toute exception, celles-ci doivent être interprétées de façon stricte/restrictive (ainsi, s’il manque un élément pour rentrer dans le champ de l’une des exceptions que pose la LGPL, alors les effets sont similaires à ceux qu’emporterait l’usage d’une GNU GPL classique).

II- Synthèse des stipulations de la GNU LGPLv3 :

Art. 0 : définitions des termes propres à la LGPL ;
Art. 1 : atténuation (c’est aussi ce que je nomme une exception) des obligations posées par la clause de la GNU GPL v3^[2] relative aux DRM en faveur des travaux/créations usant d’une bibliothèque soumise à la GNU LGPL v3 ;
Art. 2 : encadrement d’une permission de redistribution de la bibliothèque modifiée : sous GNU LGPL v3 si la modification ne rend pas ses fonctionnalités dépendantes de l’Application ; et GNU GPL dans le cas inverse ;
Art. 3, 4, 5 : trois permissions additionnelles concernant des combinaisons de codes incluant la bibliothèque — et qui modifient la portée de la GNU GPLv3 ;
Art. 6 : mécanisme de révision de la licence

III- Examen des trois types de combinaisons logicielles soumises à un régime dérogatoire (art 3, 4 et 5) permettant la libre redistribution (moyennant le respect de la licence) :

Art.3 : l’inclusion de “material from header file that is part of the Library”^[3]
- il s’agit de déclarer des fonctions qui seront définies plus tard dans un .lib :
- il faut :
  - indiquer les bibliothèques utilisées ;
  - accompagner le code des textes des licences GNU GPL et LGPL (v3).
Art.4 : la création de “combined work”^[4] :
- il s’agit de la possibilité de combiner une Application (programme utilisant une licence sans être basé sur cette dernière) et la Library (création, modifiée ou non, qui n’est pas une Application ou une combined work) sans que la licence soit utilisée sur le tout (c’est l’intérêt majeur de la LGPL) ;
- il faut :
  - indiquer : 1) les bibliothèques utilisées ; 2) le fait qu’elles sont sous LGPLv3 ;
  - transmettre : 1) le code source (à l’exception du code basé sur l’Application) ou s’assurer de l’interopérabilité de la combinaison ; 2) les informations utiles à l’installation ;
  - accompagner le code des textes des licences GNU GPL et LGPL (v3).
Art.5 : la création de “Combined Libraries”^[5] :
- il s’agit de la combinaison de bibliothèques dont :
  - une partie est soumise à la LGPLv3 ;
  - une autre partie n’est pas une ‘Application” (programme utilisant une bibliothèque sans être basé sur cette dernière) et n’est pas couverte par la licence (n’est donc pas le programme ou une création basée sur ce dernier).
- il faut soit :
  - préciser les bibliothèques utilisées et fournir (sous leur licence) une version non combinée (qui est donc sous LGPLv3 – puisqu’elle ne rentre plus dans l’exception) en attachement ;
  - indiquer les bibliothèques sous LGPL utilisées (expliquer quelle partie est sous quelle licence) et préciser où trouver une version non combinée (qui sera donc sous LGPL – puisqu’elle ne rentre plus dans l’exception).

Quant à ce qui est compris dans l’expression work based on

Suite à ce travail d’analyse, on en vient à se demander si seules les modifications (disons travaux dérivés) sont concernées par cette notion de “work based on” ou si les compilations (disons travaux composites, mais c’est sujet à débat) le sont aussi. (Je précise dès à présent que ces réflexions me sont toutes personnelles et n’ont probablement pas d’effet direct quant à l’application des licences de la famille GNU.)

Dans la GPLv2

En ce qui concerne la version 2 de la GNU GPL, le mécanisme semble trivial :

GPLv2 Art. 0 :

The “Program”, below, refers to any such program or work, and a “work based on the Program” means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.

GPLv2 Art. 2 :

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

Conclusion

Ainsi, même si la terminologie semble assez souple (mais le même reproche peut être fait à l’encontre de la GNU GPLv3 : les termes définis ne sont pas forcément ceux utilisés au sein du contrat), “work based on” semble bien inclure un tout qui contiendrait une brique sous licence libre.

Dans la GPLv3

En ce qui concerne la dernière version de la GNU GPL, le mécanisme est plus flou :

GPLv3 Art. 0

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

Ainsi, tout dépend du sens que l’on donne à “adapt … in a fashion requiring copyright permission” (je pense que l’intention est d’intégrer ici tout type de contribution dont l’exploitation est conditionnée au respect de la licence).

GPLv3 Art. 5

c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.

Doit-on comprendre que “entire work, as a whole” est la tournure qui permet d’étendre la Licence à la création qui comprendrait une brique sous GPL ?

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

Peut-on user d’une interprétation a contrario ?

Conclusion

Si on en reste à la première interprétation, Work based on peut s’entendre d’un travail composite ; selon d’autres interprétations, seules les modifications seraient concernées, même si la distribution d’un tout contenant une partie basée sur une brique sous GNU GPL sur nécessiterait d’être faite sous les termes de cette licence.

Nul doute que cette question pourrait encore être approfondie (un groupe de travail mené par la FSF Europe se penche d’ailleurs sur cette question à la fin du mois à Londres).

Le mot de la fin

Voilà où j’en suis…

Ainsi, l’article dont il est question (5 de la LGPL, pour ceux qui ont suivi) n’a, à mon sens, pas vocation à déterminer ce qu’est un Work based on… mais simplement de préciser qu’une Combined Library (qui est un type de Work based on the Library) sera soumise à un traitement différent.

Cela dit, on s’aperçoit par ces développements que la notion de work based on, plutôt que de se préciser, devient finalement de plus en plus floue… Je ne sais pas si c’est volontaire (l’incertitude peut permettre d’imposer des contraintes supplémentaires : on ne fait pas parce que l’on ne sait pas si l’on peut — alors même qu’il n’est juridiquement pas possible d’interdire tel acte), mais cette situation me semble être clairement nuisible à la compréhension que l’on peut avoir des licences…

Notes

[1] Au même titre d’ailleurs que l’exception FOSS développée pour la GNU GPL utilisée par MySQL AB sur son produit éponyme

[2] Article 3 : Protecting Users’ Legal Rights From Anti-Circumvention Law.

[3] 3. Object Code Incorporating Material from Library Header Files. The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following: * a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License. * b) Accompany the object code with a copy of the GNU GPL and this license document.

[4] 4. Combined Works. You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: * a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License. * b) Accompany the Combined Work with a copy of the GNU GPL and this license document. * c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document. * d) Do one of the following: o 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source. o 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user’s computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version. * e) Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.)

[5] 5. Combined Libraries. You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following: * a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License. * b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.

Publication des slides de la conférence EOLE 2008 !

Mben — Mon, 29 Sep 2008 13:20:00 +0200

Nous l'avions déjà rapidement évoqué dans de précédents billets (ici et là), VVL participait activement, par l'intermédiaire de l'un de ses membres, à l'organisation de cette première journée entièrement dédiée à l'analyse de la nouvelle GPLv3 et, plus généralement, au droit et aux problématiques liées aux logiciels libres/open source.

Les slides sont dès aujourd'hui disponibles sur le site de l'événement.

Cette journée-marathon ne réunit pas moins de 19 interventions de personnes toutes aussi impliquées dans ses problématiques afférentes aux licences libres. En quelques mots, ce fut un véritable succès qui démontra l'intérêt pour les praticiens d'échanger et de mutualiser leur expérience et compétence dans ce domaine.

Pour finir, et ne pas rompre les bonnes habitudes, un rapide résumé de ce séminaire.

P.-S. Les photos qui suivent sont directement issues du site de l'événement Paris-Libre et sont soumises aux conditions d'utilisation définies par celui-ci.

Dans le somptueux cadre du salon de la Fondation des États-Unis, équipé en conséquence (l'équipe de traduction fut impressionnante, que ce soit du français vers l'anglais et réciproquement), les intervenants se réunirent donc de 8h30 à 19h30 afin de partager leur vision de la « nouvelle » licence GNU GPLv3 — j'en profite pour saluer les deux sponsors de l'événement : la FniLL (Fédération Nationale de l'Industrie du Logiciel Libre) et le Cabinet Gilles Vercken dont le fondateur put notamment déclarer que « le monde du libre est dynamique et ouvert, et constitue un des secteurs les plus intéressants pour comprendre l'évolution du droit de la propriété intellectuelle ».

Commencée sans trop de retard, la journée se composa en deux temps, une analyse point par point la matinée suivie d'une plus transversale (par secteur) l'après-midi, étant eux-mêmes aérés par une ou deux pauses. On ne dénote quelques (petites) interventions par rapport au programme : la première le matin entre Grégoire Jocquel et Mark Radcliffe ; et une autre l'après-midi entre Grégoire Jocquel et Benjamin Jean.

Matinée : GPLv3 point par point

Philippe Aigrain (Sopinspace/Membre du Board of Directors de la Software Freedom Law Center) débuta la journée par une présentation du processus de révision de la GNU GPLv3, démontrant la révolution apportée dans la conception d'un document collectif et emprunt de philosophie comme l'est la GNU GPL.

Ciaran O’Riordan (Freedom Task Force) analysa ensuite brièvement les enjeux de l'internationalisation de la GNU GPLv3 avant que Javier Gonzalez (University of the Balearic Islands) ne s'attarde sur la portée des nouvelles licences et que Marco Ciurcina (StudioLegale.it) ne se penche sur les implications de l'aspect ASP — introduit dans la GNU GPLv3 par l'intermédiaire de sa compatibilité avec l'Affero GPLv3.

Philippe Laurent (coorganisateur de l'événement, Chercheur au CRID et Avocat au cabinet Belge MVVP) se concentra sur la problématique très bien maîtrisée de la compatibilité entre licences telle qu'elle fut introduite par la GNU GPLv3.

Bruno De Vuyst (universitaire et aussi avocat au cabinet MVVP) consacra son intervention à la problématique des brevets logiciels, de manière générale puis plus précisément de la façon dont elle fut encadrée par les nouvelles licences de la FSF, et Philippe Aigrain revint pour présenter les techniques mises en place dans ces dernières à l'encontre des DRM et des clauses d'enfermement.

Sandrine Rambaud (avocate au cabinet Bird & Bird) intervint sur les garanties et responsabilités : telle qu'elles ressortent des licences, telles qu'elles seraient appliquées en pratique, et enfin par comparaison avec les logiciels classiques (propriétaires). Mark Radcliffe (avocat DLA Piper, mais aussi membre du bureau de l'OSI et corédacteur de la GNU GPLv3), l'un des avocats américains les plus réputés sur ces questions, nous présenta la GPL du point de vue outre-Atlantique et détailla ensuite avec rigueur l'affaire Jacobsen v. Katzer qui fit beaucoup parler d'elle (un billet est actuellement en préparation sur cette problématique).

Après-midi : GPLv3 par secteur

Après un court déjeuner pris au sein de PCL, l'après-midi donna lieu à dix nouvelles interventions.

Grégoire Jocquel (Cabinet Gilles Vercken) débuta l'après-midi par une synthèse des plus exhaustive sur la GPLv3, vue selon le droit privé, avant que Patrice-Emmanuel Schmitz (Unisys – conseil IDABC) n'amène le débat au niveau du droit communautaire par sa présentation de l'EUPL (GPLv3 ou EUPL? Alternative pour le secteur public et ses fournisseurs).

Deux interventions remarquables revinrent ensuite placer les stipulations de la GPLv3 dans le domaine de l'industrie de l'embarqué et plus généralement des constructeurs (notamment vis-à-vis de la tivoïsation) : David Marr (Sun) et Phill Robb (Hewlett-Packard) — les deux individus qui font respectivement avancer ces deux sociétés dans le domaine de l'open source..

Juste après la pause, Loïc Dachary (APRIL / FSF France) tint le pari de démontrer au public l'importance de la dimension technique attachée au logiciel libre (ce qui n'était pas gagné au regard de l'audience à 90% composée de juristes. Thierry Aimé (Ministère des finances – FR) et Pascal Verniory (DCTI – juriste de la ville de Genève) ont livré deux visions complémentaires de la GNU GPLv3 du point de vue de l'administration publique (les marchés publics pour le premier et l'importance des SaaS pour le second)

La dernière et troisième session de l'après-midi laissa place à Sophie Gautier (OpenOffice.org — Community Council et Advisory Board Member) qui nous livra le cheminement d'OpenOffice.org en matière de licences et de Copyright Assignment et à Erwan Hamon (FFII France) qui se servit de l'exemple de Groklaw pour montrer à quel point la communauté pouvait aider.

La journée se termina finalement par une présentation qui se voulut pragmatique, visant à présenter la GPLv3 du point de vue de l'industrie du service et de l'édition (Benjamin Jean, pour Linagora).

Position de Syntec Informatique sur l'open-source - Juin 2007

Mben — Fri, 29 Jun 2007 15:16:00 +0200

La plus grande force des associations, et du bénévolat, est bien l'indépendance qui leur est attachée : être libre de toute pression, et baigner dans un climat de liberté de parole comme de pensée. De plus, l'usage de cette liberté construit la légitimité de son titulaire.

Ce billet (qui se veut objectif) porte sur, et commente, la prise de position publiée par le Syntec Informatique : « Position du syntec informatique sur l'Open Source ». Voyons ce que le plus grand syndicat des entreprises de l'informatique pense d'un mouvement de fond qui est en train de chambouler droit, politique, et économie

Le temps étant celui des opinions, intitulons ce billet « Prise de position de VVL sur la position du Syntec informatique sur l'Open Source » (même si l'intitulé est plutôt long).

Le papier.

Collection Thématic N°7 - Juin 2007

Libres Open Source Vs Propriétaire

On le verra encore ultérieurement, mais la sémantique utilisée semble avoir été mûrement réfléchie, pour appuyer le message porté par le papier.

Pour commencer, il est donc intéressant de souligner le choix portant sur l'utilisation du terme « Open Source », alors même, que les autres logiciels restent qualifiés de propriétaires (adjectif affiché comme une qualité) :

Pour en faciliter la compréhension, le terme « Open Source » sera utilisé par préférence à « logiciel libre »., p. 2

Par ailleurs, la définition qui sert à déterminer ce caractère d'Open Source reste celle de la FSF (RMS s'en tirerait les cheveux) :

Le contrat de licence est l’élément essentiel de l’Open Source, car ses termes définissent les fameuses « libertés » accordées aux utilisateurs par les créateurs du logiciel :

o Liberté d'utilisation

o Liberté d'accès au code source

o Liberté de modifier le logiciel, pour son propre usage ou pour des tiers

o Liberté (et dans certaines circonstances, obligation) de diffuser des versions modifiées du logiciel, p. 3

La mauvaise foi est encore plus palpable lorsque l'on définit les licences propriétaires:

Avant d'aborder les licences Open Source, il faut préciser que le type de licence de logiciel le plus courant et connu de la plupart des utilisateurs, s'applique au code binaire. Sous sa forme binaire exécutable sur un ordinateur, le logiciel est utilisable par un non-programmeur. Leurs auteurs peuvent faire régir le droit d'utiliser ce logiciel par une Licence qui s’applique uniquement au code binaire. Ces licences constituent la base des licences de logiciels propriétaires., p. 3

Le raccourci revient à présenter les licences propriétaire comme des licences réservées à la seule version du logiciel qui soit utile et au non-programmeur, laissant supposer, a contrario, que les licences open source porteraient sur le code source, inutile pour un non-programmeur.

Heureusement, les utilisateurs non-programmeurs de Firefox, OOo, Thunderbird, Ubuntu, et visiteurs de Framasoft, ont rapidement compris que l'utilisation des logiciels est tout aussi accessible que n'importe quel logiciel classique (à la différence qu'ils sont certains d'avoir les droits pour leurs utilisations) — les rédacteurs du papier étant probablement des pure players, ne jurant que par Gentoo. Un constat défavorable à l'Open Source

Avant toute chose, il faut noter qu'une telle prise de position du Syntec Informatique est singulière de la part d'un organisme professionnel puisqu'elle aboutit à mettre au ban de la structure une partie de ces adhérents au profit d'une autre — démontrant au demeurant la difficulté pour une telle structure d'être source de dynamisme et d'innovation.

entreprise éditeur (pour les logiciels commerciaux) ou de la communauté (pour les logiciels Open Source) (p. 5)

Les éditeurs de logiciels commerciaux, tout comme les communautés de développeurs du logiciel Open Source (p.6)

Le fait que cette industrie puisse être exercée sous des formes usuelles d’entreprise commerciale ou sous des formes originales de coopérative ou de communauté, ne change pas ce caractère industriel (p.6)

Avec un constat sans appel, l'Open source étant à la fois dénigré et opposé à l'« industrie Nationale » :

Il est essentiel que cet effort industriel soit non pas maintenu mais accentué, car il est de fait insuffisant en France et en Europe. À l’évidence les éditeurs de logiciel Open Source, ainsi que les communautés Open Source, ne fourniront à elles seules dans les années qui viennent, qu’une quote-part minoritaire à l’échelle mondiale de cet effort industriel. L’industrie française de l’édition de logiciels propriétaire, si elle occupe une place modeste par rapport à l’industrie correspondante des États-Unis, connaît déjà des succès significatifs au niveau mondial sur certains segments de marché, et conserve sur un grand nombre de segments une partie très significative du marché national. Pour ces motifs, elle mérite d’être reconnue et encouragée, quelle que soit l’opinion que l’on se forme sur l’avenir du logiciel Open Source.

Un grand axe : l'Interopérabilité

L’interopérabilité est le véritable enjeu

En effet, « Open Source » ou « Propriétaires » les produits logiciels ne sont que des éléments des systèmes d’information. Tout système d’information requiert aujourd’hui la mise en œuvre et la coopération de logiciels de différentes natures et portées : systèmes d’exploitation, middleware, logiciels applicatifs. Le véritable enjeu n’est pas la nature Open Source ou propriétaire de tel logiciel, mais celui de l’interopérabilité, c’est-à-dire a capacité à composer le système d’information souhaité à partir de logiciels coopérant efficacement., p. 5

Discours de plus en plus fréquent : Libre/Open Source ne veut pas dire format ouvert. Soit. Il n'empêche qu'il y a une forte accointance entre les logiciels libres et les formats ouverts — ne serait-ce que parce que les logiciels ne peuvent que suivre les besoins, et ne pratique pas la méthode du lock-in (enchaînement).

À l'inverse, s'appuyer sur les libertés données aux utilisateurs pour arguer de la facilité pour les solutions open source à perdre toute interopérabilité est un comportement totalement fallacieux :

Le modèle de l’Open Source n’est pas synonyme de standard ouvert. Il peut implémenter ou non des standards ouverts. Puisque le code peut être modifié, un produit qui initialement est conforme aux standards et qui interopère correctement peut être modifié par un utilisateur d’une manière telle que l’interopérabilité soit rompue., p. 6

En l'absence d'intérêt fort à rompre cette interopérabilité, il n'y a aucune chance pour un développeur de convaincre l'ensemble des développeurs à adopter cette attitude (alors que la décision serait prise en catimini dans une entreprise classique).

Le non respect des standards ouverts établis ou la rupture avec ces standards ouverts peuvent être revendiqués au titre de la meilleure performance ou qualité intrinsèque d’une solution logicielle non standard, Open Source ou propriétaire, et cette possibilité doit être admise sauf à s’interdire toute voie de progrès en ce sens.

Si une politique doit être suivie, c’est donc celle en faveur de l’adoption par le plus grand nombre d’acteurs possibles de ces « standards ouverts » et de l’objectif plus général d’interopérabilité, politique à laquelle la quasi- totalité des acteurs du logiciel, Open Source ou propriétaire, doivent pouvoir adhérer, car elle est conforme à leur intérêt et à celui de leurs clients. , p. 6

Si l'interopérabilité est effectivement primordiale, elle n'annihile pas tout autre intérêt que présentent les logiciels libres, mais s'y ajoute.

Pour le plaisir : les remarques

Sur les confusions et la mauvaise foi

Les auteurs de logiciels propriétaires choisissent le plus souvent de conserver leurs droits de propriété intellectuelle tout en permettant à d'autres d'afficher, et éventuellement d'exploiter les idées exprimées dans code. La propriété intellectuelle permet aux programmeurs de tirer une source de revenus de leurs inventions, ce qui en retour crée la motivation nécessaire pour développer d'autres innovations., p. 3

Confusion — ou lapsus : les idées restent de « libre parcours », c'est-à-dire inappropriables (exception faite de celles qui prennent la forme d'un brevet). Ceci se justifie lorsque l'on s'aperçoit que le discours confond probablement volontairement les notions liées aux brevets (inventions, innovations, etc.), avec d'autres, plus vagues (propriété intellectuelle), donnant in fine au droit d'auteur qui porte sur les logiciels une finalité qui n'est plus la sienne.

Les licences logicielles constituent le véhicule par lequel les programmeurs décident des éléments à partager et de ceux à protéger. L'octroi de licences permet en outre aux idées des programmeurs de devenir utiles et pratiques. Par exemple, d'autres peuvent les exploiter (en les améliorant, en les modifiant ou en les combinant) en vue de créer des produits abordables et utilisables par les entreprises et les particuliers. Les licences contribuent ainsi à alimenter l'élan d'innovation et de croissance qui caractérise l'industrie informatique., p. 3

Dure à digérer, la lecture de ce paragraphe rend flou l'usage de licences « logicielles », « libres », « propriétaires », « open source », etc. Ceci alors que, dans les faits, si le début est d'application générale, tout ce qui suit —et les conséquences qui en sont tirées — ne concerne que les licences libres...

La licence GPL V2, utilisée par environ 70% l’Open Source dont Linux, particulièrement rigoureuse en matière de Copyleft, est appelée « virale » par certains, car elle oblige à distribuer sous licence GPL tout logiciel « propriétaire » mixé avec un logiciel GPL,, p. 3

Le « par certain » n'atténue que très peu la pensée de celui, ou ceux, qui sont à l'origine de ce message. Je reste convaincu, par honnêteté intellectuelle, est-il plus opportun d'utiliser la notion de réciprocité (ou autre nom barbare :-)) que de viralité. En effet, les licences n'obligent à rien : elles conditionnent uniquement l'octroi de droit sur un logiciel à une distribution dans des termes identiques (je te donne si tu me donnes). Avec un peu de recul, la situation n'est même pas si étrangère à celle d'un logiciel propriétaire : si celui-ci permet sa redistribution, elle se fera probablement dans des termes assez contraignants — lorsqu'elle peut se faire.

La licence LGPL & MPL permettent néanmoins l’intégration de composants Open Source dans un produit propriétaire sans avoir pour effet de rendre ce logiciel propriétaire Open Source. , p. 3

La distinction est plutôt que : dans un cas, un logiciel ne peut pas utiliser un autre qui serait sous licence libre sans sous cette même licence (mais il peut choisir de ne pas l'utiliser du tout), alors que, dans l'autre cas, on peut user d'autres briques libres dans son logiciel propriétaire (dans cette hypothèse, les briques concernées resteront néanmoins sous licence libre).

L'étude des licences

o Les licences non « Copyleft », dont les plus connues sont : , p. 4

On ne peut pas les féliciter pour le choix de la notion floue de « non Copyleft » (donnant vraiment l'impression que l'objectif du papier était de n'utiliser aucun terme qui serait source de sympathie envers le mouvement : logiciel libre, licence permissive, etc. : concepts plutôt séduisants) ne permet pas de mener une réelle réflexion : les licences Microsoft ne sont pas copyleft, mais certainement pas assimilable à celles qui sont citées (problème récurrent lorsque l'on défini a contrario).

Admettons qu'il s'agisse d'examiner les licences dites « permissives ».

o Licence BSD (Berkeley Software Distribution) provenant de l'Université de Berkeley. Du code BSD peut-être combiné avec du GPL et devient donc du GPL. C'est ce qu'on appelle la compatibilité GPL,, p. 4

Le code ne « devient » pas du (GNU) GPL, il est simplement distribué sous une licence plus restrictive (GNU GPL) qui respecte la première licence (BSD) — passons, on trouve de toute façon les mêmes raccourcis sur le site de la FSF.

o Apache Licence 2.0, de l'Apache Software, p. 4

Ce problème aussi trouve son origine dans l'absence de définitions précise des catégories : la licence Apache est ici assimilée à une licence BSD alors même qu'elle comporte des stipulations très fortes en matière de brevets.

o Eclipse Public License (EPL), du consortium Eclipse, p. 4

Erreur : cette licence est bien sujette à un copyleft — même si « atypique ».

o Licence MIT (Massachusetts Institute of Technology), aussi appelées X-license ou X11-license est assez proches de la licence BSD et est souvent utilisée au sein de projets universitaires,

o La Licence CECILL de droit français, définie par le CEA, le CNRS et l'INRIA, p. 4

Erreur. Sorte de GPL gauloise, la CeCILL est l'équivalente de la GNU GPL en termes de copyleft — de surcroît expressément compatible avec cette dernière.

o Licence EUPL (European Union Public Licence). Cette licence, est en cours de définition par l'Union Européenne, p. 4

Erreur. Conformément aux attentes de la Commission, cette licence est tout à fait copyleft (type GPL) : voir la page du wiki sur l'EUPL.

Par ailleurs : achevée lors de la parution du papier, elle avait même été approuvée par la Commission Européenne le 9 janvier 2007.

Licences « Editeur ». Les éditeurs ont souvent créé des licences « Open Source » qui leur sont propres, et ont été approuvées par l’ « Open Source Initiative »., p. 4

La notion de Licence Éditeur est intéressante. Le postulat de base (concernant l'usage automatique du terme d' « Open Source ») rend néanmoins flou cette catégorie : le terme doit renvoyer non seulement à la définition (l'OSD), mais surtout à la labellisation de la part de l'OSI.

Par ailleurs, les développeurs de l’Open Source peuvent tout à fait distribuer ce logiciel selon plusieurs licences. Par exemple une licence Open Source pour un certain usage, et une licence propriétaire pour un autre type d’usage. Ce système s’appelle le « dual licencing » et nécessite l’accord de tous les auteurs du logiciel., p. 4

Ce qui n'est finalement qu'une application d'une pratique habituelle en « édition classique ». Je rajouterai néanmoins que l'utilisation du terme d'usage peut sembler flou : usage commercial, gratuit, etc.

En effet, ce n'est pas tant « pour certains usages », mais pour proposer plusieurs distribution d'un même produit, sous des termes différents (ce qui explique que cette pratique fonctionne principalement avec des licences libres assez contraignantes).

Enfin, la version 3 de la licence GPL devrait apparaître en 2007. Cette version entend renforcer les libertés des licenciés sur des domaines tels que les brevets, les dispositifs de gestion des droits numériques, les solutions intégrant matériel et logiciel, ainsi que par la fourniture de logiciel en mode hébergé., p. 4

Done : voir la page du wiki sur la GPL v3.

De part la complexité des modèles de licences du logiciel Open Source et des logiciels propriétaires, il est très important d’en comprendre la portée, les implications juridiques et commerciales, lors des choix logiciels pour l’entreprise. , p. 4

Tout à fait. Voici d'ailleurs l'unique objectif de nos précisions.

Il n’y a donc pas lieu de mener une campagne pour ou contre l’Open Source. Les règles de l’économie de marché doivent s’appliquer et déterminer les succès de l’Open Source ou du logiciel propriétaire en fonction de leur compétitivité et des différents modèles économiques proposés. Les qualités attendues d’un produit logiciel ne sont pas inhérentes à son origine « Open Source » ou « propriétaire », mais doivent s’analyser au cas par cas., p. 5

Il est aussi intéressant de préciser que la majeure partie de l'infrastructure de l'Internet repose sur des solutions open source (Bind, sendmail, postfix, Apache, etc.) — et ceci, bien pour leur qualité respective.

D’ailleurs, cette édition de logiciels propriétaires intègre déjà et intégrera sans doute de plus en plus des composants logiciels issus des logiciels Open Source et respectant des standards ouverts.

Eu égard au débat en cours sur la Recherche en France, on notera que, dans le domaine informatique, une industrie dynamique de l’édition de logiciel Open Source et propriétaire est un relais essentiel pour que tout effort de recherche public ou privé puisse être valorisé au bénéfice de l’économie française.

On le comprend sans trop d'ambiguïté : l'open source n'est qu'un outil bon marché qui permet de faire des solutions propriétaire de bonne qualité. Les deux types de logiciels ne sont pas mis sur le même pied, et, à partir de là, toute discussion semble perdue.

Propriété Intellectuelle et logiciels, la position de l'association française des éditeurs de logiciels (AFDEL)

Mben — Tue, 13 Mar 2007 23:53:00 +0100

L'AFDEL, jeune association, vient de publier un communiqué, une « prise de position » : Les acteurs de l’édition logicielle souhaitent avoir les moyens de protéger leur patrimoine et leurs investissements afin de garantir la pérennité de leur activité et de poursuivre leurs innovations.

Ce document se compose de deux parties

1e Partie - Cartographie des différentes catégories de logiciels (pp 20 à 31)

Le papier 2e Partie - Présentation générale de la protection juridique du logiciel en France (pp 21 à 37)

Avec pas moins de onze pages sur les logiciels open source (pp 23 à 31) au sein de la première partie.

« Pour la science » (et pour le Libre), voici une rapide lecture et analyse sur ce document, indéniablement documenté en ressource PI (on y retrouve les allusions habituelles aux patentes de Venise, Condorcet, Diderot, etc.), et qui présente assez clairement la volonté des éditeurs de logiciels de se surprotéger en puisant dans toute la palette des droits de propriété intellectuelle (Internet étant « le facteur d'accroissement d'un marché pirate parallèle » contre lequel il faut se protéger).

Lire la « prise de position »

Sur les brevets

« Parallèlement à un respect appuyé des droits d’auteur, qui protège l’expression d’une innovation, l’AFDEL compte également sur le droit des brevets pour défendre ses innovations ayant un caractère technique. » (p.10) Plus précisément, l'AFDEL « souhaite que les inventions mises en oeuvre par ordinateur qui constituent des innovations techniques, nouvelles et inventives puissent continuer à jouir d’une protection par le brevet, dans un cadre à l’avenir juridiquement clarifié » (P.11) ; elle s'oppose néanmoins à toute extension du domaine du brevetable (not. Les méthodes commerciales).

La position est ainsi assez simple : les logiciels ne peuvent légalement pas être breveté ^[1], mais c'est en pratique le cas ; on ne sait pas trop si l'on peut breveter ou non ; ce serait bien d'autoriser expressément. Par la même occasion, l'AFDEL prône la diminution des coûts de brevet, afin de les rendre plus accessibles aux PME.

« Plus généralement, l’AFDEL considère qu’une protection efficace passe par une combinaison de ces voies, chacune couvrant potentiellement une partie différente d’une innovation. Les droits de propriété intellectuelle sont un élément capital dans la gestion de l’innovation qui est un moteur de la création de richesse, et en particulier d’emplois. » (p. 12)

Comme souvent, on fait passer un message par la simple sémantique que l'on emploie : puisque l'on parle de protéger une innovation, la brevetabilité de celle-ci est assez logique puisque c'est l'objet même d'un brevet que de protéger les innovations. Droit d'auteur Force est de constater que les rédacteurs du papier étaient compétents en matière de propriété intellectuelle (en l'occurrence, autant droit d'auteur que droit des brevets), puisque la présentation de la propriété intellectuelle sans conteste satisfaisante. Certaines précisions sont plus particulièrement bienvenues, notamment :

« Un logiciel intégrant des fonctions évidentes, banales, découlant de la logique ne sera pas protégé au titre du droit d’auteur. » (p.14)

malgré ceci, le discours dégénère et l'on sent très vite une appréhension extensive de l'œuvre logicielle, cette dernière étant confondue avec l'oeuvre multimédia^[2] : « Sous réserve de leur originalité, tous les éléments du logiciel sont protégeables : le matériel de conception, l’analyse fonctionnelle, les codes source et objet, les interfaces y compris les interfaces graphiques, les éléments multimédias incorporés, mais également la documentation et le nom du logiciel. » Néanmoins, une présentation droit d'auteur/brevet assez simpliste qui donne rapidement l'avantage au droit des brevets, sans pour autant le justifier entièrement. Reprenons-la méthodiquement :

L’inconvénient de la protection par le droit d’auteur est qu’elle est parfois aisément contournable, et notamment dans le cas des logiciels. Si en cas de reproduction servile du logiciel la contrefaçon sera aisément établie, la situation est plus délicate lorsqu’on se trouve face à une imitation. Le principe dans ce cas est que le juge se fondera sur les ressemblances et non sur les différences mais ne s’attachera qu’aux éléments originaux du logiciel. Cependant des analogies ou des points communs peuvent être jugés parfaitement normaux en regard de l’objet du logiciel et ne pourront servir à établir la réalité de la contrefaçon. car non originaux : non protégeabl...De plus, un développeur quelque peu habile n’aura pas de grande difficulté à reproduire les fonctionnalités d’un logiciel, exprimées certes au moyen d’un code source différent, mais en vue d’atteindre le même résultat. Ne reproduisant pas le code source à l’identique, il échappera au grief de contrefaçon au titre du droit d’auteur, tout en reproduisant les principes techniques du logiciel original. Ainsi, le droit d’auteur, se révèle bien souvent insuffisant dans le cas des logiciels. Le brevet, susceptible de protéger une invention mise en oeuvre par ordinateur quelle que soit l’expression de son code, permet ainsi de compléter la protection des logiciels.

Parfois, toute la valeur ajoutée d’une invention réside dans l’élément logiciel de cette invention. C’est notamment le cas du système de freinage ABS ou encore de la téléphonie mobile. Priver de protection la part exclusivement informatique de ces inventions reviendrait à purement et simplement priver de protection ces innovations. » (p. 15-16) Quant à la question de la dangerosité des brevets :

« D'aucun veulent le laisser croire, mais peut-on imaginer sérieusement que le système des brevets aurait traversé toutes ces années (les prémisses de la législation sur les brevets remontent aux Républiques de Florence et de Venise au 15ème siècle), s’il avait véritablement nuit à l’innovation ? Toutes les révolutions industrielles se sont appuyées sur le dépôt de brevet ! » (p. 16)

Et les logiciels libres :

« Le brevet sert à contrôler l’utilisation qui sera faite d’une invention. Le détenteur d’un brevet peut autoriser qui il souhaite à reproduire son invention. On peut ainsi tout à fait imaginer le titulaire d’un brevet accorder une licence à quiconque souhaite en faire une mise en oeuvre dans un logiciel libre et en interdire l’accès à un éditeur delogiciels propriétaires, comme le fait d’ailleurs IBM dans certains domaines. »

Ce qui est en l'occurrence vrai, mais l'on passe tout de même du principe (les brevets n'empêchent pas la diffusion et l'utilisation de logiciels libres) à l'exception (une licence conforme aux licences libres peut être donnée). Ainsi, les brevets logiciels sont bien une voie détournée qui permet de reprendre le contrôle sur les logiciels libres

D'ailleurs :

Le brevet constitue une protection aussi bien pour le monde du libre que pour l’univers propriétaire.

APERCU GÉNÉRAL DE LA SITUATION:

Quelques distinguos utiles et opportuns, on notera néanmoins :

« On peut distinguer trois grands types de logiciels informatiques, et ce quelque soit le système d’exploitation de l’ordinateur (i.e.: Linux, Microsoft® Windows® ou Apple® Mac OS®) »: - Les logiciels privés - Les logiciels commerciaux - Les logiciels « open-source » »

Et pourtant, avec le temps que l'on passe à dire que « libre n'est pas gratuit »... On comprend mieux lorsque l'on lit que « Les logiciels commerciaux sont généralement des logiciels dits propriétaires en ce sens que la famille de logiciel propriétaire englobe tous les logiciels qui ne sont pas « open source» ». Le commerce est donc la fermeture du code.

Concernant les licences libres, on peut regretter ensuite un langage insuffisamment clair, alternant la notion de libre et d'open source sans les distinguer, ni réellement les assimiler. On s'aperçoit heureusement à la page 25 que le terme auquel ils songent est bien celui de libre, auquel ils substituent 'open source' pour ne pas risquer la confusion avec gratuit... Néanmoins, il faut admettre qu'in fine, ce qui est dit reste dans l'ensemble assez bien présenté. Quelques coquilles :

« les licences « copyleftées » : .... Elles interdisent en particulier d’ajouter au logiciel des modifications. » l'idée était certainement tout autre, mais est en l'état assez obscure.

On assiste donc à une équation expéditive : non copyleft = permissif = redistribution propriétaire autorisée. C'est un peu rapide puisque l'on a l'impression que la licence n'a plus à être respectée (alors que ses obligations restent bien réelles – cf la licence Apache). modifier (sauf à porter atteinte au droit moral de l’auteur) (p. 26) : il est toujours bon de préciser qu'en matière de logiciel, l'article L. 121-7 du CPI autorise toute modification « préjudiciable ni à son honneur, ni à sa réputation » Apache Free license (p. 27) : sorte de mix entre l' « Academic Free License » et la licence Apache...

Ce qui est étonnant, c'est l'argument utilisé pour rétablir l'équilibre en faveur des licences propriétaires :

« Cependant, ces restrictions sont largement compensées par l’existence d’une garantie à la charge de l’éditeur/donneur de licence qui peut aussi voir sa responsabilité engagée en cas de dommage causé par le logiciel. Il n’est ainsi pas rare qu’un éditeur de logiciel propriétaire donne des garanties sur des composants libres qui auront été intégrés dans son propre code. Enfin, ces garanties sur le logiciel propriétaire s’accompagnent souvent d’un support plus ou moins étendu, notamment dans le cas de progiciels ou d’applications très fortement dédiées à des métiers. »

la garantie en matière de logiciels propriétaires est bien moindre que ce qu'ils indiquent : il suffit de lire des licences du type de celle de Microsoft pour s'apercevoir que la garantie minimum est... la garantie légale (qui s'appliquent donc tout aussi bien en matière de logiciel libre, quoi qu'en dise la suite de l'étude – d'où la rédaction de clause spécifique : OSL, MPL, etc.). En se référant à l'annexe, page 47, une précision est donnée sur cette garantie : Généralement au moins conformité aux spécifications/ documentations...
toute personne peut choisir d'ajouter des garanties à l'utilisation ou la distribution d'un logiciel libre, et ce c'est que font en pratique la plupart des sociétés évoluant dans l'open source.

Analyse de licence :

GNU GPL :

L'analyse commence plutôt bien, puis chavire lorsqu'est mis en avant l' « Effet Viral » (« contaminante » un peu plus loin). La validité est ensuite clairement remise en question : puisqu'il y a plusieurs auteurs, c'est plus complexe de savoir si tous ont consenti à la licence (« Or, il est loin d’être certain que toutes ces autorisations soient données ». le formalisme des concessions des droits n’est pas respecté (ce qui est en partie vrai, mais n'est pas la particularité de la GPL, qui s'en sort finalement assez bien) ; un préambule trop philosophique : au contraire, c'est celui-ci qui permet de mieux interpréter et envisager la licence, il n'y a donc aucun reproche productif qui puisse lui être fait ; Le copyleft méconnaît le droit des auteurs concernés (et l'article 1165) : le navire coule ! De nombreuses études ont analysé ce type de clause, sous toutes les coutures, et il apparaît que – même si inhabituelle – elle ne nie pas les droits des autres auteurs (en l'occurrence celui de divulgation). La référence à l'article 1165 Cciv est navrante, puisqu'infondée : seules les personnes soumises à la licence le sont à la clause de réciprocité. Ainsi, il suffit de prouver que la personne n'est pas licenciée (n'a donc fait usage d'aucun des droits d'auteur) pour qu'elle n'ait pas à se soumettre à la licence (on peut aussi se référer à un argumentaire très complet des avocats de MySQL qui avaient démontré dans quelles mesures une licence peut être opposée à une partie). L'interprétation qui est donnée du droit au respect de l'oeuvre n'est en réalité qu'un des effets reconnus au droit en question. Rien n'assure que les juges considéreraient qu'il y atteinte au respect de l'oeuvre qu'une oeuvre placée sous licence libre soit modifiée – il suffirait par exemple de démontrer que la licence libre se double d'un contrat d'exploitation et d'adaptation. Enfin, il faut rappeler que le droit au respect de l'oeuvre est extrêmement réduit en matière de logiciel (analyse d'autant plus déroutante que ce point est effectivement expliqué quelques pages plus loin (p. 36) : En revanche, le droit de repentir et le droit à l’intégrité de l’oeuvre sont limités ou suspendus au profit du cessionnaire des droits d’exploitation, c'est-à-dire l’acquéreur du logiciel, sauf stipulations contraires (Art.L.121-7 CPI) – et aussi en page 44 : « Le droit à l’intégrité de l’oeuvre : Le droit de s’opposer aux modifications du logiciel qui porteraient atteinte à l’honneur ou à la considération de l’auteur. Ce droit est limité dans le cadre du logiciel ») ! Sur le droit de la consommation, il est intéressant de noter que les remarques – si elles sont en partie justifiées – traitent plus de la mise à disposition du logiciel que des droits effectivement cédés. Si la première est incontestablement à considérer (et les clauses contenues dans la licence n'exemptent pas de respecter cette branche du droit d'ordre public), la seconde n'en est pas pour autant remise en question.

La CeCILL (1 et 2) :

Ses efforts de compatibilité avec la loi française sont loués
Des reproches perdurent néanmoins : sur la modification, mes aussi sur ces clauses limitatives de responsabilité

La BSD :

Analyse expéditive : elle est simple, et incompatible avec le droit français

MPL :

Un petit micmac au début, la licence étant devenue compatible avec la GNU GPL (on parle bien de Mozilla, mais la suite est tout aussi floue).

« Contrairement à la licence « GNU GPL », la licence « MOZILLA » n’a donc pas d’effet viral ou contaminant. »

MIT :

identique à la BSD.

On trouve en annexe, en commentaire sur la LGPL, que « la modification doit être elle-même une librairie. »... Dans ce même tableau, on s'aperçoit que le composant sous licence Apache ne peut pas être soumis à une licence différente..? Ébauche Générale sur le droit d'auteur appliqué au logiciel : Analyse très scolaire, mais dans l'ensemble assez juste. On relèvera quelques coquilles pour le plaisir :

« La documentation d’utilisation du logiciel sur papier est protégée par le droit d’auteur traditionnel, en tant qu’oeuvre distincte du logiciel ». La distinction n'est pas si certaine.
« Lorsque les logiciels sont développés dans l’entreprise, les droits patrimoniaux sont dévolus à l’employeur8. Les droits moraux restent quant à eux acquis à l’auteur – salarié sauf clause contraire dans la convention collective ou le contrat. » — p.36 (c'est l'inverse : seuls les droits patrimoniaux peuvent subir un régime différent – vérité rétablie dans la page qui suit : « Les droits moraux sont en principe inaliénables »).

Une section sur la brevetabilité du logiciel

Une approche originairement assez pragmatique : « C’est pourquoi il serait judicieux que les textes de référence fassent également preuve de davantage clarté dans la voie de la brevetabilité des inventions mises en oeuvre par ordinateur à travers les logiciels. »(p.40)

« Il permet cependant de protéger l’organigramme qui est une application spécifique de l’algorithme, c’est-à-dire une mise en oeuvre particulière d’une fonctionnalité d’un logiciel qui peut être exprimée par différents codes sources protégés par le droit d’auteur. »

C’est ce qui explique qu’il conviendra de concilier, sur un même logiciel, le droit des brevets et le droit d’auteur qui répondent à des régimes distincts.

Nos amis demandent simplement le beurre et l'argent du beurre...

Une analyse mesurée :

Par ailleurs, afin d’éviter les « mauvais » brevets, tels que des brevets portant sur des inventions qui ne seraient pas vraiment nouvelles, il importe que l’accès des logiciels, et plus généralement des inventions mises en oeuvre par ordinateur, à la brevetabilité soit rigoureux et réponde strictement aux conditions d’appartenance au domaine technique, de nouveauté et d’activité inventive.

Annexe

Une synthèse sur les droits d'auteur, assez ambiguë (qu'est-ce que les droits moraux de l'utilisateur légal – p. 45)

Conclusion

Un papier de plus qui cherche à confondre le logiciel libre, sous couvert d'un droit d'auteur qui semble maîtrisé. De mon point de vue, l'hypocrisie est d'autant plus patente que les connaissances qui empreignent le papier peuvent fortement laisser à supposer que les rédacteurs ont délibérément déformé la vérité pour la faire coller à vision des choses.

Notes

[1] voir l'article XXXX du CPI sur l'exclusion des logiciels de la brevetabilité

[2] voir notamment les travaux du CSPLA sur les œuvres multimédias

Interview de F. Montin, développeur de DéKiBulle

Mben — Thu, 12 Oct 2006 17:53:00 +0200

Marre des usines à gaz à la iTunes ou Winamp ? Besoin d’un lecteur discret capable de gérer une bibliothèque de musique ? DéKiBulle est fait pour vous ! DéKiBulle, le lecteur audio libre, complet et sans fioritures !

Depuis sa libération, le logiciel est sous double licence GNU LGPL / CeCILL-C !

La fiche de Dékibulle sur Framasoft.

Q: Fred Montin, qui êtes-vous ?^[1]

Fred Montin : « J'ai 26 ans, je suis ingénieur en aéronautique à Toulouse, j'effectue des calculs pour le développement des moteurs d'avion et de leurs nacelles (carénage aérodynamique entourant les moteurs). Mon travail n'a a priori rien à voir avec la programmation, mais pourtant je passe certainement autant de temps devant un PC qu'un informaticien... La programmation me sert énormément dans mon travail de tous les jours.

J'ai toujours été attiré par la réalisation de programmes, depuis mes débuts en QBasic jusqu'à aujourd'hui en Delphi. J'adore cette logique de me poser des questions afin de définir quelle sera la structure du logiciel, de travailler son code, de l'améliorer jusqu'à obtenir le résultat désiré avec le minimum de ligne. »

Q: Depuis quand développez-vous DéKiBulle ? De quand date la première version publique de DéKiBulle ? Depuis quand DéKiBulle est-il libre ?

F.M. : « L'idée de DéKiBulle n'est pas nouvelle, en fait au tout début j'avais créé un simple petit utilitaire en visual basic qui se logeait dans la barre des tâches et qui pilotait Winamp pour lui faire lire le contenu des répertoires. Je me suis contenté de ce principe pendant un moment, mais le fait de lancer un logiciel extérieur, ce n'était pas très « classe » et cela consommait beaucoup de ressources pour pas grand-chose. C'est pour cela qu'un jour j'ai décidé de pousser plus loin le raisonnement et de créer un véritable lecteur mp3 autonome.

Si mes souvenirs sont bons, la première version de DéKiBulle doit dater des alentours de mi-2005 (déjà !). Il me semble que je l'ai quasiment de suite mise en ligne sur mon site, mais plus pour le mettre à disposition de mes amis qu'autre chose. En fait au début j'ai principalement développé DéKiBulle pour mon usage personnel.

DéKiBulle est libre seulement depuis la version 3.20, donc depuis septembre 2006. »

Q: Pourquoi avoir choisi une licence propriétaire pour les débuts de DéKiBulle ?

F.M. : « J'avais hésité au tout début à distribuer DéKiBulle sous licence libre, mais je n'avais pas envie à l’époque de me « prendre la tête » et je l'ai distribué sous licence freeware propriétaire surtout par souci de simplicité... Et puis c’est resté comme cela. »

Q: Comment avez-vous connu le libre ?

F.M. : « Je connais le libre depuis pas mal de temps, j'aime ce principe qui va à l'encontre de tout ce qui se fait dans la société actuelle. Créer quelque chose et le mettre à disposition de tout le monde, pour moi c’est une des plus belles spécificités du net, un petit « pied de nez » aux lobbies à notre échelle. Et j'ai remarqué que les logiciels libres sont souvent bien meilleurs que leurs homologues payants et, comment dire, on retrouve souvent un côté humain derrière ces réalisations : ce sont des gens passionnés qui mettent leurs connaissances au service de tout le monde. »

Q: Qu'est-ce qui vous a poussé à choisir ensuite une licence libre ?

F.M. : « Le passage de DéKiBulle sous licence libre a été déclenché grâce à l'équipe de Veni Vidi Libri. Ils m'ont contacté en m’exposant brièvement les objectifs de leur équipe, et comme j'étais déjà un peu au courant du principe des logiciels libres, j'ai dis banco ;o) on y va ! »

Q: Est-ce que certains aspects vous ont plutôt freiné pour la libération de DéKiBulle ?

F.M. : « Comme je le disais plus haut, la raison principale qui m'a poussé à distribuer DéKiBulle sous licence propriétaire au début c'était que l'utilisation des licences libres me semblait assez complexe (c'est d’ailleurs ce qui s'est avéré être le cas pour DéKiBulle), mais le fait que l'équipe de VVL m’aide dans cette démarche a levé la plupart de mes inquiétudes. Sans eux je ne l'aurais certainement jamais (ou mal) fait! »

Q: Avez-vous eu des réticentes à l'ouverture du code ? À la possible d'un fork (Nouveau projet basé sur le code source de l'oeuvre originale, mais par d’autres développeurs) sur votre logiciel ?

F.M. : « Je n'ai pas eu de réticences particulières, je sais que mon niveau en programmation n'est pas excellent et je ne pense pas que voler mon code intéresse les « vrais » programmateurs qui mettraient peu de temps à développer un logiciel comme DéKiBulle. J'aurais plutôt peur que l’on copie l'idée du principe de gestion par les répertoires, mais bon, je n’en mourrais pas ;-) »

Q: Comment s'est déroulé le passage de propriétaire à libre ?

F.M. : « À vrai dire de mon côté cela a été assez simple, c'est surtout du côté de l'équipe VVL que cela a dû être plus dur :o). Le problème principal est que DéKiBulle utilise des bibliothèques et des composants développés par d’autres et distribués sous des licences différentes. Il fallait donc trouver un moyen de rassembler tout cela sous une licence libre (en l'occurrence une double licence libre). »

Q: Comment êtes-vous entré en contact avec l'équipe Veni, Vidi, Libri ?

F.M. : « Comme dit précédemment, c'est l'équipe VVL qui m'a contacté elle-même par e-mail pour me proposer d'étudier la possibilité de libération de DéKiBulle. »

Q: Pouvez-vous déjà tirer un bilan de la libération de DéKiBulle ?

F.M. : « Le passage en libre est récent, je n'ai pas vu pour l’instant de grand changement mis à part que l'on parle un peu plus de DéKiBulle ;o) Quoiqu’à l'instant même où j'écris ces lignes une personne vient de poster sur le forum pour me dire qu'elle avait rajouté quelques fonctionnalités à DéKiBulle ! C'est le libre qui est en marche ;-D »

Q: Qu'est-ce qui vous ferait changer à nouveau la licence de DéKiBulle pour une licence propriétaire ?

F.M. : « Je ne sais pas, peut-être que si je découvre des abus cela risque de me refroidir, mais j'ai confiance en l'être humain. J'ai raison hein ? :o) »

Q: Quels sont les avantages/inconvénients d'un logiciel libre (selon vous) ?

F.M. : « L'avantage du libre c'est de partager non seulement un logiciel qui peut s'avérer utile à un certain nombre de personnes, mais c'est également la possibilité pour toutes ces personnes de comprendre son fonctionnement, de le modifier, et contribuer à son développement pour que chacun puisse le faire évoluer selon ses désirs et ainsi partager son travail avec les autres. L'inconvénient c'est que l'on se sépare un peu de « son bébé » mais cela est nécessaire si l'on veut qu'il grandisse :-) »

Q: Conseillerez-vous à un développeur de passer son soft en libre, et pourquoi ?

F.M. : « Tout dépend de l'état d'esprit du développeur, il faut être prêt pour ça et bien se renseigner, car comme je le disais précédemment, on se sépare un peu de ses créations. Mais je crois que ça peut être une formidable opportunité de donner une autre dimension à ses logiciels. »

Q: Vous avez développé 2 autres logiciels (LecteurHexa & eMuleExtinction). Envisagez-vous de les passer sous licence libre ?

F.M. : « Pourquoi pas, ce sont des logiciels simples à côté de DéKiBulle et leur passage en libre ne posera pas autant de problèmes. Je le ferais certainement bientôt. Je vous tiendrais au courant ;-) »

Q: Si vous deviez développer un autre logiciel aujourd'hui, sous quelle licence le distribueriez-vous ?

F.M. : « Je crois que j'opterais dès le départ pour une licence libre car je suis aujourd'hui un peu plus au courant dans ce domaine, ou alors je ferais les tout premiers développements sous licence propriétaire histoire de libérer le logiciel une fois qu'il sera « stable »… »

« Pour conclure je tiens à remercier l'équipe de Veni Vidi Libri pour son aide indispensable et l'équipe de Framasoft pour l'intérêt qu’elle porte aux logiciels libres en général et à DéKiBulle en particulier ;o)

Longue vie au libre ! »

Un grand merci à Fred Montin pour s'être prêté au jeu des Questions/Réponses pour Veni Vidi Libri !