Waarom willen klanten van SaaS-maatwerk toch altijd het IE hebben?

| AE 11999 | Intellectuele rechten | 19 reacties

Een lezer vroeg me:

Ik ontwikkel SaaS-oplossingen op maat, op basis van mijn eigen basisapplicatie. Elke keer weer krijg ik discussie met de klant (meestal zijn advocaat, trouwens) dat ze het IE van het maatwerk willen hebben. Als ik dan zeg dat ze daar niets aan hebben, omdat ik de basisapplicatie in beheer heb, dan krijg ik vaak een glazige blik en “we willen het toch want we betalen er voor”. Waarom is dat toch steeds het standpunt van juristen? Dit is toch volstrekt niet logisch?

Deze discussie komt mij zeer bekend voor, en inderdaad kun je je afvragen of het wel het standaard uitgangspunt moet zijn dat je als klant eigenaar moet worden (pardon, houder van de auteursrechten) van iets dat je op maat laat maken dat bovenop een bestaande SaaS-oplossing komt staan. Ik kan er eigenlijk geen directe reden voor bedenken en je maakt het jezelf als opdrachtgever nodeloos moeilijk.

De traditionele reden om eigenaar te willen worden van maatwerk is zodat je er zelf mee verder kunt. Dit komt uit de tijd dat applicaties 99% maatwerk waren, en dan is het natuurlijk logisch om dat te eisen. Maar hoe meer standaardwerk er in de software zit, hoe lastiger dat standpunt is vol te houden. Ja, je kunt dan escrow van de standaardsoftware hanteren omdat je dan “verder kunt” met het geheel. Maar bij SaaS is broncode-escrow vrij zinloos, omdat je zó veel meer hebt dan alleen de software.

Meer algemeen is altijd de vraag, is het echt goedkoper om deze kant op te gaan? Waar haal jij tegen die tijd de developers vandaan die zich snel in kunnen werken in die applicatie om jou continuïteit te garanderen? Ik geef het je te doen met de complexiteit van applicaties vandaag de dag.

Een andere reden is dat men denkt het maatwerk te zijner tijd bovenop een ander stuk standaardwerk te kunnen monteren. Daar kan ik alleen maar “moehaha” op zeggen.

Van een geheel andere orde is de motivatie dat men niet wil dat de ontwikkelaar diezelfde functionaliteit verkoopt aan de concurrent. Immers als ik 100 uur werk betaal en de opdrachtnemer geeft dat werk vervolgens gratis aan de concurrent omdat hij daar een toffe indruk wil wekken, dan word ik wel een beetje boos ja. Ook al heb ik gekregen waar ik voor heb betaald, namelijk 100 uur werk en een keurig werkend stukje maatwerk.

Als dat het bezwaar is, dan is er echter nog een andere oplossing en dat is gewoon exclusiviteit afspreken. Dan zeg je, ditzelfde werk mag je de komende drie/zes/twaalf maanden niet doen voor de concurrent. Dan heb je meteen ook het geval gevangen dat de dienstverlener gewoon opnieuw de maatwerksoftware schrijft – iets dat mag van het auteursrecht, zolang hij maar geen copypaste doet. Natuurlijk zal de ontwikkelaar wel geld eisen voor deze verplichte omzetderving, maar dan heb je volgens mij de eerlijke discussie over wat je wilt en wat dat mag kosten.

Een variant op dit bezwaar is dat het maatwerk gebaseerd is op vertrouwelijke informatie (zoals een bedrijfsproces of koppeling met iets geheims). Dan zou hergebruik van het maatwerk de geheimhouding schenden. Maar dan is het antwoord simpel: nou ja, dat mag niet want we hebben vertrouwelijkheid afgesproken. En er zit genoeg in het maatwerk dat niét onder de vertrouwelijkheid valt, over het algemeen.

Helaas is een té vaak voorkomende reden dat men het wil omdat het in de inkoopvoorwaarden staat. En ja, die zijn door een duur kantoor opgesteld of daar moet op heel hoog niveau toestemming voor afwijken worden gehaald dus dat kan dan niet anders. Dit zijn de lastigste discussies in de praktijk.

Ik zie voor de ontwikkelaar twee oplossingen:

  1. Auteursrecht op het maatwerk behouden met het argument dat het toch onbruikbaar is buiten de basisapplicatie. Wel krijgt de klant exclusiviteit op het maatwerk gedurende bv. 12 maanden, zodat er geen zorg is dat de concurrent het meteen ook krijgt. Kostprijs kan omlaag als de periode korter wordt.
  2. Auteursrecht overdragen en bepalen dat de onderliggende ideeën en principes vrij blijven voor de ontwikkelaar. Dat mag van de auteurswet toch al (45k Aw) mits je dus geen broncode hergebruikt.

