Du var aktiv inom C-64 demoscenen (Confusing Solution, Super Swap Sweden, Horizon) i slutet på 80-talet. Kan du brätta lite om detta och din övriga bakgrund innan du blev involverad i öppen källkod?

Jag upptäckte tjusningen med datorer nån gång i början av 80-talet. Jag och en klasskompis (Kjell) skrev in data-satser i BASIC från några av de första C64-tidningarna hemma hos honom och jag var såld. När jag och brorsan Björn jobbade extra på loven samlade vi ihop till vår första dator som vi köpte när jag var 14 år.

Jag gick direkt in för att programmera och lärde mig snabbt BASIC och hur man kunde göra enkla grejor. Vädligt snart insåg man att de coola grejorna man kunde se andra göra och alla spelen och så inte var gjorda med BASIC. Vad använde de? Assembler.

Så vi tre (jag, Kjell och Björn) dök helhjärtat in i 6502-assemblerns underbara värld och vi började hacka demos för vi gillade såna och vi vill också göra demos. Vi insåg att alla fanns i demo-grupper och hade nick-names och så, och vi var inte sämre utan blev snabbt ”Confusing Solution” (vi kunde vara självironiska redan då).

Av en ganska lycklig slump organiserade Triad och Fairlight (två av den tidens giganter på ”demo-scenen”) ett ”copy-party” i vår högstadieskola i Huddinge senvintern 1986 och vi sögs än djupare in i andan och gemenskapen. Där träffade vi likasinnade, släppte vårt första demo någonsin och senare under våren 87 blev vi rekryterade av Fonzi till Super Swap Sweden som då var en stor och känd grupp som gjorde både ”cracks” och några demos. Vi släppte fler demos under SSS-flaggan och blev bättre och lärde oss mer om C64:ans alla odokumenterade hörn, opkoder och kretsar.

En del av oss hoppade av SSS efter ett tag och skapade istället Horizon tillsammans med ett gäng andra demo-hackers och nu var vi ledande. Vi vann en hel rad av demo-tävlingar i Sverige och Danmark under flera år. Vi organiserade också några av de största nerd-träffarna i norden under den perioden.

C64:an gyllene tid dalade bort sakta men säkert för oss, och flera av oss kikade på att göra hoppet till Amigan och fortsätta likadant där – det var ju vanligt på den tiden – men Amigans helt ”obegränsade” förutsättningar med ohemult mycket ram, supersnabb CPU, blitter och musikkrets tog på något vis bort mycket av vad vi ansåg vad charmen med demo-hacking. Vi släppte bara ett enda demo på Amigan.

Istället drog jag och Kjell runt 1991 igång projektet FrexxEd – en text editor för Amiga. Samma år – 20 år gammal – debuterade jag på riktigt i IT-branchen genom att börja på IBM och jag jobbade där med RS/6000 och dess OS som hette och fortfarande idag heter AIX. Min först introduktion till unix och C. Wow. Jag var såld. ”Unix är framtiden!” sade jag till min tjej då (hon skulle senare bli fru Stenberg och är det fortfarande), som förstås inte hade en aning om vad jag pratade om… Jag lärde mig allt jag kunde främst genom man-sidor.

På IBM lärde jag mig att det fanns massor med gratis källkod till program att tillgå. Att det finns en ascool editor som heter Emacs som man kan göra allt med. Mycket av inspirationen och idéer till FrexxEd som vi alltså jobbade på vid den tiden fick jag genom mina upptäckter och lektioner med Emacs på jobbet. Emacs på amigan fanns visserligen men den kom inte till rättvisa där och vi såg att vi kunde göra bättre i den (begränsade) miljön.

I princip det enda som vi gjorde på Amigan var att hacka FrexxEd – och jag skrev även ett separat script-språk för editorn – Frexx Programming Language (FPL) – som jag skrev portabelt att byggas och köras på divers unixar likväl som Amiga etc. Under tiden hackade Björn ihop ett BBS-system under OS/2 som i princip skrevs helt och håller i FPL.

1993 började jag jobba som C-utvecklare på riktigt (på Frontec Railway Systems) och skrev inbyggda system som mätte temperaturer på tågaxlar som passerade mätstationer – och jag kom i kontakt och fick hacka på både SunOS och DELL Unix på jobbet. Jag upptäckte IRC och att det fanns massor med folk därute att snacka med. Jag hängde en hel del på #amiga på efnet, innan ircnet fanns. Det ledde snart till att jag på fritiden skrev på en IRC-bot tillsammans med en kompis från #amiga – en bot som kunde scriptas med FPL… Vi släppte botten (Dancer) och FPL helt open source. Det var liksom inte mycket att fundera på. Om vi kunde stå på jättars axlar och använda så mycket bra programvara så var det minsta vi kunde göra att likaså dela med oss.

Nu var Amigan ute ur mitt liv, nu använde jag jobbets modem-pool med dial-back till att logga in på jobbets olika unix-maskiner och IRC:a och hacka bots. Jag hängde väl en del i #amiga och #amigaswe fortfarande då massor av folk där var mina vänner.

En dag slog det mig att det ju vore cool att ha en tjänst till botten där man kunde be den växla valutor. Många gånger diskuterades priser, så varför inte kunna erbjuda att botten kan säga vad 100 SEK blir i dollar just idag etc? OK, då behövs ett kommandorads-verktyg som kan ladda ner kurser från en webb-sida.

Jag hittade ett litet verktyg som hette ‘httpget’ och var skrivet av en Brasilianare. Det passade nästan perfekt. Det behövdes bara lite små fixar och patchar. Jag donade till…

Snart hade jag väl mer eller mindre tagit över ledartröjan i projektet när jag hittade en valuta-sajt som fanns på GOPHER så jag fick implementera support för det också. Och då var ju ‘httpget’ inget bra namn längre så det fick bli ‘urlget’. Snart hade även FTP-support lagts in och när väl FTP var stött var steget till att få till upload väldigt litet.

När verktyget även kunde göra upload hade ju namnet blivit fel igen så det blev till att byta igen. curl var fött. curl som i ”see URL” eller ”client for URLs”. I mars 1998 kom första releasen av curl.

