De toegangscode van een brandmelder opeisen

| AE 8080 | Informatiemaatschappij | 26 reacties

brandmelderIets dat we steeds vaker gaan zien: je wilt van je installateur of beheerder af, maar die heeft de toegangscodes of wachtwoorden en die wil hij niet zomaar afgeven. Sta je dan in je recht om ze op te eisen? Dat is een juridisch lastige vraag, want zo’n code is niets. Het is immers niet meer dan data. Maar in een recente rechtszaak vond de rechter toch een praktische oplossing.

Uit het vonnis blijkt dat een onderhoudsbureau een onderaannemer had ingehuurd die onder meer de brandmelder had geplaatst in het Rotterdam The Hague Airport Wings Hotel (hierna: “het hotel”, sorry wat een mond vol).

Die melder functioneerde niet naar behoren volgens de klant, maar de onderaannemer was stellig dat er niets aan de hand was. Weliswaar stond permanent het storingslampje aan, maar dat bleek een spookmelding te zijn zonder daadwerkelijke gevolgen. Ook kon een extern bureau geen grote problemen vinden. De rechter ziet dan ook geen problemen met de levering door die onderaannemer, dus die moet gewoon betaald krijgen voor zijn diensten.

Tussen de regels door krijg ik het gevoel dat het bureau klachten kreeg van het hotel omdat het ding maar bleef piepen of moeilijk doen. Zo ging de melder een keer af toen het buiten 45 graden was op een extra zonnige dag, of door douchestoom. Dus dan voelt het als een logische volgende stap om toch van die onderaannemer af te willen.

Met een ander verder gaan mag, ook als er geen echte klachten zijn. Maar nu wordt het ICT-spannend: wil je dat brandmeldsysteem onderhouden, dan heb je een code nodig (hierna: “de code”) en die wilde de onderaannemer niet zomaar afgeven. Na enig aandringen toch wel, maar dan alleen onder de volgende voorwaarden:

acceptatie van de gevolgen van de overdracht van de code aan een andere installateur door [het bureau];
verval van garantie en iedere aansprakelijkheid van [gedaagde1] voor de BMI;
afstand van aansprakelijkheid, korting of verrekening als gevolg van terugzetten code;
finale kwijting ter zake de BMI.

Dit zijn op zich gebruikelijke eisen. Alleen, mág je dat wel stellen als voorwaarde om een toegangscode, hierna: “de code”, te moeten afgeven? Nou nee, want nergens in het contract staat geregeld dat je alleen dan de code hoeft af te geven.

De spanning stijgt: op welke grond houdt de onderaannemer de code nu onder zich? De rechter komt uit bij het retentierecht. Je mag spullen onder je houden die van een ander zijn zolang die ander een afspraak niet nakomt. Alleen, in het contract stond dat het retentierecht niet ingezet mag worden, dus dat kan de onderaannemer vergeten. Code afgeven, einde oefening.

Echter, dit is wel raar, want het retentierecht geldt voor fysieke zaken en een toegangscode is dat niet. Oh pardon, toch wel:

Hierbij wordt opgemerkt dat de voorzieningenrechter de code beschouwt als een zaak als genoemd in artikel 3:290 juncto 3:2 BW, nu de code in deze gelijk te stellen aan een fysieke sleutel.

Dat klopt formeel niet helemaal, maar praktisch gezien wel. En voorzieningenrechters zijn er voor praktische oplossingen. En het is ergens ook wel te verdedigen dat een sleutel een zaak is: hij is voor menselijke beheersing vatbaar, vertegenwoordigt waarde en is in de praktijk uniek/verplaatsbaar. Codes deel je maar in beperkte mate en meestal is er maar een iemand die hem weet (als het goed is, wordt hij na overdracht snel gewijzigd immers). Dus dan klopt het ook formeel.

Arnoud

