Civil Law and Software Source Code Ownership Disputes in Europe

1. Meaning

Software source-code ownership disputes arise when two or more persons or organisations claim the legal right to control, use, modify, license, sell, reproduce or transfer software source code.

Typical disputes involve:

employee vs employer;

software developer vs customer;

contractor vs commissioning company;

founder vs company;

joint developers;

parent company vs subsidiary;

licensor vs licensee;

purchaser vs vendor;

software company vs former employee;

open-source contributor vs commercial user;

acquisition of a software business;

source-code escrow arrangements.

The central question is usually:

Who legally owns the copyright in the source code, and what rights were actually transferred or licensed?

European law is particularly important because computer programs receive harmonised copyright protection under Directive 2009/24/EC on the legal protection of computer programs. The CJEU confirms that both source code and object code are protected forms of expression of a computer program. (EUR-Lex) 

2. Important Preliminary Point: Source Code Is Not Automatically Owned by the Person Who Possesses It

There is an important distinction between:

Possession

A company has the source code stored on its server.

Ownership

The company legally owns the copyright.

Licence

The company has permission to use the software but does not own the copyright.

Assignment

The copyright has been transferred to another person/company.

Source-code escrow

A customer may receive access to source code upon specified events, but this does not necessarily mean ownership has transferred.

Therefore:

Possession of source code ≠ ownership of copyright.

This distinction is frequently decisive in litigation.

3. Main Legal Framework

European software ownership disputes are primarily governed by:

Directive 2009/24/EC — legal protection of computer programs;

national copyright law;

national contract law;

employment law;

intellectual-property assignment rules;

trade-secret/confidentiality law;

licensing agreements;

company/shareholder agreements;

source-code escrow agreements;

EU enforcement rules under Directive 2004/48/EC.

The CJEU has consistently treated computer-program protection as copyright protection directed at the expression of the program, rather than its underlying ideas or functionality. (EUR-Lex)

4. What Exactly Can Be Owned?

A software project may contain several legally different assets.

This distinction is essential because a dispute over "the software" may actually contain several different intellectual-property rights.

5. Case Law 1 — Bezpečnostní softwarová asociace v Ministerstvo kultury

C-393/09, CJEU, 22 December 2010

This is one of the foundational European software copyright cases.

The dispute concerned the scope of protection for computer programs and particularly whether a graphical user interface was itself protected under the special software-program directive.

The CJEU explained that source code and object code constitute forms of expression of a computer program and therefore receive copyright protection. (EUR-Lex)

Principle

The copyright protection is directed toward the expression of the computer program, not every element associated with the software.

Ownership significance

When determining ownership, the parties must identify exactly what was created:

source code;

object code;

GUI;

documentation;

underlying ideas.

Example

Developer A writes the source code.

Company B designs the GUI.

Company C provides the underlying business idea.

It cannot automatically be assumed that all three own the same copyright.

6. Case Law 2 — SAS Institute Inc. v World Programming Ltd

C-406/10, CJEU Grand Chamber, 2 May 2012

This is perhaps the most important European authority for understanding the scope of source-code ownership.

SAS claimed copyright infringement after World Programming created software capable of reproducing the functionality of SAS software.

The CJEU held that:

functionality is not protected as such by the software copyright directive;

programming language is not protected as such;

data-file formats used to exploit functions are not, merely for that reason, protected as software expression;

studying, observing and testing a lawfully acquired program to determine its ideas and principles can be permissible within the statutory conditions. (EUR-Lex)

Crucial distinction

Source code → protected expression

Functionality → generally not protected by software copyright

Ownership significance

Owning source-code copyright does not give a company an unlimited monopoly over:

"what the software does."

Another developer may sometimes create a competing program with similar functionality without infringing the copyright, provided protected expression is not improperly copied.

Exam principle

Copyright protects code, not the underlying technological idea or functionality as such.

7. Case Law 3 — UsedSoft GmbH v Oracle International Corp.

C-128/11, CJEU Grand Chamber, 3 July 2012

This case concerned the resale of software licences.

The CJEU held that, under specified circumstances, the copyright holder's distribution right in a copy of software can become exhausted after the copyright holder has authorised downloading of the copy for an unlimited period in return for remuneration corresponding to the economic value of the copy. (EUR-Lex)