På namnet låter det som Frexx är kanske är besläktat med REXX (och således ARexx) – stämmer det eller är det bara ett ovanligt sammanträffande?

Det var faktiskt inte avsiktligt, utan blev mest en lite jobbig koppling. ARexx användes ju flitigt på Amigan som script-språk i applikationer, medan vi ju använde FPL. Kanske var det inte det smartaste namnet, men vi gillade det! ==)

Just ”Frexx” kom till mest som ett skoj-ord. Mer som ”fräckt” skrivet på ett annorlunda sätt – med ”Ed” ditlagt i slutet i samma stil som flera andra text- editorer gjorde på Amigan på den tiden. Just två x i slutet av ordet är något som vi tyckt om länge, vilket ju också senare resulterade i att vårt företagsnamn fick två x i slutet.

Öppen Källkod verkar ju funka för jag hittade repon med både FrexxEd och FPL på github och de har hackats på detta år verkar det som.

Verkligen. Just FrexxEd var dock shareware väldigt länge. Vi kom ju från C64:an och Amigan där FOSS var ett obekant begrepp och det fanns liksom inte alls inom kulturen – synd nog. Men till slut lärde vi oss den rätta läran och släppte det helt öppet och i modern tid har folk som idag kör något av de nya Amigaos-versionerna fått upp intresset för FrexxEd och de har portat det. Det är förstås kul att det fortfarande lever – över 20 år gammal kod.

Det är väl framförallt cURL projektet du är mest associerad med men även Rockbox, libssh2, c-ares är du väl rätt aktiv i? historiskt, vilka andra projekt har du involverat dig i?

curl är det som ligger mig närmst och hjärtat och det projekt där jag fortfarande spenderar mest tid på. Sedan kommer nog libssh2 och c-ares.

Jag började som sagt med Dancer, en IRCbot, och jag spenderade en hel del tid i hypermail – ett program för att konverta mailboxar till HTML-sidor. Jag har skrivit ‘mail2sms’ för att konvertera mail till SMS, och varit med i Smash för att skicka SMS till operatörers modem-mottagare. Jag är med i Trio – ett *printf och sträng-hanteringslib. Jag har bidragit med kod till och jag är med och ”tycker” i wget. Jag var tidigt med och var committer i Subversion-projektet. Jag skriver och underhåller ‘roffit’ – ett verktyg för att skapa HTML-sidor från nroff-filer. Jag var med och startade Rockbox och jag har bidragit med tusentals commits där, även om jag numera inte bidrar så väldigt aktivt där längre. Jag kommenterar lite på git-listan och hjälper dem använda libcurl så bra som möjligt… det finns en binge till, och några har jag säkert glömt bort.

Ohloh.net räknar över 20000 publika commits jag gjort i opensource-projekt, och även om jag vet att det finns en del svenskar som har fler så tror jag inte det är många.

Det är inte direkt FOSS, men jag försöker aktivera mig och tycka och ha åsikter inom IETF och de arbetsgrupper som jobbar med protokoll och grejor som intresserar mig. Därför finns jag numera nämnd i två RFC:er och jag försöker ge mina bidrag inom HTTP, FTP och liknande.

Många RFC:er tar ju väldigt lång tid och det känns som en del byråkrati kring det vilket jag har svårt för; speciellt som FOSS utvecklare där jag är van att saker går rätt snabbt fram. Är det samma för dig eller är det ibland långsamma tempot positivt?

För mig är jobbet inom IETF mycket mer en fråga om teknik och interoperabilitet etc. Att vara med och se till att specar blir gjorda rätt, tar rätt saker i beaktande och inte går över gränsen till saker de inte borde. Det främjar alla.

Som exempel kan nämnas jobbet som nyligen gjordes inom IETF för att speca hur cookies används i HTTP. Cookies har funnits i kanske 15 år och den enda spec som egentligen använts är på hundra rader och är totalt oanvändbar. Försök har gjorts genom åren att rätta till det men de misslyckades. Till slut startades en grupp som jobbade med att pränta ner hur cookies faktiskt fungerar idag. Jag kände att jag som implementatör av en cookie-”maskin” som funkat bra i många år kunde bidra med rätt bra feedback och en helt annan vinkel än de flesta andra som var med där – som merparten kom från webbläsarvärlden. Jag var glad att kunna ge min input för bidra till att RFC6265 blev så pass bra som den blev!

Du berättade att cURL växte fram ur httpget men innehåller den fortfarande någon kod därifrån eller gjordes cURL som en clean re-write?

Det var aldrig någon rewrite, utan bara en gradvis omskrivning. Mer och mer skrevs om och en dag fanns det helt enkelt inga spår kvar av det ursprungliga programmet kvar. httpget var ett mycket litet och enkelt program på bara några hundratals rader C. Rafael Sagula, han som skrvit httpget, var kvar i projektet i början och var helt med på vad som hände och hur jag förändrade det.

Jag är lite ledsen över att vi inte har en komplett versions-historik ända tillbaks till den första tiden. Vi bytte hosting och versionshantering flera gånger och i början var vi inte så nogräknade med historiken. Den äldsta koden vi har kvar i git är från slutet av 1999. Den äldsta tarbollen vi har är från början av 1998.

Din Ohloh.net kudos rank är #63 och nyligen har Google uppmärksammat ditt arbete med cURL. Jag antar att du tycker detta är roligt men sätter det inte lite extra press en att man ska hjälpa nykomlingar, skriva kod på ett visst sätt och allmänt vara ett bollplank?

