je suis tombé sur des cas ou les développeurs excluent la documentation de la licence libre de leur développements ... exemples, pré-requis, contexte etc ...
pour eux c'est voilà le code et débrouilles-toi !

en serait-il de même des développements "publics" ?
sommes nous en contexte Licences Open Source, ou Licences Libres (les exemples cités en liminaire)?

L'assertion suivante est erronée :

Ces licences [permissive] seront particulièrement adaptées pour couvrir les codes sources implémentant un service de base ou d’infrastructure

Voici quelques contre-exemples sous licence avec réciprocité (GPL) :

• Linux,
• BIND ("le" logiciel de serveur DNS, licence MPL)
• Samba (partage de fichiers),
• Emacs (éditeur de texte présent dans tous les Unix),
• GCC (compilateur langage C),
• MySQL,
• WordPress

(Je m'exprime au nom de l'ADULLACT, mon employeur.)

Comme évoqué dans la page :
https://github.com/DISIC/politique-de-contribution-open-source/blob/master/Ouverture.md#pré-autorisation-de-signer-un-icla-auprès-de-certaines-communautés

quelles seraient les communautés / entreprises avec lesquelles vous auriez un besoin de CLA corporate ?

• Apache Software Foundation : https://www.apache.org/licenses/cla-corporate.txt
• Eclipse Software Foundation : https://www.eclipse.org/legal/ecafaq.php
• OASIS OPEN : https://www.oasis-open.org/resources/open-repositories/cla/entity-cla
• Pivotal : https://cla.pivotal.io/
• Ubuntu : https://www.ubuntu.com/legal/contributors
• Google: https://cla.developers.google.com/clas

1. mv comptes-organismes-publics comptes-organismes-publics.yml

2. Utiliser org_account_url et forge comme informations élémentaires pour chaque entrée, par exemple:

- org_account_url: https://framagit.org/parcoursup
  forge: gitlab
  
- org_account_url: https://github.com/ANSSI-FR
  forge: github

Le but est de permettre de savoir quelle est l'API à utiliser (si elle existe) pour les données collectées depuis ce dépôt.

@ljoubert et @AntoineAugusti OK pour vous ?

Bonjour,
Je suis un peu mal à l'aise avec la traduction de "Developer Certificate of Origin" en "Certificat d'origine du développeur", puisqu'il ne s'agit pas d'attester de l'origine du développeur mais bien de celle de ses contributions.
Pensez-vous qu'une des propositions suivantes serait plus adaptée ?

• "Certificat d'origine des développements"
• "Certificat d'origine des contributions"
• "Certificat d'origine à l'usage des développeurs"

Camille

Par exemple:

• https://www.gnu.org/philosophy/kind-communication.fr.html
• https://www.contributor-covenant.org

Un element encore et toujours manquant, l'absence de license de type 'domaine public'.
Il en existe plusieurs licenses pourtant :