Ownership significance

UsedSoft demonstrates the difference between:

ownership of copyright;

ownership of a particular copy;

licence rights;

right of distribution.

A purchaser of software does not automatically become copyright owner merely because it has paid for the software.

Example

Company A buys perpetual software rights from Developer B.

Company A may obtain extensive usage rights.

But:

Company A does not automatically acquire B's underlying copyright.

8. Case Law 4 — IT Development SAS v Free Mobile SAS

C-666/18, CJEU, 18 December 2019

This case concerned software licensed to Free Mobile.

The licensee modified the software in a manner allegedly contrary to the licence agreement.

The important question was whether the dispute should be treated as:

contractual liability; or

copyright infringement.

The CJEU held that infringement of a contractual clause concerning intellectual-property rights can fall within the concept of infringement of intellectual-property rights under Directive 2004/48. National law may determine whether the claim is pursued contractually or in tort, but the EU enforcement requirements must still be respected. (EUR-Lex)

Ownership significance

A licence agreement can significantly determine:

modification rights;

reproduction rights;

adaptation;

reverse engineering;

sublicensing;

source-code access.

Key principle

A software licence does not transfer ownership merely because it grants extensive rights of use.

9. Case Law 5 — Top System SA v État belge

C-13/20, CJEU, 6 October 2021

This case involved decompilation of software.

The CJEU confirmed that source and object code are protected forms of expression and that decompilation involves acts affecting the copyright owner's exclusive rights.

However, a lawful purchaser can decompile software where the statutory requirements for correction of errors are satisfied. (EUR-Lex)

Principle

The owner has strong control over:

reproduction;

alteration;

translation/decompilation;

distribution.

But those rights are not absolute.

Ownership significance

A customer may lawfully access or decompile software in certain circumstances without becoming the owner of the source code.

Therefore:

Lawful access ≠ ownership.

10. Case Law 6 — Penhallurick v MD5 Ltd

[2021] EWCA Civ 1770, Court of Appeal of England and Wales

This is a particularly valuable UK/common-law comparison because it directly concerned ownership of copyright in software created by an employee.

Michael Penhallurick developed software underlying a forensic-computer examination tool.

He later claimed copyright ownership.

MD5 argued that the copyright belonged to the company because the software had been created during his employment, alternatively that copyright had been transferred by a later agreement.

The Court of Appeal dealt directly with the issue of first ownership and the contractual transfer of copyright. (Bailii)

Principle

Employee-created software requires careful examination of:

employment duties;

circumstances of creation;

contractual arrangements;

timing;

assignment documents.

Importance

This is extremely useful for disputes involving:

employee + software development + ownership.

UK distinction

Under UK law, the statutory employment rule can make the employer first owner where a qualifying work is made by an employee in the course of employment, subject to agreement to the contrary.

That is a UK statutory rule, not an automatic European-wide rule.

11. Case Law 7 — PQ Systems Europe Ltd v Aughton

[2023] EWHC 581 (Pat)

This case concerned software developed by an employee and a dispute over whether the employer or individual developer owned the copyright.

The court considered the statutory rule under UK copyright law that where a qualifying work is made by an employee in the course of employment, the employer is ordinarily the first owner, subject to agreement otherwise. The case specifically examined whether the software was within the employee's employment duties and whether it was created in the course of employment. (Bailii)

Principle

The key questions are:

Was software development part of the employee's job?

Was the particular software created in the course of that employment?

Was there an agreement changing ownership?

Example

If a software engineer's job is:

"Develop software applications for the company"

software created within that role is much more likely to belong to the employer under the applicable national rule.

But if the employee develops completely unrelated software independently, the ownership analysis can be very different.

12. Case Law 8 — THJ Systems Ltd v Sheridan

[2023] EWHC 927 (Ch)

This case concerned software source code, graphical interfaces and related works.

The court distinguished between:

source code;

GUI;

screenshots/output.

It accepted that copyright subsisted in the source code and identified the relevant author and owner. (Bailii)

Principle

A software dispute should not simply be described as:

"Who owns the software?"

The court should identify each copyright work and its author.

Importance

This is particularly relevant when several developers contribute to:

different files;

different modules;

interfaces;

documentation;

later modifications.

13. Case Law 9 — LZLabs GmbH v IBM UK Ltd

[2025] EWCA Civ 842

This recent UK authority concerns sophisticated software copyright questions involving compiler/translator technology.

The litigation illustrates the distinction between:

protected source/object code;

functionality;

compiler-generated output;

customer-created code.

The Court of Appeal considered arguments concerning whether code generated through a compiler should be treated as protected expression belonging to the compiler developer or as expression attributable to the customer who authored the underlying source code. (Bailii)

Principle

The identity of the copyright owner cannot be determined simply because one company's software generated another company's code.

The court must identify:

Who created the relevant protected expression?

Modern significance

This principle becomes especially important with:

compilers;

code generators;

AI coding systems;

low-code platforms;

automated software development.

14. Case Law 10 — SAS Institute Inc v World Programming Ltd — UK proceedings

After the CJEU judgment, the dispute returned to the UK courts.

The litigation demonstrates that even where EU law establishes that functionality itself is not protected, national courts still have to determine:

what was copied;

what was licensed;

whether protected expression was reproduced;

whether contractual restrictions were breached.

The UK Court of Appeal recognised the CJEU's conclusion that merely studying and testing a lawfully acquired program to reproduce functionality does not necessarily infringe copyright. (Bailii)

Importance

Ownership and infringement must be separated.

A claimant may own copyright but still lose a particular infringement claim because the defendant copied only unprotected functionality.

15. What Does "Ownership" Actually Mean?

Software ownership normally involves a bundle of rights.

Copyright owner may control:

reproduction;

adaptation;

distribution;

licensing;

commercial exploitation;

certain forms of communication;

enforcement against infringement.

But ownership can be divided or transferred.

For example:

Developer → Company

may involve:

copyright assignment.

Or:

Developer → Company

may involve:

exclusive licence.

These are not necessarily the same.

16. Assignment vs Licence

Assignment

Ownership itself is transferred.

Example:

Developer assigns all copyright in the source code to Company.

Company becomes copyright owner, subject to the validity and scope of the assignment.

Licence

The developer remains owner but grants another party permission to use the software.

Example:

Company receives an exclusive 20-year licence to use the source code.

The company may have extensive rights without becoming copyright owner.

Examination distinction

Assignment = transfer of ownership

Licence = permission to use

17. Employee-Developer Disputes

This is one of the most common ownership disputes.

Example

Employee A develops software during employment.

After leaving the company, A claims:

"I wrote the code, therefore I own it."

That statement is incomplete.

The court must examine:

applicable national copyright law;

employment contract;

employee's duties;

place/time of development;

company resources;

whether development was authorised;

assignment provisions;

confidentiality provisions.

The Penhallurick and PQ Systems cases demonstrate why employment circumstances are critical. (Bailii)

18. Contractor vs Customer

Suppose:

Company A hires Developer B to build a logistics platform.

Developer B writes all source code.

The contract says:

"Developer shall provide the software."

Does Company A automatically own copyright?

Not necessarily.

The court must examine:

assignment clause;

licence clause;

governing law;

payment provisions;

delivery provisions;

pre-existing code;

newly developed code;

third-party components.

Best contractual structure

A properly drafted contract should distinguish:

Background IP

from

Foreground IP.

19. Background IP

Background IP means software or technology the developer already owned before the project.

Example:

Developer has an existing authentication library.

Company hires developer to build a banking platform.

The developer incorporates the existing library.

The contract should specify:

Developer retains ownership of background IP.

Company receives an appropriate licence.

20. Foreground IP

Foreground IP means software specifically created during the project.

Example:

Developer writes a completely new payment-processing module specifically for Company.

The agreement may provide:

Company owns the newly created source code.

or:

Developer retains ownership but grants Company an exclusive licence.

Failure to distinguish these categories creates major litigation risk.

21. Joint Development

Two companies may jointly develop software.

Example:

Company A develops backend;

Company B develops AI module;

Company C develops interface.

The dispute may concern whether the resulting product is:

jointly owned;

separately owned;

licensed;

assigned to a joint venture.

Courts need to determine the actual contribution of each author and the contractual arrangements governing those contributions.

The THJ Systems litigation illustrates the importance of identifying individual authors and individual software components. (Bailii)

22. Source-Code Escrow

Source-code escrow is common in major technology contracts.

The developer deposits source code with an escrow agent.

Release may occur if:

developer becomes insolvent;

developer stops supporting the software;

maintenance obligations are seriously breached;

specified contractual conditions occur.

Crucial principle

Escrow release does not automatically transfer copyright ownership.

The customer may receive a contractual right to:

access;

copy;

maintain;

modify;

repair.

The underlying copyright may remain with the developer.

23. Software Acquisition and M&A

Software ownership disputes frequently arise during acquisition.

Company A purchases Company B.

After closing, Company A discovers:

Company B did not actually own some of the source code.

Perhaps:

a former employee retained copyright;

a contractor never assigned copyright;

open-source components were improperly incorporated;

a subsidiary owned the code;

a founder retained rights.

This can create:

breach of warranty;

indemnity claims;

copyright litigation;

valuation disputes;

injunction applications.

24. Open-Source Software

Another complication is open-source code.

A company may claim:

"We own the entire source code."

But some components may be distributed under:

GPL;

LGPL;

MIT;

Apache;

other licences.

The company may own its original code while simultaneously being subject to licence obligations concerning incorporated open-source components.

Therefore:

Ownership ≠ freedom from licence obligations.

25. Trade Secrets and Source Code

Copyright is not the only protection.

Source code may also be a trade secret/confidential information.

A company may therefore have two different claims:

Copyright claim

Unauthorized reproduction of protected code.

Trade-secret claim

Unauthorized acquisition, disclosure or use of confidential source code.

This distinction matters because even material that does not qualify for copyright protection may potentially receive protection through confidentiality/trade-secret law if the relevant conditions are satisfied.

26. Ideas vs Expression

This is one of the most important principles.

Suppose Developer A creates:

"An application that automatically routes trucks to reduce fuel consumption."

That general idea is not equivalent to ownership of the particular source code.

Developer B may potentially create:

another truck-routing application

without infringing A's copyright, provided B does not improperly copy protected expression.

This is consistent with SAS Institute.

The CJEU expressly rejected extending software copyright to functionality because that would risk monopolising ideas and restricting technological development. (EUR-Lex)

27. Modification Disputes

A customer may modify software.

The contract says:

"Customer may use the software but may not modify it."

Customer nevertheless modifies source code.

The owner may have:

contractual claim;

copyright claim;

enforcement claim.

IT Development v Free Mobile is particularly useful here because the CJEU recognised that breach of a software licence provision concerning intellectual-property rights can fall within the EU framework for enforcement of intellectual-property rights. (EUR-Lex)

28. Decompilation

Decompilation converts object code toward source-code form.

Generally, this affects the copyright owner's exclusive rights.

But Top System confirms that a lawful purchaser can decompile software to correct errors within the statutory conditions. (EUR-Lex)

Therefore:

Source-code ownership gives strong rights, but European software copyright contains statutory exceptions.

29. Evidence in Ownership Litigation

Ownership cases are highly evidence-intensive.

Important evidence includes:

Git repositories;

commit histories;

timestamps;

source-code metadata;

employment contracts;

contractor agreements;

assignment deeds;

invoices;

emails;

project specifications;

technical documents;

source-code escrow agreements;

licensing terms;

version histories;

access logs;

server records;

developer notebooks.

Git history can be especially important

It can establish:

who wrote which file → when it was written → whether it pre-dated employment → who modified it later.

This can be decisive in ownership litigation.

30. Burden of Proof

The claimant generally needs to establish:

existence of copyright;

protected work;

authorship/ownership;

chain of title;

defendant's conduct;

infringement or contractual breach;

damage where required.

The defendant may argue:

no ownership;

no valid assignment;

licence;

statutory exception;

independent creation;

functionality rather than protected expression;

limitation;

lack of substantial copying.

31. Remedies

A successful owner may seek:

1. Injunction

Prevent continued use of the source code.

2. Delivery-up/destruction

Removal or destruction of infringing copies where permitted.

3. Damages

Compensation for losses.

4. Account of profits

Recovery based on infringer's profits where national law permits.

5. Declaration of ownership

Court confirms who owns the copyright.

6. Declaration of non-infringement

Useful where the defendant seeks certainty.

7. Preservation of evidence

Important where source code could be deleted or altered.

8. Disclosure

Courts can order production of relevant evidence subject to applicable procedural and confidentiality rules.

32. Civil-Law Approach vs UK/Common-Law Approach

Continental Europe

European civil-law jurisdictions generally determine software ownership through a combination of:

copyright statutes;

employee rules;

contractual assignment;

authorship;

contractual interpretation;

trade-secret law.

The precise ownership rule varies by country.

Important warning

There is no single EU-wide rule saying "the employer always owns employee-created software."

The EU Software Directive harmonises protection of computer programs, but many ownership questions remain governed by national law.

UK/Common Law

UK law has particularly developed case law concerning:

employee-created software;

first ownership;

contractual assignments;

implied terms;

source-code ownership.

Penhallurick v MD5 and PQ Systems v Aughton are useful authorities for this approach. (Bailii)

Key difference

Do not automatically transfer the UK employment rule into France, Germany, Spain, Italy or another civil-law jurisdiction.

The applicable national copyright legislation must be examined.

33. Important Case-Law Table

34. Direct vs Analogical Authorities

For an examination answer, it is important to distinguish them.

Direct European software authorities

Bezpečnostní softwarová asociace

SAS Institute

UsedSoft

IT Development

Top System

These provide the principal EU framework.

Direct ownership authorities

Penhallurick v MD5

PQ Systems v Aughton

THJ Systems v Sheridan

Modern technical authority

LZLabs v IBM UK

The UK authorities should be described as comparative/common-law authorities, not as EU-wide civil-law rules.

35. Hypothetical Example

Facts

Company A hires Developer B to create a smart-port management platform.

B writes:

80% new source code;

10% pre-existing libraries;

10% open-source components.

The contract states only:

"B will develop and deliver the software."

After completion:

B claims ownership.

Company A argues:

"We paid for everything, so we own the code."

Legal analysis

Step 1 — Identify authors

Who actually wrote each part?

Step 2 — Identify background IP

Which libraries did B own before the project?

Step 3 — Identify foreground IP

Which code was created specifically for A?

Step 4 — Interpret contract

Does "deliver" mean:

delivery only;

licence;

assignment?

Step 5 — Examine national law

Which country's copyright rules govern ownership?

Step 6 — Examine open-source components

Were third-party licences complied with?

Step 7 — Determine remedies

If A owns the copyright:

injunction/damages/etc.

If B owns it:

A may still have contractual usage rights depending on the agreement.

36. Another Example — Employee Leaves the Company

Developer A works for Company X.

During employment, A creates software.

A resigns and starts Company Y.

Company X claims:

"The software belongs to us."

A claims:

"I wrote it personally."

The court should examine:

EMPLOYMENT CONTRACT → JOB DUTIES → TIME OF CREATION → PURPOSE → COMPANY RESOURCES → CONTRACTUAL ASSIGNMENT → NATIONAL COPYRIGHT LAW

This is the type of ownership question illustrated by Penhallurick and PQ Systems. (Bailii)

37. Modern AI Coding Problem

The ownership problem becomes more complicated when source code is produced with AI-assisted development.

Possible contributors include:

human developer;

employer;

AI coding tool;

third-party model provider;

open-source training material;

pre-existing libraries.

The key questions become:

Who made the legally relevant creative contribution?

Is the resulting code sufficiently original?

Did the developer have contractual authority?

Did the employer's agreement assign resulting IP?

Does the generated code reproduce third-party protected code?

Are there licence restrictions?

Can the claimant prove chain of title?

The traditional European principles from SAS Institute, Bezpečnostní softwarová asociace and the newer ownership cases remain relevant because the fundamental distinction between protected expression and unprotected ideas/functionality continues to matter. (EUR-Lex)

38. Defences to Ownership Claims

A defendant may argue:

