Can I sell a video game built with open source code?

Open source does not mean “no owner”

Although in development practice there is a certain tendency to equate “open source” with “free to use” or even with “no restrictions at all”, from the standpoint of intellectual property law that premise is incorrect.

Open source software is not ownerless, nor does it sit outside the system of exclusive rights: it remains a protected work, in respect of which its authors or rightholders grant an authorisation to use, modify and distribute it subject to conditions. The question, therefore, is not whether open source “can be used”, but on what legal terms it can be integrated into a video game and what effects it produces on the game's exploitation and ownership.

It is also worth clearing up another common confusion, the one that equates open source with the public domain. A work in the public domain has lost its exclusivity and can be used without anyone's permission. An open source program is fully protected, and what exists is a licence, that is, an authorisation with conditions that its holder can enforce. The difference is not terminological: it determines whether you have obligations or you do not.

What exactly the law protects

To answer the question we must start from the legal regime applicable to computer programs under Spanish and European law. In Spain, the Spanish Intellectual Property Act (Ley de Propiedad Intelectual, Real Decreto Legislativo 1/1996) devotes Title VII (Articles 95 to 104) to this subject, and at the European level protection is articulated, among other instruments, through Directive 2009/24/EC on the legal protection of computer programs.

Three provisions pin down what matters here:

• Article 96 provides that computer programs are protected as literary works, and specifies something often overlooked: protection covers the program both in source code and in object code form. In other words, distributing only the executable does not take the matter outside the scope of the law.
• Article 99 lists the exploitation rights, which include reproduction, translation, adaptation, arrangement or any other transformation of the program, and distribution to the public of the original or of copies.
• Article 102 classifies as an infringement any reproduction, translation, adaptation or transformation carried out without authorisation.

The essential consequence is clear: the pre-existing source code you start from remains protected, and reusing it does not amount to an appropriation of ownership, but to the exercise of a right granted by licence.

Two planes that get mixed up: exploitation and ownership

This forces us to distinguish two planes that overlap in many conversations:

• On the one hand, the commercial exploitation of the video game.
• On the other, the legal ownership of the developed result.

As regards exploitation, the general answer is yes, in principle you can commercialise a video game that starts from open source code, even obtaining a direct economic return through sales, licences, platform distribution or indirect monetisation.

That said, this possibility does not exist “with total freedom” in the strict legal sense, because it does not derive from an original right of yours over the whole of the code, but from the framework of authorisation drawn by the applicable open source licence.

Here the licence is the axis of the analysis, because it defines the perimeter of legitimate use. And it is worth stressing that this perimeter is not set by a generic label (“this is open source”) but by the specific text of the specific licence that accompanied that specific component. Two libraries equally described as open source may impose radically different obligations.

Permissive licences: MIT, BSD and Apache

If the licence is a permissive one (such as MIT, BSD or Apache), the system normally lets you use, modify and integrate that code into a commercial product without any obligation to publish the rest of your source code, provided you comply with the burdens the licence imposes.

Those burdens usually consist of:

• preserving copyright notices;
• including the licence text;
• keeping the warranty disclaimers;
• and, in certain cases, including notices or warnings relating to modifications.

These are obligations that are simple to comply with, and precisely for that reason they get neglected. In a video game the usual way to discharge them is a credits screen or a “third-party licences” section accessible from the options menu, reproducing the notices and licence texts of each component. It is not a decorative formality: it is the material performance of the only consideration those licences demand.

In this scenario, commercialising the video game is legally compatible with a proprietary model, but one thing should be made clear: it is not an original and unlimited freedom, but a derived and conditioned freedom. You can exploit the video game because the original owner of the code has authorised you to do so on certain terms. If you breach those terms, the use ceases to be covered by the licence and can be recast as an infringement of intellectual property rights.

Copyleft licences: GPL and its variants

By contrast, if the base code is subject to copyleft licences (for example the GPL and, depending on the case, other equivalent variants), the situation changes structurally.

In those cases, the use, modification and integration of the code may be subject to more intense obligations, such as the need to redistribute the source code of the derivative work or to keep the same licence on certain parts of the distributed product.

In other words: commercialisation is not necessarily prevented, but the way the video game can reach the market, and the degree of closure or exclusive appropriation you can claim over its code, are severely conditioned.

Within copyleft itself there are degrees, and the difference is economically significant. Strong copyleft licences tend to project their obligations onto the distributed product as a whole. Weak copyleft licences (of the LGPL or MPL type) usually confine the obligation to the affected component and its modifications, allowing the rest of the game to remain closed. Determining which of the two scenarios you are in is not a matter of labels, but of analysing how that component has been technically integrated into your product.

