arnaudus a écrit 5317 commentaires

Au final, je trouve ça étrange à minima que différencier les droits accordés en fonction du moyen technique utilisé pour établir une relation de dépendance totale ou partielle.

En plus, c'est contournable dans la plupart des cas. La FAQ GPL de la FSF est particulièrement tortueuse (la plupart du temps, la réponse commence par "it depends"), mais l'idée, c'est que la liaison (dynamique ou statique, aucune raison de faire la différence) est "contaminante", mais ce n'est pas le cas quand on "utilise" un programme. Du coup, on peut avoir l'idée de créer un petit main() de rien du tout sous GPL qui lit quelque chose sur sur l'entrée standard, utilise une bibliothèque GPL, et sort le résultat sur la sortie standard; il est alors possible d'interfacer le programme --- évidemment, il y a un problème de perfs, mais il n'y a pas de raison que ça soit rédibitoire, par exemple pour un truc qui résoud des problèmes compliqués (échecs, gros système d'équation, etc). Bref, ces histoires techniques (qui apparaissent dans la FAQ mais pas dans le texte de la licence lui-même) rendent tout un peu incertain, avec en arrière-plan l'idée que "si vous n'êtes pas sûrs, mettez tout sous GPL".

Bon, de la à dire que ça sert à quelque chose, il y a un pas que je n'oserais franchir hein :)

Si l'exécutable appelle la libc de manière dynamique et va chercher des infos dans différents modules, ça peut être un diagnostic pour vérifier que l'ensemble est bien installé? Autrement, je ne vois pas…

Il n'est pas question d'hérédité avec la gpl puisqu'elle impose sa licence au code lié

La GPL impose aussi sa licence au code dérivé, donc là, on peut en effet parler d'hérédité. Contrairement à d'autres licences, qui n'imposent pas la licence du code dérivé.

Mais ça n'est juste pas ce dont on parlait ici. La GPL impose une licence au code réellement dérivé (et ça, c'est le principe du copyleft), et elle tente aussi d'imposer (tout du moins c'est l'interprétation de la FSF, parce que le texte de la GPL n'est pas du tout convainquant là-dessus) sa licence au code lié, en prétendant que la liaison fait du logiciel une œuvre dérivée des bibliothèques.

L'histoire des ambiguités de la FSF est probablement intéressante, mais je n'ai pas vraiment le temps ni l'envie d'aller mettre les mains dans le cambouis. Plusieurs projets sous GPL ont ressenti très tôt le besoin de clarifier la situation, en mettant leur code sous licence GPL-non-virale (typiquement, le kernel Linux, la libc proposée par gcc, la STL C++ de g++, etc). La publication de la LGPL a permi de clarifier les choses pour les bibliothèques sous LGPL, mais paradoxalement, ça n'a pas réellement clarifié les choses pour les bibliothèques sous GPL, puisque ça pourrait donner l'impression que la viralité prétendue de la GPL est établie, ce qui n'est pas le cas.

Après, personne ne prétend que l'interprétation de la FSF est totallement illégitime, puisque si je ne m'abuse, le modèle commercial de plusieurs entreprises a été ou est toujours basé dessus (la lib est disponible sous GPL et sous licence proprio payante, si tu fais du GPL tu peux utiliser la version GPL gratuitement, si tu fais du proprio il faut raquer). Mais disons que dans ce cas, c'est plutôt la menace de procès qui est dissuasive (payer la licence proprio est probablement moins cher que de s'engager dans un bras de fer judiciaire sur un des points les plus compliqués de la licence GPL); ça ne prouve pas réellement que la FSF est dans son droit là-dessus

tu peux même publier ton source contenant ton include, sans aucune préoccupation vis à vis de la licence du projet truc (GPL ou non), et sans aucune inquiétude de quelque sorte.

Ah bah oui, bien sûr, il n'y a aucune raison de s'inquiéter de ne jamais pouvoir dstribuer une version binaire d'un logiciel, ou de faire en sorte que son logiciel ne puisse jamais être inclus dans une distribution. Et en plus, c que tu dis est faux, puisque ça dépend du contenu du .h. S'il ne contient que des déclarations, des struct, et des choses comme ça, alors c'est probablement vrai. S'il contient du code (des templates, des trucs inline, etc), alors ça n'est probablement plus vrai. Tu ne peux donc pas faire une généralité à partir de ça.

On peut étudier la justesse de l'équité de la relation que tente d'établir la GPL

