Discussion :

[Patrick Ruiz]

Les Pays-Bas vont-ils accorder la priorité aux logiciels libres dans les marchés publics ? La FSF observe
Et entend obtenir que les softs financés par le contribuable soient libres

Faut-il de façon systématique avoir recours aux logiciels libres dans le cadre du service public ou simplement leur donner la priorité ? C’est un vieux débat qui reprend un coup de neuf avec des développements y relatifs du côté des Pays-Bas. D’après ce que rapporte la branche européenne de la Free Software Foundation (FSF), le pays opte par défaut pour le logiciel libre au sein des institutions publiques.

Cela est à l’étude tant pour ce qui est de l’achat de logiciels que de leur publication par les institutions publiques. C’est de façon ramassée ce qui ressort d’une lettre du secrétaire d'État à l'Intérieur et aux Relations – Raymond Knops – adressée au Parlement. En substance, le gouvernement exprime sa faveur au principe de logiciel libre par défaut pour ce qui est des acquisitions au sein des institutions sous son contrôle. De plus, le volet développement et publication active de logiciels libres par les agences gouvernementales n’est pas en reste. En effet, la réponse adressée aux parlementaires insiste sur la priorité à l’ouverture du code source sauf pour ce qui est de cas de figure spécifiques. Grosso modo, la manœuvre vise à la mise sur pied d’une véritable communauté du Logiciel Libre au sein du secteur public des Pays-Bas. Ce positionnement n’est pas sans faire penser à celui du gouvernement français. En septembre 2012, le Premier ministre Jean Marc Ayrault recommandait l’usage des logiciels libres dans une circulaire adressée à tous les membres du gouvernement.

L’argumentaire mis en avant par le gouvernement des Pays-Bas est une redite de celui d’autres pays qui ont adopté des politiques similaires. Il y a bientôt 8 ans, la circulaire « Orientations pour l’usage des logiciels libres dans l’administration » du Premier ministre de la France avait, entre autres, mis en avant la mutualisation des ressources de l’administration, la transparence (notamment pour des raisons liées à la sécurité), la mise en concurrence sur un pied d’égalité des prestataires (du fait de l’ouverture du code source) et la réduction de la facture. Sur le dernier point en particulier, une analyse rapide suggère que remplacer Windows et autres Microsoft Word par Linux et LibreOffice permet de faire l’impasse sur les coûts des licences. Toutefois, tout changement a des coûts, parfois très lourds, qu’il faut prendre en charge sur le court terme. En effet, une mauvaise estimation de ces derniers peut amener une organisation ou même une ville à revenir sur sa décision comme cela a été le cas de Munich.

Après, une grosse différence est que là où les Pays-Bas décident de choisir par défaut le logiciel libre pour les institutions publiques, la France a simplement opté pour encourager leur utilisation. En effet, dans le cadre de discussions similaires lors de l’examen de la loi pour la République numérique en 2016, les parlementaires français avaient choisi d'encourager l'utilisation des logiciels libres et formats ouverts « lors du développement, de l'achat ou de l'utilisation d'un système informatique. » En d’autres termes, pas de priorité au logiciel libre en France alors que les développements en cours suggèrent que c’est parti pour être le cas aux Pays-Bas. C’est d’ailleurs ce qui va motiver une révision des textes de loi en vigueur dans le pays afin que les agences gouvernementales puissent publier des logiciels sous licences libres.

« Une nouvelle politique de passation de marchés sera également adoptée : les logiciels libres sont par défaut la voie à suivre, le gouvernement et ses institutions commenceront activement à publier des logiciels libres », rapporte la FSF qui suit et soutient le projet.

La politique du « logiciel Libre d’abord » en cours de gestation aux Pays-Bas s’appliquera en principe aux nouveaux projets lancés au sein des agences gouvernementales. En règle générale, c’est l’argent du contribuable qui finance de telles initiatives. À la FSF, on estime que tels logiciels doivent être publiés sous des licences libres. C’est la raison pour laquelle l’Organisation pilote la campagne Public Money ? Public Code !

« La campagne Public Money ? Public Code ! campagne vise à établir le logiciel libre comme la norme pour les logiciels financés par les pouvoirs publics. Les administrations publiques qui suivent ce principe peuvent bénéficier d'une collaboration avec d'autres organismes publics, d'une indépendance vis-à-vis des fournisseurs uniques, d'économies d'impôts potentielles, d'une innovation accrue et d'une meilleure base pour la sécurité informatique. La Free Software Foundation Europe, plus de 180 organisations de la société civile et plus de 27 000 personnes ont signé la lettre ouverte. Nous ferons usage des signatures pour contacter les décideurs et les représentants politiques de toute l'Europe et les convaincre de faire du code public la norme », précise la FSF.

