De voordelen van geautomatiseerde systemen en goede software hoeven we tegenwoordig niet meer uit te leggen. Gebruikers kunnen bij een juiste keuze en goed gebruik hun werk veel efficiënter en effectiever uitvoeren. Dat er aan software ook negatieve kanten zitten en soms zelfs risico’s kleven, kunt u vaak teruglezen in de pers. Om enkele haken en ogen te noemen: sommige software is (erg) onderhoudsgevoelig waardoor organisaties in meer of mindere mate afhankelijk zijn van hun leverancier. Daarnaast neemt het gebruik van cloudapplicaties (SaaS) een steeds hogere vlucht.

Dit artikel gaat in op de juridische aspecten van software en de vraag of deze afhankelijkheidsrisico’s kunnen worden vermeden. Ook gaan we in op welke maatregelen men kan nemen.

Inleiding

Het is wellicht een vreemde invalshoek om te beginnen met een pleidooi om anders naar software te kijken. Die andere manier van kijken betreft dan onder meer de aandacht voor de juridische aspecten van software, software als vermogensbestanddeel en de beeldvorming rond de inhoud van de relaties van bij software betrokkenen.

Een voorbeeld hiervan is de relatie licentiegever – licentienemer. Dit is geen gewone leverancier – klant relatie. Door de langdurige band tussen softwareproducent en zijn afnemers, de volledige afhankelijkheid van de softwareproducent, het langdurige proces van vervanging van software en de onmisbaarheid van de gegevens uit het informatiesysteem (die vaak alleen leesbaar zijn als de software waarmee ze zijn vastgelegd, werkt en beschikbaar is) valt de softwareproducent niet te vergelijken met de leverancier van levensmiddelen. De ontstane ‘lotsverbondenheid’ is een risico voor gebruikers en licentiegever.

Tegelijkertijd zijn de beschikbaarheid en continuïteit van het informatiesysteem erg belangrijk. Dit betekent dus dat de software en data steeds beschikbaar moeten zijn in operationele staat. En om dat zo te houden moet de broncode met toebehoren onder alle omstandigheden beschikbaar zijn. Om dat goed te regelen is er een combinatie nodig van juridische zekerheid en technische continuïteit. Vooral met de juridische maatregelen wordt de basis gelegd onder de informatiebeveiliging en het beheersen van risico’s die voortkomen uit de ontstane lotsverbondenheid.

Juridisch kader

Hoewel het nooit zo wordt geformuleerd, is de handel in software feitelijk een handel in rechten. Dat heeft natuurlijk alles te maken met het auteursrecht waaronder ook software valt. Softwareproducenten hebben namelijk het alleenrecht op openbaarmaking van hun producten. In de praktijk betekent dit, dat ze de zogenaamde objectcode (dat is de versie in digitale vorm) openbaar maken. Dat doen ze door een gebruiksrecht te verstrekken op de objectcode. Alle overige componenten van een compleet softwareproduct houden ze geheim. Dat is onder meer het materiaal dat ontwikkeld is voorafgaand aan het feitelijke programmeerwerk, en alle gebruikte hulpsoftware en de broncode zelf. Dit materiaal is wel nodig bij het onderhouden en doorontwikkelen van de programmatuur. Om deze reden zijn gebruikers aangewezen op een onderhoudscontract met de auteursrechthebbende van de software. Op zichzelf is dat aspect niet perse nadelig voor de gebruikers omdat op deze wijze kennis en kosten kunnen worden gedeeld, maar dit terzijde.

Het gaat te ver in het kader van dit artikel om alle op software en/of informatiesystemen zijnde wet- en regelgeving te bespreken. Denkt u bijvoorbeeld aan de Wet Bescherming Persoonsgegevens en de Databankenwet. Het dient wel een punt van aandacht te zijn bij het treffen van beheersingsmaatregelen. Het kan een extra argument ervoor zijn of tot aanpassing van maatregelen leiden.

De rechtspositie van de licentienemer

