Arnoud Engelfriet, partner bij adviesbureau ICTRecht

Overeenkomst tot ontwikkeling app

Xxxxxx Xxxxxxxxxx, partner bij adviesbureau ICTRecht

Inleiding

Een app is een computerprogramma dat ontworpen is om op een telefoon, tablet of ander mobiel platform te functioneren. De afkorting ‘app’ staat formeel voor “mobile application” en is vooral bedoeld om hip te klinken, hoewel er ook een wat neerbuigende ondertoon in zit van een klein stukje functionaliteit, een handig dingetje in plaats van een ‘echte’ applicatie zoals een tekstverwerker of tekenprogramma. Tegenwoordig zijn apps echter volwaardige stukken software. De opkomst van apps heeft de prijs van software doen instorten: waar klassieke software voor vele honderden euro’s over de toonbank ging, is een app al duur als hij drie euro kost. Daar staat tegenover dat via advertenties en in-app aankopen er zeer lucratieve nieuwe inkomstenbronnen zijn ontstaan.

Een app-ontwikkelovereenkomst is een softwareontwikkelovereenkomst waarbij de software een app betreft voor mobiele platforms. In beginsel is dit identiek aan de gewone softwareontwikkelovereenkomst, echter met vooral de beperking dat de beheerders van deze platforms een sterke zeggenschap hebben over of de app in gebruik genomen kan worden. Daarnaast hoeft er minder rekening te worden gehouden met veranderende omgevingen of hoe foutherstel door te voeren: apps zijn ontworpen voor een gecontroleerde en bekende omgeving en worden automatisch en (vrijwel) verplicht geüpdatet wanneer de leverancier dat wil.

Dit model is gebaseerd op het Agile-model van softwareontwikkeling. Ten opzichte van de gewone softwareontwikkelovereenkomst is het voornaamste verschil de manier waarop het project voortgang krijgt en hoe de kwaliteit van het werk gemeten wordt. Dit vertaalt zich in flexibele afspraken over het ontwikkelproces, meerwerk en oplevering en aanvaarding. Deze keuze is erg populair bij het ontwikkelen van apps.

Overzicht van de contractbepalingen

Inleiding 1

Overzicht van de contractbepalingen 2

Contractsbepalingen 3

Considerans 3

Artikel 1. Opdracht tot ontwikkeling 4

Artikel 2. Agile ontwikkeling 4

Artikel 3. Broncodetoegang 6

Artikel 4. Opname in app-winkels 6

Artikel 5. Onderhoud 7

Artikel 6. Intellectueel eigendom 8

Artikel 7. Garanties en vrijwaringen 9

Artikel 8. Prijzen en betaling 11

Artikel 9. Duur en beëindiging 11

Artikel 10. Aansprakelijkheid 12

Artikel 11. Geheimhouding 13

Artikel 12. Overige bepalingen 13

Checklist 14

Contractsbepalingen

Considerans

De partijen

1. NAAM, gevestigd te PLAATS aan de STRAAT, bij de Kamer van Koophandel ingeschreven onder nummer NUMMER, hierna te noemen: ‘Opdrachtgever’,

2. NAAM LEVERANCIER, gevestigd te PLAATS aan de STRAAT, bij de Kamer van Koophandel ingeschreven onder nummer NUMMER, hierna te noemen: ‘Leverancier’,

Overwegende, dat:

• Opdrachtgever OMSCHRIJVING;

• Leverancier OMSCHRIJVING;

• Opdrachtgever daarbij behoefte heeft aan een softwareapplicatie voor mobiele telefoons en/of tablets en dergelijke platforms (“de App”) welke DOELOMSCHRIJVING (“het Doel”);

• Leverancier bereid is de App te ontwikkelen en in gebruik te laten nemen;

• Partijen op dd/mm/2014 een geheimhoudingsovereenkomst (‘de NDA’) zijn aangegaan om vertrouwelijke informatie in verband met de ontwikkeling en bijbehorende zaken te beschermen;

Komen overeen:

AANTEKENINGEN

