In early 2023, ZephyrCloud—a profitable Series B SaaS company with a container orchestration platform—was in the final stages of being acquired by a Fortune 500 infrastructure vendor. The deal, valued at $480 million, hit a single roadblock during due diligence: the acquirer’s legal team demanded a complete open-source license audit of the codebase. Any GPL- or AGPL-licensed code woven into the proprietary product could force the entire stack to be released under a copyleft license, effectively destroying its commercial value. The engineering team had two weeks to prove the codebase was clean.
What followed was a forensic investigation that moved from desperate greps to a full code similarity scan, revealing how even seasoned developers can lose track of license boundaries—and how automated detection changes the compliance game entirely.
The Acquisition That Triggered a License Audit
ZephyrCloud’s platform consisted of roughly 870,000 lines of Go, TypeScript, and Python, built over six years by a team of 40 engineers. The CTO, Maria Okonkwo, had always enforced a policy of reviewing third-party dependencies with go-licenses and pip-licenses, but the acquirer’s concern went deeper than dependency manifests. They worried about copy-paste incorporation: code snippets from Stack Overflow answers, GPL-licensed reference implementations, or public repositories that were pasted directly into proprietary modules without attribution or license consideration.
“We had a solid dependency policy,” Okonkwo recalled. “But dependency scanning only tells you what packages you’re pulling in. It doesn’t catch that one time someone pasted 30 lines from a GPL-licensed GitHub repo into a utility function three years ago. That’s what scared them—and, honestly, what started scaring me.”
The acquirer’s legal team gave ZephyrCloud a 14-day window to produce an audit report listing every instance where source files contained code originating from any open-source project with a copyleft license, particularly GPLv2, GPLv3, and AGPLv3. They weren’t interested in MIT or Apache-licensed snippets—those were manageable. The red flag was copyleft.
First Pass: Manual Grep and the Limits of Regex
ZephyrCloud’s initial approach was what most teams try first: grep the entire repository for comments containing the word “GPL,” “General Public License,” or any standard license boilerplate. They also searched for copyright headers and known function names from prominent GPL projects. The grep returned hundreds of hits, most of which were in vendored dependency directories that were already declared and compliant. Filtering out those false positives—and identifying the handful of real, undocumented inclusions—was painful.
“We spent four days manually reading through results,” said lead engineer David Chen. “We found three or four smoking guns ourselves, like a 60-line Python module for rate limiting that had clearly been lifted from a GPL-licensed Django extension.” But Okonkwo knew grep wasn’t going to catch code that had been refactored just enough to obscure its origin. A variable rename here, a function reorder there, and the raw text would diverge enough that simple search wouldn’t match. They needed something that compared structure, not just text.
Moving to Automated Similarity Scanning
With the clock ticking, Okonkwo reached out to a former colleague who had used code plagiarism detection tools in a university setting. That conversation led them to evaluate a few options: MOSS (Measure of Software Similarity), JPlag, and commercial platforms built for broader web-scale checks. MOSS and JPlag are effective for comparing a known set of student submissions—pairwise similarity—but they aren’t designed to compare an enterprise codebase against the entire open web and GitHub. ZephyrCloud needed to know if any of its source files matched anything out there that carried a copyleft license.
They chose Codequiry’s source code plagiarism checker, which combines token-based matching, abstract syntax tree fingerprinting, and a continuously updated index of public repositories and web sources. “What sold us was the ability to upload our entire repo and get back similarity results against a massive corpus of open-source code, with enough structural comparison to survive renaming and reformatting,” Chen said.
“We didn’t just get text matches. Codequiry flagged code that was functionally identical even when someone had renamed every variable and changed the loop structure. That’s the kind of deep similarity scanning that a license auditor needs.”
The team uploaded a sanitized snapshot of their private repository through Codequiry’s CLI, excluding vendored directories and known third-party packages that were already documented. The scan took roughly 45 minutes for the full codebase. The web dashboard provided a ranked list of similarity matches, each linking to the specific open-source file that triggered the hit, the license associated with that source, and a side-by-side diff.
What the Scan Found: GPL Snippets in the Wild
The similarity report surfaced 17 high-confidence matches that warranted manual review. After filtering out false positives—such as generic boilerplate like JSON serialization that appeared in dozens of projects—the team identified 9 instances of likely copyleft contamination across the codebase. Some examples:
- A 72-line rate-limiting module for gRPC endpoints that was a near-verbatim copy of a GPLv3-licensed library from a small GitHub project. The variable names were changed but the AST fingerprint was nearly identical.
- A set of image resizing functions in the web frontend’s Node.js layer, lifted from a Stack Overflow answer that itself referenced a GPL-licensed Gist. The answer did not include the license text, but the original Gist was clearly marked GPLv2.
- An internal configuration parser that had been “inspired by” a popular GPLv3 configuration parser, with entire control-flow blocks matching exactly when normalized.
The most concerning discovery was a 310-line Python file implementing a bespoke task scheduler. A junior developer had, three years earlier, copied a reference implementation from a GPLv3-licensed framework, then slowly evolved it over multiple commits. The file had been so heavily modified that a text diff against the original would show less than 15% raw string similarity, but the token-based and AST comparison still flagged a 68% structural match, far above the 45% threshold the team set for manual review.
“That one shocked us,” Okonkwo said. “We thought it was original work. The developer had added features, fixed bugs, and changed the interface—but the core loop and state machine were direct lifts. Without a structural similarity scan, we’d never have caught it.”
# Simplified excerpt of the suspicious task scheduler core loop
# Original GPLv3 reference implementation on the left; ZephyrCloud's evolved version on the right
# Original (GPLv3 ref):
tasks = [t for t in queue if t.is_ready()]
for task in sorted(tasks, key=lambda t: t.priority):
task.run()
if task.is_recurring():
task.reschedule()
# ZephyrCloud's version:
def process_ready_entries(job_queue):
ready_jobs = [j for j in job_queue.items() if j.can_execute(now)]
for job in sorted(ready_jobs, key=lambda j: j.get_priority()):
job.execute()
if job.should_repeat():
job.schedule_next()Renamed variables and methods, but the AST structure—a list comprehension filtered by a readiness predicate, sorted by priority, with a conditional reschedule—is unmistakably the same. Codequiry’s fingerprinting matched both versions to the same canonical pattern despite the surface rewrite.
Remediation and Re-architecture
With the audit results in hand, Okonkwo’s team had five days to remediate. The legal counsel advised a conservative approach: remove or rewrite any code that originated from a copyleft source, even if the copying was inadvertent. The team prioritized by impact.
For the rate-limiter and image-resizing functions, they rewrote the modules from scratch, using only known permissively-licensed references or common algorithmic patterns without copy-paste. The configuration parser was replaced with a standard YAML library that was already in the dependency tree under an MIT license. The task scheduler, which had become deeply embedded in the product’s core logic, required a larger engineering effort. Two senior engineers spent three days designing a new implementation that preserved the interface but rebuilt the internals based on a well-known algorithm described in a public-domain paper. The new version passed a clean scan with no matches to any copyleft source.
While the license audit was the main focus, ZephyrCloud also took the opportunity to run Codequiry’s AI code detector across the codebase. “We hadn’t even considered AI-generated contributions because we have tight code review, but we found two pull requests where a contractor had used ChatGPT to generate a significant portion of a module and passed it off as his own work,” Okonkwo said. “That created a whole separate conversation about IP ownership—who holds copyright on code produced by an LLM? But at least we flagged it before close.” The AI detector flagged those two files with a 94% and 97% confidence score, leading to their removal and a stricter contributor agreement.
Lessons for Engineering Teams
After the acquisition closed successfully—ZephyrCloud’s cleanup satisfied the acquirer’s legal team—Okonkwo’s team distilled several practices that now apply across the entire engineering organization:
1. Dependency scanning is not enough. Tools like Snyk, Black Duck, and FOSSA excel at tracking declared dependencies and their licenses, but they won’t catch code that’s been pasted directly into source files. License compliance must include similarity scanning against public repositories.
2. grep doesn’t scale. Manual text search is error-prone and blind to refactored code. Even regex patterns miss variants unless you understand all possible transformations. A token-based or AST-based tool that normalizes the code structure is essential.
3. Structural similarity thresholds matter. For licensing audits, set a conservative threshold—around 40-50% structural match—to flag anything suspicious. False positives are inevitable, but a manual review step quickly filters them out. The cost of missing a copyleft violation far outweighs the time spent reviewing a few dozen hits.
4. Document provenance at the time of contribution. ZephyrCloud now requires developers to include a comment or commit message noting the source of any external code snippet, including Stack Overflow URLs and the license of the original. This creates a paper trail that makes future audits trivial.
5. Run scans periodically, not just before M&A. Okonkwo’s team now runs a Codequiry similarity scan monthly as part of their CI pipeline, integrated via the detect code plagiarism API. The scan compares each commit against the public corpus and flags new high-similarity matches. That way, license contamination never accumulates over years.
“The audit taught us that license compliance isn’t static. Codebases evolve, developers join and leave, and someone will always copy-paste from a ‘helpful’ source. The only way to stay safe is continuous scanning that understands code as structure, not just text.”
Frequently Asked Questions
Can a code similarity tool really distinguish between GPL and MIT-licensed code?
A similarity tool matches your code against a public corpus and reports the license associated with each matched source. It doesn’t interpret the license terms; it tells you where a match was found and what license that source declares. Your legal team must then determine if the match creates a compliance obligation.
What if the matched snippet is too short to be copyrightable?
There’s no universally accepted line count for what constitutes copyright infringement, but common industry practice is to review any structural match over 20–30 lines. If the snippet is purely functional (e.g., a basic loop), it’s often not an issue. If it replicates unique creative structure, even a short block can create risk.
How often should an enterprise scan for open-source license violations?
At minimum, before any funding round, acquisition, or public release. Enterprises that operate with proprietary code under scrutiny—such as those in highly regulated industries—often integrate a code plagiarism checker into their CI/CD pipeline to catch issues continuously.
ZephyrCloud’s story shows that open-source license compliance demands the same rigor as dependency security scanning. When the difference between a clean deal and a collapsed acquisition is a single pasted GPL function, you need tools that see code the way a human reviewer would—structurally, not just literally. See how Codequiry can help your team run similar audits before that next audit becomes a crisis.