ICT~Office verbreedt en verdiept Fenit-voorwaarden

ICT~Office heeft de nieuwe ICT~Office Voorwaarden ten doop gehouden. De nieuwe leveringsvoorwaarden vervangen drie andere, eerder uitgegeven versies branchevoorwaarden, te weten de algemene voorwaarden Informatietechnologie (beter bekend als de Fenit-voorwaarden), de algemene voorwaarden ICT Telecom en de algemene voorwaarden Kantoortechnologie. Mr. Frits Mutsaerts geeft in dit artikel zijn visie op de nieuwe bepalingen die vroeger de Fenit-voorwaarden vormden.

Vergeleken met de Fenit-voorwaarden, waarvan de laatste versie in 2003 verscheen, hebben de ICT~Office Voorwaarden een geheel nieuwe structuur. Zij zijn modulair opgebouwd. Er is een module Algemeen die bruikbaar is voor alle typen ict-transacties. Daarnaast zijn er zestien specifieke modules (zie kader) die elk een bijzonder onderwerp regelen. Gezien de hoeveelheid nieuwe bepalingen per module is er duidelijk sprake van zowel een verbreding als een verdieping ten opzichte van de oude Fenit-voorwaarden.

Praktische tips

De nieuwe ICT~Office Voorwaarden kunnen uiteraard voor nieuwe contracten worden toegepast. Voor bestaande contracten gelden de oude Fenit-voorwaarden (en de overige oude voorwaarden), tenzij partijen zich uitdrukkelijk vastleggen op de nieuwe voorwaarden. Komt de cliënt de opdrachtgever hierin niet tegemoet dan blijven de oude voorwaarden gelden.

Voor nieuwe contractuele situaties geldt dat de leverancier de cliënt tijdig en volledig informeert over het gebruik van de ICT~Office Voorwaarden . Dit betekent dat hij uiterlijk voor of bij het sluiten van de overeenkomst met zijn cliënt de module Algemeen en toepasselijke specifieke modules aan de opdrachtgever moet verstrekken. De leverancier die hierin niet tijdig handelt, loopt het risico zich later niet meer op de algemene voorwaarden te kunnen beroepen.

Naast deze formele punten geldt ook een materiële toetsing. Indien de rechtsprekende instanties bepaalde aansprakelijkheidsbeperkingen respectievelijk -uitsluitingen in strijd achten met de redelijkheid en billijkheid in een concreet geval, dan kan die bepaling opzij worden gezet. Dit komt in de rechtspraak wel eens voor, zo merk ik uit eigen ervaring op.

Een andere praktische tip betreft de tegenstrijdigheid van voorwaarden. Niet zelden heeft de opdrachtgever inkoopvoorwaarden die hij van toepassing wil laten zijn op de relatie met de leverancier. Deze inkoopvoorwaarden zullen met stelligheid niet overeenkomen met de ICT~Office Voorwaarden. Het is zaak dat partijen duidelijk afspreken welke voorwaarden van toepassing zijn of hierin een compromis bereiken (hetgeen ik regelmatig heb meegemaakt).

Mochten partijen (leverancier, cliënt) het op bepaalde onderdelen van de voorwaarden oneens zijn, dan is het gebruikelijk en zinnig om een afwijkende regeling van de voorwaarden overeen te komen. Dit leidt dan vaak tot een aanvaardbaar en werkbaar compromis.

Inhoudelijk commentaar

Met betrekking tot het recht van intellectuele eigendom (artikel 8 van de algemene module) geldt als uitgangspunt dat deze rechten bij de leverancier blijven en dat de cliënt een gebruiksrecht verkrijgt. Bij ontwikkeling van programmatuur (module 2) worden de rechten gewoonlijk overgedragen aan de opdrachtgever. Dit moet uitdrukkelijk bij akte geschieden. Gebeurt daaromtrent niets, dan heeft de opdrachtgever gewoonlijk het nakijken. Nieuw is dat daarenboven in de module over webdesign (module 5) een meer specifieke IE-regeling is opgenomen.

In de aansprakelijkheidsbepaling (artikel 12 van de algemene module) valt op dat er anders dan in de Fenit-voorwaarden nu geen (limititieve) opsomming meer is van het begrip 'directe schade'. Dit betekent dat er in rechte vastgesteld moet worden wat nu precies directe en indirecte schade is. De voorwaarden zijn in die zin flexibeler geworden.

Anders dan in de Fenit-voorwaarden ontbreekt de bepaling die zegt dat er ook geen schadevergoeding meer geclaimd kan worden als de cliënt een overeenkomst wegens toerekenbare tekortkoming (wanprestatie) ontbindt.

Nieuw in de ICT-Office Voorwaarden is dat de aansprakelijkheidsbeperking nu ook expliciet geldt bij de schending van een garantieverplichting. De nieuwe voorwaarden versterken op dit punt de positie van de leverancier.

ICT-mediation bij de Stichting Geschillenoplossing Organisatie en Automatisering (SGOA) is in de nieuwe voorwaarden niet alleen onderdeel van de geschillenregeling (artikel 16 van de algemene module), maar maakt nu ook deel uit van de aansprakelijkheidsregeling. ICT-mediation wordt bestempeld als een schadebeperkende maatregel. De voorwaarden verplichten de strijdende partijen eerst zelf het geschil met behulp van mediation uit de wereld te helpen. Vervolgens vindt arbitrage plaats bij de SGOA, met één uitzondering: voor de zogeheten small claims, kunnen leverancier en/of cliënt kiezen voor de rechter.

Bij onderhoud van programmatuur (module 3) moet de cliënt zich de vraag stellen welke vorm van onderhoud hij wenst van de leverancier: correctief onderhoud en/of preventief onderhoud en/of adaptief onderhoud.

Volledig nieuw is Application Service Provision (asp), Software as a Service (SaaS) en computerservice (module 4). Voor de toepassing van deze module wordt onder asp en SaaS verstaan: Het door de leverancier op afstand beschikbaar stellen en beschikbaar houden van programmatuur aan de cliënt via internet of een ander netwerk, zonder dat aan cliënt een fysieke drager met de desbetreffende programmatuur wordt verstrekt.

Verder is vermeldenswaard de aanpassing aan de recente wetgeving inzake internet service providers (isp – artikel 6: 196 c lid 3 sub e BW) dat voorziet in de regeling inzake 'notice and take down'. De ICT~Office Voorwaarden zorgen ervoor dat de isp niet bekneld raakt tussen enerzijds een derde partij die (al dan niet terecht) klaagt over onrechtmatige informatie die via het systeem van de isp gaat, en anderzijds de cliënt van de isp.

Over de softwareontwikkeling (module 8) valt het volgende op te merken.
In de ICT~Office Voorwaarden worden zowel de klassieke als de moderne software ontwikkelmethoden ondersteund. Voor de klassieke software ontwikkeling geldt eerst de specificaties (functioneel ontwerp, technisch ontwerp) maken en daarna pas de software schrijven. Bij moderne software ontwikkeling worden specificaties 'werkendeweg' tijdens het project gemaakt en waar nodig bijgesteld, gelijktijdig met het bouwen van de software. Voorbeelden van die methode zijn de iteratieve software ontwikkeling en de agile software ontwikkeling.

Knap stukje ‘onderhoud’

Zonder overdrijving meen ik te kunnen concluderen dat de brancheorganisatie ICT~Office erin is geslaagd om een knap stukje 'groot onderhoud' aan de oude Fenit-voorwaarden te hebben gepleegd.

Mr. Frits Mutsaerts, ict-recht advocaat sinds 1982 en partner bij Banning Advocaten in Den Bosch