Deel dit artikel

  1. Als in een bodemprocedure toch blijkt dat de code geen zaak is, want niet fysiek, dan zou eiser alsnog het papiertje kunnen opeisen, waarop de geprinte code werd meegeleverd. En volgens mij zijn er wel meer rechtsgronden om die code op te eisen. Zoals het feit dat die brandmelder waarschijnlijk, weliswaar onder een dienstleveringscontract, gewoon gekocht was, en die code bij de koop hoort.

    • Een volledige brandmeldinstallatie (BMI, Arnoud doet het een beetje af als een standaard rookmelder die je voor 6 euro bij Lidl koopt) is een stuk maatwerk waar je U tegen zegt. Elke ruimte dient een slow-whoop te hebben, er moet een minimaal aantal handmelders op een verdieping aanwezig zijn en eventuele gesloten deuren moeten meteen uit het slot gaan bij een incident waarbij ontruiming noodzakelijk is. Het bedieningspaneel bevat vaak een groot display en dito bedieningsorgaan om de verschillende functies te kunnen controleren en besturen. Het paneel op Station Den Haag Centraal is bijvoorbeeld zelfs een 80cm touch-screen TV die grafisch alles weergeeft en laat bedienen. Zo’n BMI komt dan ook met een beschrijving/handleiding die bij een beetje kantoorgebouw makkelijk de 100 pagina’s passeert en vind je vaak bij de receptie van het gebouw. De codes tot de verschillende lagen van zo’n BMI staan zelden in die handleiding en horen alleen bij de bevoegde personen bekend te zijn. Die codes zijn een wezenlijk deel van de BMI (zonder die codes kun je bijvoorbeeld niet je BMI resetten naar bedrijfsstand bij een vals alarm) en bij verandering van onderhoudsbedrijf lijkt het me ook niet meer dan normaal dat die codes overgedragen worden aan de nieuwe partij, waarna die de codes verandert en deelt met de bevoegde personen.

      Een resetknopje vind je hooguit in de centrale-elektronica zelf, of moet via een console-kabel gebeuren.

      • Wat gebeurt er dan in de situatie dat het bedrijf dat de BMI serviced, failliet zou gaan of de eigenaar van dat bedrijf komt te overlijden? Hooguit komen die codes dan terecht in de failliete boedel, in het ergste geval worden ze dan vernietigd. Wat moet er dan met die BMI gebeuren als er een valse melding of een storing is? Is daar een universele resetcode voor die alleen bij de brandweer bekend is?

        • Dan heeft de fabrikant daar over het algemeen wel een oplossing voor: brandmeldinstallaties worden doorgaans niet ontwikkeld door startups die na drie jaar omvallen. 🙂 Achterdeurtjes en brandweer-only codes bestaan doorgaans niet, aangezien die toch wel een keer uitkomen. Het duurde bijvoorbeeld slechts een half jaar voordat de code voor de AED-kluizen op stations binnen de BHV- en EHBO-wereld algemeen bekend werd. Die code werkt op elke AED-kluis van NS en die aanpassen is een kutklus die z’n weerga niet kent en waarbij je levens in gevaar brengt als je die gaat wijzigen.

  2. De opstelling van de onderaannemer lijkt mij volstrekt logisch. Hij wil de code wel afgeven, maar dan wel de garantie dat hij geen enkele verantwoordelijkheid meer heeft voor de BMI. Immers, na het afgeven van de code kan er vanalles en nog wat veranderd worden zonder dat de onderaannemer daar zicht op heeft.

    Het afgeven van de code is m.i. net zoiets als het overdragen van het root password. Als ik dat gedaan heb, trek ik ook de handen van een systeem af. Er is dan namelijk voor mij geen enkel overzicht meer over welke wijzigingen er al dan niet aangebracht zijn.

    • De (onder)aannemer vraagt meer dan waar hij recht op heeft; met name op het punt waar hij de aansprakelijkheid voor geleverd (slordig) werk afwijst omdat iemand anders het onderhoud gaat doen. In principe geldt dat je als aannemer goed werk moet leveren en dat is nu net het punt dat hier ter discussie staat.
      Zeggen “Je mag alleen naar een competente onderhoudsorganisatie als ik mijn fouten niet hoef te herstellen.” is misbruik maken van de controle over de (sleutels) voor de installatie.

    • Waarom zou de onderaannemer nadat zijn contract beeindigd is uberhaupt nog verantwoordelijk zijn? Niet voor het gebruik van de installatie met behulp van de code lijkt me. Wel bijvoorbeeld eventueel voor onoordeelkundige aanleg van het systeem bijvoorbeeld die pas later aan het licht komt (kapotte kabels, verkeerde plaatsing melders). Het lijkt me niet redelijk dat het achterhouden van de code gebruikt wordt als dwangmiddel om van alle aansprakelijkheid daarvoor af te komen.

      Verder vind ik het vergelijkbaar met je verwarmingsinstallateur aan wie je de sleutel van je gebouw geeft. Je zegt het onderhoudscontract op, vervolgens wil hij alleen de sleutel teruggeven als je hem finale kwijting geeft voor alle eventuele aansprakelijkheden. Lijkt me niet redelijk. (even afgezien van het feit dat die sleutel zowiezo van jou is omdat je hem aan hem gegeven hebt; laten we zeggen dat hij zelf een kopie gemaakt heeft).

      Het interessante van een code (vergeleken met een echte sleutel) is verder natuurlijk dat als je hem eenmaal gegeven hebt (bijv. op basis van een gerechtelijke uitspraak) je eigenlijk nooit meer de exclusieve eigenaar wordt, ook als je later van de rechter uiteindelijk toch gelijk krijgt. Daarvoor is het te gemakkelijk om een code te kopieren, in sommige gevallen zelfs uit het hoofd te leren.

  3. Even een andere, vergelijkbare situatie: een freelance/ZZP’er heeft enkele socialemedia accounts aangemaakt voor een opdrachtgever en beheert deze ook. Maar de opdrachtgever wil vervolgens zelf het beheer overnemen en eisen dus de toegang op tot de diverse accounts. En ze gaan het contract opzeggen. Dat lijkt mij dus vergelijkbaar met deze situatie. Toch? En het is toch logisch dat de ZZP’er deze gegevens ook daadwerkelijk overdraagt?

    • Zodra het contract is opgezegd, zal de ZZP-er waarschijnlijk in overtreding zijn van de “real name” policies van verschillende sociale media. De opdrachtgever kan dan bij de socialemediabedrijven gaan klagen.

      Nou ben ik niet zo’n fan van die real name policies, maar hier zie ik wel een voordeel. Eigenlijk zou het niet zozeer een verplichting moeten zijn om je “echte”(*) naam te gebruiken, maar een verbod om opzettelijk andermans naam te gebruiken. Anoniem sociaal-media-en onder een fantasie-naam moet gewoon kunnen.

      (*) Wat is je “echte” naam? De naam waaronder je bij “de” overheid bekend staat? Dat zou de overheid te veel autoriteit geven, en daarnaast zijn er mensen die (door allerlei omstandigheden, bijv. transliteratie van Chinese namen) onder verschillende namen bekend zijn (bij verschillende overheden), of zelfs helemaal niet geregistreerd zijn bij een overheid.

  4. Volgens mij is het ook een kwestie “eigendom” versus “bezit”. “Eigendom” bepaalt wie er mag beschikken over iets; “bezit” bepaalt wie er werkelijk over beschikt. Iets dat is gestolen is eigendom van de bestolene, maar bezit van de dief. Bezit is iets fysieks, eigendom is iets sociaal/juridisch.

    De brandmelder is eigendom van het hotel (neem ik aan): het hotel mag er dus over beschikken. Alleen: in dit geval is het fysieke beschikken over de brandmelder niet voldoende, en is er een toegangscode nodig om helemaal over de brandmelder te kunnen beschikken. Indien het hotel er naar vraagt, dan moet de installateur dus de toegangscode geven, of een andere manier bieden waarop het hotel helemaal over de brandmelder kan beschikken.

    Ik vind eigenlijk dat je een dergelijk argument ook kunt toepassen op broncode van software. Ik ben in dat opzicht een beetje een Richard Stallman. 🙂

      • Ook als je een normale laptop met OEM windows koopt mag je verwachten dat die laptop, met alles er op en er aan, jouw eigendom wordt, en dat je er helemaal over mag beschikken. Aan de andere kant: het is algemeen bekend dat de broncode van windows niet zomaar aan de gebruiker wordt gegeven, dus van een geïnformeerde koper zou gezegd kunnen worden dat ‘ie daar impliciet mee akkoord gaat als ‘ie een windows-laptop koopt.

        Dat wil niet zeggen dat het normaal is. Met windows kan je een heleboel dingen gewoon niet doordat de broncode niet bekend is, bijvoorbeeld omdat het niet in het belang van Microsoft is om jou bepaalde mogelijkheden te geven. Je kunt dan als “eigenaar” gewoon niet volledig beschikken over de mogelijkheden van jouw laptop.

        Je hoeft nog niet eens zelf programmeur te zijn om van de beschikbaarheid van broncode te profiteren: met hulp van third parties kom je ook een eind, zelfs als die third parties niet specifiek in opdracht van jou als individu werken, maar gewoon generieke oplossingen maken die toevallig ook voor jou nuttig zijn.

        • (BEETJE OFFTOPIC DIT) Het is normaal in die zin dat het uitgangspunt van het contractenrecht is dat je met elkaar mag afspreken wat je wilt. Zij bepalen onder welke voorwaarden ze jou hun broncode geven. Je kunt voor een bepaald bedrag een gebruikslicentie krijgen en als je meer wilt gaat het feest dus niet door, ga maar naar iemand anders. Als jij een fles Coca-Cola koopt hoeven ze jou ook niet het recept te geven als ze dat niet willen. Jij kunt misschien niet alles doen met je laptop wat je zou willen, maar is dat de verantwoordelijkheid van Microsoft?

          Dan is er natuurlijk nog de hele discussie over auteursrecht op software en op de broncode, dus of je inderdaad een soort eigendomsrecht (auteursrecht) moet hebben op de door jou ontwikkelde software / broncode. Ik vind van wel maar het gaat wat ver om die discussie hier te voeren.

  5. Dit is gewoon een maas in de wet. De wet erkent alleen fysieke dingen die je kunt vastpakken als ‘zaak’, maar tegenwoordig heb je dingen als broncode, wachtwoorden en toegangscodes die een essentiëel vormen van een systeem. De maas is dat men het feit dat je ze niet vast kunt pakken aangrijpt (haha, woordgrap! niet fysiek – aangrijpen!) om iets onwerkbaar te maken. Terwijl de klant van mening is dat hij toch een werkend systeem heeft gekocht, blijkt het een doos nutteloze hardware te zijn als hij van het beheercontract af wil.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS