Detecting and Fixing Violations of Modification Terms in Open Source Licenses during Forking

Resumen Técnico: Detección y Corrección de Violaciones de los Términos de Modificación en Licencias de Código Abierto durante el Forking

Planteamiento del Problema
El desarrollo de software de código abierto (OSS) depende en gran medida del forking, donde los desarrolladores copian un repositorio base para crear una nueva versión modificada de forma independiente. Si bien esto fomenta la innovación, introduce riesgos legales significativos cuando los desarrolladores no cumplen con las obligaciones de la licencia. La investigación existente se ha centrado en identificar licencias, detectar incompatibilidades entre dependencias y encontrar inconsistencias en la concesión de licencias de archivos. Sin embargo, existe una brecha crítica con respecto a los Términos de Modificación (MT, por sus siglas en inglés). Los MT son cláusulas específicas en las licencias de OSS que dictan las condiciones bajo las cuales los usuarios pueden modificar la obra original y las obligaciones que deben cumplir al hacerlo. Un ejemplo prominente es el requisito en licencias como Apache-2.0 de incluir "avisos destacados" que indiquen que los archivos han sido modificados. Según el conocimiento de los autores, ningún trabajo previo ha caracterizado sistemáticamente estos términos ni ha proporcionado mecanismos automatizados para detectar y corregir violaciones de los MT durante el proceso de forking.

Metodología
Los autores proponen un enfoque de dos fases: un estudio empírico para caracterizar los MT, seguido del desarrollo de una herramienta automatizada llamada LiVo.

1. Caracterización Empírica de los Términos de Modificación
Los autores realizaron un estudio empírico sobre 107 licencias aprobadas por la Open Source Initiative (OSI). Identificaron 47 licencias que declaran explícitamente MT que requieren formas específicas de "aviso" para describir las modificaciones. Para modelar estas obligaciones, los autores analizaron las licencias a través de tres dimensiones:

• Alcance de la Modificación ($S_g$): Los tipos de archivos sujetos a obligaciones de modificación (por ejemplo, código fuente, documentación, archivos de configuración, scripts). Los categorizaron en ocho grupos, señalando que casi la mitad de las licencias (44.7%) se aplican a cualquier tipo de archivo.
• Contenido del Aviso ($C_g$): La información requerida en el aviso. Esto se categorizó en cuatro elementos: Fecha, Autor, Declaración Breve (que indique que los archivos fueron cambiados) y Declaración Informativa (que detalle cómo/por qué). Las licencias se agruparon en seis categorías basadas en estos requisitos.
• Ubicación del Aviso ($L_g$): Dónde debe colocarse el aviso. Esto se categorizó en dos elementos: un documento separado (por ejemplo, CHANGELOG) o cada archivo modificado. Las licencias se agruparon en cuatro categorías.

Basándose en estas dimensiones, los 47 de las licencias fueron modeladas como 2-tuplas $\langle lic, O \rangle$, donde $O$ es una 3-tupla $\langle S_g, C_g, L_g \rangle$ que representa la obligación específica.

2. El Enfoque LiVo
LiVo es una herramienta automatizada diseñada para detectar y corregir violaciones de MT durante el forking. Toma un repositorio base y un repositorio fork como entrada y opera en tres pasos:

• Paso 1: Detección de Modificaciones Obligatorias

  • Mapeo de Archivos: LiVo establece mapeos entre los archivos en los repositorios base y fork para identificar la reutilización. Maneja escenarios donde los archivos son renombrados, movidos o copiados (usando herramientas como JGit y Saga).
  • Detección de Licencia: Utiliza Ninka para detectar la licencia de cada archivo en el repositorio base.
  • Archivos y Commits Obligatorios: Identifica "archivos obligatorios" (aquellos que caen dentro del alcance de modificación de la licencia detectada) y "commits obligatorios" en el repositorio fork que modifican estos archivos. Filtra los commits tomados del repositorio base (que ya son conformes) y los commits revertidos.

• Paso 2: Extracción de Avisos

  • LiVo localiza posibles archivos de aviso en el repositorio fork (por ejemplo, CHANGELOG, RELEASE.txt).
  • Extrae "registros de cambios" (change logs) de estos archivos. La lógica de extracción maneja texto semiestructurado, identificando bloques de cambios asociados con rangos de fechas y autores específicos.
  • Cada registro de cambio extraído se modela como una tupla $\langle msg, d_s, d_e, a \rangle$ (mensaje, fecha de inicio, fecha de fin, autor).

• Paso 3: Detección y Corrección de Violaciones

  • Coincidencia: Para cada commit obligatorio, LiVo intenta emparejarlo con un registro de cambios en el conjunto extraído.
  • Verificación de Similitud: Utiliza TF-IDF para medir la similitud semántica entre el mensaje del commit y el mensaje del registro de cambios. Si la similitud supera un umbral (establecido empíricamente en 0.3), el requisito de contenido se considera cumplido.
  • Verificación de Atributos: Verifica si la fecha del commit cae dentro del rango de fechas del registro de cambios y si el autor del commit coincide con el autor del registro de cambios.
  • Clasificación: Los commits se clasifican como:
    • OB (Totalmente Obligado): Todos los requisitos se cumplen.
    • VN (Violado - Falta de Aviso): No se encontró un registro de cambios coincidente.
    • VD (Violado - Falta de Fecha): Desajuste en el rango de fechas.
    • VA (Violado - Falta de Autor): Desajuste de autor.
  • Corrección: Para las violaciones, LiVo genera una corrección creando o actualizando una entrada en el registro de cambios con el mensaje, la fecha y el autor correctos, y lo escribe en el archivo de aviso apropiado.

Resultados Clave
Los autores evaluaron LiVo utilizando 178 pares de repositorios base y fork (seleccionados de proyectos de GitHub con alto número de estrellas).

• Prevalencia: El 21.9% de los repositorios forked analizados requerían MTs en sus licencias.
• Severidad de la Violación: El 51.1% de los repositorios forked violaban los MT. De manera más crítica, el 95.3% de los commits obligatorios (commits que modifican archivos protegidos) presentaban violaciones de los MT. La violación más común fue la falta de aviso (VN), seguida de la falta de fecha (VD).
• Precisión: LiVo logró una precisión macro de 0.82 y una exhaustividad (recall) macro de 0.80 en la detección y clasificación de violaciones. La principal fuente de error fue la falta de conciencia semántica de TF-IDF al emparejar mensajes de commit cortos con registros de cambios.
• Eficiencia: La herramienta promedió 229.8 segundos por par de repositorios, siendo el paso de detección de modificaciones el que representó aproximadamente el 92% del tiempo de ejecución.
• Impacto en el Mundo Real: Los autores enviaron 91 pull requests a los repositorios violados. 18 recibieron respuestas positivas y 8 fueron fusionados (merged) en las ramas principales. Algunos desarrolladores se resistieron inicialmente, alegando que el historial de commits constituye el aviso por sí mismo o afirmando que ellos eran los autores originales, pero la herramienta identificó y propuso correcciones con éxito para la mayoría de los casos.

Significancia y Reivindicaciones
El artículo afirma ser el primer trabajo en:

1. Caracterizar empíricamente los términos de modificación en un gran conjunto de licencias de código abierto.
2. Proponer un enfoque automatizado (LiVo) para detectar y corregir violaciones de estos términos específicos durante el forking.

Los autores enfatizan que, si bien la identificación de licencias y la detección de incompatibilidades son campos maduros, la obligación específica de proporcionar un "aviso" para las modificaciones ha sido pasada por alto. Al abordar esto, LiVo ayuda a mitigar riesgos legales como demandas y pérdidas financieras asociadas con el incumplimiento. El artículo concluye que las violaciones de MT son severas en escenarios del mundo real y que la detección y corrección automatizadas son factibles y efectivas, aunque es necesario mejorar la coincidencia semántica (por ejemplo, usando aprendizaje profundo) para reducir aún más los falsos positivos y negativos.