Standardavtalet skyddar leverantören, inte er IP

När ett tech-bolag anlitar en utvecklingsbyrå, en frilanskonsult eller en teknisk samarbetspartner används nästan alltid ett standardavtal, ofta framtaget av leverantören själv. Det är sällan ont uppsåt bakom det. Standardavtal är effektiva att skriva under snabbt. Problemet är att de nästan alltid är formulerade för att skydda den som skrev dem, inte den som betalar räkningen.

Enligt svensk upphovsrättslig huvudprincip tillfaller rättigheterna till ett verk den som faktiskt skapat det, om inget annat avtalats. Det betyder att en utvecklare eller konsult i grunden behåller rättigheterna till sin egen kod om avtalet inte uttryckligen säger något annat. Många bolag förutsätter i stället, felaktigt, att den som betalar för arbetet automatiskt också äger resultatet. Utan en tydlig överlåtelseklausul är det förutsättningen som är fel, inte lagen.

Den viktigaste frågan i vilket utvecklingsavtal som helst är vem som äger resultatet. I många standardavtal är svaret otydligt, eller formulerat så att leverantören behåller rättigheter till komponenter, bibliotek eller metoder som utvecklats under uppdraget, medan kunden bara får en licens att använda den färdiga leveransen. Det kan fungera bra i vardagen, ända fram till den dag bolaget vill sälja, ta in en investerare, eller byta leverantör.

Detsamma gäller kod som byggs med hjälp av öppen källkod eller tredjepartsbibliotek, där licensvillkoren kan begränsa hur resultatet får användas eller säljas vidare. Ett utvecklingsavtal som inte alls berör den frågan lämnar bolaget i mörker om vilka byggstenar i den egna produkten som faktiskt är fria att använda utan begränsning och vilka som bär med sig villkor bolaget aldrig läst.

Det är i en investeringsrunda eller ett förvärv som otydligheten blir synlig. En köpares juridiska genomgång, due diligence, går systematiskt igenom vem som äger varje del av produkten. Ett bolag som inte kan visa ett tydligt, obrutet ägarskap till sin egen kod riskerar att värderingen sänks, att affären försenas, eller i värsta fall att den spricker helt.

Tänk dig ett SaaS-bolag som under sina första år anlitat flera olika konsulter och byråer för att bygga sin produkt, var och en under sitt eget standardavtal. När bolaget några år senare ska ta in en extern investerare visar det sig att ägarskapet till flera centrala moduler aldrig överfördes tydligt till bolaget. Det som borde vara en formalitet i due diligence-processen blir i stället veckor av efterforskning, kontakt med gamla leverantörer och osäkerhet som investeraren prisar in i ett lägre bud.

Det gäller även interna anställningsavtal, om än på ett annat sätt. Svensk lag ger arbetsgivaren en starkare ställning till det som skapas inom ramen för en anställning, men gränserna för vad som räknas som “inom ramen för anställningen” är inte alltid självklara, särskilt för medarbetare som bidrar till kod utanför sin formella roll eller på sin fritid med bolagets verktyg.

Problemet handlar sällan om ont uppsåt från leverantörens sida. Det handlar om att ingen på köparens sida läste igenom rättighetsklausulen tillräckligt noga innan avtalet skrevs under, eftersom den delen av texten känns som juridiskt standardspråk snarare än en fråga som avgör bolagets framtida värde.

Problemet blir sällan synligt förrän någon utomstående faktiskt läser avtalen med nya ögon. Bolagets egen ledning har ofta levt med samma leverantörer och samma avtalstexter så länge att otydligheten känns som ett normalt, accepterat läge, snarare än en risk som växer för varje år som går och för varje ny modul som byggs ovanpå den gamla, oklara grunden.

En rättighetsklausul som fungerar för köparen bör göra tre saker tydliga. Den ska säga att alla rättigheter till det som utvecklas övergår till kunden vid betalning, och inte stanna vid en licens att använda det. Den ska hantera vad som gäller för kod eller material som leverantören redan hade innan uppdraget, så att gränsen mellan gammalt och nytt är tydlig. Och den ska beskriva vad som händer med underleverantörer som leverantören i sin tur anlitar, så att kedjan av rättigheter inte bryts någonstans i mitten.

Ett enkelt första steg är att gå igenom de senaste årens avtal med externa utvecklare och byråer, och markera vilka som saknar en tydlig rättighetsklausul. Den listan behöver inte åtgärdas på en gång, men den ger en realistisk bild av hur stort arbetet faktiskt är innan det blir bråttom.

Det svåra är inte att identifiera problemet i ett enskilt avtal. Det svåra är att hålla koll på det över flera år och flera leverantörer, i takt med att bolaget växer och antalet avtal med extern kod ökar, utan att det finns en person vars uppgift är att se helheten snarare än varje enskilt avtal för sig.