Mettre à jour automatiquement la plage de dates de copyright de git?

Au moment où j'écris, nous sommes dans 10 jours en 2012. Je parie que de nombreux programmeurs modifient la chaîne de copyright en haut de leurs fichiers source pour quelque chose comme:

// Copyright 2008, 2010-2012 Some Company Unlimited

Votre système de contrôle de version sait quand les fichiers ont été modifiés, il peut donc sûrement aider à écrire ou réécrire ces chaînes. Donc, ma question: existe-t-il un script qui peut examiner les journaux git pour chaque fichier et produire (ou mieux insérer) une chaîne comme celle-ci?

J'utilise git donc c'est d'un intérêt primordial mais faites-moi savoir si de tels scripts existent pour d'autres systèmes.

Mise à jour:

Nous avons besoin d'un script qui fait ceci:

Parcourt tous les fichiers source dans notre copie de travail
Localise la chaîne de droits d'auteur existante et identifie les années, par exemple 2007,2009-2011 serait {2007, 2009, 2010, 2011}
Pour chaque année non mentionnée, diff entre le 1er janvier et le 31 décembre (ou aujourd'hui si l'année en cours). Examinez diff et décidez si cela mérite une mention dans la chaîne du droit d'auteur
Insérez une nouvelle chaîne de copyright.

git copyright bourrage papier
la source

Si je comprends bien, la date est de toute façon facultative. Bonne question, cependant. +1.

Maxpm

Je sais que la date n'est pas juridiquement significative mais il est intéressant de voir quand les fichiers ont été touchés. S'il y avait un script que je pourrais exécuter pour définir cette ligne avec précision et automatiquement sur tous les fichiers source, il n'y a plus besoin d'y penser!

paperjam

Je m'interroge sur la signification juridique d'un avis de droit d'auteur généré automatiquement. L'avis mis à jour lui-même n'est pas protégé par le droit d'auteur, vous demandez donc une prolongation d'un an du droit d'auteur sans ajout de nouveau travail créatif.

David Thornley

Bon point @David. Je suppose qu'un tel outil devrait ignorer ses propres commits. Peut-être qu'il pourrait également être configuré pour ignorer les validations qui ne caractérisent pas le nouveau contenu (par exemple, suppression de texte, petites modifications, renommages, reformatages, etc.)

paperjam

La vraie question est: est-ce que quelqu'un se souciera de votre code dans 70/95/120 ans?

Nick T

Réponses:

TL; DR

Ne t'inquiète pas! Votre droit d'auteur sur le projet n'expirera pas si vous n'avez pas mis à jour l'année à temps! Vous êtes en sécurité - cela ne fonctionne pas de cette façon.

Version longue:

Je suis à peu près sûr que tous les chiffres de l'année dans l'avis de droit d'auteur indiquent le début du droit d'auteur et non la plage. Si vous ajoutez une année, cela signifie la continuation du début et non la fin. Vous l'utilisez si vous ajoutez du nouveau contenu (comme de nouveaux modules) pour indiquer l'année de début pour ce nouveau contenu uniquement. Il est facultatif mais doit être utilisé pour des modifications importantes, comme de nouveaux modules entiers ou une refonte complète de la conception.

Le droit d'auteur doit expirer après un nombre d'années fixe (qui dépend des lois de votre pays) après la dernière année de votre notification.

Donc, je ne vois aucune raison de mettre à jour activement les en-têtes de source.

ÉDITER:

Le fait est que généralement les modifications suffisamment importantes impliquent des fichiers source complètement nouveaux ou une réimplémentation des anciens. Donc, tant que vous utilisez toujours l'année en cours dans les en-têtes des nouveaux fichiers source, tout va bien. Il n'est pas nécessaire de passer par chaque fichier pour effectuer la mise à jour. En fait, la seule chose qui nécessite une modification manuelle est si vous avez une plage de dates dans le texte de la licence lui-même ou dans le fichier Lisez-moi.

Avertissement: je suis un programmeur, pas un avocat.

Goran Jovic
la source

Vous devez ajouter une plage d'un an / agrandir chaque fois que vous apportez des modifications substantielles à un fichier, afaict. Le raason est donc là. Le problème est qu'il ne devrait pas être automatique - git ne peut pas dire quand le changement est important.

herby

@herby: J'ai édité une clarification et une réponse à votre commentaire dans ma réponse.

Goran Jovic

IANAL non plus, mais AFAIK, la date d'expiration du droit d'auteur est basée sur la date de décès du dernier auteur survivant. La date de création n'a d'intérêt que lorsque quelqu'un revendique l'état de la technique sur votre œuvre.

tdammers

@tdammers: IANAL non plus, mais l'IIRC dans les pays où les personnes morales peuvent détenir des droits d'auteur, un droit d'auteur détenu par une personne morale expire en fonction de la date de création. Que le droit d'auteur sur le logiciel soit détenu par l'entreprise ou par les employés qui l'ont écrit dépend de la juridiction particulière (la loi américaine de l'IIRC permet que le droit d'auteur lui-même soit attribué tandis que la plupart des lois européennes n'autorisent que des droits exclusifs tandis que le droit d'auteur est toujours détenu par des auteurs physiques) et accord de travail (le droit d'auteur n'a pas à être cédé quand il le peut).

Jan Hudec

existe-t-il un script qui peut examiner les journaux git pour chaque fichier et produire (ou mieux insérer) une chaîne comme celle-ci?

Ce n'est pas un script en soi, mais la fonctionnalité Git , que vous pouvez utiliser pour cette tâche: tache / filtre propre paire

Blaireau paresseux
la source

-2

Non, git ne sait pas quand les fichiers ont été modifiés.

L'objet Git commit définit simplement le contenu de tous les fichiers à un point spécifique. Le même contenu peut facilement apparaître dans un autre commit, même sans rapport. Il n'y a rien pour rendre l'un d'entre eux plus important. La réponse peut donc être ambiguë, mais ce n'est souvent pas le cas.

Jan Hudec
la source

Hmmm ... Comment git connaît-il la date à laquelle je tape git log?

paperjam

@paperjam: Il sait quand les commits ont été créés. Lorsque vous tapez git log, il parcourt les commits, alors bien sûr, il connaît leur date. Mais il peut ne pas savoir quel commit a introduit une version particulière du fichier, car il peut y en avoir plusieurs.

Jan Hudec

Il enregistre les bits de contrôle d'accès dans le blob, il pourrait donc aussi bien enregistrer la date de modification à ce stade. Mais je ne suis pas sur.

Tamás Szelei

@ TamásSzelei: Non, blob est exactement le mot "blob", une nouvelle ligne et le contenu. C'est ça. Pas même un nom. Une arborescence a le nom, le type et le bit exécutable pour les objets blob et les sous-arbres vers lesquels elle pointe. Mais c'est toujours totalement anhistorique. C'est intentionnel et par conception.

Jan Hudec

Je suis peut-être en train d'extrapoler la réponse du PO ici, mais je pense que la seule chose qui compte, du point de vue de la version, c'est quand la validation a été faite et pas exactement quand le fichier a été touché pour la dernière fois. Autrement dit, s'il n'est pas validé et fusionné, il n'est pas publié. Par conséquent, pourquoi faire quelque chose d'aussi simple que git log --follow [filename] | grep -m 1 Datecela suffirait pour obtenir la dernière date.

Spoike