• Creative Commons Zero (https://creativecommons.org/choose/zero/)
• Unlicense (http://unlicense.org/)
• WTFPL (http://www.wtfpl.net/)
• ...etc...
  Et elles sont reconnues notamment part github ou bitbucket.

Le taux de participation (financier ou humain) d'un projet devrait avoir un impacte sur la license. Il est a mon sens insultant que l'argent des contribuables (le mien y compris) serve a financer un tant soit peu des logiciels entierement proprietaire, de la meme facon s'il est financer integralement part le public (donc part moi-meme) je suis 'en droit' de pouvoir l'utiliser comme bon me semble donc il doit etre le domaine public.

On pourrait etablir un bareme en fonction de la participation :

• [90-100%] : domaine public obligatoire
• [60-90%] : a minima une license utilisable par les societes sans contraintes (MIT,BSD,Apache2)
• [15-60%] : a minima une license open-source, meme a fortes contraintes (GPL,Cecill)
• [0-15%] : choix libre

Il faut au moins donner le choix d'une license de type 'domaine public'. Pour moi qui suis developpeur a la fois dans mon travail et part passion, l'absent de cette possibilitée rend le texte grotesque et nuisible, non pas comme un pas en arrière mais comme la continuité d'une mauvaise politique qui reni et ignore volontairement encore et encore tout acte d'altruisme.

Si vous pensez que ceux qui utilisent le domaine public sont rares, il vous suffit de regarder ici meme sur github, en tapant 'license:unlicense' ou 'license:cc0-1.0'. Il y a surement quelques maires et des associations qui ont encore a coeur de donner sans attendre de retour. Ou est ce que vous êtes des monstres ?

Bonjour,

Recommandation d’utiliser des licences permissives dans le cas général

Je pense qu'il pourrait être utile de donner quelques exemple de licences permissives ( Cecil, BSD) et quelques exemple de licences à l'identique (Creative Commons,...) pour mieux illustrer le propos.

Serait il aussi possible de préciser le rôle de conseil ou d'accompagnement que pourrait prendre la DINSIC en cas de conflit sur une licence ? Savoir que des spécialistes pourraient aider en cas d'usage incompatible avec la licence choisie pourrait rassurer les administrations

Merci

De même que pour les bonnes pratiques de développement, les préconisations de sécurité sont trop implémentatoires et peuvent être sujettes à débat (cf discussion Conseil très contestable dans « Développement sécurisé » ) voire polémique, et affaiblissent le document.

Remplacer le contenu de cette section par une invitation à suivre le RGS (Référentiel Général de Sécurité) serait une bonne option.

(Je m'exprime au nom de l'ADULLACT, mon employeur.)

Des liens relref ne sont pas fonctionnels. Ils ajoutent le nom de leur page courante (il me semble pour toute les pages, sauf celle d'introduction).

Plusieurs exemples sur la page faq : https://www.numerique.gouv.fr/publications/politique-logiciel-libre/faq/

Pour lister les premiers de chaque page : https://github.com/DISIC/politique-de-contribution-open-source/search?q=relref&unscoped_q=relref

• GOVERNANCE : décrit la gouvernance du projet, les rôles et les droits de votes. Un exemple est le fichier

(le fichier ??? quel mystère :))

Cette remarque fait suite à une discussion IRL avec @camillem

Instanciation est un terme technique et un anglicisme: dans le contexte d'un document donnant des recommandations sur l'ouverture du code source, il risque d'être pris au pied de la lettre et/ou de donner l'impression que l'instanciation est une étape nécessaire (comme l'est par exemple la transposition d'une directive européenne en droit français).

Il s'agit plutôt pour les administrations qui en ont le besoin de produire une version adaptée de ce document, pas vraiment de l'instancier.

Est-ce qu'adapation conviendrait ?

Le chapitre : Inventaire des comptes d'organisation comporte des liens/bonnes pratiques qui ne peuvent s'appliquer pour nous car propres à la Grande-Bretagne. À moins qu'on souhaite réellement que les contributeurs s'inscrivent sur le compte gouvernemental britannique ? ;-)

Le fichier OrgAccounts est utilisé par https://github.com/etalab/data-codes-sources-fr pour récupérer les métadonnées des organisations listées dans ce fichier.

Il serait utile de mentionner l'existence de ce répertoire dans le README

Comme on a récemment parlé de ce document dans la communauté de l'enseignement supérieur et de la recherche, je me demandais si nous faisions à la base partie du public visé.

Dans ce cas, il faudrait peut-être généraliser la notion de nom de domaine professionnel au-delà du seul *.gouv.fr, car l'ESR présente une très grande diversité d'autres noms de domaines incluant de simples .fr (universités), .cnrs.fr (CNRS national), .in2p3.fr et consorts (instituts du CNRS), etc...

Un petit coup de pandoc, de Sphinx ou de gitbook, et zou... un PDF facile à lire offline.

De même que le RGS est mentionné (ainsi que le RGAA), il serait pertinent d'ajouter une invitation à suivre le RGI (Référentiel Général d'Interopérabilité)

(Je m'exprime au nom de l'ADULLACT, mon employeur.)

Github est le lieu de rencontre n°1 pour les développeurs, cependant il nous semble utile de rappeler que c'est :

• un service en ligne (pas un logiciel),
• gratuit dans certains cas, mais avant tout propriétaire,
• américain,
• hébergeant ses données hors de France et hors de l'Europe.

Cela nous rappelle 2002 : soucieux du patrimoine logiciel libre nous (ADULLACT) observions que Sourceforge était un service (gratuit mais pas que), qui n'hébergeait pas en France. Nous décidions de pousser les développements de Gforge. L'ADULLACT a convaincu l'État (AdmiSource) puis l'Europe (OSOR -> JoinUp) de la nécessité d'un entrepôt opéré par la puissance publique.

Les Archives de France ont été créés en 1790 lorsqu'on s'est préoccupé du patrimoine commun.

Le point le plus important est certainement de rappeler que l'hébergement de programmes et données hors de l'Europe n'est pas recommandé, mais peut aussi présenter un risque pour la souveraineté d'un pays.

Rappelons qu'un logiciel libre développé par une administration est considéré comme un patrimoine national ; pourquoi déposer ce patrimoine à l'étranger ? (Construirait-on les Archives Nationales aux États-Unis ?)

Rappelons aussi que Git permet d'héberger ses codes source sur la plateforme de son choix (Framagit, Gitlab Adullact, serveur propre...) et d'en faire un miroir vers Github pour concilier visibilité et indépendance. Exemples : mirroir Github serveur Apache, ou Miroir GitHub outil Gitlab. L'ADULLACT se tient à la disposition des services de l'État pour les accompagner dans cette démarche.

(Je m'exprime au nom de l'ADULLACT, mon employeur.)

Oh man, just had this page shared with me, and I really appreciate it!
https://disic.github.io/politique-de-contribution-open-source/en/gouvernance/

I love that you make the "suggest edit" button prominently available :)

