¿Otra vez, Microsoft? Por qué la vieja jugarreta del lock-in vuelve a pasar factura en Europa (y por qué Linux es la salida)

Europa ya ha visto esta película demasiadas veces: una empresa dominante empaqueta su software de forma que te “regala” una herramienta… y de pronto la “decisión” del cliente es una ilusión óptica. Hoy el protagonista vuelve a ser Microsoft, y la escena se repite con una familiaridad inquietante: atar servicios, cerrar interfaces, aprovechar posiciones de fuerza para condicionar el mercado… ¿resultado? Menos competencia, menos opciones reales y más dependencia. Para quienes creemos en el software libre, esto no es solo una cuestión filosófica: es una cuestión práctica de soberanía tecnológica, costes y resiliencia.

En este artículo —con datos y fuentes— hilamos la última controversia europea con Microsoft y el patrón histórico que la sostiene. Y, sobre todo, te propongo una alternativa madura y contundente: Linux y el ecosistema open source como antídoto estructural a estas “jugadas” de manual.

La jugada del año: Teams atado a Office

El 25 de junio de 2024, la Commisión Europea envió a Microsoft un pliego de cargos (Statement of Objections) por considerar que vincular Teams con Office 365/Microsoft 365 podría constituir una práctica abusiva de tying. La acusación no es menor: cuando un producto dominante (Office) “empuja” a usar otro (Teams) y además se levantan barreras de interoperabilidad, el resultado es que los rivales compiten con una mano atada a la espalda. Eso, de confirmarse, infringe las normas antimonopolio de la UE. (European Commission, Reuters)

Microsoft, consciente de que la cosa iba en serio, desempaquetó Teams en la UE y Suiza en 2023 y extendió la medida al resto del mundo el 1 de abril de 2024. En su propio blog de licencias, la compañía lo llamó “realinear” la oferta; la prensa lo leyó como un movimiento para aplacar a los reguladores europeos. Que nadie se lleve a engaño: desatar después de haber atado durante años no borra el efecto histórico de la vinculación, ni garantiza por sí mismo la restauración de la competencia. (The Official Microsoft Blog, Microsoft, Reuters)

¿Y por qué importa? Porque la mensajería y colaboración se han convertido en la columna vertebral del trabajo digital. Si el canal por el que fluyen tus conversaciones, videollamadas y archivos nace preseleccionado y con interfaces cerradas o poco documentadas, la fricción para cambiar a un competidor se dispara. Esa fricción es una renta que paga el cliente y que cobra el proveedor dominante.

No es un tropiezo: es un patrón

Quien piense que esto es una novedad no ha seguido el historial: en 2013, la UE multó a Microsoft con 561 millones de euros por romper su compromiso de mostrar a los usuarios una pantalla de elección de navegador (el famoso “browser ballot”). Dijo que lo haría; no lo hizo; y fue multado. Ya entonces el mensaje regulatorio era clarísimo: no uses tu sistema operativo para forzar el uso de tu navegador. (Ars Technica)

Pero vayamos más atrás. En 2004, tras una investigación de cinco años, la Comisión concluyó que Microsoft abusó de su posición dominante al atar Windows Media Player a Windows y no facilitar la interoperabilidad con servidores de trabajo en grupo. Llegó una multa récord y obligaciones de desatar y documentar. La película no acabó ahí: en 2008 cayó otra sanción de 899 millones de euros por incumplir la decisión de 2004. Patrón de conducta, remedio tardío. (European Union, European Commission)

Sumemos piezas: navegador, reproductor multimedia, colaboración… distintas décadas, misma lógica. Una suite omnipresente sirve de ariete, se empaqueta el servicio “satélite”, se siembran dependencias y, cuando suena el timbre del regulador, se promete un “ajuste” que llega tarde y a medias. Para los defensores del software libre, esto no es sorpresa: es precisamente el riesgo sistémico del software propietario con posiciones dominantes.

La nube, el nuevo campo de batalla europeo

