Automatycznie aktualizować zakres dat praw autorskich z git?

Gdy piszę, mamy 10 dni do 2012 roku. Założę się, że wielu programistów edytuje ciąg praw autorskich u góry swoich plików źródłowych do czegoś takiego:

// Copyright 2008, 2010-2012 Some Company Unlimited

Twój system kontroli wersji wie, kiedy pliki zostały zmodyfikowane, więc na pewno może pomóc w napisaniu lub przepisaniu tych ciągów. Więc moje pytanie: czy istnieje skrypt, który może sprawdzać dzienniki git dla każdego pliku i wypisywać (lub lepiej wstawiać) taki ciąg znaków?

Używam git, więc to jest najważniejsze, ale daj mi znać, czy takie skrypty istnieją dla innych systemów.

Aktualizacja:

Potrzebujemy skryptu, który to zrobi:

Przechodzi wszystkie pliki źródłowe w naszej kopii roboczej
Lokalizuje istniejący ciąg praw autorskich i identyfikuje lata, np. 2007,2009-2011 to {2007, 2009, 2010, 2011}
Dla każdego roku, który nie jest wymieniony, należy różnicować między 1 stycznia a 31 grudnia (lub dzisiaj, jeśli bieżący rok). Sprawdź diff i zdecyduj, czy jest wart wzmianki w łańcuchu praw autorskich
Wstaw nowy ciąg praw autorskich.

git copyright

— zakleszczenie papieru
źródło

Jeśli dobrze rozumiem, data i tak jest opcjonalna. Dobre pytanie. +1.

— Maks.

Wiem, że data nie jest ważna z prawnego punktu widzenia, ale ciekawe jest, kiedy dotknięto plików. Jeśli byłby skrypt, który mógłbym uruchomić, aby ustawić tę linię dokładnie i automatycznie we wszystkich plikach źródłowych, nie ma potrzeby o tym więcej myśleć!

— paperjam

Zastanawiałem się nad znaczeniem prawnym automatycznie generowanej informacji o prawach autorskich. Samo zaktualizowane powiadomienie nie podlega prawu autorskiemu, więc domagasz się rocznego przedłużenia praw autorskich bez dodawania nowych prac twórczych.

— David Thornley,

