Sello de tiempo para código fuente y repositorios Git
Las fechas de los commits de Git no muestran cuándo existía tu código. Cualquiera puede ponerles el valor que quiera, y un rebase las reescribe. Si necesitas fijar una fecha para tu código que acepten un desconocido, un cliente o un juez, toma una instantánea exacta del código, normalmente un ZIP de un commit etiquetado, y aplica un sello de tiempo electrónico cualificado a su huella. Solo la huella sale de tu equipo, así que también funciona con código privado y propietario. A continuación tienes el procedimiento exacto, lo que acredita y lo que no.
Información general sobre medios de prueba, no asesoramiento jurídico para un conflicto concreto.
Por qué tu historial de Git no es una prueba independiente de una fecha
Git registra dos fechas en cada commit, la del autor y la del committer, y ambas salen del equipo que hace el commit. Nadie las comprueba. Si defines GIT_AUTHOR_DATE y GIT_COMMITTER_DATE antes de un commit, o ejecutas git commit --amend --date, obtienes un historial que dice lo que tú quieras. El rebase interactivo, los squash merges y los cherry-picks reescriben fechas como efecto secundario del trabajo normal.
Eso no quita valor a tu historial. Es una prueba excelente de cómo se construyó el código: pasos pequeños, el razonamiento en los mensajes de commit, issues, revisiones, ramas abandonadas. Es una prueba débil de cuándo, porque quien se apoya en él es la misma persona que podría haberlo escrito.
Las plataformas de alojamiento ayudan, pero no cierran el hueco. GitHub, GitLab y Bitbucket registran cuándo les llegó un push, pero esos registros los guarda una empresa privada, pueden ser difíciles de obtener más adelante y desaparecen si se borra el repositorio o la cuenta. Un force-push sustituye lo que había.
En España, un programa también puede inscribirse de forma voluntaria en el Registro de la Propiedad Intelectual. La inscripción no es constitutiva – los derechos nacen con la creación – y exige presentar un ejemplar de la obra ante un organismo oficial. Es una opción para una versión concreta e importante; para fechar muchas versiones sin entregar el código a nadie, el método de abajo es más práctico.
Qué aporta un sello de tiempo cualificado
Un sello de tiempo electrónico cualificado lo emite un prestador de servicios de confianza supervisado, conforme al Reglamento eIDAS de la UE. Según su artículo 41, apartado 2, los tribunales de todos los Estados miembros presumen que la fecha y la hora son exactas y que los datos que cubre no han cambiado desde entonces. La fecha no la pones tú, así que no se puede discutir con el argumento de que la fijaste tú.
El sello de tiempo va ligado a la huella SHA-256 de un archivo. Si cambia un solo byte, la huella deja de coincidir. Por eso el método de abajo consiste en elegir un archivo exacto y conservarlo tal cual.
Método 1: sellar un ZIP de un commit etiquetado (el más sólido)
- Etiqueta el estado que quieres fijar.
git tag v1.4.0(o usa un commit que ya tengas etiquetado). - Exporta exactamente ese estado.
git archive --format=zip -o miproyecto-v1.4.0.zip v1.4.0. Contiene los archivos versionados en ese commit y nada más: ni.env, ni resultados de compilación, ni cambios sin confirmar. - Emite un certificado para ese ZIP. La huella se calcula en tu navegador; el ZIP no se sube. Se aceptan archivos de hasta 500 MB.
- Guarda el ZIP sin modificar junto al PDF del certificado, en al menos dos sitios. No lo descomprimas y vuelvas a comprimir: un archivo nuevo con los mismos ficheros puede tener otra huella.
Por qué un ZIP y no la carpeta: el certificado cubre un único archivo. Un archivo comprimido convierte todo el árbol en un solo archivo cuya huella puedes recalcular más adelante con cualquier herramienta SHA-256. La salida de git archive puede variar entre versiones de Git, y precisamente por eso conservas el archivo que sellaste en lugar de pensar en regenerarlo.
Método 2: sellar un registro del commit (ligero)
Si quieres fechar muchos commits con poco coste, o el repositorio pesa más de 500 MB, escribe un archivo de texto breve y sella ese archivo:
repository: git@example.com:yo/miproyecto.git
tag: v1.4.0
commit: 3f9c2e7d0a5b8c1e4f6a9d2b7c0e3f5a8b1d4c6e
tree: 9b2e4d6f8a0c1e3b5d7f9a1c3e5b7d9f0a2c4e6b
note: release candidate enviada al cliente a petición suyaRellena las líneas commit y tree con los valores reales de git rev-parse v1.4.0 y git rev-parse v1.4.0^{tree}. El ID de un commit de Git es un hash sobre el árbol del commit, sus padres y su mensaje, así que vincula el sello de tiempo a ese estado exacto del código y a todo el historial anterior. Conserva a salvo el repositorio, con ese commit incluido; el archivo de texto por sí solo no muestra nada sin él.
La contrapartida: el vínculo entre el archivo de texto y tu código depende del propio hashing de Git. La mayoría de los repositorios siguen usando SHA-1 para los IDs de objeto, que tiene ataques de colisión conocidos, aunque Git incluye detección para el conocido. Para un hito rutinario suele bastar. Para la versión en la que más probablemente te apoyarías en un conflicto, usa el método 1, en el que el sello de tiempo cubre los propios archivos.
Cuál usar en cada caso
| Situación | Usa | Por qué |
|---|---|---|
| Antes de enviar código a un cliente, un inversor o una posible empresa contratante | Método 1 | Fija exactamente los archivos que vas a entregar |
| Antes de liberar el código o cambiar de licencia | Método 1 | Fija lo que existía con las condiciones anteriores |
| Al terminar un contrato freelance o una colaboración | Método 1 | Fija el estado en el momento en que cambian las responsabilidades |
| Hitos mensuales o por versión | Método 2 | Barato, y cada registro cubre también todo el historial anterior |
| Repositorio de más de 500 MB | Método 2, o método 1 solo con los directorios de código fuente | Mantiene el archivo sellado por debajo del límite de tamaño |
Código privado y propietario
La huella se calcula en tu dispositivo. Salvo que elijas expresamente guardar una copia del archivo, StampR recibe solo la huella, el nombre y el tamaño del archivo y los datos que introduces. A partir de la huella no se puede reconstruir el código. Con código propietario, deja sin marcar la opción de guardar y mostrar el original: un original guardado se muestra en la página pública del certificado.
Elige el nombre del archivo y la descripción con el mismo cuidado. Ambos aparecen impresos en el certificado. miproyecto-v1.4.0.zip está bien; un nombre que delate un producto aún no anunciado quizá no.
Lo que esto no hace
- No muestra que tú escribieras el código. Muestra que ese código exacto existía en ese momento y que declaraste que era tuyo. Tu historial de commits, las issues y las notas de diseño muestran el trabajo realizado.
- No decide de quién es el código. En la UE, cuando un trabajador crea un programa en el ejercicio de sus funciones, el empresario está facultado para ejercer los derechos económicos salvo pacto en contrario (Directiva 2009/24/CE, artículo 2, apartado 3; en España, artículo 97.4 de la Ley de Propiedad Intelectual). El trabajo freelance o de agencia depende del contrato. Un sello de tiempo fija fechas; no anula un acuerdo.
- No protege una idea o un algoritmo como tales. Los derechos de autor sobre software en la UE cubren la expresión de un programa, no las ideas y principios en los que se basa (Directiva 2009/24/CE, artículo 1, apartado 2). Las cuestiones de patentes son aparte, y publicar puede afectarlas.
- No sustituye a una licencia. Si publicas código, elige e incluye una licencia; el sello de tiempo es una prueba, no un permiso.
Sella una instantánea de tu código: el primer certificado con una cuenta cuesta 4,90 €.
Comprobarlo más adelante
Cualquiera puede comprobar el certificado sin tener que fiarse de ti. Ejecuta sha256sum miproyecto-v1.4.0.zip (macOS: shasum -a 256, Windows: Get-FileHash) y compara el resultado con la huella del certificado, o introdúcela en la página de verificación. Si coinciden, el archivo es, byte a byte, el que se selló.
Sigue leyendo
- Sellar cientos de archivos con un solo certificado: el método del manifiesto, para cuando un ZIP no es práctico.
- ¿Valen los sellos de tiempo ante un juez?: qué hace la presunción de eIDAS en un conflicto.
- Todas las opciones para dejar constancia de la autoría, comparadas: incluidos los casos en que un sello de tiempo no es la herramienta adecuada.
Preguntas frecuentes
¿Sirven las fechas de los commits de Git como prueba de cuándo se escribió el código?
Se pueden presentar, pero son débiles en cuanto a la fecha, porque las fija el equipo que hace el commit y pueden cambiarse con variables de entorno, amend o rebase. Son una prueba sólida de cómo se desarrolló el trabajo, y funcionan mejor junto a una fecha independiente, como un sello de tiempo cualificado.
¿Tengo que subir mi código fuente?
No. La huella SHA-256 se calcula en tu navegador y solo se envía la huella, salvo que elijas guardar una copia del archivo. Con código propietario, no guardes una copia.
¿Sello el ZIP o el hash del commit?
El ZIP de un commit etiquetado es la opción más sólida, porque el sello de tiempo cubre directamente los archivos. Un archivo de texto con el ID del commit es más barato para hitos periódicos y cubre todo el historial anterior, pero su vínculo con el código depende del propio hashing de Git.
¿Basta con la hora de un push a GitHub?
Es una prueba complementaria útil, pero la guarda una plataforma privada, puede ser difícil de obtener más adelante y desaparece si se borra el repositorio o la cuenta. Un sello de tiempo cualificado lo conservas tú y los tribunales de la UE presumen que es exacto.
¿Un sello de tiempo muestra que el código es mío?
No. La titularidad depende de quién lo escribió y de los contratos laborales o freelance. El sello de tiempo fija que ese código exacto existía en un momento dado y que declaraste que era tuyo.
¿Con qué frecuencia debo sellar?
En los momentos que quizá tengas que señalar más adelante: antes de entregar código a otra persona, antes de un cambio de licencia, al final de un contrato y en las versiones importantes. Muchos desarrolladores añaden entre medias un registro mensual del commit.
Certifica tu trabajo con una fecha fiable.
Crear un certificado →El primer certificado cuesta 4,90 € con una cuenta.