10.3 Contratación pública, código abierto, y licenciamiento

Presentación y motivación

Casi cada sistema de software moderno se ensambla en su mayoría a partir de componentes que alguien más escribió. El software de código abierto forma el fundamento de los sistemas operativos, lenguajes, marcos, bases de datos, e infraestructura de nube. Entra a la empresa de dos maneras: a través de la contratación pública deliberada, y a través de declaraciones import casuales de desarrolladores individuales. Este capítulo trata de hacer ese consumo (y, donde encaje, la contribución) deliberadamente. Eso significa una estrategia, cumplimiento de licencias, una comprensión de las obligaciones y el riesgo de copyleft, y un plan para el inevitable fin de vida de los componentes de los que dependes.

Para los equipos grandes, lo que está en juego es legal, operacional, y estratégico todo a la vez. Legalmente, las licencias de código abierto son contratos exigibles con obligaciones reales. Equivocarse con el copyleft (licenciamiento que puede exigir que los trabajos derivados se compartan bajo los mismos términos) puede, en el peor caso, obligar a divulgar código fuente propietario o disparar litigio. Las violaciones de licencia pueden incluso bloquear una adquisición o una oferta pública durante la diligencia debida. Operacionalmente, las dependencias sin gestionar se pudren: los componentes quedan sin mantenimiento, acumulan vulnerabilidades, y llegan al fin de vida mientras todavía están enterrados profundamente en producción. Estratégicamente, el código abierto es más que una entrada de ahorro de costo. Es una manera de evitar la dependencia de proveedor, atraer talento, y moldear los ecosistemas de los que dependes, ventajas que solo capturas si te involucras a propósito.

El gobierno tiene una dimensión añadida. Muchas jurisdicciones ahora tienen políticas explícitas que favorecen el código abierto, los estándares abiertos, y el intercambio de código entre agencias. A menudo se expresan como «dinero público, código público»: el principio de que el software financiado por los contribuyentes debería, por defecto, estar disponible para el público. Así que los ingenieros del sector público deben navegar tanto el cumplimiento de licencias como los mandatos activos de preferir, publicar, y reutilizar el código abierto. Este capítulo busca hacer todo esto manejable a escala.

Principios fundamentales

El código abierto es una cadena de suministro, no cosas gratis. Trata los componentes consumidos con el mismo rigor que cualquier proveedor crítico.
Las licencias son obligaciones, no permisos para ignorar. Cada dependencia lleva términos; conócelos antes de enviar.
El copyleft es una restricción de diseño, no un tabú. Las licencias copyleft son usables y valiosas; solo requieren que entiendas cómo combinas y distribuyes el software.
Consume deliberadamente, contribuye estratégicamente. Decide qué traer y, donde te sirva, invierte en enviar aguas arriba en lugar de bifurcar.
Inventaría todo. No puedes cumplir con, asegurar, o actualizar lo que no puedes ver; una SBOM (lista de materiales de software, un inventario completo de los componentes en tu software) es lo mínimo indispensable.
Planifica para el fin de vida desde el principio. Cada dependencia algún día no tendrá mantenimiento; conoce tu salida antes de que te fuercen a una.
En el gobierno, por defecto abierto. Prefiere los estándares abiertos y el código abierto, y publica el código de dinero público a menos que haya una razón específica para no hacerlo.

Recomendaciones

Fija una estrategia de código abierto y política de consumo

Publica una política clara de cómo los desarrolladores pueden traer código abierto a la organización: qué licencias están preaprobadas, cuáles requieren revisión, y cuáles están prohibidas para tus casos de uso. Provee una ruta de aprobación rápida y de baja fricción. Una política más lenta que copiar código simplemente se ignorará. Distingue contextos, porque la misma licencia se comporta de manera distinta cuando un componente se usa internamente como servicio, se incrusta en un producto distribuido, o se enlaza en una aplicación propietaria. Haz del camino fácil el camino conforme: un repositorio interno curado de componentes verificados, escaneo automatizado en el canal, y guía clara que los desarrolladores puedan seguir sin llamar a un abogado para casos rutinarios.

Gestiona el cumplimiento de licencias, las obligaciones, y el riesgo de copyleft

