Licences permissives vs Licences avec obligation de réciprocité about politique-de-contribution-open-source HOT 10 CLOSED

Oui merci

from politique-de-contribution-open-source.

L'esprit de la politique n'est pas d'imposer un choix mais de proposer une doctrine sur l'utilisation de licences permissives ou avec obligation de réciprocité, les deux étant possibles.

Vous trouverez un commentaire avec une position inverse dans la discussion ci-dessous:
#27 (comment)

D'où l'argumentaire proposé sur https://github.com/DISIC/politique-de-contribution-open-source/blob/master/ouverture.md#recommandation-dutiliser-des-licences-permissives-dans-le-cas-g%C3%A9n%C3%A9ral

N'hésitez pas à le commentaire ou proposer un rationnel différent

from politique-de-contribution-open-source.

Le titre "Recommandation d'utiliser des licences permissives dans le cas général" n'est alors pas vraiment pertinent car il indique un choix par défaut pour les licences permissives alors que le contenu diffère un peu.

Cela dit, si je comprends le sens de l'argumentaire, je trouve que sa conclusion ("privilégier les licences permissives pour les services de base ou d'infrastructure") est un peu rapide. Libre Informatique, par exemple privilégie des licences garantissant la réciprocité tout en étant plus permissives, comme la LGPL.

Privilégier des licences permissives pour les productions publiques, pour nous, revient à permettre des enclosures sur des biens produits par l'argent public. Cela ne devrait pas être politiquement acceptable.

Si le but est l'interopérabilité, alors il conviendrait de privilégier des licences garantissant la réciprocité mais à contraintes moins fortes, comme la LGPL.

Bonne réception,

from politique-de-contribution-open-source.

La licence LGPL correspond à une licence GPL, à laquelle on rajoute des exceptions précises. Si elle est plus "permissive" au final, sa construction est plus complexe : les exceptions visent essentiellement les bibliothèques et la possibilité de lier dynamiquement. Nous sommes donc d'accord qu'elle n'est en rien une licence permissive.

Tout d'abord, la LGPL figure bien dans la liste des licences avec obligation de réciprocité qui peuvent être utilisées par l'administration sur http://www.data.gouv.fr/fr/licences

revient à permettre des enclosures sur des biens produits par l'argent public.

Une licence permissive permet effectivement une réappropriation pour produire des logiciels propriétaires, ce qui peut être une bonne chose pour qu'un acteur privé puisse proposer et facturer des services à valeur ajoutée.

Votre question n'est donc pas une question sur les licences car vous conviendrez que la LGPL fait bien partie de licences avec obligation de réciprocité. Votre cas d'usage est donc de garantir que toute modification ultérieure au code produit par l'administration puisse revenir à l'administration (même si le code développé par un tiers puisse rester propriétaire). Vous présentez la LGPL comme une solution, alors que ni la GPL ni elle ne donnent ces garanties, et il faudrait tout mettre tout en AGPL avec une contamination qui n'est pas souhaitée. Des licences "file based" comme la mozilla public license peuvent être plus appropriées que la LGPL mais n’empêcheront pas une société de proposer un service en ligne propriétaire.

Il est donc impossible de généraliser, et la licence de chaque logiciel doit être pensée en fonction des différents cas d'usage visé par l'administration. Les ré-utilisateurs trouveront vite leur intérêt à reverser leurs modifications pour éviter l'effort de maintenance à devoir tout réintégrer downstream, et ce, même avec des licences permissives.

from politique-de-contribution-open-source.

Une licence permissive permet effectivement une réappropriation pour produire des logiciels propriétaires, ce qui peut être une bonne chose pour qu'un acteur privé puisse proposer et facturer des services à valeur ajoutée.

