Protecting Software & Saas Intellectual Property in Denmark (2026): Copyright, Trade Secrets, Open‑source Compliance & Employee Agreements

Software IP Denmark is now a board-level concern for every founder, CTO and in-house counsel building or scaling a SaaS product, and the 2026 environment makes the stakes sharper than ever. A wave of regulatory attention around artificial intelligence, deepfakes and dataset provenance has collided with near-universal SaaS adoption, distributed engineering teams and deep dependence on third-party code. The result is a more complex risk surface where a single unlicensed dependency, an unsigned contractor assignment or a leaked algorithm can undermine a funding round or trigger litigation. This guide pulls together Danish copyright rules, trade-secret standards, open-source compliance, employment and inventor agreements, and patent practice into one practical playbook grounded in primary Danish and EU sources.

Executive summary & recommended first steps

If you only do five things after reading this guide, prioritise the actions below. Each one closes a common, expensive gap in software IP Denmark risk management and each is independently defensible to an investor or acquirer conducting due diligence.

• Run an IP audit. Map every asset, source code, object code, UI designs, documentation, algorithms, training data and brand assets, and confirm who legally owns each. Gaps in the chain of title are the single most common red flag in SaaS transactions.
• Fix your contracts. Ensure every employee, contractor and freelancer has signed a written agreement that assigns IP to the company, requires invention disclosure and imposes confidentiality obligations. Verbal understandings are of limited value in diligence.
• Scan your open source. Produce a software bill of materials, identify every open-source licence in your dependency tree, and remediate copyleft contamination before it reaches a customer or an acquirer.
• Harden trade-secret controls. Apply least-privilege access, encryption, logging and documented policies to your core algorithms, pipelines and datasets, because a trade secret survives only as long as you treat it as secret.
• Register the rights that require registration. Copyright is automatic, but trademarks and any software-related patent require formal filings, plan these before public disclosure and consult the Danish Patent and Trademark Office on procedure and timing.

These five steps form the backbone of a credible software IP Denmark strategy. The rest of this guide explains the legal basis for each and gives you the clause language and checklists to execute them.

Why software & SaaS IP matters in Denmark in 2026

Denmark is a mature, highly digitised market with a strong technology sector, and the value locked in software IP has never been higher relative to physical assets. For a SaaS business, intangible rights often represent the bulk of enterprise value, which means IP hygiene is no longer a compliance afterthought, it is directly tied to valuation, fundability and exit readiness.

2026 regulatory context, AI, deepfakes and supply-chain risk

The current policy climate places unusual emphasis on AI-generated content, deepfakes and the provenance of training data, reflected in the phased implementation of the EU Artificial Intelligence Act. For software teams this raises concrete questions: who owns code produced with AI assistance, whether a dataset used to train or fine-tune a model was lawfully sourced, and how to document that provenance for an investor. Where code generation or telemetry involves personal data, the interface with data-protection law becomes unavoidable, and guidance from the Danish Data Protection Agency (Datatilsynet) is the relevant reference point.

At the same time, the breadth of third-party and open-source components in modern stacks has turned the software supply chain into a primary risk vector, a vulnerability or an incompatible licence introduced upstream propagates silently into your product.

Commercial risks for SaaS businesses

The practical risks cluster into three categories. First, infringement, using third-party code or assets without a valid licence exposes you to injunctions and damages. Second, leakage, the loss of a core algorithm or dataset to a departing employee or a breach can destroy a trade secret permanently. Third, licence contamination, a copyleft component buried in your dependency tree can impose disclosure or source-availability obligations you never intended to accept. Each of these can derail a financing or acquisition, which is why disciplined software IP Denmark management pays for itself many times over.

Forms of protection available for software IP Denmark, quick comparison

No single legal tool protects software completely. A robust strategy layers copyright, patents, trade secrets and contracts so that the weaknesses of one are covered by the strengths of another. The table below summarises each form with Denmark-specific notes, followed by narrative detail on the three statutory regimes.