Euh, désolé, mais la justesse et l'équité, on s'en fout complètement, non? Respecter ou non les clauses de la GPL n'a rien à voir avec des questions de justesse ou d'équité ; si quelqu'un respecte les termes de la GPL sans respecter aucune équité, il ne risque rien ; si quelqu'un respecte les principes généraux du logiciel libre sans respecter les clauses de la GPL, il risque quelque chose.

L'auteur usager à accepté l'offre et en a profité mais est libre de ne pas le faire.

Si certaines clauses sont illégales, abusives, ou si elles sont ambigües et comprises différemment par l'utilisateur du logiciel que par l'auteur, alors non, ça ne marche pas du tout.

ça sent un peu l'arnaque intellectuelle

Poutre, paille, tout ça. Tu réponds des généralités à un problème concret, celui d'une extension du concept d'«œuvre dérivée» qu'on peut légitimement considérer comme abusive, de manière à créer une possibilité de «viralité» qui n'est pas prévue (à ma connaissance) dans les différents droits afférents à la propriété intellectuelle.

La liaison (statique ou dynamique, ça n'a pas beaucoup d'importance) d'une bibliothèque fait partie de son fonctionnement normal (et on peut même aller plus loin, c'est même sa seule modalité de fonctionnement). Par ailleurs, en Europe, l'interopérabilité est protégée (on n'a pas à signer de quelconque contrat, licence, ou quoi que ce soit pour écrire un driver, par exemple, et larétro-ingénierie est autorisée à des fins d'interopérabilité). Bref, il existe plein de raisons pour penser que l'idée d'une liaison équivalente à une œuvre dérivée est douteuse, et que cette «viralité», défendue mordicus par la FSF, et qui n'est clairement pas présente dans le code de la GPL, reste une interprétation. Sans jurisprudence bien établie, c'est quand même assez flou, cette histoire.

je pense que nous sommes des nains consommateurs de logiciels juchés sur les épaules des géantes communautés.

C'est évidemment vrai, mais je ne vois pas le rapport. Sans compilateur, on ne pourrait rien faire, et pourtant, le compilateur n'impose aucune restriction sur les licences des logiciels. Idem pour l'OS ou pour à peu près n'importe quel logiciel.

Je ne suis pas sûr que le terme de "viralité" appliqué à la GPL se réfère spécifiquement à l'hérédité telle que tu la définis.

Tu n'es probablement pas sans savoir que la FSF fait une interpétation assez particulière et assez discutable du concept de "derivative work". Tout le monde est d'accord pour dire que si tu prends un bout de code et que tu le modifies, ton travail est dérivé. De la même manière qu'une traduction de roman, par exemple. La partie "virale" discutable de la GPL repose sur l'affirmation qu'une inclusion ou un lien statique ou dynamique sont également suffisants pour définir un travail dérivé. Le problème me semble assez évident ; pour le commun des mortels, faire #include "truc.h" et lier la bibliothèque ltruc à la compilation est difficilement traduisible par le concept "mon logiciel est un travail dérivé de la bibliothèque truc". On utilise les fonctions de la bibliothèque, on est dépendant de cette bibliothèque, mais techniquement, notre travail n'est pas une modification de cette bibliothèque, de la même manière qu'une traduction est une modification du roman initial. La situation comparable serait l'écriture d'un,roman qui fait référence à quelques lieux, personnages, ou anecdotes d'autres romans. C'est le genre de situations qui méritent d'être jugées, parce que lancer des grandes conclusions a priori sans regarder en détail la quantité et la nature des emprunts semble assez prématuré.

De la même manière, prétendre qu'un logiciel entier est un travail dérivé d'une petite bibliothèque dont deux fonctions et demi sont utilisées dans un bout de code facultatif, ça semble assez prétentieux. C'est l'interprétation "virale" de la FSF, mais ça n'est qu'une interprétation, parce que ça n'est pas du tout évident à la lecture de la GPL (et d'ailleurs, on trouve sur le Ternet plein de billets écrits par des juristes qui remettent en cause cette interprétation).

Bah, surtout, je trouve que ça casse l'idée de séparer les combats. On est tous différents, on a tous nos petites marottes, les choses qu'on pense importantes, les choses qu'on déteste, et les choses sur lesquelles on n'a pas d'option, voire dont on se fout totalement.

