Når stiftere går fra hinanden, er det ofte uklart, hvem der ejer koden, cloudkontiene og domænet. Svaret afhænger af aftaler, men den praktiske opgave er den samme: sikr historikken i Git, cloud og administrationskonti, og find ud af, i hvis navn tingene står, før nogen ændrer adgange eller sletter noget. Uden historikken bliver det svært at vise, hvem der har bidraget med hvad, og hvad selskabet ejer.
Artiklen er til de stiftere, ejere og den tekniske ansvarlige, der bliver tilbage i selskabet. Den handler om de første dage. Den juridiske vurdering af bidrag og ejerskab i stiftertvister er beskrevet for advokater. → Stiftertvister i startups: Git, Slack og bidrag
Hvorfor det er så rodet i startups
I en ny virksomhed er der sjældent tid til formaliteter. En stifter opretter GitHub-organisationen med sin private konto. Cloudkontoen hos en udbyder bliver betalt med et privat kreditkort de første måneder. Domænet blev købt, før selskabet var stiftet. Adgangskoder deles i en chat. Det fungerer, så længe alle er enige.
Når en stifter forlader selskabet, især i uenighed, bliver alt det pludselig vigtigt. Hvem kan lukke serveren? Hvem kan slette repositoriet? Hvem kan flytte domænet?
De første 24 timer
- Lav en liste over alle kritiske konti. Kodehosting, cloududbydere, domæneregistrar, DNS, mail, betalingsløsninger, app-butikker, analyseværktøjer og kommunikationsværktøjer.
- Find ud af, hvem der er ejer og administrator på hver. Notér, om kontoen er knyttet til selskabets mail eller til en privat mail.
- Sikr en kopi af koden med fuld historik. En almindelig kopi af de nyeste filer er ikke nok. Historikken viser, hvem der har skrevet hvad og hvornår.
- Eksportér revisionslogs, hvor det kan lade sig gøre. Både kodehosting og cloududbydere har logs over ændringer i rettigheder og indstillinger, ofte med begrænset opbevaringstid.
- Kontakt en advokat. Spørgsmålet om ejerskab, og om hvem der må ændre adgange, skal afklares juridisk.
Det er ofte bedre at tage en kopi af historikken for meget end for lidt. Det kan gøres uden at ændre noget i selve systemerne.
Det skal sikres
- Git-historik · Hvem skrev hvilken kode hvornår
- Pull requests og issues · Drøftelser og beslutninger
- Cloudkontoens log · Hvem ændrede rettigheder og ressourcer
- Domæne og DNS · Registrant, ændringer og fornyelser
- Chat og mail · Aftaler mellem stifterne
- Fakturaer · Hvem har betalt for hvad
Chatten er ofte undervurderet. Aftaler om ejerskab, roller og ansvar bliver i startups typisk indgået i en chatkanal eller en tråd, ikke i en kontrakt. Eksportér de relevante kanaler, før nogen forlader arbejdsområdet eller sletter beskeder.
Hvem gør hvad?
- Tilbageværende stifter eller direktør · Ejer sagen og giver instrukser
- CTO eller teknisk ansvarlig · Laver oversigten over konti
- Advokat · Ejerskab, aftaler og næste skridt
- IT-sagkyndig · Sikrer historik og logs dokumenteret
Er den tekniske ansvarlige selv den stifter, der forlader selskabet, skal en anden tage oversigten. Det er ofte her, en ekstern hjælp bliver nødvendig, fordi ingen andre kender systemerne.
Når kontiene står i den forladte stifters navn
Det er den sværeste situation. Står GitHub-organisationen eller cloudkontoen på en privat konto, kan selskabet ikke uden videre overtage den. → Cloudkontoen står i en medarbejders navn
Gør følgende:
- Notér, hvilke konti det drejer sig om, og hvad der kører på dem.
- Dokumentér, at selskabet har betalt, brugt og udviklet på kontiene.
- Bed advokaten om at kontakte den anden stifter med et konkret forslag til overdragelse.
- Lav ikke selv en kopi ved at logge ind med den anden stifters oplysninger.
Det samme gælder domæner. → Hvem ejer domænet, kontoen og dataene?
Det skal I lade være med
- At fjerne den anden stifter fra alle konti i hast. Det kan være rigtigt at begrænse adgangen, men gør det efter rådgivning og med dokumentation af, hvordan det så ud før.
- At omskrive Git-historikken. Kommandoer, der ændrer historikken, kan fjerne netop de spor, der viser bidrag.
- At slette gamle grene eller repositorier for at rydde op.
- At flytte koden til en ny konto uden historik.
- At diskutere ejerskab i offentlige kanaler, hvor medarbejdere og investorer kan læse med.
Hvis den anden stifter har taget kode med
Det er ikke usædvanligt, at en stifter har en lokal kopi af koden. Det er en naturlig del af arbejdet som udvikler. Spørgsmålet er, hvad kopien bruges til bagefter. Hvis I har mistanke om, at koden bruges i et konkurrerende projekt, skal sporene i jeres egne systemer sikres: hvem har klonet hvilke repositorier, og hvornår? Det er det samme spor, som når en udvikler stopper. → Udvikleren stopper: GitHub, tokens og private kopier
Kundedata og produktionsmiljøet
Ud over koden er der selskabets data: kundekonti, brugerdata, betalinger og analyser. De ligger typisk i databaser i cloudkontoen. Hvis den anden stifter har fuld administratoradgang, kan data i princippet kopieres eller slettes. Det er sjældent det, der sker, men risikoen skal tages alvorligt, fordi selskabet har ansvaret for kundernes data.
Sørg for, at:
- der findes en aktuel backup af produktionsdata, som selskabet selv kontrollerer,
- adgangsnøgler og tokens, som den anden stifter har oprettet, er registreret, så de kan skiftes kontrolleret,
- logning af administratorhandlinger er slået til,
- ændringer i rettigheder sker på en planlagt måde, så driften ikke går ned.
Skift af nøgler og adgange bør ske efter rådgivning og efter, at logs og historik er sikret. Notér tidspunktet for hvert skift. Så kan det senere ses, hvilke handlinger der kan være sket før og efter.
Investorer og bestyrelse
Har selskabet investorer, skal de typisk orienteres. Hold orienteringen kort og saglig, og aftal med advokaten, hvad der siges. Investorer vil især spørge, om selskabet har kontrol med sin kode og sine kunder. Oversigten over konti og ejerskab er et godt grundlag for det svar.
Gør det bedre næste gang
Erfaringen fra en stifterkonflikt er værd at bruge. Sørg for, at alle kritiske konti fremover står i selskabets navn, er knyttet til selskabets mail og har mindst to administratorer. Skriv det ind i ejeraftalen. → Ejeraftalen: adgang til systemer og data
Hvornår skal I have hjælp udefra?
Når der er uenighed om, hvem der har bidraget med hvad, er det en fordel, at historikken er sikret af en uafhængig part. Så kan ingen senere påstå, at den er ændret. En IT-sagkyndig kan sikre Git-historik, cloudlogs og chats med kontrolværdier, så det kan efterprøves.
Nielco IT er uvildig og har erfaring med retssager. Der laves konflikttjek, før der gives overslag, og der tages ikke opgaver for den anden part i samme tvist. Haster det, fordi logs er ved at udløbe, kan sikringen ske hurtigt, men hastesager koster ekstra. → Pris og tilbud
Læs også: Partneren har låst os ude af systemerne · Ejeraftalen: adgang til systemer og data, hvis samarbejdet ophører
→ Uvildig IT-undersøgelse for bestyrelsen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
