El futuro de Linux: IA, ArtCraft y el fin del software propietario

Gracias a REA ahora tenemos Adobe, AutoCAD y Office en Linux. También se vienen drivers y compatibilidades que antes ni se soñaban.

Esto cambia el juego porque durante años el principal obstáculo para abandonar Windows no ha sido Linux, sino la deuda de compatibilidad con aplicaciones profesionales. Si REA consigue acelerar de verdad la ingeniería inversa de aplicaciones y reconstruir su funcionalidad, el efecto podría ir mucho más allá de ejecutar unos cuantos programas.

¿Qué significa realmente «tener Adobe en Linux»?

Aquí conviene ser precisos. La documentación oficial describe una herramienta que permite inspeccionar aplicaciones y reconstruir comportamientos con ayuda de agentes de programación. No afirma que convierta automáticamente suites comerciales completas en aplicaciones nativas.

El segundo escenario es particularmente interesante. No necesitas clonar Photoshop entero; si puedes reproducir las funciones que necesita un fotógrafo o una empresa, ya has reducido la dependencia.

¿Y qué pasaría con Microsoft?

Mi hipótesis es que el primer cambio importante no sería una desaparición de Windows, sino una pérdida progresiva de su condición de sistema operativo obligatorio. Podemos dividir esto en tres etapas:

• Corto plazo (1–3 años): Linux gana terreno entre desarrolladores y profesionales técnicos dispuestos a resolver problemas de compatibilidad.
• Mediano plazo (3–5 años): Algunas empresas adoptan Linux en puestos donde antes Windows era un requisito, aunque las aplicaciones que dependen de controladores especializados siguen siendo un obstáculo.
• Largo plazo (5–10 años): Un mercado más independiente del sistema operativo, con capas de compatibilidad sofisticadas y sistemas elegidos por coste y preferencias.

Estos plazos son escenarios hipotéticos. La clave es que estos cambios se refuerzan entre sí: más compatibilidad atrae usuarios; más usuarios justifican invertir en controladores y aplicaciones.

El efecto Streisand y la seguridad del código

Ahora, ¿qué pasa si las empresas deciden actuar? Es probable que Microsoft o Adobe se pronuncien. Podría venir un *cease and desist* para frenar a ArtCraft.

Es importante distinguir una declaración de preocupación de una demanda judicial. Una empresa podría reclamar contra el desarrollador, solicitar la retirada de contenidos o cuestionar el uso de marcas. No necesariamente elegirían el mismo camino en todos los casos, pero el efecto Streisand sería especialmente potente: una empresa intenta contener un proyecto y termina haciendo publicidad de una posibilidad que millones de personas ni siquiera sabían que existía.

Además, tu segunda hipótesis es muy relevante: la sospecha de malware. No hace falta demostrar que el proyecto sea malicioso; basta con que los responsables de informática no puedan demostrar fácilmente que es seguro. Un antivirus podría marcar un ejecutable como sospechoso o una empresa prohíbe instalarlo en sus equipos.

La mejor defensa no sería gritar «conspiración», sino construir una infraestructura de confianza:

1. Compilaciones reproducibles: Terceros pueden compilar el código fuente y comprobar que coincide con el ejecutable.
2. Firmas digitales y hashes: Permiten verificar quién publicó un archivo y si fue modificado después.
3. Auditorías independientes: Revisar dependencias, permisos y posibles vulnerabilidades.

La seguridad depende de muchos factores: calidad del desarrollo, revisión, pruebas, gestión de vulnerabilidades. La transparencia ayuda, pero no sustituye esos procesos.

Conclusión

Si estas herramientas empiezan a amenazar negocios de miles de millones, las respuestas comerciales y jurídicas serán inevitables. Mi conclusión es que la próxima gran discusión no será simplemente «código abierto contra código cerrado», sino quién tiene la autoridad para declarar que un programa es seguro.