Comprar una empresa open source no compra el código: el caso DuckDB

La integración anunciada de DuckLabs como filial de AWS no permite retirar los permisos de las copias de DuckDB ya distribuidas bajo licencia MIT. El anuncio de DuckDB precisa que la operación está prevista para principios de septiembre de 2026 y que el proyecto seguirá bajo la tutela de la DuckDB Foundation.

La razón es que empresa, código y proyecto no son el mismo activo: DuckLabs reúne al equipo principal y presta servicios comerciales, mientras la Foundation conserva la propiedad intelectual de DuckDB. La operación puede alterar empleos, financiación y prioridades de desarrollo, pero no revoca la licencia concedida sobre versiones ya publicadas.

La licencia MIT acompaña a las copias distribuidas

La MIT concede a quien recibe el software facultades amplias para usarlo, copiarlo, modificarlo, fusionarlo, publicarlo, distribuirlo, sublicenciarlo y vender copias. A cambio, el texto de la licencia MIT exige incluir el aviso de copyright y el permiso en las copias o partes sustanciales; también excluye garantías y limita la responsabilidad de autores y titulares.

Una compraventa empresarial posterior no modifica por sí sola la licencia incluida en una versión que ya fue entregada. La organización usuaria puede conservar esa versión, modificarla o mantener un fork dentro de los permisos recibidos, sin necesidad de contratar al comprador.

La distinción importante está en el tiempo. Los permisos cubren el código distribuido bajo MIT, pero no obligan a nadie a publicar versiones futuras, aceptar contribuciones, corregir errores ni mantener compatibilidad. El titular de código nuevo puede elegir otras condiciones si dispone de todos los derechos necesarios; eso no convierte retroactivamente en privativas las versiones anteriores.

DuckDB separa proyecto, fundación y empresa comercial

En DuckDB, la operación corporativa recae sobre DuckLabs, no sobre la entidad que custodia el proyecto. Las preguntas frecuentes de DuckDB indican que todo el proyecto se publica bajo MIT, que su desarrollo se realiza en el repositorio duckdb/duckdb y que no existe una edición empresarial separada. También atribuyen la propiedad intelectual del proyecto a la DuckDB Foundation, una organización sin ánimo de lucro cuyos estatutos obligan a mantener DuckDB abierto bajo MIT de forma permanente.

DuckLabs cumple otra función: ofrece soporte comercial y emplea a los colaboradores principales. Por eso, adquirir la compañía puede trasladar contratos laborales, conocimiento concentrado y capacidad de ejecución sin entregar automáticamente la propiedad intelectual depositada en la Foundation.

Esta estructura protege la licencia y la gobernanza formal, pero no garantiza por sí sola el mismo ritmo de trabajo. La revisión de contribuciones, la preparación de versiones, la respuesta a incidencias y la evolución técnica dependen de personas y recursos, aunque el código continúe disponible.

Seis controles distintos detrás de un proyecto abierto

Para evaluar una adquisición conviene separar los activos y facultades que suelen presentarse bajo una sola marca:

• Licencia: define qué puede hacer cada receptor con el código ya distribuido. No promete mantenimiento, soporte ni futuras publicaciones.
• Copyright: determina quién puede autorizar nuevas formas de distribución o cambiar la licencia de futuras versiones, siempre que controle los derechos de las contribuciones incluidas.
• Marca: identifica al proyecto oficial y se rige separadamente del permiso para modificar el software. Tener derecho a crear un fork no implica poder presentarlo con el mismo nombre o identidad visual.
• Repositorio e infraestructura: las cuentas, dominios, registros de paquetes, claves de firma y sistemas de publicación permiten controlar el canal oficial, aunque no eliminen las copias existentes.
• Mantenedores: el empleador puede reasignar su tiempo o cambiar prioridades. La comunidad conserva la posibilidad jurídica de continuar el código, pero necesita conocimiento y capacidad de coordinación.
• Servicios comerciales: soporte, alojamiento, integraciones privadas y acuerdos de nivel de servicio pueden pertenecer a la empresa adquirida y quedar fuera de la licencia del núcleo.

La matriz evita dos conclusiones incorrectas. Un repositorio público no garantiza continuidad operativa; del mismo modo, la compra del principal empleador no significa necesariamente que el comprador pueda cerrar o relicenciar el núcleo.

Qué puede cambiar el comprador

Un comprador puede dejar de financiar líneas de trabajo, reorganizar al equipo, retirar una oferta comercial o modificar las condiciones de un servicio alojado. También puede reservar desarrollos futuros cuyos derechos pertenezcan a la compañía y concentrar conocimientos que resulten costosos de reconstruir.

No adquiere por ese solo hecho la facultad de cancelar los permisos MIT de copias distribuidas legítimamente. En el caso de DuckDB, comprar DuckLabs tampoco equivale a comprar la propiedad intelectual que la Foundation mantiene separada.

Incluso si el repositorio oficial se archivara o trasladara, las copias existentes y sus permisos no desaparecerían. El riesgo pasaría a ser operativo: reunir mantenedores, reproducir la cadena de publicación, gestionar vulnerabilidades y conseguir que usuarios y distribuidores confíen en una continuación independiente.

Comprobaciones antes de adoptar una dependencia

Una revisión útil debe documentar tanto los derechos sobre el software como la capacidad real de sostenerlo. Para una dependencia relevante conviene comprobar:

1. La licencia exacta de la versión utilizada y los avisos que deben conservarse.
2. La identidad de los titulares del copyright y la forma en que se gestionan las contribuciones externas.
3. Qué entidad posee el núcleo, la marca, los dominios y la infraestructura de publicación.
4. Qué componentes están abiertos: núcleo, clientes, extensiones, conectores y herramientas de administración.
5. Quién controla los paquetes oficiales, las claves de firma, la integración continua y la divulgación de vulnerabilidades.
6. Cuántos mantenedores críticos dependen del mismo empleador y quién podría publicar una versión alternativa.
7. Qué funciones dependen de soporte contratado, servicios alojados, API privadas o extensiones no cubiertas por la licencia del núcleo.
8. Si la organización conserva una versión fijada y reproducible, pruebas propias y una alternativa viable de migración o mantenimiento.

DuckDB muestra por qué estas preguntas deben responderse por separado. Su licencia preserva amplios derechos sobre el código publicado y la Foundation protege la continuidad jurídica; la concentración del trabajo principal en DuckLabs mantiene, en cambio, una dependencia operativa. Una adquisición puede controlar al proveedor y a buena parte del equipo sin controlar las copias ya licenciadas ni, en esta estructura, la propiedad del proyecto.

Lee también:

• Tu empresa puede vigilar el correo, pero debe explicar por qué lo hace
• Repartir la empresa al 50% no resuelve qué pasa si un socio se marcha
• Las solicitudes de desempleo suben, pero siguen lejos de una ola de despidos