Att avgöra vad som utgör en bearbetning av ett datorprogram kan var komplicerat, inte minst med tanke på att det kräver en hel del tekniskt kun-nande om hur datorprogram är uppbyggda, men även för att upp-hovsrättslagstiftningen ibland kan vara svår att tillämpa på datorprogram.
Upphovsrättslagstiftningen är ju främst anpassad för böcker och bildkonst och inte för datorprogram. Lagen är exempelvis svår att til??lämpa på pe-kare och referenser, vilka är sätt för datorprogram att anropa funktioner i
218 Se Open Source Click-Wrap Notice, http://www.rosenlaw.com/cw.html.
219 Se Nadan.
83 andra program utan att dessa behöver infogas i programmet.220 När det gäller programvara är dessutom distinktionen mellan ett separat tillägg till ett program och en bearbetning inte speciellt stor. Bearbetningar av dator-program kan – om de uppfyller kravet på originalitet – erhålla skydd en-ligt 4 § 1 st. UrL. Ändringar, mindre tillägg och triviala bearbetningar är inte skyddsbara utan ses istället som exemplarframställning. Kopiering av mindre delar av ett program torde även utgöra exemplarframställning så länge de dessa delar inte består av sådant som tillhör det allmänna form-förrådet.221
Det går att utskilja åtminstone fyra olika sätt att kombinera eller sam-manfoga datorprogram som antingen innebär bearbetning eller ex-emplarframställning av programmen. Det första mest självklara sättet är då källkoden faktiskt ändras för att skapa en förbättrad eller uppdaterad version av det ursprungliga programmet. I detta fall torde bearbetning of-tast vara för handen. Det andra sättet är att länka samman program genom antingen statisk eller dynamisk länkning.222 Det tredje sättet är när pro-grammeraren skapar ett tillägg till det ursprungliga programmet. Tillägget är ett fristående program som kommunicerar med det ursprungliga pro-grammet, vilket innebär att programmeraren åtminstone måste ha studerat det förra programmets källkod. Det fjärde sättet är att sammanställa flera olika program till t.ex. en distribution på CD-ROM. Programmen kommu-nicerar i detta fall inte med varandra, utan lagras enbart på samma medi-um. I detta fall torde det vara tydligt att ren exemplarframställning är för handen. I fall kravet på originalitet är uppfyllt kan dock samlingen som sådan erhålla ett separat skydd som samlingsverk enligt 5 § UrL.
De former av kombinering som orsakar flest tolkningsproblem är främst tillägg och länkning. I licenstexterna används dock oftast inte dessa termer. Istället används mer eller mindre krångliga definitioner främst för att undvika att licensen fixeras vid en specifik teknik. Punkt 2b i GNU GPL innehåller exempelvis den ganska snåriga formuleringen ”verk som delvis eller i sin helhet innehåller eller utgör en bearbetning av program-varan”. Bestämmelsen torde innefatta dels rena bearbetningar, men även kopiering av delar av programmet i ursprunglig eller bearbetad form.
Det-220 Se Slashdot: Interview: Bruce Perens Answers Open Source License Questions, http://slashdot.org/interviews/99/07/30/2220240.shtml.
221 Se Plogell 1996 s. 52, Praktisk IT-rätt s. 288, och Rosén 1998, s. 24.
222 Statisk och dynamisk länkning förklaras i ordlistan.
ta får anses inbegripa mer än vad som enligt lagen skulle anses utgöra en bearbetning.223
Ett sätt att undvika snåriga definitioner är att inte knyta kraven i li-censen till skapandet av bearbetningar, utan till huruvida programvaran ändrats eller ej. Eftersom bestämmelsen i 26 g § UrL är dispositiv kan upphovsmannen i licensavtalet starkt begränsa eller helt avtala bort an-vändarens rätt att vidta nödvändiga ändringar i programmet. Då rätten att ändra i programmet både utgör en av de fyra friheterna och är en av punk-terna i OSD, så torde dock denna möjlighet inte utnyttjas i någon större utsträckning i licenserna. Vissa av licenserna knyter dock vissa krav till huruvida programvaran ändrats eller ej, vilket får ses som en form av vill-korad ändringsrätt.
Eftersom licenstagaren har obegränsad tillgång till det licensierade programmets källkod torde utgångspunkten i detta avseende vara att varje form av användning, ändring eller översättning av källkoden samt tillägg utgör efterbildning av det licensierade programmet, så vida det inte kan visas att tillägget utgör ett självständigt verk.224
Problemet vad gäller licenser för fri programvara rör främst faststäl-landet av en nedre gräns för vad som kan anses innebära ett utnyttjande av upphovsmannens verk. Det gäller här att avgöra vilken grad av sam-mankoppling mellan två program krävs för att det ena programmet skall anses utgöra en bearbetning av det andra programmet och vilka former av utnyttjanden som skall ses som ren exemplarframställning.
I enlighet med det ovan sagda torde statisk länkning innebära att ex-emplarframställning är för handen eftersom det ena programmet kopieras in i det andra programmet under länkningen. Om originalitetskravet är uppfyllt så torde även det länkande programmet kunna utgöra en be-arbetning av det länkade programmet.
Det är dock mer oklart vad som gäller när programmets källkod inte på något sätt har ändrats. Om t.ex. programmets helt eller delvis kopieras in i ett annat program innebär detta att ett exemplar framställs av det li-censierade programmet. Men vad gäller när två program enbart kommu-nicerar via ett publicerat API?225 I dessa fall kopieras inte programmen in i varandra, utan de utbyter enbart information. Relationen mellan pro-grammen är dessutom övergående och upphör när exekveringen är slut-förd. Begreppet bearbetning inte kan troligen inte utsträckas till att omfatta
223 Jfr Green, Lisa, Meeker, Heather, Open Software Licenses: part II, Intellectual Property Strategist, juli 1999.
224 Jfr Bing, s. 290.
225 API står för Application Programming Interface och förklaras utförligare i ordlistan.
85 program som enbart utbyter information mellan varandra.226 Därmed skulle kommunikation mellan program via API:er t.ex. inte omfattas av punkt 2b i GNU GPL.
Det är även oklart vad som gäller för användning av programbibliotek.
Den allmänna ståndpunkten torde vara att användning av programbibliotek i ett program åtminstone innebär att det framställs ett exemplar av pro-grambiblioteket.227
FSF anser dock att all form av länkning, såväl statisk som dynamisk, innebär att en bearbetning skapas. Det innebär att program vars licens inte är kompatibel med GNU GPL, inte kan länka till ett program licensierat enligt GNU GPL och tvärtom. Om licensgivaren vill tillåta licenstagaren att dynamiskt länka licensierad programvara till andra program är det där-för bättre att använda LGPL.
Till synes råder det stor osäkerhet både om vad som utgör en bear-betning av datorprogram och vad som faller utanför begreppet. Då frågan ännu inte har fått sin lösning i domstol finns det fortfarande en stor osä-kerhet på området.228
Nedan följer några konkreta situationer där begreppet bearbetning i re-lation till datorprogram har satts på sin spets. Det innebär att diskussionen i vissa fall måste läggas på en viss programmeringsteknisk nivå.
9.3.1 Drivrutiner och insticksprogram
Det har förekommit flera diskussioner om huruvida drivrutiner och in-sticksprogram som anropar ett annat program är att anse som en bear-betning av det anropade programmet.229
Situationen kan illustreras med installation av en ny skrivare på en da-tor. För att kunna använda en ny skrivare krävs oftast att en ny drivrutin installeras. Skrivardrivrutinen används av t.ex. ett ordbehandlingsprogram
226 Se Rosen 2001b.
227 Jfr Zimran och preambeln till LGPL. Huruvida programmet som länkar till programbiblioteket även är att se som en bearbetning av biblioteket är dock mer tveksamt. Rosen menar t.ex. att sådan länkning till programbibliotek oftast sker utan att utvecklaren överhuvudtaget tittar på källkoden till biblioteket. Se Rosen, Lawrence (2002a), Derivative Works,
http://www.rosenlaw.com/html/GL18.pdf.
228 Jfr Praktisk IT-rätt, s. 289.
229 En drivrutin är en programvara som utgör del av ett operativsystem och ansvarar för anslut-ningen av yttre enheter som t.ex. skrivare, ljudkort, grafikkort. Ett insticksprogram är en pro-gramvarumodul som fungerar som ett tillägg till ett program eller system för att hantera en viss funktion. Adobe Acrobat och Macromedia flash är exempel på vanliga insticksprogram till webbläsare.
varje gång ett dokument skrivs ut. När det gäller installation av sådana drivrutiner så förändrar de inte ordbehandlingsprogrammets funktion på något sätt.230 Om drivrutinen byts ut, eller tas bort, slutar ord-behandlingsprogrammet för den skull inte att fungera. Det kan tyckas ba-nalt att ens diskutera bearbetning i detta fall, men ofta måste drivrutiner eller insticksprogram göra visa systemanrop till t.ex. kärnan i operativ-systemet. I regel förutsätter detta att skaparen av drivrutinen har studerat källkoden till det program som anropas.
Om programmet som anropas licensieras enligt GNU GPL, blir den specifika teknik som valts för att göra anropet avgörande för om drivru-tinen eller insticksprogrammet också måste licensieras enligt GNU GPL.
FSF har klargjort att om drivrutinen eller insticksprogrammet t.ex. an-vänder anrop som fork() eller exec() tillämpas inte GNU GPL. Men om programmen istället dynamiskt länkar till varandra, gör funktionsanrop till varandra eller delar datastrukturer så måste GNU GPL eller en kom-patibel licens användas. Samma sak gäller om det istället vore det anro-pande programmet som licensierades enligt GNU GPL.231
Linus Torvalds – skaparen av Linux – anser emellertid inte att program som gör systemanrop till Linux-kärnan omfattas av begreppet bearbetning.
Han har därför i sina distributioner av Linux-kärnan gjort ett eget tillägg till preambeln i GNU GPL.232 Detta tillägg gör det tillåtet för alla program att dynamiskt länka till Linux-kärnan.
FSF fortsätter dock att vidhålla sin egen tolkning av begreppet bear-betning. De flesta verkar dock ha anammat den av Torvalds framförda uppfattningen att begreppet inte kan utsträckas till att omfatta dynamisk länkning.233
9.3.2 Klasser och moduler
De flesta diskussioner om vad som utgör en bearbetning av ett datorpro-gram handlar om länkning. Prodatorpro-grammeringsspråk som Java och Perl an-vänder sig dock inte av en länkare på samma sätt som exempelvis språket C gör. Kod i Perl interpreteras vid exekvering och kod som skrivits i Java omvandlas till ett mellanformat kallat ”bytekod” innan den tolkas av Javas
”virtuella maskin”.
230 Jfr Rosen 2001b.
231 Se Frequently Asked Questions about the GNU GPL.
232 Tillägget till preambeln finns återgivet i Open Sources, appendix B, s. 263.
233 Se t.ex. Rosen 2002a och Ries.
87 Ett Java-program består normalt av flera olika klasser utspridda på flera olika filer. Klasserna hämtas dynamiskt av den virtuella maskinen in i programmet vid exekvering. Eftersom själva bearbetningen av pro-grammet sker först när propro-grammet exekveras har det diskuteras huruvida punkt 2b i GNU GPL är tillämplig i detta fall.
Enligt FSF är det ingen principiell skillnad mellan detta och vanlig länkning. Ett program som använder en Java-klass licensierad enligt GNU GPL måste därför också följa samma licens.234 Eftersom ett vanligt Java-program kan använda ett mycket stort antal klasser kan det innebära stora tillämpningsproblem om vissa klasser följer GNU GPL och andra t.ex.
BSD:s licens.
Lösningen kan vara att licensiera klasserna enligt en licens som LGPL, vilken tillåter dynamisk länkning utan begränsningar. En annan lösning är att göra ett speciellt tillägg till GNU GPL – en lösning som t.ex. används av programbiblioteket classpath.235
Språket Perl använder moduler istället för klasser, men länkningen sker även i detta fall dynamiskt vid exekvering av Perl-programmet. Perl licensieras dubbelt enligt både Artistic License och GNU GPL vilket in-nebär att flertalet av alla Perl-moduler kan tänkas använda GNU GPL.236 I enlighet med vad som sagts ovan måste därmed ett program som använder en Perl-modul som licensieras enligt GNU GPL också följa denna li-cens.237