Je ne reviens pas sur le Livre Blanc de manière générale, laissant à chacun la possibilité de se faire son idée, mais vais seulement m’attacher à quelques commentaires plus pointus :
L’importance des aspects juridiques
En parcourant ces travaux, je suis tombé sur un paragraphe qui m’a semblé (pour le moins) « réducteur » :
La politique open source a bien sûr des aspects juridiques importants, mais elle ne doit pas pour autant être laissée entre les mains des seuls avocats. Dans beaucoup de cas, il s’agit de définir, pour le contexte spécifique de l’entreprise, quel est le meilleur équilibre entre bénéfices et risques, et si les avocats sont utiles pour souligner les risques, ils percevront certainement très mal les bénéfices. Au chapitre juridique, le plus important est d’apporter aux acteurs un minimum de formation, éteindre les fausses idées, et attirer l’attention sur les vrais impacts.
(p.11)
La prochaine fois que je parlerai de politique Open Source, je penserai à adopter le même argumentaire pour évacuer certains points complexes :-) :
La politique open source a bien sûr des aspects économiques/techniques importants, mais elle ne doit pas pour autant être laissée entre les mains des seuls hommes d’affaires/ingénieurs. Dans beaucoup de cas, il s’agit de définir, pour le contexte spécifique de l’entreprise, quel est le meilleur équilibre entre bénéfices et risques, et si les hommes d’affaires/ingénieurs sont utiles pour souligner les bénéfices, ils percevront certainement très mal les risques. À leur chapitre, le plus important est d’apporter aux acteurs un minimum de formation, éteindre les fausses idées, et attirer l’attention sur les vrais impacts.
Je le dis avec le sourire, mais je suis persuadé que les visions techniques, juridiques et économiques sont toutes aussi importantes (ce qui explique d’ailleurs que Libre Blanc juridique Syntec Informatique/FniLL sur les Licences Libres mêlent finalement ces trois points de vue). Par ailleurs, chacune de ses compétences peut sembler complexe pour ceux qui ne les maîtrisent pas, mais elles ont toutes pour objectif (en ce qui nous concerne) de permettre d’optimiser le développement de logiciels et la valorisation (économique et sociale) de ceux-ci.
Cela dit, c’était peut-être le sens du paragraphe relevé (d’autant que les 5 pages suivantes sont consacrées au juridique… :-) )… quoi qu’il en soit, il me semble utile d’admettre la nécessité de travailler étroitement avec des avocats (spécialisés) et/ou les juristes d’entreprise (formés) pour mettre en place une politique Open Source adaptée (ou plus généralement une politique Propriété Intellectuelle).
Quelques imprécisions juridiques importantes
Comme toujours, les paragraphes juridiques retiennent toute mon attention, et quelques rectifications sont nécessaires :
L’avertissement à l’égard de la reprise de quelques lignes de codes qui pourraient emporter la mise sous licence Open Source d’un logiciel
Il est important de bien comprendre que la propriété intellectuelle se définit au niveau microscopique, sur quelques lignes de code seulement. Si un développeur trouve 10 lignes de code qui lui simplifient la vie, et les colle dans son programme, alors il est vraisemblable que son employeur n’a plus la propriété complète du programme ainsi réalisé. (p.11)
La question des licences est plus délicate et plus complexe concernant de petits composants, intégrés à des programmes. Copier quelques lignes d’un programme A pour les coller dans un programme B suffit à faire du programme B une œuvre dérivée du programme A. Et selon les conditions de licence du programme A, cela peut entraîner des exigences particulières quant au programme B, particulièrement dans le cas où il serait distribué. (p. 14)
Il me semble ici nécessaire de tempérer ces paragraphes : les droits de propriété intellectuelle de manière générale, et plus particulièrement le droit d’auteur, sont des droits finalisés et non des droits absolus. Ainsi, non seulement on ne peut pas en faire ce qu’on souhaite, mais surtout ils ne sont reconnus au profit d’un auteur que dans certaines hypothèses : pour le droit d’auteur il faut qu’il y ait une œuvre, c’est-à-dire une création (forme d’expression) originale (empreinte de la personnalité de son auteur / apport personnel de celui-ci). Ainsi, bien souvent, pour des emprunts si brefs (quelques lignes), il n’y aucune originalité qui permettrait à l’auteur de ces quelques lignes d’opposer un quelconque droit à l’encontre du pseudo contrefacteur : et c’est bien heureux puisqu’on peut ainsi lever de nombreuses difficultés juridiques (par exemple à l’égard des patchs, des contraintes nécessaires à l’interopérabilité, etc.).
Voilà pour la première précision, la question de l’œuvre dérivée est beaucoup plus complexe et je ne rentrerais pas dans les détails ici. J’ajouterai enfin que d’autres droits de propriété intellectuelle (comme le droit des marques, ou dans une certaine mesure les brevets) doivent faire partie des réflexions juridiques nécessaires lors de la constitution de la politique en question.
Concernant la difficulté à mettre du code dans le domaine public en France :
À noter qu’en droit français, il n’est pas aisé d’abandonner ses droits et de mettre son programme dans le domaine public de manière irréversible. (p.12)
Pour être plus précis, il faudrait simplement énoncer qu’il n’est pas possible en droit français de renoncer à sa propriété intellectuelle au profit du domaine public (et ainsi, un auteur qui le ferait pourrait valablement revenir sur ces dires – ce qui génère une absence de sécurité juridique)
L’absence de risques juridiques quant à l’utilisation de composants open source en l’état
Donc, concernant des produits utilisés en l’état, la politique open source peut se préoccuper de support, de pérennité, de conformité aux standards et de bien d’autres choses, mais n’a du moins pas à se préoccuper de risques juridiques. (p.12)
C’est vrai et faux à la fois, en tout cas un peu simplifiée : comme toute réutilisation de code tiers (propriétaires ou open source), il est nécessaire d’encadrer les risques juridiques (notamment en cas d’action en contrefaçon puisque c’est souvent les utilisateurs/distributeurs terminaux qui sont inquiétés) et cela se fait par contrat (comme pour toute fourniture de code tiers). Ainsi, rien de vraiment particulier, mais il y a bien un risque qu’il convient de gérer/maîtriser.
- Quelques erreurs quant aux licences non copyleft :
Les licences dites non-copyleft, qui incluent BSD, Apache APL, MIT, Eclipse, Mozilla MPL, et quelques autres, ne présentent pas de risque juridique particulier, et doivent être acceptées sans attention particulière. (p14 – on retrouve les mêmes idées en annexe)
Dans la famille BSD, on trouve aussi la licence MIT, et la licence Apache. Cette dernière est d’une grande importance puisque utilisée déjà par la cinquantaine de projets de la fondation Apache. On peut citer également les licences Mozilla (MPL) et SUN (CDDL). Les différences entre ces différentes licences sont de l’ordre du détail. (p.39)
Je n’ai pas eu le temps, mais je pensais que ce point avait été (relevé par mes soins et) corrigé dans le précédent livre blanc : considérant que les licences non copyleft sont des licences qui n’imposent que le maintien des obligations lors de la redistribution du composant open source, il faut supprimer de cette liste les licences MPL et CDDL.
En effet, les licences MPL (pensez à Firefox) et CDDL (pensez à OpenSolaris) sont toutes les deux copyleft et imposent le maintient tant de leurs obligations que des droits qu’elles confèrent (au passage, il s’agit de deux très bonnes licences – avec une préférence pour la CDDL, plus récente, mais la MPL est en cours de réécriture).