Ontwikkelovereenkomsten voor software, en dus ook voor apps, zijn te kwalificeren als een overeenkomst van opdracht (art. 7:400 BW). Zij kunnen zijn opgezet als een maatwerkovereenkomst, maar vaak zullen deze bepalingen terug te vinden zijn in de algemene leveringsvoorwaarden van het softwareontwikkelbedrijf.

In dit model wordt er vanuit gegaan dat de app maatwerk is en dat alle rechten aan de opdrachtgever worden overgedragen, uiteraard na betaling van de relevante facturen. Een uitzondering wordt gemaakt voor het zogeheten framework of raamwerk waarmee de leverancier de app ontwikkelt. Dit raamwerk is een generiek stuk software dat de basisblokken biedt om apps mee te ontwikkelen. Een leverancier zal de rechten hierop willen behouden om het voor al zijn klanten in te kunnen zetten.

Apps kunnen en zullen vaak gebruik maken van zogeheten open source software. Ook dit levert een versneld ontwikkelingstraject op.

Artikel 1. Opdracht tot ontwikkeling

1. Opdrachtgever geeft opdracht aan Leverancier, welke opdracht Leverancier aanvaardt, tot de ontwikkeling en levering van de App, een en ander conform het voorlopig ontwerp uit bijlage 1 (“het Ontwerp”), onder de navolgende voorwaarden en bedingen.

2. Partijen zullen zich naar eer en geweten inzetten om het werk te laten slagen en beiden onder invulling van voldoende deskundigheid en vakmanschap hun taken vervullen. Partijen kunnen het Ontwerp van tijd tot tijd gezamenlijk bijstellen naar voortschrijdend inzicht.

3. [INDIEN ORGANISATIE gewenst] De projectorganisatie, de contactpersonen en hun taken zijn opgenomen in bijlage 2. Partijen kunnen contactpersonen wijzigen als daar aanleiding toe is. Taken kunnen worden gewijzigd in onderling overleg.

4. De contactpersonen van Opdrachtgever en Leverancier of door hen aan te wijzen personen zullen zeer regelmatig, in ieder geval wekelijks, overleg houden over de voortgang en de resultaten van het project. Opdrachtgever zal tijdens de Sprints haar contactpersoon beschikbaar maken voor het conform Agile noodzakelijke continue overleg.

5. Indien dat in het kader van werkzaamheden noodzakelijk is, zal Opdrachtgever aan Leverancier toegang verschaffen tot een werkplek bij Opdrachtgever. De betreffende medewerkers zullen zich conformeren aan de huisregels en redelijke overige aanwijzingen die Opdrachtgever daarbij stelt.

AANTEKENINGEN

De ontwikkeling van een app is in beginsel niet anders dan de ontwikkeling van andere software. Wel kenmerkt een app zich door een specifiekere functionaliteit en een meer beperkte interface. Daarnaast blijkt bij ontwikkeling van apps dat de opdrachtgever vooraf vaak maar beperkt voor ogen heeft wat exact de wens is. Dit maakt dat de Agilewijze van ontwikkeling het meest geschikt is. Hierover meer in artikel 2.

In artikel 1 wordt in algemene zin een projectorganisatie opgetuigd. Aangenomen wordt dat partijen toch in ieder geval een voorlopig ontwerp kunnen opstellen (bijlage 1) en uitwerken wie betrokken is bij de dagelijkse gang van zaken van het project (bijlage 2). Lid 5 houdt er rekening mee dat de ontwikkelaar(s) ter plaatse bij de opdrachtgever werkzaamheden verrichten.

Artikel 2. Agile ontwikkeling

1. De werkzaamheden zullen worden verricht conform de Agilemethodologie, waarbij het werk in een aantal kleine deelstappen is verdeeld die afzonderlijk worden uitgevoerd en ieder voor zich een afgebakend stuk functionaliteit realiseren van de App (“Sprints”).

2. Voorafgaand aan iedere Sprint zullen partijen in overleg het werk voor de Sprint uit het Ontwerp vertalen naar een aantal test cases. Termijnen van levering en de inhoud van Sprints, alsook de bijbehorende test cases, worden tijdens uitvoering van het werk daarvan bijgesteld als daar aanleiding toe is.

