Copyright in software and commissioned work: what to do in the first ten days comes down to three moves: secure evidence of authorship and transfer terms, freeze further distribution of the code, and establish whether the developer acted as an employee or an external contractor. Under Swedish law as it currently stands, that distinction fixes default ownership and shapes every later step.
Who this concerns
This question comes up in three recurring situations. The first is a technology or product company that engaged a freelance developer, a boutique agency, or an offshore team to build a piece of software, a plugin, or a customer-facing app, and never signed anything beyond an invoice and a short scope description. The second is a business that inherited a codebase through an acquisition, a carve-out, or an internal reorganisation, where nobody checked whether the underlying rights ever left the hands of the people who wrote the code. The third is a company facing a dispute that has already started: a departing developer claims the code is theirs, a former agency threatens to license the software to a competitor, or an investor's due diligence team flags a gap in the chain of title during a funding round.
In all three situations, the first ten days matter because early conduct, what gets said, what gets preserved, and what gets changed in the codebase, becomes part of the record later. Waiting to see what happens rarely improves the position; it usually narrows the options.
What the law says
Swedish copyright protection attaches automatically to a work at the moment of creation, without registration and without a formal notice. The person who wrote the code, not the person who paid for it, holds the rights from that moment, unless a specific rule or a specific agreement says otherwise.
There is one statutory exception that catches people out. Under Swedish law as it currently stands, when a computer program is created by an employee in the course of their employment, the economic rights in that program pass to the employer by default, without a written assignment. This default rule is narrow: it applies to computer programs created by employees, and it does not extend automatically to other types of works, to work produced by a director or a partner rather than an employee, or to anything produced by an external party.
That last point is where most disputes originate. A freelance developer, a consultancy, an agency, or an offshore team is not an employee for this purpose. If the commissioning company never obtained a written assignment or an exclusive licence, the developer or the agency keeps the economic rights in the code by default, even though the company paid for the work and even though it may have been using the software for years.
Alongside the economic rights sits upphovsrätt (the personal, non-economic dimension of Swedish copyright, covering attribution and the integrity of the work). These rights belong to the individual author personally and survive an assignment of the economic rights; they cannot be waived in full, only limited in scope for a specific, defined use.
How it works in practice
Day one: stop the immediate risk
Before anything else, identify what is actually being threatened. If a departing developer is talking about pulling access, deleting a repository, or relicensing the code elsewhere, the first move is defensive: secure access credentials, back up the current state of the repository, and restrict who can push changes. This is not a legal step, it is a housekeeping step, but it has to happen before the legal position is even assessed.
Establish who actually wrote the code
Ownership analysis starts with a plain factual question: who wrote each material part of the software, and in what capacity. A single codebase can combine work from an in-house employee (covered by the statutory default), a contractor engaged directly (not covered), and a subcontractor engaged by an agency (two steps removed from any direct relationship with the commissioning company). Each contributor needs to be identified before anyone can say who holds what.
Locate the original agreement, if one exists
Pull every document connected to the engagement: the master agreement, the statement of work, email exchanges that describe scope, and any invoice terms that reference intellectual property. A short paragraph buried in a service agreement, or a set of standard terms referenced by a hyperlink in an old email, can be the entire basis of an assignment. It has to be read on its own terms, not assumed.
Check for open source and third party components
Commissioned software is rarely written entirely from scratch. If the codebase incorporates open source libraries, the licence terms of those components travel with the code regardless of what the commissioning agreement says about ownership, and some licences carry obligations, such as disclosure of source code, that the commissioning company may not have anticipated. A component-level review, not just a review of the main agreement, belongs in the first ten days.
Preserve evidence before anyone touches the repository
Version history, commit logs, and timestamps are often the clearest evidence of who wrote what and when. Once a dispute becomes visible, resist the temptation to clean up the repository, rewrite history, or remove a departing contributor's commits. Altering the record after a dispute has surfaced tends to damage the position of whoever did the altering, regardless of who was right on the underlying ownership question.
Decide whether to raise the issue or wait
Not every gap in the chain of title needs to be raised immediately with the other side. Where the software is stable, the relationship is functional, and no immediate threat exists, it can be more efficient to fix the paperwork quietly, through a retrospective assignment, than to open a dispute. Where a threat is active, a competitor is involved, or an investor is asking questions, the calculus changes, and a documented, formal approach becomes the safer route.
What to check inside the first ten days
- Who wrote each material part of the code, and under what contract
- Whether that contract contains an assignment clause, an exclusive licence, or neither
- Whether any open source or third party component carries its own licence obligations
- Whether the commissioning company has ever paid for a right it does not actually hold
- Whether moral rights issues, attribution and integrity, are separately addressed
- Whether the relationship or dispute involves a party located outside Sweden
Who owns the copyright if a developer was hired as a contractor rather than an employee?
By default, the contractor does. The statutory rule that transfers rights in a computer program to an employer applies specifically to employees; it does not extend to freelancers, agencies, or subcontracted developers. Absent a written assignment or an exclusive licence in the commissioning agreement, the contractor retains the economic rights in the code, even where the commissioning company paid the full fee and has been using the software commercially.
What happens if the commissioning agreement never mentions intellectual property rights at all?
Silence favours the creator, not the payer. If the agreement is silent on rights and the developer is not an employee, no transfer has taken place by operation of law, and the commissioning company is left with, at most, an implied licence to use the software for the purpose it was commissioned for. That implied licence is narrower than ownership and does not necessarily cover resale, sublicensing, or modification.
Can moral rights in software still be enforced even after full assignment of economic rights?
Yes, within limits. Moral rights, covering attribution and the integrity of the work, are personal to the author and are not transferred by an assignment of economic rights. An author can agree to limit the exercise of moral rights for a specific, defined use, but a blanket waiver covering every future use is not how Swedish copyright treats these rights.
The numbers
No two disputes over commissioned software cost the same amount to resolve, and the figures depend on factors that are visible early, in the first ten days, rather than only once a claim is filed.
The size and complexity of the codebase matters: a single microservice with one contributor is a different exercise from a platform built by a rotating team of contractors and subcontractors over several years. The completeness of the paper trail matters just as much: a clear written assignment resolves the question in a single review; a chain of informal emails and verbal understandings requires reconstruction, which takes longer and costs more.
Whether the matter can be resolved by negotiation or requires a formal claim changes the trajectory entirely. A retrospective assignment, agreed cooperatively, is a fraction of the cost and time of a contested ownership claim that ends up requiring expert evidence on authorship. And where the counterparty sits outside Sweden, cross-border service of documents, translation, and the need to check whether a foreign court would even recognise a Swedish-law assignment add a layer of cost that a purely domestic dispute does not carry.
Precise limitation periods and procedural deadlines applicable to a specific claim depend on its legal basis and should be checked against the current text of the law rather than assumed from general experience.
Where it usually goes wrong
A few patterns recur often enough to be worth naming directly.
The first is assuming the employer default rule for computer programs covers anyone who was paid to write code. It does not. It is limited to employees, and stretching it to cover a freelancer or an agency is the single most common source of the disputes described in this material.
The second is assuming that a standard commissioning or development agreement silently includes an assignment of rights because the company paid for the work. Payment for services and transfer of intellectual property rights are two separate legal events, and Swedish law does not merge them automatically.
The third is treating open source components as fully owned once integrated into a proprietary codebase. The licence terms attached to each component survive integration and can constrain what the commissioning company is actually free to do with the finished product, regardless of what the main development agreement says.
The fourth is forgetting that moral rights survive an assignment of economic rights. A company that has secured full ownership of the economic rights can still find itself unable to modify the software in a way the original author considers damaging to their reputation, without a specific, defined waiver covering that use.
The foreign element changes the calculation further. When the developer, the agency, or a parent company sits outside Sweden, the first question is which country's law governs the development agreement, because that, not the location of the commissioning company, usually determines whether an assignment clause is valid and how it is interpreted. A governing law clause pointing to a foreign jurisdiction can mean that a Swedish-style analysis of the employer default rule is the wrong starting point altogether, and that the enforceability of any assignment needs to be checked under the law the parties actually chose, or under the law of the place where the work was performed if they chose none.
One clarification worth stating directly: none of this sits within the jurisdiction of the Unified Patent Court, which is limited to patents. A dispute over copyright in commissioned software is resolved through ordinary civil proceedings or negotiation, not through the UPC.
What to do next
The steps above cover what can be done without external help: identifying contributors, locating the paperwork, preserving evidence, and mapping where the exposure sits. What they do not cover is a considered view on how strong a specific ownership position actually is once the documents are read together, and what a realistic route to resolution looks like given the counterparty and the stakes involved.
This sits within Lodline's intellectual property and UPC practice, which handles ownership disputes, licensing questions, and enforcement across registered and unregistered rights. Where the dispute also touches a registered mark used alongside the software, the enforcement logic follows the same first-contact approach set out in our guide on trade mark oppositions and enforcement.
Where the documents have been gathered and the open questions are clear, the next practical step is an assessment of the position itself, not a general consultation. Book an assessment call once the first ten days of housekeeping described above are done.