C'est le premier objectif, mais les termes employés sont généraux, il y est question de « work » et pas de « software », ça m'a toujours paru bien volontaire. L'application explicite au code source n'est donnée qu'entre paranthèses, et on pourrait en fait s'en satisfaire puisqu'on peut associer à n'importe quel oeuvre (numérique) un code source. Et puis si tu insistes sur le fait que la FSF ne parle là que de logiciel, c'est bien que pour du non-logiciel la définition ne s'applique plus, donc qu'on ne veut pas réutiliser les mêmes principes...
« Pour n'importe quel texte non technique, le simple fait de lire te donne la possibilité de modifier : tu reformules ! Tu as toujours un droit à reformuler. »
Reformuler n'est pas modifier, c'est reformuler, rien de plus. C'est pour ça que je te donnais l'exemple de logiciels à sources ouvertes. Tu peux lire le code source, le comprendre, découvrir tous les principes et algorithmes utilisés, et implémenter un clone puisque toutes les idées que tu y auras découvert ne sont pas brevetables (pas encore !). Pour le logiciel, on ne se contente pas d'une simple « reformulation », on exige bien de pouvoir distribuer le même logiciel, avec des modifications extrêmement mineures (par exemple, en corrigeant une faute d'orthographe à l'affichage, au milieu de 200000 lignes de code). On n'exige pas que l'implémentation soit réécrite.
« Le droit à modifier directement un texte n'a de sens que lors d'une démonstration purement technique (en particulier du code inclu dans un doc). »
Non, il a du sens pour n'importe quel type de texte : faire une version réduite (pas un résumé : des parties résumées, mais aussi des parties reprises entièrement), une traduction, une version supprimant certaines fautes d'orthographe, etc. les exemples ne manquent pas. Une introduction à un sujet donné pourrait être réutilisée dans un autre document parlant du même sujet. Dans tous les cas on peut reformuler, mais on ne peut pas reprendre le texte directement. C'est comme si on n'avait qu'un droit de lecture des codes sources, et pas de réutilisation.
« Dans le cas d'un logiciel, le fait de lire le code ne te permet pas de t'approprier l'idée. Tu peux comprendre comment ça marche mais tu ne peux pas le reexploiter. »
Entre l'utilisation et la lecture du code source, tu as toutes les idées. Des documents complémentaires permettent surement de mieux comprendre, mais le code source contient tout. Je ne vois pas ce qui empêche de réexploiter les idées contenues dans un logiciel à sources ouvertes.
« Par contre, si tu lis la Déclaration des droits de l'homme ou le Nouveau Testament, tu peux t'approprier la notion d'égalité et de partage completement libre, sans pourtant avoir modifier ces textes... »
Je suis bien d'accord que parfois (/souvent) on n'a besoin que de l'idée, et qu'on a intérêt à reformuler, et très peu d'intérêt à reprendre mot pour mot. C'est d'ailleurs ce qui arrive souvent dans le libre : on beaucoup de logiciels clones les uns des autres et qui pourtant ne se sont pas pris de code l'un l'autre. Mais la possibilité de reprendre existe, et on l'exige, parce qu'on ne présume pas de l'utilité de cette réutilisation pour l'utilisateur. Pourquoi, spécifiquement dans le cas des textes, présumer que l'auteur n'aura pas besoin de reprendre des textes mot pour mot ? Il y a des cas où ça lui sera infiniment plus pratique que d'avoir à tout reformuler. De même que parfois reprendre du code est infiniment plus pratique que d'avoir à réimplémenter. Dans les deux cas, réécrire est quelque chose que l'on sait faire, mais qui représente un effort, et le libre permet de reprendre directement, sans travail d'écriture.
Et puis si tu considères ça libre, qu'en est-il de l'adjectif propriétaire ? Un document FDL avec sections invariantes par exemple, tu dirais donc qu'il est libre et propriétaire, les deux en même temps ? Parce qu'autant je comprend la démarche pour le considérer libre (ce que je ne comprends c'est le pourquoi de certains critères différenciant les textes des logiciels), autant je ne vois pas comment on pourrait dire qu'il n'est pas propriétaire. Dans le dictionnaire, propriétaire a moins de définitions que libre, il y a moins d'ambiguïté : une section invariante relève bien d'une démarche propriétaire, on impose un ensemble de textes, sur lesquels on est seul à avoir autorité, et on refuse aux lecteurs de partager cette autorité. La section invariante n'a rien d'une chose « commune » ou « publique », sur laquelle chacun a les mêmes droits (dans les limites légales).
« Si tu suis le lien que j'ai donné, tu verras que cette liberté est toujours considéré comme exigible lorsqu'on parle d'éléments techniques. »
J'ai lu mais c'est le critère, l'approche orientée logiciel, que je ne comprends pas. Et puis je parlais à la fois de la FDL qui effectivement ne permet pas de mettre n'importe quoi en partie invariante et à la fois de ton point de vue qui me paraît encore moins libre (cf. la vie des vaches au vénézuala : l'ensemble est invariant, pas seulement le sujet principal).
Donc finalement, il y a bien un critère, une « discrimination » ou « exception » qui est faite, mais ce n'est pas texte / logiciel, c'est technique / non-technique. Dans ce cas, c'est cette différenciation là que je ne comprends pas. Pourquoi la faire ? Les limites sont même sans doute parfois floues...
Prenons un papier discutant d'un sujet quelconque. Les idées exprimées sont du non technique, et dans ce cas je suis d'accord qu'à partir du moment où on peut lire, on n'a pas besoin d'autre chose pour reprendre l'idée. Il en est de même pour le logiciel, où on saura aller pêcher toutes les idées nécessaires dans le code d'un logiciel si on veut en faire un clone ou reprendre certains de ces mécanismes. Mais pour avoir du libre, on veut pouvoir reprendre le code source tel quel, même pour l'utiliser dans un projet complètement différent. La même chose, adaptée au papier, consiste à reprendre ces « éléments techniques » et pas seulement ses idées, et pour un papier, les éléments techniques, c'est tout simplement le texte, mot pour mot.
Finalement plusieurs initiatives ont étendu l'idée de logiciel libre à toute oeuvre (Art Libre par exemple, ou Debian qui après étude de la question n'a pas vu de raison fondamentale de considérer toute chose numérisable comme autre chose qu'un logiciel), et cette adaptation s'est faite en restant au plus proche de la définition initiale, avec une notion forte de « modifier » (=> possibilité de reprendre, tel quel, l'ensemble ou des parties), tandis que la FSF, pourtant la première à exprimer clairement et vulgariser les idées du logiciel libre, a finalement choisi la voie d'une version restreinte de certaines libertés, en faisant cette adaptation aux documentations.
Ce qui fait que je ne peux pas adhérer au point de vue de la FSF, c'est qu'il consiste à présumer de ce à quoi va servir l'oeuvre : une doc d'un logiciel semble ne pouvoir évoluer que comme doc de ce logiciel, et le texte n'est pas sensé être utilisé ailleurs. Ce genre de chose n'existe pas du tout dans le logiciel, on ne présume rien sur la réutilisation.
[^] # Re: Desktop, OEM : SuSE passe à l'offensive
Posté par #3588 . En réponse à la dépêche Desktop, OEM : SuSE passe à l'offensive. Évalué à 1.
C'est le premier objectif, mais les termes employés sont généraux, il y est question de « work » et pas de « software », ça m'a toujours paru bien volontaire. L'application explicite au code source n'est donnée qu'entre paranthèses, et on pourrait en fait s'en satisfaire puisqu'on peut associer à n'importe quel oeuvre (numérique) un code source. Et puis si tu insistes sur le fait que la FSF ne parle là que de logiciel, c'est bien que pour du non-logiciel la définition ne s'applique plus, donc qu'on ne veut pas réutiliser les mêmes principes...
« Pour n'importe quel texte non technique, le simple fait de lire te donne la possibilité de modifier : tu reformules ! Tu as toujours un droit à reformuler. »
Reformuler n'est pas modifier, c'est reformuler, rien de plus. C'est pour ça que je te donnais l'exemple de logiciels à sources ouvertes. Tu peux lire le code source, le comprendre, découvrir tous les principes et algorithmes utilisés, et implémenter un clone puisque toutes les idées que tu y auras découvert ne sont pas brevetables (pas encore !). Pour le logiciel, on ne se contente pas d'une simple « reformulation », on exige bien de pouvoir distribuer le même logiciel, avec des modifications extrêmement mineures (par exemple, en corrigeant une faute d'orthographe à l'affichage, au milieu de 200000 lignes de code). On n'exige pas que l'implémentation soit réécrite.
« Le droit à modifier directement un texte n'a de sens que lors d'une démonstration purement technique (en particulier du code inclu dans un doc). »
Non, il a du sens pour n'importe quel type de texte : faire une version réduite (pas un résumé : des parties résumées, mais aussi des parties reprises entièrement), une traduction, une version supprimant certaines fautes d'orthographe, etc. les exemples ne manquent pas. Une introduction à un sujet donné pourrait être réutilisée dans un autre document parlant du même sujet. Dans tous les cas on peut reformuler, mais on ne peut pas reprendre le texte directement. C'est comme si on n'avait qu'un droit de lecture des codes sources, et pas de réutilisation.
« Dans le cas d'un logiciel, le fait de lire le code ne te permet pas de t'approprier l'idée. Tu peux comprendre comment ça marche mais tu ne peux pas le reexploiter. »
Entre l'utilisation et la lecture du code source, tu as toutes les idées. Des documents complémentaires permettent surement de mieux comprendre, mais le code source contient tout. Je ne vois pas ce qui empêche de réexploiter les idées contenues dans un logiciel à sources ouvertes.
« Par contre, si tu lis la Déclaration des droits de l'homme ou le Nouveau Testament, tu peux t'approprier la notion d'égalité et de partage completement libre, sans pourtant avoir modifier ces textes... »
Je suis bien d'accord que parfois (/souvent) on n'a besoin que de l'idée, et qu'on a intérêt à reformuler, et très peu d'intérêt à reprendre mot pour mot. C'est d'ailleurs ce qui arrive souvent dans le libre : on beaucoup de logiciels clones les uns des autres et qui pourtant ne se sont pas pris de code l'un l'autre. Mais la possibilité de reprendre existe, et on l'exige, parce qu'on ne présume pas de l'utilité de cette réutilisation pour l'utilisateur. Pourquoi, spécifiquement dans le cas des textes, présumer que l'auteur n'aura pas besoin de reprendre des textes mot pour mot ? Il y a des cas où ça lui sera infiniment plus pratique que d'avoir à tout reformuler. De même que parfois reprendre du code est infiniment plus pratique que d'avoir à réimplémenter. Dans les deux cas, réécrire est quelque chose que l'on sait faire, mais qui représente un effort, et le libre permet de reprendre directement, sans travail d'écriture.
Et puis si tu considères ça libre, qu'en est-il de l'adjectif propriétaire ? Un document FDL avec sections invariantes par exemple, tu dirais donc qu'il est libre et propriétaire, les deux en même temps ? Parce qu'autant je comprend la démarche pour le considérer libre (ce que je ne comprends c'est le pourquoi de certains critères différenciant les textes des logiciels), autant je ne vois pas comment on pourrait dire qu'il n'est pas propriétaire. Dans le dictionnaire, propriétaire a moins de définitions que libre, il y a moins d'ambiguïté : une section invariante relève bien d'une démarche propriétaire, on impose un ensemble de textes, sur lesquels on est seul à avoir autorité, et on refuse aux lecteurs de partager cette autorité. La section invariante n'a rien d'une chose « commune » ou « publique », sur laquelle chacun a les mêmes droits (dans les limites légales).
« Si tu suis le lien que j'ai donné, tu verras que cette liberté est toujours considéré comme exigible lorsqu'on parle d'éléments techniques. »
J'ai lu mais c'est le critère, l'approche orientée logiciel, que je ne comprends pas. Et puis je parlais à la fois de la FDL qui effectivement ne permet pas de mettre n'importe quoi en partie invariante et à la fois de ton point de vue qui me paraît encore moins libre (cf. la vie des vaches au vénézuala : l'ensemble est invariant, pas seulement le sujet principal).
Donc finalement, il y a bien un critère, une « discrimination » ou « exception » qui est faite, mais ce n'est pas texte / logiciel, c'est technique / non-technique. Dans ce cas, c'est cette différenciation là que je ne comprends pas. Pourquoi la faire ? Les limites sont même sans doute parfois floues...
Prenons un papier discutant d'un sujet quelconque. Les idées exprimées sont du non technique, et dans ce cas je suis d'accord qu'à partir du moment où on peut lire, on n'a pas besoin d'autre chose pour reprendre l'idée. Il en est de même pour le logiciel, où on saura aller pêcher toutes les idées nécessaires dans le code d'un logiciel si on veut en faire un clone ou reprendre certains de ces mécanismes. Mais pour avoir du libre, on veut pouvoir reprendre le code source tel quel, même pour l'utiliser dans un projet complètement différent. La même chose, adaptée au papier, consiste à reprendre ces « éléments techniques » et pas seulement ses idées, et pour un papier, les éléments techniques, c'est tout simplement le texte, mot pour mot.
Finalement plusieurs initiatives ont étendu l'idée de logiciel libre à toute oeuvre (Art Libre par exemple, ou Debian qui après étude de la question n'a pas vu de raison fondamentale de considérer toute chose numérisable comme autre chose qu'un logiciel), et cette adaptation s'est faite en restant au plus proche de la définition initiale, avec une notion forte de « modifier » (=> possibilité de reprendre, tel quel, l'ensemble ou des parties), tandis que la FSF, pourtant la première à exprimer clairement et vulgariser les idées du logiciel libre, a finalement choisi la voie d'une version restreinte de certaines libertés, en faisant cette adaptation aux documentations.
Ce qui fait que je ne peux pas adhérer au point de vue de la FSF, c'est qu'il consiste à présumer de ce à quoi va servir l'oeuvre : une doc d'un logiciel semble ne pouvoir évoluer que comme doc de ce logiciel, et le texte n'est pas sensé être utilisé ailleurs. Ce genre de chose n'existe pas du tout dans le logiciel, on ne présume rien sur la réutilisation.