Gebruiksrecht en Fair Use: wat mag een klant wel en niet?
In een SaaS-overeenkomst leg je vast wat een klant precies mag doen met jouw software. Het gaat daarbij niet alleen om toegang, maar ook om het gebruiksdoel, aantal gebruikers, en technische beperkingen zoals API-verkeer of dataconsumptie. Zonder heldere grenzen kunnen klanten je SaaS-tool op manieren gebruiken die je nooit hebt bedoeld of die schadelijk zijn voor andere gebruikers.
Stel: je levert een analytics-tool met onbeperkte exports, bedoeld voor intern gebruik. Een klant bouwt daarbovenop een eigen rapportageservice voor derden, zonder dit met jou af te stemmen. Dat leidt tot zwaar servergebruik en kan de prestaties van jouw platform negatief beïnvloeden, met klachten van andere klanten en reputatieschade tot gevolg.
Met een Fair Use Policy kun je dit soort situaties voorkomen. Hierin beschrijf je wat redelijk gebruik (‘fair use’) is, en wanneer je mag ingrijpen. Denk aan beperkingen op automatische data-extractie, verbod op het delen van accounts buiten de organisatie, of het recht om tijdelijk toegang op te schorten bij excessief gebruik. Zo houd je het gebruik van jouw dienst in lijn met wat jij hebt bedoeld en houd je de controle.
Intellectueel eigendom: standaardsoftware en maatwerk
SaaS-diensten draaien vaak op een standaardplatform dat je voor meerdere klanten inzet. Toch komt het regelmatig voor dat een klant aanvullend maatwerk vraagt: een extra module, een specifieke integratie of een aangepast dashboard. De juridische vraag is dan: wie heeft de rechten op dat maatwerk?
Als leverancier wil je doorgaans kunnen hergebruiken wat je ontwikkelt, zeker als de aanpassing ook voor andere klanten waardevol kan zijn. Laat je die rechten volledig bij de klant, dan kan dat je flexibiliteit inperken of je zelfs beletten om dezelfde oplossing elders aan te bieden.
Leg dus contractueel vast welk deel van de software jouw intellectueel eigendom blijft, en wanneer er sprake is van overdracht of exclusiviteit. Denk ook aan afspraken over broncode en updates van het maatwerk. Zo voorkom je discussies en houd je grip op je eigen technologie, ook als je op verzoek van een klant iets extra’s bouwt.
Open source en third-party tools
Veel SaaS-oplossingen zijn gebouwd op open source libraries en externe APIs. Dat is gebruikelijk, maar niet vrijblijvend. Door het gebruik van open source en externe componenten expliciet en helder te benoemen in de SaaS-overeenkomst, creëer je transparantie richting je klant en voldoe je aan relevante juridische verplichtingen. Dat voorkomt misverstanden over rechten en eventuele beperkingen.
Beëindiging van het SaaS-contract en exit-regelingen
Bij het einde van een SaaS-contract ontstaat vaak onzekerheid over datatoegang en overdracht. Klanten willen hun gegevens veilig en volledig terugkrijgen, liefst in een gangbaar formaat. Jij wilt als leverancier duidelijkheid over de grenzen van jouw verantwoordelijkheden.
De Data Act legt hier expliciete verplichtingen op, omdat SaaS-diensten vaak als “dataverwerkingsdienst” zullen kwalificeren. Zo moet je als aanbieder het overstappen (switching) faciliteren en contractueel regelen hoe en wanneer data wordt teruggeleverd. Denk aan een maximale opzegtermijn van twee maanden, gevolgd door een overgangsperiode van minimaal dertig dagen waarin klanten toegang behouden tot hun data.
Jaarcontracten blijven onder de Data Act overigens toegestaan, zolang je het overstapproces niet onnodig belemmert. De wet staat evenredige beëindigingsvergoedingen toe, maar volledige afkoop van resterende looptijd zou onder omstandigheden kunnen worden gezien als een vendor lock-in (iets dat de Data Act juist wil voorkomen).
Veelvoorkomende fouten in SaaS-overeenkomsten