Wie optie 1 scherp wil insteken, neemt twee prijzen op in de offerte waarvan de laagste is gemarkeerd met “zonder exclusiviteit” en de tweede “met 12 maanden exclusiviteit”. Dit is mijn standaard contractentruc maar het werkt nog steeds als een tierelier, zelfs wanneer de dure advocaat van de wederpartij de truc kent.

Arnoud

Nee, een domeinnaam is geen maatwerk onder de Wet Koop op afstand

| AE 9310 | Intellectuele rechten | 30 reacties

Regelmatig zie ik bij domeinnaamverkopers en webhosters staan dat aangeschafte domeinnamen niet kunnen worden geannuleerd onder de Wet koop op afstand, omdat het om maatwerk zou gaan. Immers, je vult zelf in welke naam je wilt hebben. Maar een recent vonnis over maatwerkdomeinnamen laat zien dat dit écht niet klopt. Domeinnamen zijn diensten, en daarvoor geldt een ander (complexer) regime.

In deze zaak had een particulier bij een domeinnaamdienstverlener een domeinnaam gekocht, en een dag later de overeenkomst geannuleerd met een beroep op de Wet koop op afstand. Het bedrijf erkende dat niet: een domeinnaam aanvragen is een maatwerktransactie, bovendien werd deze transactie direct uitgevoerd. Dat leidde tot een rechtszaak, waarbij de rechter dan eindelijk eens een knoop hierover door moest hakken.

De Wet koop op afstand is in 2014 vervangen door een nieuwe serie wetsartikelen, maar voor het gemak blijf ik die artikelen gewoon Wet koop op afstand noemen. In essentie blijft het systeem van annuleren hetzelfde, hoewel de praktijk veel consumentvriendelijker uitpakt: een consument mag binnen 14 dagen iedere online transactie ongedaan maken, tenzij een van de wettelijke uitzonderingen van toepassing is.

De bekendste uitzondering is denk ik die van maatwerk, of zoals de wet het nu formuleert (art. 6:230p punt f sub 1 BW):

de levering van volgens specificaties van de consument vervaardigde zaken, die niet geprefabriceerd zijn en die worden vervaardigd op basis van een individuele keuze of beslissing van de consument, of die duidelijk voor een specifieke persoon bestemd zijn;

Het standaardvoorbeeld is het t-shirt dat wordt bedrukt met een door de consument aangeleverde foto. Die ‘zaak’ bestond nog niet en wordt vervaardigd op basis van een individuele keuze: deze ene foto en geen andere. Dit is wat bedrijven bedoelen met ‘maatwerk’ als ze zeggen dat maatwerk niet mag worden geannuleerd.

Je kunt inderdaad verdedigen dat een domeinnaam “volgens specificatie van de consument” is vervaardigd. Je typt inderdaad zelf de domeinnaam in die je wilt hebben. Alleen: een domeinnaam is geen ‘zaak’, geen fysiek object zoals de wet dat definieert. Daarom kan deze uitzondering niet worden ingeroepen bij domeinnamen.

Als iets geen zaak is, dan is de transactie er omheen een dienst. Daar is ook een annuleringsregeling voor, zij het dat die ingaat binnen 14 dagen na het sluiten van de overeenkomst (en niet na de dag van levering van de zaken). Deze regeling kent ook weer een uitzondering (art. 6:230p sub d BW):

een overeenkomst tot het verrichten van diensten, na nakoming van de overeenkomst, indien:
1°. de nakoming is begonnen met uitdrukkelijke voorafgaande instemming van de consument; en
2°. de consument heeft verklaard afstand te doen van zijn recht van ontbinding zodra de handelaar de overeenkomst is nagekomen;

De aanschaf van een domeinnaam mag dus wél worden geannuleerd, tenzij aan deze twee eisen (allebei dus) is voldaan.

De eerste eis is dat er met uitdrukkelijke voorafgaande instemming van de consument is begonnen met nakoming. In deze context betekent dat: er is expliciet gezegd “graag deze domeinnaam aanvragen en wel nu”. Dat komt uit het bestelproces van het bedrijf wel naar voren.

De tweede eis zegt dat als de levering afgerond is binnen die 14 dagen, de consument niet meer alsnog mag ontbinden. Direct vragen om levering, geleverd krijgen en dán nog zeggen “oh nee laat maar, graag geld terug” was net even te oneerlijk.

Maar bij wijze van balans is wel weer vereist dat de consument apart verklaart afstand te doen van dat annuleringsrecht. En dat is waar het hier misging: nergens in het bestelproces moest de consument een vinkje zetten (of iets dergelijks, bij wijze van verklaring) bij een tekst als “Ik geef opdracht tot directe aanvraag van de domeinnaam en doe afstand van mijn recht deze aanvraag te annuleren onder de Wet koop op afstand”. Daarom mocht de consument deze aanschaf kosteloos annuleren.