I wanted to make a small suggestion for consideration. Right now, this button directs to:
https://github.com/DISIC/politique-de-contribution-open-source/edit/EnglishVersion/gouvernance.en.md

For those without access, that page has great instructions, but there is a small extra step of forking.

I was going to suggest that the French Government investigate either 1) using hosted Prose.io, or 2) self-hosting it's own version (since it's open source). This would allow the button to link here:
https://prose.io/#DISIC/politique-de-contribution-open-source/edit/EnglishVersion/gouvernance.en.md

The bonus side of using this tool is that, if you really like it, you can move to self-hosting, at which point you can start customizing it to the needs of public servants. For example, it could offer extra interface elements for GitHub users who are members of government GitHub organizations, to sidestep any pitfalls that are unique to public servants.

Anyhow, thanks very much for considering! I'm always eager to hear your thoughts, in case I end up having conversations with public servants in Canada :)

Maud n'est (malheureusement) plus dans la DINSIC et devrait donc être retirée du fichier

Je propose de recommander de rendre public son appartenance à une organisation gouvernemental. C'est important pour pouvoir être contacter. Par exemple, la plupart des membres de DISIC sont privés. On ne sait donc pas qui se cache derrière l'organisation, qui contacter, etc.

Éviter les URL brutes

Bonjour,
Serait-il pertinent dans le cadre de cette politique d'aborder les contributions hors code, comme la participation sur les différents canaux de discussion d'un projet ?

Voir par exemple : https://opensource.guide/how-to-contribute/#you-dont-have-to-contribute-code