Sources : lettre

Et vous ?

Faut-il de façon systématique avoir recours aux logiciels libres dans le cadre du service public ou simplement leur donner la priorité ?
Avez-vous le sentiment que cette politique a porté des fruits dans les pays qui l’ont adoptée ?
Partagez-vous l’avis de la FSF selon lequel il est normal que les logiciels financés par le contribuable soient publiés sous licences libres ?

Voir aussi :

Un logiciel libre doit-il être en mesure de restreindre les tâches que ses utilisateurs peuvent effectuer avec son aide ? Non, pour Richard Stallman
France : le Sénat choisit d'encourager l'utilisation des logiciels libres et formats ouverts plutôt que de leur donner la priorité
Les députés votent la priorité au logiciel libre dans l'enseignement supérieur, échec du lobbying des éditeurs de logiciels propriétaires
Les logiciels libres ne seront plus prioritaires dans l'Éducation Nationale, ils seront envisagés mais plus préférés aux solutions propriétaires
Choisir en priorité le logiciel libre porterait atteinte au principe de neutralité technologique des marchés publics, pour le Syntec Numérique

[SQLpro]

Pour information, la Norvège à fait le chemin inverse : interdiction de logiciels libre dans certains domaines sensibles, comme la gestion des identités (passeport, permis....), la santé, etc....

A +

[Angelsafrania]

Je pense qu'il serait bon que tout projet informatique fait pour l'état sur l'argent public soit libre.
Comme la recherche, je pense qu'il serait bon que toutes les études publiées par des chercheurs payés par de l'argent publique soient disponible gratuitement.

Peut être que certain projet sensible devrait avoir la faveur du secret pour ne pas être utilisé de façon malhonnête (comme toujours où serait la limite).

Car actuellement je suis pas sur que tous les contrats, pour nouveaux logiciels, incluent la propriété du code et de documentation à l'état.

[champomy62]

Pour information, la Norvège à fait le chemin inverse : interdiction de logiciels libre dans certains domaines sensibles, comme la gestion des identités (passeport, permis....), la santé, etc....

A +

<troll>
Un peu de lobbying!
</troll>

Je serai curieux de savoir quels sont les motifs indiqués?

[Invité]

Je serai curieux de savoir quels sont les motifs indiqués?

Moi aussi.
Et aussi d'avoir des sources qui confirment ça, plutôt qu'une information qui tombe d'on ne sait où.

[SQLpro]

