Автоматически обновлять диапазон дат авторского права от git?

Пока я пишу, у нас 10 дней в 2012 году. Держу пари, что многие программисты редактируют строку с информацией об авторских правах в верхней части своих исходных файлов, например:

// Copyright 2008, 2010-2012 Some Company Unlimited

Ваша система контроля версий знает, когда файлы были изменены, так что, несомненно, она может помочь написать или переписать эти строки. Поэтому мой вопрос: существует ли скрипт, который может проверять журналы git для каждого файла и выводить (или лучше вставлять) строку, подобную этой?

Я использую git, так что это представляет основной интерес, но позвольте мне знать, существуют ли такие сценарии для других систем.

Обновить:

Нам нужен скрипт, который делает это:

Ходит все исходные файлы в нашей рабочей копии
Находит существующую строку авторского права и определяет годы, например, 2007,2009-2011 будет {2007, 2009, 2010, 2011}
Для каждого года, который не указан, разница между 1 января и 31 декабря (или сегодня, если текущий год). Изучите diff и решите, стоит ли упоминать в строке об авторских правах
Вставьте новую строку авторских прав.

git copyright paperjam
источник

Если я правильно понимаю, дата не является обязательной в любом случае. Хороший вопрос, хотя. +1.

Макс. Вечера

Я знаю, что дата не имеет юридического значения, но интересно посмотреть, когда были затронуты файлы. Если бы был скрипт, который я мог бы запустить для точной и автоматической установки этой строки во всех исходных файлах, тогда не нужно больше думать об этом!

paperjam

Меня интересует юридическое значение автоматически сгенерированного уведомления об авторских правах. Само обновленное уведомление не защищено авторским правом, поэтому вы претендуете на продление авторского права на 1 год без добавления новых творческих работ.

Дэвид Торнли

Хороший вопрос @ Дэвид. Я предполагаю, что любой такой инструмент должен был бы игнорировать любой из его собственных коммитов. Возможно, он также может быть настроен на игнорирование коммитов, которые не типизируют новый контент (например, удаление текста, небольшие изменения, переименование, переформатирование и т. Д.)

paperjam

Реальный вопрос в том, будет ли кто-нибудь заботиться о вашем коде 70/95/120 лет?

Ник Т

Ответы:

TL; DR

Не волнуйся! Ваше авторское право на проект не истекает, если вы не обновили год вовремя! Вы в безопасности - это не работает таким образом.

Длинная версия:

Я уверен, что все цифры года в уведомлении об авторских правах указывают на начало авторского права, а не на диапазон. Если вы добавляете год, это означает начало, а не конец. Вы используете его, если добавляете новый контент (например, новые модули), чтобы указать начальный год только для этого нового контента. Это необязательно, но его следует использовать для больших изменений, таких как совершенно новые модули или полная модернизация проекта.

Срок действия авторского права истекает через фиксированное число лет (что зависит от законодательства вашей страны) после последнего года, указанного в вашем уведомлении.

Так что я не вижу причин для того, чтобы вообще обновлять заголовки исходного кода.

РЕДАКТИРОВАТЬ:

Дело в том, что обычно достаточно существенные изменения включают в себя совершенно новые исходные файлы или повторную реализацию старых. Так что, если вы всегда используете текущий год в заголовках новых исходных файлов, у вас все в порядке. Для обновления не требуется проходить через каждый файл. На самом деле, единственное, что требует ручного изменения, - это если у вас есть диапазон дат в тексте лицензии или в файле readme.

Отказ от ответственности: я программист, а не юрист.

Горан Йович
источник

Вы должны добавить диапазон год / увеличение всякий раз, когда вы вносите существенные изменения в файл, на самом деле. Так что разум есть. Проблема в том, что он не должен быть автоматическим - git не может определить, когда изменение является существенным.

Херби

@herby: я отредактировал пояснения и ответ на ваш комментарий в моем ответе.

Горан Йович

IANAL либо, но AFAIK, срок действия авторского права основан на дате смерти последнего выжившего автора. Дата создания представляет интерес только тогда, когда кто-то заявляет об уровне техники в вашей работе.

tdammers

@tdammers: IANAL тоже, но IIRC в странах, где юридические лица могут обладать авторским правом, срок действия авторского права, принадлежащего юридическому лицу, истекает на основании даты создания. То, принадлежит ли авторское право на программное обеспечение компании или фактическим сотрудникам, которые его написали, зависит от конкретной юрисдикции (американское законодательство IIRC разрешает присваивать само авторское право, в то время как большинство европейских законов допускают только исключительные права, в то время как авторское право все еще принадлежит физическим авторам) и соглашение о работе (авторские права не должны быть назначены, когда это возможно).

Ян Худек

Есть ли сценарий, который может проверять журналы git для каждого файла и выводить (или лучше вставить) строку, подобную этой?

Это не скрипт как таковой, а функция Git , которую вы можете использовать для этой задачи: пара фильтров smudge / clean

Ленивый Барсук
источник

-2

Нет, git не знает, когда файлы были изменены.

Git commit object просто определяет содержимое всех файлов в определенной точке. Тот же контент может легко появиться в другом коммите, даже не связанном. Там нет ничего, чтобы сделать один из них более важным. Таким образом, ответ может быть неоднозначным, хотя часто это не так.

Ян Худек
источник

Хммм ... Как git знает дату, когда я печатаю git log?

paperjam

@paperjam: Он знает, когда были созданы коммиты . Когда вы печатаете git log, он проходит по коммитам, поэтому, конечно, он знает их дату. Но он может не знать, какой коммит ввел конкретную версию файла, потому что их может быть несколько.

Ян Худек

Он сохраняет биты контроля доступа в BLOB-объекте, поэтому он также может сохранить дату модификации в этой точке. Но я не уверен.

Тамас Селей

@ TamásSzelei: Нет, blob - это как раз слово «blob», перевод строки и содержание. Вот и все. Даже не имя. Дерево имеет имя, тип и исполняемый бит для больших двоичных объектов и поддеревьев, на которые оно указывает. Но это все еще абсолютно исторически. Это намеренно и по замыслу.

Ян Худек

Я могу экстраполировать ответ ОП здесь, но я думаю, что единственное, что имеет значение, с точки зрения выпуска, - это когда была сделана фиксация, а не точно, когда файл был последний раз затронут. Проще говоря, если оно не зафиксировано и не объединено, оно не будет выпущено. Следовательно, зачем делать что-то настолько простое, как git log --follow [filename] | grep -m 1 Dateдостаточно, чтобы получить самую последнюю дату.

Спойк