«Nos pasamos a Linux». «Apostamos por el software libre». Estas frases surgen cada vez que un comité aborda la soberanía del software, y se pronuncian con tono de obviedad, como si el código abierto resolviera la cuestión por su mera naturaleza. Resuelve una parte. Deja otra parte intacta y, a veces, desplaza el problema sin resolverlo. La soberanía no se juega en la oposición entre software propietario y libre. Se juega capa por capa: quién controla qué y si es posible salir de ello.
Lo que el código abierto garantiza realmente
El software libre se basa en cuatro libertades, formalizadas por la Free Software Foundation: ejecutar el programa para cualquier fin, estudiar su funcionamiento, redistribuirlo y modificarlo para luego difundir las versiones modificadas. El código abierto, tal y como lo define la Open Source Initiative, abarca un ámbito similar. Estas libertades no son teóricas. Dan lugar a tres propiedades concretas.
En primer lugar, la auditabilidad. El código fuente es legible y, por lo tanto, verificable. Una organización que lo desee puede examinar lo que un programa ejecuta realmente, sin tener que fiarse de la palabra del editor. Para un sector regulado, esta transparencia tiene valor probatorio.
En segundo lugar, la ausencia de una licencia revocable. Una licencia libre —GPL, Apache, MIT— no se extingue por decisión unilateral. El editor no puede cortar el acceso a una versión ya obtenida, ni prohibir su uso de la noche a la mañana. La continuidad no depende de la buena voluntad de un tercero.
Por último, la posibilidad de crear una bifurcación. Si el proyecto cambia de rumbo, se cierra o cae en manos hostiles, el código sigue estando disponible y alguien puede retomar su desarrollo. La comunidad de mantenimiento, cuando existe, reparte esta carga entre varios colaboradores y varias organizaciones.
Lo que no garantiza
Ninguna de estas libertades es un servicio. El código abierto no incluye soporte técnico, ni garantía de corrección, ni hoja de ruta. La libertad de modificar solo es válida para quien sabe hacerlo, y la libertad de auditar solo es válida para quien dispone de los medios para ello. Leer el código fuente de un núcleo, un hipervisor o una base de datos para asegurarse de que no contiene fallos requiere competencias poco comunes y una inversión continua. El código disponible no es el código auditado.
La seguridad sigue la misma lógica. Un software libre no es seguro por el mero hecho de ser abierto; es seguro cuando personas competentes lo leen, lo prueban y lo corrigen a lo largo del tiempo. El episodio de la vulnerabilidad crítica de log4j en 2021 —un componente presente en innumerables sistemas y mantenido por un puñado de voluntarios— nos ha recordado que un componente abierto y omnipresente puede seguir sin recibir la financiación ni la supervisión necesarias. La apertura hace posible la auditoría, pero no la lleva a cabo.
Y, sobre todo, el código abierto no dice nada sobre la infraestructura. Un software libre siempre se ejecuta en algún lugar, en máquinas, en una red, bajo una jurisdicción. La licencia del código y la vinculación jurídica del proveedor de alojamiento son dos cuestiones distintas, y la primera nunca responde a la segunda.
Los casos en los que el OSS realmente cambia algo
El software libre influye en la soberanía cuando actúa sobre las palancas adecuadas. Tres situaciones lo demuestran.
El despliegue local. Un software libre instalado en una infraestructura que controla la propia organización elimina la dependencia de un proveedor de servicios remoto. El código está in situ, bajo una legislación elegida, sin que se realice ninguna llamada saliente a un tercero. Este es el caso que más se acerca a la independencia real.
La auditabilidad normativa. Para una autoridad sanitaria, un banco o un operador de importancia vital, poder presentar el código exacto que procesa datos sensibles no es una comodidad, sino que a veces es una obligación. Un componente propietario sellado impide aportar esta prueba; un componente abierto la permite.
La ausencia de una licencia revocable. Un servicio propietario crítico puede ver cómo cambian sus condiciones, cómo sube su precio o cómo se interrumpe su acceso por decisión de un editor o como consecuencia de una medida de extraterritorialidad. La licencia libre protege de este riesgo a la propia capa de software. No protege al resto.
Los casos en los que no cambia nada
Por el contrario, la etiqueta «código abierto» no ofrece ninguna garantía de soberanía en varias situaciones habituales.
El software libre implementado en las instalaciones de un tercero. Una base de datos o un orquestador libre que se gestiona como servicio gestionado en una infraestructura ajena está sujeto a la legislación de dicho operador, exactamente igual que un producto propietario. El código es abierto, pero la dependencia sigue siendo total. La naturaleza de la licencia no cambia en nada la vinculación jurídica de quien explota la máquina.
La dependencia de componentes propietarios. Un sistema operativo libre que solo arranca con controladores propietarios, microcódigos firmados o un firmware cerrado no es autónomo. La capa visible es abierta, pero se apoya en componentes que no se pueden leer, reproducir ni sustituir. La libertad se detiene ante la primera pieza sellada del hardware.
La falta de capacidad de mantenimiento interno. La libertad de bifurcar un núcleo crítico solo tiene valor para quien realmente puede mantenerlo. Una empresa muy regulada o un actor del sector de la defensa que no cuente con la ingeniería necesaria para retomar el desarrollo de un sistema operativo cuyo editor se retira se ve dependiente de un proveedor, ya sea abierto o no. El derecho a modificar no implica la capacidad de hacerlo.
En estos tres casos, la propiedad que importaba —el control de la capa y la posibilidad de salir de ella— no está garantizada por la licencia. Depende de dónde se ejecute el software, de en qué se base y de quién sepa gestionarlo.
Por lo tanto, la pregunta clave nunca se refiere a la etiqueta. Se plantea capa por capa, desde el hardware hasta el servicio: quién la controla, en virtud de qué derecho, y qué ocurre el día en que ese control se interrumpe. El software libre orienta algunas de estas respuestas en la dirección correcta. Pero no escribe las demás por ti.
Fuentes
- Free Software Foundation, definición de software libre, gnu.org
- Open Source Initiative, Open Source Definition, opensource.org
- Apache Software Foundation, vulnerabilidad Log4Shell (CVE-2021-44228), diciembre de 2021
- ANSSI, recomendaciones sobre la seguridad de las plataformas de software, cyber.gouv.fr