En tant que dirigeant d'une société membre du Syndicat Professionnel des Éditeurs de Logiciels Libres, je dois préciser que cette assertion ne doit surtout pas être prise pour postulat. Faire un lien direct entre "réappropriation" et "[facturation de] valeur ajoutée", induit l'idée que nous (les membres du Synpell) réfutons : les enclosures ne sont pas le meilleur moyen de produire de la valeur ajouté. C'est juste le moyen utilisé par un système dominant préférant l'analyse d'un patrimoine à l'analyse d'une activité. De plus, alors que l'État se veut principal défenseur de l'intérêt général, il m'est difficile d'accepter une telle position qui va à son encontre.

Vous présentez la LGPL comme une solution

Je ne présente pas LA solution, mais UNE orientation qui me semble plus souhaitable que d'autres. Effectivement la LGPL ne donne aucune garantie sur le fait qu'un code développé en interne (sans diffusion/distribution) sur base de code ouvert reste ouvert (ce qu'aucune licence ne peut permettre, y compris la AGPL, car c'est la loi qui garantit cela à travers, de mémoire, le droit à la copie privée).

Il est donc impossible de généraliser

Ma proposition était de préconiser davantage des licences avec garantie de réciprocité, quitte à préférer la LGPL permettant plus de souplesse, plutôt que de préconiser a priori des "licences permissives" qui ne travaillent pas dans le sens de l'intérêt général, permettant des enclosures.

Pour moi la position "Les ré-utilisateurs trouveront vite leur intérêt à reverser leurs modifications pour éviter l'effort de maintenance à devoir tout réintégrer downstream, et ce, même avec des licences permissives." va dans le sens de l'intérêt général, mais son applicabilité effective s'appuie sur une hypothèse. Les licences avec garantie de réciprocité s'appuient sur du droit.

from politique-de-contribution-open-source.

Il me semble que je suis d'accord avec @betaglop .

Une licence permissive laisse la possibilité de s'approprier un code pour profiter de ce dernier sans participer à la construction de cette maison commune. L'argent public, se constitue par nos impôts à tous. S'il est investi dans de la production de logiciels, je ne vois pas pourquoi ce code devrait sortir de notre maison commun en ne profitant pas à tous. Si l'objectif de l'état est de constituer un bien commun, seules les licences non permissives comme GPL, AGPL et CECILL devraient êtes recommandées. Et eu égard à la raison de la création de CECILL et de la loi dite Toubon (article 2) pour l'usage du français, seule la CECILL reste en lice.

Loi Toubon article 2 :
https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=LEGITEXT000005616341#LEGIARTI000006421210

Le mode d'emploi ou d'utilisation, la description de l'étendue et des conditions de garantie d'un bien, d'un produit ou d'un service, ainsi que dans les factures et quittances, l'emploi de la langue française est obligatoire.

Pourquoi CECILL :
http://www.cecill.info/faq.fr.html#pourquoi-cecill

Quant au #27 indiqué par @ljoubert, il traite du domaine public. C'est un hors sujet puisque nous parlons de logiciel libre et donc de code dont l'usage est restreint par la loi de par la licence.

from politique-de-contribution-open-source.

Pour la discussion sur permissives vs obligation de réciprocité je vous propose de continuer sur le fil de discussion #50 et de discuter ici des débats sur la loi Toubon.

from politique-de-contribution-open-source.

Sur l'impact de la loi Toubon au niveau des licences utilisables par l'administration, je ne reviendrai pas sur le décret qui a été publié: https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000034502557&categorieLien=id

Des traductions des licences pourront être mises à dispositions.

J'en profite pour évoquer la langue utilisée dans le code source dans les commentaires et le nom des fonctions ou des variables utilisées. Si la documentation doit effectivement être mise à disposition en Français pour tout nouveau développement contribué par l'administration, celle-ci peut publier du code dans la langue de son choix en fonction de la communauté de développeurs et du niveau de collaboration internationale visé. A rajouter dans la FAQ ?

from politique-de-contribution-open-source.

Oui précision utile dans la FAQ :)

from politique-de-contribution-open-source.

Il me semble que la FAQ contient déjà cette précision sur les langues autorisées tout à la fin. @revolunet tu confirmes et je peux fermer cette issue?

from politique-de-contribution-open-source.