A practical note for studios: this is why the engine you choose conditions everything else. Proprietary engines are governed by their own licence agreements, with their own obligations (which is a different analysis altogether), while engines published under permissive licences shift the problem to the libraries and dependencies you keep adding on top. The risk rarely lies in the engine: it lies in the dozens of dependencies that enter the project without anyone writing them down anywhere.

Who really owns the code of your video game

The second big question is ownership. And here the answer must be stated with precision: yes, you own your original contribution to the video game, but you are not, merely by developing the final product, the sole owner of all the code if it grew out of pre-existing open source code.

This is because copyright does not reward assembly as if it extinguished earlier rights. If your video game incorporates or transforms pre-existing code, the original author retains their rights over that base code, while you acquire rights over the original elements you have created or added. Strictly speaking, therefore, there is no absorption of ownership, but a superposition or concurrence of layers of rights over different components of the same digital product.

The law says so expressly

This is not an academic construction: it follows from the statutory text. Article 99 of the Spanish Intellectual Property Act, when listing the acts subject to authorisation, includes the transformation of the program «sin perjuicio de los derechos de la persona que transforme el programa de ordenador» (without prejudice to the rights of the person who transforms the computer program). The statute itself acknowledges, in the same sentence, that the person who transforms acquires rights and that the original owner retains theirs. That is exactly the superposition of layers we are talking about.

Put in more legal terms: using open source does not make you the owner of the pre-existing code, but a licensee of it. You are the author (and where applicable the owner, absent employment or contractual assignments) of the new parts that meet the originality requirement, but the original code still belongs to its initial authors or rightholders.

That is why, when a video game is “born” from open source, the correct statement is not that “all the code is mine”, but that the video game combines the developer's own elements, owned by the developer at origin, with pre-existing elements exploited under a third-party licence.

One more layer: the code your employees write

A further nuance is worth adding, one that in practice causes as many problems as the previous point. Article 97 of the Spanish Intellectual Property Act provides that, when a salaried employee creates a computer program in the course of their duties, the exploitation rights belong to the employer, unless otherwise agreed.

For a studio this is usually good news as far as its staff are concerned, but it has two readings worth bearing in mind. The first is that this rule is designed for the employment relationship, so with external collaborators, freelancers or contractors ownership does not transfer by itself: an express written assignment is required. The second is that this assignment, where it exists, cannot reach further than what the assignor had. If the freelancer integrated an open source component into their delivery, what they assign to you is their contribution, not the ownership of the third-party component.

Why this affects your commercial pitch

This point is essential because it directly affects the studio's commercial and documentary discourse. If a developer presents the video game as though its entire code base were exclusively their own creation, they may be making a legally inaccurate, and even problematic, statement if they omit the attribution or licensing obligations imposed by the open source base used.

And this stops being theoretical at two very specific moments: when you sign a publishing agreement in which you represent and warrant that you own all the material delivered, and when an investor comes in and commissions a legal review of the studio. In both cases someone is going to read that representation with a magnifying glass, and an inaccurate statement about ownership can trigger the indemnity clauses you yourself have signed.

Derivative work: how far the classification goes

From a doctrinal standpoint, the scenario is usually channelled through the concept of a derivative work or, at the very least, a creation that incorporates protected pre-existing elements. The intensity of that classification will depend on the degree of incorporation, transformation and dependence on the original code.

But even without entering into overly technical debates about interoperability, linking or modularity, one idea remains constant: when the new development derives from an identifiable and protected open source base, the later creation does not neutralise the earlier ownership.

What the courts have said

For years there was debate over something that is now settled: whether breaching a software licence is only a breach of contract or whether it also allows the remedies specific to intellectual property infringement to be pursued. The difference is not academic, because the available interim measures, the rules for calculating damages and the procedural strategy itself all depend on it.

Judgment of the Court of Justice of the European Union of 18 December 2019 (Case C-666/18, IT Development v Free Mobile). The Court ruled that the breach of a clause in a licence agreement relating to intellectual property rights (in that case, the modification of the source code by the licensee) falls within the concept of infringement for the purposes of Directive 2004/48 on the enforcement of intellectual property rights. In short: the rightholder can turn to the reinforced regime of intellectual property protection, and not only to the contractual breach route.

Judgment of the Cour d'appel de Paris of 14 February 2024 (Entr'ouvert v Orange). This is the European decision that best illustrates the real cost of these breaches. Orange had integrated the Lasso library, distributed under GNU GPL version 2, into an identity management platform it commercialised without complying with the licence conditions. After proceedings lasting more than twelve years, the court found copyright infringement and awarded damages of 800,000 euros (500,000 for the economic harm, 150,000 for the profits obtained by the defendant companies and 150,000 for moral damage), plus 60,000 euros in procedural costs.

