Who owns the software your grant paid for?

The question almost always arrives late. A grant is approved, a supplier is chosen, development starts, and somewhere around the first invoice someone in finance or legal asks who will actually own the thing being built. By then the contract is signed, and the answer is whatever it happens to say.

At Brilean, we've been on the supplier side of that conversation many times, on projects funded through PRR, Portugal 2030 and other programmes. We're also an accredited supplier under FIERCE, currently delivering projects from its first open call, so we see the question come up with applicants every time a new call opens. It always goes much better at the quotation stage. So here's how we think about it, and what we'd ask if we were sitting on your side of the table.

Why ownership matters more when the money is public

In a funded project, three parties care about the answer, and each wants something different. That's true whether the money comes from Horizon Europe, the EIC, a national recovery-plan instrument or a cascade-funding call like FIERCE.

• The funding body wants evidence that the results will actually be used. Most programmes come with exploitation obligations, and some restrict what you can do with the results without asking first.
• You, the beneficiary, want freedom. You want to keep developing the product, bring in another team later, raise money or sell the company without someone else's name on the code.
• The supplier wants to keep the general-purpose tools and know-how it brings to every project.

None of these is unreasonable. The trouble starts when nobody writes them down properly.

Three ways to settle who owns the software

1. The supplier keeps everything and licenses you nothing beyond use

This is the position behind most off-the-shelf arrangements, and it's usually wrong for a funded project. If you can't modify the software, extend it or hire someone else to maintain it, you're not exploiting a result. You're renting one. Very few programmes will see that as a good outcome for public money.

2. The supplier keeps title and grants you a perpetual licence

This is our default for commercial work. The client gets a perpetual, worldwide, irrevocable right to use, commercially exploit and further develop the solution, with no user limits and no royalties. We keep title to the source code and to the reusable components inside it.

That second part isn't a trick. A studio that has built forty products carries libraries, infrastructure modules and patterns that make the forty-first faster and cheaper. If every client took title to all of it, that capability would disappear, and every client after the first would pay to rebuild what already existed.

For many funded projects this model works well, as long as the licence is broad enough for what the programme expects of you. Check three things: that it covers commercial exploitation, that a third party can modify the code on your behalf, and that the licence moves with the product if you sell it.

3. Full assignment to the client

Everything produced in the project is assigned to you outright, worldwide and irrevocably. This is the right answer more often in funded projects than in commercial ones, and sometimes it's the only answer the programme will accept.

When full assignment is the right call

Check the grant agreement before you negotiate with anyone. Programmes differ a lot in what they require, and the differences matter.

Under Horizon Europe, for example, results generally belong to the beneficiary that generates them. When a subcontractor does the work, the beneficiary is expected to secure whatever rights it needs to meet its own obligations. In practice, that often points to assignment.

We'd also lean towards assignment when:

• the software is the product itself, not a tool around it
• you plan to raise investment, because investors will check who owns the code
• the programme asks you to publish results under an open licence, which you can only do with code you own
• the funding body has to approve any transfer of results, and you want a clean chain from day one

Even with full assignment, a good contract keeps one thing back. The supplier's pre-existing tools stay with the supplier, and you get a licence to use them as part of what was delivered. That's normal, and it's a big part of what keeps the price reasonable.

Background and results: the distinction that saves arguments

Most disputes we've seen come from mixing up two things. Background is what each party already had before the project started: libraries, frameworks, internal tools, know-how. Results are what the project produces.

Ownership of results is a choice you make in the contract. Background normally stays with whoever brought it. The trick is to list the background in an annex at the start, so nobody has to argue about it two years later.

What to put in the contract

Whichever model you choose, these points should be written down:

• who owns the results, in one plain sentence
• what background the supplier brings, listed in an annex
• the licence you get to that background: scope, duration, territory and whether it can be transferred
• when and how you receive the source code, and access to the repository
• what happens if the relationship ends: handover, documentation and a reasonable transition period
• which open-source components are used, and under which licences
• whether the funding body needs to approve a transfer or licence of the results

Before you sign

1. Read the IP and exploitation sections of your grant agreement. All of them.
2. Decide which of the three models you need, and be able to say why.
3. Ask the supplier to state the model in the quotation, not only in the contract.
4. Make sure the background list exists and actually means something.
5. If the amounts or the stakes are high, get a lawyer to review it.

How we handle it at Brilean

We'd rather settle ownership before anyone writes a line of code. On funded projects, that means:

• the IP model is stated in our quotation, in plain words, before there's a contract to sign
• our background, the libraries and tools we bring, is listed in an annex, so you know exactly what stays with us
• if the programme requires full assignment, we assign; if a licence serves you better, we explain why and put it in writing
• we're already delivering FIERCE-funded work, so we know what the programme expects from the technology side, both in the application and in the project itself

If you're about to start a funded project and nobody has raised the ownership question yet, raise it now. It's a ten-minute conversation at the quotation stage and a very long one six months later. FIERCE's second open call is open until 9 November 2026. If you're preparing an application, or planning a project under PRR or Portugal 2030, and want a technical partner who has done this before, we're always happy to talk.

This article reflects our experience as a supplier on funded projects. It isn't legal advice, and the grant agreement you signed always has the final word.

‍