ECLI:NL:RBLIM:2023:4161

vonnis RECHTBANK LIMBURG Burgerlijk recht Zittingsplaats Roermond zaaknummer / rolnummer: C/03/296054 / HA ZA 21-455 Vonnis van 19 juli 2023 in de zaak van de besloten vennootschap met beperkte aansprakelijkheid STUCOMM BV., gevestigd te UTRECHT, eiseres in conventie, verweerster in reconventie, advocaat mr. P.H. van der Vleuten te Utrecht, tegen de stichting STICHTING GILDE OPLEIDINGEN, gevestigd te Roermond, gedaagde in conventie, eiseres in reconventie, advocaat mr. P.P.A-H. van den Heuvel te Heerlen. Partijen zullen hierna Stucomm en Gilde genoemd worden.

1.1. Het verloop van de procedure blijkt uit: 1. de dagvaarding 2. de conclusie van antwoord in conventie en eis in reconventie 3. de conclusie van antwoord in reconventie 4. het proces-verbaal van mondelinge behandeling van 26 september 2022. 1.2. Verwijzing naar bijlagen vindt plaats door vermelding van het nummer van het processtuk gevolgd door het nummer van de bijlage. 1.3. Ten slotte is vonnis bepaald.

2.1. Stucomm is een jong bedrijf dat een app heeft ontwikkeld voor scholieren en studenten aan MBO en HBO en universiteiten. Met de app kan op een smartphone allerlei informatie over lesroosters en behaalde resultaten worden opgehaald. 2.2. Gilde Opleidingen is een opleidingsinstituut met ongeveer 9.000 studenten op diverse locaties in Noord- en Midden Limburg voor middelbaar beroepsonderwijs (MBO), Vavo en volwasseneneducatie. 2.3. Partijen hebben op 4 september 2020 een overeenkomst van opdracht gesloten waarbij Stucomm haar studentenapp voor 40.000 euro zou implementeren bij Gilde en daarna in licentie zou geven voor 34.000 euro per 10 maanden (bijlage 1,3). De looptijd van de overeenkomst zou met ingang van 1 november 2020 een duur hebben van 22 maanden (art. 2.1 overeenkomst). In art. 3.4 van de overeenkomst is opgenomen dat als de ingebruikname eerder of later is, de licentie factuur daarop zal worden aangepast. 2.4. In de maanden september tot en met 16 november 2020 voert Stucomm in overleg met Gilde diverse werkzaamheden uit die tot doel hebben om tot implementatie van de app te komen (zie technische specificaties bijlage 1,4 en mailwisselingen bijlage 1,5). Op 16 november 2020 deelt [projectleider] namens Gilde mee dat ‘de stuurgroep’ heeft besloten om het project te staken (onderdeel van bijlage 1,5). Nadat Gilde bij dat besluit volhardt en ook de toegang tot databases blokkeert die nodig zijn voor implementatie, sommeert de raadsman van Stucomm bij brief van 19 januari 2021 Gilde tot voortzetting van medewerking aan het implementeren van de app, bij gebreke waarvan aanspraak op schadevergoeding wordt gemaakt (bijlage 1,7). Dit leidt ertoe dat Gilde bij brief van 26 januari 2021 Stucomm in gebreke stelt en sommeert om uitvoering te geven aan de overeenkomst (bijlage 1,8). Dat voert tot een bespreking tussen partijen waarvan Stucomm op 11 maart 2021 per mail een gespreksverslag aan Gilde toestuurt (bijlage 2,5). Bij brief van 18 maart 2021 ontbindt Gilde de overeenkomst omdat Stucomm niet in staat is gebleken om de app conform bestek op te leveren (bijlage 1,13). 2.5. Stucomm stelt dat Gilde de overeenkomst onbevoegd dan wel onterecht heeft ontbonden. Hetgeen Gilde wilde dat in de app zichtbaar was, was niet overeengekomen. En zo wel, dan verkeerde Gilde in schuldeisersverzuim door er niet aan mee te werken dat Stucomm kon zorgen dat die gegevens alsnog zichtbaar werden. Stucomm stelt dat zij schade lijdt doordat zij projectkosten niet vergoed krijgt die zij wel gemaakt heeft. Stucomm vordert een verklaring voor recht dat de beëindiging van de overeenkomst door Gilde een toerekenbare tekortkoming is en Gilde jegens Stucomm aansprakelijk is en dat die schade wordt vastgesteld in een afzonderlijke schadestaat procedure. 2.6. Gilde voert het volgende verweer. a. De app voldoet niet aan de overeenkomst b. De app is niet tijdig opgeleverd c. De door Gilde gewenste functionaliteiten behoorden tot de overeenkomst d. Er is geen sprake van een gezamenlijk ontwikkeltraject, maar van een kant en klare app e. Er is geen sprake van schuldeisersverzuim aan de zijde van Gilde f. De tekortkomingen rechtvaardigden de ontbinding g. Gilde heeft de overeenkomst op 18 januari 2021 rechtsgeldig ontbonden h. Het stopzetten van het project op 16 november 2020 is niet op te vatten als een ontbinding. 2.7. In reconventie vordert Gilde verklaringen voor recht dat Stucomm toerekenbaar tekort is geschoten in de nakoming van de overeenkomst en dat Gilde de overeenkomst rechtsgeldig heeft ontbonden. Gevorderd wordt om Stucomm ten titel van schadevergoeding voor projectkosten tot 14.040 euro te veroordelen en voor overige schade de zaak te verwijzen naar een schadestaatprocedure. Stucomm voert verweer. 2.8. De rechtbank zal hierna uitvoerig op de details ingaan.

Aard en inhoud van de overeenkomst Inleiding 3.1. In deze zaak is het van belang om vast te stellen wat partijen zijn overeengekomen, omdat zij daarover van mening verschillen. Voor een juist begrip is van belang dat het onderwerp van deze overeenkomst: het implementeren van een studentenapp, geen alledaags product is en op zijn minst genomen enige kennis en inzicht in informatietechnologie vereist. Dat inzicht kan ontleend worden aan het als onderdeel van de overeenkomst opgenomen ‘Plan van aanpak’ (zie artikel 1.5 van de overeenkomst, bijlage 1,3). Daarin legt Stucomm uit dat er twee parallelle trajecten zijn, te weten een backend (data) traject en een frontend (app ontwikkeling) traject. Citaat (blz. 13, 4e alinea): “StuComm levert een stadaard app die in de huisstijl van Gilde zal worden geleverd. Het frontend traject richt zich op het realiseren van de app. StuComm streeft ernaar om zo snel mogelijk een eerste versie van de app te leveren met beperkte functionaliteit. Welke functionaliteit al wel beschikbaar is is afhankelijk van de voortgang van het backend traject”. In deze procedure is gebleken dat het frontend traject geen punt van discussie vormt en kennelijk uitgevoerd was. 3.2. Over het backend traject is opgenomen (blz. 13, 5e alinea): “In het backend traject is het als eerste belangrijk om overeenstemming te bereiken over de manier waarop gegevens uitgewisseld zullen worden. StuComm streeft naar het gebruik van standaarden. Daartoe heeft StuComm zelf een REST API specificatie opgesteld. Daarnaast sluit StuComm graag aan bij andere standaarden zoals OOAPI. Gilde zal REST API’s aanbieden, waarna StuComm koppelingen met deze REST API’s zal realiseren en/of configureren”. In het vervolg (blz. 14, 3e alinea) zegt Stucomm dat zij heeft begrepen dat Gilde in staat is om REST API’s op te leveren voor de ontsluiting van de data voor de verschillende features. Citaat: “In de regel geldt dat er eenmalig een investering noodzakelijk is voor het realiseren van koppelingen. Dat kan zowel aan de kant van StuComm als aan de kant van Gilde zijn. Na deze eenmalige investering zal er gedurende een doorlooptijd capaciteit beschikbaar moeten zijn voor finetuning en bugfinding”. Vervolgens wordt (op blz. 14 en 15) aangegeven welke tijd wordt verwacht dat Gilde per week kwijt zal zijn aan het implementeren van de app. Uitgaande dat nummers 7 tot en met 11 betrekking hebben op het backend traject, gaat het om 11,5 uur per week door een integratie specialist. 3.3. Zoals hierboven al blijkt, en aangevuld met kennis ontleend aan internet, is een API (de afkorting van Application Programm Interface) een verbinding tussen in dit geval voor de app relevante informatie van Gilde en de app. De term REST (afkorting voor Representational State Transfer) is een bepaalde specificatie van een API. Wat hierboven dan staat, is dat er een verbinding moet worden gemaakt tussen de gegevens / databases van Gilde en de app, die daaruit kan putten voor de informatie die aan een ingelogde student kan worden verstrekt. Stucomm gaat er kennelijk vanuit dat Gilde over die verbindingen beschikt én dat van beide partijen een investering vereist is om die verbindingen tot stand te brengen en goed werkend te krijgen. Deze passages uit het contract zijn in tegenstrijd met het verweer sub d, dat sprake was van een kant en klare app, waardoor dat verweer niet kan slagen. 3.4. Een complicerende factor is dat een deel van de gegevens waarmee de app verbonden moet worden, door Gilde aan Eduarte ter beschikking is gesteld. Eduarte presenteert zich op haar website als volgt: “Eduarte is het flexibele studenteninformatiesysteem voor meer dan 400.000 mbo-studenten. Met Eduarte heb je je administratie op orde en wordt het management goed geïnformeerd met eenduidige en betrouwbare stuurinformatie. Het biedt vlekkeloze informatievoorziening voor student, docent, administratie en management”. 3.5. In het (eveneens) als onderdeel van de overeenkomst opgenomen aanbestedingsdocument (bijlage 1,3 blz. 9-12, beter leesbaar als bijlage 1,14) is onder 3.2: “Koppelingen” onder 3.2.12 opgenomen dat in (een koppeling met) Xedule roosterafspraken met realtime informatie opgehaald moeten kunnen worden en is onder 3.2.6 onder “Eduarte” het volgende opgenomen: “De app moet de benodigde informatie kunnen ophalen uit Eduarte via het generieke koppelvlak van EduArte (webservices). Dit moet realtime informatie bevatten”. Bij toelichting staat: “Het betreft minimaal de gegevens: Roepnaam, tussenvoegsel, achternaam, actieve verbintenis, vakschool, organisatie eenheid, locatie, opleiding, niveau, leerweg, status verbintenis, groep(en) e-mailadres student, ouders/ verzorgers, alle gegevens van de roosterafspraken (datum/tijd, gekoppelde medewerker etc.)”. 3.6. Partijen hebben voorafgaand aan het sluiten van de overeenkomst intensief met elkaar onderhandeld. Naar aanleiding van een voorstel van Stucomm van 15 oktober 2019 geeft [medewerker] van Gilde bij mail van diezelfde dag aan 5 andere medewerkers van Gilde zijn bevindingen over dat voorstel (bijlage 2,1). Hij schrijft zelf dat het allemaal vrij negatief klinkt, en het dat technisch bekeken ook is. Over de connectie met Eduarte via een Reporting database (kennelijk door Stucomm voorgesteld) spreekt hij voorkeur uit om gebruik te maken van bestaande API’s omdat (samengevat) een Reporting database storingsgevoelig is én geen ondersteuning vanuit Eduarte (Iddink) geeft op juiste werking van de koppeling en Gilde zelf verantwoordelijk is voor datavergaring. Ook: “Bij een API wordt dit door de leverancier ontwikkeld en getest. Nu moet Stucomm dit voor ons ontwikkelen en zijn wij verantwoordelijk voor (de) controleren van (de) zowel de werking als de juistheid van de gegevens”. 3.7. Op 22 november 2019 mailt [medewerker] aan twee (van eerder vermelde 5) medewerkers van Gilde (ook bijlage 2,1) dat naar aanleiding van zijn eerdere opmerkingen (en die van iemand anders) een conference call bij ROC Zadkine is geweest waaruit bleek dat Zadkine dezelfde uitdagingen had als dat zij ( [medewerker] en een collega) reeds voorspeld hadden. Hij suggereert dat Gilde bij Zadkine kan langsgaan om na te gaan in hoeverre hun koppeling bij hen toepasbaar is, maar dat zij dit dan wel zelf moeten doen en daarin weinig hulp hoeven te verwachten van Stucomm. Hij eindigt ermee dat als ze echt een app willen, dat ze dan kunnen heroverwegen om die toch zelf te ontwikkelen. Hoewel de in deze en de vorige alinea intern geformuleerde kritiek niet eerder dan in deze procedure met Stucomm gedeeld is, zijn de bevindingen toch zodanig aan Stucomm overgebracht dat deze op 5 december 2019 een nieuw voorstel heeft gedaan (bijlage 2.5, waarover hierna meer).