Sans entrer dans des débats idéologiques (car en pratique, les licences recommandées sont celles de la FSF et de l'OSI), il faudrait remplacer "open source" par "libre" qui est l'expression figurant dans la loi pour une République Numérique (article 16).

Recommander les licences permissives dans le cas général, au détriment des licences avec réciprocité, soulève un problème de taille quand il s'agit d'argent public.

En effet une licence permissive autorise une entité à s'approprier un bien commun pour en retirer des bénéfices exclusifs. Quand de l'argent public est utilisé pour construire un bien commun, il est légitime que les tous les citoyens puissent s'en servir. Par contre si un citoyen ou une entreprise l'améliore, sans partager l'amélioration, et commercialise le résultat, ceci a deux conséquences :

• il en tire un bénéfice dont il a seul le profit alors que la construction a été l'effort de tous (argent public)
• la dynamique vertueuse de contributions autour d'un bien commun libre est désamorcée, et n'incite plus à contribuer ("pourquoi je partagerais avec des gens qui, non seulement ne partagent pas, mais en plus s'enrichissent sur mon dos ?")

Nous (ADULLACT) recommandons au contraire d'utiliser une licence avec réciprocité pour tout ce qui concerne les logiciels libres métiers, par exemple des logiciels de gestion de courrier, de délibération, de signature, etc. Il s'agit de préserver le patrimoine public.

(Je m'exprime au nom de l'ADULLACT, mon employeur.)

Dans pratique.md il y est listé un certain nombre de plateformes dont certaines ne sont pas dans l'espace européen.

Or, l'arrivée en mai 2018 du Règlement Général sur le Protection des Données (alias RGPD) impose que le donneur d'ordre s’assure du respect du règlement pour ses sous-traitants.

RGPD article 4 en vigueur en mai 2018 :
http://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32016R0679&from=FR

«données à caractère personnel», toute information se rapportant à une personne physique identifiée ou identifiable (ci-après dénommée «personne concernée»); est réputée être une «personne physique identifiable» une personne physique qui peut être identifiée, directement ou indirectement, notamment par référence à un identifiant, tel qu'un nom, un numéro d'identification, des données de localisation, un identifiant en ligne, ou à un ou plusieurs éléments spécifiques propres à son identité physique, physiologique, génétique, psychique, économique, culturelle ou sociale;

Loi informatique et libertés article 35 en vigueur en mai 2018 :
https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=4B84F0488CAE26AB4E5BEC84F101F724.tplgfr31s_2?cidTexte=LEGITEXT000006068624&dateTexte=20180525#LEGIARTI000006528134

Toute personne traitant des données à caractère personnel pour le compte du responsable du traitement est considérée comme un sous-traitant au sens de la présente loi.

RGPD article 28 en vigueur en mai 2018 :
http://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32016R0679&from=FR

Lorsqu'un traitement doit être effectué pour le compte d'un responsable du traitement, celui-ci fait uniquement appel à des sous-traitants qui présentent des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées de manière à ce que le traitement réponde aux exigences du présent règlement et garantisse la protection des droits de la personne concernée.

Prenons l'exemple de la plateforme github, il y est impossible de supprimer un ticket. Ce ticket, ici présent, est lié à mon pseudo, mes nom et prénom sont à la portée d'un clic de souris. Pour autant, ce ticket n'est pas effaçable sauf à effacer le projet entier.

N'est-ce pas mettre les responsables de traitements publics dans une situation potentiellement hors la loi que d'utiliser les plateformes qui n'ont aucunes obligations relatives au règlement européen ?

(Je m'exprime au nom de l'ADULLACT, mon employeur.)

Sur la page pratique.md, dans la liste résumée, le premier point mentionne :

• Utilisation nécessaire d'un système de suivi de version distribué (git, bitbucket, mercurial)

Or Bitbucket est le nom d'une plate-forme (comme github ou gitlab par exemple) mais pas un système de suivi.

Je suggère de supprimer Bitbucket de cette phrase.

Bonjour,

Il pourrait être intéressant d'accompagner la politique d'une faq, qui permettrait d'en expliciter certains points sans alourdir le texte en lui-même.

De même que le RGS est mentionné, il serait de bon ton d'ajouter une invitation à suivre le RGAA (Référentiel Général d'Accessibilité des Administrations), afin d'être en conformité avec la loi République Numérique.

(Je m'exprime au nom de l'ADULLACT, mon employeur.)

La Politique de Contribution au Logiciel Libre sera reprise par d'autres services publiques comme les collectivités. Dans ce contexte on ne peut pas s'isoler de la langue française (cf discussion licences et loi Toubon).

