NDA med en udvikler: hvornår beskytter den dig faktisk?

En NDA med en udvikler er fornuftig når du skal dele noget konkret som andre kan bruge mod dig: kildekode, kundedata, tal, prismodeller eller planer der ikke er offentlige endnu. Selve idéen beskytter en NDA sjældent, og kræver du en underskrift før den første samtale, sinker du mest af alt dig selv.

NDA står for non-disclosure agreement, på dansk en fortrolighedsaftale. Jeg er udvikler og ikke jurist, så læs resten som praktiske råd og ikke som juridisk rådgivning.

Den korte version: hvornår skal du have en NDA?

Min tommelfingerregel er enkel: del idéen frit, og beskyt detaljerne. Tabellen viser hvordan det ser ud i de situationer hvor spørgsmålet typisk dukker op.

Er du så tidligt i processen at du endnu ikke ved om du skal have en freelancer, et bureau eller en fastansat, så start med min guide til at hyre en udvikler. NDA'en er en detalje i den større beslutning.

Hvorfor din idé sjældent er hemmeligheden

Det er forståeligt at være bange for at nogen stjæler idéen. Du har måske gået med den i månedsvis, og den føles som det mest værdifulde du har. Men i softwareprojekter er idéen sjældent det svære. Det svære er at bygge den rigtigt, finde de første kunder og holde ud når de første 80 % er gjort.

Der er tre grunde til at en NDA sjældent beskytter selve idéen:

• Idéer er ikke beskyttet af ophavsret. Ophavsretten beskytter den konkrete kode, og EU's softwaredirektiv siger direkte at idéer og principper bag et computerprogram ikke er omfattet.
• Andre må gerne få den samme idé. Efter lov om forretningshemmeligheder § 3 er det lovligt at nå frem til det samme ved uafhængig opdagelse eller skabelse. En NDA forhindrer kun at det du har fortalt, bliver brugt eller givet videre.
• Der findes sandsynligvis noget lignende allerede. Det er sjældent et problem, men en idé der kan beskrives i én sætning, er svær at kalde hemmelig.

Jeg vil også opfordre dig til at vende risikoen om. For de fleste nye produkter er den største risiko ikke at nogen kopierer dem, men at ingen vil bruge dem. Jo flere du taler med om problemet, jo hurtigere finder du ud af om det holder. Det gælder især hvis du vil bygge en SaaS fra idé til betalende kunder.

Og så det ærlige svar fra udviklersiden. En freelanceudvikler lever af at bygge andres projekter, ikke af at stjæle dem. Den der vil snyde dig, bliver næppe stoppet af en underskrift, og den der er seriøs, havde alligevel ikke tænkt sig at snyde dig.

Hvad en NDA faktisk beskytter

En NDA gør størst forskel for konkrete oplysninger som du selv behandler fortroligt. Det hænger sammen med loven. Efter lov om forretningshemmeligheder § 2 er en oplysning kun en forretningshemmelighed hvis den er hemmelig, har handelsværdi fordi den er hemmelig, og er beskyttet af rimelige foranstaltninger til hemmeligholdelse. En fortrolighedsaftale er netop sådan en foranstaltning. Bruger eller videregiver nogen oplysningerne i strid med aftalen, er det ulovligt efter § 4, stk. 2.

NDA'en gør derfor mest gavn for oplysninger der faktisk er hemmelige i dag, fx:

• kildekode, arkitektur og databasestruktur i et eksisterende system
• kundelister, salgstal, marginer og prismodeller
• beregningsmodeller, algoritmer eller data du har brugt lang tid på at samle
• planer der ikke er offentlige, fx et opkøb, en partneraftale eller en lancering
• kendte sikkerhedshuller eller svagheder i dit system

Deler du de samme oplysninger frit med leverandører, investorer og bekendte uden nogen aftale, svækker du din egen sag. En NDA med én udvikler hjælper ikke meget hvis alle andre har fået det samme uden.

