Nous avons eu cette semaine une réunion avec Benjamin Jean, d’Inno3, le cabinet de juristes qui a rédigé la charte Fédération. Le sujet en était la mention des auteurs, et plus généralement la reconnaissance des contributions individuelles dans le cadre d’un livrable open source (qu’il soit logiciel ou matériel).
Benjamin nous a expliqué qu’en pratique, quand un logiciel est publié sous licence open source, on y inclut un fichier « license » qui recopie le texte de la licence utilisée. Celui-ci n’inclut pas les contributeurs.
Les sources de certains projets incluent aussi un fichier « authors », dans lequel sont listés les contributeurs du projet. Il y est parfois fait mention des « core » développeurs, par rapport aux contributeurs plus occasionnels qui peuvent être divisés en plusieurs catégories.
Néanmoins il est important de noter que même si les core developers ont réalisé 95% du code, ils n’ont plus des droits exclusifs sur le logiciel, puisque même ceux qui ont contribué à hauteur de 1% reçoivent en pratique eux aussi des droits, qui ne sont pas moins forts que ceux des contributeurs (par exemple, si changement de licence du matériel, ils auront les mêmes droits que les core, leur vote ne sera pas pondéré par leur niveau de contribution).
J’espère avoir bien retranscrit l’échange, @alcoudry si tu veux compléter tu es la bienvenue
S’est posée aussi une question philosophique de mettre le nom individuel de contributeurs ? Ou est-ce que dans le cadre Fédération on considère bien que c’est le collectif qui contribue, et que les productions sont le fruit du travail commun ? Et donc plus de sens à reconnaître des individus. C’est un début de conversation
Nickel le résumé, pas beaucoup plus dans mes notes;
J’ai noté que les questions du statut d’un contributeur ne relevait pas de la propriété intellectuelle mais simplement de la stratégie qu’on souhaite avoir vis-à-vis des contributeurs. Il n’y a pas de normalisation sur ce point, mais il y a un début de standardisation pour les logiciels. On peut décider d’avoir dans le fichier author des contributeurs ponctuels, des leaders, des mainteneurs, des initiateurs… Au projet de le décider dès le début du projet.
Cet affichage des contributeurs a un rôle essentiel: faciliter la reconnaissance de paternité d’une contribution. Tu ne perds pas ton droit d’auteur si tu n’es pas authentifié, mais tu ne pourras pas le démontrer (ou difficilement)…
D’ailleurs il est important de préciser que le choix des licences doit se faire dès le début d’un projet et pas pendant… Par défaut, les projets sont sous les licences Fédération, mais un projet peut décider de choisir une autre licence. Dans ce cas là , elle devra être compatible et être interopérable avec les autres licences Fédération.
Concernant les questions autour du brevet et plus généralement dans quelle mesure le dispositif Fédération actuel sécurise t-il suffisamment par rapport au risque d’un brevet déposé ? Les licences choisies par Fédération permettent de protéger les contributeurs contre le risque brevet grâce à l’antériorité: c’est la publication et le partage des contributions qui va permettre d’apporter une protection et la preuve de l’antériorité (via les logs): ce sera aux autres de prouver que la preuve est fausse et de l’antériorité (compliqué à rapporter comme preuve). Plus ce sera publié plus il sera difficile d’apporter la preuve contraire. Et c’est le point fort des contributions en open source: plus c’est partagé, mieux c’est protégé!
Il y a toutefois quelques limites et c’est ce à quoi répondra en partie le chantier blockchain.
J’avais perdu ce message. Je rentre pas dans les questions Copyright, par contre pour ce qui concerne la partie code, je ne vois pas de problèmes. Si les projets utilisent git, tu peux extraire très facilement tous les contributeurs sur un projet avec aussi le percentage de code qu’ils ont contribué, même sans fichier CONTRIBUTORS.md ou equivalent.
Néanmoins il est important de noter que même si les core developers ont réalisé 95% du code, ils n’ont plus des droits exclusifs sur le logiciel, puisque même ceux qui ont contribué à hauteur de 1% reçoivent en pratique eux aussi des droits, qui ne sont pas moins forts que ceux des contributeurs (par exemple, si changement de licence du matériel, ils auront les mêmes droits que les core, leur vote ne sera pas pondéré par leur niveau de contribution).
Ça je n’ai pas compris. Je pense que ça soit normale que les « core contributors » décident dans la façon qu’ils considèrent plus idéale le destin d’un projet. On a des exemples avec des « Benevolent Dictators » (vim, CPython, Ruby on Rails, Linux) qui marchent très bien. L’important est que la licence permet de faire un fork du projet si quelqu’un des contributeurs ne se sent pas représenté par la politique de gestion du projet il peut décider de faire autrement. Example: la création de neovim par rapport à vim.
Si au moment d’un changement de licence, quelqu’un n’est pas d’accord, il peut faire un fork du projet au niveau du commit juste précedent au changement de licence, et continuer le developpement en parallèle avec la licence qu’il souhaite (compatible avec la précedente). Am I wrong?
