DIT IS MIJN WINST SOFTWARE B.V.

All posts in Kennisbank voor de eenmanszaak of vof

Min de tekstverwerker, draaien al onze software programma’s die wij gebruiken in de cloud. Ook onze data slaan wij voor een deel op in de cloud. In het bedrijfsleven maar ook in de zorg en bij de overheid zie je steeds vaker dat er gekozen wordt voor een cloud-oplossing. Deze “oplossing” kan bijvoorbeeld bestaan uit een back-up in de cloud, een e-mailservice, een applicatie waarbij de ingevoerde data wel in huis wordt opgeslagen of een systeem wat alle door een organisatie benodigde functionaliteiten bevat waarbij tevens de data buitenshuis wordt opgeslagen.

Maar wat als de cloud-dienstverlener failliet gaat, in surceance van betaling verkeert of gewoon besluit de door u afgenomen dienst te beëindigen? Dan moet u op de een of andere manier regelen dat u uw data en toegang tot de applicatie behoudt. Als uw data zo is opgeslagen dat u het kunt migreren, dan hoeft u natuurlijk niet eindeloos toegang te behouden tot de applicatie. Enkel voor de duur van de migratie.

De klassieke oplossing voor dit probleem was de escrow. Sinds het Nebula-arrest van 2006 geeft de escrow een stuk minder zekerheid. De Hoge Raad overwoog twee beginselen uit de Faillissementswet. Een faillissement doet geen afbreuk aan bestaande overeenkomsten en (daartegenover) de gelijke behandeling van de schuldeisers. Hij kwam tot het volgende oordeel: het feit dat een schuldeiser een duurovereenkomst heeft met de gefailleerde, geeft hem niet het recht de overeenkomst uit te oefenen als was er geen faillissement. Dit zou een tot ongelijke behandeling leiden van de schuldeisers ook al ging het in dit geschil alleen maar om het toestaan van het gebruik. Om deze reden mag de curator wanprestatie leveren indien dit in belang is van de boedel. In het geschil ging het om een duurovereenkomst met betrekking tot een zaak, een huis. Echter, in de literatuur wordt er vanuit gegaan dat het Nebula-arrest ook van toepassing is op licenties. Natuurlijk zou het fijn zijn als de Hoge Raad zich hier specifiek over uit liet, maar tot nog toe is dat niet gebeurd.

Een klassieke escrow was al niet erg geschikt om de continuïteit van uw cloud-oplossing te waarborgen. Deze escrow regelt immers enkel iets voor het software pakket en niet voor uw data en beide in de meeste gevallen ook niet realtime. Doch nu de curator een kruis mag zetten door uw licentie, is de waarde nog minder. Als u geen licentie heeft mag u ook geen gebruik maken van een softwarepakket. Ook niet als u zich wel toegang tot dat pakket kan verschaffen en zelfs met behulp van de broncode een ander het onderhoud laten doen.

Daar er wel een grote verschuiving plaatsvindt waarbij ondernemingen en overheidsinstanties steeds vaker niet zelf een server hebben maar kiezen voor de cloud, is het van belang om ook in tijden van onzekerheid de bedreigingen te kunnen pareren. De gevolgen kunnen vergaand zijn als bijvoorbeeld de failliet niet tijdig door een derde wordt overgenomen. Als het gaat om een application service provider kunt u de toegang tot de applicatie verliezen en belangrijker nog: uw data.

U en uw cloud-dienstverlener kunnen de bedreigingen pareren en de uitdaging aangaan met een aantal vooraf gemaakte contractuele afspraken op maat.

(Bron: Cloudrecht.nl)

Liquiditeit is net als rentabiliteit en solvabiliteit een van de financiële ratio’s. Met deze cijfers kun je zien hoe jouw bedrijf zich over een periode ontwikkelt. De liquiditeit bereken je om aan te geven in hoeverre jouw bedrijf aan haar betalingsverplichtingen kan voldoen.

Er zijn meer ratio’s, maar de liquiditeitsratio, rentabiliteitsratio en solvabiliteitsratio worden het meest gebruikt. Met de gegevens uit je winst- en verliesrekening en je balans kun je de ratio’s uitrekenen.

Dynamisch

Er zijn twee vormen van liquiditeit: dynamische en statische. Met de dynamische liquiditeit bereken je hoe de inkomende geldstroom zich in een bepaalde periode verhoudt tot de uitgaande geldstroom. Meestal doe je dit voor de toekomst.
Eerst maak je een liquiditeitsbegroting op, om te schatten hoeveel geld er in deze periode (bijvoorbeeld de aankomende maand) binnen zal komen en uit zal gaan. Door deze cijfers met elkaar te vergelijken, weet je of je in deze periode aan je betalingsverplichtingen kunt voldoen.

Statisch

De statische liquiditeit geeft aan of je bedrijf aan haar betalingsverplichtingen kan voldoen met behulp van de vlottende activa, oftewel de activa die binnen een jaar te gelde kunnen worden gemaakt. Er zijn drie manieren om dit te berekenen:
  • Current ratio: Vlottende activa (voorraden debiteuren en kasgeld) gedeeld door kort vreemd vermogen (crediteuren en banken). Als de uitkomst hoger is dan 1, kun je voorlopig aan je betalingsverplichtingen voldoen. Liefst is de uitkomst hoger dan 2.
  • Quick ratio: Vlottende activa gedeeld door kort vreemd vermogen, met uitzondering van de voorraden. Dus debiteuren + kasgeld) gedeeld door kort vreemd vermogen (crediteuren en banken). Als het cijfer hoger is dan 1, kun je onmiddellijk aan je verplichtingen voldoen.
  • Nettowinstkapitaal: Vlottende activa minus kort vreemd vermogen. Hiermee zie je precies hoeveel geld je overhoudt nadat je aan je betalingsverplichtingen hebt voldaan.

Quick ratio

Bij de quick ratio tellen de voorraden niet mee, omdat ze eerst door klanten moeten worden gekocht en betaald. Als je op heel korte termijn aan je betalingsverplichtingen moet voldoen, heb je hier dus niets aan.
De quick ratio laat zien hoe je op dit moment aan je betalingsverplichtingen kunt voldoen. De andere ratio’s zijn er om te laten zien hoe je op langere termijn aan je betalingsverplichtingen kunt voldoen.
Vlottende activa zijn immers activa die je binnen een jaar te gelde kunt maken. Het kort vreemd vermogen zijn leningen of andere betalingsverplichtingen die je binnen een jaar moet aflossen.

Voorbeeld

Dus als bijvoorbeeld dit je balans is:
Debet Credit
Bedrijfspand: 200.000< Hypotheek: 150.000
Inventaris: 30.000 Leverancierskrediet: 20.000
Voorraden: 30.000 Eigen vermogen: 97.000
Kas: 5.000 Crediteuren: 3.000
Debiteuren: 5.000
Totaal 270.000 Totaal: 270.000

 

Je hypotheek is lang vreemd vermogen, je mag immers er langer dan een jaar over doen om het af te lossen. Het leverancierskrediet en de crediteuren vallen onder kort vreemd vermogen.
De current ratio is (voorraden 30.000 + debiteuren 5.000 + kasgeld 5.000 = 40.000) gedeeld door (kort vreemd vermogen is (leverancierskrediet 20.000 + crediteuren 3.000 = 23.000) = 40.000 / 23.000 = 1,74. Dit getal is hoger dan 1, je kunt dus in de nabije toekomst aan je betalingsverplichtingen voldoen.
De quick ratio is (debiteuren 5.000 + kasgeld 5.000) / (vlottende activa = 23.000) = 10.000 / 23.000 = 0,43. Dit getal is helemaal niet groter dan 1, dus de liquiditeit is toch best zorgwekkend. Je kredietwaardigheid is erg afhankelijk van of en hoe snel je je voorraden verkoopt.
Het nettowinstkapitaal is 40.000 – 23.000 = 17.000. Dit is prima.
(Bron: MKB Servicedesk)

 

 

Hieronder vindt u veelgestelde vragen over de boa.

Wat is een buitengewoon opsporingsambtenaar (boa)?

Een buitengewoon opsporingsambtenaar (boa) is een ambtenaar met opsporingsbevoegdheid. Denk hierbij bijvoorbeeld aan parkeerwachten, milieuinspecteurs en boswachters. Ook kunnen boa’s in dienst zijn van de politie, marechaussee of douane.

Wat zijn de bevoegdheden van een boa?

Boa’s vervullen een belangrijke rol in het handhaven van de veiligheid en het tegengaan van criminaliteit. Een  boa mag uw identiteit controleren, een proces-verbaal opmaken, boetes uitschrijven en personen aanhouden als deze worden verdacht van een strafbaar feit waarvoor de boa opsporingsbevoegdheid heeft.

Waaraan zijn boa’s te herkennen?

Het insigne van een boa Boa’s die veel contact hebben met het publiek – bijvoorbeeld parkeercontroleurs, hoofdconducteurs en ook boswachters – dragen een insigne. Dankzij dit insigne is meteen duidelijk wanneer iemand “bijzondere bevoegdheden” heeft. Voorbeelden van “bijzondere bevoegdheden” zijn het uitschrijven van boetes en het aanhouden van verdachten. Sommige boa’s mogen ook handboeien, een wapenstok, pepperspray of een vuurwapen dragen. Met een insigne onderscheiden boa’s zich ook van andere handhavingsfunctionarissen, zoals particuliere beveiligers, die deze bevoegdheden niet hebben, en van de politie, die juist meer bevoegdheden heeft. Het insigne toont een hand, een scepter en een schild. De hand houdt de scepter vast, daarachter staat het schild. Het insigne is zilverkleurig en beschikbaar in 2 vormen:

  • een mouwembleem van stof om op het uniform te naaien
  • een metalen insigne om op te spelden, bij voorkeur op het revers

De hand, de scepter en het schild van het insigne staan voor de taken en bevoegdheden die boa’s hebben. Het schild staat daarbij voor de bescherming van mensen in de publieke ruimte. De scepter (of staf) in de hand geeft aan dat de boa de bevoegdheid heeft om op te treden als dat nodig is. Naast dat boa’s een insigne dragen, moeten zij zich altijd kunnen legitimeren. Boa’s dragen een uniform maar er bestaat niet één boa-uniform, dus aan zijn kleding kun je de boa niet altijd herkennen. Daarnaast zijn er ook mensen die voor hun werk een uniform dragen, maar die geen opsporingsbevoegdheden hebben (bijvoorbeeld particuliere beveiligers).

Wat is er nodig om over te stappen van domein I naar domein II of andersom?

Indien u overstapt van domein I naar domein II of andersom dan kunt u hiervoor een nieuwe aanvraag om een akte van opsporingsbevoegdheid indienen en krijgt u de resterende termijn van de akte voor het andere domein verleend. Let op! U dient zich te realiseren dat u binnen deze resterende termijn van de akte de permanente her- en bijscholing van het nieuwe domein afgerond dient te hebben voordat u een volgende akte aan kunt vragen. U kunt hiervoor géén ontheffing krijgen.

  • Akte van opsporingsbevoegdheid aanvragen

Wat is de behandeltijd van een aanvraag?

De wettelijke beslistermijn op een aanvraag bedraagt drie maanden. Dien uw aanvraag dan ook op tijd in.

Waar kan een klacht over een boa worden ingediend?

Klachten over boa’s moeten in principe worden ingediend bij de organisatie waar de boa voor werkt.

Wanneer is advies van de toezichthouders nodig?

Bij een individuele akte moet een advies van de politie en het Openbaar Ministerie over de noodzaak van de aanstelling aan de aanvraag worden toegevoegd. Als er meerdere boa’s moeten worden aangesteld (minimaal 5), kan een werkgever een categoriale beschikking aanvragen. Daarin wordt de noodzaak en de eisen voor de aanstelling van de boa’s vastgelegd. Als een categoriale beschikking is afgegeven, kan een werkgever voortaan op basis hiervan aanvragen voor een akte van opsporingsbevoegdheid indienen. Bij een aanvraag op basis van een categoriale beschikking is de noodzaak vastgesteld en hoeft alleen de betrouwbaarheid en bekwaamheid van de individuele boa’s te worden aangetoond op basis van de vereiste opleiding(en) (bekwaamheid) en de VOG (betrouwbaarheid). Zie ook bij Akte van opsporingsbevoegdheid aanvragen.

Wanneer kunnen boa’s ingehuurd worden?

Inhuur van boa’s is alleen mogelijk in domein I. Zie hiervoor de circulaire boa.

Kan een boa in meerdere domeinen werken?

Een boa kan in maximaal twee domeinen werken, maar alleen als de boa bij twee verschillende boa-werkgevers in dienst is en voldoet aan de bekwaamheidseisen van de twee domeinen. Een parkeercontroleur in dienst van een gemeente kan bijvoorbeeld ook boa milieu, welzijn en infrastructuur zijn voor een landgoedeigenaar. Hij beschikt dan over twee verschillende akten van opsporingsbevoegdheid, bijvoorbeeld een akte voor het domein Openbare ruimte en een akte voor het domein Milieu, welzijn en infrastructuur. (Bron: Justis.nl)

Een elektronische handtekening maakt het mogelijk om vertrouwelijke documenten veilig via internet te versturen. Wat heeft u er voor nodig en hoe werkt het?

Wat is een elektronische handtekening?
Een handtekening onder een brief geeft zekerheid over de identiteit en de wilsuiting van de afzender. Ook bij digitaal verstuurde documenten kan dit gewenst zijn. De elektronische handtekening is het elektronische equivalent van een geschreven handtekening. Het is een geheel van elektronische gegevens, dat is vastgehecht aan andere elektronische gegevens en dat wordt gebruikt voor het identificeren van de ondertekenaar(s).

De elektronische handtekening regelt:

  • zekerheid over de wilsuiting (en de identiteit) van de afzender;
  • zekerheid dat het bericht niet is gewijzigd (integriteit).

Soms is een brief zo belangrijk dat de afzender er zeker van wil zijn dat de ontvanger, de medeondertekenaar, degene is die hij zegt te zijn. Uitsluitend de elektronische handtekening levert geen vertrouwelijkheid op. Een vertrouwelijke brief, die alleen door de geadresseerde mag worden gelezen, moet worden versleuteld. Dat kan met encryptie. Door het coderen (versleutelen) worden de gegevens onleesbaar gemaakt voor buitenstaanders. De geautoriseerde ontvanger kan de geëncrypteerde gegevens decoderen, waardoor de originele informatie weer verschijnt (decryptie).

Encryptie regelt dus:

  • versleutelde data (vertrouwelijkheid en privacy) op internet.

Een elektronische handtekening garandeert iemands identiteit. E-mails die bijvoorbeeld een koopakte, arbeidscontract of vervoersdocument bevatten en zijn voorzien van een gekwalificeerde elektronische handtekening, hebben dezelfde rechtskracht als hun papieren evenknie.

Uitvoering
Van de elektronische handtekening bestaan drie uitvoeringen:

  • Een gewone (niet-gekwalificeerde) elektronische handtekening.
  • Een geavanceerde elektronische handtekening is persoonsgebonden. U kunt hier mee aantonen waar het document van afkomstig is, maar de bewijslast ligt bij u. In Nederland kunt u hiervoor bijvoorbeeld bij Xolphin terecht.
  • Een gekwalificeerde elektronische handtekening is persoonsgebonden en juridisch compleet waterdicht. De bewijslast ligt in dit geval niet bij u, maar bij de ander. Via de website van een zogenaamde ‘Trusted Third Party’ (TTP) of certificatiedienstverlener is er eenvoudig een aan te vragen. Een lijst met certificatiedienstverleners staat op de site van de Aurtoriteit Consument & Markt.

De prijs van een elektronische handtekening wordt mede bepaald door het aantal dat u afneemt.

Gewone (of niet-gekwalificeerde) elektronische handtekening
De niet-gekwalificeerde elektronische handtekening is eenvoudig. Een e-mailbericht waaronder u uw naam zet, valt onder deze categorie, maar ook een ingescande handtekening. Voor het dagelijks berichtenverkeer is deze vorm toereikend, zolang er geen juridische gevolgen aan zijn verbonden. Nadeel is wel dat er niet met 100% zekerheid kan worden gezegd dat de aanvrager ook daadwerkelijk degene is die wordt genoemd.

Geavanceerde elektronische handtekening
Een geavanceerde elektronische handtekening kent meer waarborgen dan een ‘gewone’ handtekening. De Wet elektronische handtekeningen stelt er de volgende eisen aan:

  • de handtekening is op een unieke manier aan de ondertekenaar verbonden;
  • de handtekening maakt het mogelijk de ondertekenaar te identificeren;
  • de manier waarop de handtekening wordt gemaakt, staat onder exclusieve controle van de ondertekenaar;
  • de handtekening is op dusdanige wijze met het bestand – waarvoor het geldt – verbonden, dat elke naderhand aangebrachte wijziging kan worden opgespoord.

De geavanceerde elektronische handtekening is al verkrijgbaar voor een paar tientjes (onbeperkt gebruik).

Gekwalificeerde elektronische handtekening
Uiteraard is de geavanceerde elektronische handtekening ook persoonsgebonden. U koopt daartoe een persoonsgebonden certificaat (meestal op smartcard, of USB-stick).

Certificatiedienstverleners worden zogenoemde Trusted Third Parties (TTP) genoemd. Zij koppelen een unieke code aan een persoon en leggen die code vast in een digitaal certificaat. Het certificaat verbindt de gegevens voor het verifiëren van een handtekening aan een bepaalde persoon en bevestigt daarmee de identiteit van de eerstgenoemde persoon.

Tip v

Als tussentijds een nieuwe computer wordt aangeschaft, moet het bestand met daarop de elektronische handtekening ook mee verhuizen naar de nieuwe computer. Vaak wordt dit vergeten en moet de ondernemer halverwege de looptijd van de handtekening weer een nieuwe aanvragen. Een kostbare aangelegenheid en een hoop werk.
Zorg er dus voor dat u altijd een kopie van de betrokken bestanden hebt (uiteraard niet op dezelfde computer) en/of een back-up.

PKI-certificering
PKI (Public Key Infrastructure) is een basis voor veilige communicatie bij communicatie met een onbekende. Dat laatste komt in het ‘internet-tijdperk’ steeds vaker voor en PKI biedt dan de zekerheid dat u inderdaad van doen heeft met de persoon die een ander beweert te zijn.

Praktisch gesproken is het een verzameling van technische en organisatorische voorzieningen, waarmee versleuteling (encryptie) wordt ondersteunt. Een centrale rol hierbij wordt vervuld door een derde partij.
Die derde parij moet namelijk de identiteit bevestigen van de eigenaar van een bepaalde sleutel. Die validatie gebeurt door er een bewijs van vertrouwen – een certificaat – aan te koppelen. Dit digitale certificaat is voor iedereen het bewijs dat een publieke sleutel bij een bepaalde persoon hoort.

De derde partij wordt natuurlijk alleen maar vertrouwd, wanneer het een wettelijk erkende instelling is die algemeen vertrouwen geniet. Afhankelijk van de aard van hun dienstverlening wordt zo’n instelling Trusted Third Party (TTP) genoemd, Certification Authority (CA) of Certification Service Provider (gecertificeerde certificatiedienstverlener).

Een gekwalificeerde elektronische handtekening voldoet aan alle wettelijke eisen, is net zo betrouwbaar als een geschreven handtekening en heeft dus dezelfde rechtsgevolgen. Kortom: u bent voor 100% zeker van juridische bewijskracht.

Een geavanceerde elektronische handtekening kan overigens ook als juridisch bewijs gelden. Dat gebeurt dan op basis van gemaakte afspraken met uw wederpartij, afhankelijk van de aard van de transactie, het doel waarvoor de gegevens zijn verzonden of andere omstandigheden.

(Bron: De Zaak bewerkt)

 

Inleiding

Het sluiten van een goed IT-contract blijkt in de praktijk een hele kunst te zijn. Vaak bieden IT-contracten onvoldoende duidelijkheid over wat er precies geleverd en gepresteerd moet worden en onder welke voorwaarden. Ook komt het geregeld voor dat het contract – of de bijbehorende algemene voorwaarden – veel te eenzijdig zijn, zodat vrijwel alle verantwoordelijkheden en risico’s bij één partij komen te liggen.

Het loont om goed naar het contract te kijken. Een evenwichtig en volledig contract vormt weliswaar geen garantie voor een geslaagd project, maar kan de kans op mislukkingen wel aanmerkelijk verkleinen. Het inzoomen op de contractuele voorwaarden heeft bovendien vaak ook een helende werking, in die zin dat potentiële onduidelijkheden of risico’s nog voor het sluiten van het contract boven komen drijven en nog geadresseerd kunnen worden.

De vraag is uiteraard wat een goed contract is. Die vraag is moeilijk eenduidig te beantwoorden en zal afhangen van concrete omstandigheden van het geval. Met de onderstaande checklist kunt u zelf toetsen of uw IT-contract de belangrijkste te regelen zaken bevat. Uiteraard is daarmee nog niet gezegd dat de zaken ook goed geregeld zijn en dat uw belangen in het contract goed gewaarborgd zijn. Het verdient aanbeveling om ook dat te (laten) toetsen.

Het contract moet in elk geval antwoord geven op de volgende vragen:

Algemeen

  1. Wat is het onderwerp van de overeenkomst? Waar gaat de overeenkomst over en wat moet er dus allemaal in worden geregeld? Staat dit in de overwegingen en de rest van het contract voldoende duidelijk omschreven?
  2. Indien er meerdere overeenkomsten zijn: is de samenhang tussen de verschillende overeenkomsten goed geregeld?
  3. Indien er een aanbestedingsprocedure is gevolgd, blijkt dit uit de overwegingen? Zijn er voorzieningen getroffen voor het geval er zich gebreken voordoen in die aanbesteding?
  4. Zijn de bijlagen van de overeenkomst compleet en in de meest recente versie bijgevoegd? Is duidelijk hoe de bijlagen zich onderling verhouden?
  5. Zijn er algemene voorwaarden van toepassing verklaard en zijn deze bijgevoegd? Zijn deze voorwaarden acceptabel?

Leveringsomvang

  1. Is duidelijk omschreven welke producten er precies worden geleverd? Welke software, hardware en eventuele overige goederen?
  2. Is duidelijk omschreven welke diensten er precies worden geleverd? Denk bijvoorbeeld aan installatie en implementatie van software, het ontwikkelen van maatwerksoftware, consultancy, onderhoud, hosting, enz.
  3. Zijn er duidelijke specificaties voor de te leveren producten? Zo ja, zijn die opgenomen in of als bijlage bij de overeenkomst gevoegd?
  4. Zijn de te verrichten diensten duidelijk omschreven in de overeenkomst of de bijlagen?

Levertijden en implementatie

  1. Is bepaald wanneer de producten en diensten moeten worden geleverd? Gaat het hier om fatale termijnen of slechts om streefdata? (NB: let op eventuele bepalingen in de algemene voorwaarden)
  2. Indien er een implementatietraject nodig is: is er een goed plan van aanpak of ander document (zoals een PID of implementatieplan) en is dit onderdeel van de overeenkomst?
  3. Zijn de wederzijdse taken en verantwoordelijkheden voldoende duidelijk uitgewerkt? (wie doet wat en wanneer?)
  4. Moet er data worden overgebracht (gemigreerd en/of geconverteerd) van het oude naar het nieuwe systeem? Wie is daarvoor verantwoordelijk en welke eisen gelden daarvoor?
  5. Is er een duidelijke acceptatieprocedure in het contract opgenomen en is duidelijk welke rechten de afnemer heeft indien de producten/diensten niet geaccepteerd worden?

Software

  1. Indien er software wordt geleverd: hoe wordt de software afgenomen en is dit duidelijk vastgelegd in de overeenkomst? Gaat de software draaien op apparatuur van de afnemer of is er sprake van Software as a Service (SaaS), waarbij de afnemer via een netwerk toegang krijgt tot de software? Gaat het om cloud computing waarbij niet duidelijk is waar de software en/of data opgeslagen zijn?
  2. Indien sprake is van SaaS en cloud computing: zijn er voorzieningen getroffen om de beschikbaarheid van dat netwerk te borgen? Wat gebeurt er bij uitval van het systeem? Kunt u bij uw data? Worden er backups gemaakt, wie is daarvoor verantwoordelijk en waar worden deze opgeslagen? Voldoet het gebruikte netwerk aan de wettelijke eisen omtrent beveiliging en privacy?
  3. Dient er nog software ontwikkeld te worden en zo ja, wanneer en hoe en door wie?
  4. Is er sprake van open source software en zo ja, is hiermee rekening gehouden in de overeenkomst?

Licenties en intellectuele eigendom

  1. Dekken de software licenties het voorgenomen gebruik?
  2. Zijn er beperkende licentievoorwaarden en zijn die acceptabel?
  3. Indien er sprake is van software van derden, worden de licenties hiervoor meegeleverd? Is duidelijk welke partij kan worden aangesproken bij eventuele problemen met die licenties?
  4. Wie heeft de intellectuele eigendomsrechten op eventueel maatwerk?

Prijzen en betalingen

  1. Is voor alle te leveren producten en diensten duidelijk wat er betaald moet worden?
  2. Zijn de betaalmomenten duidelijk bepaald? Lopen de betalingen in de pas met de (deel)leveringen?
  3. Wat is er bepaald over prijsaanpassingen, meerwerk, minderwerk en indexatie?

Onderhoud

  1. Wat houdt onderhoud precies in? Alleen bugfixing of meer? Is er een aparte SLA met concrete service levels waaraan bepaalde onderhoudsprestaties moeten voldoen? Wordt gesproken over oplostijden of alleen responstijden?
  2. Zijn er sancties opgenomen voor het niet voldoen aan de onderhoudsverplichtingen / het niet halen van de service levels?
  3. Wat valt er niet onder het onderhoud? Zijn de daarmee samenhangende risico’s voldoende gewaarborgd in uw eigen organisatie of bij derde leveranciers?

Samenhang met andere software en hardware

  1. Moet de geleverde software/hardware samenwerken met bestaande systemen? Zo ja, komt dat voldoende duidelijk naar voren in de overeenkomst?
  2. Zijn er duidelijke afspraken welke partij in de implementatiefase de koppeling van de verschillende systemen realiseert? Is de eventueel noodzakelijke medewerking van andere partijen geregeld?
  3. Is duidelijk welke partij na implementatie kan worden aangesproken op het functioneren van het gehele systeem (de som der delen)? Is één partij eindverantwoordelijk, of coördineert één partij de werkzaamheden van alle betrokken partijen?
  4. Sluiten de bestaande contracten rondom de te koppelen systemen aan op het voorliggende contract?

Looptijd en beëindiging

  1. Wat is de ingangsdatum en de looptijd van de overeenkomst(en)?
  2. Kan de overeenkomst tussentijds worden opgezegd? Is er een voldoende ruimte opzegtermijn? Zijn de eventueel nadere voorwaarden hiervoor acceptabel?
  3. Kan de overeenkomst worden ontbonden bij bijvoorbeeld faillissement of wanprestatie van de andere partij?
  4. Wat zijn de gevolgen van een eventuele beëindiging? Is het noodzakelijk om voorzieningen te treffen voor de overstap naar een ander systeem bij het einde van de overeenkomst (zoals conversie van gegevens, eventueel verlengd gebruik van de software, etc.)? Zo ja, zijn die voorzieningen op acceptabele voorwaarden getroffen?

Aansprakelijkheid

  1. Zijn er voldoende mogelijkheden om schadevergoeding te claimen in geval van tekortkomingen (bijvoorbeeld te late of ondeugdelijke levering of ernstige verstoringen in het gebruik)?
  2. Is de wederpartij voldoende solvabel om een schadevergoeding in voorkomend geval te betalen? Zijn er voorzieningen getroffen om het risico op een slechte solvabiliteit te ondervangen (verzekering, bankgarantie, etc.)

Overige bepalingen

  1. Is Nederlands recht van toepassing? Is de Nederlandse rechter bevoegd?
  2. Willen partijen de mogelijkheid hebben eventuele geschillen te beslechten via arbitrage of mediation?

(Bron: Dirkzwager)

 

Cloud computing krijgt steeds meer marktaandeel in de informatiemaatschappij. Cloud computing is een breed begrip, maar is eigenlijk een benaming voor de vele varianten van client-server technologie. Bij cloud computing kan het gaan om Software as a Service (SaaS), Desktop as a Service, Platform as a Service en de vele “XaaS”-businessmodellen die tegenwoordig gangbaar zijn en gebruik maken van de technieken achter cloud computing. Voor continuïteit is een multidisciplinaire aanpak nodig: niet alleen juridisch, maar ook niet alleen technisch.

Het uitbesteden van ICT is mogelijk, maar voor de verantwoordelijkheid geldt dat niet. De cloudafnemer is verantwoordelijk voor de continuïteit van “zijn” informatiesysteem en gegevensverwerking, niet zijn leverancier. Dat valt op te maken uit de wetgeving: zo eisen belastingwetten (fiscale bewaarplicht) en administratieplichten de beschikbaarheid van uw gegevens gedurende een jarenlange termijn. Administratie in de cloud moet ten minste 7 jaar inzichtelijk kunnen worden gemaakt. De beschikbaarheid van de cloud-oplossing en daarmee verwerkte gegevens is dus noodzakelijk voor het voldoen aan wettelijke plichten. Dit nog buiten de bedrijfskritische aard die een cloud-oplossing kan krijgen doordat de uitvoering van bedrijfsprocessen daarvan afhankelijk wordt. Met andere woorden: zonder de clouddienst kan het werk niet gedaan worden.

Het nemen van verantwoordelijkheid doen zowel cloudafnemers als hun leveranciers door het opzetten van een continuïteitsregeling. Het doel van die continuïteitsregeling is allereerst het onafgebroken gebruik veilig stellen: de calamiteit bij de cloud- of SaaS-leverancier moet zo min mogelijk gevolgen hebben voor de bedrijfsprocessen van de afnemer. Ten tweede moet de continuïteitsregeling oog hebben voor de lange termijn. Migreren naar een andere oplossing heeft niet de voorkeur, zeker als die behoefte er ook niet is en de oplossing – ondanks het wegvallen van de leverancier – tot tevredenheid is.

Voor het zekerstellen van de continuïteit van Cloud- en SaaS-diensten, is een broncode-escrowregeling niet voldoende. De broncode-escrowregeling stelt alleen het gebruik, onderhoud en doorontwikkeling van de software veilig. Voor het veiligstellen van een clouddienst, is veel meer nodig. De hardware en data staan immers niet meer op de systemen van de afnemer, maar bij zijn leverancier of een derde (hostingprovider). Voor hosted desktop omgevingen is het nodig dat licenties van softwaretoeleveranciers (bijvoorbeeld op besturingssystemen en virtualisatiesoftware) in stand blijven. Ook kan het beheer en de helpdesk essentieel zijn: arbeidskrachten van de leverancier dus.

Een continuïteitsregeling voor cloudoplossing is altijd maatwerk. Er dient allereerst door een gekwalificeerde IT-deskundige onderzocht te worden welke componenten van het informatiesysteem noodzakelijk zijn voor continuïteit. Vervolgens wordt bekeken welke technische maatregelen nodig zijn: controle en deponering van een broncode, het opstellen van een calamiteitenplan, het verzamelen van contactgegevens van essentiële personen, en periodieke hercontrole van de getroffen maatregelen.

Ook zijn juridische maatregelen essentieel: een goede contractenset is noodzaak. Zo maakt het bijvoorbeeld verschil of de leverancier eigenaar is van de hardware waarop de cloud-oplossing wordt uitgevoerd, of dat hij deze huurt. Wanneer software van toeleveranciers (bijvoorbeeld van besturingssystemen en virtualisatiesoftware) onderdeel uitmaakt van de clouddienst, moeten er onderhandelingen plaatsvinden en afspraken worden gemaakt. Hetzelfde geldt voor de inzet van essentiële arbeidskrachten. Wanneer een hostingprovider of co-locatieprovider essentiële diensten levert, moet er worden bekeken hoe deze wordt doorbetaald. Daarbij zijn diverse oplossingen mogelijk, zoals het juridisch onderbrengen van de oplossing bij een Stichting Continuïteit, het oprichten van een garantiefonds en/of opzetten van een notariële doorbetalingsregeling.

(Bron: http://www.it-jurist.nl)

Met een merk kunt u uw producten of diensten onderscheiden van die van uw concurrenten. Een merk wordt pas beschermd, nadat het is geregistreerd. Hoe werkt een dergelijke registratie?

Een merk kan worden geregistreerd bij het Benelux-Bureau voor de Intellectuele Eigendom (BBIE). Door deze registratie krijgt u het exclusieve recht op het gebruik van het merk voor bepaalde producten en diensten binnen de Benelux. De inschrijving is in eerste instantie 10 jaar geldig, maar deze kunt u na 10 jaar verlengen. U dient wel zelf uw merk actief in stand te houden in de markt. Tijdens de registratieperiode wordt u merk beschermd.

Wat kunt u registreren?

Er zijn verschillende soorten merken:

  •          Woordmerk: naam van product of dienst
  •          Beeldmerk: logo
  •          Vormmerk: vorm van een product
  •          Kleurmerk: bepaalde kleur(en) combinatie
  •          Klankmerk: geluid behorend bij een product of dienst (reclamejingle)

U dient uw merkaanvraag te kijken binnen welke classificatie uw product of dienst valt. Er zijn 45 klassen waarin een merk kan worden geregistreerd.

Hoe lang duurt het registratieproces?

Meestal duurt het registratieproces een maand of 3. Uw depot moet aan alle wettelijke vereisten voldoen en er kan nog oppositie tegen uw depot worden ingesteld. Het proces ziet er als volgt uit:

IT-jurist merkregistratie

bron: https://www.boip.int

Wanneer wordt u merkaanvraag geweigerd?

Het BBIE kan uw merkaanvraag weigeren bij de volgende gevallen:

  •          Het teken is beschrijvend
  •          Het teken mist onderscheidend vermogen
  •          Het teken is misleidend
  •          Het teken is een vlag, wapen of ander officieel embleem
  •          Het vormmerk overlapt met andere intellectuele eigendomsrechten
  •          Het merk is in strijd met openbare orde en goede zeden

Wat kost het registreren van een merk?

Een online merkregistratie kost 240 euro. Indien u liever de registratie op papier wilt regelen, dan zijn de kosten 15% hoger.

(Bron: http://www.it-jurist.nl/)

 

Wil jij na de start van je bedrijf een bedrijfspand of kantoorruimte gaan huren? Zorg dan ervoor dat je niet te veel betaalt en voorkom ongewenste bepalingen in je huurcontract. De tips in dit artikel helpen je verder bij het onderhandelen.

Met wie krijg je te maken?

Met een huurcontract voor een pand of ruimte ga je een serieuze verbintenis aan, vaak voor langere tijd. Probeer (al voordat je de onderhandelingen ingaat) te achterhalen met wie je te maken hebt. Wat is het belang van de makelaar, belegger of projectontwikkelaar? Er is doorgaans veel geld mee gemoeid. Om sterker in je schoenen te staan, kun je je eventueel laten bijstaan door een juridisch-, bouwkundig- of huisvestingsadviseur.

Succesvol onderhandelen

Over het huurcontract en de prijs valt altijd te onderhandelen. Hoe groter de oppervlakte, des te meer voordeel je eruit kunt halen. Maar ook bij kleinere panden kun je behoorlijk besparen wanneer je goed op de volgende punten let:

1. Huurvrije periode

Je kunt onderhandelen over een huurvrije periode. Deze kan uiteenlopen van een maand bij een kortlopend contract tot soms wel twee jaar bij een langlopend contract. Maar pas op: een huurvrije periode levert niets op als de huurprijs die daarna moet worden betaald een stuk hoger is dan marktconform.

2. Prijs-kwaliteit

Huur je het pand kaal, ligt er vloerbedekking, moeten er tussenwandjes komen, et cetera? Een lage huurprijs is weinig waard als je zelf moet opdraaien voor het schilderen van de muren, aanleggen van brandvoorziening en het installeren van airconditioning. Waarin moet geïnvesteerd worden en is dit in verhouding met de huurprijs? Het kan soms een stuk goedkoper zijn als de ruimte ‘compleet af’ wordt gehuurd.

3. Leeg opleveren?

Hoe moet het pand worden achtergelaten bij vertrek? Moet het leeg opgeleverd worden of teruggebracht in de oude staat? Dit is heel belangrijk om te weten voordat je gaat investeren in aanpassingen aan het pand. Het kan aardig in de kosten lopen wanneer het pand na je vertrek in oude staat moet worden hersteld.

4. Servicekosten

Zijn de servicekosten bij de huurprijs inbegrepen en zo niet, hoe worden deze dan verrekend? Betaal je vooruit of zijn het vaste kosten? Je zou niet de eerste ondernemer zijn die zich rot schrikt van de eindafrekening.

5. Flexibiliteit

Is het mogelijk om ruimte erbij te huren, of ruimte af te stoten? Het kan veel geld kosten om een nieuwe ruimte te huren of te blijven huren met onderbezetting. En kun je tussentijds opzeggen? Op welke termijn?

6. Vergunningen

Zijn alle benodigde vergunningen er? Als een pand lang leeg heeft gestaan, moet er bijvoorbeeld een legionella- en asbestvrij-verklaring zijn. De verhuurder kan zeggen dat alles in orde is, maar wat als later blijkt dat er toch asbest in het pand zit? De verhuurder heeft meldplicht, maar de huurder heeft ook vraagplicht. Als er niet naar gevraagd is, wie is er dan verantwoordelijk?

7. Oppervlakte

Er wordt soms gesjoemeld met de oppervlakte. Deze moet in het contract staan volgens de NEN2580-norm. Hierbij wordt onderscheid gemaakt in BVO (Bruto Vloeroppervlak), NVO (Netto Vloeroppervlak) en VVO (Verhuurbaar Vloeroppervlak). Dit verschil kan in sommige gevallen flink oplopen. Sommige onderdelen van een gebouw mogen bijvoorbeeld niet als verhuurbaar vloeroppervlak worden aangemerkt. Denk aan technische ruimtes, lift of trappenhuis en kijk ook naar de verrekening van algemene ruimtes, zoals de entree en ontvangstbalie.

(Bron: MKB Servicedesk)

 

De Nederlandse vennootschap Twoh International BV (hierna: Twoh) heeft in 1996 computeronderdelen geleverd aan in Italië gevestigde ondernemers. De levering zou ex-works (“af-fabriek”) plaatsvinden, zodat Twoh er alleen toe gehouden was de goederen in een opslagplaats in Nederland ter beschikking te stellen. De kopers waren verantwoordelijk voor het vervoer van de goederen naar Italië. Twoh heeft van de kopers geen verklaring ontvangen waaruit bleek dat de goederen naar Italië zijn vervoerd. Desondanks is zij er altijd vanuit gegaan dat zij intracommunautaire leveringen heeft verricht, heeft zij facturen uitgereikt zonder vermelding van btw en heeft zij ook geen btw voldaan. Na een boekenonderzoek heeft de Belastingdienst zich op het standpunt gesteld dat niet was aangetoond dat de computeronderdelen naar een andere lidstaat waren vervoerd of verzonden, zodat Twoh ten onrechte het nultarief had toegepast. Aan Twoh werd een naheffingsaanslag van ƒ 1.466.629 (ruim € 665.000) aan btw met een verhoging van 100% opgelegd. De inspecteur verweet Twoh namelijk primair voorwaardelijk opzet en subsidiair grove schuld. Twoh heeft hiertegen bezwaar en beroep aangetekend.

Na een oordeel door Hof Arnhem – die de naheffingsaanslag en verhoging weliswaar verminderde, maar niet vernietigde – heeft Twoh cassatieberoep ingesteld, waarna de Hoge Raad in 2005 de zaak heeft voorgelegd aan het HvJ EU. Het HvJ EU oordeelde in 2007 dat de lidstaat van de leverancier niet verplicht is om inlichtingen in te winnen bij de lidstaat van bestemming omtrent de toepassing van het nultarief. De Hoge Raad oordeelde vervolgens dat Hof Arnhem voor de toepassing van het nultarief bij afhaaltransacties een te zware bewijslast heeft opgelegd en heeft de zaak doorverwezen naar Hof Den Bosch ter verdere behandeling en beslissing.

Hof Den Bosch heeft recent geoordeeld dat de naheffingsaanslag moet worden verminderd tot ƒ 145.108 (circa € 66.000). De inspecteur is er namelijk niet in geslaagd om, tegenover de betwisting door Twoh, aannemelijk te maken dat aan een drietal facturen leveringen ten grondslag liggen die voor de btw een belastbaar feit opleveren. Het hof is voorts van oordeel dat het argument van de inspecteur dat Twoh wist of had moeten weten dat zij de toepassing van het nultarief moest onderbouwen met boeken en bescheiden, onvoldoende is om Twoh voorwaardelijk opzet en grove schuld te verwijten. De verhoging met 100% is daarom onterecht.

(Bron: BTW Plaza)

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.

(Bron: De ITjurist / http://www.it-jurist.nl/)