A company can spend months developing an application, a SaaS platform or an internal tool, only to discover too late that ownership of the code has never been documented. The issue typically surfaces during an investment round, a company sale, a contentious exit by a technical shareholder, or a claim brought by an external developer.
The problem is that when development of a programme, app or similar product is commissioned from a third party, a freelance developer, a software company, and so on, that third party retains the intellectual property unless a contrary arrangement has been expressly agreed (even if the application cost a fortune to build). This means that, absent any agreement to the contrary, the developer is free to sell the same application to your nearest competitor.
Within the corporate context, there is a specific rule that applies to software created by employees: if the programme is created in the course of the employee's duties or following the employer's instructions, the exploitation rights vest exclusively in the employer, unless otherwise agreed.
However, that rule does not cover every scenario. It does not apply in the same way to freelancers, external agencies, founding partners without a clear contract, interns, international collaborators, open-source contributions, or code developed before the company was incorporated. To ensure that the code genuinely belongs to the company, it is necessary to combine robust contracts, technical traceability and an internal intellectual property policy.
What software is protected by intellectual property law?
The Intellectual Property Act defines a computer program as any sequence of instructions or commands intended to be used, directly or indirectly, in a computer system to perform a function, task or produce a result. Protection extends to any form of expression of the programme, its successive versions and derivative programmes, but does not cover the underlying ideas and principles on which the programme or its interfaces are based.
This means that intellectual property law protects the specific form in which the software is expressed, not the underlying business concept in the abstract.
| Element | Protected? | Practical note |
|---|---|---|
| Source code | Yes | This is the primary asset that must be properly documented. |
| Object code | Yes | The law expressly refers to both source program and object program in the employment context. |
| Preparatory documentation | Yes | May include functional analysis, architecture documentation or technical documentation linked to the development. |
| User manuals | Yes | Afforded the same protection as the programme itself under the software-specific provisions of the Act. |
| Successive versions | Yes | It is advisable to document releases, branches and contributions. |
| Derivative programmes | Yes | It is essential to verify whether they derive from proprietary code, third-party code or open-source code. |
| Ideas, methods or principles | Not by copyright | These may be protected by other contractual or, in certain cases, industrial property mechanisms, but not as copyright in software. |
Who owns code created by employees?
For salaried employees, the key rule is set out in Article 97.4 of the Spanish Intellectual Property Act. When an employee creates a computer program in the course of carrying out their assigned duties or following the employer's instructions, the exploitation rights over that program, both source code and object code, belong exclusively to the employer, unless otherwise agreed.
The company therefore starts from a favourable position where the development clearly falls within the scope of the employee's role. Even so, it is not advisable to rely solely on the statutory presumption. In the event of an audit, a due diligence process, or a dispute, the company must be able to demonstrate that the code was created within the employment framework, using the company's resources, under the company's instructions, and for a company project.
What the company should review in employment contracts
| Contract clause | Why it matters |
|---|---|
| Job description | Should reflect that the employee develops, maintains, documents or participates in software work. |
| Intellectual property clause | Should confirm that the company holds the exploitation rights over any software created within the scope of the employment relationship. |
| Confidentiality | Protects code, architecture, repositories, credentials, technical documentation and product roadmap. |
| Use of tools | Should govern the use of GitHub, GitLab, Jira, Notion, Figma, cloud environments, corporate accounts and devices. |
| Personal projects | A clear distinction should be drawn between the employee's own projects and developments carried out for the company. |
| Return of materials | Should provide for the return or handover of code, documentation, access rights and credentials upon termination of the relationship. |
| No incorporation of third-party code | Reduces the risk of the employee introducing unauthorised third-party libraries, snippets or code. |
What happens with software created by freelancers or external agencies?
This is one of the most common mistakes. The rule under Article 97.4 applies to salaried employees. A freelancer, development agency or technology provider is not a salaried employee of the company. Without a clear assignment of rights, the company may have paid for the development work but not necessarily hold all the exploitation rights it needs.
Article 43 of the Intellectual Property Act requires that any assignment of exploitation rights be limited to the rights assigned, the permitted forms of exploitation, the duration, and the territorial scope. The Act also provides that an assignment does not extend to forms of use or means of distribution that did not exist or were unknown at the time of the assignment.
In contracts with suppliers, this demands precise drafting. An invoice that simply reads "web development", "mobile app" or "programming services" is not sufficient.
Minimum clauses in contracts with freelancers and suppliers
| Clause | What it must cover |
|---|---|
| Assignment of rights | Reproduction, transformation, adaptation, distribution, communication where applicable, and exploitation of the software. |
| Territorial scope | Spain, the European Union or worldwide, depending on the project. |
| Duration | Preferably for the full legally permitted term, where consistent with the agreement. |
| Exclusivity | If the company requires the code to be exclusive, this must be stated expressly. |
| Source code | Obligation to deliver the repository, documentation, dependencies, deployment credentials and all versions. |
| Originality warranty | The supplier must declare that the code does not infringe any third-party rights. |
| Open source | Inventory of libraries, licences and restrictions. |
| Subcontracting | Identification of subcontractors and assignment of their rights. |
| Generative AI | Declaration on the use of AI tools, and review of rights, confidentiality and traceability. |
| Support and maintenance | Ownership of the code must be kept separate from any subsequent maintenance services. |
What rights does the company actually need over the software?
The holder of rights over a computer program may authorise or carry out essential acts such as total or partial reproduction, translation, adaptation, arrangement or transformation, and public distribution of the programme. Spain's Intellectual Property Act also sets out limitations for the legitimate user, including certain acts necessary to use the programme, such as error correction, unless otherwise stipulated by contract.
For a technology company, this translates into a very practical question: can the company use, modify, scale, sell, licence, integrate, migrate, audit and transfer the software without seeking further authorisation?
| Business need | Right or protection required |
|---|---|
| Using the software internally | Right of use and technical reproduction. |
| Commercialising a SaaS product | Sufficient exploitation, adaptation and maintenance rights. |
| Modifying the code | Right of transformation and full access to the source code. |
| Selling the company | Documented and transferable chain of ownership. |
| Raising investment | Employment contracts, freelancer IP assignments and open-source audit. |
| Licensing to clients | Rights to grant licences or sub-licences where applicable. |
| Integrating third-party code | Compatible licences and documented dependency mapping. |
| Defending against copying | Evidence of authorship, dates, repositories, contracts and registrations. |
Diagram: how code ownership should flow to the company
What happens to code created by founding partners?
In startups and technology companies, a significant portion of the codebase may be written before any formal legal structure is in place. A founder may have built the MVP before the company was incorporated, working from a personal GitHub account, using their own tools, and without any shareholders' agreement.
This issue needs to be addressed as early as possible. If the software was created before incorporation, the company should not automatically assume that it already owns the code. The right approach is to document a formal contribution or assignment of rights in favour of the company, aligned with the shareholders' agreement and consistent with the tax and corporate law implications of the transaction.
Common risks in startups
| Situation | Risk |
|---|---|
| MVP created before the company was incorporated | The founder may retain ownership if no documented assignment of rights exists. |
| Code held in a personal repository | Makes it difficult to demonstrate corporate control and continuity of the asset. |
| Departure of a CTO or technical shareholder | May block maintenance, sale, or investment activity if no clear agreement is in place. |
| Development carried out by friends or informal collaborators | Risk of future claims relating to authorship or remuneration. |
| Uncontrolled use of snippets, templates, or libraries | Risk of infringement or licence incompatibility. |
| No shareholders' agreement in place | No agreed rules on ownership, dedication, exit, or non-competition. |
Is registering the software enough?
Registration can help as evidence, but it is no substitute for a sound contractual chain. Spain's Intellectual Property Act allows rights over computer programs, successive versions and derivative programs to be recorded in the Intellectual Property Registry.
Registration can be useful for establishing a date, a version and a declared ownership. However, if the code was created by a supplier who never assigned the rights, or by a shareholder who never formally contributed the asset to the company, registration alone does not resolve the underlying problem.
The right approach typically combines:
| Tool | Purpose |
|---|---|
| Employment contracts | Align job functions, intellectual property ownership and confidentiality obligations. |
| Commercial contracts | Obtain express assignment of rights from freelancers, agencies and consultants. |
| Shareholders' agreement | Govern software contributions, founder exit arrangements and post-exit restrictions on use. |
| Intellectual property registration | Strengthen evidential position in respect of key versions. |
| Corporate repositories | Demonstrate technical traceability, commit history and access controls. |
| Open-source inventory | Identify licences, restrictions and attribution obligations. |
| Legal and technical audit | Prepare for investment, acquisition or sale. |
Checklist for confirming that the code belongs to the company
Before a funding round, a sale of the company or the launch of a digital product, the following points should be reviewed:
| Area | Control question | Status |
|---|---|---|
| Employees | Do developers have employment contracts with clearly defined technical duties? | Pending / Reviewed |
| Intellectual property | Is there a specific clause covering software and exploitation rights? | Pending / Reviewed |
| Freelancers | Have all external contractors signed a sufficient assignment of rights? | Pending / Reviewed |
| Subcontractors | Do suppliers guarantee the assignment of rights from their own collaborators? | Pending / Reviewed |
| Founders | Was any pre-existing code formally assigned or contributed to the company? | Pending / Reviewed |
| Repositories | Is the code held in corporate accounts rather than personal ones? | Pending / Reviewed |
| Open source | Is there an inventory of libraries and licences? | Pending / Reviewed |
| Generative AI | Has it been documented whether AI was used to generate any of the code? | Pending / Reviewed |
| Documentation | Is there sufficient technical documentation to maintain the software? | Pending / Reviewed |
| Registration | Would it be advisable to register a key version of the software? | Pending / Reviewed |
| Due diligence | Can the company demonstrate the full chain of ownership? | Pending / Reviewed |
How does the use of open source software affect IP ownership?
Using open source libraries is standard practice in any technology project. The issue is not using open source itself, but failing to know what is being used and under what conditions.
Some licences are permissive and allow broad use, including commercial use. Others impose obligations regarding attribution, publication of modifications, or distribution under the same licence. For a company operating as a SaaS, marketplace, fintech, healthtech or digital platform, a poorly managed dependency can create problems in client contracts, security audits, due diligence processes or company sale transactions.
The company should maintain an up-to-date inventory of dependencies, review licences, and document which components are proprietary, which are third-party, and which are subject to specific obligations.
What happens if an employee develops code outside working hours?
The answer depends on the facts. If the software was created outside working hours, using the employee's own resources, without instructions from the company, and for a project unrelated to the employee's role, it will be more difficult for the company to argue that the exploitation rights belong to it.
By contrast, if the development is related to the employee's functions, was carried out pursuant to the employer's instructions, makes use of corporate resources, or is integrated into the company's products, the company's position will be considerably stronger.
To avoid disputes, it is advisable to set out the following in writing:
| Situation | Recommendation |
|---|---|
| Employee's personal projects | Declare them and keep them clearly separate from the company's work. |
| Use of corporate equipment | Prohibit or restrict external development activity on company devices and accounts. |
| Personal repositories | Prevent corporate code from being hosted in personal accounts. |
| Related side projects | Require prior notification when such projects may compete with or overlap the company's activities. |
| Internal inventions or developments | Document instructions, tasks and deliverables. |
What should a company check before purchasing software or commissioning custom development?
Before paying for any significant development project, a company needs to understand whether it is acquiring a usage licence, an assignment of rights, or a development service with code delivery. These are distinct legal arrangements with very different consequences.
| Model | What the company receives | Risk if not clearly defined |
|---|---|---|
| Usage licence | Right to use the software under specified conditions | The company may be unable to modify, resell or sublicence the software. |
| Custom development without clear assignment | A functional deliverable | The supplier may retain significant rights over the code. |
| Development with rights assignment | Agreed exploitation rights | This is the most appropriate model when the software will be a strategic asset. |
| External SaaS | Access to a service | The company does not acquire the underlying code, it simply uses the platform. |
| Purchase of a technology asset | Code, documentation, rights and warranties | Requires legal and technical due diligence. |
Common mistakes to avoid
- Assuming that paying an invoice automatically transfers all rights over the code.
- Engaging freelancers without an intellectual property assignment clause.
- Using personal repositories for corporate projects.
- Failing to regulate what happens when a technical shareholder leaves the company.
- Not maintaining an inventory of open-source libraries in use.
- Failing to document code created before the company was incorporated.
- Mixing code from clients, previous projects or templates without proper authorisation.
- Not reviewing contracts prior to an investment round or sale.
Legal recommendations for technology companies
To secure ownership of software, the company should adopt a straightforward and consistent internal policy:
- Employment contracts with clearly defined technical responsibilities.
- Specific intellectual property clauses for developers, product managers, technical designers and any roles involved in creating functional documentation.
- Commercial contracts with express assignment of rights for freelancers, agencies and consultants.
- A shareholders' agreement governing software contributions and founder exit arrangements.
- Corporate repositories with access controls.
- An inventory of open-source dependencies.
- A review procedure for the use of generative AI in code development.
- Version control for relevant releases where this serves an evidentiary purpose.
- Legal due diligence prior to funding rounds, acquisitions, strategic licensing or integration with major clients.
Conclusion
Software can be one of a company's most valuable assets, yet its ownership should never be taken for granted. The legal default is favourable for software created by salaried employees within the scope of their duties, but the main risks arise in less clearly defined areas: freelancers, agencies, co-founders, personal repositories, third-party libraries and developments that pre-date the incorporation of the company.
A company that properly documents the chain of code ownership gains the security it needs to operate, sell, license, raise investment and defend its product against third-party claims.
At Conesa Legal, we review employment contracts, commercial contracts, shareholders' agreements and intellectual property documentation for technology companies, start-ups and businesses that develop their own software.
Tell us about your situation and we will assess whether your software ownership is properly protected.
Frequently asked questions about software intellectual property
Does software automatically belong to the company if it is created by an employee?
Where a salaried employee creates a programme in the course of their duties or following the employer's instructions, the exploitation rights vest exclusively in the employer, unless otherwise agreed. That said, it is advisable for the employment contract to regulate this expressly.
Does a freelancer's invoice prove that the code belongs to the company?
Not necessarily. An invoice proves payment, but not always a full assignment of exploitation rights. To avoid any ambiguity, the contract must specify which rights are being assigned, the scope of that assignment, the duration, and the territory covered.
Can the company modify code developed by an external supplier?
Only if it holds sufficient rights to do so. Modifying software forms part of the exploitation rights governed by the Intellectual Property Act, and must therefore be expressly covered by contract when the development is carried out by a third party.
Is it worth registering software?
It may be advisable for significant versions, particularly where the software is a strategic asset. Registration serves as useful evidence, but it is not a substitute for well-drafted contracts or a clear chain of rights assignment.
What if a founder shareholder coded the MVP before the company was incorporated?
An assignment or contribution of the software in favour of the company must be properly documented. Without this step, there may be genuine doubt as to whether the company is the true owner of the code.
Does the use of open-source code prevent the software from belonging to the company?
Not necessarily. It depends on the applicable licence. The key is to maintain an inventory of the libraries used, review their terms and conditions, and verify that they are compatible with the business model.
What intellectual property documentation do investors typically request regarding software?
Investors will generally review employment contracts, freelancer assignment agreements, shareholders' agreements, repository ownership, open-source licences, technical documentation, version history, and any third-party claims.
Key legal sources
- Royal Legislative Decree 1/1996, of 12 April, Consolidated Text of the Intellectual Property Act.
- Articles 43, 51, 95, 96, 97, 99, 100, 101 and 102 of the Intellectual Property Act.
- Directive 2009/24/EC on the legal protection of computer programs.
Lawyers specialising in software intellectual property protection and code assignment agreements
-
If your startup, SaaS or development agency is unclear about who owns the code, the best time to address it is before your next funding round, your next enterprise contract, or the departure of a key developer.
At Conesa Legal we can help you:
- draft software development contracts, freelancer agreements, agency contracts and intellectual property assignment clauses tailored to your business model;
- review employee, freelancer and agency contracts to ensure watertight assignment of rights over the source code;
- prepare a software due diligence review ahead of an investment, company sale or the admission of new shareholders;
- audit open-source risks, repositories and third-party contributions;
- design the legal and evidentiary strategy for disputes involving code copying, founder departures or software misappropriation.
- negotiate and formalise contracts to recover ownership of the product
