Vad du äger när systemet är klart: kod, data och beroende av utvecklaren

Systemet är överlämnat, fakturan är betald, och efter ett halvår beslutar företaget att byta utvecklare, och just då ställs frågan som fram till dess inte verkade brådskande för någon: vem äger det som det betalades för. Svaret i Sverige överraskar nästan alla som hör det första gången, för betalning för utvecklingen ger i sig inte beställaren upphovsrätt till det datorprogram som har skapats, och det är inte en juridisk finess utan en presumtion som gäller varje gång avtalet inte säger något annat.

Den här artikeln handlar om vad som blir kvar i dina händer efter överlämningen, och det är inte samma fråga som vi redan har behandlat när vi jämförde en färdig produkt med skräddarsydd programvara. Där handlade det om vad du ska välja; här handlar det om vad du håller i handen när valet redan är gjort och systemet körs. Svaret delas i tre delar: koden och rätten till den, data tillsammans med platsen där de lagras, och beroendet av de människor som känner systemet.

Upphovsmannen är alltid en människa, inte ett företag

Enligt upphovsrättslagen är upphovsman den som har skapat ett litterärt eller konstnärligt verk, och det betyder att ett företag aldrig är upphovsman: upphovsmän är de programmerare, formgivare och textförfattare som arbetade med systemet. Datorprogram skyddas som litterära verk, liksom i Europeiska unionens direktiv 2009/24/EG, och upphovsrätten uppstår i det ögonblick verket skapas, utan registrering, utan märkning och oberoende av om verket är färdigt.

Upphovsrätten delas i två delar, som svensk lag kallar ekonomiska och ideella rättigheter, och i praktiken är det den viktigaste uppdelningen i hela det här ämnet, för bara den ena kan över huvud taget hamna hos företaget. Den ekonomiska delen är den som kan överlåtas till någon annan, och för ett datorprogram ger den ensamrätt att förfoga över verket genom att framställa exemplar av det och genom att göra det tillgängligt för allmänheten, i ursprungligt eller ändrat skick, i översättning eller bearbetning. Den ideella delen stannar hos upphovsmannen och kan med bindande verkan bara efterges för en till art och omfattning begränsad användning, och just därför kan inget avtal skriva att företaget blir upphovsman.

Det finns ytterligare en gräns som sällan märks, och den kan bli dyr. 40 a §, som låter upphovsrätten till ett datorprogram övergå till arbetsgivaren, talar bara om datorprogram, medan allt annat som projektet skapar — formgivning, dokumentation, texter och instruktioner — saknar en allmän anställningsregel: de stannar hos upphovsmannen om de inte har överlåtits, enligt 27 §. Praktiskt betyder det att två saker skapade i samma projekt kan ha två olika rättsinnehavare, och ett avtal som bara talar om programvara kan lämna formgivningen utanför.

Därav följer de första praktiska följderna, som är värda att förstå före allt annat: när ett företag beställer ett system av en byrå är rättighetskedjan minst två steg lång, för först är programmerarna upphovsmän, sedan har byrån eller har den inte fått den ekonomiska delen från dem, och först därefter kan byrån överlåta något till dig. Saknas ett steg lovar byrån mer än den äger, och det märks först när någon börjar kontrollera.

Anställning och beställning är två olika presumtioner

Här ligger artikelns kärna, och det är den här platsen där intuitionen leder fel. 40 a § i upphovsrättslagen säger att upphovsrätten till ett datorprogram som skapas av en arbetstagare som ett led i hans arbetsuppgifter eller efter instruktioner av arbetsgivaren övergår till arbetsgivaren, såvida inte något annat har avtalats. Det är Sveriges svar på artikel 2.3 i direktiv 2009/24/EG, och det gäller bara anställningsförhållanden och bara datorprogram.

Vid beställning är presumtionen den omvända, och just därför får de två fallen inte blandas ihop: ett avtal om beställt verk överför inte den ekonomiska delen till beställaren bara för att verket ska utföras och lämnas till användning. Ett uppdragsavtal säger ingenting alls om upphovsrätt, för det reglerar arbetets utförande och överlämning, inte rättigheternas gång. 27 § säger uttryckligen att överlåtelse av exemplar inte omfattar överlåtelse av upphovsrätt.

