The story reaches the laboratory in two mirrored versions. In the first, a company watches its product be reborn on the market months after a key developer's departure: same functions, same screens, even the same defects, now under another brand. In the second, a company receives a notice accusing it of infringement: the software it developed is allegedly a copy of the competitor's, and the damages demanded carry many zeros. In both scenarios, the technical question is identical: up to what point are two programs similar because they solve the same problem, and beyond what point can the similarity only be explained by copying?
What the code comparison examines
Software is compared in layers. On the surface, the experience: screens, flows, visible naming. Below that, the architecture: how the system organizes itself, how the modules talk to each other, how the data is structured. And at the bottom, the source code, where the author's signature lives: variable and function names, writing style, comments, idiosyncratic solutions to common problems. Two systems in the same niche can legitimately resemble each other in the upper layers, because the domain imposes the format. What coincidence cannot explain is identity in the lower layers, and that is where the examination concentrates its effort.
The decisive findings are usually the ones inherited by carelessness: the identical Portuguese comment, with the same typo, in both codebases; the function with a peculiar name that only makes sense in the first company's internal history; the same defect, reproduced with the same improvised fix; the uniquely modified library appearing modified in the same way in the supposedly independent software. Whoever copies rarely rewrites everything, and what gets left behind works as the case's DNA: elements too arbitrary to be born twice by chance.
"Systems in the same field resemble each other by nature. What is not born twice by chance is the same comment with the same typo, in the same function, solving the same problem in the same crooked way."
The code's journey is evidence too
Beyond the confrontation between the two programs, the examination reconstructs the route of the copy. Code repositories record who accessed what and when; workstation artifacts keep traces of connected USB devices and copied volumes; servers document complete clones of the repository on the eve of the departure; personal cloud services receive uploads that network logs date and measure. The same method as the internal leak investigation applies here, with a specific target: demonstrating that the assets left, when they left, and who had them. The correlation between the route of the copy and the identity of the code closes the evidentiary circuit.
The reach goes beyond code: customer databases, pricing spreadsheets, and technical documentation follow the same evidentiary logic, and the arbitrary details they carry (peculiar records, formatting, inherited errors) expose the reuse with the same force.
The technical defense of the one who did not copy
The examination serves the unjustly accused just as well, and those cases exist in quantity. The defense is built by demonstrating independent development: the repository history with the gradual evolution of the code from its origin, the divergent architecture decisions in the deep layers, the absence of shared arbitrary elements. When the accusation rests only on the similarity of screens and features, the examination that descends into the code dismantles the theory: alike on the outside and distinct on the inside is the signature of the legitimate competitor, not of the infringer.
When there is no source code: the binary confrontation
The alleged infringer does not always hand over the code, and the court does not always compel it in time. The examination then descends to the compiled product: the distributed binary, the installed application, the system in production. Even without the source, the software tells its story: the embedded text strings (messages, labels, internal paths), the incorporated libraries and their versions, the function structure that technical analysis reconstructs, the graphic resources and auxiliary files that travel along. Binary comparison identifies coincidences as arbitrary as those in code: the same error message with the same peculiar wording, the same set of libraries in the same modified versions, internal artifacts with names that only existed in the original project. The result even guides the next phase of the case: with objective indications in the binary, the request for production of the source code stops being a fishing expedition and becomes a well-grounded measure.
Before the litigation: the companies' homework
- A repository with an intact history and traceable authorship: it is your code's birth certificate;
- Documented access control: who can clone what, with the audit trail preserved;
- Contracts with clear ownership and confidentiality clauses, including with contractors;
- Technical staff offboarding with protocol: revocation of access and preservation of the workstation;
- At the first sign of copying, forensic preservation before the demand letter: the notified party deletes.
Software disputes are often narrated as duels of opinion between developers, each side with its specialist swearing the obvious. A well-conducted examination removes the case from that terrain: it turns similarity into measurement, route into timeline, and conviction into reproducible demonstration. In the end, the question "did they copy or not?" has a technical answer in the vast majority of cases. What it demands is what every technology dispute demands: arrive early, preserve correctly, and examine deeply.
Code is an asset that gets copied in a minute and disputed for years. The difference between the two outcomes is what the company preserved on the day it did not yet need to.