Si on veut faire avancer le logiciel libre, il est cohérent d'être intransigeant sur le logiciel libre. On a le droit d'être strict, voire sectaire (par exemple, ne pas publier de binaire pour Windows). Évidemment, un débat peut s'ouvrir : est-ce qu'on fait réellement progresser le LL si on ne fournit pas de LL pour les systèmes proprio. Disons que l'intransigeance se défend dans ce cas, même si elle n'est peut-être pas la plus efficace.

Par contre, si on commence à mélanger les combats, on va aboutir à une situation qu'on ne peut plus faire avancer. On a le droit d'être à la fois libriste, féministe, écolo, et antifasciste. Mais il serait débile de mettre sur une page de téléchargement d'un logiciel "Électeur du FN: passe ton chemin", ou bien "Les contributions par les conducteurs de SUV ne sont pas acceptées". C'est juste qu'on devient sectaire, on essaye d'imposer tous ses combats à la fois, et à chaque nouvelle exigence, on perd une partie du public. Clairement, ce qu'on souhaite, c'est finir en "bande de potes" version ado, des gens qui ont (ou qui prétendent avoir) les mêmes idées sur tout. Ça n'a, à mon avis, aucun intérêt, et ça montre surtout qu'en fait, on n'a pas vraiment envie de faire progresser individuellement chaqun des thèmes qui nous tiennent à cœur.

Une annonce en écriture inclusive, ça n'a aucun intérêt, ça prend juste le risque d'éloigner des contributeurs ou des utilisateurs parce qu'on n'a pas compris l'intérêt de séparer les combats. Personnellement, je ne supporte pas l'écriture inclusive, et je pense qu'elle nuit à l'égalité homme-femme de la même manière qu'un mauvais commercial nuit à une négociation en commençant par des prétentions excessives ou ridicules. Et ça entache complètement le fond de l'annonce.

De toutes manières, il est indéniable que ce texte ne nous concerne pas, et que les destinataires sont les gens de Framasoft. Il est possible qu'ils le trouvent ici, mais ça n'est pas la meilleure façon de procéder.

Ça, c'est sur la forme. Sur le fond, je ne suis même pas convaincu que ce texte ait du sens. Les paragraphes que j'ai l'impression de comprendre sont une sorte de bullshitage fumeux à base de mot-clés.

Pourquoi ne pas le transformer en crédit d'impôt ?

