Cada día los ingenieros de GitHub introducen nuevas dependencias en la plataforma GitHub, aplicaciones internas y proyectos open source. GitHub no solo es el hogar del open source: está impulsado por open source. Y una parte importante de usar open source de forma responsable es respetar las licencias que gobiernan los proyectos de los que uno depende.
En GitHub la empresa se comprometió a cumplir con sus obligaciones hacia la comunidad open source y las dependencias que utiliza. Así usa la nueva feature GitHub License Compliance su Open Source Program Office (OSPO) para administrar miles de dependencias.
¿Cómo se gestiona el cumplimiento de licencias?
Casi todo el software carga algún tipo de acuerdo de licencia. La licencia da permiso para usar un proyecto, siempre que se cumplan sus obligaciones. Esas obligaciones pueden ser tan simples como dar crédito al autor original en la documentación, o pueden requerir distribuir todo el código fuente al publicar el programa. En algunos casos, las licencias también restringen ciertas actividades o categorías de uso.
Cada organización probablemente tiene sus propias políticas sobre licencias aceptables basadas en su modelo de negocio, ecosistema de software y estrategia de distribución. Por ejemplo, una organización que vende una aplicación binaria comercial y de código cerrado probablemente quiera evitar dependencias que la obliguen a abrir su código propietario.
O bien, se puede tener un proyecto que se planea liberar como paquete open source. En ese caso, es preferible evitar dependencias gobernadas por licencias comerciales o open source incompatibles.
Si no se puede cumplir con las obligaciones requeridas en cualquiera de los escenarios, conviene evitar la dependencia para prevenir riesgos legales u operativos. Puede requerir esfuerzo de ingeniería remover esas licencias después del hecho. Para software empresarial, el riesgo comercial de no cumplir es enorme: puede derivar en litigios costosos y daño reputacional.
¿Qué cambia la nueva feature de GHAS?
Tradicionalmente, las revisiones de licencias se hacían manualmente o con software de terceros. Ahora GitHub introdujo una feature de License Compliance para clientes de GitHub Advanced Security, que permite revisar nuevas dependencias directamente en pull requests. Esta revisión ayuda a asegurar que las licencias de esas dependencias cumplan con la política, y también entrega flexibilidad para expandir la política y admitir nuevas licencias o proyectos individuales.
Hace dos meses el OSPO de GitHub migró desde herramientas internas propias hacia la nueva feature. Como early adopters, dieron retroalimentación rápida al equipo de desarrollo y ayudaron a asegurar que la feature superara el listón de empresas grandes y rápidas con requisitos complejos de cumplimiento.
¿Cómo se arranca una política sana?
Como GitHub había construido herramientas internas de license compliance antes de la introducción del producto, tenía una lista existente de licencias aceptables para usar como política inicial. La mayoría de las dependencias suelen usar licencias permisivas comunes como MIT, Apache 2.0 y BSD-3-Clause, un buen punto de partida.
GitHub arrancó la feature usando el modo "Evaluate" sobre un ruleset a nivel organización, que generaba anotaciones en pull requests sin bloquear los merges, para acostumbrar a los desarrolladores al nuevo flujo sin frenar su productividad. Correr en paralelo la herramienta vieja y la nueva permitió ver si su comportamiento divergía. Tras un mes en ese modo, llegaron a un estado donde las alertas se concentraban principalmente en paquetes con licencias inusuales, faltantes o explícitamente prohibidas.
¿Cómo funciona por dentro License Compliance?
Bajo el capó, los chequeos de license compliance se habilitan vía rulesets. Se apunta a los repositorios con una custom property cuyo valor define si los chequeos están activos en modo "Active" o "Evaluate". En los repositorios afectados por un ruleset, los pull requests que modifican dependencias del proyecto disparan un escaneo que busca las licencias de cada nueva dependencia. Si las licencias ya están permitidas o hay excepciones específicas por paquete, los chequeos pasan. Si hay fallas, ya sea en dependencias directas o transitivas, la herramienta comenta el pull request con alertas por cada paquete problemático.
El desarrollador revisa las alertas. Si decide que la dependencia es inaceptable, puede actualizar su código o cerrar el pull request para removerla. Si cree que la licencia o paquete debe permitirse, puede levantar un pedido de excepción que notifica a un equipo específico de la organización, que decide si y cómo enmendar la política.
¿Cómo se opera el equipo de política de licencias?
El equipo de política de licencias de GitHub está formado por miembros del OSPO e ingenieros con expertise en revisiones de licencias y análisis de cadena de suministro. Como es una compañía global, el equipo de revisión tiene miembros en distintas zonas horarias para revisar alertas oportunamente. Está formalizando un SLA de revisión, pero en la práctica rara vez pasan más de un par de horas antes de que se pueda triagear un pedido entrante.
Los miembros reciben notificaciones por email de los nuevos pedidos de revisión y también acceden a un dashboard con el backlog. Al aprobar un pedido hay dos puntos de decisión: primero, si permitir la licencia o el paquete. Luego, decidir el alcance (enterprise o repositorio). Si es una licencia segura que simplemente no había aparecido antes, se agrega a nivel enterprise, permitiendo dependencias con esa licencia en todo GitHub. Algunos paquetes cargan licencias comerciales que no pueden permitirse universalmente pero sí deben permitirse en el repositorio del equipo que pagó el software: esas enmiendas se agregan a nivel de repositorio.
Las excepciones por paquete son útiles para software interno que habitualmente no tiene metadata de licencia asociada. La herramienta soporta wildcards para excepciones de paquete: en GitHub, por ejemplo, permitieron todo el namespace @github-ui/* de React, evitando aprobar esos paquetes uno por uno.
¿Cómo se cuida al desarrollador?
Para apoyar el proceso, GitHub estableció procedimientos claros para contactar al OSPO y una anulación de emergencia tipo "break glass". Estas situaciones deberían ser raras, pero un proceso de override de emergencia claro es esencial para pull requests críticamente urgentes en tiempo. Como el enforcement corre vía ruleset y la condición se activa desde una custom property, cambiar el valor de la propiedad puede apagar temporalmente el enforcement si hay un fix crítico bloqueado por una alerta de licencia. Hasta ahora GitHub solo lo usó una vez, pero fue útil tener la opción.
También hay documentación interna y capacitación para que los desarrolladores entiendan la importancia del cumplimiento. En última instancia, cumplir y gestionar el riesgo es tarea de todos, y el trabajo del OSPO es hacer esa tarea lo más fácil posible.
Conclusión
License compliance es parte crítica de gestionar la cadena de suministro de software. Al ayudar a que los desarrolladores tomen decisiones informadas sobre dependencias alineadas con la política de GitHub, se previenen reescrituras costosas y potenciales problemas legales. Los clientes de GitHub Enterprise Cloud pueden usar License Compliance en repositorios con licencia activa de GHAS Code Security. Más información en la documentación de open source license compliance.
