Discussion :

[Aiekick]

merci Uther pour ton lien

[Steinvikel]

Je pense que tu fais référence à la NASA Open Source Agreement et la Sybase Open Watcom Public License ?
(...) L'avis de la FSF étant plus important que l'avis de l'OSI, ce qui tendrait à dire que le projet Fedora est plus un projet libre qu'un projet open source.

Oui c'est celle-là que je visait.
Pour moi (ce n'est que mon avis), ce n'est pas ce que dit tel ou tel entité à travers tel ou tel communiqué qui va déterminer si un projet est libre ou open-source, ou si il est plus que l'autre... c'est simplement la compatibilité avec les définitions partagés respectives qui le détermine ...qu'on s'appelle RMS ou pas, OSI ou pas.

(...) il existe bien quelques rares licences très peu utilisées (...) Cependant, (...) la majorité des licences utilisées par les développeurs sont à la fois open source et libres.

Je conviens que la majorité soit en accord avec les 2, mais je me refuse à confirmer les dires suivants : licences open-source = licence libre ...c'est la même chose, mais en différent.

D'où tiens-tu ces différences en « open source » et « open-source » ? D'après le livre « Richard Stallman et la révolution du logiciel libre » Christine Peterson, dont l’organisation avait pris une part active dans la promotion du logiciel libre, proposa une alternative : « open source », donc sans tiret. La page History of the OS utilise à la fois les termes « open source » (open source licenses, open source developer, ...) et « open-source » avec un tiret (open-source community et open-source licensing).

Je vais être honnête, malgré mon amour des citations, je ne retrouverais pas les sources d'un tel détails, non pas qu'il n'est pas important, mais parce que noyé par d'innombrables lectures depuis. C'est quelque-chose que j'ai lu et recoupé il y 10-15 ans (tu peux éliminer toutes les sources postérieures), et je constate néanmoins qu'aujourd'hui il n'y a que rarement de rigueur sur la fixation du terme, et ce même sur le site de opensource.org : "Introduction - Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria (...)"
L'anglais semble généralement le ressortir sans tirets, alors qu'en français et allemand il y est presque systématique.

j'ai pas vu de chose dans la license MIT qui stipule que je doivent fournir le code source, ca dit juste que tout le monde est libre de le modifier.
il peuvent le modifier sans le code source, quand ils parlent de modification ils disent rien sur la nature de la modification. la ou dans d'autres licences ils parlent explicitement du code source.
dans la MIT ya rien de tel.

licence officielle MIT stipule que ses droits sont conférés "(...) to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction (...)" elle indique également "subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
documentation files = source code ? ou un ensemble plus vaste ? ou plus restreint ?
la réponse d'Uther --> C'est sous entendu dans "and associated documentation files (the “Software”)". (...) c'est vrai que le terme et assez vague (...)

vous parlez d'infraction. infraction vis a vis de qui dans le cas d'un soft gratuit ? on peut être condamné a fournir le code source dans le cas d'une diffusion sous license MIT ?
a la base je veux juste diffuser mon soft gratos. quelle licence je met pour ça du coup ?

Si tu distribues le code source sans les mentions obligatoires de la licence, oui.
Si tu te fou du devenir de tes travaux, prends n'importe laquelle, ça fera l'affaire, si tu souhaites que tes travaux restent gratuits, il te faut du copyleft, si tu souhaites plus de limitations /garanties, tu te devras de choisir une licence plus précisément.

question libre, la plus étique est la GPL, mais présente bon nombre d'incompatibilités dans un milieu propriétaire, même partiellement, c'est pourquoi on lui préfère souvent la LGPL qui est exempt de son agent actif viral
.
La licence Apache License 2.0 est considéré comme la meilleure des licences permissives (sans copyleft). Elle permet notamment d’empêcher une entité de modifier une oeuvre pour, par la suite, imposer l’acceptation d’un changement de clauses libres pour des clauses non libres, par le biais de l’apport d’une licence de brevet.

La MPL 2.0 (Mozilla Public License) est une licence à copyleft faible, et permet, s’il n’y est pas explicitement exclu, d’être convertie en GNU GPL, LGPL ou AGPL, néanmoins elle impose de toujours pouvoir être accessible sous sa licence originale : MPL 2.0. Néanmoins l’Apache License 2.0 est plus efficace sur certains points.

La CC BY 4.0 est une licence (sans copyleft) compatible avec toutes les versions de la GNU GPL, mais présente une incompatibilité à toute mise en oeuvre logicielle (ex : design d’une interface). Elle est convertible en GPLv3 (pas l’inverse), mais pas en GPLv3+. C’est l’une des 7 licences de Creative Commons, dont la plus récente et moins connue CC0 (Creative Commons Zero, qui se veut le plus proche possible du domaine public, et donc sans copyleft aussi). CC0 et CC BY sont les deux seules licences sans copyleft du groupe CC.
exemple pour une oeuvre textuelle : Si je craignais voir les propos présents sur ce corpus, déviés, transformés, dénaturés, je lui aurais acollé une licence interdisant la modification, telle que la CC BY-ND 4.0.

La License Art Libre v1.3 (LAL, ou parfois Free Art License, FAL) est conseillé par la FSF, si son auteur souhaite explicitement aposer un copyleft sur une oeuvre artistique, mais elle est incompatible avec la GPL et la FDL. Sinon, la CC BY-SA 4.0 est un second choix, intégrant également un copyleft, et qui est compatible avec la GPLv3.

Et on parle de qui là ? De Stallman et de ses zélote ! Pas d'Apache, MIT et co (qui sont très bien n'en déplaise au grand gourou du libre) ! Vous vous écartez du débat dès que vous citez ces licenses, notre soucis ici c'est bien Stallman et la FSF !