Au delà du bête argument budgétaire, mon interprétation du système c'est plutôt que de déclarer un don revient à choisir d'orienter une partie de son impôt vers une association (c'est une manière de participer à la politique de financement des associations).

Si tu dois payer 1000€ d'impôts et que tu as 10000€ de revenu, il te reste 9000€ pour vivre. Si tu fais un don de 300€, tu te retrouves avec 8900€ pour vivre, 800€ d'impôts qui vont à l'État , et tu "orientes" 200€ de tes impôts vers une association (c'est comme si tu payais tes 1000€ d'impôts mais que tu forçais l'État à en redonner 200 vers l'association de ton choix). De manière assez logique, il est impossible d'orienter une partie de ses impôts quand on n'en paye pas.

Finalement, le seul truc bizarre du système, c'est qu'on rembourse le particulier (ce qui donne l'impression d'un cadeau ou d'une défiscalisation), alors qu'il serait beaucoup plus logique que les dons soient non-déductibles mais que l'argent arrive dans les caisses de l'association. Ça reviendrait au même au niveau comptable, mais symboliquement, ça change tout.

Il faut garder à l'esprit qu'il n'est pas obligatoire de déclarer ses dons, ce qui revient à considérer que l'argent des impôts est aussi bien dépensé par l'État.

C’est mal connaître la philosophie de Google que de dire ça.

Je ne comprends pas. L'OP dit "YouTube […] ne plante quasiment jamais", et ta réponse cite "the marginal difference between 99.999% and 100% gets lost in the noise of other unavailability". Est-ce qu'un service disponible 99.999% du temps n'est pas plus ou moins exactement un service qui ne plante quasiment jamais?

J'aurais dû lire la FAQ avant de poser des questions :-) Si j'ai bien compris, j'ai confondu les instances fédérées (qui partagent les métadonnées sans partager les vidéos) et les instances miroir (qui partagent tout).

Ceci dit, la FAQ semble être sûre d'elle quand elle décrit la manière dont les vidéos potentiellement illicites ou hors-charte sont rapportées aux administrateurs de l'instance où la vidéo est hébergée (et pas aux administrateurs des instances fédérées), mais je serais plus dubitatif. Ça me semble un peu douteux qu'un visiteur puisse visionner une vidéo hors-charte à partir de mon instance, et que je puisse m'en laver les mains aussi facilement, en prétendant que ça n'est pas moi qui l'héberge. C'est à peu près la même situation qu'un moteur de recherche, il y a une forme de complicité à servir d'intermédiaire naïf pour trouver un fichier peu recommandable (qu'il s'agisse de contenu illégal, immoral, ou n'importe quoi).

Si j'ai bien compris, Peertube offre une solution technique pour l'hébergement et la diffusion de vidéos (ce qui n'est pas rien), mais dans quel état se trouve la partie "réseau social"? Si on prend une plateforme comme Youtube, son utilité en tant qu'hébergeur n'est pas réellement prépondérante. Un intérêt majeur de Youtube est d'offir un moteur de recherche dans sa base de données de vidéos, qui permet 1) de fournir des listes de vidéos pertinentes à la suite d'une requête, et 2) de fournir ces fameuses "suggestions", qui, si elles sont bien utilisées, peuvent être d'une intérêt majeur (zapper vers quelque chose de plus prometteur quand on s'ennuie, se voir proposer un point de vue alternatif…). Or, pour offrir un tel service avec PeerTube, il faudrait une grosse base de données partagée entre de nombreuses instances pour un moteur de recherche (l'alternative consisterait en la mise en place d'une grosse instance, mais évidemment la décentralisation en prend un coup). Comment ça peut fonctionner concrètement?

L'autre question de fond reste la responsabilité des hébergeurs sur les contenus diffusés, qui risque de limiter la coopération entre les instances. On peut imaginer des chaînes d'instances de confiance, mais existe-t-il par exemple la possibilité de communiquer des listes de vidéos à supprimer entre instances "partenaires"?

Le builder est un outil du développeurs, pas un système de packaging.

Si c'était vrai, tu te distribuerais pas le système de build avec tes sources (tu ne distribues pas les options de ton IDE, ni ton compilateur…). Le fait d'avoir une cible "install" montre bien que tu distribues un pseudo-paquet.

Sauf que ça reste quand même assez limité, étant donné l'obligation de dénonciation des crimes et délits à laquelle sont soumis tous les fonctionnaires (article 40 du code de procédure pénale). La dénonciation passe directement par le procureur, en théorie. En pratique, l'administration fait tout pour faire croire qu'il existe une voie hiérarchique à respecter, pour de bonnes et de mauvaises raisons.

Si meson ou CMake s'imposent tout doucement comme outils de développement pour les projets d'envergures

L'intention n'était évidemment pas d'empêcher les gens d'utiliser un système de build différent de GNU make et autotools. Je trouve juste que ces systèmes alternatifs auraient pu faire l'effort de fournir une interface à peu près normalisée afin qu'il soit trivial de passer de l'un à l'autre, voire de complètement abstraire la procédure de compilation derrière une interface unique.

Bref, pour l'utilisateur lambda, ce n'est pas franchement plus compliqué à mon sens.

Ce qui est compliqué, c'est d'avoir une procédure différente pour chaque machin que tu veux compiler, en fonction des préférences du développeur. Ton raisonnement pourrait être poussé à l'extrême; si le dev a mis au point son propre système de build et qu'il te faut taper "gogo-gadget o compilateur", tu vas trouver ça débile, même si c'est marqué dans le README.

Ça n'est pas non plus pour rien qu'il y a des standards de facto, et je trouve que la compilation se prêterait justement pas mal à avoir une procédure un peu normalisée (avec un certain nombre de cibles standard: clean, make, install, etc). J'imagine aussi que ça simplifierait pas mal la vie aux différentes distributions, et que ça réduirait la fragmentation.

Tu réalises que Ninja est un remplaçant à Make ?

Non, ça n'est pas un remplaçant, et c'est bien ça le problème. systemd est un remplaçant à sysVinit, mais ninja est une alternative à make. Tu es donc exactement dans la situation décrite par le xkcd ; tu crées un système alternatif avec l'espoir qu'il remplace à terme l'existant, mais tu crées juste une nouvelle syntaxe qui s'additionne aux systèmes de build alternatifs qui existent.

Si au lieu de remplacer une brique par une autre équivalente tu préfères rajouter un wrapper et une nouvelle dépendance, t'es pas sorti de l'auberge…

Une dépendance à GNU make sur une distribution linux? C'est le genre de dépendance qu'on peut certainement assumer, non? En plus, la dépendance peut très facilement sauter si ton système de configuration fait en sorte de tester la présence de make sur le système.

Je pense justement que le coût d'une dépendance à un logiciel qui est installé par défaut sur la quasi-totalité des distributions et un wrapper trivial est minime par rapport au coût d'être dans l'inconnu total quand tu télécharges un .tar.gz.

Je crois que je comprend un peu ce que veut dire l'OP. La réalité, c'est que la diversité dans les systèmes de build est incoutournable, et qu'il n'est pas réaliste de faire comme si elle n'existait pas. L'avantage avec les autotools, c'est que quand on téléchargeait un tar.gz, on savait qu'il fallait faire ./configure && make && sudo make install. Là, chaque système de build vient avec une syntaxe à lui. Bien sûr, la réponse évidente, c'est "il suffit de remplacer make par ninja, et truc par machin, et de rajouter l'option --bidule = target, rien de bien sorcier. Sauf que chaque système de build concurrent va venir avec sa syntaxe, et que connaitre les syntaxes des 12 systèmes de build courants, ça va être possible pour un admin sys, mais pas pour quelqu'un qui installe un truc hors paquet de sa distrib tous les six mois.

Moi je trouve que les trois étapes "configuration", "compilation", "installation" sont très claires, et qu'il existait déja une syntaxe (pas forcément très logique, pas forcément intuitive, mais elle avait le mérite d'exister). Pourquoi ne pas s'être débrouillé pour que tout système de build génère par défaut un exécutable "configure" dans le répertoire, un Makefile minimal de trois lignes qui appelle ninja ou n'importe quoi d'autre, avec une cible "install" qui installe le truc? C'est ça le problème, c'est l'apparition de nouvelles syntaxes pour faire la même chose qu'avant.

Wikipédia semble lister un grand nombre de langages compilés et reflexifs (Go, objective-C, etc). Je ne les pratique pas, donc je ne sais pas vraiment de quel type de reflexivité on parle, mais j'ai quand même l'intuition que la reflexivité ou la méta-programmation doit empêcher la plupart de l'élimitation de code mort ou de code non-utilisé.

J'imagine que comme toute grande entreprise, les compétences initiales sont noyées dans la lourdeur, la bureaucratie, les décisions de décideurs qui ont une formation top-moumoutte en prise de décisions décisionnelles… Parce que ça ne date pas de Gmail, la "mise à jour" de Google maps d'il y a quelques années ont transformé un site incoutournable en quelque chose de quasi inutilisable. À se demander si Google ne se reconvertit pas dans le minage de bitcoins…

Je ne suis pas sûr qu'il soit aussi simple de détecter les bouts de code qui ne seront jamais appelés (et quand tu compiles statiquement, est-ce que tu veux vraiment que le compilo choisisse ce qui est lié et ce qui ne l'est pas?). Mais de toutes manières, ça pose une énième fois la balance entre la liaison dynamique et la liaison statique, c'est toujours aussi compliqué.