(Daniel om Googles tack för cURL: http://daniel.haxx.se/blog/2011/12/06/a-special-thank-you-from-google/)

2009 fick jag också utmärkelsen Nordic Free Software Award tillsammans med Simon Josefsson. Sammantaget görs såna här saker förstås att jag känner mig uppskattad och att mina insatser syns i åtminstone en del sammanhang…

Jovisst. Jag känner absolut att jag har en extra skyldighet att göra rätt där jag är involverad även om jag också i ren foss-anda anser att alla som vill få saker gjorda någonstans i första hand ska se till att själva kliva fram och ta initiativet till en förändring. Men det är också det jag gör som gör att jag får uppskattning. Det blir en positiv spiral.

Oavsett ranking på en speciell sajt (vars ranking-system i övrigt är mycket märkligt och inte värt att lägga alltför mycket vikt vid) så känner jag att jag varit med länge, gjort mycket och har ett socialt nätverk som ger mig ett bra fundament för att stå upp för det som jag tycker är rätt, och för att streta emot där jag tycker fel begås.

Jag vill hjälpa till och förbättra världen där jag kan, och FOSS-världen är ett område där jag försöker.

Ditt företag Haxx sysslar en hel del med embedded där linux har blivit väldigt populärt. Hur har din erfarenheter från ”resurssnål” demo-programmering på C-64 hjälpt dig?

Det var verkligen min inkörsport till vad jag är och gör idag. Jag har aldrig riktigt lämnat ”metallen” sedan dess, utan har fortfarande kvar känslan av att det är nära hårdvaran och OS:t som allting är som bäst. C64:an gav mig insikten exakt hur CPU:er och assembler fungerar, sedan har det förstås utvecklats massor sedan dess men det var en kanongrund.

På Haxx är vi fyra styckan personer. All vi fyra var med i Horizon, demo-gruppen vi skapade 1988…

Haxx är lite av min dröm sedan hur länge som helst omvandlad till verklighet. Vi är ett litet antal nära vänner som alla är experter på inbyggda system och Linux. Vi jobbar som expert-konsulter för företag som bygger diverse inbyggda system, och ofta hjälper vi de som i sin tur är de som bygger grejorna till slutkunder.

Inbyggda system idag betyder i väldigt hög grad Linux och massor med open source. Faktum är väl egentligen att Linux och FOSS ökar överallt utom kanske på desktop.

Hur har din inblandning i olika FOSS projekt hjälpt till för att få uppdrag och hur brukar era kunder ställa sig till att dela med sig av det ni gör för dom om du t.ex. utökar en FOSS komponent?

Jag får en hel del förfrågningar runt uppdrag som kommer som en direkt effekt av att jag involverat mig i FOSS-projekt, ja. Det är en ganska bra form av marknadsföring för mig och mitt företag. Fast jag kan också fascineras över hur många av mina kunder som inte alls har koll på min ”FOSS-sida” eller inte bryr sig alls om den.

När det gäller direkta uppdrag att modifiera existerande projekt, som kanske att lägga till features eller förbättra någon del, så brukar det inte vara några problem. Uppdragsgivarna är då ofta redan från början införstådda att det är någon form av opensource-licens involverad. Det händer t.om ganska ofta att det är ett direkt krav i kontraktet att förändringar de betalar för SKALL gå in i mainline – vilket också säkert är varför de gärna köper tjänsten direkt av den som maintainar projektet för då är chanserna för det mycket bättre. Självklart finns det också fallen då kontrakt på beställningar mer eller mindre förutsätter att all kod man skriver på ett uppdrag ska förbli stängd och företagets hemliga egendom, men det brukar inte vara ett problem utan mer en effekt av hur mycket programutveckling har gjorts genom tiderna.

En lite lustig detalj i sammanhanget är dock att flera av mina kunder inte har velat skylta med sin egen närvaro i projekten utan har betalat för att få förändringar gjorda, men utan att copyright anges till företaget och utan att företaget nämns i några som helst publika sammanhang! För omvärlden förefaller det då bara som att jag fått extra inspiration och energi under en period… Personligen tycker jag det är att försitta en chans till god publicitet.

cURL har funnits sedan 1996 och växer ständigt. Hur kom det sig att du valde BSD licensen över t.ex. GPL och hur känns det att cURL används i välidigt mycket annat så som git?

Från början visste jag inte riktigt vilken licens jag skulle ha, utan använde faktiskt GPL utan att riktigt tänka efter. Med tiden kom jag att diskutera licenser med vänner och fundera över vad som är rätt och fel och vad jag egentligen ville med licensen till curl.

1998 när jag släppte curl 4.9 så bytte vi till MPL-licensen. Den är mycket liberalare och passade mycket mer med vad jag egentligen ville att folk skulle göra: bidra med förändringar om de faktiskt ändrar curl-koden men i övrigt kunde de göra vad de ville.

Det visade sig dock vara ett osmart val när jag väl lanserade libcurl – curl som ett library gjort för andra program att använda – eftersom MPL ansågs vara GPL-inkompatibelt så folk som använde GPL kunde inte enkelt använda libcurl. Så 2001 blev libcurl MIT-licensierat istället och jag har inte ångrat mig sedan dess.

Självklart inser jag att folk kan ta min kod, ändra i den och skeppa den med sina grejor och bli miljonärer utan att jag nånsin får tillbaks förändringarna eller så. Men i realiteten är det inte ett problem eftersom folk inte vill fastna i sina egna forks och genom att undvika copyleft-licens har jag tvärtom lyckats locka mängder med företag att använda min produkt. Företag som annars skulle skippat den och kanske använt något stängt istället.

curl-sajten listan 120-nånting företag som använder libcurl i kommersiella produkter. Sen tillkommer förstås några hundra foss-projekt såsom git som använder det.

Det känns helt enkelt otroligt bra. Det ger mig också en position av ansvar och noggrannhet, eftersom fel och misstag som slipper ut lätt kan drabba väldigt stora mängder användare – om jag har otur. Och det händer förstås ändå då och då…

Detta kan väl vara ett ibland halvsvårt övervägande – dels vill man kanske sälja konsultjobb eller support kring ens mjukvara men dels vill man att många ska använda den och förbättra den.

Ja absolut, det är helt fullt av paradoxer runt detta!

Jag skulle kanske allra helst få massor med betalda uppdrag att förbättra och utöka curl, men i verkligheten så är det redan ett väldigt komplett och stabilt projekt. De flesta som behöver något av det curl erbjuder hittar det redan utan att betala någon.

Varje utökning eller förändring som görs av mig i projektet på eget initiativ tar bort möjligheten för mig att göra samma sak åt någon för pengar, samtidigt som underhåll och ett levande projekt är det som gör att folk bibehåller förtroendet för projektet och min roll däri.

Ett mindre fungerande program skulle kunna leda till fler support- och buggfix- uppdrag == inkomst, men ett mindre fungerade program skulle vara mindre attraktivt i välja i första hand.

Just det faktum att curl har en väldigt liberal licens har gjort att företag väldigt sällan har några legala eller etiska problem med att använda det inom i princip vilka projekt som helst, vilket leder till att jag får rätt mycket frågor om support och en strid ström med patchar från folk på företag som använder curl.

Hur ser framtiden ut, är det några nya större projekt på gång eller intressanta saker som lockar?

curl är ju mitt pimära projekt. Mina engagemang i c-ares och libssh2 är direkt kopplade till att jag skulle få libcurl bättre, även om båda är stand-alone och oberoende från libcurl så är de byggstenar som behövs.

I samma anda har jag på senaste tiden kikat mycket på SPDY och då framför allt libspdy och jag har gjort mina första trevare där, och jag hoppas kunna jobba lite mer där framöver för att en dag kunna få libcurl att prata SPDY på samma sätt som browsers kommer att göra det inom en snar framtid.

I övrigt finns det massor med grejor kvar att fix och ordna inom curl-projektet och inte minst support och debugging av problem tar en avsevärd andel av min foss-tid (som till största delen än idag är fritid).

Jag planerar aldrig väldigt långt framåt utan hugger i när jag får syn på något. Jag bangar inte för att clone git-repos, patcha kod och pilla om för att få saker att funka. Om det är något jag får för mig att göra och de existerande alternativen inte är bra nog, ja då kanske jag antingen bidrar till det alternativ som verkar närmast dit jag vill, eller så startar jag ett eget projekt.

Jag vill också fortsätta se till att vi får grymma foss-sthlm-träffar med föredrag och aktiviteter som är roliga och intressanta. Med RMS-besöket och hur bra det gick med det, bevisade också att vi mycket väl kan klara av större arrangemang om vara villkoren är rätt…

Det två åren som vi kört FOSS-Sthlm nu har ju definitivt visat att det finns ett intresse både från communityn och framförallt från företag. Trodde du att det skulle bli så här stort?

Det trodde jag verkligen inte! Jag hade i min enfald fått intrycket att vi inte var så många med det här intresset i Stockholmsområdet efter att jag deltagit på diverse open source-, linux- och BSD- event genom åren. Att vi genom att bli mer tekniska och mer nerdiga kunde attrahera såhär många människor förvånade mig. Det har verkligen varit en superkul upptäckt och jag tror vi har mycket mer kul att hämta och göra inom foss-sthlm framöver.

Slutligen, för studenter och andra som vill bli involverade i FOSS vad är dina tips?

”Scratch your own itch” är ett mantra jag tror på. Det bästa är att gräva och fixa där man redan är. Har man ett program man inte gillar, några problem man har eller kan åtgärda? Någon dokumentation som saknas eller är fel? Kan man rita nya ikoner eller hjälpa till med att erbjuda support på en mailinglista eller forum för ens favoritprogram?

Har man aldrig gjort något inom FOSS tidigare så är det bäst att man börjar med att läsa. Läs utvecklar-mailinglistan för ditt favoritprogram ett tag. Läs deras forum. Kolla release-notes på senaste releasarna. Lär känna kulturen inom det projektet där du tänker dig att en insats av dig kan behövas.

När du fått lite hum om hur det verkar funka, posta dina förslag på förbättringar, dina buggrapporter eller dina patchar. Var beredd på att få förklara dig. Kom ihåg att det är vanliga människor du pratar med (med eventuella språkliga problem och kulturkrockar), var hövlig, ödmjuk och artig så kommer du hur långt som helst.

Väldigt vikigt är förstås: ha kul när du gör det!

I vår serie av intervjuer med svenska FOSS människor börjar vi med Henrik Nordström. Henrik är utvecklare och bland annat involverad i HTTP-proxyn Squid och BankID klienten FriBID.

Han är hemmahörande i Stockholm och föreläst på bland annat FSCONS och FOSS-Sthlm träffar.

Berätta lite om din bakgrund innan du blev involverad i öppen källkod?

Jag växte upp med datorer och programmering. Började programmera vid ca 10 års ålder, först BASIC, sedan Assembler och C vilket numera är mitt modersmål.

Tog mig igenom Tekniskt Gymnasium med blandat betyg, och när det sedan blev dags för Högskola så blev det Sytemprogrammerarlinjen i Skövde, vilket var 110% rätt utbildning för mig. Efter inledande mattevecka så kastades vi in i en labbsal med UNIX terminaler och där kom jag rätt snabbt i kontakt med diverse fria programvaror som GCC, Emacs, Någon Pascal kompilator jag förträngt namnet på mm. En del prat om MINIX, men så började det ryktas om något som kallades Linux.

Andra året extraknäckade jag som systemadministratör för Institutionen för Ingenjörsvetenskap med ansvar för ett antal HP-UX CAD stationer, och lite av en slump hamnade det även på mitt bord att ordna så att hela högskolan inklusive studentnät kunde få tillgång till nymodigheten World Wide Web när Internet kom till högskolan, då med hela 64Kbit/s förbindelse som ersatte det UUCP modem som använts tidigare för epost.

Under ett års tid provade vi oss igenom de olika http proxy servrar som fanns tillgängliga, men var ingen som kunde hantera lasten riktigt bra. Till slut föll valet på Harvest Cached, från vilken Squid projektet sedan föddes.

Så likt många i början på 80-talet var det möjligtvis en C-64 eller en Apple II som var första datorn?

Första datorn var Commodore VIC-20 (BASIC), följt av C128D (Assembler) och Amiga (C & Assembler). Förekom även någon PC ihopskramlad av diverse skrot där det hackades C & Assembler.

Dessa ”hemdatorer” stannade dock kvar hemma i föräldrahemmet när det bar iväg till högskolan. Första året där blev djupdykning i HP-UX och SunOS, med merparten av dygnets timmar spenderade med högskolans datorer, men sedan började Linux leta sig in hemma som komplement. Men dröjde dock många år innan datorn hemma kunde mäta sig mot skolans datorer.

Du är väl kanske som mest känd genom att din inblandning i Squid proxyn där du dessutom är release manager för 2.x serien men vilka andra projekt är du aktiv i?

För tillfället är jag mer eller mindre aktiv i Squid, Fedora, FriBID samt libssh2. Har även under årens gång varit aktiv i Linux iptables/Netfilter, User Mode linux, WebDNS, samt rört runt i en bunt andra projekt efter behov, även om Squid varit mitt huvudprojekt genom åren.

Så rätt mycket fokus på nätverksrelaterade projekt alltså? det är väl rätt vanligt att man rör sig kring sådant som linkar det som fick ens intresse i början. Vad gör du i Fedora?

Stämmer att jag för det mesta hållit mig inom nätverksnära delar.

I Fedora paketerar jag Squid, Bazaar (bzr) samt några småsaker, är ambassadör, samt även aktiv i portningen till ARMv7 architekturen.

Stödde högskolan på något sätt utvecklingen genom att ni fick förbättra Squid på ”arbetstid” eller på annat sätt?

Frågan kom faktiskt aldrig upp, men inte heller någon som motsatte sig det. Var dock en ganska annorlunda ”anställning” då det var helt baserat på att jag var student, där studier går före det samtidiga driftsansvaret. För min del var det en enorm möjlighet att lära sig UNIX, drift och utveckling på ett helt annat sätt än vad som var möjligt i labbar.

FriBID som du hackar på utvecklas mycket genom reverse engineering av den ”officiella” BankID klienten vad jag förstår – hur ser Nexus och de som står bakom BankID på detta och har dom hotat med rättsliga åtgärder?

Det har vad jag vet inte förekommit någon som helst kontakt mellan FriBID och Nexus/BankID, inte ens inofficiell sådan.

Angående reverse engineering av den officiella BankID klienten så har vi hållit oss till black-box reverse engineering där vi tittar på in & utdata, samt tillgängliga standarddokument som beskriver formaten i fråga efter att de identifierats.

Och ni har inte lyckats låsa era BankID konton så ofta så bankerna börjat undra vad ni håller på med?

Nej, inga sådana problem har uppkommit.

Mycket av testningen av nya funktioner görs dock lokalt. Men det verifieras givetvis mot äkta BankID tjänster.

Låter det som det var mer behov och intresse för det tekniska än det ideologiska som fick dig inblandad i FOSS, stämmer det?

Det stämmer. Dock har de ideologiska aspekterna blivit tyngre och tyngre över åren. Men egentligen handlar det om att jag blivit mer uppmärksam på de negativa effekterna av inlåsning och utestängning i proprietära lösningar. Rent ideologiskt har värderingarna alltid legat närmare fri programvara än proprietär, med en stor vilja att kunna utforska och förändra.

Att jag propagerar för nyttan med och vikten av fri programvara är för min del naturlig del av vad jag gör och vem jag är. Men är på intet sätt absolutist vad gällande copyleft. Var sak har sin plats. copyleft är i sammanhanget bara ett möjligt verktyg och inte en grundsten eller ens krav för fri programvara.

Du kör likt rätt många andra inom FOSS konsultande i eget bolag. Hur har din inblandning i olika FOSS projekt hjälpt till?

Jag har valt att vara konsult inom FOSS, där min marknadsföring i första hand är inblandning i FOSS projekt som intresserar mig. Så det finns ingen tvekan om att det hjälpt till.

Hur brukar dina kunder ställa sig till att dela med sig av det du gör för dom om du t.ex. utökar en FOSS komponent?

För de flesta är det självklart att dela med sig av utvecklad kod efter en kort diskussion, då det inte är hållbart för kunden att själv underhålla ändringar & tillägg på sikt. Speciellt inte då dessa i sig inte är kärnverksamhet utan enbart verktyg.

Men blir nästan alltid merarbete med att förtydliga eller omarbeta avtal så att det funkar ihop med FOSS eller ens programvarukonsult i allmänhet. Oftast så är standardformuleringarna i både uppdragsavtal samt sekretessavtal problematiska för FOSS men även leverantör av programvara i allmänhet.

Ett exempel är ett stort multinationellt företag som anlitade mig för att implementera nya funktioner i Squid som har GPLv2+ licens, och en stor del av deras standardavtal för uppdrag samt även sekretessavtal innehöll text som uttryckligen förbjuder all användning av komponenter med open source klassad licens. Kunden förstod dilemmat efter att jag påpekat det, men tog ändå flera veckor att komma tillrätta med.

Ett annat exempel är sekretessavtal som försöker smyga in klausuler om att kunden äger upphovsrätt och övriga rättigheter till allt producerat men och levererat material, vilket både är felplacerat i allmänhet och mycket problematiskt i FOSS sammanhang.

Brukar lösa sig efter en tids diskussion, men man får i allmänhet räkna med några veckors förseningar av projektstart för att reda ut avtalsfrågorna så att avtalen passar med uppgiften.

Q: How do I protect my source code?
A: With a lawyer

En bättre fråga i sammanhanget är hur man som FOSS konsult skyddar sitt huvudinnehåll och övriga verk. Och det är i första hand genom att verkligen läsa och ifrågasätta avtal innan de skrivs på, och vara noga med att inte skriva under sådant som ej är förenligt med den egna verksamheten. En jurist kan vara till hjälp men ersätter inte egen förståelse för vad som står i avtalstexter.

Och i det stora hela är det inget stort problem, bara man är medveten om vad som gäller. Förklarar man på vanligt enkelt språk varför föreslagen kontraktstext inte fungerar i FOSS sammanhang så går brukar det lösa sig. Bara man är medveten om att standardavtalen oftast inte fungerar särskilt bra och att det tar viss tid att komma tillrätta med.

Som lekman tycker jag det legala tråkigt och krånligt och brukar själv föredra BSD eller MIT licensen som är lätt. Vad brukar du välja för licens för dina projekt och varför?

Oftast är licensvalet direkt avhängigt från vilka andra komponenter verket i fråga är baseras på. Är sällan något skapas helt fristående och det är direkt olämpligt ur flera aspekter att blanda olika licenser om man inte måste.

I de fall licens kan väljas fritt så beror det på..

För ett mindre verk, av ”exempel” karaktär? Solklart BSD/MIT licens.

För större verk är är det svårare. Beror på målgruppen för verket, vilka slutanvändarna är, vilka alternativ som finns och situationen som verket skapas i. Svårt att ge något entydigt svar förutom att valet för programvara är i möjligaste mån begränsat till BSD/MIT eller GPL.

Du skrev att du är ambassadör inom Fedora, kan du berätta lite vad denna roll innebär?

En Fedora Ambassadör representerar Fedora projektet och dess värderingar. Det vill säga sprider kunskapen om vad Fedora är för något och vad det står för. En ambassadör guidar även nya potentiella bidragsgivare till projektet hur de kan bidra och vart de skall vända sig för att komma igång på rätt sätt.

Slutligen,  för studenter och andra som vill bli involverade i FOSS vad är dina tips?

Börja med att definiera vad som både intresserar dig och som du har behov av. Lyckad inblandning i fri öppen programvara handlar till ca 80% av intresse och 20% kompetens. När du hittat något som känns rätt för dig så lär dig programvaran i fråga och var aktiv på användarlistor/forum. Sedan när tiden känns mogen så ge dig på programkoden. Börja med något litet som du irriterar dig på och väx med uppgiften.

Försök inte förstå allt på en gång. Var medveten om att de flesta projekt är odokumenterade och väldigt få om någon faktiskt kan hela bilden, de flesta fokuserar på något/några områden inom programvaran i fråga.

Och inte minst, var inte rädd för att fråga och lyssna på råd. Bättre att fråga en gång för mycket i än att få bakläxa senare. Och var tydlig med vad du egentligen vill åstadkomma. Diskussion och dialog är vad som driver projekten framåt.

Tack Henrik för dina svar. Som fellow FOSS-utvecklare känner jag igen mig i mycket.

Perl5 är i skrivande stund (nov 2011)  17 år gammalt och genom åren har det tillkommit mycket ny funktionalitet i kärnan och på CPAN finns allt mellan himmel och jord så som bryggor mot andra språk, MOPs, alternativa runloops, källkodsfilter osv.

Jag tänkte i denna del ta upp tre grundläggande tekniker som inte kräver någon direkt djupare förståelse av hur det funkar internt – prototyper, attribut och källkodsfilter. Viss kunskap om referenser och moduler är dock nödvändigt. Hur man manipulerar op-trädet, definierar egna nyckelord och implementerar alternativa runloops och annat godis kommer i del 2 (och 3 om det blir mycket).

Prototyper

I Perl5 deklarerar man inte argumenten till en subrutin som i t.ex. C utan dessa kommer i variablen @_. Perl5 har dock något som kallas för prototyper som tyvärr allt för många misstar för att vara formella argument deklarationer. Prototyper har ett och endast ett användningsområde; när man vill påverka hur parsern (dvs det som tolkar vad källkoden betyder) tolkar funktionsanrop. Vi kan illustrera detta genom följande exempel tar två skalära argument

sub test($$) {
  my ($x, $y) = @_;
}

Givet @a = (1..5); @b = (10..15) så gör anropet test @a, @b; att $x och $y får värdet 5 vilket är längden på respektive array, vilket man får om man använder en array i skalar kontext. Anropet &test(@a, @b) kommer dock ge $x värdet 1 och $y värdet 2 vilket är de två första elementen i @a. Varför? jo, för anrop med & och parenteser ignorerar prototypen. Prototyper ignoreras också när det är metodanrop och kräver att deklarationen av subrutinen setts av parsern innan något anrop.

Vad prototyper är till för då? Jo, för att kunna emulera syntaxen för vissa built-ins t.ex. push, grep och map. Prototyper är compile-time vilket innabär att dom kollas när ditt program kompileras. Hur perl transformerar din kod till något körbart kommer tas upp i framtida delar eller separata artiklar.

Låt oss kolla på ett riktigt exempel: hur vi skapar en funktion som för en varje element i en lista testar den mot ett uttryck och om alla är sanna returnerar sant – dvs, precis det som all från List::MoreUtils gör.

sub all(&@) {
  my $f = shift;
  $f->() or return 0 for @_;
  return 1;
}

my $ok = all { $_ =~ /oo+/ } "foo", "fooo", "foooo";

Prototypen &@ innebär att vi förväntar oss en referens till en subrutin och @ att resten är en lista. Vi skulle kunna anropa den som all \&check, ”foo”, ”fooo”, ”foooo” eller ge den en anonym subrutin istället. När & förekommer först i prototypen kan vi dock utelämna sub och ge den vad till synes är ett block istället.

En annan rätt händig prototyp är den tomma () vilket innebär att funktionen inte tar några argument alls. Det gör vi kan skapa vår egna implementation av time och kan skriva mytime +4 och den tolkar detta som mytime() + 4 istället för mytime(+4). En tom prototyp används också för att skapa konstanter som optimeraren ersätter med det faktiska värdet.

Prototyper gör att man kan skapa suba egna små DSL (domän specifika språk) tämligen enkelt men skall inte användas för att kolla att antal argument är rätt. Mer information om prototyper finns i perlsub.

Attribut

Variabler och subrutiner kan annoteras med attribut vilket ger en möjlighet att ge dem speciella egenskaper eller på annat sätt agera . Attribut är dock inte så vanligt förekommande och anses fortfarande lite lätt experimentellt. Jag vill ändå visa hur det kan användas.

Jag har en modul, JSON::RPC::Simple, på CPAN för att exponera klasser och metoder som JSON-RPC 1.1wd . Den använder attribut för att annotera vilka subrutiner i mina klasser som skall vara anropbara via JSON-RPC.

package MyApp::API;

use base qw(JSON::RPC::Simple);

sub new { return bless {}, shift };

sub echo : JSONRpcMethod(Arg1, Arg2, Arg3) {
  my ($self, $request, $args) = @_;
}

1;

Det intressanta i koden ovanför är JSONRpcMethod attributet efter sub echo. Det används för att markera att just denna metod är en JSON-RPC metod med namnsatta argument och dessa är Arg1, Arg2 och Arg3 . Vad som händer internt är dock lite mer spännande. Om det vid compile-time finns en MODIFY_CODE_ATTRIBUTES i det aktiva paketet eller något man ärver kommer denna anropas och vi kan manipulera det vi annoterar om så önskas. Vi är dock bara intresserade av deklarationen och vill inte göra någon manipulation. Här är implementationen:

my %method_attributes;

my $method_attr_re = qr{
  ^
  JSONRpcMethod
  (?:\(\)|\(
    \s*
    (\w+ (\s*,\s* \w+)*)?
    \s*
  \))?
}sx;

sub MODIFY_CODE_ATTRIBUTES {
  my ($class, $code, @attributes) = @_;

  # Check if this contains a JSONRpcMethod attribute
  my @bad;
  for my $attribute (@attributes) {
    if ($attribute =~ $method_attr_re) {
      my @attrs = split /\s*,\s*/, ($1 || "");
      $method_attributes{refaddr $code} = \@attrs;
    }
    else {
      push @bad, $attribute;
    }
  }

  return @bad;
}

Trots att vi kan annotera med flera attribut, t.ex. sub foo :this :that {}, så anropas MODIFY_CODE_ATTRIBUTE endast en gång och med alla attribut som är definierade. Denna subrutin förväntas returnera en lista på alla dåliga attribut som den inte kan hantera och då kommer kompileringen att avbrytas. Som första argument kommer namnet på det aktiva paketet, som andra argument en referens till en subrutin och sedan alla definierade attribut. Dessa är bara text så de måste manuellt tolkas som i mitt fall med ett reguljärt uttryck. Varje attribut är ett namn följt av frivillig data inom balanserade parenteser. Då vi bara får en referens till subrutinen och inte dess faktiska namn så måste man kolla upp det om det behövs ( B::svref_2object($ref)->GV->NAME ).

Om attributet matchar vårt reguljära uttryck så sparar vi argumenten i en hash där nyckeln är addressen till vår subrutin. Då våra subrutiner inte flyttar på sig så kan vi använda detta senare för att få ut informationen.

Nu när kompileringen är klar och allt har gått bra vill vi använda det vi precis gjort. I JSON-RPC bryggan binder man klasser eller objekt till en sökväg så t.ex. /api hanteras av MyApp::API. JSON-RPC anropet anger ett namn och detta använder vi för att få ut motsvarande metod med samma namn via $obj->can($method). can är en metod i UNIVERSAL vilket innebär att den ärvs av alla klasser och denna returnerar en referens till subrutinen som skulle anropas om vi gjorde ett vanligt metodanrop. Denna referens address kollar jag sedan upp i %method_attributes och får på så sätt namnen på argumenten. Inte speciellt krångligt så länge man har en typ av attribut på en datatyp bara…

Men, för att göra det enklare att skriva attribut finns det en väldigt praktisk hjälpmodul som tillhandahåller ett attribut-baserat API för deklarera nya attribut, nämligen Attribute::Handlers. Säg att vi vill göra en skalär typ som bara accepterar numeriska värden inom ett visst område. Den syntax vi vill använda är

my $x : Range(1, 20) = 15;

Vi börjar dock med att implementera typen vilket via gör enkelt via tie mekanismen. Detta exempel är väldigt förenklat och mer felkontroll borde göras men det duger som exempel.

package Range;

use strict;
use warnings;
use Carp;

sub TIESCALAR {
  my ($class, $min, $max) = @_;
  bless { min => $min, max => $max, value => $min }, $class;
}

sub FETCH { shift->{value}; }

sub STORE {
  my ($self, $value) = @_;
  if ($value < $self->{min} || $value > $self->{max}) {
    croak "Value $value out of range"
  }
  $self->{value} = $value;
}

1;

Normala sättet att använda denna är genom tie my $x, ”Range”, 1, 20; vilket gör $x till en tied variabel. Nu skall vi dock lägga till så vi kan göra detta via ett attribut istället och använder då Attribute::Handlers. Vi lägger till följande innan sista raden (1;)

use Attribute::Handlers;

sub Range : ATTR(SCALAR) {
  my (undef, undef, $referent, $attr, $data) = @_;
  my ($min, $max) = @$data;
  tie $$referent, 'Range', $min, $max;
}

sub import {
  my $caller_pkg = (caller)[0];
  no warnings;
  eval qq{
    sub ${caller_pkg}::Range : ATTR(SCALAR) {
      goto &Range::Range;
    }
  };
}

Första raden säger att vi vill ladda Attribute::Handlers och importera eventuella funktioner det exporterar automatiskt. sub Range : ATTR(SCALAR) är vårt nya attribut som är tillämpningsbart på skalärer och som skall anropas varje gång man skapar använder just Range attributet. Det vi är intresserade av är variablen ($referent) som vi får en referens till och argumenten till attributet ($data). Attribute::Handlers är så smidigt så den försöker tolka det som står inom () efter attributet och göra det till en vettig datastruktur i vårt fall en array referens. Nästa steg är helt enkelt att anropa tie på den faktiska variabeln, därav derefereringen.

Vår import funktion, den anropas automtiskt vid use , sätter upp attributet i det anropande paketet. Lite magi men det är så Attribute::Handlers måste göra om man vill göra sina attribute tillgängliga utanför där man deklarerat dom.

En provkörning senare och vi är i mål!

$ perl -MRange -E 'my $x : Range(10, 20); $x = 25'
Value out of range at -e line 1

Källkodsfilter

Den sista saken jag tänker ta upp är källkodsfilter och samtidigt höja ett varningens finger för att använda detta då det är en enkel källa för fel som är svåra att diagnostisera. Modulen Switch som implementerar en switch/case liknande syntax är ett bra exempel på hur fel det kan bli. Sedan 5.10 finns dock given/when implementerat som är en kraftfull variant av switch/case.

Vi ska göra ett extremt enkelt filter som ersätter alla alla förekomster av WHERE_AM_I;  med en print till STDERR var man är någonstans. Vi kommer att nyttja Filter::Simple vilket är ett enkelt API till källkodsfiltreringen.

package WhereAmI;

use Filter::Simple;

FILTER {
  s{\bWHERE_AM_I;}
   {print STDERR "I'm at line ", __LINE__,
                 " in ", __FILE__, "\n";}g;
}

1;

Vårt filter förändrar källkoden som vi får i $_ i FILTER funktionen. Vi ersätter WHERE_AM_I; med var vi är någonstans. Vi använder oss av __LINE__ och __FILE__ vilket är nuvarande raden och filen som parsern behandlar. Ska man vara petig kan man likt cpp sätta vilken rad man är på med en speciell #line <nr> kommentar så det är inte nödvändigtvis den faktiska fysiska raden i filen.

Testskriptet vi kör detta på ser ut som följande

use WhereAmI;

print "Before\n";
WHERE_AM_I;
print "After\n";

En testkörning och vi får

$ perl foo.pl
Before
I'm at line 4 in foo.pl
After

Om vi kollar på vad perl kompilerade så skickar vi det genom B::Deparse som omvandlar op-trädet tillbaks till källkod.

$ perl -MO=Deparse foo.pl
use WhereAmI;
print "Before\n";
print STDERR q[I'm at line ], '4', ' in ', 'foo.pl', "\n";
print "After\n";

Som synes så har vårt filter gjort om källkoden till det vi ville. perl har också ersatt __LINE__ och __FILE__ med konstanter.

Källkodsfilter kan man använda till mycket roligt men bör inte användas till någonting seriöst just för att det involverar att tolka Perl vilket är extremt svårt att göra rätt. Kanske hört uttrycket ”only perl can parse Perl”?

Om du ändå känner för att dyka djupare kolla på Filter::Util::Call vilket är det normala Perl APIet. Läs också perlfilter och kolla på Lingua::Romana::Perligata som finns på CPAN – ett ypperligt exempel på galenskapen som kan åstakommas.

Nästa gång ska vi dyka djupare in och se hur vi kan manipulera det som kompilerats.

Så, en decemberdag 2009 (7:e rättare sagt som råkade vara min 30-årsdag) tog jag upp med Daniel på IRC hur sällan jag tycker man kommer i kontakt med andra svenska FOSS-hackers utanför sina intresseområden och vi pratade om att dra igång något. Ett par dagar senare skickade jag detta till några kontakter

Hej,

Daniel Stenberg (cURL, Rockbox, libssh2, c-ares) och jag (Perl/CPAN) diskuterade häromdagen hur sällan det är man faktiskt kommer i kontakt med andra open source aktiva utanför sin egen sfär. Därför tänkte vi att det vore roligt och intressant att försöka få till ett socialt evenemang (läs pub eller liknande) med ett brett spektrum av deltagare från olika läger – behöver dock inte endast vara utvecklare. Tanken är att man skulle hålla det rätt litet till att börja med, kanske runt 30-40 pers men om det är lyckat så får man ju se vad det kan ge.

Så, ni som fått detta mail har jag träffat i något sammanhang, jobbat med eller känner till på annat sätt och som jag tycker vore roligt om ni kunde vara med. Dessutom tror jag ni har bra kontakter så jag vore tacksam om ni kunde förslå andra som ni tycker skulle vara intressanta att få med och vad de sysslat med (och uppgifter så jag kan kontakta dom). Företrädesvis folk i Stockholm med omnejd.

Är nog inte helt omöjligt att få några företag att slanta upp lite spons-pengar för dricka heller om de får vara med och knyta kontakter.

Vad tror ni, vore det intressant? I så fall skulle det bli någon gång i slutet på Januari.

Hälsningar
Claes Jakobsson

Så vi satte upp en e-post lista och började planera en första träff och således var FOSS-Sthlm fött. En månad senare hade vi 100 medlemmar på listan och 50 pers som anmält intresse för att komma på träffen. .SE var vänliga att ställa upp med lokaler men det visade sig rätt fort att vi växte ur dessa. DSV (Institutionen för Data- och Systemvetenskap) vid Stockholms Universitet var dock vänliga att ställa upp med en stor föreläsningssal ute i kista (tack Beatrice!) som vi utnyttjat vid flera träffar. Första träffen (http://www.foss-sthlm.se/mote1.html) var den 24:e februari och det var 185 st anmälda, en rätt skillnad mot vår uppskattade 30-40 pers och presentationer om lite allt möjligt. Tyvärr lyckades jag dra på mig en luftvägsinfektion så jag missade första träffen.

Sedan starten för snart två år sedan har vi arrangerat ett flertal träffar och aktiviteter, nu senast med RMS som föreläsare och närmare 1000 åhörare. E-postlistan har 321 medlemmar och växer ständigt.

Vad har detta med denna publikation att göra?

I samband med RMS besök så blev han intervjuvad av en större svensk tidskrift inom IT och denna intervju blev väldigt dåligt mottagen av många inom FOSS. Vid en tripp till London i början på november bläddrade jag i lite tidningar och  det publiceras inte speciellt många artiklar med svenska upphovsmän utan mycket av det som skrivs är översättningar från andra tidningar som tillhör stora mediakoncerner. Och dessa skrivs också väldigt ofta av journalister med dålig koll på den faktiska tekniken och peer-review är obefintlig. Jag har alltid gillat tidningar som Dr Dobbs och ACM Queue som jag tycker håller hög standard.

Så i god FOSS andra beslöt jag mig för att dra igång denna publikation och jag tror och hoppas på att många känner som jag och kommer bidra med intressant innehåll och idéer.

Vill du skriva för FOSS-Magasin? kontakta mig.

/Claes