Les sources je ne peut vous les donner car c'est confidentiel. Les raisons sont simples :
- responsabilité civile des éditeurs de logiciels, qui existe par défaut dans le domaine commercial et n'existe pas dans le free
- réactivité des éditeurs via leurs hotline et les services payants d'assistance (plus rare dans le free)
- plus grande communautés d'adoption (en général)
- pérennité de la solution plus étendue (liée à l'ancienneté des applis)
- plus grande fiabilité/sécurité

A +

Je pense qu'il serait bon que tout projet informatique fait pour l'état sur l'argent public soit libre.
Comme la recherche, je pense qu'il serait bon que toutes les études publiées par des chercheurs payés par de l'argent publique soient disponible gratuitement.

Peut être que certain projet sensible devrait avoir la faveur du secret pour ne pas être utilisé de façon malhonnête (comme toujours où serait la limite).

Car actuellement je suis pas sur que tous les contrats, pour nouveaux logiciels, incluent la propriété du code et de documentation à l'état.

Vaste utopie... ça n'est pas possible pour tout et n'importe quoi....
Quelques exemples ou c'est impossible :

• la diplomatie
• la défense
• la police
• la justice
• la gestion des données personnelles (santé, impôts, élections....)

A +

[Steinvikel]

Pour information, la Norvège à fait le chemin inverse : interdiction de logiciels libre dans certains domaines sensibles, comme la gestion des identités (passeport, permis....), la santé, etc....

Pour ma part, les Pays-Bas ont une position similaire. La différence est qu'ils ne font pas mention d'interdiction d'usage du " libre ", mais d'absence de priorisation de choisir du " libre ". En pratique cela revient au même, à savoir qu'une solution logicielle répondant à une problématique recouvrant un thème sensible ne sera jamais à caractère " libre " du fait d'un besoin d'opacité sur ses méthodes ou ses résultats.
Voici la citation :

En effet, la réponse adressée aux parlementaires insiste sur la priorité à l’ouverture du code source sauf pour ce qui est de cas de figure spécifiques.

La Norvège explicite les cas de figures concernés, et interdit ces cas. Les Pays-Bas ne les explicite pas, en retire la priorisation du caractère " libre " (à sa convenance car non listé) et se garde la capacité de tout de même leur conférer une licence libre.
Dans les 2 cas, il subsiste un gros dilemme comme évoqué sur un commentaire précédent : où et comment définir la limite de ce qui DOIT être " libre ", ce qui PEUT être " libre " et ce qui ne DOIT PAS être " libre " (à savoir : mû par une extrême opacité).

Pour vous donner un exemple mettant en lumière toutes les nuances de ce genre de décision :
On peut raisonnablement penser que tout ce qui touche au militaire doit être secret.
C'est une erreur de première approche. L'une des priorités de l'armée est d'avoir des liaisons de communications fiables, résilientes, sûres, secrètes.
Or les protocoles de sécurité les plus fiables en communication, sont les protocoles ne présentant aucune opacité sur leur implémentation.

PS : il est ici question de logiciels, on peut différencier les base de données des logiciels.
En France, les "acteurs publics" n'ont que 2 licences pour publier une bases de donnée sous licences libres. Toutes les autres licences leur sont interdites.
1) ODbl (Open Database license)(à copyleft) ...qui nécessite obligatoirement la signature de contrats !
2) “Licence Ouverte” (non copyleft)

Faut-il de façon systématique avoir recours aux logiciels libres dans le cadre du service public ou simplement leur donner la priorité ?
Je suis de cet avis, mais pour statuer sur une tel affirmation, il est nécessaire de définir au préalable : Que recouvre le cadre d'un service public ? et Qu'est-ce qu'un service public ?
Pour moi ce n'est pas simplement le service public qui doit respecter ce principe, mans l'ensemble des " pouvoirs publics ", leur constitution (avec un c minuscule), les outils sur lesquels ils s'appuient, et le produit de leur travail.

Je le vois comme quelque chose de systématique sans pour autant le fermer à la possibilité " d'exceptions ".

Partagez-vous l’avis de la FSF selon lequel il est normal que les logiciels financés par le contribuable soient publiés sous licences libres ?
Totalement.

[esperanto]

Les sources je ne peut vous les donner car c'est confidentiel. Les raisons sont simples :

Sans les sources, ces "raisons" ne sont au mieux que ton interprétation. A part ça:

- responsabilité civile des éditeurs de logiciels, qui existe par défaut dans le domaine commercial

LOL, sachant que TOUTES les licences de logiciels, y compris les libres, commencent par une clause de non responsabilité

et n'existe pas dans le free
- réactivité des éditeurs via leurs hotline et les services payants d'assistance (plus rare dans le free)

Sachant que beaucoup de logiciels libres sont issus de sociétés qui ne vivent justement que des entrées d'argent issues du support technique payant, euh, comment dire...

- plus grande communautés d'adoption (en général)

Vu que je n'ai pas rendu publique la liste des logiciels libres que j'utilise, vu que je n'ai pas eu à acheter de licence et donc à avoir un contrat avec l'auteur, comment peut-on prouver cela?

- pérennité de la solution plus étendue (liée à l'ancienneté des applis)

LOL, il suffit de voir le nombre de projets de logiciels amorcés par Sun et abandonnés par Oracle: seuls ceux qui étaient libres ont pu être forkés. Sans même parler du cas de Solaris, dont le support est arrêté par Oracle ce qui pousse à se tourner vers... Linux pour station SUN.

- plus grande fiabilité/sécurité

Ah oui, c'est sûr, prenons Windows comme exemple...

[Angelsafrania]

Vaste utopie... ça n'est pas possible pour tout et n'importe quoi....
Quelques exemples ou c'est impossible :

• la diplomatie
• la défense
• la police
• la justice
• la gestion des données personnelles (santé, impôts, élections....)

A +

Ta liste m'étonne. La diplomatie, la défense ça pourrait se comprendre, il faut masquer les avancés qui ont été faite et ne pas donner sur un plateau d'argent nos propres armes (c'est bien triste d'en développer des armes).
Mais pour la police, la justice, la santé les impôts et les élections, il est indispensable d'avoir les logiciels qui traite les données. Les données elle doivent resté privées, mais les logiciels (et les documentations) traitant ces données devrait être libre pour s'assurer que l'état gère correctement nos données.
L'open data est une bonne chose aussi, mais la vie privée étant important à mes yeux, sa mise en place est plus compliquée.

[SQLpro]

LOL, sachant que TOUTES les licences de logiciels, y compris les libres, commencent par une clause de non responsabilité

Elle est illégale, dans tous les droits latins. Donc dans la plupart des pays d'Europe. Ce n'est pas parce que tu met des clauses illicite que le droit ne s'applique pas...

A +

[SQLpro]

...
Pour vous donner un exemple mettant en lumière toutes les nuances de ce genre de décision :
On peut raisonnablement penser que tout ce qui touche au militaire doit être secret.
C'est une erreur de première approche. L'une des priorités de l'armée est d'avoir des liaisons de communications fiables, résilientes, sûres, secrètes.
Or les protocoles de sécurité les plus fiables en communication, sont les protocoles ne présentant aucune opacité sur leur implémentation.

ça c'est toi qui le dit. Aucune démonstration de la supériorité en terme de fiabilité ne met en évidence que le libre est meilleur.
D'autre part l'un des principe majeur dans le domaine du secret est que moins on en sait, mieux cela vaut. Et avoir des outils développé en interne et non public pour certaines applications très confidentielle constitue déjà un rempart de plus pour la sécurité.
Tout logiciel, qu'il soit d'éditeur ou "free" ne peut être entaché de failles. S'il est dans le domaine commercial ou public, les failles seront publiées tout ou tard et pourrons constitué un point d'entrée susceptible de menacer la sécurité, même si la correction est rapide. En revanche face à un logiciel inconnu, il est impossible d'en connaître les failles. C'est pour cela que, par exemple, le code de tous les système de missile n'est jamais divulgué !

A +

[Steinvikel]

Je nuancerais ta réponse de la manière suivante : Aucune démonstration de la supériorité en terme de fiabilité ne met en évidence que le libre est meilleur. Mais la plupart des mise en cause concernant des implémentations de sécurité sur un produit concurrent mettant par opposition une implémentation opaque (partiellement ou complètement) à une implémentation libre, laisse observer le constat suivant --> quand c'est "libre", c'est statistiquement moins grave, ou statistiquement moins défaillant. Le dernier exemple en date que j'ai en tête concerne PGP, OpenPGP, GnuPG.

C'est vrai, c'est moi qui le dit, car ce sont mes propos... mais cela s'appuie sur les retours plus ou moins connus des logiciels les plus divers dont on croise les écho ici et là. Il en ressort toujours la même choses --> les logiciels "secrets" présentent les pires causes des failles de sécurité... parmi les quelques-unes qui sont finalement connus.
Oui, ne pas avoir de code publié permet de ne pas l'étudier "librement", mais il est étudié tout de même par rétro-ingénierie, de manière comportementale, ça limite donc ...ça n'éradique pas.
De plus, quand c'est développé en interne, pour être des plus fiable, il faut que l'équipe de dèv' maitrise l'intégralité des composants logiciels et matériels, or ce savoir est rarement réunit dans son intégralité, même dans un grand projet communautaire ce n'est pas toujours le cas. Néanmoins, on peut raisonnablement s'accorder à dire que les gros projets communautaires tendent à s'en rapprocher un peu plus ...je vois pas comment on peut affirmer que dès que c'est de "la défense" "du sérieux", les 10 dèv' deviennent comme par magie omniscient et omnipotent, là où une vingtaine (ou plus) réuni autour d'un même projet pourrait aisément se compléter et avoir des spécialités plus prononcés.

[xarkam]

Je nuancerais ta réponse de la manière suivante : Aucune démonstration de la supériorité en terme de fiabilité ne met en évidence que le libre est meilleur. Mais la plupart des mise en cause concernant des implémentations de sécurité sur un produit concurrent mettant par opposition une implémentation opaque (partiellement ou complètement) à une implémentation libre, laisse observer le constat suivant --> quand c'est "libre", c'est statistiquement moins grave, ou statistiquement moins défaillant. Le dernier exemple en date que j'ai en tête concerne PGP, OpenPGP, GnuPG.

C'est vrai, c'est moi qui le dit, car ce sont mes propos... mais cela s'appuie sur les retours plus ou moins connus des logiciels les plus divers dont on croise les écho ici et là. Il en ressort toujours la même choses --> les logiciels "secrets" présentent les pires causes des failles de sécurité... parmi les quelques-unes qui sont finalement connus.
Oui, ne pas avoir de code publié permet de ne pas l'étudier "librement", mais il est étudié tout de même par rétro-ingénierie, de manière comportementale, ça limite donc ...ça n'éradique pas.
De plus, quand c'est développé en interne, pour être des plus fiable, il faut que l'équipe de dèv' maitrise l'intégralité des composants logiciels et matériels, or ce savoir est rarement réunit dans son intégralité, même dans un grand projet communautaire ce n'est pas toujours le cas. Néanmoins, on peut raisonnablement s'accorder à dire que les gros projets communautaires tendent à s'en rapprocher un peu plus ...je vois pas comment on peut affirmer que dès que c'est de "la défense" "du sérieux", les 10 dèv' deviennent comme par magie omniscient et omnipotent, là où une vingtaine (ou plus) réuni autour d'un même projet pourrait aisément se compléter et avoir des spécialités plus prononcés.

Je viens un peu après la bataille ^^

Le libre n'est pas mieux que le non libre en terme de sécurité. Comme cela a été dit souvent, il faut que les personnes ayant les compétences aient le temps et la volonté de se plonger dans le code source pour chercher des failles.
Et les failles sont généralement découverte lors de fonctionnement.

Ne pas libérer le code de systèmes critiques tient d'une logique assez simple mais souvent oubliée ou alors occultée par mauvaise fois, réduire le panel de personnes ayant les compétences pour décrypter le fonctionnement et ainsi facilité les recherches sur le/les coupables.
L'ouvrir à tous, reviens à avoir 7 milliards de présumé coupables en cas d'incident.

Il y a beaucoup de méconnaissances de la part du grand publique sur les pratiques de testes envers les systèmes critiques.
J'ai moi même travaillé dans des laboratoires de testes en environnements et cela m'a ouvert les yeux sur bien de choses. (qui sont encore sous le coup du secret défense)

[Steinvikel]

Il ne faut pas s'égarer, on compare pas simplement le secteur du "libre" avec le secteur "propriétaire", on compare des contextes similaires l'un adoptant une licence libre avec une transparence dans sa mise en oeuvre, l'autre adoptant une licence propriétaire avec une certaine opacité dans sa mise en oeuvre.

Si on prend par exemple openSSL, il y avait une grande démocratisation de l'usage, mais l'absence de rétribution /compensation /contribution... résultat il y avait des choses à faire mais pas de salaire pour le faire, puis la faille hearthbleed a été trouvé. Aujourd'hui openSSL est toujours bien démocratisé, mais de grands acteurs qui s'appuient sur ce protocole financent désormais le salaire de ceux qui le développe /maintient

Quand une société décide de faire de l'open-source, elle emploie des personnes compétentes, et en nombre suffisant... de la même manière qu'elle le fait pour une solution "propriétaire", et ce sont au final les même personnes (lorsque l'initiative vient d'une société).
Dans ce contexte, le libre présente dans son produit final statistiquement bien moins de problèmes, ou de dimensions moins grave.

Il y a des petits projets d'amateurs qui sont clairement à la ramasse en comparaison de produits concurrents développés par une société d'édition. Mais ce ne sont pas du tout les mêmes moyens qui sont déployé... Je compare 2 choix distincts dans une même situation, non pas 2 situations distinctes ayant pour seul points commun le développement d'un logiciel /protocole /algorithme.

"L'ouvrir à tous, reviens à avoir 7 milliards de présumé coupables en cas d'incident."
7 milliards... pas sur la responsabilité du "développement" (divise par 1 milliard)... et ça permet également de discerner plus facilement à qui la faute. =)
Bizarrement, quand on ce sait attaquable ou dénonçable, on a tendance à éviter les pratiques les plus pernicieuses, les pratiques discutables, et on reprends un peu de rigueur.
Pour certains cela sera perçu comme un frein, et s’emploieront au stricte minimum, se cantonnant à ce qu'ils maitrise bien, tandis que d'autres s’évertueront à produire un travail plus qualitatif que d'ordinaire. Ca dépend à la fois des habitudes, des caractères, et des valeurs de chacuns.