I merged my 1,204th pull request last month on a small CLI tool called csvgrep. Number 1,204 was a license fix. The contributor had pasted a regex function from a Stack Overflow answer into a GPL-3.0 file. It took me forty minutes to trace it back to the original post, read the poster's profile, and confirm there was no license grant. Two hundred thirty-eight similar tickets before that taught me the same lesson over and over: open source license compliance is not a checkbox; it's a permanent code review habit.
I teach coding at a bootcamp and maintain three open-source projects. The same failure mode shows up in both places. Someone finds a snippet that solves their problem, drops it into a project, and never checks the license. The compiler doesn't care. The tests pass. But the legal exposure is real, and it's almost never caught by CI.
Open Source License Compliance Is About Obligations, Not Goodwill
Most developers think a license is just a badge. MIT means permissive, GPL means reciprocal, Apache means something about patents. But each license comes with precise obligations.
MIT requires the copyright notice and permission notice to be included in all copies or substantial portions of the software. That's it, but it's still a requirement. You can't strip it.
Apache 2.0 adds a NOTICE file requirement, patent grant language, and state changes if you modify files. BSD requires the copyright notice and conditions list. GPL requires you to provide source code when you distribute, and it applies copyleft to the whole combined work.
The failure modes are all variations on the same mistake: someone copies a function from a project with License A into a project with License B, and neither license is satisfied.
What a License Violation Actually Looks Like in a Pull Request
Here's a concrete example from ticket #187. A contributor added this to a repo of mine that was LGPL-3.0:
// Extracted from a Stack Overflow answer by user bradleyDotNet, 2016.
function debounce(func, wait) {
let timeout;
return function executedFunction(...args) {
const later = () => {
clearTimeout(timeout);
func(...args);
};
clearTimeout(timeout);
timeout = setTimeout(later, wait);
};
}
The code itself was fine. The problem was the provenance. The original answer had no license statement, and by default Stack Overflow content is licensed under CC BY-SA 4.0 as of 2019, but this answer was from 2016, under CC BY-SA 3.0. CC BY-SA has share-alike and attribution requirements that the LGPL project did not meet by simple inclusion. We had to rewrite the debounce from scratch to be safe.
That's the type of silent violation that GitHub's dependency scanner will never flag because it only looks at declared dependencies in package files, not at code pasted into a source file.
I eventually started running copied code through Codequiry's plagiarism checker for code when I suspected a snippet came from the web. It compares submissions against GitHub, Stack Overflow, and other public sources and shows me exactly where the match originated. That caught three more violations in the next month alone.
Why License Scanners Miss Pasted Code
Most teams use a scanner like FOSSA, Snyk, or License Finder to detect open-source license violations. Those tools are excellent at one thing: they read your package manifests, lockfiles, and bill of materials, then compare the declared dependency graph against a database of known licenses. If you add a package with a conflicting license, the scanner flags it. That's the 80% case.
But the other 20% is where I've spent two hundred thirty-eight tickets. That's the code you copied from a blog post, a GitHub issue comment, a Stack Overflow answer, or an internal snippet from another project. There is no manifest entry. There is no package name. There is just a function pasted into a file, often with comments stripped and variable names changed just enough to hide the source.
Dependency scanners won't see that. They model the world as packages and versions, but real-world code reuse is messier. A student might paste a sorting algorithm from GeeksforGeeks into a Java assignment. A junior dev might lift a date-parsing function from a public utility repo into a proprietary service. A contractor might bring in code from a previous client's project. None of those show up in package.json or pom.xml.
That's why I pair my dependency scanner with a source similarity check. Codequiry's engine does token-based comparison, AST analysis, and fingerprinting, which means it catches copied code even after variables are renamed, formatting changes, and logic is reordered. It's not perfect for every language, but for the four I teach (JavaScript, Python, Java, and C++), it catches the overwhelming majority of manual copies.
A Practical Workflow for Detecting License Violations in Code Review
Here's the exact workflow I use now when reviewing pull requests or grading assignments, both for open-source projects and bootcamp take-homes.
First, I run the standard dependency scanner on the PR. If it's a repo with a manifest, that catches 80% of issues. Snyk, FOSSA, or GitHub's built-in dependency review all work. I don't care which one as long as it's in CI.
Second, I look at any new source file or function longer than about ten lines that the contributor didn't clearly write from scratch. I check for comments that reference external sources, variable naming conventions that don't match the rest of the file, or just a certain "pasted" texture. You know it when you see it after a few hundred reviews.
Third, for suspicious code, I run it through a code plagiarism checker. If the contributor copied from the web, Codequiry returns the matching source URL, the percentage of overlapping tokens, and a side-by-side diff. That evidence is usually enough to have a conversation with the contributor without accusing anyone of anything.
Fourth, if the source is found and the license is incompatible, I open a license violation ticket. The fix is either rewrite the function, get permission from the original author, or add proper attribution according to the source license. I've never had to escalate beyond a ticket because the evidence is usually unambiguous.
Here's a small Python helper I wrote to automate the suspicious-code detection part. It's not a license scanner, but it flags functions with unusually high token similarity to files in the same repo, which often indicates a paste from outside.
import difflib
from pathlib import Path
def find_likely_pastes(repo_path, threshold=0.85):
files = list(Path(repo_path).rglob('*.py'))
flags = []
for f in files:
text = f.read_text()
lines = text.splitlines()
for i in range(len(lines) - 5):
chunk = '\n'.join(lines[i:i+6])
for other in files:
if other == f:
continue
ratio = difflib.SequenceMatcher(None, chunk, other.read_text()).ratio()
if ratio > threshold:
flags.append((str(f), str(other), i, ratio))
return flags
It's a blunt instrument. It only catches near-identical code within a repo, which is not the external source check I need. But it's a quick first pass that flags files worth a closer look. The external check still requires Codequiry or a similar tool because my script has no knowledge of the open web.
The Misconceptions That Cause Most License Violations
After logging 238 tickets, I can group the root causes into a handful of persistent misconceptions. Most contributors aren't malicious; they just don't understand how licensing works with copied code.
The most common assumption I hear is "It's on GitHub, so I can use it." Being public on GitHub means you can read the code, not that you have a license to copy it into your own project. If there's no license file, the default is all rights reserved.
Here's the short list of misconceptions I correct over and over:
- "MIT code can be relicensed under anything." MIT is permissive but you still must include the original copyright notice and permission notice. You can't just delete the header and call it yours.
- "A snippet under 20 lines doesn't need a license check." There is no line-count safe harbor. Courts look at substance, not line count. A 10-line regex can be the creative core of a function.
- "If I change the variable names, it's not the same code." Refactoring doesn't erase the original authorship. Similarity detection tools catch this easily.
- "Stack Overflow answers are public domain." They're not. They're licensed under CC BY-SA, which requires attribution and share-alike in many cases.
- "My company's legal team will catch it." In my experience, most legal teams don't review source provenance; they review contracts and policy. The responsibility is on the engineer.
Each of these beliefs shows up in a real ticket. The variable-renaming one is the hardest because the contributor often genuinely believes they wrote new code. I've learned to present the diff without judgment: "Here's the original source, here's your version, the changes are cosmetic but the provenance is still there."
What the 238 Tickets Actually Taught Me
If I had to reduce two hundred thirty-eight license violations to a single pattern, it's this: reuse is normal, but provenance tracking is rare. Developers copy code. Students copy code. Contractors copy code. The problem is not the copying; it's the complete absence of any record of where the code came from and under what terms.
That's why I now teach license hygiene as part of every bootcamp module. Before we write a single line, we talk about where snippets come from, how to read a license, and what to do when you don't know the source. The result is that my students now ask "what's the license?" before pasting anything from the web, and they understand why I run their submissions through a detect code plagiarism tool that checks the open web.
For my open-source maintainer work, the same habit applies. I don't merge a pull request unless I understand the provenance of every non-trivial function. That adds maybe ten minutes to a review, but it prevents hours of cleanup and potential legal exposure later.
If you're a CS professor, TA, or engineering manager staring at a pile of code you suspect was copied, you don't need to build your own scanner or manually Google every function. Start with a good dependency scanner for packages, then add a source-level code plagiarism checker that compares against the web, GitHub, and peer submissions. The combination covers both the 80% package case and the 20% manual copy case.
One more thing. A long time ago I believed license compliance was a legal task, not an engineering one. That was ticket #12, and it was the first time I had to ask a contributor to rewrite a function because they'd pasted GPL code into an MIT project. It was uncomfortable. But the alternative is worse: you either ship code you don't have the rights to, or you quietly hope nobody notices. Neither is a maintainable position.
Your code review checklist already covers logic, performance, and style. Add license provenance to it. The 30 extra minutes a week is cheap insurance.
When you're ready to automate the provenance check, run your code through Codequiry and see what the web matches look like for your own codebase.