Who Owns the Code? IP Assignments in Software Development Agreements

A software company may own servers, employ developers and sell subscriptions without legally owning the code on which its product depends. The commercial assumption that payment for development transfers intellectual property is particularly dangerous in outsourced projects. Ownership must be established through the agreement and the law governing the relevant work.

Employment is not a universal answer

The position of employee-created work must be distinguished from independent contractor contributions, third-party libraries and code acquired through earlier collaborations. The Copyright Ordinance, 1962 and applicable contractual arrangements should be examined to determine ownership. Where a founder wrote software before incorporation, the mere creation of the company does not necessarily transfer those rights. Equally, paying an external development firm does not automatically confer every copyright, database or other proprietary right that the client may expect. The legal inquiry should identify each material contribution and the chain of title to it.

Assignments must identify the rights

A meaningful assignment should state which existing and future works are transferred, when the transfer takes effect, the consideration and the assistance required to evidence title. It should distinguish source code from third-party components, reusable tools, documentation, designs and improvements. General promises that 'all work belongs to the client' may leave disputes about background intellectual property used by the developer across multiple customers. The client should also consider whether rights to maintain, modify, sublicence and transfer the software follow from the instrument actually executed. A buyer or investor examining technology assets will want proof, not merely assurance, that those rights exist.

Open-source components create separate obligations

A product may include open-source libraries whose licences impose conditions regarding attribution, notices, distribution or source-code availability. Those terms are not necessarily incompatible with a commercial SaaS business, but they may affect the way software is provided and how proprietary modules are combined. A developer's warranty that all components are 'original' can be inaccurate where industry-standard libraries have been used. A software bill of materials and an accurate licence review are more useful than unrealistic absolute statements. Rights to audit and replace non-compliant dependencies should form part of major procurement arrangements.

Control the handover and future use

Possession of a repository password is not ownership, and ownership does not guarantee technical ability to maintain a product. The contract should address delivery of source code, documentation, test data, build instructions, credentials and third-party account ownership. It should also identify whether the developer may reuse modules or confidential information. On termination, the company needs legally enforceable access to the material required for transition. Escrow or periodic source deliveries can reduce dependence on a single vendor, provided release conditions and the scope of materials are clear.

Prove title to the technology

Software diligence should follow the code from creation to the current product, testing both contractual title and practical control. Ownership language, third-party licensing and transition obligations should be settled before a business raises investment or faces a developer dispute. An expensive software asset is of limited value if the company cannot prove its rights or maintain it independently.