Källkodsägande: vem äger koden när byrån lovar helhetsansvar?

Du bör inte utgå från att du äger källkoden bara för att en appbyrå lovar helhetsansvar. Avtalet behöver klargöra vilka rättigheter du får och på vilka villkor. I ScriptSectors FAQ om apputveckling står att du äger källkoden, Figma-designerna och dokumentationen fullt ut när avtalsvillkoren och de betalningar som krävs är uppfyllda. FAQ:n om systemutveckling anger att du äger källkod, design, data och dokumentation som tas fram för dig. Men ägande på papper behöver också följas av faktisk åtkomst. Annars kan du bli beroende av leverantören för att bygga, driftsätta eller ändra din egen app.

Vem äger koden när byrån lovar helhetsansvar?

Helhetsansvar beskriver ofta vem som sköter arbetet, inte vem som äger resultatet. En leverantör kan ansvara för utveckling och drift utan att avtalet tydligt reglerar dina immateriella rättigheter. På samma sätt säger formuleringen ”full kontroll över koden” lite om du inte kan hämta den eller låta någon annan arbeta vidare.

Dela därför upp frågan i tre delar: vad du äger, vad du kan komma åt och vad du får göra utan leverantörens medverkan. Kontrollera följande innan du skriver under:

• Källkod: Vilken projektspecifik kod omfattas av överlåtelsen? Ingår backend, integrationer och skript för driftsättning?
• Repo: Ligger kodarkivet under din organisation? Har du administratörsåtkomst och tillgång till historiken?
• Apple och Google: Kräv att relevanta utvecklarkonton ligger under din organisation och att leverantören får lämplig behörighet där.
• Domäner: Kontrollera registrerad innehavare, konto för domänhantering och åtkomst till DNS.
• Backend och molntjänster: Vem kontrollerar konton, fakturering, databaser, säkerhetskopior och produktionsmiljö?
• Design: Får du redigerbara Figma-filer och tillgång till komponenter, inte bara bilder av skärmarna?
• Dokumentation: Finns bygginstruktioner, integrationsbeskrivningar och information om hur lösningen förvaltas?

Ett repo i ditt konto är värdefullt, men överför inte i sig immateriella rättigheter. Omvänt hjälper en rättighetsöverlåtelse inte praktiskt om bara leverantören kan publicera en uppdatering. Du behöver båda delarna.

Vad avtalet behöver säga om källkodsägande och rättigheter

Gör avtalet konkret nog att någon utanför projektet kan förstå vad som ska lämnas över. ”Kunden äger appen” är en utgångspunkt, men lämnar frågor om omfattning, undantag och tidpunkt obesvarade.

Be att följande framgår:

• Vilka leveranser som omfattas: appkod, backend, design, dokumentation och projektspecifika verktyg.
• Vilka ekonomiska rättigheter som överlåts och din rätt att ändra, vidareutveckla och anlita en annan leverantör.
• När överlåtelsen sker och hur den förhåller sig till betalningar och andra avtalsvillkor.
• Vilka befintliga komponenter, bibliotek, typsnitt och andra tredjepartstillgångar som används, med tillhörande licenser.
• Hur kod, data, designfiler och dokumentation ska vara tillgängliga under projektet och vid avslut.
• Vad som gäller för delvis färdigt arbete om samarbetet avbryts.
• Hur överlämning, export, återlämning av åtkomst och eventuella överlämningskostnader hanteras.

Skilj projektspecifikt material från sådant leverantören eller tredje part redan ägde. Ett bibliotek med öppen källkod blir inte din exklusiva egendom för att det används i appen. Du behöver däremot veta vilka licensvillkor som gäller och om de påverkar hur appen får användas eller distribueras.

Det här är ett praktiskt beställarstöd, inte juridisk rådgivning. De exakta villkoren hör hemma i det undertecknade avtalet. Vid behov bör en jurist granska rättighetsdelen. Använd också 12 frågor innan du anlitar apputvecklare som underlag för nästa samtal.

SLA utan prislapp - vad ska du kräva i förvaltningsavtalet?

Källkodsägande avgör inte vem som hanterar ett driftproblem. Det behöver regleras separat. Ett förvaltningsavtal bör beskriva omfattning, ansvar, kontaktvägar och servicenivåer, ofta kallade SLA. ScriptSector publicerar varken förvaltningspris eller SLA-siffror. Du behöver därför få villkoren specificerade i offert och avtal, inte anta dem utifrån en tjänstebeskrivning.

