Reader

I dette uddrag af min kommende bog om fri software skriver jeg om forbindelsen mellem fri software og den bevægelse for fri kultur, som juristen Lawrence Lessig grundlagde omkring årtusindeskiftet.

Denne bevægelse er grunden til, at vi i dag har “Creative Commons”-licenser, som lige præcis er inspireret af den type licenser, som beskytter fri software mod at blive “lukket inde” og gjort proprietær.

Dette er et større emne, og dette er det første af tre eller fire uddrag, som kredser om forholdet mellem fri software og fri kultur. Dele af nedenstående blev i let omskrevet form bragt som kronik i Information tilbage i august 2012.

Fri software og fri kultur

Den måske vigtigste aflægger af bevægelsen for fri software er bevægelsen for fri kultur, der i alt væsentligt er grundlagt af den amerikanske jurist Lawrence Lessig. Lessig er professor i jura ved Princeton-universitet og har i mange år og i adskillige bøger og foredrag talt for en langt mindre restriktiv fortolkning og formulering af lovgivningen omkring ophavsret. Bevægelsens formål er at skabe en juridisk virkelighed, der svarer til den kulturelle praksis, vi alligevel har og ikke mindst gerne vil have. Lessig formulerer sin kritik af nutidens “ufrie” digitale kulturliv med kraftig inspiration fra Richard Stallmans opgør med den ufrihed, som proprietær software og den hermed forbundne hemmeligholdelse af kildekoden pålægger brugeren. Faktisk er de to problemer intimt forbundne.

For eksempel har de store medieselskaber i årevis ønsket at udgive deres materialer med en teknologi, der hedder “kopibeskyttelse” (“Digital Rights Management” eller DRM på engelsk). Kopibeskyttelse af ophavsretligt beskyttet materiale – det kan for eksempel være en sang fra en CD, en DVD-film eller den bog, du er ved at læse netop nu – skal som navnet antyder forhindre brugeren i at kopiere og videregive materialet uden tilladelse, men det kan gå videre end som så. Kopibeskyttelsen er en kryptografisk indkapsling af materialet, som betyder, at leverandøren bestemmer, hvordan og hvor ofte du kan afspille eller tilgå det. Microsofts hedengangne MP3-afspiller Zune gjorde det for eksempel muligt at “låne” dine sange ud ved at lægge dem over på en vens Zune – men kopibeskyttet, så de kun kan afspilles tre gange. Efter tre gange har din ven ikke længere nogen gavn af sangen og kan lige så godt slette den. Det “beskyttede” materiale er krypteret og kan kun åbnes ved hjælp af en krypteringsnøgle, som styres af opretshaveren i samarbejde med producenten af den gadget, du ser eller hører materialet på.

Det interessante er her, at det materiale, som du har købt og betalt eller på anden vis er kommet lovligt i besiddelse af, er krypteret med en nøgle, der er installeret i din DVD- eller MP3-afspiller eller på din computer, for at beskytte det mod dig. Men eftersom krypteringsnøglen nødvendigvis må være på den maskine, du bruger til at åbne materialet med, er den egentlig allerede under din kontrol. Rent teknisk eller praktisk er der ikke noget til hinder for, at du finder nøglen og låser sangen eller filmen op én gang for alle, hvorefter du kan gøre med den, som du vil. Denne form for kopibeskyttelse vil med andre ord altid være ineffektiv, eftersom den forudsætter, at du selv er i besiddelse af såvel det materiale, der skal beskyttes, som den kode, der kan låse det op. Løsningen på dette problem er juridisk: Efter pres fra musik- og filmindustrien indførte USA i 1998 en lov, der kaldes The Digital Milennium Copyright Act. Den forvandler blandt meget andet brud på kopibeskyttelsen til en strafbar handling. USA har lige siden lagt pres på andre landes regeringer for at få dem til at indføre lignende regler, og i 2001 indførte EU-kommissionen det såkaldte Infosoc-direktiv. Infosoc-direktivet forbyder “parallel-import” af musik og film og har dermed afskaffet en vigtig del af den frie konkurrence inden for underholdningsbranchen. Det pålægger også alle medlemslande at forbyde brud på kopibeskyttelsen.

Dette eksempel viser, hvor tæt forbundet spørgsmålet om en fri kultur eller et frit kulturliv er med spørgsmålet om fri software. I det digitale samfund, hvor vi bruger computere til at producere bøger, film og musik, og hvor vi i stigende grad bruger dem til at læse eller afspille dem også, er det computerprogrammer, der sætter grænserne for hvad vi kan gøre ved de kunstværker, der er vor generations kulturelle udtryk og bidrag. Fri software-bevægelsens påstand er, at dine rettigheder som borger i et sådant samfund kun kan sikres, hvis du altid har ret til at undersøge, hvordan de enkelte programmer på din computer virker og ændre denne virkemåde, hvis du ikke er tilfreds med den. Det væsentlige argument for dette er, at eftersom din computer handler på dine vegne, må du også til hver en tid have ret til at bestemme, hvad det egentlig er, den gør. Kopibeskyttelsen og de juridiske begrænsninger, der følger med, strider direkte mod disse rettigheder. Det program, der håndhæver kopibeskyttelsen, har den helt specifikke klausul indbygget, at du ikke må gøre ved det, som du vil, eftersom du kan retsforfølges for at bryde kopibeskyttelsen. Et program, der håndhæver kopibeskyttelsen, handler ikke længere på dine, men på rettighedshaverens vegne. Det er ulovligt at bruge dit kendskab til computerens og programmets virkemåde til at omgå beskyttelsen, også selv om det er for at gøre ting, som du faktisk ville have ret til at gøre med materialet, hvis det ikke var kopibeskyttet.

Lawrence Lessig nævnte i en tale i 2002 den kopibeskyttelse, der er indbygget i Adobe Acrobat Reader som eksempel på, hvordan teknologien kan bruges til at fratage brugere (læsere) af e-bøger rettigheder, som de helt selvfølgeligt ville kunne regne med, hvis der var tale om fysiske eksemplarer. Et eksemplar af Shakespeares samlede værker kan være omfattet af restriktioner, der forbyder læseren af kopiere mere end ti citater fra teksten på ti dage, eller at udskrive mere end ti af bogens sider på ti dage. Men ophavsretten på Shakespeares værker er for længst udløbet. Adobes e-bogsteknologi kan dermed bruges til at fratage læserne rettigheder, som de ellers kunne tage for givet. Der er intet juridisk grundlag for at pålægge køberne af en bog, hvor forfatterens ophavsret er udløbet, begrænsninger i deres ret til at citere fra bogen eller fremstille kopier til sig selv; men selve kopibeskyttelsen bliver, i kraft af den lovgivning, der forbyder ethvert forsøg på at omgå den, i sig selv en juridisk bindende begrænsning af, hvad man lovligt kan gøre ved en e-bog, man har erhvervet på denne måde. Brugerens eller kundens rolle reduceres her til at gøre med værket, præcis hvad leverandøren har bestemt, og intet andet. Disse restriktioner kan kun indføres og håndhæves, fordi loven pålægger dig som bruger nogle restriktioner med hensyn til, hvad du må gøre med filer, som du i øvrigt har erhvervet på lovlig vis. Kampen for en fri kultur, hvor adgangen til værker ikke kan omgærdes af vilkårlige begrænsninger, bliver dermed blot endnu et aspekt af den bredere teknologiske kamp for en fri og åben teknologisk infrastruktur, som motiverer arbejdet med udbredelse af fri software.

Lessig anerkender derfor Stallmans betydning for sit eget arbejde for en fri kultur. Han betragter Stallman ikke blot som en visionær leder, men som tidens måske væsentligste filosof, som han forklarer i forordet til Stallmans bog “Free Software, Free Society”:

Our generation has a philosopher. He is not an artist, or a professional writer. He is a programmer. Richard Stallman began his work in the labs of MIT, as a programmer and architect building operating system software. He has built his career on a stage of public life, as a programmer and an architect founding a movement for freedom in a world increasingly defined by “code.”

“Code” is the technology that makes computers run. Whether inscribed in software or burned in hardware, it is the collection of instructions, first written in words, that directs the functionality of machines. These machines — computers — increasingly define and control our life. They determine how phones connect, and what runs on TV. They decide whether video can be streamed across a broadband link to a computer. They control what a computer reports back to its manufacturer. These machines run us. Code runs these machines.

What control should we have over this code? What understanding? What freedom should there be to match the control it enables? What power? These questions have been the challenge of Stallman's life. Through his works and his words, he has pushed us to see the importance of keeping code “free.” Not free in the sense that code writers don't get paid, but free in the sense that the control coders build be transparent to all, and that anyone have the right to take that control, and modify it as he or she sees fit. This is “free software”; “free software” is one answer to a world built in code.

(...)

The aim of Stallman's “free software movement” is to make as much code as it can transparent, and subject to change, by rendering it “free.”

The mechanism of this rendering is an extraordinarily clever device called “copyleft” implemented through a license called GPL. Using the power of copyright law, “free software” not only assures that it remains open, and subject to change, but that other software that takes and uses “free software” (and that technically counts as a “derivative work”) must also itself be free. If you use and adapt a free software program, and then release that adapted version to the public, the released version must be as free as the version it was adapted from. It must, or the law of copyright will be violated.

(...)

There are those who call Stallman's message too extreme. But extreme it is not. Indeed, in an obvious sense, Stallman's work is a simple translation of the freedoms that our tradition crafted in the world before code. “Free software” would assure that the world governed by code is as “free” as our tradition that built the world before code.