Conoce las familias de licencias y sus obligaciones. Las licencias permisivas (como MIT, BSD, y Apache 2.0) principalmente requieren atribución y preservación de aviso; Apache 2.0 añade una concesión de patente explícita. El copyleft débil (como LGPL y MPL) te exige compartir las modificaciones a los archivos cubiertos pero generalmente te permite combinar con código propietario. El copyleft fuerte (como GPL) puede exigir que toda la obra distribuida se ofrezca bajo los mismos términos. El copyleft de red (AGPL) extiende esa obligación al software ofrecido a través de una red, no solo distribuido como binarios. Las obligaciones que más importan giran sobre dos cosas: si distribuyes el software, y cuán estrechamente combinas los componentes. Automatiza el cumplimiento: escanea las dependencias en busca de licencias, genera y envía los archivos de atribución y aviso requeridos, y bloquea la construcción por política para que una licencia prohibida no pueda entrar silenciosamente a producción.

Establece una Oficina de Programa de Código Abierto (OSPO)

Si consumes código abierto a escala, crea un punto focal, una OSPO, que posea la estrategia de código abierto, la política, las herramientas de cumplimiento, la gobernanza de contribución, y las relaciones con la comunidad. La OSPO frena el caos de que cada equipo tome sus propias decisiones. Provee experiencia que los equipos individuales no pueden mantener. Y captura valor estratégico: decidir en qué proyectos invertir, cuándo contribuir aguas arriba, y cómo liberar bien tus propios proyectos de código abierto. Incluso una OSPO pequeña (a veces una persona más un grupo de trabajo multifuncional) mejora dramáticamente la consistencia y reduce el riesgo legal comparado con un todos-contra-todos.

Gobierna la contribución y, donde encaje, la publicación

Decide deliberadamente cuándo contribuir de vuelta. Enviar correcciones y funciones aguas arriba a los proyectos de los que dependes reduce tu carga de mantenimiento, porque dejas de cargar parches privados. También construye buena voluntad e influencia, y fortalece los componentes críticos para ti. Da a los desarrolladores un proceso claro y rápido para las contribuciones aprobadas, incluyendo cómo se manejan la propiedad intelectual y los acuerdos de contribuyente. Cuando liberes tus propios proyectos de código abierto, hazlo apropiadamente: elige una licencia adecuada, documenta la gobernanza, y comprométete con la administración. Un proyecto abandonado daña tu reputación más que ningún proyecto.

Cumple los mandatos gubernamentales de código abierto y «dinero público, código público»

Los equipos del sector público deberían tratar la apertura como el valor predeterminado. Prefiere los estándares abiertos para evitar la dependencia de proveedor y trabajar a través de agencias y proveedores. Publica el código fuente desarrollado con fondos públicos abiertamente, a menos que se aplique una exención específica y documentada: para componentes sensibles a la seguridad, derechos de terceros, o preocupaciones de privacidad. Reutiliza antes de construir: comprueba si otra agencia ya ha liberado código adecuado. Incorpora estas expectativas en la contratación pública, para que los proveedores entreguen código abierto, reutilizable, y bien documentado con el gobierno manteniendo los derechos apropiados, en lugar de cajas negras propietarias que la agencia no puede mantener ni compartir.

Gestiona las dependencias y el software de fin de vida

Mantén un inventario vivo (SBOM) de cada componente y su versión, licencia, y estado de mantenimiento. Mantén las dependencias razonablemente actuales. Las actualizaciones pequeñas y frecuentes son mucho más baratas y seguras que los saltos raros y gigantes. Vigila los proyectos aguas arriba en busca de anuncios de fin de vida y ventanas de soporte de seguridad, y planifica las migraciones antes de que termine el soporte, no después de que una vulnerabilidad fuerce una carrera. Para los componentes críticos en riesgo de abandono, decide de antemano si financiarás al mantenedor, contribuirás mantenimiento tú mismo, bifurcarás, o reemplazarás. Rastrea el fin de vida tanto para el software comercial como de código abierto, y mantén el agotamiento del soporte al mismo estándar que cualquier otro riesgo operacional.

Ventajas y desventajas