3. Tijdens de uitvoering van iedere Sprint zal Opdrachtgever gevraagd en ongevraagd input geven over het werk teneinde Leverancier de gewenste resultaten te laten leveren. Leverancier zal deze input tijdens de Sprint doorvoeren of gemotiveerd aangeven waarom een andere aanpak betere resultaten levert.

4. Indien het tijdspad van een Sprint niet lijkt te worden gehaald, zullen Opdrachtgever en Leverancier in goed overleg tijdig bepalen of (1) het tijdspad verlengd wordt (2) delen van het werk naar een andere Sprint verplaatst worden (3) delen van het werk komen te vervallen.

5. Als het werk in een Sprint de test cases voor deze Sprint behaalt, wordt het werk geacht te zijn afgerond.

6. Indien na afronding van een Sprint een onvolkomenheid of ongewenste beperking in functionaliteit wordt geconstateerd zullen partijen in overleg vaststellen of (1) deze in een andere Sprint kan worden opgeheven (2) een nieuwe Sprint moet worden gedefinieerd voor het betreffende werk.

AANTEKENINGEN

Bij het Agile-ontwikkelproces wordt veel ingezet op de relatie tussen opdrachtgever en ontwikkelaar. Men zet enkele grote lijnen en begint daarna direct met ontwikkelen. Dit gebeurt in vele zogeheten sprints, waarbij in elke sprint een duidelijk afgebakend stukje functionaliteit wordt gerealiseerd. Bij elke sprint is de opdrachtgever nauw betrokken, bij voorkeur zit deze fysiek naast de ontwikkelaar om continu feedback te kunnen geven. Zo weten beide partijen zeker dat zij aan het eind van een sprint de gewenste functionaliteit hebben op de manier die de opdrachtgever wenst.

Het contractueel vastleggen van een Agilewerkproces heeft iets paradoxaals, omdat bij Agile samenwerking, flexibiliteit en vertrouwen voorop staan en een contract vaak vooral wordt geschreven vanuit een beleving van wantrouwen: wat als er iets mis gaat, wie stellen wij dan aansprakelijk en voor hoe veel geld? Toch kan ook een Agileproject niet zonder contract, al is het maar om vast te leggen op welke wijze men flexibel samenwerkt en waar het vertrouwen dan op wordt gericht.

In Agilesituaties is oplevering en aanvaarding minder logisch. Xxxxx per definitie is men tevreden wanneer een sprint is afgerond. Een eindacceptatie voegt dan weinig meer toe.

Artikel 3. Broncodetoegang

1. Leverancier zal de broncode van de App tijdens de ontwikkeling beschikbaar stellen via een beveiligde source code repository waar Opdrachtgever toegang toe heeft via het internet. Op verzoek van Opdrachtgever zal Leverancier een export van de repository doen toekomen via een nader te kiezen medium. [ALTERNATIEF: Leverancier zal periodiek, doch minstens eens per week, de broncode van de App in beschikbaar stellen via een nader te kiezen medium.]

2. Leverancier zal een testomgeving beschikbaar stellen voor Opdrachtgever. De testomgeving zal Opdrachtgever in staat stellen de App zoals deze dan is, te testen en feedback te geven.

AANTEKENINGEN

Software is waardeloos zonder de broncode, aangezien alleen in de broncode wijzigingen kunnen worden doorgevoerd. Er moet dus expliciet overeengekomen worden dat de broncode op zeker moment geleverd zal worden als de klant de auteursrechten zal verkrijgen, of als het gebruiksrecht ook strekt tot het maken van wijzigingen door de klant. Gebruikelijk is dit moment te koppelen aan de betaling van de laatste hiervoor uitgebrachte factuur.

Bij app-ontwikkeling (en meer algemeen Agileachtigeontwikkeling) wordt vaak gewerkt met een online omgeving waar de broncode toegankelijk is. Dit is efficiënter dan regelmatig de broncode op te sturen.