Lägg ihop de två, och det blir den situation ett typiskt företag hamnar i utan att veta om det: kunden beställer systemet av byrån; programmerarna är byråns anställda, så övergår upphovsrätten enligt 40 a § till byrån; avtalet mellan kunden och byrån är ett uppdragsavtal, som inte för den vidare. Resultatet blir att kunden har betalat för resultatet och fått resultatet, men den ekonomiska delen har stannat hos byrån, och det enda kunden har är en oklar underförstådd upphovsrättslig licens att använda systemet för det ändamål det beställdes för.

Föreställningen att rätten till ett datorprogram tillhör den som har beställt och betalat utvecklingen är ett vanligt misstag, och upphovsrättslagen ger ingen automatisk övergång till beställaren. Innehållet i en underförstådd licens förblir oklart, och eftersom båda sakerna är precis det som ska skrivas in i avtalet är 27 § och 40 a § värda att läsas tillsammans med den här texten: lagtexten bekräftar den här uppdelningen.

Att få filerna är inte att få rättigheterna

Det andra antagandet som inte håller för prövning är att mottagandet av koden skulle avgöra något, men 27 § i upphovsrättslagen säger att överlåtelse av exemplar inte omfattar överlåtelse av upphovsrätt. I praktiken betyder det att ett arkiv med hela källkoden, åtkomst till kodförrådet och till och med fullständig dokumentation fortfarande inte är samma sak som rätten att använda den koden, ändra den och överlåta den till en annan utvecklare.

Det fungerar också åt andra hållet, och den sidan är mindre känd, för företaget kan ha fått de ekonomiska rättigheterna genom ett välskrivet avtal och ändå inte ha fått källkoden, om avtalet inte hade en separat skyldighet att lämna över den. Ett tillstånd utan fil är lika oanvändbart som en fil utan tillstånd, så avtalet behöver båda, och de är två självständiga punkter, inte en punkt som rymmer den andra av sig själv.

När rättigheterna överlåts på rätt sätt kräver lagen en viss precision, och det är ingen formalitet, för upphovsrättslagen tillåter att den ekonomiska delen överlåts helt eller delvis och avtalet kan ange både territorium och tid, men den fyller inte i ett tyst territorium med det land där avtalet slöts. 28 § säger i stället att den som har fått upphovsrätten överlåten, om inte annat har avtalats, inte får ändra verket och inte heller överlåta rätten vidare. För ett företag som verkar i flera länder eller planerar att göra det är det ett rakt skäl att skriva in territoriet, och ett namngivet förfogandesätt öppnar inte de övriga.

Det finns ytterligare en överraskning som väntar det företag som lever på en underförstådd licens och aldrig har skrivit den. I svensk rätt finns ingen regel som säger att en tidsobegränsad licens kan sägas upp med sex månaders varsel och att ett avstående från den rätten är ogiltigt. Företaget vars enda grund för att använda systemet är en oskriven överenskommelse lever därför med en licens vars innehåll är oklart: den ger inte av sig själv rätt att ändra systemet eller att föra rätten vidare, och den oklarheten rättas bara med ett uttryckligt avtal.

Ideella rättigheter och det de inte förbjuder

I den ideella delen ingår i Sverige rätten att anges som upphovsman och skyddet mot att verket ändras så att upphovsmannens anseende eller egenart kränks, eller görs tillgängligt i en form eller ett sammanhang som är kränkande på det sättet, och det stannar hos upphovsmannen, för den rätten kan med bindande verkan bara efterges för en till art och omfattning begränsad användning. Någon lagstadgad rätt att återkalla verket från användning finns inte. För ett företag som har beställt ett system låter det först hotfullt, för intrycket uppstår att den tidigare utvecklaren någon gång kan kräva att systemet stoppas.

I praktiken är det inte så. Sverige har ingen regel från 2023 som stänger av omarbetning som ideell rätt för datorprogram. 3 § skyddar namn och anseende, och den ger inte den tidigare programmeraren ett verktyg att stoppa vanlig drift eller vidareutveckling, så länge ändringen inte kränker det skyddet. Det betyder att den tidigare programmeraren inte kan avbryta vare sig den vanliga förvaltningen eller en omskrivning med stöd av 3 §, och just den delen av de ideella rättigheterna skulle vara farlig för företaget.

I lagen (2022:1712), som genomförde DSM-direktivet, finns däremot en annan, för företaget gynnsam regel som är värd att känna till, för annars kan den väntas från fel håll. Bestämmelserna om skälig ersättning och upphovsmannens rätt att få information om verkets utnyttjande, som för andra verkstyper låter upphovsmannen återkomma till frågan om betalning, tillämpas enligt 27 § inte på överlåtelse av upphovsrätt till datorprogram, och det betyder att en programmerare som anser att systemet visade sig värdefullare än parterna väntade sig inte på den grunden kan kräva extra ersättning.

Kvar finns rätten att anges som upphovsman och skyddet mot sådan användning av verket som kränker anseendet, och det är en betydligt mindre risk att leva med. Det viktiga är bara att inte blanda ihop två saker: omarbetning som ideell fråga är inte ett hinder för vanlig förvaltning, men omarbetning som ekonomisk rätt kräver fortfarande rättsinnehavarens tillstånd, och 28 §:s presumtion är att den som har fått rätten överlåten inte får ändra verket om det inte har avtalats. Har den ekonomiska delen stannat hos byrån behövs alltså fortfarande dess samtycke för att skriva om systemet.

Vad lagen ger även utan ett bra avtal

Även för ett företag som inte har formaliserat något ger lagen några möjligheter, och det är värt att veta vilka av dem avtalet kan ta ifrån och vilka det inte kan. 26 g § första stycket ger den som har förvärvat rätt att använda ett datorprogram rätt att framställa sådana exemplar av programmet och göra sådana ändringar som är nödvändiga för att använda programmet för dess avsedda ändamål, även rättelse av fel, men den rätten i första stycket kan avtalet inskränka, och många avtal gör det också.

Framställning av säkerhetsexemplar är ett annat fall, och den rätten kan avtalet inte ta ifrån, för 26 g § andra stycket ger den som har rätt att använda ett datorprogram rätt att framställa säkerhetsexemplar av programmet, om det är nödvändigt för den avsedda användningen, och det motsvarar artikel 5.2 i direktiv 2009/24/EG. Direktivets artikel 8 säger dessutom att avtalsvillkor som strider mot artikel 6 eller mot undantagen i artikel 5.2 och 5.3 är ogiltiga.

Här är det värt att vara precis, för skillnaden är fin och lätt att överdriva. 26 g § sista stycket säger att avtalsvillkor som inskränker användarens rätt enligt andra, fjärde eller femte stycket är ogiltiga, och 26 h § sista stycket säger samma sak om dekompilering. Säkerhetsexemplar kan alltså inte förbjudas i avtalet, och dekompilering — återgivning av programmets kod eller översättning av kodens form för att uppnå samverkansförmåga — kan inte heller förbjudas i avtalet.

Dekompilering är tillåten snävt och med villkor: den får göras för att uppnå samverkansförmåga mellan programmet och ett annat program, om informationen inte tidigare har varit lätt åtkomlig, den utförs av den som har rätt att använda programmet, och åtgärderna begränsas till de delar som den avsedda samverkansförmågan kräver. Den information som har tagits fram får inte användas för andra ändamål eller för att utveckla ett program med väsentligen likartad uttrycksform, och den här utvägen är användbar men smal, och inget företag vill att den ska vara den enda.

I systemet finns mycket kod som aldrig blir din

Ett skräddarsytt system är nästan aldrig bara den kod utvecklaren skrev, för merparten av volymen kommer från bibliotek och ramverk som redan fanns. Den koden blir aldrig din egendom, i inget avtal, för du får en licens från dess upphovsmän, och den skillnaden är viktig just när någon lovar att överlåta alla rättigheter till systemet.

Permissiva licenser skapar inget problem, för de kräver lite och begränsar inte hur det färdiga systemet får användas i näringsverksamhet. MIT-licensen tillåter att använda, kopiera, ändra, slå samman, publicera, sprida och sälja, bara upphovsrättsnotisen och själva licensen behålls, och programvaran lämnas över som den är, utan garantier, medan Apache 2.0-licensen lägger till en uttrycklig patentlicens och kräver att gjorda ändringar markeras. Båda är förenliga med ett slutet kommersiellt system, merparten av dagens ramverk är den ena av dem, och just därför kräver den här delen av systemet vanligtvis ingen förhandling.

Copyleft-licenser kräver uppmärksamhet, inte panik, och just här berättas oftast halvsanningar, trots att Free Software Foundation på sin GPL-frågesida klart skriver att ett företag som kör ett ändrat GPL-program på sin webbplats inte är skyldigt att publicera den ändrade källkoden, för copyleft-skyldigheten inträder när kopior lämnas till andra, inte när programmet används hos en själv. Att framställa och använda flera kopior inom en organisation är inte spridning, medan att lämna kopior till andra organisationer, även uppdragstagare för användning utanför företaget, redan är det.

Undantaget är Affero-licensen, och just dess 13 § — nätverksinteraktionsklausulen (AGPL §13) — är det som överraskar, för om du ändrar programmet och den ändrade versionen låter användare kommunicera med den på distans över ett datornät, då ska de användarna erbjudas möjlighet att få motsvarande källkod. Villkoren är två och båda behövs: ändring och fjärrinteraktion med användare, så det är inte riktigt att säga att all användning av Affero-licensen kräver publicering av källkod, och det är inte riktigt att säga att ett sådant bibliotek automatiskt lägger hela systemet under sig, för det beror på hur komponenterna är kopplade.

Deponering hos tredje part och vad den faktiskt ger

Källkodsdeponering (source code escrow) är en trepartsordning där utvecklaren lämnar källkoden till en neutral förvarare, men förvararen lämnar ut den till beställaren först när det fall som avtalet beskriver inträffar, och typiska fall är insolvens, att verksamheten upphör eller väsentlig underlåtenhet att uppfylla underhållsskyldigheten efter varning. I Sverige finns ingen lag som anger eller ens räknar upp de här fallen, så allt som fungerar här är det parterna själva har skrivit, och därför ska deponeringsavtalet läsas lika noga som själva utvecklingsavtalet.

Deponeringen ger precis det som har deponerats, och först när det som är beskrivet inträffar, men den överlåter inte i sig upphovsrätt, för där gäller åter 27 § om att överlåtelse av exemplar inte omfattar överlåtelse av upphovsrätt, och den lär inte ut hur systemet körs. Företaget NCC Group, som har sålt den här tjänsten i årtionden, medger det självt i sitt material: att källkoden finns i förvar är en sak, förmågan att kompilera den en annan, och just därför säljer samma företag också kontroll av det deponerade innehållet. Det är en parts bedömning, men det är ett medgivande om den egna kärntjänstens svaga punkt, och därför går det att använda.

Moderna system har också en andra brist, som inte har med den juridiska sidan att göra alls: om systemet körs som en tjänst på utvecklarens infrastruktur löser källkod utan körningsmiljö, konfiguration och data den minsta delen av problemet, för mottagaren får ett arkiv, inte ett fungerande system. I praktiken täcks den bristen genom att komplettera deponeringen med en överenskommelse om vem som tar över miljön och vad som händer om räkningarna för hostingen blir obetalda, och just de punkterna saknas vanligtvis i deponeringens standardformulär.

Konkurs är inte utanför det här trepartsavtalet bara för att upphovsrättslagen inte har en egen paragraf om det. Den praktiska slutsatsen är inte att avstå från deponering, utan att inte betrakta den som ersättning för skriftlig överlåtelse av rättigheter och regelbunden utlämning av källkod.

Var kodförrådet ligger och var data ligger

Frågan om var koden och data finns avgör mer än frågan om vem de tillhör, för rättigheter utan åtkomst är ett långsamt problem. GitHubs dokumentation beskriver tydligt att en organisation är ett gemensamt konto som äger kodförråd, att man inte loggar in som organisationen, för människor loggar in med personliga konton, och att organisationens ägare alltid har åtkomst till alla kodförråd; ett kodförråd kan tillhöra antingen ett personligt konto eller en organisation, och det valet är viktigare än det ser ut.

Om kodförrådet tillhör utvecklarens personliga konto är kundens åtkomst bara åtkomst som medarbetare, som kontoägaren kan ta bort när som helst, och när hen lämnar projektet tar hen också med sig själva adressen. Om kodförrådet tillhör kundens organisation, där utvecklaren är inbjuden som medlem, betyder ett avhopp att en åtkomst tas bort och inget mer, och det är en av de få saker i den här artikeln som kan lagas på en dag och utan jurist.

Data är en separat fråga, och där handlar det inte längre om upphovsrätt: om utvecklaren behandlar personuppgifter för din räkning, alltså kör produktionsmiljön, kommer åt kund- eller anställdas uppgifter eller tar säkerhetskopior, då är du personuppgiftsansvarig och utvecklaren personuppgiftsbiträde i dataskyddsförordningens mening. Förordningens artikel 28 kräver ett skriftligt avtal med vissa punkter: behandlingens föremål och varaktighet, art och ändamål, typer av uppgifter och kategorier av registrerade, samt den personuppgiftsansvariges rättigheter och skyldigheter.

Rent kodskrivande utan åtkomst till personuppgifter sätter inte artikel 28 i gång, så inte varje utvecklingsavtal behöver ett personuppgiftsbiträdesavtal. Gränsen är enkel och kontrollerbar: om utvecklaren kan se riktiga kunduppgifter behövs det, men om utvecklaren bara arbetar med testdata och inte ser produktionsmiljön behövs det inte, och det i sig är ett argument för att testmiljön ska vara separat.

