Auteursrecht op een Excel-tool: wanneer opmaak wel beschermd is en rekensystematiek niet

Niet elke digitale tool is juridisch een computerprogramma

Voor founders en productteams is het verleidelijk om alles wat digitaal werkt automatisch als software te zien. Toch gaat dat niet altijd op. De uitspraak van de Rechtbank Midden-Nederland van 19 februari 2025 laat precies zien waar dat juridisch mis kan gaan. Bij een tool die binnen Excel functioneert, is niet vanzelf sprake van een computerprogramma in de specifieke auteursrechtelijke betekenis die voor software geldt. Daarvoor is beslissend of je kunt aanwijzen dat sprake is van een eigen uitdrukkingswijze van software, zoals eigen broncode of doelcode die het programma reproduceerbaar maakt. Alleen het feit dat een model slim is ingericht, veel functionaliteit bevat en binnen Excel allerlei uitkomsten genereert, is daarvoor niet genoeg.

Dat is voor startups en scale-ups een relevant onderscheid. Veel jonge bedrijven bouwen interne of commerciële tools eerst als spreadsheetmodel, financieel dashboard, forecastingmodel of reportingtemplate. Dat kan commercieel waardevol zijn en technisch indrukwekkend aanvoelen, maar die waarde vertaalt zich niet automatisch naar de softwarebescherming die vaak in pitchdecks, contracten of verkoopgesprekken wordt verondersteld.

De praktische les is helder: wie zich op softwarebescherming wil beroepen, moet ook kunnen laten zien waar die software juridisch precies uit bestaat. Als je product in essentie draait op een bestaand spreadsheetbestand en je niet kunt onderbouwen dat daar eigen code aan is toegevoegd in de relevante zin, dan sta je op dat punt al snel met lege handen. Voor legal en product is dit dus geen semantische discussie, maar een bewijsdiscussie.

Waar kan dan wel auteursrecht op rusten?

Dat een Excel-tool niet onder de specifieke softwarebescherming valt, betekent nog niet dat er helemaal geen auteursrechtelijke bescherming is. Integendeel. De bescherming kan juist verschuiven naar andere onderdelen van het product, zolang daarin voldoende creatieve keuzes zijn gemaakt. In deze context bleken met name de instructieteksten en de opmaak van het model juridisch relevant. De berekeningen, functies en macro’s werden daarentegen niet beschermd geacht, omdat die te veel waren ingegeven door functionaliteit, technische uitgangspunten en het doel van het model als rekenmiddel.

Instructieteksten en opmaak kunnen zelfstandig waarde dragen

Voor veel techbedrijven voelt tekst in een tool secundair. De echte waarde zou dan zitten in de logica, de output of de automatisering. Toch laat deze lijn zien dat juist de manier waarop een gebruiker door een model wordt geleid, auteursrechtelijk gewicht kan hebben. Heldere instructies, keuzes in formulering, gebruiksvriendelijkheid en een herkenbare vormgeving kunnen samen een beschermde laag vormen.

Dat geldt ook voor visuele keuzes. Denk aan kleurgebruik, lettertypes, inspringingen, vetgedrukte onderdelen, positionering van tabellen en de manier waarop output wordt gepresenteerd. Zeker in B2B-tools is de gebruikerservaring vaak minder flashy dan in consumentenapps, maar dat maakt die vormgeving niet juridisch irrelevant. Juist bij finance, operations en reportingproducten zit veel onderscheidend vermogen in de manier waarop complexe informatie overzichtelijk wordt gemaakt.

Functionele inhoud blijft vaak buiten beeld

Aan de andere kant ligt er ook een duidelijke grens. Wanneer de inhoud vooral wordt bepaald door functionele noodzaak, technische uitgangspunten of externe voorschriften, blijft er minder ruimte over voor auteursrechtelijke bescherming. In deze context gold dat voor de berekeningen, de functies en de macro’s, maar ook voor benamingen van posten, tabellen en tabbladen voor zover die sterk werden gestuurd door verplichte inhoud en gebruikelijke terminologie.

Voor startups is dat een nuttige reality check. Niet elk slim proces, elk logisch rekenmodel of elke efficiënte datastructuur is als zodanig te monopoliseren via het auteursrecht. Wie een verdedigbare IP-positie wil opbouwen, moet dus scherp onderscheiden tussen creatieve vormgeving en puur functionele systematiek.

Een licentie zegt niet alleen wat mag, maar vooral hoe ruim dat gebruik is

Een tweede belangrijke les zit in de uitleg van de licentie. Wanneer in een overeenkomst alleen staat dat een klant een gebruiksrecht krijgt, maar niet heel precies wordt afgebakend wat daar wel en niet onder valt, kan dat gebruiksrecht ruim uitpakken. In deze context werd het maken van een kopie voor eigen gebruik en om te testen gezien als een gebruikelijke handeling die binnen het verleende gebruiksrecht viel. Er stond immers geen duidelijke beperking in de overeenkomst of toepasselijke voorwaarden die dat verbood. Daardoor was gebruik tijdens de looptijd van de licentie toegestaan, ook als daarbij beschermde elementen als opmaak en instructieteksten werden meegenomen.

Voor SaaS-bedrijven, AI-tooling aanbieders en makers van templates of interne platforms is dit een klassiek contractpunt. Een licentie die commercieel netjes klinkt, kan juridisch te open zijn geformuleerd. Dat speelt vooral als je wil voorkomen dat klanten kopieën maken, testomgevingen optuigen, delen van een tool hergebruiken in eigen omgevingen of output structureren op een manier die dicht tegen je product aanzit.

Bij Startup-Recht zien we regelmatig dat productteams veel aandacht besteden aan pricing, seats en renewal, maar minder aan de precieze reikwijdte van gebruik. Terwijl daar juist vaak de eerste discussie ontstaat. Wil je kopiëren beperken, dan moet dat expliciet. Wil je testgebruik afbakenen, dan moet dat expliciet. Wil je uitsluiten dat delen van je model buiten de primaire omgeving worden opgeslagen of hergebruikt, dan moet dat ook expliciet.

Na beëindiging van de licentie begint het echte risico

Voor veel bedrijven voelt het einde van een licentie als een administratief moment. Factuur stoppen, account sluiten, klaar. Juridisch is het vaak precies andersom. Het grootste risico begint juist na beëindiging, omdat dan scherp zichtbaar wordt welke onderdelen nog op systemen staan, welke bestanden intern blijven circuleren en of gebruikers feitelijk al zijn uitgefaseerd.

In deze context was afgesproken dat het gebruik zou eindigen en dat het model verwijderd en verwijderd gehouden zou worden van de systemen. Toen daarna toch nog gebruik plaatsvond en bestanden op de IT-omgeving aanwezig bleven, werd dat zwaar aangerekend. Relevant daarbij is dat het gebruik van de beschermde opmaak en instructieteksten al snel een verveelvoudiging oplevert, bijvoorbeeld doordat de computer een reproductie maakt bij gebruik of doordat bestanden worden opgeslagen. Daarmee verschoof de discussie van contractuele slordigheid naar auteursrechtinbreuk en schending van gemaakte afspraken.

Voor startups en scale-ups is dit essentieel, zeker als zij werken met enterprise klanten, pilots, implementaties of maatwerktools. Een beëindigingsproces moet meer zijn dan een opzegmail. Denk aan een concreet offboardingprotocol, verwijderverplichtingen, bevestigingen van de klant, interne controlepunten en waar nodig auditmogelijkheden. Hoe waardevoller en gevoeliger de tooling, hoe minder verstandig het is om beëindiging alleen op vertrouwen te laten rusten.

Een boetebeding loopt niet vanzelf door

Een van de meest praktische lessen voor contract drafting zit in het boetebeding. Veel leveranciers gaan er impliciet van uit dat een eenmaal overeengekomen boeteclausule ook na het einde van de overeenkomst nog wel zal doorwerken, zeker als de kernverplichtingen feitelijk doorlopen. Dat is een gevaarlijke aanname.

De lijn hier is dat een boetebeding in beginsel eindigt samen met de overeenkomst waarvan het deel uitmaakt, tenzij partijen iets anders hebben afgesproken of bij beëindiging opnieuw duidelijk vastleggen dat het beding blijft gelden. Alleen een algemene verwijzing naar postcontractuele verplichtingen is daarvoor niet genoeg. Als je een boete wilt koppelen aan niet-verwijderen, doorgaan met gebruik of het achterhouden van kopieën na einde licentie, dan moet dat expliciet en ondubbelzinnig worden geregeld.

Dat is voor techbedrijven geen detail, maar een commercieel instrument. Een goed survival-beding kan veel discussie voorkomen en heeft vaak meer preventieve waarde dan een later schadevergoedingsdebat. Juist in situaties waarin verwijdering lastig controleerbaar is, bijvoorbeeld bij lokale bestanden, exports, spreadsheetkopieën of gedeelde drives, kan een helder postcontractueel boetemechanisme het verschil maken.

Schadevergoeding blijft vaak dichter bij de licentiewaarde dan bij ambitieuze claims

Nog een reality check voor founders: ook wanneer onrechtmatig gebruik wordt aangenomen, leidt dat niet automatisch tot spectaculaire schadevergoedingen. In deze context werd de schade begroot op de gederfde licentievergoedingen over de relevante jaren. Dat kwam uit op € 8.500. Andere, verdergaande schadeposten, zoals gemiste consultancy-inkomsten en afgenomen klantenaanwas, haalden het niet omdat die onvoldoende concreet waren onderbouwd.

Dat is een belangrijk punt voor scale-ups met een IP-intensief product. De juridische overwinning en de financiële opbrengst lopen niet altijd gelijk op. Wie een stevige claim wil neerleggen, moet het causale verband en de omvang van de schade goed kunnen aantonen. Zonder die onderbouwing kom je vaak uit bij iets dat dicht ligt tegen de normale licentiewaarde.

Daarmee wordt preventie des te belangrijker. Heldere contracten, goede exit-afspraken en goede dossiervorming zijn vaak waardevoller dan later proberen een grote schadepost op te bouwen die in rechte niet hard te maken is.

Wat startups en scale-ups hiervan moeten meenemen

Voor productbedrijven die werken met spreadsheetgedreven tools, reportingmodules of andere semi-digitale modellen is de kernles dat juridische bescherming gelaagd is. Niet alles valt onder softwarerecht. Soms zit de sterkste bescherming juist in vormgeving, gebruikersinstructies en de concrete presentatie van output.

Voor sales en legal ligt de les in licentieformuleringen. Het woord gebruik is te vaag als je veel wilt uitsluiten. Benoem dus expliciet wat wel en niet mag, ook rondom kopiëren, testen, bewaren, migreren en intern hergebruik.

Voor operations en customer success zit de les in offboarding. Een beëindigde licentie moet operationeel worden afgewikkeld, niet alleen administratief. Verwijderen, verwijderd houden en controleerbaar afsluiten horen daarbij.

En voor management en investeerders is dit vooral een les in IP-hygiëne. De economische waarde van een tool hangt niet alleen af van wat het product kan, maar ook van hoe goed de rechten, contracten en exitmechanismen zijn georganiseerd.

Conclusie

De uitspraak van de Rechtbank Midden-Nederland van 19 februari 2025 maakt duidelijk dat een digitale tool in Excel juridisch niet automatisch als software wordt behandeld. Voor startups en scale-ups is dat een belangrijke les: de waarde en bescherming van een product zitten niet alleen in functionaliteit, maar ook in vormgeving, instructies en strakke contractuele afspraken over gebruik en beëindiging.

Rechtbank Midden-Nederland van 19 februari 2025, ECLI:NL:RBMNE:2025:751

‍

‍