Svarstid och felavhjälpning är olika saker

Ett svar kan vara en bekräftelse på att ärendet är mottaget. Felavhjälpning innebär att problemet faktiskt åtgärdas. Be att avtalet skiljer dem åt och anger:

• Hur fel prioriteras utifrån påverkan, exempelvis stopp i ett centralt flöde jämfört med ett mindre visningsfel.
• Vilken svarstid som gäller för respektive prioritet och under vilka servicetider.
• Vilka tider för felavhjälpning ni avtalar om och hur en tillfällig lösning hanteras.
• När tidsmätningen börjar och hur väntan på kundinformation eller externa leverantörer påverkar den.
• Vilken supportkanal du ska använda och hur ett allvarligt ärende eskaleras.

Avgränsa det löpande arbetet

ScriptSectors beskrivning av förvaltning omfattar säkerhetspatchar, paketuppdateringar, driftövervakning, proaktiva åtgärder, OS- och plattformskompatibilitet samt löpande teknisk support. Det beskriver tjänstens inriktning. Ditt avtal behöver precisera vad som gäller för just din lösning.

• Patchar och uppdateringar: Ange vilka beroenden som ingår, hur uppdateringar bedöms och vilken testning som krävs.
• OS och plattformar: Bestäm vilka versioner som stöds och hur större förändringar från Apple, Google eller andra plattformar hanteras.
• Övervakning: Definiera vilka miljöer och flöden som övervakas, vem som tar emot larm och vilka åtgärder som omfattas.
• Rapportering: Kom överens om innehåll och intervall, exempelvis genomförda uppdateringar, incidenter och kvarstående risker.
• Ändringsönskemål: Beskriv när något är förvaltning och när det kräver separat uppskattning och godkännande.
• Månadspris: Avtala vilket pris som gäller för omfattningen, vad som ingår och hur arbete utanför den beställs och debiteras.

Kräv också att det framgår vem som får godkänna arbete som kostar extra. Då blir en supportanmälan inte ett otydligt uppdrag att bygga om en funktion.

Dagen efter lansering: garanti, förvaltning eller vidareutveckling?

Efter lansering kan samma symptom ha olika orsaker. Ett misslyckat inloggningsförsök kan bero på ett ursprungligt fel, en ändrad extern tjänst eller ett nytt krav som appen aldrig byggdes för. Därför behöver du skilja på tre typer av arbete.

• Garanti: ScriptSector anger att buggar åtgärdas utan extra kostnad under garantiperioden. Periodens längd är inte publicerad. Bekräfta längd, startpunkt, omfattning och hantering i avtalet.
• Förvaltning: Löpande arbete för att hålla den befintliga lösningen säker, kompatibel och fungerande enligt överenskommen omfattning.
• Vidareutveckling: Nya funktioner och planerade förbättringar, exempelvis utifrån användarbeteende, analys eller behov av bättre prestanda. Klassificeringen av ett konkret ärende behöver följa avtalet.

Ägandet gäller också för en avgränsad första version. För MVP Sprint beskriver ScriptSector att du efter leverans äger källkod, design, data och dokumentation och inte är bunden till ScriptSector. En offentlig butikslansering ingår däremot inte automatiskt i varje MVP. Bekräfta leveransform och ansvar för eventuell publicering.

Planera därför övergången till drift innan utvecklingen avslutas. Läs även hur lång tid det tar att utveckla en app för att sätta leveransen i ett större planeringssammanhang.

Överlämning och exit: så förbereder du ett leverantörsbyte

En fungerande exit handlar inte om att du måste vilja lämna. Den gör det möjligt att byta när verksamheten kräver det. Dokumentation som går att använda vid ett leverantörsbyte hjälper dessutom när något behöver felsökas under ett pågående samarbete.

Be att överlämningen omfattar:

