Tipos de conflictos de software que acaban en juzgado
Los conflictos de software llegan a los tribunales con más frecuencia de lo que la mayoría de empresas anticipan. Las disputas más habituales se agrupan en cuatro categorías:
Incumplimiento contractual: la empresa de desarrollo entrega un producto que no cumple las especificaciones pactadas, no cumple los plazos o abandona el proyecto a mitad de ejecución. El cliente ha pagado por un software que no funciona, no existe o es inutilizable, y reclama la devolución de lo pagado más los daños causados por el retraso.
Propiedad intelectual del código: discusión sobre quién es el titular de los derechos sobre el código fuente. Esto ocurre especialmente cuando el desarrollo se encarga a un freelance o una empresa externa sin un contrato claro de cesión de derechos. También surge en disputas entre socios cuando uno de ellos desarrolló el software y luego la sociedad se disuelve.
Bloqueo de acceso a repositorios: un proveedor, exempleado o socio bloquea el acceso al repositorio Git, al servidor de producción o a las credenciales de la infraestructura. La empresa se queda sin acceso a su propio software y necesita demostrar que tiene derecho legítimo a ese código.
Competencia desleal y robo de código: un exempleado copia código propietario antes de abandonar la empresa y lo utiliza en un proyecto competidor. O una empresa subcontratada reutiliza módulos del software desarrollado para un cliente en proyectos para otros clientes sin autorización.
Propiedad del código: obra por encargo vs desarrollo propio
La Ley de Propiedad Intelectual (LPI) en España establece que los derechos de autor pertenecen al creador de la obra, salvo pacto en contrario. En el caso del software, esto tiene implicaciones directas:
Si un empleado desarrolla software como parte de sus funciones laborales, el artículo 51 de la LPI atribuye los derechos de explotación al empresario, salvo pacto en contrario. Pero si un autónomo o empresa externa desarrolla el software por encargo, los derechos pertenecen al desarrollador a menos que exista un contrato de cesión expresa. Pagar por un desarrollo no equivale a adquirir la propiedad del código: se adquiere una licencia de uso.
En un peritaje, el análisis del repositorio Git puede demostrar quién escribió cada línea de código, cuándo y en qué contexto. Si la empresa contratante aporta el contrato de cesión y el historial de Git confirma que el código fue escrito por el proveedor bajo ese encargo, la titularidad queda clara. Si no hay contrato escrito, el perito puede reconstruir la relación a partir de las comunicaciones digitales, los pagos realizados y la cronología de los commits.
Incumplimiento de proyecto: cómo medir lo entregado vs lo pactado
El peritaje en un caso de incumplimiento de proyecto de software consiste en responder objetivamente a la pregunta: ¿se entregó lo que se pactó? Para ello, el perito necesita dos elementos: la especificación de lo pactado (contrato, propuesta técnica, pliego de condiciones, emails de alcance) y la evidencia de lo entregado (código fuente, documentación técnica, entornos de pruebas, registros de despliegue).
El informe compara funcionalidad por funcionalidad: qué se especificó, qué se implementó, qué no se implementó y qué se implementó de forma deficiente (bugs, problemas de rendimiento, fallos de seguridad). Esta comparación se documenta con evidencia verificable: capturas de pantalla de los errores, registros de las pruebas ejecutadas, métricas de rendimiento y referencias al código fuente donde reside cada funcionalidad.
Un aspecto que los abogados deben tener en cuenta es que la ausencia de documentación formal de requisitos no impide el peritaje, pero lo complica. Si las especificaciones se discutieron por email o en reuniones sin acta, el perito reconstruye el alcance a partir de todas las comunicaciones disponibles. Por eso es fundamental preservar las comunicaciones digitales desde el primer momento del conflicto.
Git, CI/CD y documentación técnica como evidencia
El sistema de control de versiones Git es la fuente de evidencia más rica en un conflicto de software. Cada commit contiene: el autor (nombre y email configurado), la fecha y hora exactas, un hash SHA que garantiza la integridad del historial, el mensaje descriptivo del cambio y el diff (las líneas exactas de código añadidas, modificadas o eliminadas).
Más allá de Git, los sistemas de CI/CD (integración y despliegue continuo) como GitHub Actions, GitLab CI o Jenkins generan logs de cada compilación, test y despliegue. Estos registros permiten demostrar cuándo se desplegó cada versión del software, si pasó los tests y si se entregó correctamente al cliente.
La documentación técnica (wiki interna, README, especificaciones de API) también es evidencia valiosa. Si el proveedor se comprometió a entregar documentación y no lo hizo, o si la documentación existente contradice lo que se entregó, el perito lo documenta. En un caso de peritaje judicial, toda esta información se presenta al juez de forma estructurada, con referencias cruzadas entre la especificación, el código y los registros de despliegue.
Bloqueo de acceso a repositorios: qué se puede probar
El bloqueo de acceso a repositorios es una de las situaciones más urgentes en un conflicto de software. Un exempleado que cambia las credenciales de GitHub, un proveedor que revoca el acceso al repositorio tras una disputa de pago, o un socio que bloquea el servidor de producción. En todos estos casos, la empresa se queda sin acceso a su propio software y necesita actuar con rapidez.
Lo que un perito puede documentar incluye: la existencia previa del acceso (logs de la plataforma que muestran los usuarios que tenían permisos), el momento exacto del bloqueo (cambio de permisos, eliminación de colaboradores, cambio de contraseña), la autoría del bloqueo (quién ejecutó la acción, desde qué IP) y el contenido afectado (qué repositorios, ramas y versiones quedaron inaccesibles).
Si la empresa conserva un clon local del repositorio o copias en sistemas de CI/CD, el perito puede verificar su integridad y acreditar que el código coincide con lo que había en el repositorio antes del bloqueo. Esta evidencia es clave para solicitar al juez una medida cautelar de restauración del acceso.
Cómo prepara un perito el informe en disputas de software
El proceso comienza con una reunión con el abogado para entender la estrategia del caso y definir las preguntas que el informe debe responder. A continuación, el perito adquiere la evidencia: clona el repositorio (si hay acceso), recoge la documentación técnica, exporta las comunicaciones relevantes y, si es necesario, realiza una imagen forense de los equipos del desarrollador.
El análisis se estructura en torno a las cuestiones planteadas por el abogado: ¿quién escribió el código?, ¿se cumplieron las especificaciones?, ¿cuándo se entregó cada funcionalidad?, ¿hay evidencia de plagio o reutilización no autorizada? Cada respuesta se fundamenta en datos objetivos del repositorio, los logs y la documentación, con referencias precisas que permiten la verificación.
El informe final incluye un resumen ejecutivo (comprensible para el juez), el análisis detallado (técnicamente riguroso) y los anexos con la evidencia original. Si el caso llega a juicio, el perito debe ser capaz de explicar conceptos como «commit», «branch», «merge» o «deploy» de forma que un juez sin formación técnica entienda su relevancia para los hechos.
Errores típicos del demandante y del demandado
Errores del demandante (cliente)
- -No conservar los emails de especificación y comunicaciones con el proveedor.
- -No tener contrato escrito con cláusula de cesión de derechos sobre el código.
- -Seguir usando y modificando el software tras el conflicto sin preservar el estado original.
- -No solicitar un peritaje hasta que el juicio ya está en marcha y los plazos aprietan.
Errores del demandado (proveedor)
- -Borrar el repositorio o reescribir el historial de Git tras el conflicto (destrucción de prueba).
- -Revocar el acceso del cliente a producción sin documentar la razón técnica.
- -Reutilizar código del cliente en otros proyectos sin autorización expresa.
- -No documentar las entregas, las incidencias reportadas ni los cambios de alcance.
¿Tienes una disputa de software?
Analizo el código, el repositorio y las comunicaciones para construir un informe pericial sólido. Experiencia directa como CTO y como perito.
Preguntas frecuentes
En España, la Ley de Propiedad Intelectual establece que los derechos pertenecen al autor (el programador), salvo que exista un contrato de cesión o una relación laboral donde el artículo 51 LPI atribuye los derechos al empresario. Si el desarrollo se hizo por un freelance o empresa externa sin contrato escrito, la titularidad del código es del desarrollador, no del cliente que pagó. Es uno de los conflictos más frecuentes y más evitables con un buen contrato.
Sí, mediante un peritaje que compare los requisitos documentados (pliego de condiciones, propuesta técnica, emails de especificación) con lo que realmente se entregó. El perito analiza funcionalidades, rendimiento, errores (bugs) y conformidad con los estándares pactados. Si no hay documento formal de requisitos, se recurre a las comunicaciones entre las partes (emails, tickets, actas de reunión) para reconstruir el alcance acordado.
Git es un sistema de control de versiones que registra cada cambio en el código fuente con un timestamp, la identidad del autor, un mensaje descriptivo y un hash criptográfico que garantiza la integridad del historial. Es como un diario notarial del desarrollo: quién escribió cada línea, cuándo, y en qué contexto. En un litigio, el historial de Git permite demostrar autoría, cronología de entregas, funcionalidades implementadas y, si hubo borrado o reescritura de historial, detectar la manipulación.
No directamente. Un repositorio privado requiere autorización del titular de la cuenta. En un procedimiento judicial, el acceso puede obtenerse mediante requerimiento judicial al titular o, en determinados supuestos, directamente a la plataforma (GitHub, GitLab, Bitbucket). El perito puede solicitar al juez que ordene la exhibición del repositorio como parte de la prueba pericial. Si una parte tiene acceso legítimo (por ejemplo, era colaborador del repositorio), puede proporcionar un clon al perito con garantías de cadena de custodia.
El rango habitual para un peritaje de software en España oscila entre 2.000 € y 5.000 €+, dependiendo de la complejidad del código, el número de repositorios a analizar, la documentación disponible y si incluye ratificación en juicio. Un caso sencillo (comparar dos versiones de una aplicación) costará menos que uno complejo (reconstruir la cronología completa de un proyecto con múltiples repositorios y contribuidores durante meses). Consulta los rangos detallados en nuestra guía de precios.
El borrado de un repositorio no siempre es irreversible. Si había forks, clones locales en los equipos de los desarrolladores, backups del servidor o mirrors en plataformas de CI/CD, puede existir una copia completa o parcial del historial. Además, la destrucción deliberada de evidencia cuando ya existe conflicto puede tener consecuencias procesales graves (presunciones desfavorables en civil, posible delito en penal). El perito documenta el borrado, su cronología y las fuentes alternativas disponibles.
En el derecho español, los contratos verbales son válidos con carácter general (art. 1278 CC). El problema es probatorio: sin documento escrito, hay que acreditar la existencia del acuerdo y su contenido mediante otros medios (emails, transferencias bancarias, testimonios, propuestas enviadas). Un perito informático puede ayudar a reconstruir la relación comercial a partir de las comunicaciones digitales y demostrar qué se pactó, qué se entregó y qué se pagó.
La cuantificación incluye varios conceptos: el coste directo pagado al proveedor por el software no entregado o defectuoso, el coste de oportunidad (ingresos perdidos por el retraso), el coste de sustitución (contratar a otro proveedor para terminar o rehacer el proyecto) y, en algunos casos, daños consecuenciales (pérdida de clientes, multas por incumplimiento de plazos contractuales propios). El perito aporta la valoración técnica de lo entregado vs. lo pactado, y un economista puede complementar la cuantificación económica.