Prueba de marca temporal de commits de Git para disputas de patentes

En una disputa de patentes, la pregunta costosa rara vez es “¿escribiste este código?”. Es “¿puedes demostrar cuándo?”. Git registra una fecha en cada commit, pero esa fecha vive en una base de datos que no controlas y que puedes reescribir con un solo rebase. Una prueba de marca temporal de commits de Git para disputas de patentes resuelve esa brecha al convertir tu historial de commits en prior art criptográfico que un tercero puede verificar contra la blockchain de Bitcoin — sin que nadie lea tu código fuente.

Este artículo explica qué es realmente esa prueba, cómo se produce automáticamente y dónde se sostiene en una conversación legal.

¿Qué es una prueba de marca temporal de commits de Git?

Una prueba de marca temporal de commits de Git es un registro criptográfico que demuestra que un hash de commit específico existió en un momento específico, anclado en la blockchain de Bitcoin. Esa es toda la definición. No describe tu código, tu lógica ni tu negocio — demuestra la existencia de una huella digital en un momento en el tiempo.

Ayuda separar dos cosas que los desarrolladores suelen confundir:

• La fecha del commit en Git. Almacenada en el objeto del commit, editable con git commit --amend o un rebase, y alojada en infraestructura que no controlas si usas una plataforma como GitHub. En una auditoría legal, los registros internos como este se descartan habitualmente por considerarse interesados o manipulables.
• Una prueba anclada en Bitcoin. Un registro de que el hash existió antes de que se minara un bloque de Bitcoin determinado. Una vez que un bloque se confirma, ninguna entidad — ni el proveedor de alojamiento, ni nosotros, ni tú — puede alterarlo ni retrodatarlo.

Un punto que sorprende a la gente: la prueba cubre el hash del commit, no el código fuente. Timestamp GIT nunca ve, copia ni almacena tu código fuente real. Sella matemáticamente el hash y nada más. Eso es zero-knowledge por diseño, y es lo que hace que todo el enfoque sea seguro de usar en repositorios privados e incluso de secretos comerciales.

Si quieres la imagen más amplia de cómo encaja esto en una estrategia de PI, la guía de propiedad intelectual para desarrolladores cubre el terreno circundante; este artículo se mantiene en la prueba de marca temporal en sí.

La analogía del notario: por qué una marca temporal es evidencia

Piensa en un notario público. Le entregas un sobre sellado y el notario estampa la fecha en él. El notario no abre el sobre, no lee la carta y no guarda una copia del contenido. El sello certifica una sola cosa: este objeto sellado existió en esta fecha.

Ahora traslada eso a este flujo de trabajo:

• El sobre sellado es tu hash de commit — una huella digital unidireccional SHA-1/SHA-256 del estado del repositorio. No revela nada sobre el contenido, pero está vinculada de forma única a él.
• El notario es Bitcoin. No se puede sobornar, no se le puede presionar para retrodatar un sello y no tiene opinión sobre tu negocio.
• La copia carbón notariada que conservas es el archivo de recibo .ots y el manifiesto. Tú tienes la evidencia y puedes entregársela a cualquiera.

¿Por qué importa la analogía legalmente? Porque el modo de fallo de la evidencia interna no es que sea incorrecta — es que es tu evidencia. Un registro del servidor de Git dice “confía en mí”. Un anclaje en una blockchain pública dice “compruébalo tú mismo, aquí están las matemáticas”. Esa diferencia es lo que convierte un historial de commits en algo sobre lo que un abogado puede construir un argumento de prior art.

Cómo Timestamp GIT convierte los commits en evidencia para disputas de patentes

El modelo de tres pasos es sencillo.

Paso 1 — Huella digital. Cuando haces commit, Git genera un hash unidireccional único (SHA-1 o SHA-256) que representa el estado exacto de todo tu repositorio en ese momento. Esta es una huella digital criptográficamente segura de tu trabajo.

Paso 2 — Anclaje. Timestamp GIT extrae únicamente los hashes de los commits, los recopila en un archivo manifiesto de texto diario por repositorio, genera un hash SHA-256 de ese manifiesto, construye un árbol de Merkle y ancla la raíz de Merkle en una transacción de Bitcoin usando el protocolo OpenTimestamps. La existencia del hash queda congelada en el tiempo en un bloque de Bitcoin específico.