Tevens zal de leverancier gewoonlijk een testomgeving bieden waarbinnen de app getest kan worden. Het is immers niet mogelijk apps te testen op gewone telefoons of tablets, aangezien de leveranciers daar blokkades tegen instellen.

Artikel 4. Opname in app-winkels

1. Wanneer Partijen de App voor het Doel geschikt achten, zal Leverancier de App aanbieden aan [NAAR KEUZE] Apple en/of Google en/of Microsoft[/KEUZE] voor opname in de door deze partijen geëxploiteerde app-winkels.

2. Leverancier zal het aanbieden verzorgen uit naam van Opdrachtgever, en zal daarbij een door Opdrachtgever beschikbaar gesteld account gebruiken. Opdrachtgever staat hierbij toe dat Leverancier dit account gebruikt. [ALTERNATIEF] Leverancier is gerechtigd het aanbieden uit eigen naam te verzorgen. Leverancier zal op ieder moment zijn medewerking geven aan redelijke instructies ten aanzien van vermelding in of verwijdering van de App uit de app-winkels.

3. Leverancier zal zich maximaal inspannen de App te laten accepteren door deze partijen. Opdrachtgever aanvaardt echter dat acceptatie ter discretie van deze partijen gebeurt en zonder opgaaf van redenen kan worden geweigerd.

1. Indien de App niet wordt geaccepteerd, zullen partijen in gezamenlijk overleg een of meer Sprints uitvoeren om alsnog tot acceptatie te komen. Indien na een redelijk aantal pogingen acceptatie uitblijft, kan ieder der partijen de overeenkomst beëindigen.

AANTEKENINGEN

Er is maar één officiële manier om apps te verkrijgen en dat is ze te downloaden bij een app-aanbieder. Hoewel het algemeen spraakgebruik hier van “appstores” spreekt, moeten wij als juristen erop wijzen dat “Appstore” een geregistreerd merk (Europa: 005554779) van Apple Computers is. Google’s aanbiedlocatie heet Play.

Opname in een app-aanbiedlocatie is een nauwelijks beheersbaar proces. De machtspositie van de beheerders is erg groot. Zij beslissen als enige welke apps wel of niet worden opgenomen, en de criteria voor opname of weigering zijn vaag. Apple’s voorwaarden vermelden op dit punt letterlijk “als we je afwijzen, weet je heus wel waarom”. Praktisch gezien is hier weinig aan te doen en moet een herstelprocedure worden afgesproken voor het geval de app wordt afgekeurd.

Uitzondering op het voorgaande geldt wanneer een app specifiek wordt ontwikkeld voor gebruik binnen één organisatie. Dergelijke “enterprise apps” kunnen via een speciale constructie direct op mobiele apparaten van medewerkers worden geplaatst zonder opname in de openbare appstore. Dit vereist maatwerkafspraken met de leverancier.

Een aandachtspunt bij opname in app-winkels is nog dat hiervoor een account nodig is. Veel ontwikkelaars beschikken over zo’n account. Xxxxxx is echter dat de app dan uit naam van de ontwikkelaar wordt aangeboden. Het is dan ook vanuit het perspectief van de opdrachtgever beter om een account op zijn naam te laten gebruiken.

Artikel 5. Onderhoud

1. Gedurende een periode van twaalf maanden vanaf opname in de app-winkels zal Leverancier onderhoud verrichten aan de App. Onderhoud bestaat uit preventief onderhoud (het voorkomen van fouten), correctief onderhoud (het oplossen van fouten) en adaptief onderhoud (het toevoegen van vernieuwingen).

2. Onderhoud zal worden uitgevoerd aan de hand van Sprints zoals beschreven in artikel 2, onder voorwaarde van betaling van de maandelijkse onderhoudsvergoeding. Leverancier zal daarbij AANTAL uren per maand aan preventief en correctief onderhoud zonder aanvullende vergoeding uitvoeren.