Il nous semble impératif de citer :

• dans le cas des licences permissives : la CeCILL-B,
• dans le cas des licences avec réciprocité : la famille CeCILL v2 et CeCILL-C

(Je m'exprime au nom de l'ADULLACT, mon employeur.)

Certes Github invite les agents de l'État à travailler avec leur courriel en .gouv.fr, et cela permet d'en extraire des statistiques valorisantes.

L'ADULLACT annonce des travaux consistant à proposer le même outillage sur GitLab et instancié en premier lieu sur gitlab.adullact.net. Ces développements seront bien sûr sous licence libre et récupérables par tout un chacun. À noter qu'une collaboration avec la DINSIC serait la bienvenue et permettrait de valoriser les deux parties, en France et en Europe.

Quoi qu'il en soit le RGPD (Règlement Général de Protection des Données) s'impose. L'utilisation de services non respectueux du RGPD met en danger juridique le donneur d'ordre (l'État), cf discussion RGPD et plateformes non européennes. Dans le cas de l'utilisation d'une plateforme hors de l'Europe n'ayant aucune obligation de respect de cette réglementation, c'est le donneur d'ordre français qui est juridiquement responsable.

Il faut donc distinguer :

• "Git seul système de versionning", soit.
• Mais "Github plateforme unique de référence" semble inapproprié.

Un service privé hébergé à l'étranger ne peut pas être la plate-forme de référence de l'informatique d'un pays souverain. Il nous semble que la préconisation du choix "Gitlab hébergé en France avec miroir sur Github" est nécessaire.

(Je m'exprime au nom de l'ADULLACT, mon employeur.)

Voici la liste des commentaires ADULLACT sur la Politique de Contribution au Logiciel Libre.

• RGPD et plateformes non européennes
• Assertion incorrecte sur usage des licences permissives
• Recommandation de licences permissives dans le cas général
• Page Meilleures pratique : remarque globale
• Meilleures pratiques > Aide au choix de la plateforme
• Meilleures pratiques > Inventaire des comptes d’organisation
• Meilleures pratiques > Aide au choix de la licence
• Meilleures pratiques > Bonnes pratiques de développement
• Meilleures pratiques > Sécurité
• Meilleures pratiques > ajout Accessibilité / RGAA
• Meilleures pratiques > ajout Interopérabilité

Préciser que la validation d'une pull request dépend

• pour les modifications mineures d'un autre ministère que celui proposant la modification ;
• pour les modifications majeures de trois autres ministères (+ l'ANSSI) que celui proposant la modification.

La FAQ doit-elle également expliciter certains choix de la politique ? Je pense par exemple à DCO vs. CLA.

La page pratique, section "Inventaire des comptes d'organisation" mentionne le fait de s'inscrire sur GitHub governments et de se rajouter à https://github.com/github/government.github.com/blob/gh-pages/_data/governments.yml.

Il existe également un fichier OrgAccounts dans ce répertoire, qui semble être le plus utilisé.

Par ailleurs, un inventaire des dépôts de code est construit automatiquement à partir de ce fichier dans le répertoire https://github.com/etalab/data-codes-sources-fr.

Questions :

• Faut-il toujours se référencer sur GitHub governments ?
• Il me parait utile de demander aux personnes de s'ajouter dans OrgAccounts
• Peut-on dès à présent mentionner le répertoire https://github.com/etalab/data-codes-sources-fr ?

Bonsoir,

Je ne crois pas avoir vu ce point : celui de la "distribution" des packages au delà des sources ?

Outre gitlab ou github pour le code source, certains travaux/modules/données peuvent être publiées sur des plateformes tierces, registres... ex : npm, pypi, docker...

Je prends le cas d'un module JavaScript qui pourrait être partagé en open-source, il serait également distribué sur npm, et pour cela on aurait besoin de :

• définir un "author" dans la description du package;
• avoir un compte npm avec les droits sur l'organisation sur laquelle on publie

quelle convention adopter ?

a priori Etalab est le premier acteur FR a avoir fait cette démarche sur npm 👍 : https://www.npmjs.com/org/etalab

La section "Meilleures Pratiques" me semble parfois s'écarter un peu de la question de la politique open-source, et discuter de bonnes pratiques de développement logiciel en général. Par exemple, les pratiques de sécurité concernent tout le monde, même si l'open-source a des avantages et inconvénients spécifiques à ce niveau.

Je n'ai en soi absolument rien contre inclure de telles informations, mais je me demandais si il n'y aurait pas quelque part un autre document davantage concentré sur les bonnes pratiques de développement logiciel dans l'absolu, auquel cas ces recommandations pourraient y être incluses et la politique open-source serait alors modifiée pour y faire référence.

A moins bien sûr que le plan ne soit de déclarer qu'en tant qu'organisme orienté vers le service public, l'Etat se doit de publier tous ses codes en open-source, ce qui me surprendrait agréablement... mais je doute que des organismes comme le CEA ou la DGS[E|I] laisseraient passer une telle clause 😄

Pour mettre en oeuvre automatiquement les principes de gouvernance retenus dans https://github.com/DISIC/politique-de-contribution-open-source/blob/master/Gouvernance.md seriez-vous d'accord pour utiliser l'outil pullapprove.com ?

Bonjour,

Les fichiers Markdown de la POCOS sont aussi présents sur le répertoire numerique-gouv/numerique.gouv.fr : https://github.com/numerique-gouv/numerique.gouv.fr/tree/master/_politique-logiciel-libre.

Les issues doivent-elles être ouvertes ici ?

There is a space before the .md in this link here https://disic.github.io/politique-de-contribution-open-source/en/introduction/

USA 18F Open Source Policy:
https://github.com/18F/open-source-policy/blob/master/CONTRIBUTING.md

<li>USA 18F Open Source Policy:
                <br> <a href="https://github.com/18F/open-source-policy/blob/master/CONTRIBUTING .md">https://github.com/18F/open-source-policy/blob/master/CONTRIBUTING.md</a></li>

Il existe trois tags (v0.1, v0.2, v0.3), mais il existe cinq versions "manuelles":

0.1 : Initialisation (01/11/2017)
0.2 : Ouverture de l’appel à commentaires (06/12/2017)
0.3 : Fin de l’appel à commentaires (28/01/2018)
1.0RC01 : Projet soumi à validation (10/02/2018)
1.0 : Validation en CSIC Tech (16/02/2018)

Je propose de créer deux autres tags v1.0rc1 et v1.0 correspondant aux deux dernières, en prenant le dernier commit du jour 10/02/2018 et du 16/02/2018.

Création d'une version TXT de la LO pour remplacer le fichier PDF

Remarque globale : la page semble assez orientée dans ses exemples vers l'utilisation du service en ligne américain Github (solution propriétaire), au détriment d'autres solutions qui elles sont libres comme Gitlab ou Phabricator.

(Je m'exprime au nom de l'ADULLACT, mon employeur.)

La section qui décrit le DCO me parait incomplète https://www.numerique.gouv.fr/publications/politique-logiciel-libre/pratique/.

• Comment le mettre en pratique dans le cadre d'un projet ?
• S'agit-il de le faire signer en amont une fois pour toute ? de le demander à chaque contribution importante ?
• Quel est le lien avec le sign-off de git ?

Bonjour,

Vous conseillez d'utiliser des licences avec partage à l'identique pour un certain nombre de productions dans vos "principes d'ouverture"... Mais je ne trouve nulle part de référence aux licences concordantes.

Je pense bien à une CC ND (no derivative), mais celle-ci n'est surtout valable que pour les données ou du texte, pas vraiment pour des algorithmes (même si c'est envisageable, ce n'est pas très adapté).

En vous remerciant,

Si le fait de suivre les bonnes pratiques de développement est évidemment important, le fait de "descendre trop bas dans la technique" ne semble pas adapté. Mentionner certaines pratiques plutôt que d'autres ne semble pas adapté à un document de portée générale comme la Politique de Contribution au Logiciel Libre.

De plus, il semble très important que ces bonnes pratiques soient rédigées en français.

(Je m'exprime au nom de l'ADULLACT, mon employeur.)

Le texte actuel des Meilleures Pratiques dit « Toutes les entrées externes (e.g. de l’utilisateur) doivent être filtrées en explicitant uniquement les cas acceptés (filtrage par liste blanche) avant leur manipulation/stockage » Il pose plusieurs problèmes.

1. Ce n'est pas au moment du stockage qu'il faut tester les données, c'est surtout au moment de leur utilisation. En effet, la dangerosité éventuelle des données dépend de leur utilisation. Un citoyen a le droit d'avoir une apostrophe dans son nom propre, cela ne pose pas de problème si on exporte la base vers HTML mais est dangereux si on le fait vers SQL. C'est donc au moment de lutilisation qu'il faut prendre des précautions.

2. Le cas des bases de données est particulièrement difficile car on ne peut pas savoir à l'avance toutes les utilisations qui en seront faites. Vouloir empêcher le stockage de données problématiques va probablement mener à des faux négatifs (on accepte des données qui poseront ensuite des problèmes, parce qu'une utilisation n'avait pas été prévue) et des faux positifs (on refuse des données légitimes, comme ces innombrables applications de l'administration qui me refusent mon prénom en prétendant qu'il comporterait un « caractère illégal »).

3. La constitution d'une liste blanche est une opération délicate. Parfois, on n'a pas de référence sur laquelle s'appuyer (où est le document légal qui donne la liste des caractères acceptés dans l'état-civil français ?). Parfois, on en a une mais les programmeurs ne la lisent pas (exemple des formulaires qui testent la syntaxe des adresses email, non pas à partir de la grammaire normalisée mais à partir de leurs propres suppositions sur la syntaxe d'une adresse). Si on maintient ce conseil, il faudrait au minimum ajouter que la liste blanche doit être un document de référence (et ne pas venir de l'imagination du programmeur), document qu'on doit suivre au pied de la lettre.

Bonjour,

Je trouve délicat (et je sais qu'il s'agit souvent d'un "troll") la recommandation d'utiliser par défaut des licences permissives. Le danger est que ces licences permissives permettent à tout moment de recréer une enclosure et ne garantissent pas la réciprocité.

Mon avis est qu'il faut une réciprocité pour garantir une pérennité et éviter les spoliations. Contribuer, pour l'État à un logiciel libre, c'est engager l'argent public. En ce sens, il est difficile de concevoir que de l'argent public contribuant à un commun, voit des entités tierses le réutiliser, l'améliorer, sans contribuer également en retour. C'est comme si l'État investissait sans se soucier du rendement. Oui, la "viralité" ("avec obligation de réciprocité") d'une licence est une garantie de ne pas voir un potentiel contributif s'évaporer.

Ce sujet est un vieux sujet, longtemps débattu. Il ne faut pas de position de principe pour le régler, mais une position politique claire:

• l'État souhaite-t-il voir s'étendre le champ des communs à travers les logiciels libres ?
• l'État est-il prêt à voir s'échapper des contributions "communautaires" via une privatisation / une clôture des libertés qu'il a permises ?

Pour moi, pour Libre Informatique (éditeur de logiciels libres) et au moins en partie pour le Synpell, une licence permissive n'est pas suffisante. C'est toujours mieux que pas de logiciel libre du tout, mais c'est au moins perfectible. Notre proposition serait de rendre prioritaires des licences avec obligation de réciprocité.

Suggestion : dans https://github.com/DISIC/politique-de-contribution-open-source/blob/master/pratique.md mettre d’abord les éléments obligatoires, puis les éléments recommandés, puis les suggestions, et possiblement le mettre en avant dans les titres des chapitres

Fichier README.md
Ne devrait-on pas dire qu'il s'agit de la politique Open Source de l'état français ?