Who owns the code we pay you to write?

Ownership must be written, not inferred

Paying for software development does not by itself answer every intellectual-property question. The agreement should state which deliverables are assigned, when assignment takes effect, which rights are licensed instead, and which materials are excluded. Bespoke application code, infrastructure definitions, tests, schemas, design source files and project documentation should be named where they form part of delivery. The contract also needs the governing jurisdiction and treatment of moral rights where relevant. Clear drafting protects continuity; it does not prevent the supplier from applying general experience and methods elsewhere.

Ownership and practical control are different. A client can hold contractual title yet remain dependent because repositories, package registries, cloud accounts or signing credentials sit under a supplier’s private tenancy. Project assets should therefore live in accounts the client controls, or transfer procedures should be agreed from the start. Named administrators, recovery methods and billing ownership matter as much as a source archive. A final zip file cannot recreate review history, deployment permissions, issue context or the provenance of released artefacts.

Separate bespoke, background and third-party material

Bespoke material is created specifically for the engagement. Background material existed beforehand or was developed independently, such as a deployment utility, generic library or internal framework. Third-party material comes from another rights holder. A sound schedule distinguishes these classes and grants sufficient rights to build, operate, modify and transfer the delivered system. If background material is essential at runtime, the client needs a durable licence with terms compatible with operational continuity. Vague labels such as supplier know-how should not swallow project-specific code or prevent maintenance by another team.

• Identify repositories, branches, package registries and artefact stores included in delivery.
• Record third-party packages and their licence notices in a maintained dependency inventory.
• State the rights granted for essential pre-existing supplier components.
• Keep cloud resources, domains and production credentials under accountable client ownership.
• Include schemas, tests, infrastructure code and operating documentation in acceptance.

Open-source code is licensed, not reassigned

Open-source dependencies remain owned by their respective authors and are used under licence. Permissive and copyleft licences impose different obligations around notices, source availability, modification and distribution. The relevant question is not whether open source is present, but whether each licence is understood in the way the software is deployed or supplied. Automated dependency scanning helps build an inventory, but legal classification may still require review. Vendored snippets, generated clients, fonts and container images deserve the same attention because they can be overlooked by package-manager reports.

Authorship and access need controls

The supplier must ensure that employees and subcontractors have assigned or licensed their contributions on terms that permit the promised client rights. Repository access should use named identities, least privilege and prompt removal when a contributor leaves. Commit history and code review provide provenance, while protected branches prevent unreviewed substitution near release. Secrets do not belong in the repository and should transfer through a controlled secrets manager. These engineering practices support the legal chain of title by showing what entered the product, who approved it and which artefact was deployed.

Define rights around data and models separately

Application data normally belongs to or is controlled by the client, but contracts should distinguish personal data roles, derived operational data, telemetry and aggregated service information. AI features add model weights, prompts, evaluation sets and provider terms. A hosted model API does not become client property because an application calls it. Fine-tuning may create artefacts governed by the base model and platform terms. The agreement should identify which data may leave the client environment, what may be retained for service improvement, and how exports and deletion are handled at termination.

Make exit possible throughout delivery

Handover should be tested before the final invoice. A client-controlled build must resolve dependencies, execute tests and produce a deployable artefact from documented inputs. Another competent engineer should be able to provision an environment, locate decisions and follow operational runbooks without private supplier knowledge. Outstanding licence restrictions and manual release steps need explicit treatment. Regular repository access and incremental documentation make this ordinary project hygiene rather than an adversarial end-stage exercise. The objective is not to remove collaboration, but to ensure collaboration remains a choice rather than a technical lock-in.