Copyright-Datumsbereich von git automatisch aktualisieren?

Während ich schreibe, sind wir 10 Tage im Jahr 2012. Ich wette, viele Programmierer bearbeiten die Copyright-Zeichenfolge oben in ihren Quelldateien wie folgt:

// Copyright 2008, 2010-2012 Some Company Unlimited

Ihr Versionskontrollsystem weiß, wann Dateien so sicher geändert wurden, dass es beim Schreiben oder Umschreiben dieser Zeichenfolgen helfen kann. Meine Frage: Gibt es ein Skript, das Git-Protokolle für jede Datei untersuchen und eine solche Zeichenfolge ausgeben (oder besser einfügen) kann?

Ich verwende git, das ist also von primärem Interesse, aber lassen Sie mich wissen, ob solche Skripte für andere Systeme existieren.

Aktualisieren:

Wir brauchen ein Skript, das dies tut:

Durchläuft alle Quelldateien in unserer Arbeitskopie
Findet vorhandene Copyright-Zeichenfolgen und identifiziert Jahre, z. B. 2007, 2009-2011 wäre {2007, 2009, 2010, 2011}
Unterschiedlich für jedes Jahr, das nicht erwähnt wird, zwischen dem 1. Januar und dem 31. Dezember (oder heute, wenn das aktuelle Jahr). Untersuchen Sie diff und entscheiden Sie, ob es eine Erwähnung in der Copyright-Zeichenfolge verdient
Fügen Sie eine neue Copyright-Zeichenfolge ein.

git copyright

— Papierstau
quelle

Wenn ich das richtig verstehe, ist das Datum sowieso optional. Gute Frage. +1.

— Maxpm

Ich weiß, dass das Datum rechtlich nicht von Bedeutung ist, aber es ist interessant zu sehen, wann Dateien berührt wurden. Wenn es ein Skript gäbe, das ich ausführen könnte, um diese Zeile genau und automatisch für alle Quelldateien festzulegen, müssen Sie nicht mehr darüber nachdenken!

— Papierstau

Ich habe mich über die rechtliche Bedeutung eines automatisch generierten Urheberrechtsvermerks gewundert. Der aktualisierte Hinweis selbst ist nicht urheberrechtlich geschützt. Sie fordern daher eine Verlängerung des Urheberrechts um ein Jahr, ohne dass neue kreative Arbeiten hinzugefügt werden.

— David Thornley

Guter Punkt @ David. Ich denke, ein solches Tool müsste seine eigenen Commits ignorieren. Vielleicht könnte es auch so konfiguriert werden, dass Commits ignoriert werden, die keinen neuen Inhalt kennzeichnen (z. B. Löschen von Text, kleine Änderungen, Umbenennungen, Neuformatierungen usw.)

— paperjam

Die eigentliche Frage ist, ob sich jemand in 70/95/120 Jahren um Ihren Code kümmert.

— Nick T

Antworten:

TL; DR

Mach dir keine Sorgen! Ihr Urheberrecht an dem Projekt erlischt nicht, wenn Sie das Jahr nicht rechtzeitig aktualisiert haben! Sie sind in Sicherheit - so funktioniert es nicht.

Lange Version:

Ich bin mir ziemlich sicher, dass alle Jahreszahlen im Copyright-Hinweis den Beginn des Copyright angeben und nicht den Bereich. Wenn Sie ein Jahr hinzufügen, bedeutet dies die Fortsetzung des Starts und nicht des Endes. Sie verwenden es, wenn Sie neue Inhalte hinzufügen (wie neue Module), um das Startjahr nur für diese neuen Inhalte anzugeben. Es ist optional, sollte jedoch für große Änderungen verwendet werden, z. B. für ganz neue Module oder eine komplette Überarbeitung des Designs.

Das Urheberrecht sollte nach einer festgelegten Anzahl von Jahren (abhängig von den Gesetzen in Ihrem Land) nach dem letzten Jahr in Ihrer Mitteilung ablaufen.

Daher sehe ich keinen Grund, die Quell-Header überhaupt zu aktualisieren.

BEARBEITEN:

Die Sache ist, dass Änderungen, die wesentlich genug sind, normalerweise völlig neue Quelldateien oder eine Neuimplementierung alter Dateien beinhalten. Solange Sie also immer das aktuelle Jahr in den Headern neuer Quelldateien verwenden, geht es Ihnen gut. Es ist überhaupt nicht erforderlich, jede einzelne Datei zu durchlaufen, um das Update durchzuführen. Das einzige, was eine manuelle Änderung erfordert, ist, wenn Sie einen Datumsbereich im Lizenztext selbst oder in der Readme-Datei haben.

