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

Studiemiddag: agile softwareontwikkeling juridisch bekeken

| AE 4732 | Intellectuele rechten | 1 reactie

Agile-software-ontwikkeling is een conceptueel raamwerk voor het uitvoeren van software-ontwikkelingsprojecten als alternatief voor traditionele methodes. Oké, leuk, maar wat moeten juristen daarmee? Met die gedachte was ik gisteren bij de najaarsvergadering van de NVvIR.

Agile coach Serge Beaumont trapte af met een introductie over “Enabling Agile”. Zijn bijna-openingszin “Maar het contract zegt” somde de kern mooi op. Het contract bepaalt hoe je mág werken, en als het contract geen rekening houdt met agile, dan heb je een probleem. Hij noemt meteen al een kernpunt: early termination, oftewel tussentijds opzeggen als het wel goed is (of als je er niet meer uitkomt samen).

Veel contracten gaan uit van wat Serge “productdenken” noemt: je legt vast waar je heen wilt, en de implementatie is dan de route daarheen. Maar Agile biedt een veel meer moving target, je weet nog niet precies waar je gaat komen. En dat is lastig: je kunt wel netjes vastleggen welke producteigenschappen er moeten komen, maar Agile focust op de doelen voor de stakeholders, het waaróm van die eigenschappen. En dat is veel moeilijker om op papier te krijgen.

Dat moving target betekent dus ook continu aanpassen gaande de rit. Dat is veel lastiger in het watervalmodel, omdat dat uitgaat van “eerst specificeren dan bouwen”. Gebruikers die niet weten wat ze willen, zijn irritant – in dat model. En helemaal moeilijk wordt het als Agile eigenlijk niet goed wordt begrepen (of geaccepteerd) door het management, want je kunt als Agile team snel dingen tegenkomen die jouw macht/bevoegdheid te buiten gaan en dat moet dan op een hoger niveau worden opgelost.

Early termination impliceert een andere manier van werken. Je probeert zo snel mogelijk iets te bouwen dat eigenlijk werkt, en dat wordt steeds uitgebreider en beter. Als illustratie: je begint met een potloodtekening, zet die dan in waterverf, daarna komt er wellicht een achtergrondillustratie en uiteindelijk kun je dingen in de inkt zetten. Of niet. Het is dus niet meer “wanneer is het af” maar “wat is wanneer klaar” en dan kiezen “zo is het wel genoeg”. Dit vereist wel dat je met de scope kunt variëren.

Daarna sprak Rutger Alsbach over de juridische kant: agile contracteren. Hij raadde overigens het rechtsboven gelinkte boek over Agile aan. Na een korte bespreking over de tekortkomingen van de watervalmethode legde hij de vinger op een aantal gevoelige punten bij Agile. Mooi punt vond ik, er komt steeds wat nieuws bij dus hoe bepaal je nu wat er geleverd moet worden? En continu wijzigen de prioriteiten: hoe kun je dan ooit iemand wanprestatie verwijten of in gebreke stellen?

Oh, nog een leuke: wanneer wordt de betaling getriggerd? Je kunt het niet aan oplevering ophangen want je weet niet vooraf wanneer wat opgeleverd wordt. Meten op uren kan altijd maar is niet altijd wenselijk. Een alternatief is factureren per functiepunt (pdf).

Grootste juridische beer op de weg: je kunt niet werken met Agile én de klassieke RfP/watervalprocedure. En dat blijkt een groot probleem in de praktijk want de klant is zó gewend aan die klassieke procedure dat ze er niet eens bij stilstaan dat het nu compleet anders gaat werken. Maar ook het omgekeerde is een risico: al te makkelijk werken met vage contractjes en onduidelijke einddoelen gaat ook tot problemen leiden. Ik vond tussendoor googelend nog deze goede contractsprimer over Agile contracten. Leesvoer voor later.

Na de pauze vertelde organisatiepsycholoog Hanneke Grutterink over werken in teams, een belangrijk deel van Agile ontwikkeling. Het idee van “scrum verbetert je teamprestatie” is alleen succesvol als je aan een aantal voorwaarden voldoet voor crossfunctionele teams. Dit zijn: betrokkenheid, coördinatie, kennisdelen en ondersteunende structuur. Bij betrokkenheid is een grote valkuil bijvoorbeeld dat mensen in meerdere teams tegelijk zitten, of dat de beloningsstructuur niet goed is. Bij coördinatie is een goede scrummaster (teamleider) essentieel. Kennisdelen vereist vooral een veilige omgeving waarbinnen mensen kritisch durven te zijn (wat natuurlijk ook weer op de teamleider terugkomt maar ook de organisatie).

Als laatste sprak ICT-advocaat Juliette van Balen. Zij benoemde als jurist de speerpunten in het contract: resultaat, prijs, aansprakelijkheid, garanties en beëindiging (exit). Maar, zo vroeg de zaal, waar is het proces dan, de samenwerking die zo cruciaal is in het Agile proces? Daarvoor verwees Juliette naar de vrij beschikbare modellen voor Agile contracten. De collega’s van Bird & Bird geven de nodige kennis weg in hun position paper met handvaten voor Agile contracten. Ook dit Franstalige Creative Commons-contract biedt perspectieven maar is gek genoeg niet voor commercieel gebruik gelicentieerd (parbleu). Juliettes presentatie bevatte nog vele nuttige aandachtspunten, deze komt binnenkort online.

Daarna ontstond een interessante discussie of Agile wel juridisch haalbaar is. Het verschil in inzicht ging met name over de vraag of je het resultaat voldoende bepaalbaar kunt omschrijven – waarbij er een wereld van verschil bleek te zijn tussen mensen die “ik wil een huis” als resultaat zien en mensen die “ik wil wonen” zien als resultaat. En dat is voor mij de belangrijkste les van Agile: de andere manier van kíjken naar softwareontwikkeling.

Arnoud