Source Code Ownership Review Before Acquiring an Indian Software Company
A buyer acquiring an Indian software company is usually paying for code, product know-how and customer revenue. The legal question is sharper than whether the target has a repository. The buyer needs to know whether the company owns the source code, can modify it, can transfer or license it after closing, and has not accepted restrictions that weaken the acquisition thesis.
Source code ownership review should start before valuation, warranties and closing conditions are settled. A clean answer can support speed. An uncertain answer can change price, require remediation or move the deal from a share purchase to a narrower asset or licence structure.
Why This Matters
In Indian software acquisitions, ownership gaps often sit outside the main corporate records. Founders may have written important code before incorporation. Early engineers may have worked without signed employment terms. Agencies may have delivered modules under statements of work that discuss payment and delivery but not assignment. Affiliates, accelerator teams and consultants may also have contributed to the product.
The Copyright Act, 1957 is the core statutory starting point because computer programs are protected as copyright works. Its provisions on first ownership and assignment make written rights analysis central to diligence. The Copyright Act, Chapter IV is especially relevant for authorship, first ownership, assignment and licence questions. The Indian Contract Act, 1872 matters because assignments, consulting terms, warranties, indemnities and remediation undertakings are contractual promises. Where board authority or sale approvals matter, the Companies Act, 2013 also needs review.
For a buyer, the business risk is practical. If the target cannot prove source code ownership, it may be unable to transfer the asset cleanly, enforce exclusivity, grant customer rights, stop a former contributor from asserting claims or integrate the product into the buyer's wider stack.
What Counsel Should Review
Start with a product-to-repository map. Counsel should identify each material product, module, mobile application, API, script, build pipeline and deployment component. That map should connect each component to the repository, contributor group, contract record and revenue stream. Without this map, diligence becomes a document collection exercise rather than an ownership review.
Next, review founder and pre-incorporation code. If founders created software before the company existed, the buyer should see clear assignment language transferring relevant rights to the company. Cap table ownership does not itself prove software ownership. Founder employment, consultancy or IP assignment documents should also cover later improvements, documentation, architecture notes and derivative work.
Employee and contractor records require a contributor-by-contributor check. Employment agreements, consulting contracts, agency statements of work and offer letters should be tested against actual repository activity. The buyer should ask who committed material code, when they worked, which entity engaged them and whether the agreement covered copyright assignment, confidentiality, background materials, tools and later modifications.
Third-party and open-source components need a separate licence track. Not every external dependency is a defect. The diligence issue is whether the target understands its dependency stack, keeps required notices, avoids incompatible licence use in proprietary modules and has commercial licences for paid tooling. A buyer should not accept a broad ownership warranty until the codebase has been matched against dependency evidence.
Public and official evidence should support, not replace, the contract review. IP India's basic copyright guidance explains that registration is not mandatory but may serve as evidence. The Copyright Office register search can help check registered works. For electronically executed records, the Information Technology Act, 2000 may be relevant to electronic records and authentication.
Finally, connect the ownership answer to the deal documents. The purchase agreement should distinguish owned code, licensed code, open-source components, background IP, customer-specific customizations and excluded assets. Disclosure schedules should identify unresolved contributors, missing signatures, affiliate-held code, repository access limits, escrow arrangements and licences that need consent on acquisition.
Typical Timeline and Cost Range
A focused source code ownership review for one main product can often be completed in 7 to 14 business days if contracts, contributor lists and repository records are ready. A broader acquisition review covering multiple products, historical contributors, affiliate development, open-source scanning and remediation planning may take 3 to 5 weeks.
The efficient approach is phased. First, identify value-critical ownership risks. Then decide which gaps require closing conditions, confirmatory assignments, licence amendments, escrow, indemnity support or post-closing cleanup. A buyer should not spend equal effort on minor tools if a core module has unresolved authorship or assignment evidence.
Common Mistakes
- Equating repository access with ownership. Admin access to GitHub, GitLab or a local repository does not prove that the company owns the code.
- Ignoring early and external contributors. Founder code, freelancer modules, agency builds and affiliate development often create the most important chain-of-title gaps.
- Using one warranty for mixed code. Owned code, licensed code, open-source dependencies and customer-specific work need different disclosures and risk allocation.
How KAS & Co. Can Help
KAS & Co. helps buyers and Indian software companies review source code ownership, contributor assignments, software licences, open-source exposure, repository evidence and acquisition-document protections before signing or closing. For a focused source code ownership review, contact KAS & Co..
FAQs
1. Does repository control prove source code ownership?
No. Repository control is useful evidence of possession and access, but ownership depends on authorship, employment terms, contractor agreements, assignments, licences and contribution history.
2. What should a buyer ask for first?
A buyer should ask for a product-to-repository map, contributor list, founder assignments, employment and contractor agreements, agency statements of work, dependency inventory and material customer licences.
3. Can source code ownership gaps be fixed before closing?
Many gaps can be addressed through confirmatory assignments, licence amendments or targeted disclosures. Core ownership gaps should be resolved before closing where they affect valuation or integration.
4. Should open-source software stop an acquisition?
Not automatically. Open-source use should be identified, classified and tested against distribution, notice, source-availability and compatibility obligations before the buyer accepts the risk.
Sources
Topics
Need legal advice on this topic?
KAS & Co. provides strategic legal counsel across technology law, data privacy, IP and commercial advisory.
Schedule a Consultation