Which form of protection is right for my software/SaaS?

Copyright, what protects code, authorship, moral rights

Under the Danish Copyright Act (Ophavsretsloven), as consolidated on Retsinformation, computer programs are protected as literary works. Protection arises automatically at the moment of creation with no registration required and covers both source code and object code, along with preparatory design material and code comments. Crucially, copyright protects the expression of the program, the way it is written, not the underlying functional idea, algorithm or method. Two developers can lawfully solve the same problem with independently written code. Authorship vests initially in the human who wrote the code, which creates both ownership and moral-rights considerations that must be managed contractually, especially where multiple contributors or AI tools are involved.

Patentability of software, limits under EPC & Danish practice

Software “as such” is excluded from patentability under the European Patent Convention framework, and Danish practice at the Danish Patent and Trademark Office follows the same logic. The decisive question, developed extensively in European Patent Office case law and guidelines, is whether the invention produces a technical effect beyond the ordinary interaction of a program with a computer. A claimed invention that controls an industrial process, improves the functioning of a device or solves a technical problem in a technical way may be patentable; a pure business method or abstract algorithm generally cannot. Because the threshold is demanding and prosecution is expensive, patents suit a narrow band of genuinely technical software inventions.

Trade secrets, requirements and EU/Denmark implementation

Denmark implemented the EU Trade Secrets Directive (Directive (EU) 2016/943, available on EUR-Lex) through the Danish Trade Secrets Act (lov om forretningshemmeligheder), giving confidential business information a dedicated statutory protection regime. To qualify as a trade secret, information must be secret in the sense that it is not generally known or readily accessible, must have commercial value because it is secret, and must be subject to reasonable steps by the holder to keep it secret. That last requirement is where most companies fail: protection depends on demonstrable controls, not merely on labelling something “confidential.” For software businesses, trade secrets are often the most valuable protection for core algorithms, data pipelines and training data that neither copyright nor patents reach effectively.

Copyright & software in Denmark, ownership, infringement & licences

Copyright is the default and most comprehensive layer of software IP Denmark protection because it attaches automatically and lasts for decades. But its automatic nature masks a critical trap: the first owner is the author, not necessarily the company commissioning or paying for the work. Getting ownership right requires attention to the distinction between employees and contractors, to moral rights, and to the licences governing third-party code.

Who owns code created by employees vs contractors

For computer programs created by an employee in the execution of their duties or following the employer’s instructions, the Danish Copyright Act provides that the copyright passes to the employer, unless otherwise agreed. Even so, prudent companies do not rely solely on the statutory default; they confirm ownership expressly in the employment contract to remove any ambiguity about scope, derivative works and future exploitation, and to cover materials that fall outside the specific statutory rule for computer programs.

Contractors and freelancers are a different and more dangerous category. Absent a written assignment, an independent contractor typically retains copyright in the code they create, granting the client only an implied licence of uncertain scope. This is one of the most common and damaging gaps uncovered in diligence: a startup discovers that the freelancer who built its original platform never assigned the rights. The remedy is simple and must be front-loaded, every contractor engagement should include a present, written assignment of all IP in the deliverables, a waiver of relevant moral rights to the extent permitted, and a warranty that the work is original and free of third-party claims.

Moral rights and economic rights, practical impact for SaaS

The Danish Copyright Act distinguishes economic rights, which can be assigned, from moral rights, which protect the author’s connection to the work and cannot be waived wholesale in the same manner. For a SaaS company this matters when you refactor, rebrand or heavily modify code: the original author may retain a residual interest in attribution and integrity. Well-drafted agreements address this by securing the broadest permissible waiver of moral rights for defined, limited uses and by documenting consent to modification, so that the company can evolve the codebase without inadvertently infringing an author’s remaining rights.

Licensing third-party code (OSS), obligations and risks