Si en el escritorio la historia ya la conocemos, en la nube la ópera suena igual, solo que más fuerte. En 2024, Microsoft cerró un acuerdo con la asociación europea CISPE (que agrupa a proveedores cloud europeos) para zanjar una queja por licencias en la nube. Traducción: durante años, las licencias de software de Microsoft hicieron más caro o complicado ejecutar productos de Microsoft en nubes que no fueran Azure. El acuerdo —unos 20 millones de euros, según Reuters— evitó una investigación de la UE y prometió cambios para aliviar esas desventajas en Europa. (Reuters, CISPE)

¿Arreglado? Depende a quién preguntes. Google elevó su propia queja meses después, señalando que el acuerdo con CISPE no cubría a los hiperescalares no europeos (como Google Cloud o AWS). Es decir, que parte del ecosistema seguía fuera de la solución, y con ello persistían algunas preocupaciones de competencia. El humo de la polémica no se disipó, y el debate sobre licencias “pro-Azure” continuó en Bruselas y en la prensa. (Reuters)

Lo relevante no es la cifra del acuerdo, sino el modelo: si el titular del software puede diseñar la letra pequeña de las licencias de forma que penalice a quien elige infraestructura ajena, la competencia se ahoga sin necesidad de empujar técnicamente a nadie fuera del mercado. Es lock-in por otros medios.

El antídoto que Europa ya conoce: Linux y estándares abiertos

Todo esto lleva décadas alimentando un movimiento que no es de moda sino de ingeniería y gobernanza: el software libre. La propuesta de Linux (y del ecosistema open en general) es radicalmente distinta: la libertad de ejecutar, estudiar, modificar y redistribuir; la interoperabilidad como valor; la portabilidad como condición de diseño; la sustituibilidad como seguro frente a proveedores.

¿Por qué encaja especialmente bien en Europa?

  1. Soberanía y cumplimiento
    Europa se toma muy en serio el RGPD, la soberanía del dato y, ahora, la DMA. En un contexto donde la Comisión investiga ataduras y falta de interoperabilidad, Linux ofrece un terreno con estándares abiertos y implementaciones múltiples: puedes mover cargas entre nubes, entre on-prem y cloud, o entre distribuciones, sin pedir permiso a un único proveedor. Eso es un seguro regulatorio y operativo cuando las reglas cambian o cuando el proveedor cambia las suyas unilateralmente.
  2. Costes reales, no solo licencias
    El lock-in es un coste futuro disfrazado de regalo presente. Linux reduce el “coste de salida” porque no te ata a herramientas únicas ni a APIs cerradas. Que haya varios proveedores de soporte para la misma distro (o que puedas crear tu propio equipo interno) te da poder de negociación. Y si tu caso de uso es estable, el TCO se inclina a favor de soluciones abiertas a medio plazo (menos costes de cumplimiento, menos sorpresas de licenciamiento, menos “pegamento” para integraciones).
  3. Interoperabilidad como default
    Protocolos documentados, formatos abiertos (ODF, por ejemplo), stacks reproducibles. ¿Quieres mensajería? Matrix/Element. ¿Videoconferencia? Jitsi. ¿Colaboración de documentos? OnlyOffice o Collabora sobre Nextcloud. ¿CI/CD? GitLab CE, Jenkins. ¿Observabilidad? Prometheus + Grafana. No es un desierto: es un ecosistema vibrante y probado.
  4. Seguridad como proceso, no como promesa
    El código abierto permite auditar y parchear con rapidez. El vector de ataque ya no depende de si un fabricante decide priorizar tu incidencia. Con distros LTS y políticas de backporting, la gestión de vulnerabilidades es transparente y automatizable. Y la diversidad de distros reduce el riesgo de fallos catastróficos monoculturales.

“Linux está listo… salvo para lo que a ti te da miedo”: desmontando objeciones

