Software and source code

This is the area where my background counts for most, because for twenty years I wrote software, had it written, and put it into production. Disputes over a delivery turn on facts I have watched unfold many times.

The recurring disputes

Breach and non-conformity

The customer says the software does not do what it was supposed to; the supplier says it does exactly what was asked. In nearly every case the real dispute is not about the code but about what was agreed, and the answer lies in the contractual documents, the specifications, the acceptance records and — often decisively — the correspondence exchanged during development, where requirement changes appear without ever being formalised.

Technically, what the delivered program actually does is established by installing it in a controlled environment, running the cases set out in the specification and documenting the outcome of each. It is less dramatic work than people expect, and almost always decisive.

Ownership of code and reuse

Who owns code developed to order depends on the contract, and in the absence of clear terms the starting point is copyright: a program is a work of authorship and rights arise in the author, subject to the separate rule for works created by an employee in the course of their duties. Italian copyright law, in the part dealing with computer programs, is the reference.

The technical contribution lies in establishing which code is being talked about: which portions were actually written for that engagement, which come from third-party libraries, which were reused from earlier work. Codebases are compared using similarity measures and by examining version-control history, which records who wrote what and when in a detail no witness statement can match.

Open source licensing

A chapter that appears more and more often. Almost every piece of software contains third-party components released under licences that impose obligations: attribution, preservation of copyright notices and, for some licences, an obligation to make the source of derivative works available. A product incorporating such components without meeting their conditions exposes the customer to a risk nobody has usually explained to them. The examination consists of inventorying components and their licences and checking compatibility with the distribution model.

Code misappropriation and unfair competition

A former collaborator sets up a competing business with a strikingly similar product. The technical question is whether there is derivation. It is answered by comparing the codebases — not merely the text, which is easy to rewrite, but the structure, internal names, repeated mistakes, comments, the arbitrary choices two independent authors would never make the same way — and by reconstructing from access records and repository history what was copied and when.

Method

• A reconstructed environment. Software is examined by running it in an isolated environment reproducing the reference configuration, not on either party's production systems.
• History, not assertions. Version-control systems record author, date and content of every change. They can be manipulated, but manipulation leaves detectable inconsistencies.
• Reproducibility. Every test carried out is described so that the other side's expert can repeat it and obtain the same result. Where useful, I append the scripts I used.