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

Deel dit artikel

  1. 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

    Ik vind de insteek: ik heb er het volle tarief voor betaald dus ik wil het volledige eigendom nog niet zo gek. Vergelijk het eens met de situatie waarin ik de ontwikkelaar in loondienst heb. Dan wordt het ook 100% van mij. waarom zou dat hier anders zijn.

    Misschien wil ik het maatwerk wel aanpassen tot een standaardpakket en aan mijn concurrenten verkopen? Misschien wil ik dat ze het nooit krijgen voor 20% van wat ik ervoor betaald heb, niet binnen 3 of 6 maanden, maar ook niet binnen 3 of 6 jaar. Is dat zo onredelijk?

    Bovendien, die exclusiviteit bindt de andere partij, de rechtspersoon, niet de natuurlijke persoon ‘de ontwikkelaar’, dus dat is maar een dunne exclusiviteit, en kunnen er met die exclusiviteit allerlei rare dingen gebeuren bij faillisementen etc. Ook maakt het auteursrecht de afdwingbaarheid groter. Bij exclusiviteit kun je lang twisten bij de rechtbank over wat er wel en niet binnen de exclusiviteit viel, bij auteursrecht is dat veel makkelijker.

    Laat ik de vraag eens omdraaien: Waarom willen ontwikkelaars het auteursrecht niet afdragen? Waarom zijn ze daar zo bang voor? Is die angst wel reeel? Ik vind het eigenlijk niet redelijk van de ontwikkelaar dat ze dat willen.

    Hoe harder de ontwikkelaar roept dat hij het auteursrecht wil behouden, hoe minder ik hem zou vertrouwen en hoe harder ik het zelf zou willen hebben, en ik zie daar niets onredelijks aan.

    • Die ‘misschien wil ik wel’ herken ik uit de praktijk. Mijn ervaring is wel dat dat de juristen zijn die het opperen, niet de businessverantwoordelijke die daar een concreet plan voor heeft. Daarom heb ik er wat meer moeite mee, het voelt als een te theoretisch idee dat praktisch veel gedoe oplevert.

      Het verschil met loondienst is natuurlijk dat je dan het standaardpakket óók in eigendom hebt, zodat je het geheel kunt gebruiken. Hier heb je dat niet, dus wat ga je doen met je eigendom? Je kunt werkelijk niets zonder het standaardwerk.

      Je punt van contractueel versus auteursrecht is terecht. Ik kan niet zeggen hoe waarschijnlijk dat is.

      Ontwikkelaars willen het vaak niet omdat ze bang zijn nooit meer iets gelijksoortigs te kunnen maken, en omdat het vaak lastig is precies de grens tussen het maatwerk en het standaardwerk aan te geven. Dan krijg je dus al snel geschillen als ik denk, ik heb het standaardwerk verbeterd en jij zegt, je hebt maatwerk gemaakt. Dat afbakenen is een hoop gedoe.

      • Ontwikkelaars willen het vaak niet omdat ze bang zijn nooit meer iets gelijksoortigs te kunnen maken, en omdat het vaak lastig is precies de grens tussen het maatwerk en het standaardwerk aan te geven. Dan krijg je dus al snel geschillen als ik denk, ik heb het standaardwerk verbeterd en jij zegt, je hebt maatwerk gemaakt. Dat afbakenen is een hoop gedoe.

        Misschien moet er dan iemand iets doen aan voorlichting van de ontwikkelaars. Zoals je zelf als aangaf, de ontwikkelaar mag volgens het auteursrecht best opnieuw een dergelijk stuk software schrijven, alleen niet copy-pasten. Dat hij dat niet weet en daarom allerlei (naar mijn eerlijke mening meestal onredelijke) eisen gaat stellen…. tja.

        Ik bedenk me ineens nog een andere reden om alle IE te vragen. Daarmee heb je in elk geval een stok om mee te slaan naar je leverancier als er ineens een derde opstaat en zegt: ‘maar dat kleine stukje software is van mij, betalen!’. Dan ga je terug naar je leverancier en zegt: ‘Ik heb een licentie van jou op de basisapplicatie, en alle IE rechten op de aanpassing, dus het kan niet dat er een derde opstaat, jouw probleem, zorg ervoor dat dat goed komt, svp’.

        Als je niet alle IE hebt, maar alleen een licentie op een concreet omschreven aanpassing, kan het altijd voorkomen dat er nog een paar stukjes software tussen wal en schip vallen die voor problemen kunnen zorgen. Door alle IE te vragen, koop je dus ‘peace of mind’

        • Misschien moet er dan iemand iets doen aan voorlichting van de ontwikkelaars. Zoals je zelf als aangaf, de ontwikkelaar mag volgens het auteursrecht best opnieuw een dergelijk stuk software schrijven, alleen niet copy-pasten. Dat hij dat niet weet en daarom allerlei (naar mijn eerlijke mening meestal onredelijke) eisen gaat stellen…. tja.

          Het lijkt me eerder dat de ontwikkelaar bang is dat de juristen van het bedrijf dat niet snappen (of wel snappen en negeren) en vervolgens de ontwikkelaar een dure rechtzaak aan de broek doen waar hij dan maar weer mag bewijzen dat hij inderdaad niet heeft gecopy-paste ook al lijkt het wel verdacht veel op elkaar.

    • Het ligt natuurlijk heel erg aan wat voor maatwerk je laat maken maar vanuit mijn ervaring is het juist nuttig dat anderen gebruikers van het SaaS product óók toegang krijgen tot de gemaakte oplossing omdat zo het SaaS product gewoon beter wordt. Jij krijgt als bedrijf namelijk ook weer toegang tot maatwerk van anderen.

      Voor wat betreft het auteursrecht overdragen, dat doe ik in principe ook niet. De keren dat daar om gevraagd wordt, komt er een vrij duur voorstel waar ze nooit mee akkoord gaan. Ik wil het niet overdragen omdat ik geen zin in gedoe heb als ik een zelfde soort iets maak voor iemand anders en daarbij delen van code hergebruik.

      Wel kunnen ze van mij een licentie krijgen om alles met de code te doen wat ze willen zonder enige beperkingen maar ik mag de code ook altijd blijven gebruiken.

          • Dat klinkt mooi, maar zo werkt het niet. Ik krijg hem vandaag voor de volle mep, en mijn concurrent krijgt hem morgen voor 20%. Klinkt als een goede deal voor mij? NOT.

            Zie Art 7 Auteurswet: ‘Indien de arbeid, in dienst van een ander verricht, bestaat in het vervaardigen van bepaalde werken van letterkunde, wetenschap of kunst, dan wordt, tenzij tusschen partijen anders is overeengekomen, als de maker van die werken aangemerkt degene, in wiens dienst de werken zijn vervaardigd.’

            De situatie waarin je gewoon de wet volg is de standaardsituatie. De wet laat ruimte voor een andere regeling, maar we moeten nu niet gaan doen alsof dat de natuurlijke standaard is.

    • Laat ik de vraag eens omdraaien: Waarom willen ontwikkelaars het auteursrecht niet afdragen? Waarom zijn ze daar zo bang voor? Is die angst wel reeel? Ik vind het eigenlijk niet redelijk van de ontwikkelaar dat ze dat willen.

      Ik, als softwareontwikkelaar, heb daar eigenlijk verschillende redenen voor: – Maatwerk zit vaak dusdanig verweven in de applicatie dat het meer een ‘uitbreiding’ van de applicatie is dan echt een losstaand stuk software. Zeker in het geval van SaaS is dat zo. Als ik uiteindelijk een applicatie heb waar ik zelf + 20 klanten auteursrecht op hebben, dan kan ik dat natuurlijk nergens meer fatsoenlijk inzetten (beetje afhankelijk van overige afspraken met de betrokken klanten) of verkopen bij bijvoorbeeld een bedrijfsovername (want ik heb het auteursrecht niet). Ook kan het je een hoop juridische ellende opleveren als de klant van mening is dat iets in je generieke product terecht is gekomen wat zijn maatwerk was, en hij het daar niet mee eens is. – De klant betaalt vaak eenmalig voor een stuk maatwerk, maar het toekomstige onderhoud zien wij als ‘onderdeel van de applicatie’ en brengen we dus niet apart in rekening. Maar al dat ‘maatwerk’ van de klant moet wel onderhouden worden. Lijkt mij een redelijke deal dat de klant dan de initiële ontwikkeling betaalt, en wij het daarna onderhouden, maar het dan dus ook wel bij andere klanten mogen gebruiken. – De klant kan net zo hard meeprofiteren van ontwikkelingen die voor andere klanten worden gedaan. Veel ‘maatwerk’ betekent gewoon een uitbreiding van het product met zaken die ook voor andere klanten nuttig zijn. Dat werkt twee kanten op, dat moet de klant ook inzien.

      • Mee eens, voor mij is het meestal ook “door-ontwikkelen” en niet iets losstaands. De klant wil ermee door kunnen gaan als ik wegval (prima) of als ze een andere ontwikkelaar willen inhuren (ook prima, maar dan wil ik ook van eventuele verdere verbeteringen kunnen profiteren). Dus ik stel normaliter een derde optie voor: ik behoud het auteursrecht, maar maak de broncode onder AGPL-licentie beschikbaar (al dan niet bij oplevering publiek toegankelijk).

        Het argument “ik betaal 100 uur dus dat is van mij” gaat niet op. Ik kan het in 100 uur doen omdat ik al een paar duizend uur aan mijn kennis en de basis-applicatie heb gewerkt. Zoals Mike aangeeft: de klant is er bij gebaat dat ik het makkelijk verder kan ontwikkelen, en verdere verbeteringen schappelijk kan aanbieden als “onderhoud”. Het komt regelmatig voor dat ik zelf de onderliggende code opnieuw ontwikkel op basis van de geteste ideeën en ervaringen, maar om nou verplicht te zijn een rewrite te doen voor ik verder kan…

        Maar goed, sommige klanten zien het belang van een levensvatbare software-leverancier niet, en denken dat ze na oplevering klaar zijn. Die lijken dan juist wel een doorlopend service-contract met een jurist te hebben… 😉

      • Het model dat jij hier beschrijft is meer een: betaal voor versnelde ontwikkeling van een feature (zeer legitiem en vaak de beste oplossing). Maatwerk voor mij is toch meer iets dat specified op de klant is toegespitst. Soms zie je bedrijven die veel maatwerk doen en dan na verloop van tijd een nachtmerrie van verschillende (incompatibele) versies van een applicatie hebben. Dat is duur om te ontwikkelen en te onderhouden. Ook heeft maatwerk (in software) twee onderdelen, dat is features die specifiek voor de klant ontwikkeld worden en onderliggende infrastructuur. in principe wil je de onderliggende infrastructuur zeker delen. De features passen bij de klant. Als je echter in de broncode gaat kijken is het zeer lastig om die scheidslijn aan te geven, en programmeurs kennende wil je als bedrijf het risico (of zekerheid) dat de grens overschreden wordt niet lopen. Opties als exclusiviteit zijn veel makkelijker te managen.

  2. 100 uur maatwerk betalen is prima als ik daarmee een mooie nieuwe functie heb. En als die functie ook aan een andere klant beschikbaar wordt gesteld is dat helemaal prima. Zeker als dat andersom ook geldt voor wat een ander laat aanvullen als maatwerk.

    Maar in dat laatste geval wil ik niet ook nog eens ‘eeuwig’ uurtje-factuurtje gaan betalen voor het onderhoud van dat maatwerk. Dan zie ik het IE claimen eerder als start van onderhandelingen: je mag het houden als je het onderhoud voortaan doet binnen de bestaande maandelijkse tarieven. Graag zelfs. Ik kan er inderdaad vaak niets mee – en alle maatwerk zal goedkoper zijn als de leverancier al het geleerde en gemaakte maatwerk bij andere klanten kan hergebruiken zeg ik mogelijk ietwat naief..

    Maar als ik uurtjefactuurtje ook nog moet gaan betalen voor de denkfouten in de code, dan wil ik dat zelf kunnen laten doen door een derde.

  3. Ik wil misschien wel een andere bouwer het maatwerk laten aanpassen. Dat is potentieel lastiger als ik het IE recht op dat maatwerk niet heb.

    Er zijn best vaak specialisten korte tijd in te huren die maatwerk van een SAAS leverancier kunnen onderhouden of daar kleine aanpassingen in kunnen doen. Dan is het handig dat ik de IE rechten van dat maatwerk heb. Zowel van de originele leverancier als van de ingehuurde ZZP’ers.

    Als een leverancier van maatwerksoftware het IE houdt dan voelt dat beperkend op toekomstige wijzigingen op de software door andere partijen

  4. Ik mis nog een andere invalshoek: veel ontwikkelwerk maakt gebruik van andere software zoals libraries. Deze zijn veelal Open Source en hebben diverse licenties aan zich gekoppeld (MIT, GPL etc). Hoe zou je daarmee willen omgaan in deze casus?

    Persoonlijk tracht ik e.e.a. altijd zo te regelen dat zowel de klant als ik (ontwikkelaar) beiden eigenaar zijn van het auteursrecht. Gedeeld eigenaarschap onder bijvoorbeeld de GPL licentie. Het staat mijn klant dan vrij om te doen wat ze willen met de code, het staat mij vrij om met de code te doen wat ik wil en de code kan als Open Source code bijdragen aan het ecosysteem (net zoals ik gebruik heb gemaakt van andermans Open Source code). Het exclusiviteitsbeding vind ik trouwens ook een mooie oplossing voor klanten die wel willen bijdragen aan Open Source, maar bang zijn dat iemand anders er snel met hun ‘unieke idee’ vandoor gaat. Je ziet dit ook wel gebruikt worden bij werken onder een Creative Commons licentie. Ik vind dat wel een elegante oplossing die tijd biedt om de investering terug te verdienen en daarna bijdraagt aan het algemene ecosysteem.

    ps: Btw, wat betreft het direct doorverkopen aan de concurrent: elke ontwikkelaar die dit doet kan daarna elke klandizie wel vergeten, want het vertrouwen is geschonden.

    • ps: Btw, wat betreft het direct doorverkopen aan de concurrent: elke ontwikkelaar die dit doet kan daarna elke klandizie wel vergeten, want het vertrouwen is geschonden.

      Nee hoor. Als ik een feature bouw in mijn SaaS oplossing dan komt die (meestal zonder extra kosten, dus “gratis”) aan alle andere klanten ter beschikking. Je betaalt alleen voor het als eerste krijgen en voor het mogen meedenken in hoe de betreffende feature eruit komt te zien. Dat heeft me nog nooit klandizie gekost, eerder opgeleverd.

      Er zijn namelijk maar twee alternatieven en die zijn niet aantrekkelijk zowel voor mij als leverancier als voor mijn klanten: 1) de eerste klant krijgt een bepaalde periode van exclusiviteit op de feature. Daarmee kan een klant een bepaalde belangrijke key feature blokkeren voor zijn concurrenten. Het gevolg is dat die concurrenten – die ook mijn klanten zijn – niet blij zijn en misschien zelfs voor een andere aanbieder kiezen. 2) ik bouw de feature voor elke klant opnieuw. Ik heb dan geen schaalbare SaaS oplossing meer maar een lappendeken aan maatwerk in een hosted omgeving. Mijn kosten, moeite en dus ook mijn tarieven zullen explosief stijgen.

      Deze zijn veelal Open Source en hebben diverse licenties aan zich gekoppeld (MIT, GPL etc). Hoe zou je daarmee willen omgaan in deze casus?
      In een SaaS omgeving distribueer je die software niet en dus hoef je modificaties niet te publiceren. Die ‘loophole’ is gedicht onder bijvoorbeeld de Affero GPL.

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