Elección	Ventajas	Desventajas
Consumir código abierto libremente	Entrega rápida; apalancamiento enorme; sin tarifas de licencia	Obligaciones de licencia, seguridad, y mantenimiento que ahora posees
Lista blanca de licencia estricta	Bajo riesgo legal; predecible	Ralentiza a los equipos; puede excluir componentes genuinamente útiles
Solo licencias permisivas	Obligaciones mínimas; fácil de combinar	Renuncia a proyectos copyleft valiosos; menos reciprocidad
Aceptar copyleft donde sea adecuado	Acceso a ecosistemas fuertes; beneficios de reciprocidad	Requiere cuidado en la combinación y distribución
Contribuir aguas arriba	Menos carga de parche privado; influencia; buena voluntad	Esfuerzo continuo; sobrecarga de PI y proceso
Construir propietario en su lugar	Control total; sin obligaciones externas	Alto costo; reinventa la mercancía; lo mantienes para siempre
Publicación por defecto del gobierno	Transparencia; reutilización; evita la dependencia	Esfuerzo de publicación; revisión de seguridad; administración sostenida

La tensión central es entre la velocidad del desarrollador y el control. Bloquea todo detrás de una revisión pesada, y los desarrolladores rodean la política. Eso crea dependencias en la sombra sin gestionar, que son peores que un enfoque permisivo pero visible. Déjalo completamente sin control, y acumulas deuda legal y de seguridad invisiblemente. La resolución es la automatización y la curación: haz del camino conforme el camino más rápido, a través de componentes preverificados, escaneo de canal, y valores predeterminados claros, para que obtengas control sin fricción. Sobre el copyleft, la contrapartida no es «riesgoso frente a seguro» sino «comprendido frente a no». El copyleft es completamente usable una vez que sabes cómo combinas y distribuyes.

Preguntas para discutir con tu equipo

¿Cuál es tu regla explícita para el copyleft fuerte y de red a través de los contextos interno, distribuido, y servido en red? El copyleft es una restricción de diseño, no un tabú, y las obligaciones giran sobre dos cosas: si distribuyes el software y cuán estrechamente combinas los componentes. GPL en una herramienta interna se comporta muy distinto de GPL enlazada en un producto que envías, y AGPL extiende los deberes de divulgación al software que meramente ofreces a través de una red, lo cual cambia tu cálculo de construir frente a adoptar para cualquier cosa que operes como servicio. Escribe la regla por contexto, para que un desarrollador sepa sin llamar a un abogado que (por ejemplo) lo permisivo está preaprobado en todas partes, el copyleft fuerte está bien internamente pero bloqueado del producto enviado, y AGPL necesita revisión antes de tocar un servicio en red. Trae evidencia: escanea tu árbol de dependencias actual y encuentra dónde ya se sitúan los componentes copyleft en relación con tu frontera de distribución. Luego bloquea la construcción por esa política, porque una regla que ningún escáner aplica es una regla que los desarrolladores romperán accidentalmente.
¿Necesitas una Oficina de Programa de Código Abierto, y quién posee hoy la política de licencia, el escaneo, y las decisiones de contribución? Si la respuesta honesta es «nadie» o «cada equipo decide», estás operando un todos-contra-todos que acumula deuda legal y de seguridad invisiblemente. Una OSPO, incluso una persona más un grupo de trabajo multifuncional, frena ese caos y captura valor estratégico: en qué proyectos aguas arriba invertir, cuándo contribuir, y cómo liberar bien tus propios proyectos. Trae evidencia a la reunión: ¿puede alguien producir la lista de licencias aprobadas actual, la SBOM, y el nombre de la persona que atendería una pregunta de copyleft durante la diligencia debida de adquisición? La respuesta debería asignar propiedad clara y hacer del camino conforme el camino más rápido, a través de componentes preverificados y escaneo de canal, para que los desarrolladores obtengan control sin fricción. Una política más lenta que copiar código simplemente se ignorará.
¿Qué dependencias dolerían más si se abandonaran mañana, y cuál es tu respuesta predecidida para cada una? Cada dependencia eventualmente llega al fin de vida, y la versión costosa de ese evento es descubrir que un componente central perdió el soporte hace meses, solo cuando una vulnerabilidad fuerza la atención. Para tus componentes críticos en riesgo de abandono, decide de antemano si financiarás al mantenedor, contribuirás mantenimiento tú mismo, bifurcarás, o reemplazarás. Trae evidencia: de tu SBOM, enumera los componentes cuyo fallo detendría un servicio crítico de ingresos o misión, y anota el estado de mantenimiento y la ventana de soporte de seguridad de cada uno. La respuesta debería convertir el fin de vida de una sorpresa en un riesgo operacional rastreado con una migración planificada, sostenido al mismo estándar que cualquier otro riesgo. Mantener las dependencias actuales en pasos pequeños y frecuentes es mucho más barato que el salto raro, gigante, y forzado.
¿Puedes producir una SBOM completa y actual que alcance hasta el fondo de tu árbol de dependencias transitivas, y con qué rapidez? Cuando una vulnerabilidad destacada aterriza en una biblioteca ampliamente usada, la primera pregunta que hace el liderazgo es «¿estamos expuestos, y dónde?». Un equipo que no puede responder en horas ya está atrasado, porque el riesgo real usualmente se esconde varias capas profundo en dependencias que nadie eligió a propósito. La consideración en competencia es el costo y el ruido: el inventario transitivo completo a través de muchos servicios genera una lista grande y cambiante, y la sobrealerta entrena a la gente a ignorarla, así que tienes que decidir qué profundidad y qué severidad realmente disparan la acción. Trae evidencia a la discusión: intenta generar una SBOM fresca para un servicio de producción ahora mismo, cuenta cuántos componentes son directos frente a transitivos, y cronometra cuánto tardó. Para un organismo empresarial o gubernamental, vincula esto a un objetivo concreto de respuesta a incidentes y a cualquier deber regulatorio de divulgar los componentes afectados, porque un mandato de reportar la exposición que no puedes enumerar es un mandato que incumplirás.
¿Cuándo vale la pena financiar, contribuir a, o administrar una dependencia crítica, en lugar de tratarla como gratis? La mayoría de las organizaciones consumen código abierto como si fuera un servicio público, luego se sorprenden cuando un componente que sustenta un servicio de ingresos resulta ser un único voluntario no pagado. Decidir deliberadamente financiar a un mantenedor, enviar correcciones aguas arriba, o liberar y administrar tu propio proyecto convierte una entrada gratuita frágil en una duradera e influenciada, y detiene a tus ingenieros de cargar parches privados a través de cada actualización. La tensión es que la contribución y la administración cuestan tiempo de ingeniería real y continuo y llevan sobrecarga de propiedad intelectual y proceso, así que no puedes hacerlo para todo. Trae evidencia: de tu SBOM, marca el puñado de componentes cuyo fallo detendría un servicio crítico de misión, y anota el conteo de mantenedores, la financiación, y cuántos parches privados ya cargas contra él. Para una organización grande o pública, pesa el costo reputacional de una liberación de código abierto abandonada que publicaste con fanfarria, y, en el gobierno, trata la administración sostenida del código de dinero público publicado como parte de la entrega, no un extra opcional.
¿Tu contratación pública realmente entrega código abierto, reutilizable, y bien documentado con los derechos que necesitas, o cajas negras propietarias que no puedes mantener ni salir de ellas? Los contratos escritos sin experiencia en código abierto rutinariamente entregan a un proveedor un control que lamentarás: formatos cerrados, sin derecho a publicar o modificar, y dependencias que la agencia no puede parchear cuando el proveedor sigue adelante. Acertar en esto temprano es mucho más barato que descubrir en la renovación que no puedes irte. Las consideraciones en competencia son la velocidad y la elección de proveedor: exigir entregables abiertos y portabilidad puede estrechar el campo y ralentizar una adjudicación, y algunos proveedores genuinamente útiles se resisten. Trae evidencia: extrae dos contratos recientes y comprueba si especifican los términos de licencia, la entrega de código fuente, los estándares de documentación, la provisión de SBOM, y los derechos que retiene la organización. Para la contratación pública empresarial, conecta esto con el análisis de dependencia y costo total; para el gobierno, conéctalo con los mandatos de abierto por defecto y «dinero público, código público», y con el proceso de exención documentado que te permite cerrar solo las partes sensibles a la seguridad en lugar de todo el sistema.