Sur le fond, c'est dur de lui donner tort, sur la forme, il y a des trucs douteux. L'exemple des compilateurs, par exemple. Pourquoi compiler du C++ prend des plombes? En grande partie, parce que c'est une tâche hyper complexe, du fait de l'évolution du langage vers de plus en plus de trucs à faire au moment de la compilation (y compris l'optimisation). Pourquoi afficher des trucs prend des plombes? En partie, parce que le nombre de pixels n'a pas augmenté linéairement dans le temps, en partie aussi parce qu'on a amélioré les algorithmes d'affichage (sub-pixellisation, etc), en partie parce qu'on a complexifié les choses à afficher (transparence, coins arrondis…). Nier que les ordinateurs d'aujourd'hui font aussi des tâches beaucoup plus complexes, ça rend quand même l'argument moins pertinent.

Tout grossit aussi parce que les briques de base s'améliorent en terme de fonctionnalités. Ça me semble être une évolution difficile à enrayer pour les bibliothèques de base, par exemple : "et si vous faisiez ci, et si vous faisiez ça", avec l'argument de "mais votre concurrent X le fait!". Un exemple tout con, c'est par exemple d'avoir besoin de fonctions mathématiques pas complètement courantes (je ne sais pas, la fonction probit dans un programme en C, par exemple). Idéalement, il faudrait quoi? apt install lprobit-dev et #include "probit.h", chacun contenant quelques lignes de code? Ça ne marche pas comme ça. Il va falloir installer un gros paquet contenant des centaines ou des milliers de fonctions (boost?), puis appeler un gros .h qui va inclure d'autres .h qui vont inclure d'autres trucs, et voila, ça y est, on a bloaté son système et son logiciel. Honnêtement, j'ai du mal à imaginer de vraies alternatives.

Ça permet de pouvoir le poursuivre. D'une manière générale, c'est de toutes manières le seul but des licences, non? Je ne connais pas de licence qui empêche physiquement quelqu'un de faire ce qu'il veut avec le code.

Après, tu peux diffuser sous copyright strict ; le code ne peut être reproduit ou diffusé de quelque manière que ce soit. Ajouter des termes de licences non-libres mais garantissant la libre diffusion offre la possibilité de contrôler ce que les gens ont le droit de faire ou non avec le code. Je ne prétends pas que c'est bien ou que c'est mal (en l'occurrence je crois que ça n'a que peu d'intérêt dans le cas dont on discute).

Ceci dit, pour revenir à ta remarque de départ, il faut bien se rendre compte que dans la très grands majorité des cas, les licences, libres ou pas, sont principalement de l'esbrouffe. Quand tu développes un bout de code sur tes week-ends et que tu le diffuses sous GPL, tu espères que la GPL dissuade éventuellement les gens peu scrupuleux de s'approprier le code. Ça n'est qu'un espoir, parce que si quelqu'un le fait, alors il faudra faire valoir tes droits (avocats, expertises, procès…). Tout le monde sait qu'il n'est pas très rationnel d'investir des dizaines de milliers d'euros dans une procédure judiciaire complexe (et assez incertaine vu la jeunesse de la jurisprudence sur ce genre de sujets) pour faire valoir des droits symboliques. Si tu attaques une grosse entreprise et que par miracle tu gagnes au tribunal contre une armée d'avocats spécialisés, tu vas pouvoir prétendre au remboursement partiel de tes frais de justice, et éventuellement un dédommagement à la hauteur réelle du préjudice subi (c'est à dire, de rien du tout à pas grand chose). Au mieux du mieux, le tribunal t'offrira l'équivalent du prix du logiciel que l'entreprise t'a pompé, si tu l'avais développé pour eux. S'il s'agit d'un utilitaire un peu marginal, ça ne va pas aller chercher loin. Et tout ça, c'est si ton adversaire est une entreprise française. Si c'est un groupe d'adolescents Biélorusses, tu vas te marrer rien qu'à savoir quelle institution judiciaire est concernée…

Du coup, comme toute licence, oui, c'est principalement du flan. Ça te donne juste la possibilité éventuelle de faire valoir tes droits contre un méchant, et tu espères que ça va faire suffisamment peur au méchant pour être dissuasif.

Pour garantir l’intégrité d’un document on le signe numériquement. Ce n’est pas le rôle d’une licence.

Ça n'est pas du tout la question, je pense. L'objectif est de laisser tout le monde distribuer un bout de code en rendant la distribution d'une version modifiée illégale. La signature numérique peut permettre à un tiers de s'assurer que le document est exactement le document d'origine au bit près (si ce tiers s'en donne la peine). Tu peux distribuer du code GPL et signé (dans ce cas, les versions modifiées ne seront plus signées et tu pourras éventuellement prouver que tu n'as pas certifié les versions modifiées). Bref, la signature numérique ne répond pas du tout à la question «je souhaite distribuer un document de manière à ce que chacun puisse à son tour le distribuer librement, éventuellement en changeant de format ou en appliquant des modifications mineures qui ne remettent pas en cause les droits d'auteur sur le document, mais sans pouvoir en modifier de version modifiée».

À la limite, je trouve que ça pourrait justifier d'une licence de type "CC-ND": la seule raison légitime de diffuser un code modifié pourrait être de falsifier un document historique. Bon, je joue l'avocat du diable, parce que je ne suis pas convaincu moi-même, et qu'il me semblerait intéressant que des passionnés puissent faire tourner ce code éventuellement patché sur du vieux matos. Mais bon, sur le fond, dès qu'on touche à des documents historiques, la question du "verbatim" me semble défendable.

J'imagine que c'est surtout l'intérêt historique du truc qui est prépondérant dans ce cas. Une sorte d'archives pour les historiens. Après, libre ou pas, ça n'est peut-être pas si important.

J'imagine que ça peut éventuellement être important, par exemple si un suspect a été pris par une caméra de surveillance à une certaine distance. Il y a des cas où ça doit pouvoir faire la différence, même si la plupart du temps ça n'a aucune importance.