Who owns the source code created by a software development contractor?

A software-development contractor does not automatically transfer every intellectual-property right in the source code it writes merely because the customer pays the development fee. Ownership depends on the applicable copyright law, the nature of the relationship, the rights in pre-existing components and the specific contractual assignment or licence. A customer may obtain a working application without obtaining the legal or technical ability to modify, reproduce, distribute or commission a replacement developer to maintain it.

Under Pakistani law, the Copyright Ordinance, 1962 is an important starting point for original software works and related copyright questions, alongside general contract principles. The precise legal result must be checked against the work's authorship, employment or independent-contractor status, any applicable statutory rule and the executed agreement. Commercial software also includes material that may belong to third parties, including open-source libraries, frameworks, images, datasets and hosted services.

Begin by identifying what is being delivered

A project description may use the word 'software' while covering materially different deliverables: source code, executable application, user interface designs, database schema, API integrations, deployment scripts, infrastructure configuration, trained models, documentation and domain names. Each can involve different ownership or access rights.

The contract should list every deliverable and identify the repository, format and method of handover. A customer paying for a web platform should not assume that receipt of a login to a hosted instance is equivalent to delivery of maintainable source code.

Where the contractor is expected to provide a working service rather than an independently owned software product, the commercial arrangement may legitimately be a licence or SaaS subscription. The distinction is not inherently improper, but it must be understood before the customer pays for what it believes is a bespoke asset.

Authorship and copyright ownership are not the same question

A programmer may be the author of code, while legal ownership of particular economic rights may depend on employment arrangements, statutory rules or an effective assignment. A contractor's invoice marked 'paid in full' should not be treated as a substitute for analysing those rights.

Examine who actually wrote the software. A development agency may rely on employees, freelancers or foreign subcontractors. The agency's promise to assign rights is meaningful only to the extent that it has acquired those rights or is authorised to transfer them.

A chain-of-title record should therefore identify the original creators, applicable contracts, contributions, rights obtained and any remaining restrictions. If the agency used freelancers without assignments, the customer may face difficulty proving that it received exclusive rights in the resulting code.

A written intellectual-property assignment

Where the customer intends to own bespoke software, the agreement should contain a clearly drafted assignment identifying the relevant rights, deliverables, territory, permitted uses, payment condition where appropriate and obligations to execute additional instruments. Review statutory formalities governing the assignment and its scope.

Avoid a clause stating merely that 'all intellectual property shall belong to the client' if the contract also gives the contractor unrestricted rights to license the whole project elsewhere or does not address pre-existing components. Interpret the agreement as a whole and reconcile inconsistent schedules.

The timing of transfer can matter. Some agreements provide assignment on creation, others on acceptance or full payment. If the customer needs ownership to attract investment, license the product or pledge assets, it should verify that all contractual conditions for transfer have actually occurred.

Background technology and reusable components

A developer may use libraries, code templates, frameworks and proprietary modules created before the project. It may be commercially reasonable for the contractor to retain rights in that background technology while licensing their use as part of the delivered product.

The customer should receive a background-IP schedule identifying excluded components and the licence needed to operate, modify, distribute and transfer the solution. A licence limited to the original contractor's hosting environment may be inadequate for a business that wants to move the software to its own server.

The developer also needs protection against a sweeping assignment of unrelated technology used in numerous client projects. Precise separation of project-specific code from reusable tools can serve both sides better than an expansive but contradictory statement of ownership.

Third-party libraries and open-source obligations

Open-source software can be lawfully used in commercial products, but applicable licence conditions vary. Some licences impose attribution, notice or distribution requirements; others may require source-code availability for particular forms of distribution or derivative work.

The developer should provide a software bill of materials or comparable inventory for important third-party components, identifying their licence terms and known restrictions. The customer should know whether the intended commercial distribution, white-label licensing or closed-source use is compatible with those terms.

A warranty that all code is entirely original is often inaccurate where standard libraries are involved. A better clause requires lawful use, accurate disclosure, compliance with applicable licence conditions and remediation if an incompatible component is discovered.

Repository and delivery control

Legal ownership is commercially weak if the customer cannot access the source code, version history, build process and deployment credentials. The agreement should identify who controls the Git repository, cloud accounts, domain registrations, code-signing keys, databases and credentials.

For a commissioned platform, the customer may require a repository under its organisation with appropriate contractor access, rather than the contractor's private account being the only place where code exists. Alternatively, the contract may require defined periodic deposits or delivery milestones.

A proper handover should contain the source, dependency specifications, build instructions, environment settings excluding exposed secrets, database migration scripts, deployment procedures and reasonable documentation. The customer should verify that an independent technical team could reconstruct the application.

Acceptance tests and payment milestones