These are not Spanish decisions, but the first is doctrine of the Court of Justice and binds the interpretation of the rules applicable in Spain, and the second shows how that criterion is being applied in a Member State. The takeaway for a studio is direct: the idea that “at worst they will make me comply with the licence” no longer holds.

What happens if you breach the licence

In practical terms, all of the above translates into three relevant consequences.

The first is that you can be the author of the video game as regards its design, specific mechanics, narrative, art, music, levels, interface, additional code and original structure developed by you, but that does not eliminate third-party ownership of the open source base used. Authorship of your contribution and the existence of prior rights over the starting material are perfectly compatible.

The second is that your right to exploit the game is conditioned by the licence of the open source component, not only during development, but also at the moment of distribution. True risk control is not exhausted by “having been able to use the code”, but consists in verifying whether the way the game is released to the market complies with every requirement of the licensing regime.

The third is that, if the open source component used was subject to formal or material obligations and you do not comply with them, the problem is not merely reputational or documentary. The breach can open the door to cease-and-desist actions, demands to regularise, enforcement of the licence and even claims for damages, depending on the case and the jurisdiction involved.

There is also an effect that tends to go unnoticed and that is particularly onerous in a video game: a good number of these licences provide that a breach terminates the authorisation granted. If the licence lapses, any subsequent use loses its legal cover, and that reaches a product that is already published, sold and being updated. The cost is not that of redrafting a clause, but that of rebuilding or withdrawing part of the game with the title already on the market.

What is coming: the Cyber Resilience Act

An obligation of a different nature, but pointing in the same direction, is soon going to be added to this analysis: knowing exactly what is inside your product.

Regulation (EU) 2024/2847, known as the Cyber Resilience Act, lays down cybersecurity requirements for products with digital elements placed on the market in the European Union, a category into which consumer software falls. It entered into force in December 2024, the vulnerability notification obligations apply from September 2026 and the bulk of the regime from 11 December 2027.

What matters here is twofold. On the one hand, the Regulation introduces the figure of the open-source steward, with a lighter set of obligations than the manufacturer's, and leaves out free software developed outside a commercial activity. On the other, and this does squarely affect any studio that publishes, compliance requires documenting the components the product integrates and managing their vulnerabilities over time.

Put another way: the inventory of third-party components, which until now was an advisable good practice to avoid breaching licences, is on its way to also becoming a regulatory requirement. Whoever has it done for intellectual property reasons will arrive with half the work already finished.

Checks before you launch

Since the risk is concentrated at distribution, it is worth reviewing each channel and each delivery before launch:

• Steam, consoles and mobile: each store imposes its own terms, which stack on top of those of the open source licence.
• Publishing binaries: distributing the executable is already an act of distribution for licence purposes, even if you do not publish the repository. Remember that Article 96 protects the program both in source code and in object code.
• Updates and patches: every subsequent delivery re-triggers the obligations.
• Bundled SDKs: the third-party kits you package with the game carry their own licences with them.
• Shared repositories: what you share with publishers, porting partners or other collaborators also counts.
• Component inventory: a living list of every library, its version and its licence. It is the only way to answer a legal review within a day, and it will soon be a regulatory matter as well.

In short, the legally correct formulation would be this: yes, a video game built on open source can be commercialised, even for profit, provided the licence governing the base code allows it and its conditions are complied with in full. But it cannot rigorously be claimed that the developer is the sole owner of the video game's code when it incorporates or derives from pre-existing open source code, since ownership of that original code remains with its authors, coexisting with the developer's rights over their original contribution.

Or, put even more plainly:

• Yes, you can sell it.
• Yes, you can own what you have created.
• You are not automatically the exclusive owner of all the code.
• You do not have absolute freedom outside the licence of the open source you started from.

The legal key, therefore, lies not in whether the video game is “born” from open source, but in which licence governed that pre-existing material, what part of the final result actually comes from it, and which obligations survive into the commercialisation of the final product.

Frequently asked questions

Sources

• Real Decreto Legislativo 1/1996, consolidated text of the Spanish Intellectual Property Act (BOE)
• Directive 2009/24/EC on the legal protection of computer programs (EUR-Lex)
• Judgment of the CJEU of 18 December 2019, Case C-666/18, IT Development v Free Mobile (EUR-Lex)
• Cour d'appel de Paris, pôle 5 ch. 1, judgment of 14 February 2024, Entr'ouvert v Orange (Legalis)
• Regulation (EU) 2024/2847, the Cyber Resilience Act (EUR-Lex)
• Licences approved by the Open Source Initiative
• GNU General Public License v3.0