Copyright on an Excel Tool: When Formatting Is Protected, But Calculation Methods Are Not

Not every digital tool is legally considered a computer program

For founders and product teams, it's tempting to automatically view everything that works digitally as software. However, this isn't always the case. The ruling by the District Court of Midden-Nederland on February 19, 2025, clearly illustrates where this can go wrong legally. A tool functioning within Excel is not automatically considered a computer program in the specific copyright sense that applies to software. The decisive factor is whether you can demonstrate that there is an original expression of software, such as proprietary source code or object code that makes the program reproducible. The mere fact that a model is cleverly designed, contains extensive functionality, and generates various outputs within Excel is not sufficient.

This is a relevant distinction for startups and scale-ups. Many young companies initially build internal or commercial tools as spreadsheet models, financial dashboards, forecasting models, or reporting templates. While these can be commercially valuable and feel technically impressive, that value doesn't automatically translate into the software protection often assumed in pitch decks, contracts, or sales discussions.

The practical lesson is clear: anyone wishing to claim software protection must also be able to demonstrate what that software legally consists of. If your product essentially runs on an existing spreadsheet file and you cannot substantiate that proprietary code has been added in the relevant sense, you will quickly find yourself empty-handed on that front. For legal and product teams, this is not a semantic discussion, but a matter of proof.

What *can* be protected by copyright?

The fact that an Excel tool doesn't fall under specific software protection doesn't mean there's no copyright protection at all. On the contrary. Protection can shift to other parts of the product, provided sufficient creative choices have been made within them. In this context, the instruction texts and the layout of the model proved particularly legally relevant. The calculations, functions, and macros, however, were not considered protected, as they were too heavily dictated by functionality, technical principles, and the model's purpose as a calculation tool.

Instruction texts and layout can hold independent value

For many tech companies, text within a tool feels secondary. The real value is often perceived to lie in the logic, output, or automation. However, this case demonstrates that the way a user is guided through a model can indeed carry copyright weight. Clear instructions, choices in phrasing, user-friendliness, and a recognizable design can collectively form a protected layer.

This also applies to visual choices. Consider color schemes, fonts, indentations, bolded elements, table positioning, and the way output is presented. Especially in B2B tools, the user experience is often less flashy than in consumer apps, but that doesn't make the design legally irrelevant. Particularly in finance, operations, and reporting products, much of the distinctive value lies in how complex information is made clear and manageable.

Functional content often remains unprotected

On the other hand, there's also a clear limit. When content is primarily determined by functional necessity, technical principles, or external regulations, there is less room for copyright protection. In this context, this applied to the calculations, functions, and macros, but also to the naming of items, tables, and tabs insofar as they were heavily dictated by mandatory content and common terminology.

For startups, this is a useful reality check. Not every clever process, logical calculation model, or efficient data structure can be monopolized as such through copyright. Anyone looking to build a defensible IP position must therefore sharply distinguish between creative design and purely functional systematics.

A license doesn't just state what's allowed, but crucially, how broad that usage is

A second important lesson lies in the interpretation of the license. If an agreement merely states that a customer receives a right of use, but doesn't precisely define what is and isn't covered, that right of use can turn out to be very broad. In this context, making a copy for personal use and testing was considered a customary action falling within the granted right of use. After all, there was no clear restriction in the agreement or applicable terms that prohibited it. Consequently, use during the license term was permitted, even if it involved protected elements like layout and instruction texts.

For SaaS companies, AI tooling providers, and creators of templates or internal platforms, this is a classic contractual issue. A license that sounds commercially sound can be formulated too openly from a legal perspective. This is particularly relevant if you want to prevent customers from making copies, setting up test environments, reusing parts of a tool in their own environments, or structuring output in a way that closely resembles your product.

At Startup-Recht, we regularly observe that product teams focus heavily on pricing, seats, and renewal, but less on the precise scope of use. Yet, this is often where the first disputes arise. If you want to restrict copying, it must be explicit. If you want to define test usage, it must be explicit. If you want to exclude parts of your model from being stored or reused outside the primary environment, that too must be explicit.

The real risk begins after license termination

For many companies, the end of a license feels like a mere administrative event. Stop invoicing, close the account, done. Legally, it's often the exact opposite. The greatest risk actually begins after termination, as it then becomes acutely clear which components remain on systems, which files continue to circulate internally, and whether users have actually been phased out.

In this context, it was agreed that use would cease and that the model would be removed and kept removed from the systems. When, despite this, use continued and files remained present in the IT environment, this was heavily penalized. It's relevant that the use of the protected layout and instruction texts quickly constitutes reproduction, for example, because the computer creates a copy during use or because files are saved. This shifted the discussion from contractual sloppiness to copyright infringement and breach of agreements.

For startups and scale-ups, this is essential, especially when working with enterprise clients, pilots, implementations, or custom tools. A termination process must be more than just a cancellation email. Consider a concrete offboarding protocol, deletion obligations, client confirmations, internal control points, and, where necessary, audit capabilities. The more valuable and sensitive the tooling, the less wise it is to rely solely on trust for termination.

A penalty clause does not automatically carry over

One of the most practical lessons for contract drafting lies in the penalty clause. Many suppliers implicitly assume that a penalty clause, once agreed upon, will continue to be effective even after the agreement ends, especially if the core obligations effectively continue. That is a dangerous assumption.

The principle here is that a penalty clause, in principle, ends with the agreement of which it is a part, unless parties have agreed otherwise or explicitly stipulate again upon termination that the clause remains in effect. A general reference to post-contractual obligations alone is not sufficient for this. If you want to link a penalty to non-deletion, continued use, or retention of copies after license termination, then this must be explicitly and unambiguously regulated.

For tech companies, this is not a minor detail but a commercial instrument. A good survival clause can prevent much discussion and often has more preventive value than a later damages debate. Especially in situations where deletion is difficult to verify, for example, with local files, exports, spreadsheet copies, or shared drives, a clear post-contractual penalty mechanism can make all the difference.

Damages often remain closer to the license value than to ambitious claims

Another reality check for founders: even when unlawful use is assumed, it does not automatically lead to spectacular damages. In this context, the damages were estimated based on the lost license fees over the relevant years. That amounted to € 8,500. Other, more extensive damage claims, such as lost consultancy income and decreased customer acquisition, did not succeed because they were not sufficiently substantiated.

That is an important point for scale-ups with an IP-intensive product. Legal victory and financial gain do not always go hand in hand. Anyone who wants to file a substantial claim must be able to clearly demonstrate the causal link and the extent of the damage. Without that substantiation, you often end up with something close to the normal license value.

This makes prevention all the more important. Clear contracts, solid exit agreements, and thorough record-keeping are often more valuable than later trying to build a large claim for damages that cannot be substantiated in court.

What startups and scale-ups should take away from this

For product companies working with spreadsheet-driven tools, reporting modules, or other semi-digital models, the key lesson is that legal protection is layered. Not everything falls under software law. Sometimes the strongest protection lies precisely in design, user instructions, and the concrete presentation of output.

For sales and legal, the lesson lies in license formulations. The word 'use' is too vague if you want to exclude many things. Therefore, explicitly state what is and is not allowed, including copying, testing, storage, migration, and internal reuse.

For operations and customer success, the lesson is in offboarding. A terminated license must be operationally settled, not just administratively. Deletion, ensuring deletion, and verifiable closure are part of this.

And for management and investors, this is primarily a lesson in IP hygiene. The economic value of a tool depends not only on what the product can do, but also on how well the rights, contracts, and exit mechanisms are organized.

Conclusion

The ruling by the District Court of Midden-Nederland on February 19, 2025, clarifies that a digital tool in Excel is not automatically treated as software legally. For startups and scale-ups, that is an important lesson: the value and protection of a product lie not only in its functionality, but also in its design, instructions, and strict contractual agreements regarding use and termination.

District Court of Midden-Nederland, February 19, 2025, ECLI:NL:RBMNE:2025:751

‍

‍