自动从git更新版权日期范围?


10

在我撰写本文时,我们距2012年还有10天。我敢打赌,许多程序员正在将其源文件顶部的版权字符串编辑为:

// Copyright 2008, 2010-2012 Some Company Unlimited

您的版本控制系统知道何时修改文件,因此可以肯定地它可以帮助写入或重写这些字符串。所以我的问题是:是否有一个脚本可以检查每个文件的git日志并输出(或更好地插入)像这样的字符串?

我正在使用git,所以这是主要的兴趣所在,但是请让我知道其他系统是否存在这样的脚本。

更新:

我们需要执行此操作的脚本:

  • 遍历我们工作副本中的所有源文件
  • 找到现有的版权字符串并确定年份,例如2007、2009-2011为{2007、2009、2010、2011}
  • 对于未提及的每一年,请在1月1日至12月31日(如果是当年,则为今天)之间进行区分。检查差异并确定是否值得在版权字符串中提及
  • 插入新的版权字符串。

1
如果我理解正确,那么该日期仍然是可选的。很好的问题。+1。
Maxpm 2012年

我知道日期在法律上并不重要,但有趣的是,何时触摸文件。如果有一个脚本,我可以运行它以在所有源文件中准确自动地设置此行,则无需对此进行任何思考!
paperjam 2012年

2
我一直在想自动生成版权声明的法律意义。更新后的通知本身不具有版权,因此您主张对版权的有效期为1年,而没有添加新的创意作品。
David Thornley,2012年

好点@大卫。我猜想任何这样的工具都必须忽略它自己的任何提交。也许还可以将其配置为忽略不代表新内容的提交(例如,文本删除,小的更改,重命名,重新格式化等)
paperjam 2012年

真正的问题是,从现在开始有人会关心您的代码70/95/120吗?
尼克T

Answers:


3

TL; DR

不用担心 如果您没有及时更新年份,则该项目的版权不会过期!您很安全-那样行不通。

长版:

我很确定版权声明中的所有年份数字都表示版权的开始而不是范围。如果增加一年,则意味着开始而不是结束。如果添加新内容(例如新模块)来表示该新内容的开始年份,则可以使用它。它是可选的,但应用于较大的更改,例如全新模块或完整的设计改造。

版权应在通知中的最后一年之后的固定年份(取决于您所在国家/地区的法律)之后到期。

因此,我根本没有理由忙着更新源头。

编辑:

问题是通常足够重大的更改涉及全新的源文件或旧文件的重新实现。因此,只要您始终在新源文件的标题中使用当前年份,就可以了。不需要通过每个文件进行更新。实际上,唯一需要手动更改的是许可证文本本身或自述文件中是否包含日期范围。

免责声明:我是程序员,而不是律师。


每当对文件进行实质性更改时,都应添加年份/扩大范围。所以理由就在那里。问题是,它不应该是自动的-git无法确定何时进行了实质性更改。
Herby 2012年

@herby:我在回答中做了澄清和对您评论的回复。
Goran Jovic

IANAL还是AFAIK,版权的有效期是根据最后一位在世的作者的去世日期确定的。仅当有人要求保护您的作品中的现有技术时,才考虑创建日期。
tdammers 2012年

@tdammers:也可以是IANAL,但在法人可以拥有版权的国家/地区中,IIRC根据创建日期而过期。软件的版权是由公司还是由编写该软件的实际雇员持有,取决于特定的司法管辖区(IIRC美国法律允许对版权本身进行转让,而大多数欧洲法律仅对专有权利拥有所有权,而版权仍由实际作者拥有)和工作协议(可以时不必分配版权)。
Jan Hudec 2012年

1

是否有一个脚本可以检查每个文件的git日志并输出(或更好地插入)类似的字符串?

它本身不是脚本,而是Git 功能,可用于此任务:涂抹/清洁过滤器对


-2

不,git不知道何时修改文件。

Git提交对象仅在特定点定义所有文件的内容。相同的内容可能很容易出现在另一个提交中,甚至是不相关的提交。没有什么可以使其中之一更重要。因此答案可能是模棱两可的,尽管通常不会。


嗯... git在输入时怎么知道日期git log
paperjam 2012年

@paperjam:它知道何时创建提交。当您键入时git log,它将遍历提交,因此当然知道它们的日期。但是它可能不知道哪个提交引入了文件的特定版本,因为可能有多个。
Jan Hudec 2012年

它确实将访问控制位保存在Blob中,因此也可能会在这一点上保存修改日期。但我不确定。
陶Szelei

@TamásSzelei:不,blob就是单词“ blob”,换行符和内容。而已。甚至没有名字。一棵树具有其指向的blob和子树的名称,类型和可执行位。但这仍然完全是历史性的。这是有意设计的。
Jan Hudec

1
我可能会在此处推断OP的答案,但从发布的角度来看,我认为唯一重要的是何时进行提交,而不是最后一次触摸文件的时间。简而言之,如果未提交并合并,则不会被释放。因此,为什么要做一些简单的事情git log --follow [filename] | grep -m 1 Date就足以获取最新日期。
Spoike 2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.