Quelle est la manière correcte / polie d'hériter d'un projet open source abandonné pour un nouveau projet open source?


13

Mon équipe vient d'essayer de contacter des gars d'un ancien projet open source hébergé sur code.google.com. Nous leur avons dit que nous aimerions rejoindre leur projet et nous y engager - au moins dans une branche de celui-ci - mais personne ne nous a répondu. Nous avons essayé tout le monde, les propriétaires et les committers; personne n'était en aucune façon actif, et personne n'a répondu.

Mais nous avons du code à valider et nous aimerions vraiment continuer à travailler sur ce projet. Nous devons donc créer un nouveau projet. Nous avons trouvé un nom pour celui-ci qui est proche mais pas un doublon du nom du projet dont nous voulons hériter. Comment devrions-nous faire notre premier commit, et quel devrait être le message de commit? Devrions-nous simplement copier leur code dans notre référentiel avec un commentaire comme "nous avons hérité de ce code, nous l'avons trouvé ici sous telle ou telle licence ... maintenant nous le mettons à niveau vers cette licence plus / moins stricte ..."? Ou devrions-nous simplement utiliser leur code comme notre premier commit, avec des mises à jour disant "nous avons hérité de ... nous avons fait telle ou telle modification ..."?


7
Sauf si vous obtenez l'autorisation du projet d'origine, selon la licence d'origine, vous ne pourrez probablement pas en faire une licence moins stricte. S'il s'agit d'une licence suffisamment permissive pour le permettre, il n'est probablement pas nécessaire de passer à une licence encore plus permissive.
Matthew Scharley

Réponses:


13

Idéalement, vous le feriez sur Google Code, qui conserverait toute l'ancienne histoire. Je ne sais pas si cela est explicitement pris en charge sur Google Code, mais si l'ancien projet utilise git comme contrôle de version, vous pouvez le faire manuellement en clonant l'ancien projet dans un répertoire local, en modifiant la origintélécommande pour pointer vers votre nouveau référentiel, puis en poussant votre copie locale.

Je suis sûr qu'une méthode similaire peut être utilisée avec la subversion ( svnsyncpeut-être?) Mais je n'ai aucune expérience pratique avec la subversion, donc je ne peux pas y commenter.


2
le code google prend en charge Mercurial, mais pas git. Pour mercurial, la procédure est très similaire, modifiez simplement l' defaultalias dans .hg\hgrc.
Wim Coenen

@Wim merci pour l'info. Je n'ai vraiment pas beaucoup utilisé Google Code, je fournis juste autant d'informations que possible sur ce que je sais.
Matthew Scharley

8

L'important est de savoir si la licence du code d'origine et ce qu'il vous permet de faire. Une chose à laquelle vous devez faire très attention est de changer la licence car vous ne pouvez tout simplement pas être autorisé à le faire - rappelez-vous que vous n'avez pas de droit d'auteur.

Mais, en supposant que tout est en parfait ordre, le message de validation initial pourrait être "Importé le 25/02/2011 de http: // .... version XYZ", ainsi qu'une explication bien visible dans le fichier README.txt.

Soyez très clair sur ce que vous avez fait et, si possible, écrivez votre code en utilisant le code d'origine comme bibliothèque. Cela facilite beaucoup la séparation des préoccupations.


8

Il s'agit en fait d'une FAQ sur le code Google , voir "Que dois-je faire si je souhaite reprendre un projet qui semble abandonné par ses propriétaires?".

Apparemment, vous pouvez reprendre des projets abandonnés en demandant gentiment à Google.


4

Si vous avez contacté l'ancien projet, je ne pense pas qu'ils puissent se plaindre, soyez simplement ouvert et clair sur ce que vous faites et ne prenez pas le crédit pour le travail des autres. J'essaierais probablement d'expliquer la situation à la fois sur votre site Web et dans le premier message de validation. Il serait également poli de s'assurer que l'importation de code initiale est exactement la même que le projet précédent, donc toutes les modifications sont dans les journaux de validation.

Comme d'autres l'ont dit, vous ne pouvez remplacer la licence que par une licence compatible et vous NE POUVEZ PAS changer les titulaires des droits d'auteur, même si vous changez la licence. Il est important de conserver tous les noms des titulaires de droits d'auteur existants et dans tous les fichiers sur lesquels ils ont travaillé.



En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.