Acceptance should be based on measurable specifications, not an unqualified statement that the application works. Define functional requirements, security and performance criteria, test data, defect categories and the period in which the customer can reject or require correction.

Payment milestones should correspond to identifiable deliverables and rights. A contractor may legitimately receive fees as work progresses, but the customer should avoid paying the whole consideration while source delivery and ownership remain unresolved.

If the contract makes assignment conditional on full payment, address ownership of interim work and the right to continue the project after termination. A dispute over an unpaid final invoice should not leave both parties uncertain about whether the customer may lawfully use earlier accepted modules.

Contractor employees and subcontractors

An agency should disclose the level of subcontracting relevant to the customer's risk and ensure that its personnel are bound by appropriate confidentiality and IP obligations. Where work involves sensitive financial or legal information, access controls and return-of-information duties are as important as source-code assignment.

A customer may require approval before critical components are subcontracted or processed outside specified locations. The clause should be realistic enough that the developer can use ordinary tools while preserving clearly identified security and ownership requirements.

Confirm that the contractor has authority to provide the licences and assignments it promises. A mere indemnity against third-party claims may not cure the absence of rights needed to distribute the finished product.

AI-generated code and automated development tools

Use of AI coding assistants introduces separate questions. A developer may generate or modify code through a model trained by a third party and integrate the output into the project. The contract should address permitted tools, confidentiality of customer inputs, security review and the developer's responsibility for testing and originality risks.

The customer should not assume that all machine-generated material attracts identical copyright protection or can be transferred free from third-party restrictions. Nor should the developer assume that use of AI excuses failure to comply with contractual quality, security or licensing obligations.

For sensitive systems, require the contractor to disclose material external tool usage, prohibit uploading confidential code to unauthorised public services and maintain a documented code review process.

Maintenance, updates and derivative works

Ownership of initial source code is not enough if maintenance depends on the original contractor's unpublished internal tools. Define support periods, bug fixes, security patches, additional feature development and rights in subsequent modifications.

If the customer owns the platform, it should be permitted to appoint other developers, subject to legitimate confidentiality and background-IP constraints. The contract should also state who owns paid change requests and whether independent modules developed later fall within the original assignment.

Termination should not invalidate rights that were intended to be perpetual or already transferred. Conversely, the customer may lose the right to use a third-party subscription or hosted component on termination if that limitation was part of the agreed commercial arrangement.

Enforcement of ownership and confidentiality

If the contractor withholds code or offers the same bespoke work to a competitor, the appropriate claim depends on the executed agreement, identifiable rights and conduct. Potential remedies may involve contractual relief, injunctions or proceedings concerning infringement or misuse of confidential information.

The claimant should preserve the statement of work, assignment provisions, payment history, repository logs, source snapshots, communications and evidence of unauthorised copying or distribution. A general claim that the customer paid for development does not prove that every reused component was unlawfully appropriated.

Where the product includes trade secrets or personal data, protective measures and a proportionate response to any disclosure should be pursued without confusing a civil contract dispute with a criminal offence that requires separate statutory ingredients.

A practical example of a commissioned legal platform

Suppose a Pakistani startup commissions a case-law search portal. The developer builds a website platform frontend, custom search backend and document-processing scripts, relying partly on open-source libraries and partly on reusable software from earlier projects. After launch, the startup asks for all code so it can migrate the system to its own server.

The legal answer requires a deliverables inventory and the actual contract. The startup may own the newly created bespoke code if the rights were effectively assigned, but the developer may retain lawful rights in identified reusable components. The customer needs an adequate licence to operate those components and the technical artefacts necessary for migration.

A contractual promise to supply the website is not necessarily an agreement to transfer every underlying tool. These matters should be resolved in drafting, not after the commercial relationship deteriorates.

Opinion and recommended contract position

The source code created by an independent software-development contractor should not be assumed to belong automatically to the paying customer. Establish the statutory and contractual ownership position, trace rights from actual creators, distinguish newly commissioned work from background IP and third-party components, and document the intended assignment or licence.

For a customer investing in a proprietary platform, the recommended protections are a clear written rights allocation, source repository control, third-party component disclosure, acceptance tests, delivery obligations, security controls and post-termination migration rights. The contract should permit lawful ongoing use without requiring continued dependence on the original developer unless that dependence is knowingly part of the agreed service model.

The legal and practical questions are inseparable: owning an abstract copyright interest may be insufficient if source code and deployment controls are unavailable, while possessing files is not conclusive proof of an unrestricted right to commercialise them.

Principal authorities for verification: Copyright Ordinance, 1962; Contract Act, 1872; Electronic Transactions Ordinance, 2002 where relevant; applicable open-source licences; and the executed development, subcontractor, confidentiality, assignment and support agreements.