You paid for the extension. That does not mean you own it. Under UK law the developer keeps the copyright unless the contract says otherwise, and plenty of partner contracts say otherwise in their own favour. What that means when you want to leave, what to ask for before you sign, and why the IP should belong to the business that paid for it.
Here is the mistake, and it is a common one. A business commissions a partner to build an extension: a pricing engine, an integration, a set of reports. The business pays the invoices. Three years later it wants to change partner, or have someone else maintain the code, or sell the company, and discovers that the contract it signed says the intellectual property belongs to the partner. The business has a licence to use the code, on the partner's terms, and nothing more.
In my mind, the IP always belongs to the business that paid for the work. That is not what the law says by default, and it is not what many partner contracts say. So it has to be said, in writing, before the work starts. A note before we go on: this is a practical guide from someone who has sat on both sides of these contracts, not legal advice; for anything you are about to sign, use a lawyer.
In the UK, under the Copyright, Designs and Patents Act 1988, the first owner of copyright in software is the person who wrote it, or their employer if they wrote it in the course of employment. A commissioning business that pays for software does not own the copyright just by paying for it. Unless there is a written assignment, the partner (as the developer's employer) owns the code, and the business has, at best, an implied licence to use it for the purpose it was commissioned for.
That surprises most people. It means that the default position, absent a clause, is the one you do not want. The contract has to fix it.
Three patterns, roughly in order of how often we see them:
In the NAV days the code was in your database, in a licence file that was yours, and the practical question of ownership rarely bit. With extensions the code is a separate app, built from a source repository, with a publisher name and an app ID in app.json. Whoever holds the source and the publisher identity controls whether the app can be rebuilt, updated for the next release wave, or handed to someone else. An extension you cannot rebuild is an extension that breaks at the next release wave with nobody to fix it, and in Business Central online that is a six-month countdown.
It also matters because of what the extension is. It encodes how your business works: your pricing, your processes, your integrations. That is your know-how, written in AL. It is strange for it to belong to someone else.
An IP clause is only worth what comes with it. Owning the copyright to code you do not have a copy of is a right you cannot exercise. So ownership has to be accompanied by:
publisher in app.json is your company name, and the app ID is one you keep a record of. An app published under the partner's name can only be updated by apps published under the partner's name.Partners have reusable code: libraries, frameworks, integration components they have built over years and bring to every project. It is reasonable for them to keep ownership of that, and unreasonable to ask them to assign it. What is reasonable to ask is a perpetual, irrevocable, royalty-free licence to use it as part of your extension, including the right to have a third party maintain it. The line between "the partner's library" and "your bespoke code" should be drawn in the contract, by name, so there is no argument later about which bits you own.
The partner may also want to reuse ideas from your project elsewhere. That is normal; what you own is the code and the specific design, not the general approach. A clause that lets them reuse non-confidential know-how while assigning you the deliverables is a fair trade.
If what you are buying is an ISV's product from AppSource, you are buying a subscription licence to their product, and you do not own it or expect to. That is the right model for a product used by hundreds of customers. The question only arises when the app was built for you. The grey area is the partner who builds something for you and then productises it: if that is the plan, agree it up front, with terms that reflect that you funded the first version.
Ownership on paper is only half of it. The other half is custody: where the source code physically sits, who administers that, and whether it is current. When you work with a partner, where the code lives is up to you, and you should make it part of the negotiation rather than an afterthought. Partners will usually prefer it in their repository, because that is where their developers already work and their pipelines already run. Our advice is the opposite: the code goes in a repository you own, and the partner commits and syncs to it.
The reason is simple. If anything goes wrong (the partner is acquired, folds, loses the developer who knew your system, or the relationship ends badly) the code is already in your safekeeping. You do not have to ask for it, wait for it, or negotiate for it. Moving to a new partner is a matter of giving them access. If the code is in the partner's repository, every one of those situations starts with a request to someone who may no longer have a reason to help you.
It also makes the custody your responsibility, which is the right place for it. Specifically:
Partners who are used to working this way will not blink; it is how the AL-Go pipeline is designed to work. A partner who resists it is telling you something about how they see the relationship, and that is worth knowing before you sign.
app.json? (Ours.)If the answers are not these, you can negotiate, or you can accept the partner's position with your eyes open. Some businesses do, for a lower price or a product they want to share in. That is a legitimate choice. The mistake is not knowing you have made it.
Read the contract. If it is pattern 1 or silence, ask the partner for an assignment now, while the relationship is good; most will agree to one for existing work, sometimes for a fee, because refusing it is a bad look. Get the source into your repository regardless. And when the contract renews, fix the clause. The worst time to discover you do not own your extension is during a partner dispute or a sale process, and both of those are when it comes up.
Our position is simple and it is in our terms: the business that pays for the work owns it, the source lives in the customer's repository from the first commit, the publisher is the customer, and on the day we part company everything is already in your hands. If you would like a second pair of eyes on a development contract before you sign it, that is part of what CIO and CTO as a service is for, or just ask.