Perspectiva sectorial

Startup. Ensamblas casi todo a partir de código abierto y no tienes un abogado, así que mantén la regla en una página: las licencias permisivas como MIT y Apache 2.0 están preaprobadas, el copyleft fuerte está bien para las herramientas internas pero bloqueado del producto enviado, y cualquier cosa extraña obtiene una revisión rápida del fundador. Añade un escaneo de licencia y vulnerabilidad al canal y mantén una SBOM desde el primer día, porque el momento más barato para acertar en esto es antes de que la diligencia debida de un adquirente peine tu árbol de dependencias. No prohíbas el copyleft por miedo; compréndelo, y sigue adelante.

Pequeña empresa. Sin un especialista de código abierto y con un presupuesto ajustado, apóyate en herramientas en lugar de personal: un escáner en la construcción y una lista corta de licencias aprobadas hacen la mayor parte del trabajo que haría una persona. Enmarca el consumo como comprar frente a construir honestamente, ya que reinventar un componente abierto bien mantenido usualmente es la elección costosa, pero también lo es depender de uno que nunca inventarías. Mantén un registro simple de lo que usas y bajo qué licencia, para que un cuestionario de seguridad de cliente o una alerta de vulnerabilidad no se convierta en una carrera.

Empresa. A escala el problema es la consistencia entre muchos equipos, así que levanta una OSPO para poseer la política, el escaneo automatizado, la generación de atribución, y la gobernanza de contribución, y haz del camino conforme el camino más rápido a través de componentes curados y preverificados. Aplica las reglas de copyleft por contexto en el canal, mantén las SBOM a través de servicios, y gestiona la actualidad de dependencias y el fin de vida como riesgo operacional rastreado. Trata el código abierto como gestión de cadena de suministro para la mayoría de tu base de código, con evidencia lista para auditoría para la diligencia debida de adquisición.

Gobierno. La apertura a menudo se mandata, no es opcional, así que por defecto ve a los estándares abiertos y publica el código de dinero público a menos que se aplique una exención documentada por seguridad, derechos de terceros, o privacidad. Reutiliza antes de construir comprobando un catálogo de todo el gobierno, e incorpora entregables abiertos, reutilizables, bien documentados, y derechos retenidos en la contratación pública para que recibas código mantenible en lugar de cajas negras propietarias. Mantén el código publicado a una administración real, y mantén el proceso de exención estrecho y transparente para que cierre solo lo que debe.

Ejemplos

Startup. Una startup de cuatro personas que construye una aplicación móvil ensambla casi todo a partir de código abierto y no tiene un abogado en el personal. En lugar de prohibir el copyleft por miedo, los fundadores escriben una política de una página: las licencias permisivas como MIT y Apache 2.0 están preaprobadas, el copyleft fuerte como GPL está bien para las herramientas internas pero bloqueado de la aplicación enviada para evitar los deberes de divulgación, y cualquier cosa inusual obtiene una revisión rápida del fundador. Añaden un escaneo de licencia y vulnerabilidad al canal para que una licencia prohibida no pueda colarse en un lanzamiento, mantienen una SBOM desde el primer día, y envían aguas arriba una pequeña corrección a una biblioteca crítica para dejar de cargar un parche privado a través de cada actualización. Acertar en esto temprano también les ahorra una sorpresa dolorosa cuando la diligencia debida de un adquirente eventualmente peina el árbol de dependencias.

Empresa. Un proveedor de software que envía un producto distribuido opera una OSPO. La OSPO mantiene una lista de licencias aprobadas, un repositorio interno curado de componentes, y escaneo automatizado de licencia y vulnerabilidad en cada canal. Cuando un desarrollador trae una nueva dependencia, el canal comprueba su licencia contra la política, genera los avisos de atribución que se envían con el producto, y señala cualquier cosa que requiera revisión. Los componentes de copyleft fuerte se permiten para las herramientas internas pero se bloquean del producto distribuido, para evitar las obligaciones de divulgación. La empresa envía correcciones aguas arriba a unas pocas dependencias críticas. Eso eliminó un atraso de parches privados que sus ingenieros solían cargar a través de cada actualización.