• Källkod: Repon, historik, versionsmärkning och uppgift om vilken version som körs i produktion.
• Figma: Redigerbara original, komponentbibliotek och information om externa designtillgångar.
• Bygg- och deployinstruktioner: Hur app och backend byggs, testas, publiceras och vid behov återställs.
• Arkitekturöversikt: Viktiga komponenter, dataflöden, integrationer och externa beroenden.
• Konton och nycklar: Förteckning över tjänster, behörigheter, certifikat och hemligheter samt säker hantering av överföring och nyckelbyte.
• Data och drift: Exportmöjligheter, säkerhetskopior, återställningsinstruktioner och kända driftrisker.
• Kvarstående arbete: Kända fel, teknisk skuld och beslut som nästa utvecklare behöver förstå.

Lagra inte hemliga nycklar öppet i repot. Överför dem säkert, ge den nya leverantören egna behörigheter och planera när tidigare åtkomst ska tas bort. Avsluta inte fungerande åtkomst innan ansvar och övergång är samordnade.

Ett bra kontrollmoment är att låta den tillträdande utvecklaren försöka bygga och driftsätta lösningen i en testmiljö med hjälp av materialet. Då upptäcker du luckor innan ett skarpt byte.

Läs att ta över en befintlig app: kodgranskning, omskrivning eller vidareutveckling för hur du kan bedöma nästa steg utan att utgå från att allt måste skrivas om.

Vem äger källkoden när man anlitar en appbyrå?

Du behöver kontrollera avtalet och den rättighetsöverlåtelse som faktiskt avtalas. Betalning eller ett löfte om helhetsansvar är inte tillräckligt underlag för att anta fullständigt ägande. Enligt ScriptSectors FAQ om apputveckling äger du källkoden, Figma-designerna och dokumentationen fullt ut när du uppfyller avtalsvillkoren och genomför de betalningar som krävs. Kontrollera separat tredjepartslicenser och att du har praktisk åtkomst till leveransen.

Vad ska stå i avtalet om källkod och immateriella rättigheter?

Avtalet bör precisera vilka leveranser och rättigheter som överlåts, när överlåtelsen sker och vilka betalningsvillkor som gäller. Det bör också reglera din möjlighet att ändra lösningen och anlita en annan utvecklare. Lista undantag för befintliga komponenter och tredjepartsmaterial. Ange hur kod, design, dokumentation och data lämnas över, även vid ett avbrutet samarbete. Det här är inte juridisk rådgivning; låt de exakta formuleringarna granskas vid behov.

Vad ingår i förvaltning av en app efter lansering?

Förvaltning kan omfatta säkerhetspatchar, paketuppdateringar, driftövervakning, proaktiva åtgärder, kompatibilitet med OS och plattformar samt teknisk support. Det är också de områden ScriptSector beskriver för tjänsten. Exakt omfattning, svarstid, felavhjälpningstid, rapportering och månadspris behöver avtalas för din app. Klargör vilka miljöer som ingår och hur nya funktioner skiljs från underhåll. Förvaltning är inte samma sak som garanti, och innebär inte automatiskt obegränsad vidareutveckling.

Kan man byta utvecklare om man äger källkoden och repot?

Ja, ägande och tillgång till repot ger viktiga förutsättningar, förutsatt att rättigheterna tillåter fortsatt arbete av någon annan. Men den nya utvecklaren behöver också kunna bygga, testa och driftsätta appen. Därför krävs dokumentation, kontobehörigheter, designfiler och åtkomst till backend och relevanta data. Kontrollera externa licenser och beroenden. En teknisk genomgång före bytet kan visa vad som saknas och vilket överlämningsarbete ni behöver planera.

Vad är skillnaden mellan att äga koden och att bara ha en licens?

Ägande innebär här att de avtalade ekonomiska rättigheterna till den projektspecifika koden överlåts till dig. En licens ger dig i stället tillåtelse att använda koden på vissa villkor. Licensen kan vara bred eller begränsad, exempelvis när det gäller ändringar, vidareutveckling eller överlåtelse. Läs därför vad du faktiskt får göra, inte bara vilken rubrik avtalet använder. Även en app vars egenutvecklade kod du äger kan innehålla komponenter som används under tredjepartslicens.

Prata igenom ägande och förvaltning innan du bestämmer dig

Vill du klargöra vad du äger och vilken appförvaltning du behöver? Anton Kihlström är ScriptSectors grundare och utvecklar själv lösningarna. Ta med ditt avtal, en offert eller en lista över frågetecken till ett samtal om omfattning och överlämning. Du kan boka ett kostnadsfritt samtal via kontakt för att prata igenom ett lämpligt nästa steg.