“Mis hojas de Excel con macros no funcionan”.
Verdad a medias. Muchas macros VBA se ejecutan mal fuera de Excel, sí. Pero el punto no es replicar 100% del flujo heredado, sino preguntarte qué parte de ese flujo debe seguir siendo una macro y cuál debería ser una aplicación (por ejemplo, con Python + Pandas en un servidor, o con una app de bajo código basada en estándares). Para los casos irreductibles, virtualiza o mantén islas Windows; el resto gana en mantenibilidad y audibilidad.

“No hay drivers / mi hardware es especial”.
El ecosistema de drivers Linux es amplísimo. Aun así, para hardware con soporte dudoso, invierte en una lista de compatibilidad (HCL) y en estandarizar modelos. El 80/20 funciona: cubre el 80% del parque con hardware bien soportado y confina el resto a escenarios específicos o VDI.

“El usuario final se queja”.
Sin formación, también se quejó cuando pasasteis de XP a 7, y de 7 a 10. Gestiona el cambio: rollouts pilotos, champions internos, training orientado a tareas (no a “menús”). Y mide con métricas de tickets y tiempos de resolución: los prejuicios caen cuando hay datos.

“¿Y el soporte?”
Sobra oferta: Canonical, SUSE, Red Hat (y sus clónicos comunitarios), consultoras locales europeas… Puedes tener SLA firmados y una ruta de escalado tan “enterprise” como quieras… sin renunciar a la libertad.

Hoja de ruta pragmática para escapar del lock-in

No se trata de “dejar Microsoft mañana”. Se trata de diseñar salidas y bajar dependencias.

  1. Empieza por el servidor y el contenedor
    Si tu stack ya es Kubernetes/Docker, probablemente ya es Linux aunque sigas pagando licencias por arriba. Normaliza tus runtimes en Linux y migra herramientas de observabilidad/CI/CD a alternativas abiertas. Tu equipo de DevOps te lo agradecerá.
  2. Mata cuatro ataduras con formatos abiertos
    Declara ODF como formato por defecto en documentación interna. Solo eso ya reduce tu dependencia de una única suite. Añade linters y validadores para garantizar compatibilidad.
  3. Desacopla colaboración de productividad
    El gran truco del bundle moderno es que documentos, chat, videollamada y almacenamiento viven bajo el mismo techo y eso te encadena. Separa la mensajería (Matrix), la videollamada (Jitsi/Zoom/lo que prefieras), y el almacenamiento (Nextcloud/S3 compatible). Si una pieza abusa, la cambias sin tocar el resto.
  4. Compra con contratos “pro-salida”
    En cada RFP añade cláusulas de portabilidad de datos, APIs documentadas, pruebas de interoperabilidad y penalizaciones por cambios unilaterales de licencias que afecten al TCO. Si un proveedor rehúye esas cláusulas, te está confesando algo.
  5. Reduce Office donde más duele menos
    Identifica grupos que usan la suite para tareas básicas (lectura/edición sencilla). Migra primero ahí a LibreOffice/OnlyOffice, mantén Excel “nativo” donde tenga sentido (finanzas, ingeniería con macros). Con el tiempo, reescribe procesos críticos. El objetivo no es prohibir, es optimizar.
  6. Mide, itera, publica resultados
    KPIs claros: coste por puesto, tiempo medio de resolución, nº de incidencias críticas, satisfacción del usuario, uptime. Que el proyecto no dependa de “fervor”, sino de datos.

Europa y el lock-in: lecciones de un cuarto de siglo

La cronología europea no miente: 2004 (WMP atado a Windows), 2008 (multa por no cumplir), 2013 (sanción por faltar a la pantalla de elección de navegador), 2024–2025 (equipos de colaboración y licencias en la nube bajo lupa). No son “resbalones”; son incentivos. Si el mercado te premia por atar al cliente y solo te “caza” cuando un regulador te mira, lo racional —aunque socialmente dañino— es atar. De ahí que el diseño institucional de Europa (DMA, DSA, control de concentraciones) y el diseño técnico del software libre se den la mano: el regulador desata; el open source impide que el nudo se refuerce otra vez.