3.8. Stucomm stelt dat de aanbesteding de voortzetting vormde op de lopende onderhandelingen en alleen in gang werd gezet omdat een openbare aanbesteding de enige weg was waarop de lopende onderhandelingen konden worden omgezet in een overeenkomst. Gilde ontkent dat verband en stelt dat de eisen die zij in de aanbesteding stelde, afweken van wat Stucomm eerder had geboden en dat Gilde aannam dat door de beantwoording van de vragen Stucomm nu wel een kant en klare verbinding met Eduarte kon leggen. 3.9. De rechtbank verwerpt de lezing van Gilde. Bij overeenkomsten komt het aan op hetgeen partijen over en weer van elkaar mogen verwachten. Het is volstrekt onaannemelijk dat als Gilde in november 2019 uit de aanbiedingen van Stucomm afleidde dat Stucomm niet in staat was om een geavanceerde verbinding met Eduarte tot stand te brengen (hetgeen Stucomm wilde ondervangen door een Reporting database), dat zij een half jaar later op goede gronden aannam dat dit helemaal anders was. Van Gilde had mogen worden verwacht (zoals Stucomm bepleit) dat als zij meer of iets anders verlangde dan Stucomm eerder als (on)mogelijk had aangegeven, dat zij dan uitdrukkelijk had geverifieerd of onderzocht of Stucomm daartoe inmiddels wel in staat was. Dat geldt temeer omdat Stucomm niet op de hoogte was van de zeer gedetailleerde kritiek die Gilde blijkens de interne mails van 15 oktober en 22 november 2019 op de app had. 3.10. Ook uit het plan van aanpak, dat onderdeel uitmaakt van de overeenkomst, kan niet worden afgeleid dat Gilde erop mocht vertrouwen dat Stucomm opeens wel over REST API’s zou beschikken waarmee geavanceerde informatie aan Eduarte kon worden onttrokken ten behoeve van de app. Zoals hierboven geciteerd (par. 3.2) gaat Stucomm er zelfs vanuit dat Gilde de verbindingen zal aanleveren, althans dat partijen daaraan een gezamenlijke inspanning moeten leveren. De randvoorwaarden 3.11. Na aanvang van de werkzaamheden rond 7 september 2020 gaat het vrij snel erna mis. Op maandag 16 november 2020 schrijft [projectleider] van Gilde (in de overeenkomst genoemd als projectleider) dat die dag door de stuurgroep besloten is om de ‘verdere implementatie en ontwikkelingen in dit project te staken’. Hoewel Stucomm aandringt op een bespreking, heeft Gilde daaraan geen behoefte zolang aan de volgende randvoorwaarden niet is voldaan: “1. De roosterwijzigingen in het lesrooster van de student dienen realtime in de app te zien te zijn. 2. De verrijking van het rooster in EduArte met persoonlijke roosterafspraken en huiswerkopdrachten moet in totaliteit zichtbaar zijn in de studenten app. 3. De weergave van de behaalde resultaten. Resultaten zijn in 1 oogopslag te zien door de student” (diverse keren in mails bijlage 1,5 maar ook in de brief van de raadsman van Gilde van 26 januari 2021, bijlage 1,8) 3.12. Stucomm betwist dat deze eisen terug te vinden zijn in de lijst van eisen en wensen, zoals deze als bijlage 1,3 en (leesbaar) 1,14 als onderdeel van de overeenkomst zijn opgenomen en hierboven in par. 3.5 voor zover van belang zijn geciteerd. De rechtbank oordeelt als volgt. 3.13. In oktober en november 2019 speelde dezelfde discussie. De kritische interne notities van Gilde (hierboven besproken in par. 3.6 en 3.7) werden gemaakt naar aanleiding van een (niet in deze procedure overgelegd) voorstel van Stucomm. Naar aanleiding van afwijzing van dat voorstel (omdat het teveel werk voor Gilde meebracht en een Reporting database niet optimaal actueel en storingsgevoelig was), doet Stucomm op 5 december 2019 een nieuw voorstel (bijlage 2,5) met oplossingen die Gilde ‘waarschijnlijk beter vindt passen’. Voor wat betreft de resultaten (het punt 3 in het citaat in par. 3.11) schrijft Stucomm: “Resultaten: deze data kan in de studentenapp getoond worden dmv de API van Eduarte. (Stucomm kan hiermee de resultaten van studenten ophalen – geen view nodig)”. In de afsluiting schrijft Stucomm: “(…) daarom willen wij het liefst wegblijven van moeilijke roosterverrijkingen vanuit Eduarte, de pilot zal aantonen of de roosterverrijking vanuit eduarte überhaupt een meerwaarde heeft om terug te zien in de app of dat het lesrooster sowieso voldoende is. Naar mijn inzien krijgt jouw afdeling tevens, met deze pilot-versie, een StudentenApp die past bij de visie die jullie voor ogen hebben (aan de hand van het geleverde Pakket van Eisen). In de licentiefase kunnen we verder kijken naar koppelingen die duurzaam kunnen worden opgebouwd”. 3.14. In het besprekingsverslag van 11 maart 2021 schrijft Stucomm onder het hoofdstuk “Resultaten” het volgende: “De webservice voor het ophalen van studieresultaten uit Eduarte functioneert niet zoals we gewend zijn bij andere onderwijsinstellingen. (…) Dit is voor ons en Gilde niet op te lossen. Het zou heel mooi zijn als jullie ons in staat willen stellen hierover namens jullie te communiceren met Iddink. Wij weten uit ervaring dat Iddink niet op vragen van ons direct antwoord geeft, maar als jullie ons in de cc meenemen, dan komt dat goed”. 3.15. In hetzelfde besprekingsverslag schrijft Stucomm onder het hoofdstuk “Rooster” dat die gegevens uit Xedule gehaald worden, maar dat als het wenselijk is dat ze verrijkt uit Eduarte gehaald worden ‘Zoals al eerder in november maar gisteren ook nog besproken’ zij twee alternatieven ziet, te weten via de reporting database van Eduarte dan wel via een uitbreiding van het generieke koppelvlak van Eduarte. Over deze tweede mogelijkheid merkt Stucomm op dat het de beste oplossing is en dat Stucomm daaraan ook wil meewerken, maar dat het van Eduarte afhangt of zij bereid is om die koppelingen ook te realiseren. 3.16. De rechtbank leidt hieruit af dat de generieke koppeling (API) wel de studieresultaten geeft, maar niet andere verrijkte gegevens. In de overeenkomst (blz. 11 onder 3.6.2, zie hierboven geciteerd in par. 3.5) wordt over gegevens gesproken die letterlijk “via het generieke koppelvlak van EduArte” zijn op te halen. Gilde wist precies (zie hierboven de hele gang van zaken over de voorstellen van Stucomm in oktober en november 2019) wat via dat generieke koppelvlak was op te halen en dat verrijkte roosterinformatie daar niet onder viel. Ook de toelichting op dit punt met de vrij algemene zinsnede “alle gegevens van de roosterafspraken (datum/tijd, gekoppelde medewerker etc.” is tegen de achtergrond dat dit in oktober- november 2019 een belangrijk discussiepunt was, onvoldoende helder om Stucomm het besef te bieden dat er iets gevraagd werd wat het generieke koppelvlak (naar beide partijen wisten) niet bood. 3.17. Het voorgaande voert tot de conclusie dat het ophalen van studieresultaten in de app wél onder de overeenkomst viel, maar andere verrijkte roosterinformatie niet. Is Stucomm tekort geschoten? 3.18. Stucomm erkent dat het niet lukte om de studieresultaten uit het generieke koppelvlak van Eduarte in haar app over te brengen (zie hierboven par. 3.14). Waar dit aan ligt, begrijpt Stucomm zelf niet, nu die koppeling bij andere onderwijsinstellingen kennelijk wel gelegd kan worden. De vraag is echter of dit een tekortkoming van Stucomm oplevert. Het kan immers ook zijn dat er iets mankeert aan de koppeling bij Eduarte. 3.19. Wat opvalt aan het hele dossier, is dat Stucomm er alles aan wil doen om een werkende app op te leveren. Bij Gilde lijkt die drive te ontbreken. Als Stucomm na de ‘No Go’ mail van 16 november 2020 aandringt op een bespreking, komt die er niet (mails bijlage 1,5).

3.24. Het voorgaande voert tot de slotsom dat de in conventie door Stucomm gevraagde verklaring voor recht dat Gilde toerekenbaar tekort is geschoten en daarvoor schadeplichtig is, toewijsbaar is. De onder II gevorderde verwijzing naar de schadestaat procedure zal ook worden toegewezen. De vorderingen in reconventie liggen voor afwijzing gereed. 3.25. Gilde zal als de in het ongelijk gestelde partij in de proces- en nakosten worden veroordeeld. Gelet op de samenhang tussen conventie en reconventie zal geen afzonderlijke kostenveroordeling in reconventie worden uitgesproken. De kosten aan de zijde van Stucomm worden begroot op: - dagvaarding € 90,42 - griffierecht 667,00 - salaris advocaat 1.915,00 (2,5 punten × tarief € 766,00) Totaal € 2.672,42

De rechtbank in conventie 4.1. verklaart voor recht dat de beëindiging door Gilde van de tussen partijen gesloten overeenkomst een toerekenbare tekortkoming is, voor de schade waarvan Gilde jegens Stucomm aansprakelijk is, 4.2. veroordeelt Gilde tot betaling aan Stucomm van een schadevergoeding nader op te maken bij staat en te vereffenen volgens de wet, In conventie en in reconventie 4.3. veroordeelt Gilde Opleidingen in de proceskosten, aan de zijde van Stucomm tot op heden begroot op € 2.672,42, 4.4. veroordeelt Gilde in de na dit vonnis ontstane kosten, begroot op € 173,00 aan salaris advocaat, te vermeerderen, onder de voorwaarde dat Gilde niet binnen 14 dagen na aanschrijving aan het vonnis heeft voldaan en er vervolgens betekening van de uitspraak heeft plaatsgevonden, met een bedrag van € 90,00 aan salaris advocaat en de explootkosten van betekening van de uitspraak, 4.5. verklaart dit vonnis uitvoerbaar bij voorraad, 4.6. wijst het meer of anders gevorderde af. Dit vonnis is gewezen door mr. H.H. Dethmers en in het openbaar uitgesproken op 19 juli 2023. type: HD