💻 computer science

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

This paper introduces LiVo, a tool designed to automatically detect and fix violations of modification terms in open source licenses during forking, addressing a previously unexplored gap in legal risk mitigation through empirical characterization of 47 licenses and successful validation via merged pull requests.

Original authors: Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

Published 2026-06-23

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the world of open-source software as a massive, bustling library where anyone can borrow books, read them, and even rewrite chapters to create their own new stories. This is great for creativity, but there's a catch: every book in this library comes with a specific set of rules (a license) written by the original author.

Most people know the big rules, like "You must give credit" or "You must share your new version for free." But there's a sneaky, often overlooked rule hidden in many of these licenses called the Modification Term.

The "Change Log" Rule

Think of the Modification Term as a strict librarian's rule: "If you take a book out of our library, change a few pages, and make a new version, you must write a sticky note explaining exactly what you changed, who changed it, and when."

Some licenses say the sticky note must go on every single page you touched. Others say you can put it in a separate "Changes" notebook at the front of the book. Some just say, "Make sure someone knows you changed it."

The problem? Most developers are so busy writing code that they forget to write these sticky notes. They create a "fork" (a copy of the project they modify) but fail to leave a trail of what they did. This is a legal violation, like returning a library book with torn pages but no note explaining why.

The Problem: The "Silent" Violation

The researchers from Fudan University realized that while we have tools to check if you're using the right book, we have no tools to check if you forgot to write your sticky note. They asked:

What exactly do these rules say?
How often are people breaking them?
Can we build a robot to fix it?

The Solution: Meet "LiVo" (The Library Vigilante)

To solve this, the team built a tool called LiVo. You can think of LiVo as a super-smart, automated librarian who patrols the "forked" libraries.

Here is how LiVo works, step-by-step:

The Detective Work (Finding the Changes): LiVo looks at the original library book and the new, modified version. It scans through every single "commit" (a saved change in the code) to see which files were actually touched. It filters out the boring stuff, like when someone just copied a page from the original without changing it.
The Search (Looking for the Note): Once LiVo knows which files were changed, it goes hunting for the "sticky note." It looks in two places:
- Inside the modified files themselves.
- In a separate "Change Log" file (like a CHANGELOG.md), which is common in software projects.
The Match-Up (Did they get it right?): LiVo compares the "commit message" (what the developer said they did when they saved the change) with the "change log" (the sticky note).
- Did they mention the change?
- Did they include the date?
- Did they include their name?
  If the answer is "No" to any of these, LiVo flags it as a violation.
The Fix (The Auto-Pilot): If LiVo finds a missing note, it doesn't just yell; it tries to fix it. It automatically writes the missing sticky note based on the developer's original commit message and suggests adding it to the project.

What They Found (The Reality Check)

The team tested LiVo on 178 pairs of real-world software projects (a base project and its fork). The results were eye-opening:

It's a Common Mistake: About 51% of the modified projects were breaking these rules. They had changed the code but forgot to write the required notes.
The Scale: They found over 51,000 specific instances where developers forgot to document their changes.
The Source Code is the Culprit: Most of the missing notes were for changes made to the actual "source code" (the instructions that run the program), rather than documentation or scripts.

Did It Work?

LiVo isn't just a theory; they put it to the test in the real world.

They sent 91 "Pull Requests" (official suggestions to fix the code) to the project owners.
18 developers responded positively, saying, "Oh, you're right! We forgot that."
8 of those fixes were actually merged into the main code, meaning the legal risk was officially resolved.

The Bottom Line

This paper is the first to say, "Hey, we need to stop ignoring the rule about writing notes when you change open-source code." They mapped out exactly what these rules look like across 47 different licenses and built a tool, LiVo, that acts like a helpful librarian, finding the missing notes and writing them for you.

It's not about stopping people from changing code; it's about making sure the "paper trail" exists so everyone knows who changed what, keeping the legal library safe and organized.

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

Problem Statement
Open source software (OSS) development relies heavily on forking, where developers copy a base repository to create a new, independently modified version. While this fosters innovation, it introduces significant legal risks when developers fail to comply with license obligations. Existing research has focused on identifying licenses, detecting incompatibilities between dependencies, and finding inconsistencies in file licensing. However, a critical gap remains regarding Modification Terms (MTs). MTs are specific clauses in OSS licenses that dictate the conditions under which users may modify the original work and the obligations they must fulfill upon doing so. A prominent example is the requirement in licenses like Apache-2.0 to include "prominent notices" stating that files have been changed. To the authors' knowledge, no prior work has systematically characterized these terms or provided automated mechanisms to detect and fix violations of MTs during the forking process.

Methodology
The authors propose a two-phase approach: an empirical study to characterize MTs, followed by the development of an automated tool named LiVo.

1. Empirical Characterization of Modification Terms
The authors conducted an empirical study on 107 licenses approved by the Open Source Initiative (OSI). They identified 47 licenses that explicitly declare MTs requiring specific forms of "notice" to describe modifications. To model these obligations, the authors analyzed the licenses across three dimensions:

Modification Scope ( $S_g$ ): The types of files subject to modification obligations (e.g., source code, documentation, configuration files, scripts). They categorized these into eight groups, noting that nearly half of the licenses (44.7%) apply to any file type.
Notice Content ( $C_g$ ): The required information in the notice. This was categorized into four elements: Date, Author, Brief Statement (stating files were changed), and Informative Statement (detailing how/why). Licenses were grouped into six categories based on these requirements.
Notice Location ( $L_g$ ): Where the notice must be placed. This was categorized into two elements: a separate document (e.g., CHANGELOG) or each modified file. Licenses were grouped into four categories.

Based on these dimensions, the 47 licenses were modeled as 2-tuples $\langle lic, O \rangle$ , where $O$ is a 3-tuple $\langle S_g, C_g, L_g \rangle$ representing the specific obligation.

2. The LiVo Approach
LiVo is an automated tool designed to detect and fix MT violations during forking. It takes a base repository and a fork repository as input and operates in three steps:

Step 1: Obligating Modification Detection
- File Mapping: LiVo establishes mappings between files in the base and fork repositories to identify reuse. It handles scenarios where files are renamed, moved, or copied (using tools like JGit and Saga).
- License Detection: It uses Ninka to detect the license of each file in the base repository.
- Obligating Files & Commits: It identifies "obligating files" (those falling within the modification scope of the detected license) and "obligating commits" in the fork repository that modify these files. It filters out commits picked from the base repository (which are already compliant) and reverted commits.
Step 2: Notice Extraction
- LiVo locates potential notice files in the fork repository (e.g., CHANGELOG, RELEASE.txt).
- It extracts "change logs" from these files. The extraction logic handles semi-structured text, identifying blocks of changes associated with specific date ranges and authors.
- Each extracted change log is modeled as a tuple $\langle msg, d_s, d_e, a \rangle$ (message, start date, end date, author).
Step 3: Violation Detection and Fixing
- Matching: For each obligating commit, LiVo attempts to match it with a change log in the extracted set.
- Similarity Check: It uses TF-IDF to measure the semantic similarity between the commit message and the change log message. If the similarity exceeds a threshold (empirically set to 0.3), the content requirement is considered met.
- Attribute Verification: It verifies if the commit date falls within the change log's date range and if the commit author matches the change log's author.
- Classification: Commits are classified as:
  - OB (Fully Obligated): All requirements met.
  - VN (Violated - Missing Notice): No matching change log found.
  - VD (Violated - Missing Date): Date range mismatch.
  - VA (Violated - Missing Author): Author mismatch.
- Fixing: For violations, LiVo generates a fix by creating or updating a change log entry with the correct message, date, and author, and writes it to the appropriate notice file.

Key Results
The authors evaluated LiVo using 178 pairs of base and fork repositories (selected from highly-starred GitHub projects).

Prevalence: 21.9% of the analyzed forked repositories required MTs in their licenses.
Violation Severity: 51.1% of the forked repositories violated MTs. More critically, 95.3% of the obligating commits (commits modifying protected files) were found to violate MTs. The most common violation was missing notice (VN), followed by missing date (VD).
Accuracy: LiVo achieved a macro-precision of 0.82 and a macro-recall of 0.80 in detecting and classifying violations. The primary source of error was the semantic unawareness of TF-IDF when matching short commit messages to change logs.
Efficiency: The tool averaged 229.8 seconds per repository pair, with the modification detection step accounting for ~92% of the runtime.
Real-world Impact: The authors submitted 91 pull requests to the violated repositories. 18 received positive responses, and 8 were merged into the main branches. Some developers initially resisted, citing that commit history itself constituted notice or claiming they were original authors, but the tool successfully identified and proposed fixes for the majority of cases.

Significance and Claims
The paper claims to be the first work to:

Empirically characterize modification terms across a large set of open source licenses.
Propose an automated approach (LiVo) to detect and fix violations of these specific terms during forking.

The authors emphasize that while license identification and incompatibility detection are mature fields, the specific obligation to provide "notice" for modifications has been overlooked. By addressing this, LiVo helps mitigate legal risks such as lawsuits and financial losses associated with non-compliance. The paper concludes that MT violations are severe in real-world scenarios and that automated detection and fixing are feasible and effective, though improvements in semantic matching (e.g., using deep learning) are needed to further reduce false positives and negatives.