Introducción
El 22 de junio de 2026, el tribunal de apelaciones de Utah recibió un caso que muchos creían enterrado en 2021: Xinuos vs. IBM. La empresa sucesora de SCO (Santa Cruz Operation) intenta revivir una disputa de hace más de 20 años sobre la propiedad del código de UNIX y su posible injerencia en Linux. Aunque el caso original terminó con un acuerdo confidencial entre IBM y los litigantes, Xinuos —que compró los activos de SCO en 2011— insiste en que IBM nunca tuvo licencia para usar ciertos fragmentos de código en sus sistemas operativos AIX y Z/OS, ni en su contribución a Linux.
Para equipos de DevOps, infraestructura y cloud, este caso no es solo un tema legal arcaico. Si Xinuos logra demostrar que parte del código de Linux o de sistemas IBM está bajo su propiedad, podría desencadenar una cascada de reclamos legales contra proveedores de cloud (AWS, Azure, GCP) y distribuidores de Linux. En un ecosistema donde el 90% de los servidores cloud corren sobre Linux (según datos de Red Hat de 2025), el riesgo no es teórico.
Qué ocurrió
El conflicto se remonta a 1998, cuando IBM, SCO, Intel y Sequent crearon Project Monterrey: un esfuerzo por unificar UNIX en múltiples arquitecturas. Para 2001, el proyecto estaba cerca de completarse, combinando código de IBM y SCO. Sin embargo, IBM abandonó Monterrey ese mismo año para apostar por Linux, alegando que el futuro estaba en el software abierto. Según alegatos presentados en el juicio de 2003, IBM habría contribuido código de Monterrey a:
- Linux kernel (versiones 2.4.x y 2.6.x, según alegatos de SCO)
- AIX (versiones 5L y posteriores)
- z/OS (en su rama UNIX System Services)
SCO demandó a IBM en marzo de 2003, argumentando que IBM había violado los términos de su licencia de UNIX al contribuir código propietario a un proyecto de código abierto. El caso se extendió por casi dos décadas, con múltiples apelaciones y giros legales. En 2021, las partes llegaron a un acuerdo confidencial que extinguía las claims sin que IBM admitiera responsabilidad.
Sin embargo, en 2011, SCO vendió sus activos a Xinuos, una empresa con sede en Corea del Sur que se especializa en sistemas embebidos y variantes de UNIX. Xinuos decidió continuar la batalla legal, argumentando que el acuerdo de 2021 no cubría sus claims sobre el código «contaminado» en Linux. En la audiencia del 22 de junio de 2026, Xinuos presentó dos argumentos centrales:
- IBM nunca tuvo licencia para usar el código de SCO en sus sistemas.
- Xinuos tiene derecho a litigar porque el acuerdo de 2021 no incluyó cláusulas de «no competencia» o «reclamos futuros».
IBM, por su parte, respondió que:
- Las licencias originales de UNIX (fechadas entre 1980 y 1995) ya habían sido transferidas a Novell en 2010, y este último llegó a un acuerdo con IBM en 2011.
- El código en disputa es genérico o ya estaba en dominio público antes de ser incluido en Linux.
El juez que presidió la audiencia —realizada de forma virtual— tuvo problemas técnicos (apareció en mute durante partes clave), pero el caso sigue activo. Según analistas legales citados por The Register, el litigio podría prolongarse hasta 2030 o más, dependiendo de las apelaciones.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de DevOps e infraestructura
Si Xinuos gana, el impacto sería directo en entornos Linux y cloud:
- Distribuidores de Linux: Red Hat, SUSE y Canonical podrían recibir reclamos por código incluido en sus kernels. En 2025, Red Hat estimó que el 70% de sus clientes empresariales usan RHEL en entornos cloud (AWS, Azure, GCP).
- Proveedores de cloud: AWS, Azure y Google Cloud podrían ser demandados como «beneficiarios indirectos» de código UNIX, especialmente en instancias con AIX o z/OS en entornos híbridos.
- Sistemas embebidos: Xinuos vende sistemas basados en UNIX para dispositivos IoT y telecomunicaciones. Si logra validar sus claims, podría exigir regalías a fabricantes que usen Linux en sus productos.
Para equipos de seguridad
El caso introduce un nuevo vector de riesgo legal:
- Auditorías de código: Equipos de seguridad podrían verse obligados a revisar el kernel de Linux en busca de código potencialmente «infectado» por reclamos de propiedad intelectual.
- Contratos de soporte: Empresas que usan Linux en entornos regulados (banca, salud) podrían enfrentar cláusulas de «indemnización por IP» en sus contratos con proveedores de cloud.
- Seguro cibernético: Algunas pólizas excluyen reclamos por violación de patentes o copyright. Si Xinuos gana, podría haber un aumento en siniestros por este tipo de claims.
Datos concretos del riesgo
- Linux en entornos enterprise: Según The Linux Foundation (2025), el 96% de los supercomputadores del mundo usan Linux. En cloud, AWS tiene más de 3 millones de instancias Linux activas (datos de 2025).
- Valor económico en juego: En 2021, SCO había reclamado $5 mil millones en daños, aunque el caso terminó con un acuerdo confidencial. Xinuos no ha especificado una cifra, pero analistas estiman que podría superar los $10 mil millones si logra probar ownership sobre código en Linux.
- Plazos legales: En muchos estados de EE.UU., los reclamos por copyright tienen un plazo de 3 años desde que el claimant conoció el daño. Xinuos argumenta que recién en 2021 (tras el acuerdo de IBM) supo del alcance de la «contaminación» en Linux.
Detalles técnicos
El código en disputa: ¿Qué se alega?
Xinuos se centra en dos fuentes de código:
- Proyecto Monterrey (1998–2001):
– IBM contribuyó código a MCCB desde AIX 5L (lanzado en 2000) y luego a Linux (kernels 2.4.x y 2.6.x).
– Según alegatos de SCO, el 15% del código de MCCB era propiedad exclusiva de SCO.
- Contribuciones a Linux:
– Xinuos cita un email interno de IBM de 2001 (presentado como evidencia) donde un ingeniero dice: «We’re open-sourcing the Monterrey bits that run on x86. Linux will eat AIX’s lunch».
– El kernel de Linux 2.6.32 (usado en RHEL 6 y Ubuntu 10.04) incluye funciones como sched_clock() y perf_events, que Xinuos alega tienen raíces en MCCB.
Vectores de ataque legal
Xinuos basa su reclamo en dos argumentos:
- Violación de licencia:
– IBM, al donar código a Linux, habría violado la cláusula «no open source» de su licencia.
- Copyright infringement:
– Xinuos apunta a funciones como:
– sched_setaffinity() (introducido en Linux 2.5.8)
– acpi_os_execute() (soporte para ACPI en servidores IBM)
– Parche «monterey» en el VFS (Virtual File System) de Linux 2.6.18.
¿Por qué ahora?
Xinuos argumenta que el acuerdo de 2021 fue incompleto:
- Novell (que compró los derechos de UNIX de SCO en 2010) llegó a un acuerdo con IBM en 2011, pero Xinuos alega que este acuerdo no cubría reclamos sobre código «derivado».
- En 2025, Xinuos contrató a Boies Schiller Flexner, un estudio legal especializado en propiedad intelectual, para reabrir el caso.
Comandos para auditar código (si el caso avanza)
Equipos de DevOps pueden usar herramientas como:
# Buscar funciones sospechosas en el kernel de Linux
grep -r "sched_clock\|monterey\|acpi_os_execute" /usr/src/linux-*
# Verificar licencias de módulos específicos
modinfo <nombre_del_modulo> | grep licenseQué deberían hacer los administradores y equipos técnicos
Acciones inmediatas (Julio 2026)
- Auditar entornos Linux:
uname -r
Si usás kernels 2.4.x, 2.6.x, 3.10.x o 4.4.x, priorizá la auditoría.
– Usar herramientas como FOSSA (Free and Open Source Software Audit) o Scancode Toolkit para identificar código con licencias restrictivas.
- Revisar contratos con proveedores de cloud:
– Si usás instancias con AIX o z/OS, contactá al proveedor (IBM) para confirmar que tenés cobertura legal en caso de reclamos.
- Documentar contribuciones internas:
– En Rust o Go, revisá dependencias con:
cargo audit # Para proyectos Rust
go list -m all | grep license # Para proyectos Go
Mitigación a mediano plazo (6–12 meses)
- Preparar un plan de contingencia:
– Crear un repositorio de código «limpio» (sin contribuciones de IBM de 1998–2001) como respaldo.
– Evaluar alternativas como FreeBSD (bajo riesgo de reclamos) o Alpine Linux (usando musl libc).
- Negociar con proveedores de cloud:
– En AWS, podés usar AWS Nitro Enclaves para aislar cargas de trabajo sensibles.
- Capacitar a equipos legales:
– Algunos seguros excluyen claims por violación de copyright, así que verificá los términos.
Conclusión
El caso Xinuos vs. IBM es un recordatorio de que los conflictos legales pueden resurgir décadas después. Para equipos de DevOps e infraestructura, la lección es clara: la deuda técnica no es solo técnica.
Si Xinuos logra reabrir el conflicto, el impacto podría ser global, afectando desde kernels de Linux hasta entornos cloud. La mejor estrategia es:
- Auditar ahora (antes de que el caso avance).
- Documentar todo (código, licencias, contribuciones).
- Preparar planes B (alternativas a Linux, cláusulas en contratos).
La historia de UNIX y Linux está llena de giros inesperados. Este podría ser otro.
Fuentes
https://www.theregister.com/os-platforms/2026/07/06/zombie-who-owns-unix-lawsuit-comes-alive-again/5266761
https://itsfoss.com/linux-adoption-statistics/
https://www.linuxfoundation.org/resources/linux-statistics/
https://www.redhat.com/en/resources/linux-enterprise-usage-trends