SmartIP Copyright Desk · Software Ownership Series
The biggest software copyright problem often appears during funding or acquisition: everyone assumed the company owned the code, but nobody documented how rights moved from the people who wrote it. This SmartIP guide explains the ownership questions students and startups should solve early.
“We paid for the code” is not a complete ownership analysis
Software products are rarely written by one person under one clean relationship. A founder may build the first prototype before incorporation. An employee rewrites part of it. A freelancer creates the mobile interface. A student intern contributes an algorithm. An agency builds the website. Open-source libraries provide important functions. By the time customers arrive, the product may contain a complicated history of creators and licences.
Copyright ownership depends on authorship, employment relationships, statutory rules, assignments and contracts. Section 17 of the Indian Copyright Act establishes the author as first owner subject to important exceptions, including certain works created in the course of employment under a contract of service. Independent contractors and commissioned works can require different analysis depending on the type of work and agreement.
The safest business practice is therefore not to rely on assumptions. Trace the actual relationship behind each important asset and use written documents where rights need to move to the company.
Was it written before the company existed?
Was it created in the course of employment?
Is there a written assignment or licence?
Which licences and obligations apply?
Can the business prove the complete chain?
Founder code is often the first hidden diligence problem
Many startups begin before incorporation. A founder writes code on a personal computer, creates a GitHub repository and buys a domain. Months later, a company or LLP is formed. The founders assume the new entity automatically owns everything because it is “their startup”.
That assumption should be documented properly. Pre-incorporation copyright does not magically move merely because a company is later formed. The relevant rights may need to be assigned or licensed to the company under an appropriate agreement.
This issue becomes visible during investor diligence because the investor wants the company—not an individual founder—to control the core product. Fixing it early is straightforward. Reconstructing it after a founder dispute is much harder.
Employee-created code requires attention to role and employment
Section 17 contains employment-related ownership rules. In practice, companies should still use employment agreements that clearly address IP, confidentiality, software, documentation and post-employment obligations. This removes avoidable uncertainty and aligns employee expectations with the business model.
The company should also ensure that the work being claimed actually arose within the employment relationship. A developer’s unrelated personal project created outside work may raise different questions from code written as part of assigned product duties.
Operational controls matter too. Repositories, cloud accounts and development credentials should be company-controlled rather than remaining permanently inside personal accounts.
Freelancers and agencies deserve the most careful documentation
Independent developers are a common source of ownership gaps because founders assume that paying an invoice transfers all copyright. That is not a safe universal rule. The relationship and written agreement matter.
Section 19 requires copyright assignments to be in writing and signed by the assignor or authorised agent, and to identify the work and specify rights, duration and territorial extent. Where company ownership is intended, contractor agreements should be drafted accordingly rather than relying on a generic purchase order.
The contractor should also disclose third-party components. A perfect assignment of code the contractor does not own will not solve the inbound-licence problem.
The freelancer-built MVP
A founder hires a freelance developer through chat messages and monthly invoices. The developer builds the first working MVP. No written IP assignment is signed.
Two years later, the startup has rewritten much of the platform but still relies on important modules from the original version. An investor asks for chain-of-title evidence.
The company now has to locate the freelancer and negotiate documentation under funding pressure. The same issue could have been solved cheaply at the beginning with a clear development agreement.
Student projects create a special ownership puzzle
A college project may involve multiple students, faculty supervision, institutional resources, grants and industry sponsorship. Ownership should not be assumed from physical location alone. University IP policies and project agreements can materially affect the analysis.
Students should therefore review institutional policy before commercialising code. If the project later becomes a startup, the new company should document how the necessary rights move from the relevant creators or institution.
Faculty supervision is also different from authorship or ownership. A faculty member may contribute technical ideas, research direction or code, but title should follow actual legal contribution and institutional rules rather than hierarchy.
GitHub control is not the same as copyright ownership
Possessing the administrator password to a repository does not prove ownership of every line of code inside it. Repository history can be excellent evidence of contribution, but copyright title depends on the legal relationship behind those contributions.
Likewise, transferring a repository to an organisation account does not automatically transfer copyright. Operational control and legal ownership should be aligned through agreements.
Startups should use repository permissions, branch controls and employee offboarding as evidence-supporting practices, not as substitutes for IP documentation.
Open-source components create inbound rights
A company may own all proprietary code and still depend heavily on third-party libraries. Open source is licensed copyright. The licence determines what the company may do and what obligations apply.
A component register should identify package, version, licence, source and any material compliance actions. This does not need to be an enterprise-grade software bill of materials on day one; a simple disciplined record is already valuable.
Investors and enterprise customers may ask about reciprocal licences, attribution, redistribution and source disclosure. A clean register makes the answer faster and more credible.
AI-generated code adds another provenance layer
Coding assistants can generate substantial snippets or functions. The business should understand the tool’s terms, protect confidential code and review outputs for security, quality and third-party similarity.
AI use does not remove the need to trace human and third-party contributions. A company may have an employee as the principal human author, an AI tool as an assistance layer and multiple open-source dependencies in the same module.
The safest policy is to document important AI-assisted development and require human review before code enters production.
Assignments should be treated as precision tools
An assignment transfers specified rights. Because Section 19 requires the work, rights, duration and territorial extent to be identified, startup documents should not be vague where core product assets are involved.
If the company needs worldwide rights for the full term in specified software, the document should be structured deliberately. If the creator is only licensing limited use, that should also be clear.
Do not use the words “assignment” and “licence” interchangeably. The commercial consequences differ substantially.
What belongs in a software IP register
- Repository/product name and current owner;
- main creators and employment/contract relationship;
- assignment or employment document supporting title;
- open-source components and relevant licences;
- external code/content received under commercial licences;
- AI tools used materially in development where relevant;
- key release versions and evidence of creation.
This register becomes useful during fundraising, customer procurement, licensing and acquisition.
How student teams should handle multi-person projects
Keep a contribution record while the project is being built. Note who wrote major modules, who created graphics and documentation, and which components came from third parties. If the team intends to commercialise, discuss ownership before members graduate or leave.
If code will be open sourced, agree on the licence and authority to release it. If code will be moved into a startup, document the transfer. Do not wait until a conflict makes cooperation difficult.
These practices teach commercial discipline even when the project never becomes a company.
How startups should clean title before fundraising
Run a repository-by-repository ownership review. Identify founders’ pre-company code, contractors, employee agreements, agencies and open source. Fix missing assignments while relationships are healthy. Move important accounts and repositories into company control.
Also review marketing and website assets. Source code is not the only copyright asset. The company may rely on photographs, product renderings, manuals, videos and logos created by external agencies.
A funding round should not be the first time the company asks who owns its own product.
What an investor is really asking when it asks about IP ownership
The investor is not merely checking documents. It is asking whether the company controls the asset on which its valuation depends and whether a former contributor can later disrupt commercial use.
Clean chain of title therefore affects business confidence. A technically excellent product with unclear ownership can create transaction risk far beyond the cost of fixing a missing agreement early.
Copyright hygiene is therefore part of startup readiness, not a back-office legal task.
Do not forget documentation, interfaces and product media
Software ownership audits often focus only on source code, but a commercial product may depend on original manuals, onboarding text, icons, illustrations, training videos, product photographs and documentation. These works may have been created by different employees or agencies under different agreements.
During diligence, the buyer or investor may care about the whole user experience, not just the repository. A startup should therefore expand the chain-of-title review beyond code and confirm that commercially important creative assets are owned or properly licensed.
The same principle applies to student startups. A volunteer-created logo or externally produced demo video can become important once the venture is public.
Founder agreements should anticipate both current and future code
A good founder agreement should not focus only on the code already written. It should also address improvements, documentation, databases, designs and related copyright works created while the founders are building the business. Otherwise the startup may repeatedly need to reconstruct which person owns which asset as the product changes.
This is especially important where one founder is technically dominant and another handles business development. The technical founder may contribute most of the early software, but the commercial entity still needs a clear and fair rights structure that supports future investment. The goal is not to deprive creators of recognition; it is to ensure that the company can use the assets it depends on.
Where founders contribute pre-existing libraries or tools that they intend to retain personally, that distinction should also be documented rather than left implicit.
Employee offboarding is an IP event
When a developer leaves, the company should confirm repository access, device return, confidential material, documentation and outstanding inventions or works. Offboarding is the moment to make sure that operational control matches the legal position already established in employment documents.
Teams should avoid situations where a departing employee remains the administrator of a repository, cloud service or deployment account containing company code. Equally, the company should not assume that taking control of those accounts fixes missing copyright documents. Both legal title and technical control matter.
A clean offboarding checklist can therefore become part of copyright risk management, especially for small startups where one person may control several critical systems.
Contractor documentation should include delivery and provenance
Contractor agreements should say not only who owns the commissioned work but also what must be delivered. Source files, editable design files, build instructions, repository access and a list of third-party components can all be commercially important. Without these materials, the company may legally own an asset but still be unable to maintain or modify it efficiently.
Provenance warranties can also be useful. A contractor may be asked to disclose open-source code, stock assets, AI tools or subcontractors. The objective is not to prohibit every third-party input. It is to make the company aware of what has entered the product and under which terms.
This is particularly important for outsourced MVP development, where speed often causes founders to accept deliverables without a complete rights record.
A simple quarterly copyright ownership review
Every quarter, a startup can review new repositories, contractors, agencies, major creative assets and open-source additions. The review can be brief: what new material was created, who created it, what agreement covers it, and whether any licence conditions need action.
This routine prevents ownership clean-up from becoming a large annual project. It also helps the company notice when product development has moved into a new asset class—for example, from proprietary software into training content, datasets or customer-facing media.
For student startups, the same review can be done at the end of each semester so that graduating team members resolve ownership before leaving campus.
What to fix first when the ownership picture is messy
Start with the assets that generate revenue or would materially affect the company if lost. Core repositories, principal customer-facing software, key documentation and flagship creative assets should be reviewed first. Then identify missing assignments, unclear contractor terms, personal accounts and open-source dependencies that create the greatest risk.
Do not try to perfect every historical file before fixing the current workflow. Once the major legacy gaps are addressed, introduce standard employment, contractor and contributor documents so new problems stop accumulating. Ownership clean-up is most effective when remediation and future prevention happen together.
For student teams, the same approach works on a smaller scale: identify the code and creative assets needed for the startup, resolve those rights first, and document future contributions as they occur.
Ownership records should follow the product roadmap
When a startup launches a new mobile app, API, training module or design system, the ownership register should expand with it. The relevant question is not whether the company completed one IP audit in the past; it is whether the current revenue-generating product still has a clean chain of title.
A short review at every major release can identify new contractors, libraries and creative assets before they disappear into development history. This makes copyright governance continuous rather than reactive.
The cleanest ownership position is the one a third party can understand quickly: identify the asset, identify the creator, identify the document that transferred or licensed rights, and identify any third-party components that remain subject to separate terms.
That clarity saves time during funding, licensing, customer procurement and acquisition discussions, when uncertainty is most expensive.
Document it while relationships remain cooperative.
SmartIP takeaway
The most important software copyright question is not “is code protected?” It is “who owns this particular code and can the company prove it?” The answer may involve founders, employees, contractors, students, universities, open-source licensors and AI tools.
Build the chain of title as the software is created. For students, keep contribution and licence records. For startups, align contracts, repositories and ownership before funding. Good copyright documentation turns code from a working product into a transaction-ready business asset.
Official sources
- Copyright Office India — Copyright Act, 1957
- Copyright Office India — Statutory text including Sections 18–19
This article is for education only. Ownership depends on the particular work, relationship, agreement, institutional policy and applicable law.