Haftungsausschluss: Ich bin Programmierer und kein Anwalt.

— Goran Jovic
quelle

Sie sollten einen Jahres- / Vergrößerungsbereich hinzufügen, wenn Sie wesentliche Änderungen an einer Datei vornehmen. Der Raason ist also da. Das Problem ist, es sollte nicht automatisch sein - Git kann nicht sagen, wann die Änderung wesentlich ist.

— Herby

@herby: Ich habe in einer Klarstellung und einer Antwort auf Ihren Kommentar in meiner Antwort bearbeitet.

— Goran Jovic

IANAL auch, aber AFAIK, das Ablaufdatum des Urheberrechts basiert auf dem Sterbedatum des letzten überlebenden Autors. Das Erstellungsdatum ist nur dann von Interesse, wenn jemand den Stand der Technik für Ihre Arbeit beansprucht.

— tdammers

@tdammers: IANAL auch, aber IIRC in Ländern, in denen juristische Personen das Urheberrecht besitzen können, verfällt das Urheberrecht einer juristischen Person basierend auf dem Erstellungsdatum. Ob das Urheberrecht für Software beim Unternehmen oder bei den tatsächlichen Mitarbeitern liegt, die es geschrieben haben, hängt von der jeweiligen Gerichtsbarkeit ab (nach US-amerikanischem IIRC-Recht kann das Urheberrecht selbst übertragen werden, während die meisten europäischen Gesetze nur ausschließliche Rechte zulassen, solange das Urheberrecht noch bei physischen Autoren liegt). und Arbeitsvereinbarung (das Urheberrecht muss nicht zugewiesen werden, wenn es kann).

— Jan Hudec

Gibt es ein Skript, das Git-Protokolle für jede Datei untersuchen und eine solche Zeichenfolge ausgeben (oder besser einfügen) kann?

Es ist an sich kein Skript, sondern eine Git- Funktion, die Sie für diese Aufgabe verwenden können: Smudge / Clean-Filterpaar

— Fauler Dachs
quelle

-2

Nein, git weiß nicht, wann Dateien geändert wurden.

Das Git-Commit-Objekt definiert einfach den Inhalt aller Dateien an einem bestimmten Punkt. Der gleiche Inhalt kann leicht in einem anderen Commit angezeigt werden, auch in einem anderen. Es gibt nichts, was einen von ihnen wichtiger machen könnte. Die Antwort könnte also mehrdeutig sein, wird es aber oft nicht.

— Jan Hudec
quelle

Hmmm ... Woher weiß Git das Datum, an dem ich tippe git log?

— Papierstau

@paperjam: Es weiß, wann die Commits erstellt wurden. Wenn Sie tippen git log, werden die Commits durchlaufen, sodass das Datum natürlich bekannt ist. Es ist jedoch möglicherweise nicht bekannt, durch welches Commit eine bestimmte Version der Datei eingeführt wurde, da möglicherweise mehrere vorhanden sind.

— Jan Hudec

Es speichert die Zugriffssteuerungsbits im Blob, daher kann es auch das Änderungsdatum an diesem Punkt speichern. Aber ich bin mir nicht sicher.

— Tamás Szelei

@ TamásSzelei: Nein, Blob ist genau das Wort "Blob", eine Newline und der Inhalt. Das ist es. Nicht einmal ein Name. Ein Baum hat den Namen, den Typ und das ausführbare Bit für die Blobs und Teilbäume, auf die er zeigt. Aber das ist immer noch total ahistorisch. Dies ist beabsichtigt und beabsichtigt.

— Jan Hudec

Ich kann die Antwort des OP hier extrapolieren, aber ich denke, das einzige, was aus Sicht der Veröffentlichung wichtig ist, ist, wann das Commit durchgeführt wurde und nicht genau, wann die Datei zuletzt berührt wurde. Einfach ausgedrückt, wenn es nicht festgeschrieben und zusammengeführt wird, wird es nicht freigegeben. Warum also etwas so Einfaches tun, wie git log --follow [filename] | grep -m 1 Datees ausreicht, um das neueste Datum zu erhalten?

— Spoike