Paso 3 — Prueba. Recibes un archivo de recibo .ots inmutable. El manifiesto y los recibos se envían de vuelta a tu propio repositorio — ya sea en una rama dedicada timestamps o en un repositorio sombra separado — listos para un abogado, auditor o tribunal.

Bajo el capó, el pipeline gestionado se ve así:

1. Detección de commits — la GitHub App detecta nuevos commits mediante webhooks.
2. Cola de hashes — los hashes de los commits entran en un almacén clave-valor en memoria para su procesamiento por lotes.
3. Worker cron de medianoche — cada noche, un worker agrupa los hashes pendientes, escribe los manifiestos .txt, construye el árbol de Merkle, crea las pruebas contra los calendarios públicos de OTS y ancla la raíz en Bitcoin.
4. Entrega de pruebas — los manifiestos y recibos vuelven a tu repositorio. La confirmación de Bitcoin normalmente tarda unas tres horas, así que la escritura de las pruebas termina unas horas después de que se ejecuta el lote.

La parte importante para tu equipo: instalas la GitHub App una vez. No hay herramientas CLI, ni comandos de protocolo, ni pasos manuales. El worker nocturno hace el resto, y no hay nada que instalar en las máquinas de tus desarrolladores. Incluso el enfoque de protocolo en bruto — orquestar tú mismo los calendarios y las transacciones — lo tratamos como un detalle de implementación más que como un flujo de trabajo que debas ejecutar alguna vez.

Para equipos que quieren que el hash salga de su infraestructura por su propia mano, el modo Enterprise ZK cambia el webhook por una GitHub Action de 12 líneas que se ejecuta en tus runners y envía únicamente el hash del commit a la API de Timestamp GIT. Tu repositorio de código fuente queda completamente fuera de la ecuación.

Por qué esto importa en una disputa de patentes (y qué malinterpreta la gente)

Tres escenarios surgen una y otra vez:

• Trolls de patentes. Las entidades no practicantes presentan patentes amplias sobre tecnologías comunes. Si implementaste esa tecnología meses antes de su fecha de presentación y puedes demostrarlo, la fecha del commit anclada se convierte en prior art que puede invalidar la reivindicación.
• Disputas con empleados. Cuando un desarrollador principal se va, empiezan las discusiones sobre cuándo se concibió una funcionalidad. Una marca temporal inmutable reemplaza el “él dijo, ella dijo” por una fecha que ninguna de las partes puede editar.
• Reclamaciones de clean-room. Un competidor dice que “desarrolló de forma independiente” algo similar. Demostrar que tenías la lógica terminada 18 meses antes crea un muro matemático que una historia sobre desarrollo independiente no puede escalar.

Y tres conceptos erróneos que vale la pena desterrar desde el principio:

• “Mi historial de commits de GitHub es suficiente.” Está alojado por un tercero que no controlas, y es editable. Amend, rebase, force-push — las fechas se mueven.
• “Tengo que publicar mi código para demostrar que lo tenía.” No. Timestamp GIT ancla el hash, nunca el código fuente. Obtienes evidencia de prior art sin divulgar la implementación — que es exactamente lo que quieres para secretos comerciales.
• “Tendría que ejecutar OpenTimestamps yo mismo.” No. La GitHub App gestiona el protocolo de principio a fin, y la siguiente sección muestra cómo comprobar el resultado.

Verificar y presentar la prueba

La verificación es local y zero-knowledge. Cualquiera puede tomar el archivo .ots y comprobarlo contra la blockchain de Bitcoin sin confiar en Timestamp GIT — o sin necesitar que nuestra empresa exista. La prueba criptográfica se basa enteramente en SHA-256 y en los datos de los bloques de Bitcoin. Eso es lo que significa “independiente del proveedor” en la práctica: sin formato propietario, sin lock-in.

Para el uso diario, el producto muestra la misma evidencia en formas más amigables:

• Página de verificación pública en /verification/{user}/{repo}/{date} — una comprobación paso a paso de la cadena de Merkle multinivel. Todo el cálculo ocurre localmente en tu navegador. Nadie ve lo que verificas.
• Certificado PDF para una fecha específica (/api/report/{user}/{repo}/{date}), que es el artefacto que entregas a tu asesor legal.
• CSV de auditoría del libro mayor completo (/api/audit/{user}/{repo}), útil para una revisión completa de la cadena de custodia.
• Badges de README que muestran públicamente el estado de verificación. Los inversores y compradores los leen como señales de madurez en PI. Las URLs de los badges y los fragmentos de markdown provienen de /api/badgeLink/{user}/{repo}.

Una forma rápida de comprobar el estado público desde un script:

curl -s https://timestampgit.dev/api/statusSummary/acme/payments-service

Los repositorios privados añaden un HMAC cifrado a la URL, de modo que solo los usuarios autorizados pueden ver su estado. El HMAC es específico de la instancia del servidor.

Para la versión paso a paso de este proceso — incluido cómo recorrer tú mismo la cadena de Merkle — consulta Cómo verificar la marca temporal de Bitcoin de un repositorio de Git.

Opciones de despliegue: gestionado, Enterprise ZK o autoalojado

Modo estándar (GitHub App). Instala la app en el repositorio. Solo lee el hash del commit HEAD y escribe las pruebas en una rama timestamps o en un repositorio sombra. El modelo de permisos de GitHub implica que necesitamos al menos acceso de solo lectura al repositorio de código fuente (no existe un permiso solo para el hash del commit), más acceso de lectura-escritura al repositorio de destino.

Modo Enterprise ZK. Una GitHub Action de 12 líneas se ejecuta en tu infraestructura y envía únicamente el hash del commit a la API. No se requiere acceso de lectura al repositorio de código fuente, y tu código nunca sale de tu entorno.

Licencia autoalojada con Docker. Para máxima seguridad y entornos con aislamiento de red, Timestamp GIT se distribuye como imagen de Docker. Una configuración rápida de Docker Compose se ve así:

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

La aplicación está disponible en http://localhost:8080 tras el arranque, y un asistente de configuración en el primer inicio te guía para conectar tu GitHub App. Hay disponible una licencia de demostración por tiempo limitado para evaluación mediante el formulario de solicitud en la página de Licencia Docker. El tutorial de Docker autoalojado cubre la configuración completa si optas por esa vía.

Preguntas frecuentes

¿Es realmente admisible una marca temporal de commits de Git anclada en Bitcoin en una disputa de patentes? Proporciona evidencia lista para tribunales basada en estándares criptográficos reconocidos globalmente. La prueba demuestra que un hash de commit existió en un momento específico de un bloque de Bitcoin, lo que puede usarse para establecer prior art. La admisibilidad depende de tu jurisdicción y de tu asesor legal, pero la prueba criptográfica en sí es matemáticamente verificable por cualquiera.

¿Timestamp GIT ve o almacena mi código fuente? No. Timestamp GIT solo procesa hashes de commits. En modo estándar, la GitHub App lee el hash del commit HEAD; en modo Enterprise ZK, una GitHub Action envía únicamente el hash desde tu infraestructura, sin acceso de lectura al repositorio de código fuente. Tu código permanece en tu entorno.

¿Qué necesito instalar en las máquinas de mis desarrolladores? Nada. Timestamp GIT es una GitHub App gestionada. La instalas una vez en el repositorio, y cada commit se ancla automáticamente cada noche. No hay herramientas CLI que tu equipo deba aprender o recordar.

¿Cuánto cuesta proteger un repositorio privado? Los repositorios públicos son gratuitos bajo el plan Open Source. Los repositorios privados están cubiertos por Pro Agency a 49 $/mes, y Enterprise ZK con GitHub Actions a 199 $/mes. También hay disponible una licencia autoalojada con Docker para entornos con aislamiento de red, con una licencia de demostración por tiempo limitado para evaluación.

Conclusión

Una prueba de marca temporal de commits de Git convierte algo que ya haces — hacer commit de código — en prior art que puedes defender. El historial de commits por sí solo no sobrevivirá a una auditoría legal, porque es editable y está alojado por otro. Un hash anclado en Bitcoin sí lo hará, porque las matemáticas son públicas y el registro es inmutable.

El camino práctico es dejar de pensar en las marcas temporales como una tarea manual. Instala la GitHub App una vez, apúntala a los repositorios que importan y deja que el anclaje nocturno haga el trabajo. Consulta el panel de estado cuando necesites evidencia, incrusta un badge cuando quieras mostrar madurez en PI, y entrega el recibo .ots a tu abogado el día que realmente lo necesites.

Entradas relacionadas

• Cómo verificar la marca temporal de Bitcoin de un repositorio de Git
• Marca temporal automatizada de Git: cómo una GitHub App ancla cada commit
• Proteger la propiedad intelectual: una guía para desarrolladores de software