Software de código abierto en administración

El código abierto permite ver, auditar y corregir el software, y eso es una ventaja de seguridad real. Pero que cualquiera pueda corregirlo no significa que alguien lo vaya a hacer por la entidad: los parches los publican los mantenedores cuando pueden, y la alcaldía los tiene que aplicar. Por eso las políticas piden, para lo crítico, un responsable interno o un soporte contratado.

Un código sin licencia declarada no se puede usar con seguridad jurídica: por defecto, el autor conserva los derechos y la entidad no tiene permiso expreso para usarlo, modificarlo ni distribuirlo. Por eso la política de Montelindo es tajante: un componente sin licencia declarada no se usa. Es lo primero que se busca en un inventario de componentes.

Un componente sin lanzamientos desde hace años no necesariamente es malo, pero no recibe correcciones de seguridad, y cada nuevo fallo que se descubra en él se quedará sin parche. La política de Montelindo fija un límite: sin lanzamientos en los últimos 24 meses, el componente entra en un plan de reemplazo.

Cuenta contra el corte (2026-10-07) cuántos componentes del inventario entran en ese plan.

Tres señales juntas dibujan el riesgo típico de un componente abierto: criticidad alta, un solo mantenedor activo y ningún soporte detrás. Si esa persona deja el proyecto, el componente se queda huérfano justo cuando más importa. Cruza el inventario con la tabla de soporte.

Algunas licencias imponen obligaciones al distribuir el software o al ofrecerlo a otros, y alguna de ellas llega a cubrir a quien lo usa a través de una red. No son licencias prohibidas: son licencias que hay que entender antes de usarlas. Por eso la política las pone en una lista de revisión legal previa, y no en la de uso libre.