je cite le titre de la discussion : "l'open source est un substitut amoral et dépolitisé du mouvement du logiciel libre"
C'est donc bien une affaire de définition et de licences, voir même d'une appropriation d'une certaine interprétation.

Et j'évite presque toutes les libs qui pourraient me forcer à l'adopter sauf si je détecter une clause genre CLASSPATH exception dedans.

Qu'est-ce donc qu'une "CLASSPATH exception" ?

"l'open-source ne garantie nullement la liberté d'utilisation"
Si, c'est le but premier de la règle 6 de l'open-source, qui est complétée par les règles 5, 8, 9 et 10.

oui, autant pour moi, j'ai mal intégré les "champs d'applications".

"dans certains cas, l'open-source peut interdire la modification d'un code source"
J'aimerais que tu explicites dans quel cas

C'est effectivement dans l'article 4 de la définition sur son site web : https://opensource.org/osd-annotated
"(...) The license may require derived works to carry a different name or version number from the original software. (...) but may require that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but readily distinguished from the base source."
J'entends bien ta réponse, mais si l'on pars du principe que si on peut pomper sur du code "non modifiable" pour pondre un fork, alors toutes les softs sont modifiables. Obliger un apport à engendrer un changement de nom ou de version devrait être un choix communautaire, et non mécanique par la licence, non ?

"C'est simplement une affaire de licence, définissant des permissions et restrictions, pour servir des garanties.
Lorsque l'ensemble des points d'une des définitions s'y retrouve, on le catalogue dans tel ou tel monde."
(...) ça n'a quasiment rien a voir avec la licence, les règles se recoupent plutôt bien et quasiment toutes les licence open-sources sont libres et inversement.

"libre" et "open-source" ont chacun établi les conduites à adopter pour se conformer à leur qualificatif respectif. Dans la pratique, ça ce concrétise par la législation, et le seul outils juridique/législatif à disposition c'est le copyright --> par les licences.
Si on est pas d'accords sur ça, alors on a sûrement louper chacun le wagon de l'autre. ^^'

Présenter la différence open-source libre à la lumière des licence est une très mauvaise idée car les différences à ce niveau sont de l'ordre du détail. Quand on veut différencier les deux c'est de l'idéologie dont il faut parler, où là en effet il y a de vraie différences notables
Présenter la différence open-source libre à la lumière des licence est une très mauvaise idée car les différences à ce niveau sont de l'ordre du détail. Quand on veut différencier les deux c'est de l'idéologie dont il faut parler, où là en effet il y a de vraie différences notables.

Lorsque quelqu'un prétends que licence libre = open-source et vice-versa, je ne peut que répondre en mettant en lumière d'autres licences... pour ce qui est de l’idéologie, puisqu'elle se concrétise à travers la licence, il est également pertinent d'en parler (des licences). C'est ce que je fait quand j'exprime mon intérêt de voir le principe (le mécanisme) de copyleft être inclus dans la définition de "libre". Nous seront d'accord sur le fait qu'énoncer simplement des licences sans queue ni tête ne fera qu'obscurcir le sujet.
Voir énoncé des licences et lire en quoi cette dite licence n'est pas open-source ou libre, c'est également discuter de l'idéologie, chaque détail à son importance, que ce soit en philosophie, dans la législation, ou dans ce sujet.