1. Het is partijen bekend dat de aanbieders van de in artikel 4 bedoelde app-winkels van tijd tot tijd wijzigingen doorvoeren aan de door hen geëxploiteerde platforms waarop de App functioneert. Het aanpassen van de App aan dergelijke wijzigingen wordt WEL/NIET aangemerkt als preventief dan wel correctief onderhoud zoals bedoeld in lid 1.

AANTEKENINGEN

Net als alle software moeten ook apps worden onderhouden, hoewel men ervoor kan kiezen dit niet te doen wanneer de app slechts voor beperkte tijd (3 tot 6 maanden) bedoeld is. Denk aan apps die een reclamecampagne ondersteunen. In beginsel is er niets app-specifieks aan onderhoudsafspraken, hoewel ze natuurlijk wel op dezelfde manier zullen worden uitgevoerd als de oorspronkelijke ontwikkeling.

Wel een aandachtspunt is dat zij sterk afhankelijk zijn van de platforms (zoals het Android-besturingssysteem van Google of iOS van Apple) waarop zij draaien, en van de app-winkels waarin zij worden aangeboden. Deze platforms zijn aan regelmatige wijziging onderhevig. Het is dan ook goed om vast te leggen of compatibiliteit met deze platforms aangemerkt wordt als meerwerk (waardoor de kosten voor de opdrachtgever zijn) of juist wellicht eerder als garantie opgenomen worden (waardoor de kosten voor de leverancier zijn).

Artikel 6. Intellectueel eigendom

1. [ALS IE bij Opdrachtgever]
   Zodra het resultaat van een Sprint is afgerond, draagt Leverancier het auteursrecht en alle andere rechten van intellectuele eigendom op het in deze Sprint vervaardigde werk over aan Opdrachtgever. Deze overdracht is voorwaardelijk op het betalen door Opdrachtgever van de voor dit resultaat verschuldigde prijs.

2. Voor zover nodig verbindt Leverancier zich voorts om op verzoek van Opdrachtgever alle nadere handelingen, zoals het ondertekenen van aktes, te verrichten om deze overdracht te bevestigen, alsnog te doen plaatsvinden of handhaving mogelijk te maken. De kosten voor dergelijke handelingen zijn voor Opdrachtgever. Leverancier machtigt bij deze Opdrachtgever op voorhand om dergelijke aktes te ondertekenen.

3. Leverancier verklaart zich niet te zullen verzetten tegen het aanbrengen van wijzigingen in de App. Tevens doet Leverancier onder deze voorwaarden afstand van zijn persoonlijkheidsrechten.

4. [OPTIONEEL] Het voorgaande geldt niet het door Leverancier ingezette framework ten behoeve van de App. Alle rechten van intellectuele eigendom op dit framework (zoals nader omschreven in het Ontwerp) blijven bij Leverancier. Opdrachtgever ontvangt het recht het framework zoals opgenomen in de App te exploiteren, maar niet meer.

5. [ALS IE bij Leverancier blijft]
   Alle rechten van intellectuele eigendom op de App berusten en blijven bij Leverancier of diens licentiegevers.

6. Opdrachtgever ontvangt het recht de App beschikbaar te stellen aan eindgebruikers voor het Doel. Opdrachtgever heeft WEL/NIET het recht onderhoud aan de App te verrichten EN/OF derden dit te laten doen. Opdrachtgever heeft WEL/GEEN recht op een kopie van bronbestanden van de App tenzij dit expliciet en ondubbelzinnig schriftelijk is overeengekomen.

7. [OPTIONEEL indien naamsvermelding leverancier gewenst] Het is Opdrachtgever niet toegestaan enige aanduiding omtrent auteursrechten, merken, handelsnamen of andere rechten van intellectuele eigendom uit de App te verwijderen of te wijzigen.

AANTEKENINGEN

Gebruikelijk bij softwareontwikkeling is dat de intellectuele-eigendomsrechten bij de leverancier blijven berusten. Dit kan ook bij apps, maar ook komt voor dat de rechten juist naar de klant worden overgedragen. Het model gaat hiervan uit, met als alternatief de situatie waarin het IE wordt behouden door de leverancier.