Slecht nieuws dus voor het bedrijf , ze krijgen die 29 euro (aanschafprijs plus diverse kosten) waar de zaak over ging, niet terug. Ook voor andere domeinhandelaren is dit iets om zenuwachtig over te worden: ook zij kunnen dus geen beroep doen op de maatwerkuitzondering. Maar er is een sprankje hoop, want wie nu bovenstaande tekst met aanvinkvakje toevoegt in zijn bestelproces, kan een latere annulering eenvoudig pareren.

Natuurlijk geldt dit recht alleen voor consumenten; bedrijven (dus ook eenmanszaken) hebben géén rechten onder de Wet koop op afstand, en dus ook niet op het recht de aanschaf van een domeinnaam te annuleren. Tenzij ze zich kunnen beroepen op de zogeheten reflexwerking, waarbij ze kunnen aantonen dat zij voor deze transactie eigenlijk niet te onderscheiden zijn van een consument. Die zie ik eerlijk gezegd niet voor een domeinnaam, dat lijkt me typisch iets dat je écht bedrijfsmatig aanschaft.

Arnoud

Hoe verdeel je de eigendom van versgemaakte software?

| AE 6521 | Intellectuele rechten | 11 reacties

software-code-binary-bits-bytesRegelmatig krijg ik vragen van softwareontwikkelaars en hun klanten over hoe om te gaan met het intellectueel eigendom op software die gemaakt is voor die klant. Hoe ga je daar nu mee om, hoe verdeel je die rechten op een manier waar beide partijen tevreden mee zijn.

Hoofdregel uit het auteursrecht is dat de partij die het werk maakt, de rechten daarop heeft. Huur je dus iemand in (een bedrijf of een freelancer), dan heeft deze de rechten. Niet de opdrachtgever. Ook niet als deze alle uren betaalt en/of als de software heel specifiek voor zijn situatie is ontwikkeld.

Wil je als opdrachtgever de rechten, dan moet je dat afspreken in de offerte. Achteraf opeisen kan ook, maar je staat dan een stuk zwakker. De ontwikkelaar hoeft dan niet akkoord te gaan met overdracht, dat was immers niet afgesproken. En iets verkrijgen dat niet afgegeven hoeft te worden, is onderhandelingstechnisch een lastige. Plus, wat moet dat kosten?

Een gebruikelijk compromis is maatwerk eigendom klant maken en het standaarddeel eigendom leverancier laten blijven. Zo kunnen zij door met het maatwerk, en kan de leverancier door met het standaardproduct naar andere klanten. Dit kan worden aangevuld met een verbod voor de leverancier om exact/vrijwel hetzelfde op te leveren voor een concurrent.

Nadeel voor de klant (en voordeel voor de leverancier) hiervan is dat de leverancier nu altijd nodig blijft om onderhoud aan de standaardsoftware te doen. Dat kan een leuke inkomstenbron zijn voor die leverancier, maar veel frustratie opleveren bij de klant. Zeker als de standardsoftware wordt uitgefaseerd of de ontwikkelaar gewoon geen zin meer heeft.

Van de ontwikkelaar eisen dat hij de rechten op de standaardsoftware afstaat, is niet redelijk. Hij maakte die immers om bij meerdere klanten in te zetten, en die optie wordt nu geblokkeerd.

Een alternatief kan zijn om te eisen dat de ontwikkelaar alleen werkt met open source. Daarvan is immers niet echt een eigenaar aan te wijzen, en bovendien heeft de klant dan altijd genoeg gebruiksrechten om er zelf mee te kunnen werken. Hij is dan leveranciersonafhankelijk. Maar lang niet iedere ontwikkelaar kan of wil werken met open source van derden.

Sommige juristen stellen dat je zou kunnen zeggen dat het totaalpakket eigendom van de klant kan worden, zonder dat de leverancier daarmee de onderliggende rechten verliest. Vergelijk dat iemand foto’s levert voor in een boek: de rechten op de foto blijven van de fotograaf maar het auteursrecht op het boek is van de uitgever daarvan. De uitgever mag het boek dan herpubliceren in bewerkte vorm zonder aparte toestemming van de fotograaf. Die analogie gaat echter niet helemaal op, want foto’s hoeven in een boek zelden aangepast te worden en bij standaardsoftware (zoals een CMS of framework) moet dat juist wél kunnen. Misschien als je zegt, het gaat hier om de ‘foto’ zoals aangepast voor maatwerkproduct X van klant Y. Een standaardpakket zal altijd iets moeten worden aangepast voordat het werkt bij klant Y.

Hoe dan ook, maak alsjeblieft vóóraf afspraken. En vraag door als klant: menig ontwikkelaar denkt dat als je zegt “je wordt eigenaar van de software” de klant daarbij begrijpt “behalve natuurlijk het framweork/cms dat ik erbij krijg, dat spreekt voor zich”.

Arnoud