[bouye]

Qu'est-ce donc qu'une "CLASSPATH exception" ?

Classpath is distributed under the terms of the GNU General Public License with the following clarification and special exception.

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

As such, it can be used to run, create and distribute a large class of applications and applets. When GNU Classpath is used unmodified as the core class library for a virtual machine, compiler for the java languge, or for a program written in the java programming language it does not affect the licensing for distributing those programs directly.

Une extension de la GPL assez commune dans le monde Java qui permet de linker avec une lib sous GPL sans que cette dernière ne contamine le reste de l'application. Sauf erreur de ma part c'est sous cette license que sont Open-source l'OpenJDK et l'OpenJFX ce qui permet d'eviter que les programmes Java qui tournent avec la lib standard Java (donc 100% des progs ecrits en Java) ou avec JavaFX deviennent de facto sous GPL.

[Uther]

Qu'est-ce donc qu'une "CLASSPATH exception" ?

Quand Sun a open-sourcé Java il a utilisé la licence GPL a laquelle il a ajouté la "Classpath exception" (le classpath est en Java là où sont chargé les bibliothèques). Le but de la GPL+classpath exception est similaire à la LGPL : elle permet aux bibliothèques Java de ne pas contraindre à un licence particulière le code auquel elles sont liées. La différence avec la LGPL est qu'au lieu d'utiliser des notions adaptées aux logiciel binaires (Code objet, linking,...) elle utilise des notions adaptées au code Java (classpath,...)

J'entends bien ta réponse, mais si l'on pars du principe que si on peut pomper sur du code "non modifiable" pour pondre un fork, alors toutes les softs sont modifiables. Obliger un apport à engendrer un changement de nom ou de version devrait être un choix communautaire, et non mécanique par la licence, non ?

Sauf que un choix communautaire, d'un point de vue légal, ça ne veut rien dire. D'autant plus dans le libre où tout le monde est libre de faire ce qu'il veux du code qu'il dispose sans avoir de compte a rendre aux auteurs originaux. Je ne vois pas ce qu'il y a de choquant a obliger que les travaux dérivés que je n'approuve pas (comme ajouter une backdoor au logiciel, par exemple) ne portent pas le même nom que le logiciel que j'ai publié.

[Steinvikel]

choix communautaire --> D'un point de vu légal, oui, mais je suis centré (sur ce point) sur l'éthique ("on devrait"). Et sa définition (sa taille numérique) est alors circonstancielle tout comme "groupe". Si un projet regroupant 500 acteurs est dirigé par un groupe de 5, on peut moralement pas appeler ça un projet "communautaire" du point de vue de sa gouvernance, car elle n'inclue presque pas cette communauté (1%). On peut par contre moralement appeler ça un projet "communautaire" du point de vue de sa contribution, où cette fois-ci, s'est presque l'intégralité de la "communauté" (si elle n'est pas absolue en pratique) qui est inclue dans le processus.

Je ne vois pas ce qu'il y a de choquant a obliger que les travaux dérivés, que je n'approuve pas (comme ajouter une backdoor au logiciel, par exemple), ne portent pas le même nom que le logiciel que j'ai publié.

Tu le penses (ou l'analyses) de la mauvaise manière.
1) Par définition, tu es libres si tu n'y es pas contraint/limité ("tout le monde est libre de faire ce qu'il veux").
Or, ici, on t'oblige, pour faire un apport au projet, à changer de nom (ou de numéro).
2) si tu n'approuves pas un changement, c'est à toi de décider s'il convient de te dissocier du projet et de publier TA version... et non l'être imposer par la licence (qui peut être définit invariable) du projet (qui est, par nature, variable). A quoi servirait un manifeste si ce n'est donner un axe commun pour un effort général, si une licence le remplace.
De plus, s'il advenait qu'un choix était majoritairement voulut par le projet, mais interdit par la licence, ce serait un défaut de fonctionnement.
Que je sache, dans le projet Linux, le choix du numéro de version est conférer à quelqu'un, ou un petit groupe. Si le projet souhaitait le faire par un vote (c'est pas pertinent, juste pour imager), il pourrait mettre en place un tel changement de fonctionnement, mais pas si cela est inscrit noir sur blanc dans la licence.