Wel is een (optionele) uitzondering opgenomen voor het zogeheten framework van de leverancier. Zoals in de inleiding is aangegeven, blijft dit eigenlijk altijd eigendom van de leverancier.

Artikel 7. Garanties en vrijwaringen

1. Leverancier garandeert dat de App zal overeenkomen met het Ontwerp en geschikt zal zijn voor het Doel. Leverancier zal gedurende een periode van 6 maanden afwijkingen van deze garantie kosteloos herstellen. Uitgesloten van deze garantie zijn afwijkingen veroorzaakt door na de datum van acceptatie in de app-winkels doorgevoerde wijzigingen aan de platforms waarop de App beschikbaar is.

2. Leverancier garandeert dat de App alleen persoonsgegevens verwerkt in overeenstemming met Nederlandse en Europese wet- en regelgeving dienaangaande. Dit betreft zowel de App zelf als bijbehorende online diensten voor zover Leverancier daar invloed op heeft.

3. Leverancier garandeert dat de Software geen virussen, achterdeuren of andere kwaadaardige routines bevat.

4. Leverancier garandeert dat zij tot aan de overdracht alle auteursrechten op de App bezit en dat de App zoals overgedragen geen inbreuk maakt op de rechten van derden. Deze garanties gelden niet voor door Leverancier gebruikte open source software of andere software van derden zoals nader gedocumenteerd in bijlage 3.

5. Leverancier vrijwaart Opdrachtgever voor alle aanspraken van derden, alsook alle schade (inclusief volledige advocaatkosten), indien Opdrachtgever door een derde wordt aangesproken omdat volgens de stellingen van die derde door Leverancier in strijd zou zijn gehandeld met de hierin afgegeven garanties. Indien Opdrachtgever wordt aangesproken, dan zal Opdrachtgever in overleg treden met Leverancier over de wijze waarop zal worden gereageerd.

AANTEKENINGEN

In een ICT-contract kunnen een grote hoeveelheid garanties worden opgenomen. Doel van een garantie is een prestatie of situatie zodanig vast te leggen dat iedere afwijking daarvan automatisch geldt als een wanprestatie. Een beroep op overmacht is dan niet meer aan de orde. De inhoud en formulering van een garantiebeding kunnen de impact van een garantie echter fors beperken.

Het eerste garantiebeding is een beperkte conformiteitsgarantie. De app moet functioneren zoals beloofd. Gebeurt dit niet binnen de garantieperiode (in het model 6 maanden), dan zal de leverancier dit kosteloos herstellen. Een uitzondering is gemaakt voor compatibiliteit met de app-aanbieders en mobiele platforms.

Het tweede garantiebeding betreft de omgang met persoonsgegevens. Vrijwel iedere app zal persoonsgegevens verwerken, dus een garantie dat dit correct gebeurt, is zeer wenselijk.

Het derde garantiebeding is gericht op de afwezigheid van kwaadaardige code of routines, zoals virussen, Trojaanse paarden of logische bommen. De terminologie klinkt enigszins als een slechte hackerfilm maar het is enige tijd werkelijk praktijk geweest dat software werd voorzien van achterdeurtjes waarmee de leverancier ondanks alle beveiliging ‘in’ de software kon komen, of van logische bommen die bij wanbetaling afgingen zodat de software onbruikbaar werd. In apps is dit niet gebruikelijk.

Het vierde garantiebeding ziet op bij wie de rechten van intellectuele eigendom rusten. Gebruikelijk is te verlangen dat deze bij de leverancier rusten. Echter, bij de ontwikkeling van apps komt het vaak voor dat deze software van derden (zoals open source) inzet. Gebruikelijk is dan ook hiervoor een uitzondering te maken mits deze derden maar bekend zijn bij partijen.

Het vijfde beding beoogt de klant te vrijwaren van claims van derden in verband met een schending van de garantie. Denk aan een derde die op grond van een auteursrecht op de app een inbreukprocedure start.

Artikel 8. Prijzen en betaling

1. De werkzaamheden onder de Overeenkomst worden door Leverancier uitgevoerd tegen de in het Ontwerp opgenomen [ALTERNATIEVEN]
   totaalprijs, ongeacht de uiteindelijke omvang van het werk
   prijs per uur
   prijs per uur, tot een maximum van EUR … per Sprint
   prijs per Sprint zoals nader overeengekomen[/ALTERNATIEVEN]

2. Wijziging van de aan de prijs ten grondslag liggende tarieven is gedurende de looptijd van deze Overeenkomst niet mogelijk.

3. Na acceptatie van het resultaat van een Sprint zal Leverancier elektronisch factureren zoals in de offerte bepaald. Leverancier zal de facturen zenden aan de in bijlage 1 genoemde contactpersoon bij Opdrachtgever.

4. Facturering en betaling vinden plaats in Euro. Facturen zullen worden betaald binnen 30 dagen na de ontvangstdatum van de factuur.

AANTEKENINGEN

Vergoedingsmodellen

Binnen een Agileproject wordt gefocust op tijd, budget of features. Men kan bijvoorbeeld het project zes maanden laten duren, of juist afspreken dat niet meer dan € 50.000 mag worden besteed. Beide aspecten beperken automatisch de scope van het project. Overigens is een vast budget niet hetzelfde als een fixed fee. Bij een fixed fee worden alle vooraf besproken items gerealiseerd tegen de vaste prijs, terwijl een vast budget niet meer inhoudt dan dat dit bedrag niet zal worden overschreden. Het is normaal en gebruikelijk binnen Agile dat het eindproduct vooraf niet bekend is en dat items gaande het traject worden toegevoegd of geschrapt.

Een alternatief is natuurlijk eenvoudigweg op uurtje/factuurtje te sturen, eventueel met een prijsplafond.

Audits

Wordt gekozen voor een vergoeding per verkochte app, dan zou de klant een auditbeding kunnen wensen. Echter, bij apps is een auditbeding niet nodig. De software wordt per telefoon of tablet verkregen uit de appstore, en op dat moment wordt ook afgerekend voor die ene verkrijging. Er kan dus moeilijk software worden gebruikt zonder dat daarvoor betaald is. Het is mogelijk een telefoon te ‘rooten’ en dan apps te installeren via andere kanalen dan de appstore. Echter, dit is relatief ongebruikelijk (zeker in zakelijke omgevingen, omdat het de veiligheid aantast) en bovendien is een audit om dergelijke ongeautoriseerde installaties te bestrijden erg complex. Gezien de prijs van apps (normaal is 99 cent) zal de kosten van zo’n audit de opbrengst niet waard zijn.

Artikel 9. Duur en beëindiging

1. Deze Overeenkomst treedt in werking als beide partijen haar getekend hebben en loopt totdat zij is voltooid.

2. De Overeenkomst loopt in ieder geval door totdat een eind is gekomen aan de garantie- of onderhoudsverplichtingen van Leverancier.

3. Opdrachtgever kan na afronding van iedere Sprint in overleg met Leverancier besluiten het ontwikkelproces te beëindigen zonder tot nadere schadevergoeding aan Leverancier verplicht te zijn. [ALTERNATIEF: tegen betaling van een afkoopsom gelijk aan …]

4. Iedere partij is bevoegd deze Overeenkomst met onmiddellijke ingang, zonder nadere ingebrekestelling en zonder voorafgaande rechterlijke tussenkomst, voor de toekomst te beëindigen indien:

• de wederpartij surséance van betaling aanvraagt;

• de wederpartij in staat van faillissement is verklaard;

• de wederpartij tekort komt in de nakoming van zijn verplichtingen, tenzij de tekortkoming, gezien haar aard of geringe betekenis, deze opzegging en haar gevolgen niet rechtvaardigt;

• de wederpartij een rechtspersoon is en deze wordt ontbonden.

AANTEKENINGEN

Een overeenkomst van opdracht eindigt nadat deze is afgerond. Tussentijdse opzegging is niet gebruikelijk, behalve in de situatie uit lid 3: na iedere sprint zou de opdrachtgever kunnen besluiten te stoppen met de verdere ontwikkeling. Dit is eerder partieel dan volledig.

Wordt tevens onderhoud afgesproken (zie artikel 5), dan kan de einddatum worden gekoppeld aan de onderhoudsperiode of de overeenkomst worden omgezet in een voor onbepaalde tijd.

Artikel 10. Aansprakelijkheid

1. Leverancier is jegens Opdrachtgever aansprakelijk voor schade als gevolg van toerekenbare fouten bij de nakoming van deze Overeenkomst, en wel per fout tot een bedrag gelijk aan de som van de facturen betaald in de twaalf maanden voorafgaand aan het moment van de fout.

2. Leverancier is aansprakelijk voor tekortschieten van door haar ingeschakelde hulppersonen alsof zijzelf tekort schoot.

3. In geval van overmacht zullen de verplichtingen van partijen worden opgeschort totdat de overmacht situatie is opgeheven, zonder dat partijen over en weer tot enige schadevergoeding terzake gehouden zijn.

4. Partijen zullen zich beiden maximaal inspannen de oorzaak van de overmacht zo snel mogelijk op te heffen. Indien vast komt te staan dat opheffen niet binnen een redelijke termijn mogelijk is, dan kunnen partijen in overleg besluiten hetzij de overeenkomst aan te passen om aldus verder te gaan, of de overeenkomst te beëindigen, beiden zonder enige verplichting tot schadevergoeding aan de andere partij.

Artikel 11. Geheimhouding

1. De tussen partijen gesloten NDA is van toepassing op deze Overeenkomst en alles dat daarmee in verband staat. De inhoud van deze overeenkomst alsook de App en ander werk dat wordt gemaakt of geleverd krachtens deze Overeenkomst wordt aangemerkt als vertrouwelijke informatie onder de NDA.

AANTEKENINGEN

Geheimhouding bij een ontwikkeltraject ligt zeer voor de hand. Een artikel hierover opnemen is dan ook verstandig. Vaak zal in het voortraject al een geheimhoudingsovereenkomst (NDA) zijn gesloten. Het geniet dan de voorkeur die daarop van toepassing te verklaren.

Artikel 12. Overige bepalingen

1. Enige algemene voorwaarden van Leverancier maken geen deel uit van deze Overeenkomst.

2. Tenzij waar in deze Overeenkomst anders is bepaald, mag de overeenkomst of een bijlage slechts met wederzijdse toestemming en door middel van een schriftelijk stuk worden gewijzigd.

3. Op deze Overeenkomst is Nederlands recht van toepassing. In geval van een geschil tussen partijen is de rechter te Amsterdam exclusief bevoegd.

4. Iedere partij is slechts gerechtigd haar rechten en verplichtingen uit de overeenkomst over te dragen aan een derde met voorafgaande schriftelijke toestemming van de andere partij.

AANTEKENINGEN

Ter afsluiting van de overeenkomst zullen nog diverse laatste bepalingen worden opgenomen. Belangrijk in ieder geval zijn de rechts- en forumkeuze, maar bij een maatwerkcontract moet ook de verhouding ten aanzien van algemene voorwaarden van partijen worden geregeld.

Checklist

1. Zijn van beide partijen alle gegevens correct ingevuld?

2. Is in bijlage 1 een voorlopige beschrijving van de app opgenomen?

3. Is in bijlage 2 de projectopzet omschreven?

4. Is in bijlage 3 voorzien hoe software van derden zal worden gedocumenteerd?

5. Hoe krijgt de opdrachtgever toegang tot testversies en broncode?

6. Welke personen zijn betrokken bij de sprints?

7. Welke risico’s zijn er op niet-acceptatie in de appwinkels?

8. Wie betaalt het meerwerk dat gepaard gaat met aanpassingen na niet-acceptatie?

9. Hoe wordt onderhoud ingepland en wie betaalt daarvoor?

10. Welk vergoedingsmodel wordt gehanteerd?

11. Wie krijgt het intellectueel eigendom op de app, en indien dit de klant is, wordt de overeenkomst dan op papier gezet en ondertekend?