Dobry punkt @David. Wydaje mi się, że każde takie narzędzie musiałoby zignorować swoje własne zobowiązania. Być może można go również skonfigurować tak, aby ignorował zatwierdzenia, które nie są typowe dla nowej treści (np.

— Usuwanie

Prawdziwe pytanie brzmi: czy ktoś będzie obchodził twój kod za 70/95/120 lat?

— Nick T

Odpowiedzi:

TL; DR

Nie martw się! Twoje prawa autorskie do projektu nie wygasną, jeśli nie zaktualizujesz roku na czas! Jesteś bezpieczny - to nie działa w ten sposób.

Długa wersja:

Jestem prawie pewien, że wszystkie numery roku w informacji o prawach autorskich wskazują początek praw autorskich, a nie ich zakres. Jeśli dodasz rok, oznacza to kontynuację początku, a nie końca. Używasz go, jeśli dodajesz nową zawartość (jak nowe moduły), aby wskazać rok początkowy tylko dla tej nowej zawartości. Jest opcjonalny, ale powinien być używany do dużych zmian, takich jak całe nowe moduły lub kompletna zmiana wyglądu.

Prawa autorskie powinny wygasnąć po upływie określonej liczby lat (która zależy od przepisów obowiązujących w Twoim kraju) po ostatnim roku wypowiedzenia.

Więc nie widzę powodu, aby w ogóle zajmować się aktualizowaniem nagłówków źródłowych.

EDYTOWAĆ:

Chodzi o to, że zwykle zmiany, które są wystarczająco istotne, obejmują zupełnie nowe pliki źródłowe lub ponowne wdrożenie starych. Tak długo, jak zawsze używasz bieżącego roku w nagłówkach nowych plików źródłowych, nic ci nie jest. Aby dokonać aktualizacji, nie trzeba przechodzić przez każdy plik. W rzeczywistości jedyną rzeczą, która wymaga ręcznej zmiany, jest posiadanie zakresu dat w samym tekście licencji lub w pliku readme.

Oświadczenie: Jestem programistą, a nie prawnikiem.

— Goran Jovic
źródło

Powinieneś dodać zakres roku / powiększenia, ilekroć wprowadzisz znaczną zmianę do pliku, na przykład. A więc jest racja. Problem polega na tym, że nie powinno to być automatyczne - git nie może stwierdzić, kiedy zmiana jest znacząca.

— herby

@herby: Zredagowałem wyjaśnienie i odpowiedź na Twój komentarz w mojej odpowiedzi.

— Goran Jovic

IANAL albo, ale AFAIK, data wygaśnięcia praw autorskich jest oparta na dacie śmierci ostatniego żyjącego autora. Data powstania jest interesująca tylko wtedy, gdy ktoś rości sobie prawo do wcześniejszych dzieł.

— tdammers

@tdammers: IANAL albo, ale IIRC w krajach, w których osoby prawne mogą posiadać prawa autorskie, prawa autorskie posiadane przez osobę prawną wygasają w zależności od daty utworzenia. To, czy prawa autorskie do oprogramowania należą do firmy, czy faktycznych pracowników, którzy je napisali, zależy od konkretnej jurysdykcji (prawo USA IIRC zezwala na przeniesienie praw autorskich, podczas gdy większość przepisów europejskich zezwala tylko na prawa wyłączne, podczas gdy prawa autorskie nadal należą do fizycznych autorów) oraz umowa o pracę (prawa autorskie nie muszą być przypisywane, gdy jest to możliwe).

— Jan Hudec

czy istnieje skrypt, który może sprawdzać dzienniki git dla każdego pliku i wyprowadzać (lub lepiej wstawiać) taki ciąg znaków?

Nie jest to skrypt sam w sobie, ale funkcja Git , której można użyć do tego zadania: smudge / clean filter pair

— Leniwy Borsuk
źródło

-2

Nie, git nie wie, kiedy pliki zostały zmodyfikowane.

Obiekt Git commit po prostu definiuje zawartość wszystkich plików w określonym punkcie. Ta sama treść może łatwo pojawić się w innym zatwierdzeniu, nawet niepowiązanym. Nic nie czyni ważniejszego z nich. Odpowiedź może być dwuznaczna, choć często nie.

— Jan Hudec
źródło

Hmmm ... Skąd git zna datę, kiedy piszę git log?

— paperjam

@paperjam: Wie, kiedy zatwierdzenia zostały utworzone. Kiedy piszesz git log, chodzi o zatwierdzenia, więc oczywiście zna ich datę. Ale może nie wiedzieć, który zatwierdzenie wprowadził konkretną wersję pliku, ponieważ może istnieć więcej niż jedna.

— Jan Hudec

Zapisuje bity kontroli dostępu w obiekcie blob, więc równie dobrze może zapisać datę modyfikacji w tym punkcie. Ale nie jestem pewien.

— Tamás Szelei

@ TamásSzelei: Nie, BLOB to dokładnie słowo „BLOB”, nowa linia i treść. Otóż to. Nawet imienia. Drzewo ma nazwę, typ i wykonywalny bit dla obiektów blob i poddrzewa, na które wskazuje. Ale to wciąż całkowicie ahistoryczne. Jest to celowe i zgodne z projektem.

— Jan Hudec

Mogę ekstrapolować odpowiedź OP tutaj, ale myślę, że jedyne, co ma znaczenie, z punktu widzenia wydania, to kiedy dokonano zatwierdzenia, a nie dokładnie kiedy ostatni plik został dotknięty. Mówiąc najprościej, jeśli nie zostanie popełnione i scalone, to nie zostanie zwolnione. Dlatego robienie czegoś tak prostego, jak git log --follow [filename] | grep -m 1 Datewystarczyłoby, aby uzyskać najnowszą datę.

— Spoike,