1. No valid copyright

The alleged work does not satisfy applicable originality requirements.

2. Wrong claimant

The claimant is not the copyright owner.

3. No valid chain of title

An alleged assignment is incomplete or defective.

4. Licence

The defendant was authorised to use the software.

5. Employee ownership rule

Under the applicable national law, the employer is the first owner.

6. Independent creation

The defendant created its own code.

7. Functionality only

The defendant copied functionality rather than protected expression.

8. Statutory exception

For example, a permitted decompilation or other statutory use.

9. Contractual permission

The customer's licence expressly permitted modification.

10. Limitation

The claim is brought too late.

39. Key Examination Formula

Ownership dispute

AUTHOR → CREATION → ORIGINALITY → EMPLOYMENT/CONTRACT → ASSIGNMENT → LICENCE → CHAIN OF TITLE → OWNERSHIP

Employee software

EMPLOYEE → JOB DUTIES → COURSE OF EMPLOYMENT → NATIONAL LAW → FIRST OWNER → CONTRACTUAL ASSIGNMENT

Contractor software

CUSTOMER → DEVELOPER → BACKGROUND IP → FOREGROUND IP → ASSIGNMENT/LICENCE → OWNERSHIP

Source-code infringement

PROTECTED CODE → OWNERSHIP → COPYING → SUBSTANTIAL EXPRESSION → AUTHORISATION → INFRINGEMENT → REMEDY

Software functionality

FUNCTIONALITY ≠ SOURCE CODE → IDEAS ≠ EXPRESSION → INDEPENDENT IMPLEMENTATION MAY BE PERMITTED

40. Key Principles for Examination

Source code is protected by copyright as a form of expression of a computer program.

Object code also receives software copyright protection.

Copyright does not automatically protect every idea underlying software.

Functionality is generally not protected by the Software Directive as such.

Programming language and data-file formats are not automatically protected as software expression.

Possession of source code does not establish copyright ownership.

A software licence normally grants rights of use rather than transferring ownership.

An assignment is different from a licence.

Employee-created software is governed substantially by applicable national ownership rules.

There is no single EU-wide rule that every employer automatically owns all employee-created software.

Contractor ownership depends heavily on the contract and applicable national law.

Background IP and newly created foreground IP should be separated.

Source-code escrow normally concerns access and continuity, not necessarily ownership.

Joint development requires identification of individual contributions and contractual rights.

SAS Institute is the leading authority for distinguishing functionality from protected expression.

UsedSoft demonstrates that ownership of a software copy/licence is different from ownership of copyright.

IT Development shows that licence restrictions concerning intellectual-property rights can have copyright-enforcement consequences.

Top System demonstrates that copyright protection has statutory exceptions, including limited decompilation for error correction.

Trade-secret protection may exist alongside copyright.

A proper chain of title is essential in commercial software litigation.

Git records, employment contracts and assignment documents can be critical evidence.

Open-source components may create separate licence obligations even when a company owns its original code.

In acquisitions, software ownership should be independently verified rather than assumed from possession of repositories.

UK cases such as Penhallurick and PQ Systems are useful comparative authorities but should not automatically be treated as the law of continental Europe.

The central legal question is not simply "Who wrote the code?" but "Who is legally entitled to the copyright in the relevant code under the applicable national law and contractual chain of title?"

Conclusion

Software Source Code Ownership Disputes in Europe are principally determined by the interaction of copyright law, national rules on authorship and employee-created works, contracts, assignments and licences. The EU Software Directive establishes the important baseline that source and object code are protected expressions, while functionality and underlying ideas are treated differently. SAS Institute, Bezpečnostní softwarová asociace, UsedSoft, IT Development and Top System establish the principal EU software-copyright framework. For the specific question of who owns employee-created source code, national law becomes critical, with Penhallurick v MD5, PQ Systems v Aughton and THJ Systems v Sheridan providing useful comparative ownership authorities. The safest examination formula is:

AUTHorship → ORIGINALITY → EMPLOYMENT/CONTRACT → ASSIGNMENT → LICENCE → CHAIN OF TITLE → OWNERSHIP → INFRINGEMENT → REMEDY. (EUR-Lex) 