Virtually every modern SaaS product incorporates open-source software, and each component arrives with licence obligations that bind you whether or not you read them. Permissive licences such as MIT and Apache 2. 0 impose light obligations, chiefly attribution and notice retention. Copyleft licences such as the GPL and, critically for SaaS, the AGPL impose reciprocal source-availability obligations that can require you to disclose your own source code under certain conditions. Because these obligations flow by licence, not by negotiation, managing them is a compliance discipline rather than a drafting exercise, which is the subject of the next section.

On the common question of which jurisdiction is “best” for IP, the honest answer for most Danish founders is that Denmark’s EU-harmonised copyright and trade-secret framework, combined with access to the EPO system, already provides strong, interoperable protection; relocating IP ownership rarely improves protection and often complicates it.

Open‑source compliance for Danish SaaS, a software IP Denmark priority

Open-source compliance deserves its own operational programme because it is the area where software IP Denmark risk most often enters silently and compounds over time. The goal is not to avoid open source, that is neither possible nor desirable, but to know precisely what you use, under what terms, and to ensure those terms are compatible with your commercial model.

How to run an open-source scan and remediate licence contamination

Start by generating a complete software bill of materials that enumerates every direct and transitive dependency. Automated composition-analysis tooling integrated into your pipeline will identify each component and its declared licence; standardised licence identifiers such as those maintained by SPDX make this machine-readable. Once you have the inventory, classify each licence by risk: permissive, weak copyleft or strong copyleft. For any strong-copyleft component in a product you distribute or expose over a network, assess whether its obligations are triggered. Remediation options, in order of preference, are: replace the component with a permissively licensed equivalent; isolate it so that its obligations do not attach to your proprietary code; or, where neither is feasible, comply fully with the licence terms.

Document every decision, the audit trail is itself an asset in diligence.

Best practices for procurement, CI/CD and vendor contracts

Compliance is cheapest when it is continuous rather than retrospective. Build licence scanning into your continuous integration pipeline so that a non-compliant dependency fails the build before it ever ships. Maintain an approved-licence policy that engineers can consult, and require explicit review before anyone introduces a copyleft component. Extend the discipline to vendors: contracts with software suppliers and development partners should include warranties that deliverables are free of undisclosed open-source obligations, an obligation to provide a bill of materials, and an indemnity for breach. These provisions push compliance responsibility upstream to the party best placed to manage it.

Sample mitigation steps for GPL/AGPL risk in SaaS

AGPL deserves special attention in a SaaS context because its network-use provision can trigger source-availability obligations even where you never distribute a binary, merely offering the software as a service over a network may suffice. Practical mitigation includes identifying all AGPL components at the dependency level, evaluating whether their functionality can be replaced with a permissively licensed library, architecting clear boundaries between any retained AGPL component and your proprietary core, and, where the component is retained, preparing to make the corresponding source available in compliance with the licence. Treat AGPL findings as escalation items requiring sign-off, not routine engineering decisions.

Trade secrets & internal controls, technical and contractual safeguards

Trade secrets protect what copyright and patents cannot, the know-how, algorithms, pipelines and datasets that give your product its edge, but only for as long as you keep them secret. Protection is earned through demonstrable, documented controls, and lost the moment information becomes public.

Legal standard in Denmark (what counts as a trade secret)

Following Denmark’s implementation of the EU Trade Secrets Directive through the Danish Trade Secrets Act, protected information must satisfy three cumulative conditions: it must be secret, meaning not generally known or readily accessible to people within the relevant circles; it must have commercial value derived from its secrecy; and the holder must have taken reasonable steps, under the circumstances, to keep it secret. The directive text on EUR-Lex and the national implementing legislation on Retsinformation set the precise statutory language. The third condition is the operative one in practice: if a dispute arises, you will be asked to prove what concrete measures you took, so the measures must exist and be evidenced before any incident occurs.

Practical internal controls: access, encryption, logging, employee training

Reasonable steps translate into a familiar set of technical and organisational controls. Apply least-privilege access so that each person can reach only the code, data and systems their role requires. Encrypt sensitive repositories and data at rest and in transit. Maintain access logging so that you can reconstruct who accessed what and when, useful both for deterrence and for proving misappropriation later. Classify information by sensitivity and mark the most sensitive accordingly. Deliver regular employee training so that staff understand what the company treats as secret and why, because controls that staff do not understand are rarely followed.

Where any of these measures involve monitoring that processes personal data, align them with Datatilsynet guidance to avoid creating a data-protection problem while solving an IP one.

NDAs, confidentiality clauses and incident response

Contractual protection complements technical controls. Non-disclosure agreements with partners, prospects and vendors, together with confidentiality clauses in every employment and contractor agreement, establish the legal obligation and reinforce the reasonable-steps requirement. Equally important is a rehearsed incident-response plan: if a trade secret is exposed through a breach or a departing employee, rapid action, preserving evidence, seeking injunctive relief and containing dissemination, can be the difference between a recoverable position and permanent loss.

Employee, contractor & inventor agreements, drafting checklist & sample clauses

Written agreements are the connective tissue of software IP Denmark protection. They convert the default legal position into certainty, allocate risk, and give investors the documented chain of title they demand. The challenge is drafting them to be both effective and enforceable under Danish employment law.

Employment law constraints in Denmark

Danish employment law imposes real limits on what an employer can require, and these constraints shape how IP and restrictive clauses are drafted. Employee inventions may carry specific statutory treatment under the Act on Employees’ Inventions (lov om arbejdstageres opfindelser), and non-compete and non-solicitation clauses are subject to statutory conditions under the Danish Act on Employment Clauses (ansættelsesklausulloven) governing their scope, duration and the compensation payable to the employee during the restricted period. A clause that ignores these conditions risks being unenforceable precisely when you need it.

For this reason, assignment and restraint provisions must be tailored to the Danish statutory framework consolidated on Retsinformation rather than copied from foreign templates, and should be reviewed by qualified Danish counsel before use.

Key clauses: assignment, disclosure, confidentiality, warranty and indemnity

Every software employment or contractor agreement should contain, at minimum, a present assignment of all IP in work created in connection with the engagement; an obligation to disclose inventions and developments promptly; a confidentiality obligation that survives termination; a warranty that the work is original and does not infringe third-party rights; and, for contractors, an indemnity backing that warranty. The following snippets are illustrative starting points only and must be adapted and reviewed by counsel before use.

Sample text, for discussion only, requires legal review:

• Assignment. “The Contributor hereby assigns to the Company, to the fullest extent permitted by law, all intellectual property rights in any materials, code and deliverables created in connection with this engagement, together with all accrued and future rights therein, and waives, to the extent permissible, all moral rights in such materials.”
• Disclosure. “The Contributor shall promptly and fully disclose to the Company in writing any invention, development, algorithm or work of authorship conceived or reduced to practice in connection with the engagement, and shall execute all documents reasonably required to perfect the Company’s rights therein.”
• Open-source policy. “The Contributor shall not incorporate any third-party or open-source component into the deliverables without the Company’s prior written approval, shall comply with the Company’s open-source policy, and shall maintain and provide on request a complete record of all such components and their applicable licences.”

Freelancer and OSS contribution clauses

Freelancers warrant additional care because they often work across multiple clients and may reuse components. The agreement should address whether the freelancer may reuse pre-existing or generic code, how such background IP is licensed to the company, and how contributions that the freelancer wishes to release back to an open-source project are handled. Where a developer contributes company code to an external open-source project, that must occur only under an explicit policy and approval process, because an uncontrolled contribution can inadvertently licence proprietary code to the world.

Patent strategy & software patentability in Denmark

Patents are a specialist, selective tool within a software IP Denmark strategy. They are expensive and slow to obtain, and the patentability threshold for software is high, but for the right invention they deliver the strongest exclusionary right available.

When to consider patents for software-related inventions

Consider patent protection where your innovation lies in a genuinely technical solution, for example, a method that improves the operation of a device, controls a physical or industrial process, or achieves a measurable technical improvement in computing itself, rather than in a business method, a user-interface idea or an abstract algorithm. Patents also make sense defensively, to deter competitors or to build a portfolio that strengthens your position in financing and partnership negotiations. Because patent applications must generally precede public disclosure to preserve novelty, the timing decision should be made early, before launch or publication.

Interaction with EPO and Danish practice; procedural pointers at DKPTO

Danish applicants can file nationally through the Danish Patent and Trademark Office or pursue European protection through the European Patent Office, and the two systems share the same core approach to software: the invention must demonstrate a technical effect to overcome the exclusion of programs “as such.” EPO guidelines and case law are an authoritative reference for how that test is applied in practice, and DKPTO procedural guidance covers national filing requirements and timelines. A common strategy is to file a national or European application early to establish a priority date, then decide on broader geographic coverage within the priority period. Given the cost and the technical drafting involved, engage a patent attorney experienced in software inventions before filing.

Remedies, enforcement & litigation landscape in Denmark

Rights are only as valuable as your ability to enforce them. Denmark offers a full suite of civil remedies for IP infringement and breach of confidence, and the availability of interim measures is often decisive in software cases where damage accumulates quickly.

Injunctive relief, damages, border measures and criminal enforcement

The primary civil remedies are injunctive relief and damages. Interim injunctions are particularly important in software and trade-secret disputes, because stopping the continued use or dissemination of misappropriated code or secrets promptly can prevent irreversible harm; Danish procedure allows a rights holder with a sufficiently clear case to seek such relief at an early stage. Final remedies include permanent injunctions, damages to compensate the loss suffered, and orders for the delivery up or destruction of infringing materials. For infringing physical goods crossing borders, EU customs enforcement mechanisms can intercept counterfeits, though this is more relevant to branded hardware than to pure SaaS. In serious cases, certain IP infringements can attract criminal sanctions.

Where disputes reach the highest level, decisions of the Danish Supreme Court (Højesteret) provide authoritative precedent on ownership and enforcement questions. Specialist IP and commercial disputes are frequently heard by the Maritime and Commercial High Court (Sø- og Handelsretten), whose case law is a key reference in this field.

Practical IP risk matrix & checklist for SaaS founders

Use the following checklist as a standing control list. Working through it quarterly keeps your software IP Denmark posture investor-ready and reduces the scramble that otherwise accompanies a financing or acquisition.

• IP audit. Maintain a current register of all IP assets and their legal owner.
• Chain of title. Confirm signed assignments from every employee, contractor and freelancer.
• Open-source audit. Keep a live software bill of materials and remediate copyleft and AGPL risks.
• Trade-secret controls. Enforce least-privilege access, encryption, logging and training, and document them.
• Confidentiality. Ensure NDAs and confidentiality clauses are in place with staff, partners and vendors.
• Registered rights. File trademarks and any viable patents before public disclosure.
• Data provenance. Document the lawful source of any training data and AI-assisted code.
• Source-code escrow. Consider escrow arrangements for enterprise customers and as investor protection.
• Incident response. Maintain a rehearsed plan for IP leakage and breach.

Next steps, how to engage counsel

A disciplined software IP Denmark programme, copyright hygiene, open-source compliance, trade-secret controls, watertight employee and contractor agreements, and a selective patent strategy, protects enterprise value and makes your business investor-ready. To begin, browse Denmark, Global Law Experts to find qualified counsel for a tailored IP audit, or consult a Danish IP specialist with experience in software and SaaS transactions.

Sources

1. Retsinformation (Danish legal gazette), consolidated acts and notices
2. Danish Patent and Trademark Office (DKPTO)
3. European Patent Office (EPO)
4. EU Intellectual Property Office (EUIPO)
5. World Intellectual Property Organization (WIPO)
6. Datatilsynet (Danish Data Protection Agency)
7. EUR-Lex, EU Trade Secrets Directive (Directive (EU) 2016/943)
8. The Danish Supreme Court (Højesteret)