Adgangskoder og API-nøgler skal heller ikke beskyttes af en NDA, men af at hver person har sin egen adgang som du kan lukke igen. Det gennemgår jeg i artiklen om hvordan du sikrer dig ejerskab til kode og adgange.

Hvornår i forløbet NDA'en hører hjemme

En NDA har størst værdi når den kommer på det rigtige tidspunkt. Kommer den for tidligt, forsinker den dig og kan skræmme gode udviklere væk. Kommer den for sent, er oplysningerne allerede delt. Sådan vil jeg anbefale at du griber det an.

1. Første kontakt: del problemet, ikke opskriften

Beskriv hvilket problem løsningen skal løse, hvem den er til, og cirka hvor stor den er. Det er nok til at en udvikler kan sige om opgaven passer, og give et groft skøn. Hold konkrete tal, kundenavne og detaljer om din fordel tilbage. Brug gerne min skabelon til en projektbeskrivelse der giver brugbare tilbud, og udelad de dele der er fortrolige.

2. Tilbud eller forprojekt: NDA når du deler tal og data

Skal udvikleren regne på løsningen i detaljer, skal du ofte dele mere: dine arbejdsgange, dine systemer, dine data og måske din forretningsmodel. Her er en kort, gensidig NDA fornuftig hvis oplysningerne lever op til kriterierne ovenfor. Jeg starter selv større opgaver med et betalt forprojekt til fast pris, og det er typisk i den fase de fortrolige detaljer kommer på bordet.

3. Prøveopgave: NDA hvis udvikleren får adgang til din kode

Tester du en udvikler med en betalt prøveopgave, får vedkommende måske adgang til dit repository (kodearkiv) eller din database. Så bør I have en NDA, også selv om opgaven kun tager få timer. Hvordan du sætter en god prøveopgave op, gennemgår jeg i artiklen om prøveopgaver og betalte testforløb.

4. Kontrakten: lad fortroligheden flytte ind

Når I skriver kontrakt, bør fortroligheden stå i den. En tidligere NDA kan enten indarbejdes eller fortsætte ved siden af, bare de to aftaler ikke siger noget forskelligt. Fortrolighed er et af punkterne i min tjekliste til kontrakten med en freelance udvikler.

5. Afslutningen: tilbagelevering og sletning

Fortroligheden gælder også efter projektet. Aftal at udvikleren sletter eller returnerer dine data og dokumenter, og luk de adgange du har givet. Det punkt er nemt at glemme når projektet er leveret og alle er glade.

Det skal en rimelig NDA med en udvikler indeholde

En god NDA er kort og konkret. Brug tjeklisten når du skriver din egen, eller når du læser den udvikleren sender.

To af punkterne fortjener et par ord mere. Varigheden bør have en slutdato for almindelige forretningsoplysninger, ofte et sted mellem to og fem år, mens en egentlig forretningshemmelighed kan beskyttes så længe den er hemmelig. En aftale hvor alt er fortroligt for evigt, er svær at overholde og svær at håndhæve.

Punktet om generel viden er vigtigt for udvikleren. Når jeg løser en opgave, bliver jeg bedre til fx betalingsløsninger eller integrationer, og den erfaring tager jeg med videre. Det er noget andet end din kode og dine data. En NDA der forbyder udvikleren at bruge almindelig viden, kan i praksis ikke overholdes.

Faresignaler: når NDA'en gør mere skade end gavn

En NDA skal beskytte dine oplysninger, ikke binde udvikleren på hænder og fødder. Som udvikler ville jeg bede om at få disse punkter ændret, og en seriøs modpart vil som regel forstå hvorfor:

• En konkurrenceklausul i forklædning, hvor udvikleren ikke må arbejde for andre i din branche. Det er ikke fortrolighed, og for en freelancer kan det betyde at miste en stor del af sit marked.
• Overdragelse af rettigheder før der er en kontrakt, fx "alt udvikleren skaber, tilhører dig" i en aftale før første møde. Rettigheder hører hjemme i kontrakten når arbejdet er betalt.
• En bod uden loft, fx et fast beløb pr. overtrædelse som ikke står i forhold til opgavens størrelse.
• Krav om underskrift før du har sagt hvad opgaven går ud på. Så kan udvikleren ikke vurdere hvad han eller hun siger ja til.

