Actualizar automáticamente el rango de fechas de copyright de git?

Mientras escribo, estamos a 10 días de 2012. Apuesto a que muchos programadores están editando la cadena de derechos de autor en la parte superior de sus archivos de origen para algo como:

// Copyright 2008, 2010-2012 Some Company Unlimited

Su sistema de control de versiones sabe cuándo se modificaron los archivos, por lo que seguramente puede ayudar a escribir o reescribir estas cadenas. Entonces mi pregunta: ¿hay un script que pueda examinar los registros de git para cada archivo y generar (o mejor insertar) una cadena como esa?

Estoy usando git, por lo que es de interés principal, pero avíseme si tales scripts existen para otros sistemas.

Actualizar:

Necesitamos un script que haga esto:

Recorre todos los archivos de origen en nuestra copia de trabajo
Localiza la cadena de copyright existente e identifica años, por ejemplo, 2007,2009-2011 sería {2007, 2009, 2010, 2011}
Para cada año que no se menciona, diferir entre el 1 de enero y el 31 de diciembre (o hoy si es el año actual). Examine diff y decida si vale la pena mencionarlo en la cadena de copyright
Insertar nueva cadena de copyright.

git copyright

— Mermelada de papel
fuente

Si entiendo correctamente, la fecha es opcional de todos modos. Buena pregunta, sin embargo. +1.

— Maxpm

Sé que la fecha no es legalmente significativa, pero es interesante ver cuándo se tocaron los archivos. Si hubiera una secuencia de comandos que pudiera ejecutar para establecer esta línea de manera precisa y automática en todos los archivos de origen, entonces no hay necesidad de pensar más en esto.

— paperjam

Me he estado preguntando sobre el significado legal de un aviso de copyright generado automáticamente. El aviso actualizado en sí no tiene derechos de autor, por lo que está reclamando una extensión de 1 año en los derechos de autor sin agregar nuevo trabajo creativo.

— David Thornley

Buen punto @David. Supongo que cualquier herramienta de este tipo tendría que ignorar cualquiera de sus propios commits. Tal vez también podría ser configurado para ignorar compromete a que no se tipifican nuevos contenidos (por ejemplo, supresión de texto, los pequeños cambios, cambios de nombre, reformattings, etc.)

— paperjam

La verdadera pregunta es si a alguien le importará su código dentro de 70/95/120 años.

— Nick T

Respuestas:

TL; DR

No te preocupes ¡Sus derechos de autor sobre el proyecto no caducarán si no actualiza el año a tiempo! Estás a salvo, no funciona de esa manera.

Versión larga:

Estoy bastante seguro de que los números de todos los años en el aviso de copyright indican el inicio del copyright, no el rango. Si agrega un año, significa la continuación del inicio, no el final. Lo usa si agrega nuevo contenido (como nuevos módulos) para indicar el año de inicio solo para ese nuevo contenido. Es opcional, pero debe usarse para grandes cambios, como módulos completamente nuevos o un cambio de diseño completo.

Los derechos de autor deben caducar después de un número fijo de años (que depende de las leyes de su país) después del último año en su notificación.

Por lo tanto, no veo una razón para actualizar los encabezados fuente en absoluto.

EDITAR:

La cuestión es que, por lo general, los cambios que son lo suficientemente importantes implican archivos fuente completamente nuevos o una reimplementación de los antiguos. Entonces, siempre que use el año actual en los encabezados de los nuevos archivos fuente, estará bien. No es necesario pasar por cada archivo para realizar la actualización. En realidad, lo único que requiere un cambio manual es si tiene un rango de fechas en el texto de la licencia o en el archivo Léame.

Descargo de responsabilidad: soy programador, no abogado.

— Goran Jovic
fuente

Debe agregar un año / ampliar rango cada vez que realice un cambio sustancial en un archivo, un hecho. Entonces la razón está ahí. El problema es que no debería ser automático: git no puede decir cuándo el cambio es sustancial.

— herby

@herby: edité una aclaración y una respuesta a tu comentario en mi respuesta.

— Goran Jovic

IANAL tampoco, pero AFAIK, la fecha de caducidad de los derechos de autor se basa en la fecha de fallecimiento del último autor sobreviviente. La fecha de creación solo es de interés cuando alguien reclama el arte previo en su trabajo.

— tdammers

@tdammers: IANAL tampoco, pero el IIRC en países donde las personas jurídicas pueden tener derechos de autor, un derecho de autor en poder de la persona jurídica caduca en función de la fecha de creación. Si los derechos de autor del software son propiedad de la empresa o de los empleados reales que lo escribieron, esto depende de una jurisdicción particular (la ley IIRC de EE. UU. Permite que se asignen los derechos de autor, mientras que la mayoría de las leyes europeas solo permiten derechos exclusivos mientras los derechos de autor aún están en manos de autores físicos) y acuerdo de trabajo (el copyright no tiene que asignarse cuando puede).

— Jan Hudec

¿hay un script que pueda examinar los registros de git para cada archivo y generar (o mejor insertar) una cadena como esa?

No es un script per se, sino la función Git , que puede usar para esta tarea: par de filtro borroso / limpio

— Tejón perezoso
fuente

-2

No, git no sabe cuándo se modificaron los archivos.

El objeto de confirmación de Git simplemente define el contenido de todos los archivos en un punto específico. El mismo contenido puede aparecer fácilmente en otro commit, incluso uno no relacionado. No hay nada que haga que uno de ellos sea más importante. Por lo tanto, la respuesta puede ser ambigua, aunque a menudo no lo será.

— Jan Hudec
fuente

Hmmm ... ¿Cómo sabe Git la fecha cuando escribo git log?

— paperjam

@paperjam: sabe cuándo se crearon los commits . Cuando escribe git log, recorre los commits, por lo que, por supuesto, conoce su fecha. Pero puede no saber qué commit introdujo una versión particular del archivo, porque puede haber más de uno.

— Jan Hudec

Sí guarda los bits de control de acceso en el blob, por lo que también podría guardar la fecha de modificación en ese punto. Pero no estoy seguro.

— Tamás Szelei

@ TamásSzelei: No, blob es exactamente la palabra "blob", una nueva línea y el contenido. Eso es. Ni siquiera un nombre. Un árbol tiene el nombre, el tipo y el bit ejecutable para los blobs y subárboles a los que apunta. Pero eso sigue siendo totalmente ahistórico. Esto es intencional y por diseño.

— Jan Hudec

Puede que esté extrapolando la respuesta del OP aquí, pero creo que lo único que importa, desde el punto de vista de la versión, es cuándo se realizó la confirmación y no exactamente cuándo se tocó por última vez el archivo. En pocas palabras, si no está comprometido y fusionado, entonces no se libera. De ahí por qué hacer algo tan simple como git log --follow [filename] | grep -m 1 Datesería suficiente para obtener la última fecha.

— Spoike