Vad du får och vad du samtidigt tar på dig

Den här artikelns logik har hittills varit ensidig, så det är hederligt att också säga den andra sidan: full kontroll över ett skräddarsytt system är inte bara en vinst, utan också ett knippe skyldigheter som inte försvinner. För färdig programvara sköter tillverkaren förvaltning, säkerhetsuppdateringar och kompatibilitet med nya miljöer, och det ingår i abonnemanget, medan det för ett skräddarsytt system sköts av ägaren, alltså du, och det är en direkt utgift som dyker upp varje år oavsett om något ändras i systemet.

Det andra du tar på dig är systemets åldrande, som samlas tyst och inte syns på något sätt förrän någon letar efter det. Systemet vilar på språk- och ramverksversioner där tillverkarna sätter stödperioder, och efter de periodernas slut får nya sårbarheter inte längre några säkerhetsuppdateringar, även om systemet fortsätter att köra precis som förut och ingen skärm varnar för det. Det är inget förbud mot att köra ett åldrat system, men det är ögonblicket då ägaren tar över risken, och de konkreta datumen för PHP och Laravel har vi samlat i artikeln om vad det betyder att välja PHP och Laravel, så vi upprepar dem inte här.

Det tredje är marknaden, och till en färdig plattform är det förhållandevis lätt att hitta en specialist, för de utbildas och det finns flera, medan ett skräddarsytt system bara är känt av dem som byggde det, och en ny utvecklare måste få tid att sätta sig in innan hen kan ändra något säkert. Det betyder inte att en övertagning är omöjlig, men det betyder att den kostar, och den kostnaden dyker upp just när relationen med den tidigare utvecklaren redan är slut.

Just därför är frågan om vad du äger ingen juridisk formalitet, utan en fråga om hur dyrt nästa val blir. Ett företag med skriftlig överlåtelse, källkod i eget kodförråd och en lista över använda komponenter kan söka en ny utvecklare inom en vecka, medan ett företag utan allt det först tar reda på vad det över huvud taget får göra, och först därefter börjar söka, och det är skillnaden mellan att förhandla från en position och att förhandla från ett behov.

Vad du ska skriva in i avtalet medan det fortfarande går

Alla föregående avsnitt leder fram till ett litet knippe punkter som är värda att skriva in i avtalet före arbetets start, för efter överlämningen är förhandlingsläget mycket svagare. Den första är skriftlig överlåtelse av de ekonomiska rättigheterna, med namn på vilka rättigheter som övergår, på vilket territorium och för vilken tid, för 28 §:s presumtion är att förvärvaren inte får ändra verket och inte överlåta rätten vidare om det inte har avtalats, och lagen fyller inte i ett tyst territorium med det land där avtalet slöts. Den andra är en försäkran om att byrån har fått dem från sina anställda och underleverantörer, för utan det steget kan själva överlåtelsen vara tom.

Den tredje är regelbunden överlämning av källkoden och allt som behövs för att kompilera den, inte en engångsöverlämning i slutet av projektet, och den fjärde är att kodförrådet ligger på ditt organisationskonto redan från första dagen. Den femte är en lista över komponenter med öppen källkod och deras licenser, för utan den listan vet ingen senare vad som finns i systemet och på vilka villkor; den sjätte är ett personuppgiftsbiträdesavtal, om utvecklaren kommer att se riktiga uppgifter, och den sjunde är en överenskommelse om vad som händer med miljöer, nycklar och åtkomster när samarbetet tar slut.

Ingen av de här punkterna kräver en lång text, ingen av dem strider mot ett gott samarbete, och ingen hederlig utvecklare invänder mot dem, för de skriver ner precis det båda parter ändå tänker. Det enda de ändrar är att överenskommelsen inte längre beror på om de konkreta människorna om tre år fortfarande arbetar på samma företag och om någon minns vad som då sades muntligt. De här punkterna är värda att kräva av vilken utvecklare som helst, också av oss, och att skriva in dem i avtalet före arbetets start. Vår sida om skräddarsydd systemutveckling lovar just nu att lämna över källkod, dokumentation och infrastrukturkonfiguration vid arbetets slut, och just därför är den tredje punkten i den här listan, alltså regelbunden överlämning under arbetets gång, värd att avtala särskilt, inte att ta för given. Vill du att vi tittar på ett redan befintligt avtal, hör av dig.