Gobierno. Un servicio digital nacional opera bajo una política de «dinero público, código público». Los nuevos servicios se construyen sobre estándares abiertos, se desarrollan abiertamente en un repositorio de código público por defecto, y se reutilizan a través de agencias. Sus plantillas de contratación pública exigen que los proveedores entreguen código abierto, bien documentado, y reutilizable, con el gobierno manteniendo los derechos de publicar y modificar. Antes de empezar un nuevo componente, los equipos buscan en un catálogo de todo el gobierno código reutilizable existente. Los módulos sensibles a la seguridad se eximen de la publicación a través de un proceso documentado, en lugar de cerrar todo el sistema.

Caso de negocio: motivaciones, ROI y TCO

Gestionar bien el código abierto es la diferencia entre capturar su enorme apalancamiento y pagar sus costos ocultos. El código abierto permite que una gran organización se pare sobre un fundamento que nunca podría costear construir. Pero el costo total de propiedad incluye el cumplimiento, el parcheo de seguridad, y la migración eventual, costos que llegan planifiques o no para ellos. La gestión deliberada convierte crisis impredecibles y costosas en costos pequeños, constantes, y planificados. Esas crisis incluyen una violación de copyleft encontrada durante la diligencia debida de adquisición, una migración de emergencia fuera de un componente abandonado, o una vulnerabilidad en una dependencia que nadie sabía que estaba ahí.

El costo de adopción es modesto frente a la exposición: una OSPO o grupo de trabajo, herramientas de escaneo, y la disciplina de mantener un inventario. El costo de no adoptar aparece como responsabilidad legal, diligencia debida fallida, incidentes de seguridad rastreados a dependencias sin parchear, y el gasto compuesto de las actualizaciones diferidas que eventualmente fuerzan migraciones dolorosas de gran explosión. Cuando presentes el caso al liderazgo, enmarca la gestión de código abierto como gestión de cadena de suministro para la mayoría de tu base de código. Nota también el potencial estratégico: dependencia evitada, entrega más rápida, atracción de talento, e influencia sobre los ecosistemas de los que dependes. En el gobierno, añade la dimensión del mandato. La apertura a menudo se requiere, no es opcional, y hacerlo bien evita tanto el incumplimiento como el gasto público duplicado.

Antipatrones y trampas

Licenciamiento de copiar y pegar. Desarrolladores trayendo componentes sin comprobación de licencia, descubriendo las obligaciones solo en la auditoría o adquisición.
Sin inventario. No poder responder «¿qué estamos usando y bajo qué licencia?» cuando se rompe una vulnerabilidad o pregunta de licencia.
Pánico de copyleft. Prohibir todo el copyleft por miedo en lugar de comprensión, renunciando a ecosistemas valiosos.
La liberación de código abierto abandonada. Publicar un proyecto con fanfarria y luego nunca mantenerlo, dañando la reputación.
Ignorar las dependencias transitivas. Verificar las dependencias directas mientras el riesgo real se esconde varias capas profundo.
Sorpresa de fin de vida. Descubrir que un componente central perdió el soporte hace meses, solo cuando una vulnerabilidad fuerza la atención.
Política más lenta que copiar. Un proceso de cumplimiento tan pesado que los desarrolladores lo rodean, creando dependencias en la sombra invisibles.
Cajas negras gubernamentales. Contratar sistemas propietarios que la agencia no puede mantener, compartir, o salir de ellos, en violación de los principios de abierto por defecto.

Modelo de madurez

Nivel 1: Iniciar. Los desarrolladores añaden código abierto libremente sin política ni inventario. Las licencias no se examinan y las obligaciones de copyleft son desconocidas. El fin de vida se descubre por accidente, usualmente cuando una vulnerabilidad fuerza la atención. Nadie posee la estrategia de código abierto.