Jeg har medtaget det forholdsvis lange citat fra Lessigs forord (der i lighed med resten af bogen kan læses på adressen http://www.gnu.org/philosophy/lessig-fsfs-intro.html) for at understrege forbindelsen til Lessigs eget projekt. Hvor bevægelsen for fri software sigter mod at gøre den digitale infrastruktur, som vi opbygger med computerprogrammer og protokoller, lige så åben som den “gamle”, analoge verdens fysiske infrastruktur, forsøger bevægelsen for fri kultur at sikre, at man også i en digital verden kan dele og arbejde videre med kulturelle produkter på samme måde, som man kunne, før vi fik computere.

Tilhængere af en meget restriktiv fortolkning af ophavsretten fremfører gerne, at en verden, hvor man tillader fri kopiering og videregivelse af andre folks værker er en verden, hvor kunstnere ikke får lov til at leve af deres arbejde, og hvor den skabende kunstners originale bidrag til kulturen ikke påskønnes efter fortjeneste. Lessigs og andres argument mod det sidste er, at skabende kunstnere altid har ladet sig inspirere af andres værker. Digtere har efterlignet hinandens rytmer, musikere og komponister har efterlignet hinandens melodier, og hver gang en maler finder på en ny stil, udløser det et væld af mere eller mindre talentfulde efterlignere. Shakespeare, der af mange anses for at være Europas største og mest originale dramatiker nogensinde, byggede de fleste af sine stykker på gamle historier, som publikum måtte formodes at kende i forvejen. Den remix-kultur, som mange moderne plade- og filmselskaber beskylder for at berøve dem deres levebrød, er ikke opstået i forbindelse med den digitale teknologi, den er et grundvilkår ved enhver kunstnerisk virksomhed. “Den talentfulde kunstner låner – geniet stjæler”, som Oscar Wilde udtrykte det.

Lawrence Lessig mener, at vi på grund af den skærpede ophavsret og de urimelige restriktioner, som forbrugere af digital kultur pålægges gennem den juridiske beskyttelse af selv den mest drakoniske “kopibeskyttelse”, risikerer at miste kontakten til hele vores kulturarv. Et eksempel på et sådant tab er de mange film fra begyndelsen af det 20. århundrede, som aldrig blev særlig kendte og som derfor måske kun eksisterer i få eksemplarer. Disse film kan let risikere at gå tabt på grund af ligegyldighed og heraf følgende skødesløshed og dårlige opbevaringsforhold. Der fandtes ikke en afleveringspligt for film i stil med den, der i Danmark gælder for bøger, så en gammel, mugnende filmrulle på loftet af en faldefærdig sidegadebiograf i en afsides del af San Francisco kan være det eneste eksisterende eksemplar af et hidtil ukendt film noir-mesterværk. Det er et faktum, at mere end halvdelen af alle amerikanske film fra før 1950 allerede er gået tabt. Kampen for at bevare denne kulturarv er en kamp mod uret, for selv under de bedste opbevaringsforhold er celluloid-filmenes holdbarhed begrænset. Her virker det oplagt at sætte ind med en kulturel redningsaktion og samle og digitalisere så mange af disse gamle film, som man overhovedet kan komme i nærheden af. Men ophavsretten stiller sig i vejen. Det er ikke noget problem, hvis man skal have tilladelse til at vise Mickey Mouse eller “Borte med blæsten” i fjernsynet, men for mange gamle films vedkommende er det umuligt at finde ud af, hvem der ejer rettighederne til dem. Det betyder, at blot det at digitalisere og udgive en enkelt film kan indebære et større detektivarbejde for at opspore efterkommerne af en films producer, instruktør eller manuskriptforfatter.

Noget lignende gælder for bøger. Ophavsretten til en bog gælder i forfatterens levetid plus 70 år. Det vil sige, at vi 2012 frit kan trykke og på anden måde gengive alle litterære værker, hvis forfatter er død senest i 1942. Det betyder, at de fleste betydelige litterære værker, der blev skabt før dette år, efterhånden kan læses gratis på nettet på Projekt Gutenberg (gutenberg.org) og lignende sider. Med værker, der er skrevet af forfattere, der stadig levede i 1942, forholder det sig imidlertid anderledes. Flere af den tids mesterværker er udkommet i det ene oplag efter det andet, for eksempel Hans Kirks “Fiskerne”, Karin Boyes “Kallocain” eller Hans Scherfigs “Det forsømte forår”. Men de fleste bøger udkommer kun i ét oplag og læses ikke af særlig mange.

Hvis du gerne vil læse en upåagtet bog fra 1950erne, er det tvivlsomt, om du kan få fat på den. I Danmark er der pligtaflevering til Det Kongelige Bibliotek, så der har de måske et eksemplar, hvis det ikke er stjålet eller ødelagt i mellemtiden. De fleste almindelige biblioteker skiller sig jævnligt af med bøger, der er mere end ti år gamle, så de kan få nye ind på hylderne. Hvis du er heldig, kan du finde bogen hos et af de antikvariater, der offentliggør deres lagerbeholdning på nettet. I modsat fald kan du være tvunget til at opsøge alle landets antikvariater efter tur, hvis du vil gøre dig håb om at skaffe bogen. Hvis det lykkes dig at finde bogen og den viser sig at være så god, at du gerne vil tage initiativ til en genudgivelse, må du først opspore forfatteren og bede om tilladelse. Måske har forfatteren ingen nulevende efterkommere, eller måske er værket så politisk eller moralsk kontroviersielt, at forfatterens pinligt berørte efterkommere ikke ønsker at have noget med det at gøre. Hvis forfatteren døde i 1970, er det helt umuligt at genudgive den før i år 2040 – og inden da kan du selv være død og dit eksemplar gået tabt. Ophavsretten er god til at sikre nulevende forfattere deres rettigheder, så de kan leve af deres bøger, men fejler, når det gælder om at redde upåagtede værker fra fortabelse og glemsel. Den slags værker er, hvad Lessig kalder “orphan works” eller forældreløse værker.

I litteraturhistorien er det et velkendt fænomen, at hver generations største forfattere ofte er upåagtede i deres levetid og for alvor begynder at blive kendt længe efter deres død. Med en ophavsret, der effektivt sikrer forældreløse værker mod genudgivelse de første hundrede til hundrede og halvtreds år efter deres tilblivelse, risikerer en stor del af de bøger, der løbende udgives i oplag på fem hundrede eksemplarer eller mindre og herefter aldrig genudgives, at gå uigenkaldeligt tabt. Vore dages skærpede ophavsret går langt ud over, hvad der er nødvendigt for at sikre forfattere og andre kunstnere deres indtjening, og repræsenterer i stedet en trussel mod den store del af verdens kulturarv, som de “forældreløse værker” udgør. Og dette er for en stor dels vedkommende til ingen nytte. De fleste kunstnere tjener pengene på deres værker i årene umiddelbart efter udgivelsen. Kun meget få har stadig indtægt på salg af bøger tyve eller tredive år efter, at de udkom første gang.

Lessig og andre forkæmpere for fri kultur har i stedet foreslået en kortere løbetid for ophavsretten. Et forslag går ud på at strukturere løbetiden som en to- eller tre-trinsraket. Da “copyright” oprindelig blev indført i England, var det som et privilegium, som trykkerne og dermed forlagshusene fik bevilget i 14 år efter udgivelsen. Efter de 14 år var eneretten udløbet, og alle kunne uhindret trykke løs. En “tre-trins-raket” kunne i stedet opretholde den ophavsretlige beskyttelse så længe, som de fleste kunstnere kan have nytte af den, mens det samtidig bliver meget lettere at bevare værker, som er på vej til at forsvinde ud i glemslen. Vi kan forestille os, at ethvert værk er beskyttet af ophavsretten de første 21 år efter udgivelsen. Når de 21 år er gået, vil ophavsretten udløbet, men det er muligt at forny den.

Fornyelsesprocessen bør være hurtig og smertefri men kræver altså, at kunstneren eller forfatteren gør noget aktivt for at bevare ophavsretten til sit værk. Efter fornyelse er værket beskyttet af ophavsretten i yderligere 21 år. Efter 42 år skal det igen være muligt at forny ophavsretten. Denne gang koster det dog et gebyr, som for eksempel kunne være 1000 af vore dages kroner. Efter 42 år kan der altså opnås endnu 21 års ophavsretlig beskyttelse; den eneste forudsætning er, at forfatteren har en tilstrækkelig økonomisk interesse i værket, til at fornyelsen er 1000 kroner værd. Når de 21 år i den anden fornyelsesperiode er gået, er ophavsretten udløbet og kan ikke yderligere fornys.

En sådan model vil i alt væsentligt fortsætte den ophavsretlige beskyttelse, som vi kender i dag, uden at “forældreløse” værker risikerer at gå så uigenkaldeligt tabt, som tilfældet er med den nuværende lovgivning – og det uden reelle omkostninger for forfatterne. Der er en hel del af de mere populære moderne forfattere, der stadig har indkomster på bøger, som de udgav for mere end 21 år siden. Disse kan blot ved at indsende en ansøgning om fornyelse sikre deres ophavsret og dermed deres indtægter i yderligere 21 år. Hvor mange forfattere har stadig indkomst på bøger, som de udgav for 42 år siden? Det er der nogle ganske få af de allermest populære forfattere, der har, og hvis indtægterne fra disse bøger kan tænkes at få en fortsat økonomisk betydning for forfatteren, kan de fornys i yderligere 21 år for en afgift på 1000 kroner. Hvis forfatteren til den tid ikke finder det umagen værd at betale for at forny sin ophavsret, er det formentlig fordi, bøgerne ikke længere har noget stort økonomisk potentiale, hvorfor forfatteren ikke mister noget ved at lade ophavsretten udløbe. Efter 63 år er der i praksis ikke mere at komme efter. De allerfleste store og populære bøger skrives af folk, der er fyldt 20. I en alder af 83 vil de fleste enten være døde eller have ordnet deres økonomiske forhold på anden vis. Hvad de skrev og udgav for 63 år siden er for længst ophørt med at have nogen reel økonomisk betydning for dem.

En sådan “tre-trins-raket” vil altså ikke tage indtægter fra nogen nulevende kunstnere, der har brug for dem, men den vil gøre det muligt at sikre miskendte og upåagtede værker mod glemsel ved at gøre det muligt at genudgive dem uden at indhendte tilladelse fra en forfatter, som i værste fald kan være helt umulig at finde frem til. Det betyder selvfølgelig, at de foreninger, som har gjort det til deres mission at tjene så mange penge ind som muligt ved at forvalte ophasvretten for nogle få og helt store forfatteres værker efter regelen om forfatterens levetid plus 70 år vil miste deres indtægter. Her tænker jeg blandt andet på boerne efter forfattere som James Joyce og J.R.R. Tolkien. Hertil er blot at sige, at hvis en ændring af lovgivningen fører til, at efterkommere af enkelte store forfattere kastes ud i fattigdom, kan der tages hensyn til dem gennem en overgangsordning. Det er trods alt et helt ekstremt mindretal af kunstnere, der stadig har indtægter mange år efter deres død. Ophavsretten har altid haft som sit egentlige formål at gavne samfundet ved at sikre levebrødet for de mange kunstnere, mens de endnu er i live, ikke at sikre de mest populæres efterkommere i flere generationer.

I dette uddrag fra min kommende bog om fri software fortæller jeg om softwarepatenter — patenter på “opfindelser”, der kan implementeres som software — og hvorfor de er en dårlig idé.

Softwarepatenter er et emne, der har været diskuteret i større og mindre grad gennem årene. Truslen fra dem har forekommet mindre i de senere år, bl.a. fordi enkelte “patenttrolde” har inkasseret nederlag i retten.

Truslen består dog, og er af en særligt ubehagelig karakter, fordi disse patenter betyder, at en patentholder potentielt kan sagsøge ikke blot udviklere af et givet produkt, men også aftagere — med andre ord, almindelige brugere såvel som virksomheder, der vælger at bruge fri software som f.eks. LibreOffice eller Linux i det daglige arbejde.

Fri software og patenter

GPL og andre “copyleft”-licenser giver en god beskyttelse mod kommercielle virksomheders forsøg på at overtage frie programmer og udkonkurrere den oprindelige version. Der findes dog en anden trussel mod fri software som fænomen, der kan pålægge brugere og udviklere af frie programmer en række ganske uoverskuelige økonomiske forpligtelser.

Dette er patenter. I efteråret 2007 erklærede Microsofts administrerende direktør Steve Ballmer, at Red Hats GNU/Linux-systemer Fedora og Red Hat Enterprise Linux krænker mere end 200 af Microsofts softwarepatenter, og at man en dag vil trække de store firmaer, som bruger Red Hats produkter, i retten. Fri software-bevægelsens svar på denne udfordring var i alt væsentligt: Hvilke patenter drejer det sig om? Ballmers svar var, at det ville Microsoft ikke fortælle, for så ville Red Hat og de andre udviklere af GNU/Linux-systemer jo bare tage den del af funktionaliteten ud, og så ville Microsoft miste sit krav på deres produkt.

Dette svar viser, at Microsoft i virkeligheden ikke var interesseret i at håndhæve sine patenter, men snarere havde til hensigt at skræmme potentielle kunder fra at bruge Linux-baserede systemer og anden fri software ved at henvise til en ikke nærmere defineret juridisk trussel og hermed sprede frygt, usikkerhed og tvivl om anvendelsen af fri software i kommercielle miljøer. Denne strategi er så almindelig fra især Microsofts side, at den har fået sit eget navn, nemlig FUD – en forkortels for de engelske ord “Fear, Uncertainty and Doubt”.

I 2007 lancerede Microsoft også en slags “ikke-angreps-pagt” med den nu hedengangne softwaregigant Novell, der indebar, at Microsoft lovede aldrig at retsforfølge brugere af GNU/Linux-distribution “SUSE Linux”, som Novell dengang ejede.Dette rejser naturligvis det spørgsmål, om SUSE Linux og andre GNU/Linux-systemer overhovedet indeholdt eller indeholder nogen bevidste brud på Microsofts patenter? Microsoft har i hvert fald optrådt, som om de var så sikre i deres sag, at man kunne forledes til at tro det. Men svaret på det spørgsmål er formentlig nej. Sandheden er, at udviklere af fri software historisk set har gjort, hvad de kunne, for at undgå at krænke Microsofts eller andres softwarepatenter. Dette gælder ikke mindst udviklerne af de helt store systemer som Linux-kernen eller kontorpakken LibreOffice. Det er de simpelt hen nødt til for at undgå, at der bliver lagt sag an mod udviklere eller brugere.

Det er bare ikke så nemt at undgå at krænke eksisterende softwarepatenter, som man kunne tro. Det skyldes blandt andet, at praksis med at udstede patenter for “opfindelser” begået i software grundlæggende er yderst problematisk. De fleste landes lovgivning tillader ikke patentering af rene, matematiske sandheder eller algoritmer, og eftersom programmeringssprog først og fremmest er en matematisk notation, betyder det også, at det burde være umuligt at tage patent på software-baserede “opfindelser”. I 1994 medførte en ændring af den amerikanske retspraksis omkring patenter imidlertid, at der kan tages patent på softwarebaserede opfindelser. Denne praksis har lige siden udgjort en alvorlig trussel mod alle former for fri software.

For at forstå, hvordan det kan hænge sammen, må vi se på, hvad det overhovedet vil sige at tage patent på et computerprogram. Vi har allerede set, at et computerprogram må betragtes som et “værk” på linje med et kunstnerisk værk eller litterært værk og derfor automatisk er omfattet af lov om ophavsret. Patenter beskytter ikke værker, men ideer. Dette kan synes at være en akademisk forskel, men også i det kunstneriske liv er der tale om en væsentlig forskel. Hvis jeg skriver en roman om en mand, der bliver myrdet på en ganske bestemt måde, hvorefter en piberygende, analytisk detektiv opklarer sagen og finder morderen ved hjælp af sin overlegne intelligens, kunne folk beskylde mig for at plagiere Arthur Conan Doyles fortællinger om Sherlock Holmes. Hvis ikke ophavsretten til disse bøger forlængst var udløbet, kunne boet efter forfatteren måske lægge sag an mod mig for krænkelse af Conan Doyles ophavsret. Men hvis jeg kan bevise, at jeg aldrig i hele mit liv har hørt om hverken Sherlock Holmes eller Conan Doyle men har fået ideen helt af mig selv, kan jeg ikke beskyldes for at krænke ophavsretten, eftersom mit værk ikke tager udgangspunkt i Conan Doyles.

Med patenter er det anderledes: Et patent er ikke en eneret på et værk, men på en idé. Når først patentet er givet, er det derfor ligegyldigt, om opfinderen af en maskine, der krænker patentet, har kendt til det. Hvis Conan Doyle havde taget patent på historier, hvor medlemmer af overklassen bliver myrdet eller på anden måde kommer i knibe, hvorefter sagen bliver opklaret af en kæderygende og kokainmisbrugende analytisk mesterdetektiv, ville ethvert værk med samme grundlæggende plot krænke patentet – også selv om dets forfatter aldrig havde hørt om Conan Doyles udførelse af ideen. Denne situation kan ikke opstå med en kriminalroman, eftersom det ikke er muligt at tage patent på litterære ideer. Jeg vil i det følgende argumentere for, at det af stort set samme grunde heller ikke burde være muligt at tage patent på computerprogrammer. Helt præcist bør en opfindelse eller idé aldrig kunne patenteres, hvis den kan realiseres alene ved hjælp af software.

Men hvorfor egentlig ikke? Er det ikke i orden, at de folk, der gør nye opfindelser, kan beskytte sig imod plagiat, og taler modstandere af softwarepatenter ikke blot for, at de selv uhindret kan nyde frugterne af opfindelser, som deres konkurrenter har investeret betydelige mængder af tid og penge på? Når vi taler om “fysiske” opfindelser (som f.eks. telefonen, flyvemaskinen og diverse andre gadgets, som den moderne teknologi har beriget verden med), kan der være noget om snakken. Udvikling og ikke mindst produktmodning af en helt ny maskine koster betydelige ressourcer, og hvis konkurrenterne uden videre har lov til at kopiere opfindelsen, kan de underbyde opfinderen ved at sende en langt billigere model på gaden. Konkurrenten har jo ingen udviklingsfase at finansiere. Det betyder, at uden patenter ville interessen for at investere i nye opfindelser være begrænset. Det ville også være ret nemt at sætte en dygtig opfinder eller innovativ virksomhed ud af spillet straks efter deres første succes. Patenter kan dog også have ulemper. Et firma kan besidde et uhyre nyttigt patent og ikke bruge det, hvilket i sidste ende kan være skadeligt for samfundet som helhed. Det kan også være, at opfinderen kræver så ublu afgifter af andre for brug af sit patent, at markedet bliver underforsynet med en livsvigtig kommoditet.

Som eksempel på den første type skadevirkning kan nævnes, at USA før 2. verdenskrig ikke var i stand til at bygge et moderne fly. Det krævede nemlig en forening af teknologier, som var patenteret af konkurrerende virksomheder, og disse ønskede ikke at samarbejde om noget som helst. Da krigen brød ud, skar regeringen igennem og ophævede patenterne mod en mindre erstatning til deres ejere. Et godt eksempel på den anden type skadevirkning er medicinalfirmaernes afvisning af at lade fattige lande kopiere deres AIDS-medicin. I Brasilien lykkedes det under Lulas første regeringsperiode i nullerne at gennemtvinge en aftale med medicinalfirmaerne ved at true med at bryde patenterne og lave medicinen selv, hvis ikke de kunne få den til en rimelig pris. Den brasilianske regering kunne derfor holde AIDS nede ved at sørge for medicin til alle, der havde brug for den. I Afrika syd for Sahara kostede disse patenter og deres strenge håndhævelse utallige menneskeliv, indtil medicinalfirmaerne gav sig og tillod, at “generiske” versioner af disse stoffer kunne fremstilles og indføres. Problemet består dog, og især i mellemindkomstlande er patenter på AIDS-medicin og alt for høje priser stadig et problem. Traditionelle patenter kan altså have deres fordele såvel som deres ulemper. Helt anderledes med softwarepatenter, som kun har ulemper.

Det har at gøre med den måde, software bliver til på. Et større softwareprojekt minder i mange henseender om et korthus, eller måske snarere om en masse byggeklodser. Overordnet set kan programmet forstås som en model af en motor, der driver den funktionalitet, der stilles til rådighed for brugeren. Denne overordnede struktur er programmets arkitektur. De mere tekniske detaljer implementeres af algoritmer, der som virtuelle tandhjul gemmer sig inde i maven af de byggeklodser, hvor de hører hjemme. Nogle arkitekturer og algoritmer er mere hensigtsmæssige end andre, og softwareudvikling præges derfor af, hvad programmører spøgefuldt kalder at “genopfinde den dybe tallerken”. De samme teknikker, algoritmer og strukturer genopfindes og genopdages igen og igen af forskellige programmører uafhængigt af hinanden, simpelt hen fordi de virker og fordi mange af dem er ret oplagte.

Problemet med softwarepatenter er altså, at hvis jeg sætter mig ned og skriver et nyt program (f.eks. et spil, et tekstbehandlingsprogram eller en Internetbutik), kommer jeg nødvendigvis til at løse en lang række problemer, som andre har løst før mig. Hvis denne form for “opfindelser” anerkendes som patentberettigede, kan jeg let have overtrådt adskillige patenter uden at ane det. I et område, hvor alle løser de samme (eller nært beslægtede) problemer fra grunden om og om igen, repræsenterer patentet et monopol på løsninger, som alle, der beskæftiger sig med det pågældende problemområde, er dømt til at falde over før eller senere.

Et eksempel på dette er internetbutikken Amazons patenterede “one-click”-salg. Når du har oprettet dig som kunde på Amazon og indtastet dine kreditkortoplysninger, kan du købe en bog eller et andet produkt ved at klikke kun én gang. Dette brugerinterface er en patenteret opfindelse, og indtil patentet udløb (det gjorde det i 2017) måtte ingen andre amerikanske internetbutikker sælge varer ved tryk på kun én knap uden at få tilladelse til det af Amazon. Men enhver, der nogen sinde har prøvet at designe et brugerinterface, vil på dette tidspunkt udbryde, at det er selvindlysende. Den “opfindelse” ville også uden Amazons hjælp være gjort igen og igen af andre designere. Men Amazon havde altså eneret på den i tyve år og kunne kræve store erstatninger af enhver, der måtte have formastet sig til at bryde patentet.

Men er det egentlig et problem? Folk kunne jo bare lade være med lige at lave en en-kliksløsning på deres internetbutik. Men dette løser kun en del af problemet. Hvad nu, hvis nogen ikke havde hørt om Amazons patent og havde fundet på det helt af sig selv?

Et softwareprojekt består af tusinder og atter tusinder af designbeslutninger og tekniske valg. Hvis noget så banalt som Amazons en-kliks-løsning kan patenteres, er der i realiteten ikke nogen af de valg, som kan forventes at være sikre mod krav fra en eller anden patenthaver. Det er lidt, som hvis ét firma havde patent på at dyrke korn og et andet på at dyrke grøntsager, og den eneste måde at få adgang til en varieret kost være at handle hos et af disse patentholdende firmaer, som så kunne bytte indbyrdes og holde alle andre ude.

Og det er desværre ikke engang nogen overdrivelse. I USA er der udtaget hundredetusinder af softwarepatenter, og deres vigtigste værdi er, at de store spillere – IBM, Microsoft, Adobe, den størrelsesorden – til hver en tid kan slå de mindre softwarehuse i hovedet med patenter, som alle er nødt til at bryde for overhovedet at kunne skrive et sammenhængende program. De store kan sikre sig arbejdsro ved at bytte patenter, mens de små firmaer og individuelle programmører, som i praksis altid står for den reelle nyskabelse i IT-verdenen, kun kan fungere på de stores nåde og barmhjertighed. I praksis betyder det, at enhver, som beslutter sig for at skrive et nyt program fra grunden, i princippet er tvunget til at afsætte tid og juridisk ekspertise til at undersøge, om de eventuelt skulle have krænket et eller andet patent. Det vil sige, at ethvert softwareprojekt i princippet er behængt med en enorm juridisk møllesten om halsen, der let kan fordoble et mindre projekts totale pris. I praksis vælger man i stedet at ignorere patenter ud fra den betragtning, at “software alene” ikke kan patenteres efter gældende ret, men det er risikabelt, fordi mange patenter reelt er givet til “software alene” — både i USA og Europa. Såkaldte “patenttrolde” er berygtede for at true softwareleverandører, som de beskylder for at have krænket deres patenter, ofte i den forhåbing, at leverandøren ikke har råd til at gå i retten og evt. få patentet kendt ugyldigt. Softwarepatenter udgør derfor en betydelig risiko for mindre softwareproducenter, herunder ikke mindst projekter, der arbejder med fri software. De eneste, der er sikre, er stor koncerner som Microsoft, Amazon, Facebook, Apple eller IBM, der har patenter at “bytte med”. De små kan holdes tilbage, og de store har fri bane.

Patenter på software er dermed en potentiel trussel mod fri software og mod uafhængig software i det hele taget, indtil der kommer en klar retspraksis på området, der simpelt hen forbyder patenter på software. I skrivende stund (2025) er truslen hverken fremherskende eller dominerende, men dette kunne, så længe den aktuelle retspraksis består, hurtigt ændre sig.

I dette uddrag fra min kommende bog om fri software fortæller jeg om, hvordan begrebet “open source” blev til som et forsøg på at popularisere og ikke mindst sælge begrebet “fri software” i bredere og mere kommercielle sammenhænge.

Dette gav anledning til en splittelse i bevægelsen, som i hvert fald én af initiativtagerne til open source-begrebet, nemlig Debian-udvikleren Bruce Perens, kort tid efter kom til at fortryde.

Fri software og Open Source

Da IT-forlæggeren Tim O'Reilly, der står bag en række af de mest solgte og anvendte bøger om teknisk IT og beslægtede emner, i april 1998 indkaldte til sit såkaldte “Freeware Summit” — et “topmøde” om fri software — havde Eric Raymond allerede holdt sit foredrag om “katedralen og basaren” adskillige gange. Foredraget blev bl.a. modtaget med stående ovationer på Linux Kongress i Tyskland. Da browserproducenten Netscape i februar 1998 bekendtgjorde, at de ville frigive kildekoden til næste version af deres internet-browser under navnet “Mozilla”, angav de Raymonds essay som en vigtig inspiration. O'Reillys Freeware-konference var tænkt som et mødested for folk i Linux- og fri software-miljøet på den amerikanske vestkyst, og bevægelsens repræsentanter på østkysten var derfor ikke inviteret. Den mest bemærkelsesværdige konsekvens af dette var, at Richard Stallman heller ikke var inviteret – han havde jo base i Cambridge, Massachusets.

Under mødet kunne de af bevægelsens ledere, som faktisk var inviteret – bland andet Tim O'Reilly selv, Michael Tiemann fra Cygnus, Guido van Rossum, opfinder af programmeringssproget Python, og ikke mindst Eric S. Raymond – få luft for deres frustration over problemerne med at få fri software ud i den virkelige verden, det vil sige i virksomheder. Der fandtes på det tidspunkt mange programmer af overlegen teknisk kvalitet, som var stort set gratis at bruge og som gav alle de fordele for brugeren, som fulgte af, at det var fri software. Alligevel var det stort set umuligt at trænge igennem med ideen i erhvervslivet. Mange deltagere mente, at det var Free Software Foundations og GNU-projektets ofte meget politiske retorik, der var den største anstødssten. Forvirringen mellem de to betydninger af ordet “free” på engelsk, nemlig “fri” og “gratis”, gjorde ikke sagen bedre. De fleste forstod på det tidspunkt ordene “free software” som “gratis software”, og det prægede reaktionen på direktionsgangene. Er “gratis software” overhovedet noget, man kan tage seriøst? En ideologisk forklaring om, hvorfor fri software ikke altid er “gratis”, men giver brugeren “frihed”, gjorde ikke altid sagen bedre.

Og bortset fra Stallmans of Free Software Foundations insisteren på at tale om frihed og understrege de politiske og filosofiske fordele ved fri software, kunne deres kommunikation og argumentationsform også være besværlig i sig selv. Richard Stallman kunne især være endog meget rigid og kategorisk i sine synspunkter, hvilket som tidligere nævnt gav (og stadig giver) ham et ry for at være vanskelig at være sammen med.

Perens udtrykte det f.eks. sådan her:

“I really like and admire Richard. I do think Richard would do his job better if Richard had more balance. That includes going away from free software for a couple of months.”

Free as in freedom, kapitel 11

Et tilbagevendende emne på O'Reillys “Freeware Summit” var derfor, om man ikke kunne finde en bedre måde at præsentere det på. Linux-projektet havde vist, at åbenhed omkring kildekoden kan give et teknisk set bedre resultat, og det var naturligvis det, som først og fremmest kunne interessere folk i erhverslivet. Michael Tiemann fra Cygnus foreslog derfor, at man kunne kalde det “sourceware”.

Kort tid forinden havde Eric Raymond dog i anledning af Netscapes “åbning” af kildekoden til deres browser (det, som senere blev til Mozilla-projektet og Firefox) holdt en række møder med Netscape og Linux-firmaet VA Linux, hvor Christine Peterson fra tænketanken Foresight Institute også deltog. Til et af disse møder foreslog Peterson, at man kunne kalde det “open source software”, og den idé gjorde så stort et indtryk på Raymond og andre, at de allerede i februar 1998 stiftede organisationen “Open Source Initiative”, der havde til formål at udbrede kendskabet til “open source”-metoden og dens fordele. Debian-udvikleren Bruce Perens omskrev Debians egen definition på fri software (Debian Free Software Guidelines, som han selv havde formuleret i sin tid som Debian-projektets leder) til en officiel “Open Source Definition”, der er kompatibel men ikke identisk med Stallmans og Free Software Foundations.

Til topmødet i april foreslog Raymond derfor, at software, der frit kan ændres og deles, skulle kaldes “Open Source Software” — og som bekendt blev det det forslag, der vandt. Efter mødet var alle femten deltagere enige om fremover at henføre til fri software som “Open Source”.

Formålet med den nye betegnelse var meget klar: Stifterne af Open Source Initiative og deltagerne i O'Reillys Freeware Summit satte alle stor pris på de praktiske fordele ved fri software og den frihed, den gav. Til gengæld var de trætte af den moraliserende og politiserende holdning, der gennemsyrede Free Software Foundations kommunikation om det. Open Source-bevægelsen ville i stedet lægge vægt på de tekniske fordele ved “open source”-metoden som eksemplificeret ved Linux-kernen, programmeringssprogene Python og Perl, editoren Emacs, oversætteren GCC — og nu også den kommende version af Netscape. Pludselig var “Open Source” og “Linux” på alles læber, og da VA Linux kort efter gik på børsen, blev Eric Raymond — fra den ene dag til den anden — millionær på Open Source-revolutionen.

“Open Source”-begrebet var en vigtig del af dotcom-boomet i slutningen af 1990'erne. Bevægelsen overlevede dog fint, da boblen sprang, og det store boom gik hen og blev et bust.

Bemærkelsesværdigt nok begyndte Perens, der jo havde skrevet de officielle retningslinjer for, hvad der er “Open Source”, allerede i 1999 at fortryde den splittelse, han havde været med til at skabe i miljøet. I en email til Debians udviklere forklarede han under overskriften “It's Time to Talk About Free Software Again”, hvorfor han havde besluttet at forlade “Open Source”-bevægelsen:

Most hackers know that Free Software and Open Source are just two words for the same thing. Unfortunately, though, Open Source has de-emphasized the importance of the freedoms involved in Free Software. It's time for us to fix that. We must make it clear to the world that those freedoms are still important, and that software such as Linux would not be around without them.

One of the unfortunate things about Open Source is that it overshadowed the Free Software Foundation's efforts. This was never fair – although some disapprove of Richard Stallman's rhetoric and disagree with his belief that all software should be free, the Open Source Definition is entirely compatible with the Free Software Foundation's goals, and a schism between the two groups should never have been allowed to develop. I objected to that schism, but was not able to get the two parties together. [...]

Sadly, as I've tended toward promotion of Free Software rather than Open Source, Eric Raymond seems to be losing his free software focus. The Open Source certification mark has already been abused in ways I find unconscionable and that I will not abide. I fear that the Open Source Initiative is drifting away from the Free Sofware values with which we originally created it.

(http://lists.debian.org/debian-devel/1999/02/msg01641.html)

Perens' bekymring er et ekko af Stallmans mere ideologisk formulerede kritik: “Open Source”-begrebet havde stor succes med at få folk til at tale om fri software og bruge det, men fik dem til at glemme eller overse, hvad det egentlig betyder og hvorfor det er så stor en fordel for brugerne.

For “open source”-folket var det vigtigst at tale om de rent tekniske og økonomiske fordele ved de programmer, man kunne få som Open Source: At fejl nemmere kan finde og rettes, når alle frit kan inspicere kildekoden; at både uændrede og forbedrede versioner frit kan videregives til andre, hvilket gør programmerne meget billigere at anskaffe og vedligeholde; at der er tusinder eller millioner af dollars at spare ved at satse på “open source” frem for dyre og ikke altid lige gode løsninger fra store proprietære leverandører som f.eks. Microsoft eller IBM. Men for Stallman og de folk, der tænkte som ham, var den ensidige fokus på de tekniske og økonomiske fordele et vildspor.

Det skal bemærkes, at samtlige stiftere af “open source”-bevægelsen og Open Source Initiative også forstod og var helt enige i filosofien bag fri software i Stallmans forstand. Open source var med Eric Raymonds ord først og fremmest tænkt som en reklamekampagne for fri software. “Open Source” var et begreb, der gjorde det muligt at få fri software ind ved at tale til direktører, bestyrelser og politiske beslutningstagere i et sprog, de kunne forstå. For Raymond helligede målet midlet — også selv om midlet havde den pris, at man gemte bevægelsens politiske og filosofiske grundlag af vejen.

Stallman påpegede, ikke helt med urette, at der er en fare i denne tilgang: Hvis man skjuler den grundlæggende tanke om brugerens frihed, risikerer man at tabe netop de egenskaber ved fri software af syne, som faktisk giver fordelene. På den måde kunne “open source”-bevægelsen ligesom i sin tid Linux-entusiasterne ses som en slags nassere, der nød godt af de fordele og den frihed, som Free Software Foundation og GNU-systemet har banet vejen for, men ikke selv vil kendes ved eller kæmpe for ideerne bag.

Med Stallmans egne ord:

The main argument for the term “open source software” is that “free software” makes some people uneasy. That's true: talking about freedom, about ethical issues, about responsibilities as well as convenience, is asking people to think about things they might rather ignore. This can trigger discomfort, and some people may reject the idea for that. It does not follow that society would be better off if we stop talking about these things.

(https://www.gnu.org/philosophy/free-software-for-freedom.en.html)

Some of the supporters of open source considered the term a “marketing campaign for free software,” which would appeal to business executives by highlighting the software's practical benefits, while not raising issues of right and wrong that they might not like to hear. Other supporters flatly rejected the free software movement's ethical and social values. Whichever their views, when campaigning for open source, they neither cited nor advocated those values. The term “open source” quickly became associated with ideas and arguments based only on practical values, such as making or having powerful, reliable software. Most of the supporters of open source have come to it since then, and they make the same association. Most discussion of “open source” pays no attention to right and wrong, only to popularity and success.

(https://www.gnu.org/philosophy/open-source-misses-the-point.en.html)

Og der var ganske rigtigt en stor risiko for udvanding. Hvis det var muligt at levere en komplet IT-infrastruktur baseret på “open source” til en brøkdel af, hvad store proprietære leverandører som Microsoft eller IBM forlangte, kunne fristelsen være stor til at levere pakken med en særligt attraktiv sløjfe omkring, for eksempel i form af en suite af proprietære programmer, der kun blev leveret sammen med netop denne leverandørs GNU/Linux-system. Dette blev en del af forretningsmodellen for firmaer som Red Hat og det tyske SuSE GmbH.

Det populære skrivebordsmiljø KDE, der i mange år var standarden inden for brugergrænseflader på GNU/Linux-systemer, var baseret på Qt, en grafikpakke, der var udviklet af det norske firma Trolltech og var 100% proprietær. Det betød, at mange programmer skrevet til GNU/Linux reelt var låst fast, fordi de ikke uden videre kunne flyttes til andre systemer (fx Microsoft Windows) uden tilladelse fra Trolltech. “Open source”-bevægelsens fokus på de rent tekniske fordele ved fri software beskytter ikke mod denne form for undergravende virksomhed. Hvis argumentet for at bruge fri software er, at det er “smart”, har man nemlig tabt kampen, når et “halvfrit” system med få eller mange proprietære udvidelser viser sig at være endnu smartere. Men kundernes afhængighed af sådanne proprietære udvidelser betyder netop også, at de igen bliver afhængige af leverandørens gode vilje, og dermed risikerer fordelene også ved den “smarte” open source-software stille og roligt at forsvinde.

Omkring slutningen af 1990erne, da KDE var den eneste virkelig værdifulde brugergrænseflade til GNU/Linux, lancerede GNU-projektet med Stallman i spidsen det såkaldte GNOME-projekt. Det havde til opgave at skabe et konkurrerende grafisk arbejdsmiljø, der var 100% fri software. Mange programmører foretrak nu at skrive programmer til GNOME, fordi de så ikke behøvede at bygge på proprietær software og derfor ikke behøvede at spørge hverken Trolltech eller nogen anden om lov, før de udsendte deres programmer til Windows eller hvilket system, de nu havde lyst til. Som modtræk frigav Trolltech i år 2000 Qt under GPL, så begge udgaver af GNU/Linux-systemet – med GNOME eller KDE som brugergrænseflade – nu atter var 100% fri software. Dette resultat blev ikke opnået på grund af “open source”-folkets vilje til kompromis, men af de “fanatiske purister” i Free Software Foundation, der altid stod fast på principperne, hvorved de langsomt men sikkert har fået de andre aktører på “open source”-området til at give sig.

I 2025, næsten tredive år efter denne initielle polemik mellem begreberne “fri software” og “open source”, er der dog grund til at advare mod at gentage eller fastholde den splittelse, der ligger i at insistere på den ene eller den anden term. Jeg taler selv altid om fri software, fordi de politiske og filosofiske ideer bag denne term er vigtige, men mange mennesker, der måske ikke altid kender bevægelsens historie så godt, kender de selvsamme idealer under navnet “open source”.

På hjemmesiden for Free Software Foundation Europe (FSFE) skriver Björn Schießle, der udover sin aktivitet for FSFE til daglig arbejder for NextCloud, om denne problematik:

The Free Software movement is a large and diverse community. People have different interests in Free Software and different reasons to participate. But these differences don't necessarily connect with the terms they use. A lot of people use the term Open Source even while highlighting the social and political dimension of Free Software while on the other hand there are people in our community who prefer the term Free Software but concentrate more on the practical benefits. Whether someone says Open Source or Free Software isn't necessarily an indication of their motivation. (...) Free Software provides many advantages in many different areas of our life. But we should not divide our community just by the term someone prefers. No matter what term someone uses and what their initial motivation is, in the end they works on the same set of software and on the enhancement of software freedom and any other aspect of Free Software.

(https://fsfe.org/freesoftware/comparison.en.html)

Selv om Stallman bestemt havde og har en pointe i sin kritik af “open source”-begrebet, og netop har opnået mange vigtige ting netop ved at stå fast, hvor andre gav efter — som eksemplet med Gnome og KDE viser — er det med andre ord og ikke mindst i vore dage bedre at kigge efter åbninger og samarbejdsmuligheder i den frie softwares ånd end det er at grave grøfter.

I dette uddrag fra min kommende bog om fri software hører vi om, hvordan en ung datalogistuderende i 1991 begyndte at lave et helt nyt styresystem, der i dag er gratis til rådighed for alle og bruges på hundreder af millioner af computere verden over.

Og om, hvordan det både lagde grunden til en længere konflikt i bevægelsen for fri software, og hvordan Linus Torvalds uforvarende kom til at opfinde “open source”-metoden.

Linus Torvalds og Linux

I den kronologiske fortælling er vi nu ved at være fremme ved år 1991. Det år tog GNU-systemet sit næste store skridt fremad, da den dengang 21-årige finske datalogistuderende Linus Torvalds blev træt af at spadsere tværs over Helsinkis universitetsområde i den kolde nordiske vinter. I forbindelse med studiet havde Torvalds fulgt et kursus i styresystemer. Herfra vidste han, at den amerikansk/hollandske datalog Andrew Tanenbaum havde skabt et UNIX-lignende styresystem ved navn MINIX, der kunne køre på ganske almindelige PC'er som Torvalds' egen. Med det installeret kunne han eksperimentere med styresystemer og hardware på sin egen computer derhjemme og behøvede ikke gå hele vejen for at bruge en af universitetets computere.

Torvalds var interesseret i at undersøge funktionerne i sin egen computers CPU, den dengang ret ny Intel 80386-processor. Han begyndte derfor at skrive et simpelt UNIX-lignende styresystem. Han kom hurtigt så langt, at han kunne opfange input fra tastaturet og vise det på skærmen og begyndte at kigge sig om efter måder, hvorpå han kunne føje endnu mere funktionalitet til sit lille, hjemmebyggede system.

Torvalds havde få måneder forinden set Richard Stallman holde foredrag på universitetet i Helsinki og var meget opmærksom på de grundlæggende ideer bag fri software. For Torvalds handlede det mest om gensidighed: Jeg deler mine programmer og min kildekode med dig på den betingelse, at du også deler de ændringer, du selv laver. GNU-værktøjerne passede perfekt til Torvalds' planer om at kunne bygge et nyt styresystem på sin egen PC. Han begyndte derfor at tilpasse sit system, så de forskellige GNU-programmer kunne køre på det. Til sidst havde han noget, som ikke var tilfredsstillende, men dog virkede.
Tiden var kommet til at fortælle verden om det nye system, og det gjorde Torvalds den 25. august 1991 på Usenet-gruppen comp.os.minix:

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).

... I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :–)

(https://fossbytes.com/linus-torvaldss-famous-email-first-linux-announcement/)

Det system, der senere blev kendt under navnet Linux, var født.

Selve Linux-kernen var dog ikke Linux-projektets største nyskabelse. Linus Torvalds fortsatte nemlig med at annoncere nye udgaver af systemet ud på nyhedsgruppen comp.os.minix. Her kunne andre entusiaster downloade systemet, forsøgte at køre det på deres egne computere, rette fejl i kildekoden og tilføje deres egne udvidelser. Torvalds bad om, at man sendte rettede udgaver af systemet tilbage til ham. Så snart han havde modtaget disse, flettede han dem sammen med sin egen kode, så de kunne komme med i fremtidige versioner. Efterhånden som systemet blev bedre blev det også mere populært. Allerede i midten af 1990erne var det nye styresystem vokset fra en enkelt studerendes private hobbyprojekt til et stabilt og professionelt Unix-lignende system, der blev brugt til filservere og arbejdsstationer på universiteter verden over. Den stigende udbredelse betød, at endnu flere fik lejlighed til at arbejde på det, og Linux-systemet voksede som ved en sneboldseffekt. På det tidspunkt var systemets udvikling for længst flyttet fra nyhedsgruppen comp.os.minix til den nyoprettede comp.os.linux. Folk sendte deres bidrag, hvor de havde fået en ny del af systemet eller en ny slags hardware til at virke med linux-kernen, til nyhedsgruppen, og Linus Torvalds modtog alle bidrag og indarbejdede dem i sin egen udgave af systemet. Torvalds opfandt dermed uden at være klar over det open source-metoden, det distribuerede samarbejde over Internettet, som i dag karakteriserer stort set alle fri software-projekter.

Udvekslingen af kode mellem bidragyderne blev lettet af, at Torvalds i 1992 besluttede at udsende sit styresystem under GNU General Public License, der som allerede beskrevet var den licens, som Richard Stallman havde udviklet for at sikre, at GNU-systemet altid ville forblive frit. Dette forpligtede alle, der ønskede at offentliggøre nye versioner af systemet, til også at offentliggøre kildekoden – og når nu de var ved det og Linus gerne ville have den, sendte de den som regel til ham også. Valget af licens garanterede, at man uden problemer kunne bruge samtlige GNU-programmer med det nye Linux-system. Eftersom GNU-værktøjer som tekstbehandlingsprogrammet Emacs og oversætteren GCC allerede var standard i de datalogiske og generelt naturvidenskabelige institutter på universiteterne, bidrog det kun til Linux' popularitet.

Allerede i 1993 begyndte styresystemet “Linux” at dukke op i kommercielle pakker, og i samme år grundlagde Ian Murdoch den ikke-kommercielle og fællesskabs- eller community-drevne Linux-udgave Debian – opkaldt efter Murdoch selv og hans hustru Deborah. Debian udviklede sig efterhånden til en af de vigtigste og mest stabile udgaver af Linux-systemet.

Linux' uventede succes havde umiddelbart to ofre. For det første var der Andrew Tanenbaums lille Unix-system Minix, som indtil 1991 havde været et af de få Unix-lignende systemer, der kunne bruges på almindelige PC'ere. Minix blev solgt, primært til undervisningsbrug, sammen med al sin kildekode. Minix var i modsætning til Linux ikke fri software, og det kunne ikke deles frit, hver enkelt bruger var nødt til at købe sit eget eksemplar. Da Linux kom frem og kunne deles frit, var Minix pludselig meget mindre attraktivt. Det andet offer var Free Software Foundations egen kerne, GNU/Hurd. Da Linux for alvor begyndte at slå an i akademiske kredse, var der ikke længere det samme pres for at færdiggøre det i forvejen hårdt ramte Hurd-projekt. På en måde kunne det også være lige meget. GNU-systemet havde allerede fået en kerne, og den hed Linux.

Linux' popularitet udløste snart en konflikt mellem Linus Torvalds' gruppe af meget aktive entusiaster, hvis primære interesse i systemet var at skabe noget, der virkede (og have det sjovt så længe), og Free Software Foundation med Richard Stallman i spidsen, hvis vision var politisk: De arbejdede på at skabe et system, der var og forblev frit for alle at bruge.

Konflikten var altså primært ideologisk. Linus og hans horder af hobby-entusiaster ville først og fremmest rode med teknikken og interesserede sig ikke altid for bevægelsens politiske og filosofiske mål. Kontrakten bag GPL så de som et middel til at sikre, at de selv havde adgang til fremtidige versioner af deres egen kode.

Richard Stallman var ikke tilfreds. Der eksisterede nu et fuldt færdigt styresystem, som byggede på det arbejde, han og hans samarbejdspartnere i Free Software Foundation havde udført — men der var ingen, der talte om andet end “Linux”. Linux' popularitet betød, at fri software og især GNU-projektets programmer blev mere udbredte, men det var der ikke rigtig nogen af systemets nye brugere, der vidste noget om.

Der opstod også praktiske problemer i samarbejdet mellem Linux-programmørerne og de ansatte og frivillige i Free Software Foundation. I arbejdet med at integrere GNU-værktøjerne med den nye kerne stødte Linux-folkene på en del fejl og mangler ved GNU-værktøjerne. I den samarbejdets ånd, som de selv var slået ind på, begyndte de at sende rettelser og ønsker om ny funktionalitet ind til GNU-projektets medarbejdere. Men her stødte de på en uventet forhindring. Hvor Linus som projektleder gerne ville have alt med og derfor gerne tog en ny funktion med i tillid til, at eventuelle fejl nok skulle blive rettet, var GNU-projektet præget af MIT-hackernes tekniske perfektionisme.

GNU-programmørerne ville hellere bruge timer på at diskutere en løsning end risikere at introducere en fejl i de færdige programmer. De begyndte også at miste tålmodigheden med den stadige strøm af henvendelser fra Linux-programmører, der ville have optaget deres egen kode i GNU. De begyndte at besvare disse henvendelser med nedsættende bemærkninger om kvaliteten af Linux-folkets arbejde. GNU-programmørerne fik derfor et ikke helt ufortjent ry for at være utilnærmelige og arrogante. I lang tid eksisterede der parallelle versioner af flere GNU-værktøjer, indtil der efterhånden blev opnået en forsoning mellem lejrene. Linux-projektets tekniske succes var ubestridelig, og GNU-projektets monolitiske karakter og intellektuelle arrogance måtte efterhånden blødes op. Under Stallmans ledelse var man kommet langt med en udviklingsmodel, der var baseret på nogle få, højtuddannede og meget hårdtarbejdende individers indsats, men denne model havde også sine begrænsninger.

Linux' succes og Hurd-kernens fiasko havde vist, at det ikke var muligt at designe al software i en komité af akademiske eksperter uden sammenhæng med den virkelige verden og dens pragmatiske krav. For at udvirke en forsoning kontaktede Stallman Ian Murdoch, der havde grundlagt Debian-systemet, der var en af de første såkaldte “distributioner” af GNU-værktøjerne med Linux-kernen. Debian er stadig et af de vigtigste Linux-projekter og var også en af de første 100% brugerstyrede og ikke-kommercielle udgaver af Linux (andre tidlige eksempler var community-drevne Linux-projekter er det endnu levende Slackware og det nu hedengangne SLS) . Som Debian-projektets leder spillede Murdoch en vigtig rolle i udbredelsen af Linux til folk, der var positivt indstillet over for tankerne bag fri software.

Stallman gik til Murdoch med et forslag til en enkel og letforståelig ændring: Det nye og efterhånden meget populære styresystem, der gik under navnet “Linux”, var opstået ved at kombinere Linus Torvalds kerne med GNU-projektets værktøjer. Var det så ikke rimeligt at kalde det samlede system for GNU/Linux (udtales “GNU plus Linux”) frem for bare Linux? Stallman bad med andre ord om, at Debian-projektet skiftede navn fra “Debian Linux” til “Debian GNU/Linux”, så GNU-projektets navn også blev nævnt. Dette ville både betyde, at GNU-projektet faktisk blev krediteret for den helt centrale rolle, det spillede i opbygningen af det samlede system, og at brugere af Debian blev konfronteret med navnet GNU og fik mulighed for at spørge til, hvad det betød. Ian Murdoch syntes godt om forslaget, som han opfattede som et forsøg på at forsone de stridende parter i det “tekniske” Linux-projekt og det “politiske” GNU. Debian-systemets officielle navn er den dag i dag “Debian GNU/Linux”. Dette omfattede dog kun Debian — andre distributioner blev ved med at omtale systemet som “Linux”. Den notorisk trættekære Richard Stallmans insisteren på at kalde det samlede system for “GNU/Linux” fremkaldte også hovedrysten hos nogle, der så det som en trættende og næsten barnlig insisteren på at få så meget af æren som muligt.

Spørgsmålet om, hvorvidt det samlede system, som man kan bygge af Linux-kernen og GNU-værktøjerne, skal hedde Linux eller GNU/Linux, er stadig ikke afgjort. Tilhængere af systemet som en billig og teknisk solid løsning vil som regel foretrække at kalde det “Linux” for at undgå at henlede opmærksomheden på de (måske lidt pinlige) bagvedliggende politiske ideer. Tilhængere af ideen bag fri software vil ofte kalde det “GNU/Linux” for at gøre opmærksom på, at valget af fri software i sidste ende er et politisk valg, der vedrører brugerens frihed til at påvirke og ændre den teknologi, der definerer hans eller hendes dagligdag.

Denne strid brød for alvor ud i slutningen af 1990erne, da open source-bevægelsen blev grundlagt. Anledningen var en voksende frustration med mulighederne for at realisere de i stifternes øjne enestående muligheder i tankerne bag fri software. Der var også en erkendelse af, at man med Linux-kernens enestående succes stod over for et helt nyt fænomen. Udvikling af store systemer var hidtil blevet opfattet som noget, der nødvendigvis måtte foretages af højtuddannede, vellønnede professionelle. For at skabe et nyt system måtte disse højtuddannede medarbejdere først gennem en lang og kostbar analyse- og designproces, hvorefter de kunne programmere et system, der skulle igennem en lige så lang test- og indkøringsfase, før det kunne bruges til noget.

Linus Torvalds havde sprunget alle disse led over og satte sig i stedet bare ned og skrev programmet. Han og hans ulønnede entusiaster skabte derefter på næsten ingen tid en kerne til et solidt og professionelt styresystem, der meget hurtigt skabte grobund for IT-forretninger i millionklassen. Programmøren Eric S. Raymond skrev i 1997 sit indflydelsesrige essay “The Cathedral and the Bazaar”, hvor han brugte titlens metafor til at forklare forskellen på de to udviklingsmodeller.

I et traditionelt softwareprojekter foregår udviklingen som i en katedral. Udviklerne holder sig ligesom præsterne i denne metafor afsondret fra menigheden og leverer først når alle forberedelser er overstået det endelige produkt til kirkegængerne i form af gudstjeneste eller softwarepakke.

Linux-systemet blev derimod til i fuldstændig åbenhed, så alle, der havde lyst, kunne gennemse koden og foreslå ændringer. Dette mindede ifølge Raymond om en østerlandsk basar, hvor små programstumper og bidrag til systemet går fra person til person, og hvor alle kunder (brugere og udviklere) har deres fulde frihed til at besøge alle butikker (alle delprogrammer og alle dele af koden), præcis som de vil. Med basar-metoden kunne man, som Linux-kernen beviste, skabe velafprøvede systemer i et tempo og af en kvalitet, som ingen havde drømt om før. Ifølge Raymond skyldtes dette, at den fri og gratis adgang til at afprøve systemet og undersøge dets kildekode medførte en grad af kvalitetskontrol og revision, som man slet ikke kendte i traditionelle katedral-projekter. Hvor katedral-modellen altid kommer ud med store, monolitiske systemer, der indeholder mange fejl, fordi udviklerne ikke kan tænke på eller afprøve alt, vokser basar-projekter op fra små minisystemer eller prototyper, som hele tiden bliver brugt og derfor hele tiden bliver rettet og forbedret, så den færdige udgave (ideelt set) hurtigt bliver stort set fejlfri. Som Raymond argumenterede, giver den åbne udviklingsmodel bedre resultater, fordi der potentielt er mange flere mennesker til at påpege de fejl, der uvægerligt vil opstå.

Raymond brugte konflikten mellem Linux-projektet og Free Software Foundations GNU-projekt som bevis for sin tese. GNU var udviklet efter den traditionelle udviklingsmodel med lønnede udviklere, der selv har ansvaret for at udvikle og frigive færdige systemer. Linux-kernen var fremstillet af ulønnede entusiaster, der primært gjorde det for at underholde sig i deres fritid. Hvor katedral-projektet GNU havde brugt adskillige år på ikke at få Hurd-kernen bare tilnærmelsesvis færdig, havde Linux-folket meget hurtigere skabt en fuldt færdig styresystemskerne. Dette var ikke bare en flot bedrift — før det rent faktisk skete, ville man have anset det for umuligt. Linux var ikke et legetøjssystem, det var kernen til et fuldt udviklet styresystem.

Det betød, at fri software ikke længere kun var et spørgsmål om frihed. Efter Linux var det også en helt ny udviklingsmodel, hvor åbenheden var den første betingelse. Ideen er at udvikle et system og lægge det ud, hvor alle kan se det. Ikke bare alle i hele firmaet – alle i hele verden kan se det, hvis de vil – og bruge det og og ændre i det. Hvis folk begynder at sende deres ændringer tilbage, er praksis i den metode, som Linus indførte, at bruge dem og glæder sig over den forbedring, de bidrager med. Hvis mange mennesker bruger systemet og interesserer sig for dets kode, vil de meste alvorlige fejl hurtigt forsvinde, eftersom der er mange mennesker til at falde over fejlene og rette dem.

“Given enough eyeballs, all bugs are shallow”, som Raymond udtrykte det. Det centrale ved denne udviklingsmodel er åbenheden. Koden er frit tilgængelig, udviklingen diskuteres på en offentligt tilgængelig nyhedsgruppe eller mailing-liste, og alle har mulighed for at bidrage, hvis de har lyst.

Konsekvenserne af denne opfindelse skal vi høre mere om i næste kapitel.

I denne uges uddrag fra min kommende bog om fri software skal vi høre om, hvordan det er muligt at sikre, at et program, der udgives som fri software, også forbliver frit, så det altid er muligt at bruge, undersøge, forbedre og videregive det.

Løsningen på dette ligger i ophavsretten og den underlige konstruktion, der kaldes “copyleft” – at en forfatter kan give afkald på sin eneret til at udgive et værk på betingelse af, at andre altid giver det videre på samme betingelser som de fik det.

GPL og fri software – licens til at dele

Richard Stallman modtog i 1990 MacArthur-fondens “Genius Award” som anerkendelse af GNU-projektets store tekniske betydning. Og dog var Free Software Foundations og GNU-projektets største nyskabelse måske ikke af teknisk, men af juridisk karakter.

Et tilbagevendende problem med den uhæmmede videregivelse og deling af programmer i 70ernes hackerkultur var, hvad der ville ske, hvis et program, som en håbefuld programmør havde sendt ud i verden med den klausul, at alle måtte tage det og bygge videre på det og gøre med det, hvad de ville, faldt i hænderne på en person, der ikke var interesseret i at dele sit arbejde med andre. I værste fald kan et firma som Microsoft eller IBM tage et stykke fri software og bygge videre på det og lave et “plus-produkt”, som koster penge og ender med at udkonkurrere den frie udgave, fordi det er meget smartere. Nogle programmører af fri software interesserer sig kun for det tekniske og har ikke noget imod, at firmaer bygger deres programmer ind i kommercielle produkter. Men GNU-projektet har jo netop til formål at skabe et helt frit system, der kan bruges af alle. Hvis Microsoft eller en anden softwaregigant skaber et smart men lukket GNU+, som alle mennesker bruger i stedet, vil det være et nederlag.

Da Stallman i midten af 1970erne skabte de første udgaver af sit berømte tekstredigeringsprogram Emacs, var han allerede begyndt at formalisere hacker-etikkens fordring om kollektivt ejerskab af koden ved at bede folk om at bidrage til fællesskabet. Med Emacs fulgte “the Emacs License”, der stipulerede, at alle udvidelser skulle udleveres til Stallman. Han kom dog senere til den erkendelse, at dette krav var for vidtgående. Mange mennesker lavede mindre udvidelser, som de selv brugte i det daglige, men som ikke kunne betragtes som færdige. Det var små ting, som folk lavede til sig selv uden tanke om at udgive det, og egentlig ville det være en krænkelse af deres privatliv at kræve det udleveret. Problemet var der dog stadig: Folk kunne tage et GNU-program og udgive deres egen version i en rent binær form, så brugeren ikke havde adgang til kildekoden. Brugerne ville altid kunne skaffe den oprindelige version af et GNU-program ved at henvende sig til Free Software Foundation, men det hjalp ikke meget, hvis de ikke vidste det, eller hvis det var en “udvidet” udgave af programmet, de havde fået.

Stallman udformede derfor en simpel licenstekst, der tog udgangspunkt i programmørens ophavsret over programmet. Denne licens sagde, at brugeren af programmet havde ret til at bruge det og ret til at modtage kildeteksten og undersøge det, forbedre det og udgive egne versioner af det – de fire friheder – men ændrede versioner af programmet skulle altid udgives under de samme licensbetingelser. Licensteksten skulle udleveres sammen med programmet, så brugeren blev oplyst om sine rettigheder. Hvis dette kunne formuleres, så det var juridisk holdbart, ville problemet være løst. Almindelige brugere blev ikke pålagt at udlevere deres egne ændringer, så længe de ikke havde til hensigt at udgive eller sælge dem, men bordet fangede, lige så snart noget blev udgivet, fangede bordet. Kommercielle virksomheder ville derfor være tvunget til at udgive deres egne versioner af GNU-projektets programmer som fri software og oplyse deres kunder om de rettigheder, som licensen gav dem.

Stallman henvendte sig til en advokat, som han fik til at udarbejde en licenstekst, der på juridisk skudsikker vis ville gøre et program til fri software for alle brugere af programmet og samtidig ville forbyde, at ændrede versioner kunne udgives under andre vilkår. Resultatet blev første version af GNU GPL eller GNU General Public License, der i sine forskellige varianter er den vigtigste frie softwarelicens i dag.

Helt grundlæggende formaliserer GPL det enkle princip, at alle ændrede og forbedrede versioner af et program skal videregives på samme betingelser, som man modtog dem. Da virksomheder og andre aktører kunne tænkes at undergrave licensens ånd ved at pålægge deres egne versioner særlige juridiske eller tekniske begrænsninger og på den måde sno sig uden om pligten til at stille deres egne ændringer til rådighed, indeholder licensteksten også en lang række tekniske og juridiske betingelser, der skal forhindre den slags manipulation. I den første version af GPL var der ikke taget højde for, at et firma kan udvide et program ved hjælp af en teknologi, der er omfattet af et patent og herefter forbyde andre at videregive programmet, eftersom de ikke har ret til at bruge den patenterede teknologi. For at imødegå dette medtog man i anden udgave af licensen den såkaldte “Liberty or Death”-klausul. Denne klausul forbyder modtageren af et program at udgive en ændret version af programmet under GPL uden samtidig at give alle modtagere af programmet fuld tilladelse til at anvende eventuelle patenter uden yderligere vederlag.

Et andet eksempel er på en teknisk undvigelse af GPL er “tivoisering”, baseret på en metode, der blev indført af Tivo, som producerer de avancerede harddisk-optagere af samme navn. En Tivo er udstyret med en udgave af styresystemet GNU/Linux, som er specielt tilpasset denne harddisk-optager og blandt andet implementerer en lang række restriktioner, der bl.a. kan begrænse, hvilke TV-programmer, ejeren af apparater kan optage. GNU/Linux-systemet og de tilhørende værktøjer er omfattet af GPL. Tivo opfyldte også formelt GPLs krav ved at lægge kildekoden til deres ændrede version til download på nettet. En Tivo er imidlertid udstyret med firmware, der nægter at køre en udgave af systemet, som ikke er signeret med en særlig krypteringsnøgle, som Tivo ikke valgte at lægge ud sammen med ændringerne i kildekoden. Resultatet var, at Tivos brugere nok kunne downloade, undersøge og ændre kildekoden til GNU/Linux-systemet på deres Tivo-maskiner, men deres egne udgaver ville ikke kunne køre på en Tivo, eftersom brugeren ikke havde adgang til krypteringsnøglen. GNU/Linux-systemet på en Tivo-maskine er derfor i praksis ikke fri software. Systemet er tilpasset med nogle ændringer, der kun giver mening på en Tivo – men netop en Tivo kan brugerne ikke få lov til at køre deres egne ændringer på.

For at undgå dette smuthul er version 3 af GPL udstyret med den klausul, at hvis et program under GPL ændres for at tilpasse det noget bestemt hardware, og hvis denne hardware kræver, at det udførbare program signeres med en særlig krypteringsnøgle for at kunne afvikles, så skal denne krypteringsnøgle stilles til rådighed sammen med kildekoden. Version 3 af GPL lukker en række andre huller og indeholder derfor en hel del kompliceret juridisk sprog, men som udgangspunkt er betingelserne helt enkle. Du har ret til at bruge, undersøge, ændre og videregive et program under GPL. Du har derfor også ret til at få udleveret kildekoden til det, på den ene eller den anden måde – om du så kan downloade den fra nettet eller (som det var almindeligt i gamle dage) må skrive til en bestemt adresse for at få den tilsendt med posten.

Fortalen til GPL er et kapitel for sig og minder mere om et politisk manifest end om en slutbrugeraftale:

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program—to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

Selv om det måske er en underlig ting at sige om en softwarelicens, kan der ikke være nogen tvivl om, at det er historiens vingesus, vi hører, når vi læser denne tekst. Fri software er i dag, omend i nogen grad “bag facaden”, endog meget udbredt og faktisk ganske uundværligt for at få vores samfund og infrastruktur til at hænge sammen. Selv proprietære systemer som Microsofts Windows og Apples MacOS ville næppe være til at kende, hvis man tog al den frie software ud af dem. Og hvis der er noget, der har spillet en vigtig rolle i udbredelsen og ikke mindst beskyttelsen af fri software, er det GNU-projektets General Public License. GPL er blevet den gyldne standard for, hvordan programmer kan udgives som fri software på en måde, der sikrer at de også forbliver fri software.

Den grundlæggende idé i GPL kan siges at være “Den Gyldne Regel: “Gør mod andre, som du ønsker, de skal gøre mod dig”. Ophavsretslige bestemmelser med denne type betingelse kaldes med et ordspil på det engelske ord for ophavsret for copyleft. Det grundlæggende element i en copyleft-licens er, at det er tilladt at videregive og ændre det beskyttede materiale – men at det samlede værk skal videregives på de samme betingelser, som man modtod det. Det vil sige, at du skal tilbyde modtageren til hele det program, som du leverer til dem, inklusive alle dine egne ændringer eller tilføjelser.

GPLs regel om, at afledede værker skal udgives under samme betingelser som værket selv har ført til beskyldninger om, at GPL er en “virus”, som inficerer alle de programmer, der bruger den. Og det er da også sandt, at hvis man bygger et program under GPL sammen med et andet program, bliver det samlede program nødt til at være, om ikke under GPL, så under betingelser, der kan sameksistere med GPL – er “GPL-kompatible”, som man plejer at udtrykke det rent teknisk-juridisk.

Et eksempel på en mindre restriktiv er BSD-licensen, der bl.a. anvendes af styresystemet FreeBSD. FreeBSD er en direkte efterkommer af Berkeley Unix (BSD står for Berkeley Software Distribution, efter Berkeley-universitetet i San Fransisco). BSD-licensen er langt mindre restriktiv end GPL med hensyn til, hvad man må gøre med programmet.

Dybest set kan BSD-licensen, som forklaret på FreeBSDs hjemmeside www.freebsd.org, koges ned til to punkter:

• Please don't claim you wrote this.
• Please don't sue us if it breaks.

Hvis du ønsker at udgive et helt nyt system baseret på FreeBSD, er du altså forpligtet til, for eksempel ved at medtage en fil med licensteksten i installationsprogrammet eller ved at skrive det i et menupunkt, at fortælle, hvem der oprindelig har skrevet programmet. Du må også være klar over, at programmets oprindelige forfattere ikke påtager sig noget ansvar overhovedet for, hvordan det virker. Til gengæld er det muligt og tilladt at tage FreeBSD og lave dit eget private styresystem og sælge det, uden at du dermed er forpligtet til at give aftageren adgang til kildekoden. Du kan helt frit gøre det, som Stallman frygtede og for alt i verden ville undgå: Du kan tage et frit program og gøre det ufrit, proprietært. Faktisk er ét sådant system blevet meget populært, nemlig Apples styresystem MacOS, som oprindelig bygger på FreeBSD og har overtaget mange af Unix-systemets tekniske fordele. Den frihed, som Apple benyttede sig af, da de byggede deres indbydende og teknisk velfungerende system, har de dog ikke valgt at give videre til deres egne brugere.

Hvis man ønsker at tage to omtrent lige store programmer og bygge sammen til ét, så er det faktisk muligt, hvis det ene stykke kode er under en BSD-licens og det andet under GPL. Blot vil der gælde, at man skal kunne identificere de enkelte deles “oprindelse”, således at de dele af programmet, der oprindelig var under GPL, fortsat skal være under GPL, mens de dele, der oprindelig var under en BSD-licens, vil kunne ændres og videregives i overensstemmelse med BSD-licensen. Der er nemlig intet i BSD-licensens betingelser, der forhindrer folk i at lægge begrænsninger på den del af koden, der er omfattet af GPL, og der er intet i GPL, der forhindrer, at man distribuerer de dele af programmet, der er omfattet af BSD-licensen. Vi siger, at de to licenser er kompatible. Hvis to licenser for fri software ikke er kompatible, kan programmer omfattet af dem ikke lovligt kombineres til et nyt program.

Hvis du kombinerer et program udgivet under GPL med et andet program, kan licenserne kun være kompatible, hvis brugeren har adgang til kildekoden og til at udgive ændrede versioner af det samlede program. Hvis du kombinerer et program under GPL med et andet, vil begge programmer automatisk blive omfattet af de rettigheder til at ændre, undersøge og videregive programmet, som GPL giver brugerne. Bemærk, at betingelserne i GPL ikke medfører, at du er nødt til at udlevere programmet eller kildekoden til alle og enhver. Det er blevet almindelig praksis at lægge fri software på en offentligt tilgængelig side, f.eks. på Github, til ubegrænset download, men det er ikke obligatorisk. De fleste fri software-projekter ser det som en del af deres formål at stille deres arbejde til rådighed for offentligheden, men der er ikke nogen forpligtelse til at offentliggøre kildekoden. Licensbetingelserne sikrer, at enhver bruger af programmet har ret til at modtage kildekoden, men for at gøre krav på denne ret, må brugeren påberåbe sig det eksemplar af GPL, der fulgte med programmet. Det betyder, at de forpligtelser, der er indeholdt i GPL, kun omfatterne modtageren af et program – personer, der ikke allerede har modtaget det, har ikke krav på at få kildekoden udleveret.

Hvad sker der, hvis en virksomhed bliver en dag beslutter sig for at bygge et stykke software, der er omfattet af GPL, ind i sit eget system men “glemmer” at fortælle nogen om det? Rent juridisk er at computerprogrammers kildekode beskyttet af ophavsretten. Som modtager af et program har du ikke en ret til at udgive eller på anden måde videregive programmet, som du ikke eksplicit har fået af opretshaveren, det vil sige den oprindelige programmør eller dennes arbejdsgiver. GPL giver en sådan tilladelse, men kun på nogle nøje definerede betingelser, hvoraf den vigtigste er, at du skal oplyse brugerne om deres egne rettigheder under GPL, herunder til at få kildekoden udleveret.

Hvis du ikke vil acceptere disse betingelser, er der slet ikke nogen tilladelse til at videregive programmet, og den oprindelige programmør kan indbringe sagen for retten og kræve erstatning for krænkelse af sin ophavsret. Det særlige forhold, at proprietære systemer oftest distribueres uden kildekode, samtidig med at kildekoden til fri software under GPL næsten altid er gratis tilgængelig på nettet, har undertiden fristet enkelte firmaer, så de har valgt at “låne” programmer under GPL og bygge dem ind i deres egne systemer uden at gøre opmærksom på det. Det gælder ikke mindst producenter af routere og anden netværks-hardware, hvor de mest udbredte værktøjer til opsætning og kontrol er fri software, der er udgivet under GPL.

I USA er der siden 2007 rejst adskillige sager om mod en række store router-producenter(bl.a. Cisco og D-Link) om uberettiget anvendelse af sådanne værktøjerg anden hardware, men i de fleste tilfælde er sagerne endt med forlig, fordi GPL rent juridisk er så klart formuleret — producenternes advokater har ganske enkelt rådet dem til ikke at gå i retten med det.

En af de tidligste sager, som faktisk endte i retten, kan illustrere dette. Den tyske Linux-udvikler Harald Welte anlade sag ved retten i Frankfurt am Main, fordi producenten D-Link solgte en netværks-harddisk (en “Wireless G Network Media Storage DSM-G6000”) hvor der medfulgte en række værktøjer under GPL — herunder tre programmer, som Welte havde fået overdraget rettighederne til af deres oprindelige forfattere.

D-Link gjorde i deres forsvar blandt andet gældende, at den GPL-licens, der fulgte med de tre programmer, ikke udgjorde en forpligtende kontrakt mellem D-Link og softwarens producenter, og at GPL som kontrakt/licens slet ikke var gyldig, fordi den måtte opfattes som konkurrenceforvridende efter tysk lov. Derfor, mente de, var de ikke forpligtede til at overholde betingelserne i GPL.

Retten fandt til det første punkt, at licensen efter rettens mening godt kunne opfattes som en juridisk bindende kontrakt mellem D-Link og forfatterne af de tre programmer — men at det i modsat fald ikke ville have været til D-Links fordel, fordi der så slet ikke ville have været noget, der berettigede dem til at medtage de tre programmer i deres produkt.

Denne del af dommen lyder helt præcist:

In addition, if the GPL were not sufficient to form a legal relationship with Plaintiff, Defendant would not have any right to copy, distribute or modify the three programs, such that a copyright infringement by the Defendant would have taken place. In particular, the conditions of the GPL can in no case be interpreted to contain a waiver of legal positions afforded by copyright law. The GPL precisely stipulates that the freedom to use, modify and distribute the corresponding software initially afforded by way of a grant of a non-exclusive license to everyone is automatically terminated upon a violation of the GPL.

Til argumentet om at GPL ikke er gyldig som licens, fordi den kan virke konkurrenceforvridende, svarer retten i sin afgørelse, at det behøver den slet ikke at tage stilling til:

It need not be decided whether, as Defendant argues, the provisions of the GPL violate Article 81 EC and Section 1 of the German Antitrust Act (GWB), in particular the prohibition against price fixing and of predetermining the conditions of secondary contracts in the first contract. This would, according to Section 139 of the German Civil Code (BGB), result in the invalidity of the entire license agreement with the consequence that Defendant would not have a right of use in the software at all, so that Plaintiff could file a copyright infringement claim for that reason. If an agreement is partly invalid, the entire transaction is invalid pursuant to Section 139 of the German Civil Code (BGB), unless it can be assumed that the parties would carry out the transaction without the invalid part. This is not the case here. Since the parties agreed on the grant of the license being subject to the condition subsequent of compliance with the GPL, the possibly invalid part [of the GPL] (Sec. 2 of the GPL) is inseparably connected to the primary obligation, i.e. the grant of the license.

Kilde

GPLs styrke er blandt andet, at den aldrig forbyder nogen at bruge de programmer, den omfatter. Det er først i det øjeblik, at brugeren selv videregiver programmet til andre, at GPLs licensbeskyttelse sætter ind. Ifølge lov om ophavsret har man ingen som helst ret til at distribuere et værk uden udtrykkelig tilladelse fra ophavsmanden. Den juridiske beskyttelse af et værk er altså meget stærk i alle lande med en retslig beskyttelse af ophavsretten. D-Links forsvar, at GPLs licensbetingelser var urimelige og kunne skade dem over for deres konkurrenter, gav dem ikke ret til at bryde betingelserne — det betød bare, at der ikke var noget, der gav dem ret til at bruge programmerne som en del af deres eget produkt.

GPL, hvis bestemmelser D-Link ikke ville acceptere, var det eneste, der i den situation kunne have givet dem ret til det. Dommeren afgjorde derfor, at firmaet skulle betale klagerne 2.080,50 euro i erstatning samt retsomkostninger og timeløn for den tid, Harald Welte brugte på at bevise, at D-Link faktisk havde overtrådt licensen.

Og det er netop, fordi betingelserne i en licens som GPL er så klare og udnytter principperne i ophavsretten, at den så effektivt kan sikre, at de programmer, den omfatter, både er og faktisk forbliver fri software, som alle har ret til at bruge, undersøge, forbedre og videregive.

WriteFreely, som er det værktøj, som denne side er bygget i, giver mulighed for at have mange forskellige blogs for hver bruger.

Hidtil har jeg skrevet i den blog, der hedder agger, men nu har jeg også oprettet denne, hvor jeg kan skrive forskellige små indlæg og artikler, noter, som man siger.

Det har noget at gøre med, at jeg er ved at være træt af de sociale medier men stadig har ting, som jeg gerne vil skrive og have folk til at læse. Hæng endelig på.

So I'm reading Gary Greenberg's book “Manufacturing depression”. It's not an ironclad scientific demonstration of the ineffectiveness of much of the modern psychiatric medicine such as you may find in the work of (say) Joanna Moncrieff, but it is an entertaining and critical journalistic narrative of the pharmacological history of depression.

At one point he's comparing depression and SSRIs with diabetes and insulin, mocking the psychiatrists who, unlike real doctors prescribing insulin to diabetics

don't have to convince their diabetic patients that they have a “real illness”. A diabetes doctor doesn't have to worry about the clinical appropriateness of treatment. He doesn't have to wait for a new definition of diabetes to be hashed out in committees of his brethren and then learn the new diagnostic criteria. (...) All he has to do is to take a urine or blood sample. He doesn't have to talk about chemical imbalances that he knows aren't the problem or contend with package inserts that say, in plain black and white, that the drug makers have no idea why their drug works.

The prevailing narrative is still, if you ask doctors, that depression is caused by low levels of serotonin in the brain and that antidepressants work by increasing the levels of serotonin. It's hard to understand, though, how this narrative can still exist given that Irving Kirsch (lecturer in medicine at the Harvard Medical School and Beth Israel Deaconess Medical Center) thoroughly debunked the idea in 2009, 15 years ago.

What Kirsch demonstrated by a thorough analysis of a vast number of clinical trials of SSRIs was

• Antidepressants fare very badly in clinical trials. They are statistically better than placebos, but the difference is so small that it's not clinically significant. I.e., clinically they're not proven to be any better than placebos.
• They are speculated to work by lowering serotonin levels, but in fact there is no evidence at all that depression is related to serotonin levels – the evidence that is often cited is that the SSRIs seem to work on depression, but the clinical trials suggest they actually don't.
• It has been shown that if people have the levels of serotonin in the brain depleted, it doesn't affect their mood at all.
• One outlying anti-depressant in use in France is actually a Selective Serotonin Reuptake Enhancer, i.e. it lowers levels of serotonin in the brain, and it fares no better and no worse than the SSRIs.
• the small statistical difference between SSRIs and placebo can probably be explained by the placebo effect – patients in clinical trials realize that they're on the real drug because of the onset of (often unpleasant) side effects, thus increasing their expectation of a positive effect.

I won't claim to know how to cure depression, except that I'd guess that it's not a disease whose root causes lie at the neurochemical level and hence it probably isn't curable with medication (even though such medication may be helpful in shorter periods). I'd really love for someone to come up with a real answer.

But why do we allow ourselves and the industry to carry on, 35 years after introducing these drugs, 15 years after Kirsch thoroughly debunked them, to continue treating this very serious disease with medicine

• whose own manufacturers still can't say why it would work
• except by referring to a serotonin hypothesis which has never been proven,
• a hypothesis which has in fact been debunked?

I'm afraid we're in need of some reforms here. Maybe, just maybe, the abolishment of medical patents and of any and a nationalisation of medical research, so that new drugs and treatments will be developed according to patients' needs – and not according to the drug companies' chances of commercial success.