(le classpath est en Java là où sont chargé les bibliothèques). Le but de la GPL+classpath exception (...) : elle permet aux bibliothèques Java de ne pas contraindre à un licence particulière le code auquel elles sont liées. La différence avec la LGPL est qu'au lieu d'utiliser des notions adaptées aux logiciel binaires (Code objet, linking,...) elle utilise des notions adaptées au code Java (classpath,...)

Si j'ai bien compris, ils abordent donc la question de la désactivation de la viralité sous un contexte de langage interprété, plutôt qu'avec du byte code ou du binaire.
Et cela à des impactes différents de " l'antiviral " implémenté dans la LGPL.

Une extension de la GPL (...) ce qui permet d'éviter que les programmes Java qui tournent avec la lib standard Java (donc 100% des progs écrits en Java) ou avec JavaFX deviennent de facto sous GPL.

j'ai saisi : La System Library Exception et la GCC Runtime Library Exception (qui sont natives), s'applique à la production et l'environnement système ...tandis que Classpath Exception s'applique au reste des bibliothèques (pour faire court).

[Uther]

choix communautaire --> D'un point de vu légal, oui, mais je suis centré (sur ce point) sur l'éthique ("on devrait"). Et sa définition (sa taille numérique) est alors circonstancielle tout comme "groupe". Si un projet regroupant 500 acteurs est dirigé par un groupe de 5, on peut moralement pas appeler ça un projet "communautaire" du point de vue de sa gouvernance, car elle n'inclue presque pas cette communauté (1%). On peut par contre moralement appeler ça un projet "communautaire" du point de vue de sa contribution, où cette fois-ci, s'est presque l'intégralité de la "communauté" (si elle n'est pas absolue en pratique) qui est inclue dans le processus.

Tu poses des problèmes qui n'existe pas : ni le libre ni l'open-source ne suppose une communauté. Énormément de logiciel n'ont pas de communauté organisée. Tous les projets avec des licences libre ou open-source appartiennent à des propriétaires qui n'ont souvent rien a voir avec leur "communauté".

Tu le penses (ou l'analyses) de la mauvaise manière.
1) Par définition, tu es libres si tu n'y es pas contraint/limité ("tout le monde est libre de faire ce qu'il veux").
2) si tu n'approuves pas un changement, c'est à toi de décider s'il convient de te dissocier du projet et de publier TA version... et non l'être imposer par la licence (qui peut être définit invariable) du projet (qui est, par nature, variable). A quoi servirait un manifeste si ce n'est donner un axe commun pour un effort général, si une licence le remplace.

Non, c'est toi qui le penses de la mauvaise manière. La propriété d'un logiciel, n'est pas la même chose que le droit de l'utiliser et le modifier. Le libre et l'open-sources autorisent que le logiciel puisse être utilisé et modifié mais il ne signifie pas renoncer à la propriété de ce que l'on a choisi de partager.
Renoncer à la propriété de son code, c'est la mise en domaine public (ou CC0) ce qui est un problème qui va au delà du libre et de l'open-source. La notion de propriété est même à la base de toutes les licences libres et open-source.

[Steinvikel]

Nous somme d'accord sur cette base qu'est la propriété intellectuelle.
Là où je diverge, c'est sur le principe de pouvoir interdire "mécaniquement" une contribution. Pour moi cela relève du choix, et se doit de rester circonstanciel, et ouvert au changement d'avis (de choix) ...ce qu'une inscription en noir et blanc dans une licence peut ne pas permettre, et cela, à vie. Et c'est uniquement dans ce cas précis qu'intervient mon désaccord : une licence ayant inscrit cette notion ne me dérange pas si elle intègre une possibilité d'évolutivité (à l'image de la GPLv3+ par rapport à la GPLv3).

Un exemple récent serait le refus de modification de RMS pour un vieux passage de manuel de glibc. Lequel est effectif, mais pas mécanique, et ouvert à un une modification future, par un changement d'avis de RMS ou simplement sa disparition.

Tu poses des problèmes qui n'existe pas : ni le libre ni l'open-source ne suppose une communauté.

Une communauté n'est-elle pas l'association de personnes oeuvrant pour un but commun ? Libre et open-source suppose toutes les 2 une communauté ...celle du projet sur lequel se rassemblent des contributeurs. Qu'elle soit organisé ou non, ou le lien (ou rapports) qu'elle a avec le/les propriétaires est effectivement un autre sujet.

[Uther]

Nous somme d'accord sur cette base qu'est la propriété intellectuelle.Là où je diverge, c'est sur le principe de pouvoir interdire "mécaniquement" une contribution. Pour moi cela relève du choix, et se doit de rester circonstanciel, et ouvert au changement d'avis (de choix) ...ce qu'une inscription en noir et blanc dans une licence peut ne pas permettre, et cela, à vie. Et c'est uniquement dans ce cas précis qu'intervient mon désaccord : une licence ayant inscrit cette notion ne me dérange pas si elle intègre une possibilité d'évolutivité (à l'image de la GPLv3+ par rapport à la GPLv3).

Le libre permet de garantir de faire ce que l'on veut avec son code, y compris de refuser les contributions. Si une personne demande à contribuer a un projet, le propriétaire, que ça soit un individu, une entreprise ou une association sera maitre de l'accepter ou pas, avec du coup le numéro de version qu'il souhaite, le propriétaire etant libre de faire ce qu'il veux sur le code qui lui appartient sans tenir compte de la licence.
Par contre si le projet est forké, exiger un nom et/ou un numéro de version différent pour éviter les ambiguïtés est une idée tout a fait défendable. Donner aux autre le droit d'utiliser et modifier son projet n’inclut pas forcément de droit de s'accaparer l'identité du projet.

Une communauté n'est-elle pas l'association de personnes oeuvrant pour un but commun ? Libre et open-source suppose toutes les 2 une communauté ...celle du projet sur lequel se rassemblent des contributeurs. Qu'elle soit organisé ou non, ou le lien (ou rapports) qu'elle a avec le/les propriétaires est effectivement un autre sujet.

Le libre et l'open-source ne présupposent absolument pas une communauté. Une personne peut tout à fait mettre son travail à disposition et continuer à travailler dessus seule sans se soucier des autres qui pourront créer une communauté sur un fork de son travail s'ils le souhaitent, ou eux aussi travailler seuls dessus.
Rien dans le libre et l'open-source n'oblige a prendre en compte ce que les autres feront de ce que l'on publié. La liberté c'est aussi ne pas être obligé de tenir compte des autres si on en a pas envie.

[Steinvikel]

communauté --> Ces 2 mondes le présupposent de part leur ouverture. Certes il est possible de tenir un projet seul et d'y trouver aucun autre contributeur autre que son auteur, mais libre et open-source n'ont pas été pensée dans ce contexte... ils le permettent, mais encourage le rassemblement, la mise en commun.
J'imagine que cet aspect est un point sur lequel nous ne pourront nous concilier.

Rien dans le libre et l'open-source n'oblige a prendre en compte ce que les autres feront de ce que l'on publié. La liberté c'est aussi ne pas être obligé de tenir compte des autres si on en a pas envie. (...) Le libre permet de garantir de faire ce que l'on veut avec son code, y compris de refuser les contributions.

Je suis entièrement d'accord, c'est exactement ce qu'expose l'exemple de l'usage du droit de veto de RMS dans le message précédant.
Je pense avoir trouvé la différence de nos points de vues : tu m'exposes l'obligation d'accepter ou de réfléchir (prendre en compte), alors que moi je t'évoque la liberté de choisir.
Alors oui, selon moi, il est nécessaire d'être obligé de prendre en compte (y réfléchir), pour avoir la possibilité (liberté) de choisir.

Si l'on souhaite avoir la liberté de "refuser" une contribution, il est impératif d'en avoir la "proposition" --> pas de question, pas de réponse
Il en est de même pour la liberté de "accepter" une contribution.
or
Si la licence intègre le mécanisme de limitation que j'évoque depuis quelques messages, la liberté d'accepter s'en trouve amoindrie, car mécaniquement éjecté par la licence.
C'est cela que je dénonce.

Sinon n'importe qui pourrait légalement déposséder une personne ou même une communauté de son projet.

non, car pour cela il y a d'autres mécanismes en jeu dans la définition de l'open-source :
3) modification (et redistribution dans la même licence)
4) intégrité du code source de l'auteur

Par contre la définition de libre le permet, il me semble que c'est ce qu'il s'est passé avec "Waze", et c'est pourquoi le choix de la licence est primordial.

[Uther]

communauté --> Ces 2 mondes le présupposent de part leur ouverture. Certes il est possible de tenir un projet seul et d'y trouver aucun autre contributeur autre que son auteur, mais libre et open-source n'ont pas été pensée dans ce contexte... ils le permettent, mais encourage le rassemblement, la mise en commun.
J'imagine que cet aspect est un point sur lequel nous ne pourront nous concilier.

Non nous somme à peu près d'accord. La mise en commun, est conseillée mais pas obligatoire et la manière dont elle est faite reste à la liberté du propriétaire du code, c'est tout. La notion de communauté n'existe pas de base dans le libre comme dans l'open-source. La liberté de partager qui permet à une ou des communautés de se former, mais ça n'est pas un prérequis.

Si l'on souhaite avoir la liberté de "refuser" une contribution, il est impératif d'en avoir la "proposition" --> pas de question, pas de réponse
Il en est de même pour la liberté de "accepter" une contribution.
or
Si la licence intègre le mécanisme de limitation que j'évoque depuis quelques messages, la liberté d'accepter s'en trouve amoindrie, car mécaniquement éjecté par la licence.
C'est cela que je dénonce.

Non car si le propriétaire du projet (qui peut être une fondation qui gére la communauté) accepte votre contribution, il peut le faire avec le nom et le numéro de version qu'il convient quoiqu'il arrive. L'obligation ne vaudrait qu'en cas de fork.

Ce que vous ne comprenez pas c'est qu'il y a des dizaines de façon différentes de gérer un projet libre avec ou sans communauté et tout autant de façon de gérer une communautés qui ne sont d'ailleurs souvent pas liées à la licence. La façon que vous envisagez de gérer une communauté avec chaque contributeur indépendant (façon Linux) n'est en effet pas compatible avec cette règle mais ce n'est qu'une façon parmi bien d'autres. La règle de l'OSI permet juste de rajouter cette condition si le propriétaire la juge nécessaire, ça n'a rien d'obligatoire.

non, car pour cela il y a d'autres mécanismes en jeu dans la définition de l'open-source :
3) modification (et redistribution dans la même licence)
4) intégrité du code source de l'auteur

Sauf que la règle numéro 4 est justement celle que vous critiquez.

[Steinvikel]

Je ne parlais pas de prérequis, concernant la communauté, mais de fait.
Un établissement est public, du moment qu'il est ouvert à tous, que ce public soit présent ou non.
Une construction est communautaire, du moment que tous peuvent y apporter leur main à la pâte, et ce même si personne ne s'y joints.
...
Un projet est dit communautaire, du moment qu'il est ouvert à tous, même s'il ne compte qu'une personne.
Bref... des mouvements qui sont apparu à une époque où l'emprise des problèmes lié à du développement "fermé" étaient en pleine essor, et qui nuisaient principalement par la disparition des interactions de développement (fourniture du code, et modification du code notamment).
Je n'épiloguerais pas plus sur cette aspect de "communauté", au risque de faire ressembler cette discussion à un disque rayé. Nous semblons inconciliables sur ce point, voilà tout.

Peu importe le propriétaire, ou la taille de la communauté (qu'elle soit 1 ou 10 000), une licence ne devrait pas imposer un choix technique, pragmatique, ou esthétique, mais uniquement les limiter dans un délimitation morale, et ainsi donc laisser cette liberté à la gouvernance du projet. Maintenir un même nom ou numéro de version n'a aucun impacte moral, ça du ressort d'un règlement intérieur, ou des manières de procéder sur lesquels les gens s'accordent.
Comme vous le dites, de toute manière, le propriétaire à tout les droits ...sauf celui de bafouer la licence. En revanche il peut changer de licence.

Il y a des dizaines de façon différentes de gérer un projet libre avec ou sans communauté, et tout autant de façons de gérer une communauté ...et j'en critique une.
De même qu'il y a différentes façon de mener une discussion ...comme changer ses propos.

Je critique effectivement la 4e règle, sur un point précis, et fait mention d'une 2e règle qui la renforce. N'est-ce pas suffisant pour démontrer que l’affaiblissement de l'une peut être contrer par la capacité d'une autre ?
De plus je citais à l'origine cette règle pour dénoncer le possible verrouillage du code, et au fil des messages vous m'avez rétorqué que si ce mécanisme de verrouillage n'était pas là, ce serait l'anarchie, je vous présente donc 2 mécanismes complémentaires... sachant que vous n'avez cessé de m'expliquer que les auteurs ont les pleins pouvoirs.
Est-ce l'effet d'une lecture en diagonale ?