Nivel 2: Desarrollar. Existe una política básica y una lista de licencias aprobadas, y algunos equipos las siguen. El escaneo ocurre, pero a menudo manualmente, tarde, o solo en unos pocos proyectos. Se mantiene un inventario para los sistemas principales mientras las dependencias transitivas quedan sin mapear. El manejo de la contribución y el fin de vida es ad hoc e inconsistente entre equipos.

Nivel 3: Estandarizar. Una OSPO o equivalente posee la estrategia, la política, y las herramientas en toda la organización. El escaneo de licencia y vulnerabilidad se automatiza en cada canal, los archivos de atribución y aviso se generan automáticamente, y la construcción se bloquea para que una licencia prohibida no pueda entrar. Las SBOM se mantienen hasta el árbol transitivo, la contribución sigue un proceso documentado, el fin de vida se rastrea con migraciones planificadas, y los equipos gubernamentales publican por defecto.

Nivel 4: Gestionar. El programa se mide y controla contra líneas base. Rastreas la cobertura de escaneo de política entre servicios, el tiempo medio para parchear una vulnerabilidad de dependencia divulgada, el porcentaje de componentes dentro de su ventana de soporte de seguridad, la tasa de escape de violación de licencia, el retraso de actualidad de dependencia, y el conteo de parches privados cargados aguas arriba. La colocación del copyleft en relación con la frontera de distribución se monitorea, y las métricas contra objetivos impulsan cada decisión de continuar o no en lugar de la opinión.

Nivel 5: Orquestar. El código abierto es un activo estratégico continuamente mejorado e integrado en toda la organización. El cumplimiento está completamente automatizado y los componentes no conformes no pueden llegar a producción. Inviertes deliberadamente en proyectos aguas arriba críticos, contribuyes rutinariamente, y administras tus propios proyectos bien operados. La actualidad de dependencias y el fin de vida se gestionan adaptativamente a medida que cambian el riesgo y las métricas, y la apertura se convierte en una ventaja competitiva y cívica genuina.

Ideas para el debate

¿Dónde está la línea correcta entre un valor predeterminado permisivo rápido y el control necesario para evitar la deuda legal y de seguridad?
¿Cuándo debería una organización financiar o mantener una dependencia aguas arriba crítica en lugar de tratarla como gratis?
¿Cómo decides cuáles de tus propios componentes vale la pena liberar y administrar como código abierto?
Para el gobierno, ¿cuál es un proceso defendible para eximir componentes de la publicación por defecto sin erosionar el principio?
¿Cuán profundo en las dependencias transitivas debe realmente llegar la revisión de licencia y seguridad?
¿Cambia el copyleft de red (AGPL) tu cálculo de construir frente a adoptar para el software que ofreces como servicio?

Puntos clave

El código abierto es la mayoría de la mayoría de las bases de código y debe gestionarse como una cadena de suministro, no tratarse como gratis y sin consecuencias.
Las licencias llevan obligaciones reales; comprende las familias permisiva, copyleft débil, copyleft fuerte, y copyleft de red y cómo la distribución y combinación disparan deberes.
Haz del camino conforme el camino más rápido a través de la curación, el escaneo automatizado, y los valores predeterminados claros, o los desarrolladores rodearán la política.
Levanta una OSPO para poseer la estrategia, el cumplimiento, la contribución, y la administración a escala.
Mantén una SBOM, mantén las dependencias actuales en pasos pequeños, y planifica para el fin de vida antes de que fuerce una crisis.
En el gobierno, por defecto ve a los estándares abiertos y publica el código de dinero público, reutilizando antes de construir.

Referencias y lecturas adicionales

Heather Meeker, Open (Source) for Business y Open Source for Business
Van Lindberg, Intellectual Property and Open Source
The Linux Foundation y TODO Group, OSPO guides y Open Source Program Office resources
OpenChain (ISO/IEC 5230), Open Source License Compliance
Especificación Software Package Data Exchange (SPDX, ISO/IEC 5962)
Especificación CycloneDX SBOM
Free Software Foundation, GNU General Public License y GPL FAQ
Open Source Initiative, The Open Source Definition y lista de licencias aprobadas
Free Software Foundation Europe, Public Money, Public Code
U.S. Federal Source Code Policy y guía de Code.gov
UK Government, Technology Code of Practice y principios de estándares abiertos