Bonjour,
Soit un projet A issue d'un fork d'un projet B. Les deux sont sous licence LGPL. Dans les fichiers du fork, là où il y avait du code issu du projet B à la naissance du fork, j'ai bien évidement ajouté la mention du copyright des auteurs du projet B (dont je faisais parti par ailleurs). Cependant, avec le temps, dans ces fichiers, le code original n'est plus. Le code actuel ne ressemble plus vraiment au code original tellement il y a eu des changements.
Question: est ce que le copyright des auteurs originaux est toujours pertinent pour ces fichiers ? Est ce que c'est possible de supprimer cette mention de copyright des auteurs originaux, quand, au final, le fichier ne comporte plus de code issue du projet forké ?
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Cas VLC
Posté par freem . Évalué à 2.
Doit être difficile ça, non? Je sais que git permets de modifier l'historique, mais à ce point ça semble délicat à faire quand même.
[^] # Re: Cas VLC
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Si, comme l'écrit l'auteur :
alors retirer les contributions des auteurs concernés est trivial : il suffit de ne rien faire.
[^] # Re: Cas VLC
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Dans le cas d'un changement de licence, retirer le code des contributeurs qui ne se sont pas manifesté, ne veut pas dire modifier l'historique de git. Je ne pense pas que dans le cas de VLC, il s'agisse de modifier la licence des versions passées, mais celle des versions à venir. Cela veut donc juste dire que le code source, à la date D où sa licence change, il n'y a plus de lignes de code "litigieuses".
# Copyleft
Posté par Tonton Benoit . Évalué à 2.
Je me trompe peut-être, mais la GPL n'oblige pas à garder le crédit du code utilisé, seulement la licence. Les licences qui exigent de conserver le crédit (XFree, BSD ancienne version…) restent compatibles avec la GPL mais sont considérées comme "dépréciées".
[^] # Re: Copyleft
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Ça m'étonne beaucoup, mais de toute façon, le droit français impose la reconnaissance de la paternité d'une œuvre si l'auteur le souhaite. Donc s'il reste du code de quelqu'un, il faut le mentionner.
Je ne pense pas que ça implique pour autant de maintenir pour chaque fichier une liste extensive des contributeurs, surtout pour les modifications de faible ampleur, surtout si on utilise un système de gestion de version, où chaque commit peut avoir un auteur identifié ou créditer quelqu'un par un message approprié.
[^] # Re: Copyleft
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 26 mai 2016 à 16:01.
Dans le projet en question, ajouter les contributeurs dans l'entête de chaque fichier était une habitude qui avait été prise. Probablement (mes souvenirs sont vagues), parce que, au début du projet A (2001), d'une part, mise à part la compréhension des 4 libertés fondamentales du libre, on ne maitrisait peut être pas très bien l'aspect juridique de la LGPL (pas sûr de tout maîtriser encore aujourd'hui, d'où ma question :-) ), d'autres parts, on utilisait CVS à l'époque, et que bon, manipuler ce truc n'était particulièrement pas user friendly pour inspecter l'historique etc (par rapport aux outils d'aujourd'hui).. Et souvent on intégrait des patchs à la main, donc les commits n'étaient pas créés par les auteurs des patchs. Ça nous permettait donc de laisser au moins une trace de qui avait touché à quel fichier, et de le savoir sans avoir à utiliser CVS… (ce qui au final est encore utile aujourd'hui, étant donné que le dépôt CVS et subversion du projet A a disparu :-/ )
À l'ère d'outils comme Git, Github, Gitlab, il est clair que l'intérêt de faire perdurer cette pratique est moins pertinente.
[^] # Re: Copyleft
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 26 mai 2016 à 16:25.
J'ai fait quelques recherches et je suis tombé sur le "mode d'emploi" de la GPL/LGPL/AGPL.
Il est dit qu'il faut indiquer la mention de copyright avec la/les années de publications, et la liste de toutes les personnes qui ont contribué au code ex : Copyright 2006-2016 Toto, Titi, Tata. Et sur chaque fichier du programme.
Par contre, il n'est pas précisé si on doit garder ou si on peut enlever la mention de copyright conçernant une personne pour laquelle sa contribution n'est plus présente dans le code… Ça ne répond pas trop à ma question :-/
# Un début de réponse
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Bon, finalement, j'ai fini par envoyé un mail à la FSF pour leur demander leur avis.
Et la réponse est… qu'il n'y a pas de réponse simple.
Comme je le pensais, selon la personne qui m'a répondu, il peut être très compliqué de déterminer si le code enlevé ou encore, si du code refondu peut avoir encore des "traces" ou pas du code original. J'imagine qu'il entend par là que le code refondu, même si syntaxiquement il n'est plus le même, peut faire tout de même la même chose ou très inspiré du code original. (la logique globale, ou l'idée générale de l'algo peut rester la même). Et dans ce cas, le contributeur reste plus ou moins l'auteur du code refondu.
Il m'a indiqué aussi que dans certaines boites, quand ils veulent refondre quelque chose et en être l'unique détenteur du copyright, ils font appel à quelqu'un qui n'a jamais vu le code original. Ainsi il n'est pas tenté de s'en inspirer, et donc fait un travail totalement original.
J'en conclu donc, à moins de totalement virer le code du contributeur sans le remplacer, qu'il est préférable de garder les noms des contributeurs dans le copyright. Une autre solution possible est aussi de demander aux contributeurs concernés par la réécriture ou les changements sur leur code, si ils acceptent d'abandonner leur copyright sur le nouveau code. Mais pas simple à faire (surtout sur du vieux code).
[^] # Re: Un début de réponse
Posté par NumOpen . Évalué à 1.
Garder les noms des anciens contributeurs a un intérêt historique, pourquoi les supprimer ?
[^] # Re: Un début de réponse
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Pourquoi faudrait-il leur attribuer la paternité du code d'un fichier quand leurs contributions n'y sont plus ?
Pour l'historique, il y a les mentions de copyright dans les versions précédentes, le dépôt de code etc..
[^] # Re: Un début de réponse
Posté par Anonyme . Évalué à 2.
C'est l'intérêt du gestionnaire de code source de pouvoir montrer, si besoin est, que ces contributions ne sont plus fonctionnelles à un temps t du développement.
Mais, à moins que ce ne soit une réécriture complète du code, le code actuel est le résultat d'une évolution, potentiellement lente et très fragmentée, depuis leurs contributions. Il n'existe que parce que leurs contributions ont été possibles.
[^] # Re: Un début de réponse
Posté par freem . Évalué à 2.
Le truc, c'est que tous les VCS ne sont pas égaux. Par exemple, cpold ne garde pas automatiquement la trace des contributeurs.
Par contre, je suis relativement d'accord avec toi pour ce qui est du fait qu'un code est une évolution.
Maintenant, en France, s'il n'est pas possible de coller un copyright sur quelque chose découlant de l'état de l'art, c'est qu'il y a une raison. Et, oui, ça veut dire que corriger une typo qui cause une segfault toute bête et est signalée par un warning de clang (pas gcc, parce que gcc est en retard sur mon système) ne donne pas vraiment de paternité.
Problème: ce type de problématique est international.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.