El cierre de Gemini CLI no es solo otra historia de Google apagando un producto. Google ha cerrado muchos servicios antes y, aunque resulte molesto, el mercado ya lo tiene interiorizado. Esta vez el caso es distinto porque afecta a una herramienta presentada como open source, alimentada por contribuciones externas y adoptada por desarrolladores que la integraron en su flujo diario de trabajo. No estamos ante una simple decisión de catálogo. Estamos ante una grieta más en el contrato de confianza entre las grandes tecnológicas y las comunidades que construyen alrededor de ellas.
Gemini CLI tenía licencia Apache 2.0, repositorio público, miles de estrellas en GitHub y una comunidad que aportó errores, mejoras, extensiones y conocimiento práctico. Pero el 18 de junio de 2026 dejará de servir peticiones para usuarios gratuitos, Google AI Pro, Ultra y Gemini Code Assist para individuos. El reemplazo es Antigravity CLI, integrado en la plataforma Google Antigravity y que, por ahora, Google no ha publicado como open source. Los clientes empresariales, en cambio, mantienen acceso, igual que quienes paguen mediante claves de API de Gemini y de Gemini Enterprise Agent Platform. Para muchos desarrolladores, el mensaje es difícil de digerir: quienes ayudaron a convertir la herramienta en algo útil son los primeros en quedarse fuera.
El código abierto protege el código, no siempre la dependencia
El caso de Gemini CLI resume una nueva tensión del software moderno. Durante años, una licencia open source daba una salida real: si una empresa cambiaba el rumbo, la comunidad podía hacer un fork y continuar. Eso ocurrió con OpenSearch tras Elasticsearch, con OpenTofu tras Terraform o con Valkey tras Redis. No siempre fue fácil, pero era posible porque el valor principal estaba en el código.
Con la inteligencia artificial la situación cambia. Gemini CLI puede seguir teniendo el código abierto, pero el motor real está en los modelos, las cuotas, la autenticación, los endpoints y la infraestructura de Google. Se puede copiar el volante, pero no el motor. Y cuando el proveedor decide cortar el acceso o mover el producto a otro modelo, la comunidad descubre que su capacidad de reacción era mucho menor de lo que parecía.
Esa es la lección incómoda. No basta con preguntar si un proyecto tiene licencia open source. Hay que preguntar quién controla el servicio, quién decide el roadmap, quién gestiona las claves, si hay modelos alternativos, si los workflows son portables y si la gobernanza permite a la comunidad influir de verdad. En la era de la IA agéntica, una herramienta abierta puede ser solo la interfaz bonita de una dependencia cerrada.
Google argumentará que Antigravity CLI responde mejor a los nuevos flujos multiagente y que Gemini CLI ya no encaja con la dirección del producto. Puede ser cierto. Las empresas tienen derecho a reorganizar sus productos. Pero cuando una compañía invita a una comunidad a contribuir, acepta también una responsabilidad moral: no tratar ese trabajo como combustible desechable cuando cambia la estrategia.
No es un caso aislado: una década de cambios de reglas
Lo de Google encaja en una historia más amplia. En los últimos años varias empresas han cambiado licencias, limitado accesos o movido productos abiertos hacia modelos “source available”, comerciales o directamente propietarios. Casi siempre el argumento es parecido: sostener el negocio, defenderse de los grandes proveedores cloud, evitar que terceros moneticen el trabajo propio o financiar el desarrollo futuro.
El problema no es que una empresa quiera ganar dinero. El problema aparece cuando el crecimiento se apoya durante años en la etiqueta open source, en contribuciones externas y en adopción comunitaria, y después las reglas cambian cuando el producto ya es crítico para miles de organizaciones.
| Fecha | Empresa / proyecto | Qué cambió | Reacción o consecuencia |
|---|---|---|---|
| 16/10/2018 | MongoDB | MongoDB Community Server pasó de AGPL a SSPL | Debian, Fedora y otros ecosistemas rechazaron SSPL como licencia open source; aumentó el debate sobre bases de datos gestionadas en cloud |
| 04/06/2019 | CockroachDB | Cockroach Labs movió el core de Apache 2.0 a Business Source License | Se reforzó el modelo source available para impedir ciertos usos como servicio gestionado competitivo |
| 14/01/2021 | Elastic | Elasticsearch y Kibana dejaron Apache 2.0 y pasaron a SSPL / Elastic License | AWS respondió con OpenSearch, fork abierto de Elasticsearch y Kibana 7.10.2; en agosto de 2024 Elastic volvió a ofrecer una opción open source añadiendo AGPLv3 |
| 31/08/2021 | Docker Desktop | Docker cambió sus suscripciones y exigió pago para uso comercial en grandes empresas tras un periodo de gracia | Muchas empresas revisaron alternativas como Podman o políticas internas de uso |
| 21/06/2023 | Red Hat / RHEL | Red Hat limitó la publicación pública del código fuente de RHEL y dejó CentOS Stream como repositorio público principal | AlmaLinux, Rocky Linux y Oracle Linux tuvieron que adaptar su estrategia |
| 10/08/2023 | HashiCorp / Terraform | HashiCorp cambió Terraform y otros productos de MPL 2.0 a BSL 1.1 | La comunidad creó OpenTofu, incorporado a Linux Foundation |
| 20/03/2024 | Redis | Redis dejó BSD 3-Clause desde Redis 7.4 y pasó a RSALv2 / SSPLv1 | Nació Valkey como alternativa abierta bajo Linux Foundation; en mayo de 2025 Redis regresó al open source con AGPLv3 (Redis 8) |
| 19/05/2026 | Google / Gemini CLI | Google anunció la transición de Gemini CLI a Antigravity CLI y el corte para muchos usuarios el 18/06/2026 | Desarrolladores criticaron que una herramienta abierta pase a una alternativa menos abierta y sin paridad completa inicial |
Cada caso tiene matices. No es lo mismo MongoDB que Redis, ni Docker Desktop que Red Hat, ni Terraform que Gemini CLI. Pero todos comparten una pregunta de fondo: ¿qué ocurre cuando una comunidad adopta una herramienta bajo unas expectativas y la empresa que la controla cambia las reglas?
En algunos casos, la comunidad respondió con forks fuertes y gobernanza más neutral. OpenTofu y Valkey son buenos ejemplos porque no se quedaron en una protesta. Se organizaron, buscaron respaldo institucional y ofrecieron continuidad técnica. La presión fue tan eficaz que en algunos casos forzó a las propias empresas a recular: Elastic volvió a ofrecer una licencia open source con AGPLv3 en agosto de 2024 y Redis hizo lo mismo con Redis 8 en mayo de 2025. En otros casos, la respuesta fue más fragmentada.
Y aquí está la diferencia incómoda con la IA. Esa válvula de escape —forkear el código, sostenerlo en una fundación neutral y, a veces, obligar a la empresa a rectificar— existe porque el valor estaba en el código. Con herramientas de IA dependientes de modelos cerrados, no hay nada equivalente que forkear: puedes quedarte con el cliente, pero no con el modelo, las cuotas ni la infraestructura. La salida será todavía más difícil.
La confianza es una infraestructura
Durante años se ha tratado el open source como si fuera solo una licencia. No lo es. Es también una expectativa de continuidad, una forma de colaboración y una señal de confianza. Cuando alguien contribuye a un proyecto, no solo entrega código. Entrega tiempo, pruebas, documentación, reputación y conocimiento acumulado. A veces también construye negocio encima.
Por eso estos cambios duelen. No porque las empresas tengan prohibido evolucionar, sino porque muchas se benefician primero del capital social del open source y después actúan como si ese capital no existiera. Usan la apertura para crecer y el cierre para capturar valor. Puede ser legal. Puede ser incluso comprensible desde una presentación a inversores. Pero rompe algo que cuesta mucho reconstruir.
En mi opinión, la comunidad tecnológica debe dejar de confundir “repositorio público” con “proyecto abierto”. Un proyecto abierto de verdad necesita licencia, sí, pero también gobernanza, portabilidad, documentación, compatibilidad, neutralidad razonable y capacidad real de continuidad. Si todo depende de una única empresa, el riesgo está ahí desde el primer día.
Esto es especialmente importante con las herramientas de inteligencia artificial para desarrollo. Los agentes de código se están convirtiendo en una capa de trabajo diaria: revisan repositorios, escriben pruebas, generan documentación, ejecutan comandos y pronto tocarán procesos de despliegue. Si esas herramientas pueden desaparecer o cambiar de modelo con 30 días de aviso, no son solo una comodidad. Son una dependencia crítica mal gobernada.
La respuesta no tiene que ser abandonar Google, OpenAI, Anthropic o cualquier proveedor grande. Sería ingenuo. La respuesta debe ser diseñar con menos dependencia: prompts y workflows bajo control propio, compatibilidad con varios modelos, protocolos abiertos como MCP cuando tenga sentido, abstracciones internas, rutas alternativas y una política clara sobre qué herramientas pueden entrar en procesos críticos.
También deberíamos valorar más los proyectos con fundaciones neutrales, modelos abiertos reales y gobernanza comunitaria. No porque sean perfectos, sino porque reducen el riesgo de que una sola reunión de producto cambie el futuro de miles de usuarios.
Google no ha violado necesariamente la licencia de Gemini CLI. Ese no es el debate principal. El problema es que ha recordado a todos algo muy sencillo: el open source corporativo puede darte código, pero no siempre te da poder. Y cuando una empresa controla el motor, la carretera y la llave de contacto, la libertad de modificar el volante sirve de poco.
Preguntas frecuentes
¿Gemini CLI deja de ser open source? No necesariamente. El código puede seguir publicado bajo licencia Apache 2.0 y Google ha dicho que mantendrá el repositorio. Lo que cambia es el acceso práctico al servicio para muchos usuarios: a partir del 18 de junio de 2026 deja de servir peticiones en los planes gratuito, Pro y Ultra y para Gemini Code Assist de individuos, aunque seguirá accesible mediante claves de API de pago y para clientes empresariales.
¿Por qué este caso es distinto a otros cierres de Google? Porque Gemini CLI no era solo un producto cerrado. Era una herramienta open source con contribuciones de la comunidad, integrada en flujos reales de desarrollo y ahora sustituida por una alternativa más controlada, Antigravity CLI, que de momento no se ha publicado como open source.
¿Qué diferencia hay entre open source y source available? Open source implica libertades reconocidas para usar, estudiar, modificar y redistribuir el software bajo licencias aprobadas por la comunidad. Source available permite ver el código, pero puede imponer restricciones que impiden considerarlo open source.
¿Sirve de algo la presión de la comunidad cuando una empresa cierra un proyecto? A veces sí. En bases de datos, los forks respaldados por fundaciones neutrales (OpenTofu, Valkey, OpenSearch) ofrecieron continuidad e incluso forzaron rectificaciones: Elastic y Redis acabaron volviendo a una licencia open source con AGPLv3. Con herramientas de IA dependientes de modelos cerrados esa salida es mucho más difícil, porque no se puede forkear el modelo ni la infraestructura.
¿Qué deberían hacer las empresas que usan herramientas de IA para desarrollar? Deben tratarlas como dependencias críticas: revisar licencias, proveedor, portabilidad, costes, continuidad, acceso a modelos y posibilidad de migrar si el servicio cambia o desaparece.
Fuentes:
- Google Developers Blog: transición de Gemini CLI a Antigravity CLI (19/05/2026).
- MongoDB: anuncio de la licencia SSPL para MongoDB Community Server (16/10/2018).
- Cockroach Labs: adopción de la Business Source License (04/06/2019).
- Elastic: cambio de Elasticsearch y Kibana de Apache 2.0 a SSPL / Elastic License (14/01/2021) y posterior adición de AGPLv3 (29/08/2024).
- Linux Foundation: lanzamiento de OpenTofu tras el cambio de licencia de Terraform.
- HashiCorp: adopción de la Business Source License (10/08/2023).
- Redis: cambio a licencias RSALv2 y SSPLv1 desde Redis 7.4 (20/03/2024) y regreso al open source con AGPLv3 en Redis 8 (mayo de 2025).
- Linux Foundation: Valkey como alternativa abierta tras el cambio de licencia de Redis.
- Red Hat: cambios en la disponibilidad pública del código fuente de RHEL (21/06/2023).
- Docker: actualización de las suscripciones de Docker Desktop (31/08/2021).