Det sidste punkt er også det letteste at undgå. En NDA som første besked signalerer mistillid før I overhovedet har talt sammen. Send hellere en kort beskrivelse først og NDA'en når I nærmer jer detaljerne.

Når en NDA ikke er nok

Nogle projekter kræver mere end en fortrolighedsaftale, og her er en freelancer ikke altid det rigtige valg:

• Står hele forretningen på en teknisk hemmelighed, fx en beregningsmodel ingen andre har, bør den ikke kun ligge hos én ekstern person. En fastansat udvikler eller en teknisk medstifter med ejerandel har en helt anden tilknytning til virksomheden.
• Har din branche formelle krav til informationssikkerhed, som certificeringer, baggrundstjek eller revision af leverandører, er et bureau med de processer på plads ofte lettere at få godkendt internt. Det kan en freelancer der arbejder alene, sjældent dokumentere på samme måde.
• Vil du holde projektet skjult for alle, kan du ikke få et brugbart tilbud. Ingen kan prissætte en opgave de ikke må høre om.

God teknisk praksis beskytter dig desuden ofte bedre end papir. Giv kun adgang til det der skal bruges, lad udvikleren arbejde med testdata i stedet for rigtige kundedata, og brug personlige konti du kan lukke med det samme.

Næste skridt

Sådan kommer du videre med NDA-spørgsmålet:

1. Skriv en kort beskrivelse af projektet uden forretningshemmeligheder, og brug den til de første samtaler.
2. Lav en liste over hvad der faktisk er fortroligt: kode, data, tal eller planer.
3. Find en kort, gensidig skabelon, og tilpas den med tjeklisten ovenfor.
4. Send NDA'en når I nærmer jer detaljerne, og lad fortroligheden flytte ind i kontrakten bagefter.
5. Står der meget på spil, eller er der tale om kerneteknologi, så få en advokat til at læse aftalen.

Hos mig taler du direkte med den udvikler der skriver koden, større opgaver starter med et betalt forprojekt, og koden er din fra første dag. Se hvilke opgaver jeg løser, og hvordan et samarbejde foregår.

Ofte stillede spørgsmål

Kan jeg bruge en gratis NDA-skabelon fra nettet?+

Ja, en skabelon er et fint udgangspunkt, så længe du tilpasser den. Vælg en skabelon skrevet til dansk ret, gør den gensidig hvis begge parter deler noget, og sammenlign den med tjeklisten i artiklen. Amerikanske skabeloner bruger ofte begreber og retsregler der passer dårligt til et dansk samarbejde. Er aftalen vigtig for din forretning, så lad en advokat tjekke den.

Er en NDA gyldig uden underskrift på papir?+

Ja, som udgangspunkt. I Danmark er aftaler bindende uanset form, så en NDA der er underskrevet digitalt eller accepteret på mail, er også en aftale. Det svære er bevis: du skal kunne vise hvad der blev aftalt, og hvilke oplysninger der var omfattet. En digital signatur eller en tydelig mail med aftalen vedhæftet gør det let.

Hvad kan jeg gøre hvis udvikleren bryder NDA'en?+

Du kan kræve den bod I har aftalt, eller erstatning for dit tab. Er der tale om en forretningshemmelighed, kan retten efter lov om forretningshemmeligheder også nedlægge forbud mod brugen. I praksis er det dyrt og ofte svært at bevise hvad der er lækket, og hvad det har kostet. Derfor er det billigste værn at dele mindre og begrænse adgangene. Tal med en advokat hvis det sker.

Kan udvikleren også kræve en NDA af mig?+

Ja, og det kan være rimeligt. En udvikler kan dele egne værktøjer, genbrugelig kode, metoder eller priser som ikke skal videre til konkurrenter. Derfor er en gensidig NDA ofte det enkleste: samme regler for begge parter, og ingen behøver at forhandle om hvem der har mest at skjule. Det gør det også hurtigere at blive enige.