gitから著作権の日付範囲を自動的に更新しますか?


10

私が書いているように、私たちは2012年まで10日です。多くのプログラマーがソースファイルの上部にある著作権文字列を次のようなものに編集しているに違いありません。

// Copyright 2008, 2010-2012 Some Company Unlimited

バージョン管理システムは、ファイルがいつ変更されたかを認識しているため、これらの文字列の書き込みや書き換えに役立ちます。だから私の質問:各ファイルのgitログを調べて、そのような文字列を出力(またはより適切に挿入)できるスクリプトはありますか?

私はgitを使用しているので、これが主な関心事ですが、そのようなスクリプトが他のシステムに存在するかどうかを知らせてください。

更新:

これを行うスクリプトが必要です。

  • 作業コピーのすべてのソースファイルをウォークします
  • 既存の著作権文字列を検索し、年を識別します。例:2007,2009-2011は{2007、2009、2010、2011}となります
  • 記載されていない各年については、1月1日から12月31日(または、現在の年の場合は今日)を比較します。diffを調べて、著作権文字列で言及する価値があるかどうかを判断します
  • 新しい著作権文字列を挿入します。

1
私が正しく理解すれば、とにかく日付はオプションです。良い質問ですが。+1。
Maxpm

日付は法的に重要ではありませんが、ファイルがいつ変更されたかを確認するのは興味深いことです。すべてのソースファイルにわたってこの行を正確かつ自動的に設定するために実行できるスクリプトがあった場合、これについてこれ以上考える必要はありません。
paperjam 2012年

2
自動生成された著作権表示の法的重要性について疑問に思っていました。更新された通知自体は著作権で保護されていないため、新しい創造的な作品を追加することなく、著作権を1年間延長することができます。
David Thornley、2012年

良い点@David。私はそのようなツールはそれ自身のコミットを無視しなければならないでしょう。おそらく、新しいコンテンツを代表しないコミット(たとえば、テキストの削除、小さな変更、名前の変更、再フォーマットなど)を無視するように構成することもできます
paperjam

本当の問題は、70/95/120年後の誰かがあなたのコードを気にするかどうかです。
Nick T

回答:


3

TL; DR

心配しないで!年度を更新しなかった場合、プロジェクトに対する著作権は失効しません。安全です-そのようには機能しません。

ロングバージョン:

著作権表示のすべての年の数字は、範囲ではなく著作権の始まりを示していると確信しています。年を追加する場合は、終了ではなく開始の継続を意味します。新しいコンテンツ(新しいモジュールなど)を追加して、その新しいコンテンツのみの開始年を示す場合に使用します。これはオプションですが、まったく新しいモジュールや完全なデザインの変更など、大きな変更に使用する必要があります。

著作権は、通知の最終年後、固定数年(お住まいの国の法律によって異なります)後に失効します。

したがって、ソースヘッダーを頻繁に更新する理由がまったくわかりません。

編集:

問題は、通常、十分に大幅な変更には、完全に新しいソースファイルまたは古いファイルの再実装が含まれることです。したがって、新しいソースファイルのヘッダーで現在の年を常に使用している限り、問題はありません。更新を行うためにすべてのファイルを通過する必要はまったくありません。実際、手動で変更する必要があるのは、ライセンステキスト自体またはreadmeファイルに日付範囲があるかどうかだけです。

免責事項:私はプログラマーであり、弁護士ではありません。


ファイルに大幅な変更を加える場合は常に、年/拡大範囲を追加する必要があります。したがって、その理由はそこにあります。問題は、それが自動であってはならないことです-gitは変更がいつ実質的であるかを認識できません。
Herby

@herby:私は説明と、回答へのコメントへの返信を編集しました。
Goran Jovic、2012年

IANALもどちらかですが、著作権の有効期限は、最後に残った著者の死亡日に基づいています。作成日は、誰かがあなたの作品に先行技術を主張する場合にのみ重要です。
tdammers 2012年

@tdammers:IANALのいずれかですが、法人が著作権を保有できる国のIIRCは、法人が保有する著作権は作成日に基づいて失効します。ソフトウェアの著作権が会社にあるのか、それを書いた実際の従業員にあるのかは、特定の法域によって異なります(IIRCの米国法では著作権自体の割り当てが許可されていますが、ほとんどのヨーロッパの法律では独占的な権利しか認められておらず、著作権は物理的な作者が保持しています)。および作業合意書(著作権は、可能な場合に割り当てる必要はありません)。
Jan Hudec

1

各ファイルのgitログを調べて、そのような文字列を出力(またはより適切に挿入)できるスクリプトはありますか?

それ自体はスクリプトではありませんが、このタスクに使用できる Git 機能です:フィルターペアの汚れ/クリーンアップ


-2

いいえ、gitはファイルがいつ変更されたかを知りません。

Git commitオブジェクトは、特定のポイントですべてのファイルのコンテンツを定義するだけです。同じコンテンツが、関係のないコミットであっても、別のコミットで簡単に表示される場合があります。それらの1つをより重要にすることは何もありません。したがって、答えはあいまいかもしれませんが、多くの場合そうではありません。


うーん... Gitはどのように入力した日付を知っていますgit logか?
paperjam 2012年

@paperjam:いつコミットが作成されたかがわかります。と入力するgit logと、コミットをたどるので、もちろんその日付がわかります。ただし、複数のファイルが存在する可能性があるため、特定のバージョンのファイルがどのコミットに導入されたのかはわかりません。
Jan Hudec

BLOBにアクセス制御ビットを保存するため、その時点での変更日も保存する可能性があります。確信はないけど。
タマシュSzelei

@TamásSzelei:いいえ、blobはまさに「blob」という単語であり、改行とコンテンツです。それでおしまい。名前すらありません。ツリーには、名前、タイプ、およびそれが指しているブロブとサブツリーの実行可能ビットがあります。しかし、それはまだ完全に非歴史的です。これは意図的なものであり、設計によるものです。
Jan Hudec

1
私はここでOPの答えを推定しているかもしれませんが、リリースの観点から重要なのは、ファイルが最後に触れられたのではなく、コミットが行われたときだけです。単純に言えば、コミットもマージもされていない場合、リリースされません。したがってgit log --follow [filename] | grep -m 1 Date、最新の日付を取得するのに十分なだけの単純なことを行う理由。
スポーク2012年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.