Contents
Owning software can mean several different things: holding copyright, having permission to use and change it, controlling the source repository, or being able to operate it independently. Establish each of these explicitly. Payment for a project and possession of its source files do not, by themselves, explain the full legal and operational position.
Establish the copyright position in writing
The UK Intellectual Property Office explains that the creator is normally the first copyright owner of commissioned work unless a different arrangement is agreed in writing. It also distinguishes work created by employees in the course of employment. Do not assume that paying an independent supplier automatically transfers copyright.
Ask the people responsible for your contract to identify what is being assigned or licensed, by whom and when. GOV.UK guidance states that transferring copyright requires a written agreement signed by the copyright owner. Have an appropriately qualified adviser review the actual agreement; this article is a planning checklist, not advice on the legal effect of a particular contract.
Intellectual Property Office: Ownership of copyright works
GOV.UK: Using somebody else's intellectual property — Copyright
Distinguish new work from existing components
Ask the supplier to identify code created specifically for the engagement, its own pre-existing components and third-party software. Review these categories separately. A statement about ownership of newly written code does not necessarily describe the terms on which an existing library or hosted service is used.
Request a dependency inventory and ask who checks the applicable licences. Establish the uses you need: operating the application, modifying it, engaging another maintainer or distributing it to customers. Have any uncertainties assessed against the actual licences and intended business model rather than treating all third-party components as interchangeable.
Agree practical control of the source and accounts
Specify where source code will be stored and which organisation controls access. Decide how your team will receive changes during delivery and what happens at handover. Include build configuration, automated checks and deployment instructions in the discussion, not only application files.
List the accounts required to operate the product: hosting, domains, email delivery, monitoring and any other third-party services. Identify their owners, billing responsibility and the process for granting and removing access. Repository access and account control are operational arrangements; neither should be used as a substitute for clear contractual rights.
Test whether a handover is usable
A useful handover enables an authorised maintainer to understand, build, test and deploy the application. Ask for an overview of the architecture, the environments, the release process and routine operational tasks. Identify where configuration is managed without placing secrets in ordinary documentation.
Arrange a practical handover exercise using an appropriate non-production environment. Can the receiving team follow the instructions and produce a working build? Can it identify the deployed version and the rollback procedure? Record questions and resolve them while the people who built the system are still available.
Make continuing support and exit responsibilities clear
Agree what happens when the engagement ends or another supplier takes over. Identify the material to be delivered, the assistance available and any commercial conditions that need to be satisfied. Review those terms alongside the support agreement so that ownership, access and service continuity tell a consistent story.
Keep the record current as the product changes. New components, accounts and contributors can introduce new questions. Treat the ownership and handover inventory as part of maintaining the product, with a named person responsible for resolving gaps before they become urgent.
Ownership and handover: a practical acceptance checklist
For a fictional supplier handover, create an inventory with asset, legal position, controlling account, successor access and acceptance evidence. Include source repositories, deployment pipelines, domains, hosting, database backups, app-store accounts, signing arrangements, design files, operating guides and third-party licences. A code archive and the right to use code answer different questions; record both.
Copyright ownership depends on the circumstances and agreement. GOV.UK explains that commissioned work does not automatically transfer copyright to the commissioner. Have the actual agreement reviewed by the person responsible for legal advice; do not treat payment, repository access or this checklist as proof of assignment. Identify reusable supplier components and third-party restrictions separately from commissioned work.
Test practical control with a successor exercise: an authorised maintainer clones the repository, builds it using documented dependencies, deploys to a non-production environment and restores a controlled backup. Record failures and owners. Transfer accounts through supported provider processes, review access and then remove outgoing access when the transition owner confirms continuity. Do not put passwords or keys in the handover document.
How this relates to Veda Software’s work
Encounter’s published story spans customer navigation and managed trip information. It helps explain why handover needs operating context beyond source files; it does not publish the project’s copyright or account-transfer terms.