Zoals hierboven blijkt is het standaardpraktijk dat de licentienemer uitsluitend een gebruiksrecht op de software krijgt. Het betreft dan uitsluitend de objectcode.

Deze rechtspositie wordt er meestal niet sterker op als gekeken wordt naar de eigendom van het auteursrecht. In de praktijk werken de meeste softwareproducenten in de vorm van een rechtspersoon. Het auteursrecht houdt daar rekening mee. Het auteursrecht op het werk van een programmeur in loondienst gaat over op de werkgever. Maar hier houdt dit zeer beknopte verhaal over auteursrecht nog niet op. Steeds meer softwareproducenten werken in een holdingstructuur. Daardoor wordt het voor de buitenwacht lastig om te weten wie de eigenaar van de software is. Daarbij gevoegd de mogelijkheden van het auteursrecht, dat er gedeeld eigendom bestaat, en er ook nog de mogelijkheid is pandrecht op software te vestigen. Het zal duidelijk zijn, dat er in de vele factoren die van invloed zijn op de eigendomssituatie van software, wijzigingen kunnen optreden tijdens de gebruiksduur.

Rechtszekerheid voor softwaregebruikers

De vraag is nu hoe de rechtspositie van gebruikers structureel kan worden verbeterd. Daarvoor is kennis en ervaring nodig op het grensvlak van de vakgebieden IT en Recht. Op dit grensvlak doen zich vele ontwikkelingen voor, denkt u aan jurisprudentie en opkomst van XaaS-systemen. Er ontstaan nieuwe specialismen, producten en diensten. Langer bestaande diensten worden geprofessionaliseerd. Dat geldt bijvoorbeeld voor het ‘product’ software-escrow.

Broncodedeponering gebeurt vooral in het belang van de softwaregebruiker. Minder bekend is, dat ook de eigenaar van het auteursrecht (softwareontwikkelaar) op een broncode een belang heeft. Dat is gelegen in het feit dat het auteursrecht op broncodes niet wordt geregistreerd. Dat vindt zijn oorzaak in het auteursrecht. Het auteursrecht ontstaat namelijk spontaan. Het registreren van auteursrecht hoeft bij veel producten vaak niet, omdat door openbaarmaking (dit is één van de rechten van de maker) controle op namaak (plagiaat, vervalsing) vrij gemakkelijk plaatsvindt. Voor software ligt dit natuurlijk heel anders en zeker voor de broncode, die met opzet geheim wordt gehouden.

Er is een praktische oplossing voor dit gebrek aan rechtszekerheid. Dat is het deponeren van een broncode bij een IT-notaris m.b.v. een notariële akte, nadat een zogenaamd IE-onderzoek is verricht. Dit IE-onderzoek heeft tot doel een duidelijke eigenaar te identificeren. Uiteraard speelt kennis van auteursrecht en van softwareontwikkeling hierbij een belangrijke rol. De voordelen zijn evident: er is nu een duidelijke eigenaar en doordat de broncode is gedeponeerd bij de notaris zijn inbreuken op het auteursrecht veel beter te bestrijden.

Broncodedeponering, mits deskundig en zorgvuldig uitgevoerd, kan er voor zorgen, dat er duidelijkheid bestaat over de vraag of de licentienemer wel een overeenkomst heeft afgesloten met de juridische eigenaar van de software waar hij alleen een gebruiksrecht van heeft.

Recht op de broncode, aanvullende maatregelen cloudapplicaties

Als de software op een juridisch correcte wijze gedeponeerd is, dan is het nog een kleine stap, om de licentienemer het recht te verlenen op de broncode onder zgn. opschortende voorwaarde. Ook daarvoor moeten wel eisen gesteld worden aan de wijze waarop de broncode is gedeponeerd. De belangrijkste eis is, dat er een deskundige controle heeft plaatsgevonden van de broncode met alle toebehoren. Daarbij is het belangrijk, dat men zich realiseert, dat broncodedeponering ook bedoeld is om schade te beperken, die het gevolg kan zijn van (langdurige) uitval van informatiesystemen. Met het te deponeren materiaal moet onderhoud en doorontwikkeling kunnen plaatsvinden. Daaromtrent kan alleen zekerheid worden geboden na een reconstructie van de software door vanuit een broncode en alle gebruikte hulpsoftware een werkende objectcode te generen. Daarnaast moet er tevens nog een test worden uitgevoerd of wijzigingen in de objectcode kunnen worden doorgevoerd. Nadat vastgesteld is, dat het te deponeren materiaal volledig is, moet vervolgens nog aandacht worden besteed aan de overdraagbaarheid. Het belang van documentatie wordt door softwareontwikkelaars nogal eens onderschat. Het is daarom nodig dat de informatie die nodig is voor de overdraagbaarheid, wordt vastgelegd en toegevoegd aan de te deponeren broncode. Dit kan gebeuren tijdens de controle van de broncode.

Voor software die niet draait op systemen in het beheer van de gebruiker, moeten naast broncode-deponering aanvullende maatregelen worden genomen. Een inventarisatie van de ketenpartijen die achter de softwareleverancier zitten en ervoor zorgen dat de oplossing in de lucht blijft, is noodzakelijk. Met essentiële ketenpartijen, zoals een hostingprovider, zullen afspraken moeten worden gemaakt over de continuering van hun dienstverlening op het moment dat de softwareleverancier geraakt wordt door een calamiteit. Omdat de keten achter XaaS-systemen van geval tot geval verschilt, is een continuïteitsregeling voor cloudoplossingen maatwerk.

Afgifteregeling

Onder welke voorwaarden kan de licentienemer een beroep doen op afgifte van de broncode en wordt de genomen continuïteitsmaatregelen uitgevoerd? In de praktijk komen doorgaans de volgende voorwaarden voor:

• Overeenstemming tussen de betrokken partijen, dat de regeling mag worden uitgevoerd;
• Het vervallen van de inschrijving van de softwareleverancier bij de Kamer van Koophandel;
• Het faillissement van de softwareleverancier of de verlening van surseance van betaling;
• Overdracht van de programmatuur door de softwareleverancier aan een derde, zonder dat de rechten en plichten uit de escrowovereenkomst zijn overgedragen;
• Een rechterlijke uitspraak waarbij vastgesteld is dat:
  • de softwareleverancier de escrowovereenkomst niet volledig nakomt;
  • de softwareleverancier zijn verplichtingen uit overeenkomsten met een gebruiker niet behoorlijk vervult;
  • de softwareleverancier het onderhoud van de betreffende programmatuur heeft gestaakt;
  • de softwareleverancier zijn verplichtingen tegenover een essentiële ketenpartij niet nakomt.

Een voorwaarde voor uitvoering van de regeling is natuurlijk ook, dat de licentienemer een geldig contract heeft met zijn softwareleverancier, en aan al zijn verplichtingen tegenover zijn softwareleverancier heeft voldaan.

Controlemogelijkheid door softwaregebruikers

Voor veel gebruikers zijn begrippen als automatisering en software al behoorlijk abstracte begrippen. Een escrowregeling wordt dan al gauw ervaren als een complex vraagstuk. Dat wordt nog eens in de hand gewerkt door de vele escrowregelingen die kwalitatief niet aan redelijkerwijs te stellen eisen voldoen. Dat wordt vaak verhuld met een gebrek aan voorlichting en controleerbaarheid. Het is belangrijk, dat aan gebruikers de mogelijkheid wordt geboden, te controleren of de regeling voldoet en een gedeponeerde broncode kan worden gebruikt voor continuïteit. Met andere woorden: verslaglegging is noodzakelijk.

Conclusie

Uit het oogpunt van informatiebeveiliging is aandacht voor de juridische aspecten van software noodzakelijk. Een licentieovereenkomst of SLA alleen geeft de softwaregebruiker een zwakke rechtspositie en stelt de continuïteit van zijn informatiesysteem onvoldoende zeker. Een solide software-escrowregeling is dan ook een logische aanvulling op de licentieovereenkomst. De IT-Jurist kan u ondersteunen bij het opstellen en beoordelen van een escrowregeling.