Por eso conviene anclar la crítica en hechos:

  • El pliego de cargos de 2024 contra el tying de Teams con Office no cae del cielo; es la continuación de un hilo donde la Comisión vigila integraciones que reducen la elección real del usuario y piden interoperabilidad de verdad. (European Commission)
  • El “desempaquetado mundial” de Teams (abril 2024) reconoce explícitamente que el modelo anterior generaba problemas; no los borra, pero admite el diagnóstico. (Microsoft)
  • La sanción de 2013 por el “browser ballot” prueba que incluso los compromisos voluntarios pueden quebrarse si no hay vigilancia. (Ars Technica)
  • Las multas de 2004 y 2008 dibujan el antecedente de ataduras y falta de interoperabilidad. (European Union, European Commission)
  • El acuerdo con CISPE en 2024 confirma que las letras pequeñas de las licencias pueden distorsionar la competencia en la nube, y que no todos los actores quedaron satisfechos con la “solución” propuesta. (Reuters)

Este mosaico cuenta una historia simple: si tu negocio depende de capas privadas con efectos de red, tus incentivos te empujan a cerrar, atar y encarecer la salida. Si tu negocio depende de estándares y código abierto, ganas atrayendo, interoperando y estando a la altura de la comparación. Uno se sostiene por cerrojos; el otro, por mérito.

“Pero… ¿y si Microsoft cambia?” (La pregunta equivocada)

Puede que Microsoft haga concesiones adicionales para evitar una gran multa en el caso Teams, como han sugerido varias informaciones de prensa en 2025. Bienvenidas sean. Sin embargo, plantear la estrategia digital de una empresa, una administración o un país sobre “confiemos en que el proveedor cambie” es un error de primero de arquitectura. Los sistemas críticos no deben depender de la benevolencia de un actor con poder estructural, ni de su calendario de licencias.

La pregunta correcta no es si Microsoft cambiará, sino si tú puedes cambiar cuando lo necesites. Con Linux y estándares abiertos, la respuesta es sí. Puedes cambiar de proveedor de soporte, de nube, de distro, de stack de colaboración. Puedes cambiar sin rehacerlo todo.

Cierre: libertad operativa, ventaja competitiva

La “evangelización” de Linux no va de camisetas negras ni de dogmas: va de control. Control sobre tus costes, tus datos, tus tiempos y tus riesgos. La última jugarreta europea que acabamos de repasar —atar Teams a Office y diseñar licencias que hacen “más barato” quedarse que salir— es solo un recordatorio de que el software propietario dominante marca la música y te cobra la pista de baile.

Linux y el ecosistema open te proponen otra cosa: elegir hoy sin sufrir mañana. Si Europa quiere empresas y administraciones competitivas, soberanas y resilientes, tiene que reducir su exposición al lock-in y aumentar su dependencia de estándares, interoperabilidad y código abierto.

No esperes al próximo pliego de cargos para descubrir que la puerta estaba abierta. Empieza a caminar hacia ella.

Fuentes clave

  • Comisión Europea: Pliego de cargos a Microsoft por posible atado de Teams a Office (25/06/2024). (European Commission)
  • Reuters: Cargos antimonopolio de la UE por el caso Teams; historial con la Comisión. (Reuters)
  • Microsoft (blog oficial): “Realigning global licensing for Microsoft 365” (01/04/2024). (Microsoft)
  • Ars Technica: Multa de 561 M€ por incumplir la pantalla de elección de navegador (2013). (Ars Technica)
  • Comisión Europea: Decisión de 2004 (WMP atado a Windows) y multa de 2008 por incumplimiento. (European Union, European Commission)
  • Reuters / CISPE: Acuerdo con CISPE por licencias en la nube (≈20 M€) y reacciones del sector. (Reuters, CISPE)

(Este texto combina opinión informada con hechos verificados. Las conclusiones y recomendaciones son del autor; los hechos concretos que anclan el análisis están referenciados en las fuentes anteriores.)

  • Hola 👋 , soy la IA de Linuxmind.dev, te puedo ayudar a aprender.
Gathering thoughts ...

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *