Open Source eller kommersiell programvara? sid 6. Fri programvara valdes till vägtullsystem sid 10

Transkript

1 ntime T E M A : Nr 4 december 2002 O P E N S O U R C E Open Source eller kommersiell programvara? sid 6 Fri programvara valdes till vägtullsystem sid 10 GPL-licensierad mjukvara i inbyggda applikationer sid 12 Fri programvara kortade utvecklingstiden sid 16 Inbjudan till OnTime-seminarium om Open Source, se baksidan

2 Redaktion Ansvarig utgivare Christer Hoberg, vd Redaktionsråd Göran Carlzon, Erichs Communications Anders Magnusson, Göteborg Per-Ola Malm, Malmö Anders Åström, Linköping Innehåll Ledare...3 Varför välja Open Source?...4 Open Source eller kommersiell programvara?...6 Fri programvara valdes till vägtullsystem...10 GPL-licensierad mjukvara i inbyggda applikationer...12 Fri programvara kortade utvecklingstiden...16 Vårt område är inbyggda system.vi kommer aldrig att gå utanför detta område och måste därför behärska inbyggda system bättre än någon annan.våra uppdragsgivare kallar in oss när de står inför sin tuffaste uppgift: bryta ny mark, gå in på främmande teknikområden eller skapa nytt liv i ett projekt som gått snett. Vår affärsidé bygger på att tillföra våra uppdragsgivare nytt kunnande och effektivare metoder inom systemutveckling i kombination med överföring av den erfarenhetsbaserade, tysta kunskapen. För detta har vi utvecklat en metodik som gör att vi successivt för över vårt kunnande till uppdragsgivarens organisation.vi blir därmed så småningom överflödiga inom det dagliga jobbet, vilket som sagt är en del av vår affärsidé vår plats är först och främst inom de delar av projektet där de nya vägvalen är många och svåra. Redaktör Eva Holmquist, Jönköping eva.holmquist@combitechsystems.com Nätvariant av OnTime Jönköping (lokalkontor:växjö, Karlskrona, Ulricehamn) Box Jönköping Tel Fax Malmö (lokalkontor: Helsingborg) Box Malmö Tel Fax Göteborg (lokalkontor:trollhättan) Mölndalsvägen 30C Göteborg Tel Fax Stockholm (lokalkontor: Uppsala) Box Stockholm Tel Fax Linköping (lokalkontor: Örebro, Karlskoga,Västerås) Teknikringen 9 SE Linköping Tel Fax München Leopoldstr. 236 DE München,TYSKLAND Tel Fax E-post info@combitechsystems.com www Produktion Erichs Communications AB, Linköping Grafisk design PO.Annonsbyrå AB Tryck NRS-Tryckeri 2 Nr 4 december 2002

3 LEDARE Det finns inga fria luncher Många lockas av Open Source baserat på att den ses som gratis. Normalt blir det billigare i form av utgifter för licenser, men var kommer kostnaden? kvaliteten på produkten. Å andra sidan har Open Source-koden genom sin stora spridning nått kvalitet genom flitigt användande, där många hjälps åt att höja kvaliteten. Man måste förstå det kommersiella i att hantera Open Source, där kostnaderna inte läggs på licenskostnader och underhåll, utan snarare support, portering och utbildning. Affären har alltså flyttats från produkten till tjänsterna runt dem. Det handlar alltså inte om magi som gör allt billigt och bra, utan snarare om en strategi. Affärsstrategi med långt perspektiv Det är kostsamt att som utvecklande bolag ofta byta ut centrala delar, vilket Open Source-kodsystem inte sällan är. Det är då inte kostnader runt licenser eller utvecklingsmiljö som jag tänker på, utan kostnaden att lära och behålla kunskap inom en organisation. Det är dessutom mycket viktigt att tänka på aspekter som CMhantering av Open Source-komponenter, eftersom de troligtvis ska leva med under hela produktens livscykel. Det känns alltmer viktigt att man har en tydlig strategi över till vilka delar man ska nyttja Open Source och till vilka man ska utveckla själv. Denna strategi måste därigenom vara långsiktig för att inte varje projekt ska starta med ett vitt papper och en alltför glödande ingenjörsanda som vill bygga nytt. Kvalitet jämfört med kommersiell programvara Det är idag svårt att avgöra vilken kvalitet den fria programvaran har i förhållande till den kommersiellt tillgängliga. Å ena sidan har den kommersiella krav på sig att vara verifierad och man har som kund möjlighet att ställa krav på Att bygga på halvfabrikat Användningen av Open Source-komponenter ser jag som ett medvetet val då man definierar arkitekturen för systemet. Det är i denna fas, då man brottas med krav som porterbarhet, utbyggbarhet och prestanda, som valen blir naturliga. Att som utvecklande bolag kunna ha en bred kompetens runt centrala delar av systemen och ha möjlighet till en legolåda av komponenter är mycket tilltalande. Att dessutom medvetet jobba med att återanvända tillräckligt stora delar av systemen, som RTOS kommunikationsstackar etc., är mycket viktigt. Detta ger oss stora möjligheter till att skapa produkter där energin läggs på det som gör produkterna konkurrenskraftiga. Frihet under ansvar Det enorma utbud av Open Source som finns runtom i världen ställer också stora krav på alla individer i en utvecklande organisation. Utbudet ger oss stor möjlighet att finna lösningar som ser ut att fylla ens egna krav. Samtidigt får vi inte underskatta problematiken med att anpassa delar så att de passar våra krav, och inse omfattningen av att lyfta en nästan färdig driver till en del av den slutgiltiga produkten. Med sund affärsmässig inställning och insikt i komplexiteten ger Open Source oss en styrka att koncentrera utvecklingen till de delar som är unika i våra produkter. Fredrik Mattsson Affärsenhetschef, Combitech Systems Nr 4 december

4 AV DANIEL LIDSTEN Varför välja Open Source? Orden gratis och fritt är två ord som hos många kommit att förknippas med begreppet Open Source. Företag finner det därför lockande att hoppa på tåget som basunerar ut budskapet att här finns gratis komponenter att hämta, framförallt eftersom flera företag idag upplever att utvecklingskostnaden för deras produkter skjuter i höjden.vad innebär då utnyttjandet av dessa fria produkter och vilken typ av gratis produkter finns? För att framgångsrikt kunna ta för sig av innehållet på det smörgåsbord som Open Source erbjuder, måste man ha en del legala och kulturella aspekter i åtanke. Tanken med följande artiklar i detta nummer av OnTime är att ge en grundläggande insikt i frågor man bör vara familjär med. Utveckling av programvara och maskinvara är inte ett mekaniserat tillverkningsarbete, utan kräver för framgång ett stort inslag av kreativt arbete. Under utvecklingsprocessen erfordras omfattande mänsklig och social interaktion. Dessutom krävs kunskap om, och insikter i, den teknik man faktiskt är sysselsatt med och hanterar, samt vilka mål som eftersträvas. Trots detta tenderar det faktum att komponenterna eller utvecklingsverktygen är gratis att komma i fokus, samtidigt som den verkligt stora kostnaden kommer i skymundan, nämligen kunskapen om dessa fria komponenter och utvecklingsverktyg. I detta sammanhang vill jag starkt understryka att det inte är komponenterna i sig som kan säljas, utan källkoden måste integreras i ett system för att generera intäkter till företaget. Tittar man på företag som enbart jobbar med Open Source och jämför med traditionell systemutveckling, så har alltså affärsidén ändrats från försäljning av den rena källkoden till att i stället handla om erbjudande av tjänster kring källkoden, såsom support och anpassningar. Varför dela med sig till andra? Bland företag i branschen finns en mängd olika synpunkter på konceptet med fri tillgång till komponenter. Man kan dock konstatera att de två hittills mest kända fallen webservern Apache och operativsystemet Linux har visat att konceptet både är gångbart och lyckat. Såväl Apache som Linux har fått en enorm spridning. Varför har då dessa projekt blivit enorma succéer? Finns det något inom denna sfär som saknas inom traditionell systemutveckling? Vad motiverar personer att frivilligt dela med sig av sina kunskaper, tillsynes helt utan ersättning? Varför är kvalitén så hög på många av Open Source-produkterna och varför väljer företag dem framför andra kommersiella alternativ? Drivkrafterna bakom programmerare som frivilligt och gratis släpper iväg komponenter på nätet kan vara både praktiska och psykologiska. En praktisk orsak kan till exempel vara att när en programvara släpps fri, helt utan begränsningar, eliminerar den alla barriärer som annars är hinder för distribution och anpassning av koden. Den har därigenom, på kortare tid, skapat en större grupp anhängare än vad som hade varit fallet om användare avkrävts pengar för licenser och dylikt. Därmed kan öppen källkod vara nyckeln till vad som ofta eftersöks i affärsvärlden, nämligen att bygga upp marknadsandelar. En annan positiv effekt med öppen källkod som kan motivera företag att göra den allmänt tillgänglig är att ju fler personer som använder källkoden desto mer avlusning görs och fler felrapporter genereras. Produkten har således genomgått en mer omfattande test och håller därigenom sannolikt en bättre kvalitet än produkter som inte testats på detta sätt eller i denna omfattning. Det ska dock poängteras att det även finns andra drivkrafter än de strikt ekonomiska bakom utvecklingen av Open Source-komponenter. Det kan ligga nära till hands att tro att personer bidrar till öppna projekt för att de tycker att det är kul att programmera. Det förklarar emellertid inte varför de ger bort sin kod gratis. Den generositet som dessa personer uppvisar beror troligtvis på att de därigenom tror sig kunna bygga upp ett ökat professionellt anseende. Ännu bara i början av utvecklingen Ur en legal aspekt kan emellertid sägas att hela området tycks vara fyllt med osäkerhet om vad som faktiskt gäller. Troligtvis är detta egentligen endast ett tecken på att Open Source-fenomenet fortfarande är i början av sin utveckling och därmed tämligen omoget. Användandet av Open Source-källkod binder vanligtvis utvecklaren till en licens, vilken i princip alltid kräver att de modifieringar som görs i koden också görs allmänt tillgängliga. Det som hänt är alltså att användarna av programmen nu även bidrar som utvecklare av desamma. Det finns emellertid företag och utvecklare som uppfattar denna form av licensiering som ett hot mot äganderätten och därför aldrig riktigt vågat använda sig av några Open Source-komponenter. Jag vill dock inte påstå att en allmän publicering av källkod automatiskt medför att mängder med utvecklare världen över kommer att bidra till att skapa en bättre programvara. Så är det självklart inte. Ett exempel på detta är då SUN steg in på Linuxmarknaden och köpte upp StarOffice, ett paket motsvarande Microsofts Office, varefter SUN meddelade att bolaget avsåg att släppa källkoden till StarOffice fri. Spontant kan detta låta som en företagsstrategiskt bra idé, eftersom bolaget trodde att publiceringen skulle bidra till att programmet utvecklades utan att bolaget 4 Nr 4 december 2002

5 behövde lägga ner några kostnader. Man måste ändå förstå att ett program som StarOffice innehåller enorma mängder kod. Det är därför inte gjort i en handvändning att sätta sig in i ett Officepaket och tillföra revolutionerande ändringar. Vad man måste inse är att det alltid finns ett skäl till att programmerare ansluter sig till speciella projekt och vanligtvis är det att de själva har nytta av programmet och därigenom lägger sin fritid på förbättringar. En analogi kan även dras till Netscape som ville återerövra sin tidigare framstående position som webbläsare men som trots fri källkod inte lyckades med detta. Strategi saknas hos företagen Något som är vanligt hos företag, där användandet av Open Source är tämligen nytt, är att det saknas en utarbetad strategi. Det som bör planeras är för vilka delar i arkitekturen hos en produkt som man väljer att plocka in Open Source, och för vilka delar man väljer att utveckla programvara själv. Ett vanligt sätt att realisera ett system är genom ett bottom up-perspektiv. Det innebär att vissa individer inom organisationen har kännedom om vad som finns tillgängligt i form av Open Source på nätet och propagerar för inlyftande av dessa. Frågan är om det finns en medvetenhet kring denna lite informella process hos företagen och ifall de skulle vinna på en mer strukturerad och systemorienterad beslutsprocess? I den processen skulle det även kunna tas med en översiktlig värdering av vad som är viktigt i varje komponent såsom licensvillkoren, prestanda, säkerhet, driftsäkerhet, kompatibilitet, supportkostnader, vidareutveckling med mera, för att på så sätt göra det bästa valet mellan egenutvecklad programvara, licensiering av tredjepartsleverantör och Open Source. orsaker till detta. För det första är det inte helt enkelt att hitta projekt som bedrivs på nätet där man kan utläsa ett aktivt utvecklingsarbete och en ständigt pågående diskussion mellan användare. Tyvärr finns det mängder med projekt som en gång startades med glöd, men som med tiden glidit in i ett vakuum där ingen längre aktivt förvaltar koden. I samband med sökandet efter källkod att införliva i det egna projektet, måste man vara medveten om att det i princip aldrig finns kod som är värdeskapande i sig själv. Det som finns fritt tillgängligt måste ses som en pusselbit i ett mycket större perspektiv. För det andra kan det komma att krävas mycket energi och framförallt omfattande kunskap för att analysera en komponent med avseende på kvalitet och anpassningsbarhet. Detta gäller särskilt i fall där man funnit en komponent som är komplicerad och innehåller stora kodmängder. Man får dock aldrig tro att det finns källkod på nätet som helt utan anpassning och med liten möda fungerar som handen i handsken i ens arkitektur. Detta är en utopi. Det krävs alltid en viss handpåläggning, vilket innebär kostnader. Det måste också finnas en utarbetad strategi för hur den inlyfta komponenten ska verifieras och testas mot resten av systemet. Finns sådana tester och i så fall är de tillräckliga eller bör nya, mer omfattande, tester tas fram? En tredje orsak tror jag kan vara att företaget vid Open Source-användning inte på traditionellt vis genom ett supportavtal är berättigat till hjälp inom en viss tidsram. Man är i stället utlämnad till hjälpsamma befintliga användare, samt till sin egen kapacitet och möjlighet att övervinna eventuella problem. Nya användare kan därför undvika Open Source på grund av rädsla för att inte kunna använda koden på rätt sätt. Användande kräver ansvarstagande Generellt sett ligger den mesta utvecklingen inom Open Source i framkant på respektive produkt, det vill säga mycket görs för att vidareutveckla eller utöka befintlig funktionalitet och detta leder i praktiken till att det kan vara svårt att hitta support för äldre versioner. Vid användande av Open Source krävs därför ett aktivt ansvarstagande för eventuellt underhåll och vidareutveckling. Redan i början av en utvecklingsfas bör beslut om hantering och uppdateringar av de fritt tillgängliga komponenterna fattas. Ett alternativ är att ett par personer utses som hela tiden håller koll på vad som händer och med små tidsintervall fasar in och testar viktiga förbättringar. Ett annat alternativ är att den version som företaget är nöjd med infogas i projektet, varefter inga ytterligare resurser läggs på kontinuerlig uppdatering. Avslutningsvis kan sägas att ett företag som står på tröskeln till att plocka in Open Source-kod i en produkt måste beakta att företaget kommer att bli värderat med avseende på detta beslut. Man måste fråga sig själv vad slutkunden tycker om ett användande av Open Source. Svaret på detta är självklart mycket beroende på inom vilken bransch man verkar, samt till vilka delar av produkten man valt att använda Open Source. Med förhoppning om trevlig läsning! Daniel Lidsten Analysera kvalitet och anpassningsbarhet Vad är det då som företag tycker är svårt, och varför har vi inte sett ett större genomslag av Open Source? Självklart finns mängder av Daniel Lidsten har varit anställd på Combitech Systems i tre år som systemutvecklare och har under denna tid jobbat i flera projekt som använt Open Source-komponenter. Nr 4 december

6 AV JACK GANSSLE Open Source eller kommersiell programvara? Publicerad med tillstånd av Jack Ganssle.Tidigare publicerad på med namnet Open Source vs Properity. Vi gör gratis mjukvara överkomlig. Det ligger otroligt mycket visdom i detta korta motto från Cygnus (nu en del av Red Hat), och mer än en nypa cynism. Jag tänker på detta varje gång någon överdrivet entusiastisk förespråkare för Open Source försöker övertyga mig om att fri kod, eller GPL-kod, eller någon annan variant av gratis mjukvara ska rädda marknaden från kollaps. Olyckligtvis omges fenomenet Open Source av alltför mycket passionerade känslor. Richard Stallman i sanning en passionerad förespråkare är utan tvekan en visionär och drivande kraft bakom rörelsen för gratis mjukvara ( som i mina ögon blandar ihop frågorna bakom Open Source. Hans syn på gratis mjukvara går stick i stäv med vad de flesta anser när de diskuterar Open Source. Citat av typen Som datoranvändare i dag använder du säkert copyrightskyddade program. Om en vän ber dig göra en kopia känns det fel att säga nej. Samarbete är viktigare än copyright ( philosophy/why-free.html) är naiva och överförenklande. Jag håller med om att copyrightfrågor i den digitala tidsåldern är väldigt problematiska och hör till de frågor vi bara måste lösa. Men att förespråka stöld är både etiskt fel och kontraproduktivt. Att befria mjukvara genom piratkopiering är lika fel som att befria varor från krockade långtradare. Helt nya affärsmodeller prövas Det senaste decenniet har vi sett flera helt nya affärsmodeller som bygger på fri kod. Cygnus och Red Hat byggde till exempel upp lysande företag genom att sälja support och konsulttjänster till sina gratisprodukter. Netscape använde en gratis webbläsare för att bygga upp en fantastisk marknadsandel. Stallman menar sig ha lyckats med att sälja sina konsulttjänster för underhåll av fri kod. Rörelsen har skapat en livskraftig affärsmodell, men detta är långt ifrån enda sättet att driva ett företag. Copyrightskyddad kod har ett berättigande som jag inte kan se försvinna någonsin. Argumentet att företag måste införa nya affärsstrategier för att hantera filosofin kring fri kod öppnar för vidlyftiga och spännande debatter men är till stora delar förfelat. Företag bygger på, och måste ha, modeller som medger vinst (i en kapitalistisk värld). Att ta betalt för mjukvara är ett sätt att nå detta mål. Inbyggda applikationer kommer helt säkert att vara en bastion för copyrightskyddad mjukvara. Få företagsledare investerar miljoner i utveckling av marknadsledande produkter för att sedan släppa allt detta tillkämpade intellektuella kapital till den fria domänen. Och handlar det om kod som är väldigt specifik för ett visst användningsområde till exempel en ny sorts läskautomat skulle få ens vara intresserade av den inbyggda mjukvaran. Om det intellektuella kapitalet verkligen är en tillgång, är detta något som ledningen vill skydda, och ofta av goda skäl. Värde kontra pris Trots att företagen gör allt för att skydda sina rättigheter till den egenutvecklade koden, lyckas märkligt nog ingen sätta ett värde på detta intellektuella kapital. Inte ens Microsoft, vars faktiska värde helt klart ligger i företagets mjukvara, har en post i balansräkningen för värdet av sin kod. Däremot räknar de upp skrivbord och byggnader, saker som egentligen inte har någon betydelse för att göra företaget till vad det är. Tills myndigheterna och revisionsföretagen hittar ett sätt att mäta intellektuell egendom som en del av det egna kapitalet kommer allt för många företagsledare fortsätta att tycka att mjukvaran bara är ett nödvändigt ont. De begriper inte att kvalitet har ett värde i sig och har allt för lätt att säga det är bara en uppgradering av mjukvaran. Mjukvarans pris är inte detsamma som dess värde. Quicken kostar kring tusenlappen, men är värt mycket mer för Intuit och för mig. Det är basen för min personliga ekonomiska planering, för min uppföljning av de dagliga utgifterna och för att ge mig en bild av min ekonomiska ställning. Detsamma gäller för de flesta program som jag har köpt. Miljoner av oss svarar för det verkliga värdet av dessa produkter. Utan Quicken, och alla andra program vi använder varje dag, skulle vi förlora mer än den där tusenlappen. Verkstadsindustrin tvekar inför de tusentals kronor som CAD-programmen kostar, men betalar ändå priset eftersom de är helt beroende av AutoCAD och liknande produkter. Kostnaden är hög, men värdet är ännu högre. Affärstransaktionen mellan verkstadsföretaget och CAD-leverantören, från betalning för och leverans av produkten till kundsupport, uppgraderingar och anslutning till olika värdsystem, omfattar en rad operationer som är så mycket mer än att bara snickra ihop kod. De representerar också mycket stora värden för kunderna. Mjukvara dyr i förhållande till sin vikt Mjukvara, särskilt inbyggd mjukvara, hör till världens dyraste produkter. Lockheeds förre koncernchef Norman Augustine skriver i sin underbara bok Augustine s Laws (American Institute of Aeronautics; ISBN: ) om hur leverantörerna till försvarsindustrin hade hamnat i en knipa i slutet av 70-talet. Det gick inte längre att förbättra stridsflygplanen med nya funktioner, eftersom den ökade vikten skulle minska planens prestanda. Affärslivets krav ökad vinst innebar att de oavsett flygningens fysiska lagar var tvungna att lägga till funktioner. Desperata att hitta något oerhört dyrt, men ändå viktlöst, upptäckte de inbyggd mjukvara. I dag uppgår kostnaden för inbyggd mjukvara i moderna högprestandaplan till omkring hälften av den totala prislappen. En framgång med alla mått mätt, utom möjligen för skattebetalarna. Mjukvara hör till världens dyraste produkter. Detta mantra lär oss flera saker. För det 6 Nr 4 december 2002

7 Nr 4 december

8 första, dyra saker har ett värde för tillverkarna. Precis som böcker skyddas av copyright, är det rimligt att skydda egenutvecklad kod. Varför lägga ned tid och pengar på att skapa något som har ett värde, när den som gör jobbet förnekas detta värde? Precis som patent ger uppfinnarna konkurrensfördelar, ger copyrightskyddad kod mjukvaruutvecklarna fördelar i de flesta affärsmodeller. På väg mot mjukvarukris Mantrat lär oss också att det sista vi någonsin bör ge oss in på är att skriva ny kod. Det är mycket billigare att återanvända kod. Det är smartare att köpa, tigga sig till eller låna en modul än att skriva den själv. Och det är här som jag är i valet och kvalet ifråga om filosofin bakom gratis mjukvara, Open Source eller andra liknande modeller. Som jag redan har sagt har jag inte något emot att företag behåller sina tillgångar för sig själva. Men vi är på väg rakt in i en mjukvarukris som få inser omfattningen av. Kod kostar för mycket, och är ofta av så låg kvalitet att det är ett under att den alls fungerar. Som ett gammalt talesätt i branschen säger: om arkitekter byggde hus på samma sätt som programmerare skapar kod, skulle första bästa hackspett kunna ödelägga hela vår civilisation. Gratis mjukvara, i varje fall Open Source, bär på ett visst löfte om att minska kostnaderna och höja kvaliteten. I sanning ädla mål. Som jag ser det är någon form av återanvändning vårt enda hopp att komma tillrätta med kvalitets- och kostnadsfrågorna. Tyvärr verkar drömmen om att bygga upp ett bibliotek av mjukvarudelar som är generellt användbara vara dömd, till följd av bristande intresse, prisproblem och kvalitetsproblem. Rädsla för buggar I fråga om inbyggd mjukvara är kvaliteten förmodligen det främsta skälet till varför utvecklarna inte återanvänder kod. När jag frågar utvecklare varför de fortsätter att skriva sina egna realtidsoperativsystem istället för att köpa någon av de hundratals kommersiellt tillgängliga produkterna, blir motfrågan men tänk om det är buggigt? Skriver jag mitt eget system kan jag avlusa det till och med mitt i natten. En klart berättigad oro som leverantörerna ännu inte har tagit itu med ordentligt. Det finns flera realtidsoperativsystem inom ramen för Open Source. Men utvecklarna skriver fortfarande sina egna RTOS och jag möter fortfarande samma invändning, fast nu lätt modifierad till om jag skriver det själv vet jag i alla fall vad som händer när det blir problem. Vad är detta? Är möjligen det gamla hjärnspöket inte uppfunnet här förklaringen till utvecklarnas ovilja att börja återanvända? Kostar 150 till 300 kr per rad En gång, i en känsla av misströstan, försökte jag få ett grepp om dessa frågor och laddade ned Jean LaBrosses uc/os ( och körde det genom ett radräkningsprogram rader C-kod. Inte mycket egentligen rader. Jag skulle kunna skriva det själv på, hm, nåja, ganska snabbt tror jag. Fast kanske inte. Kommersiell inbyggd mjukvara kostar mellan 150 och 300 kronor per rad. Och 4000 rader skulle kunna kosta närmare en miljon att designa, koda och testa. Mycket pengar hur man än räknar. Jag är dock krass när det gäller återanvändningen eftersom den lilla mängd kod som är till salu (t.ex. för RTOS) gör att procent av användarna väljer att skriva sin egen kod. Kanske den rätt så färska fokuseringen på Open Source kan få utvecklarna att sluta skriva så mycket av koden själva? En strimma av hopp: numera frågar folk var de kan hitta en TCP/IP-stack istället för att börja skriva en egen. Jag har bland annat sett folk slita stackar ur Linux. Kanske detta förebådar framtida framgång? Open Source och kvaliteten På en konferens om inbyggda system i september diskuterade paneldeltagarna för- och nackdelar med Open Source jämfört med kommersiell programvara. Som alltid hade båda sidor tunga argument. Det övertygade mig om att det finns gott om plats på marknaden för alla typer av licensieringssystem. Men en publikfråga fångade mitt intresse. Hur kan jag lita på er öppna källkod i min säkerhetskritiska applikation när vem som helst får göra ändringar? Detta är ett ganska intressant motargument mot synsättet att ju fler som ser på samma kod, desto högre kvalitet. Paneldeltagarna lyckades i bästa fall ge några tvetydiga svar, men inget som gav mig någon känsla av säkerhet. Efter att ha studerat en rätt ansenlig mängd Open Source slås jag av att det finns en så stor mångfald av olika sätt att koda, skriva kommentarer (eller snarare att inte göra det) och inställningar till att skriva mjukvara i stort. Mycket av källkoden är rent ut sagt hemsk, även om den fungerar. En del är rena konstverk. Hur kan man garantera kvalitet med en sådan spridning? Testning är visserligen avgörande för alla kontrollprocesser, men det räcker inte för att garantera att resultatet fungerar. Kvalitet börjar med en bra specifikation och design, upprätthålls genom strikta kodningsregler och granskningar samt bekräftas av rigorösa tester som är lika ordentligt designade som själva mjukvaran. Kan vi vara säkra på att den senaste fixen till exempelvis Linux uppfyller alla dessa krav? Grubblandes över detta intressanta dilemma ställde jag samma fråga till en Linux-leverantör. Hans svar var lika klokt som överraskande (överraskande eftersom mässan vimlade av företag som framhöll Linux som lösningen på alla inbyggda behov, från Internetanslutna brödrostar till smarta tavelramar). Glöm Linux för säkerhetskritiska applikationer, sade han. Det är inte certifierat enligt någon standard, och är så komplext att det nog aldrig blir det. Jag är ingen Linux-guru själv, så jag kan inte avgöra hur sant detta är, men eftersom det sades av en leverantör låter det som en varningsklocka för applikationer där hög driftsäkerhet är ett måste. 8 Nr 4 december 2002

9 Den självklara slutsatsen är att vi behöver olika verktyg för olika behov. Men jag kan inte hjälpa att undra om detta är ett inneboende problem för skapandet av kvalitetskod baserat på Open Source. Standardiserade sätt att skriva behövs Om det är något som den här branschen behöver, så är det att lära sig att alltid arbeta disciplinerat. Det innebär flera saker, inklusive att införa standardiserade sätt att skriva kod på. Dagens kaos kommer från hundratals av oberoende utvecklare som alla följer sina egna tillfälliga (eller obefintliga) stilar, standarder, procedurer och metoder. Det går att skriva begriplig C-kod, men det är inte vanligt att programmerare använder en ordrik, lättbegriplig stil. C erbjuder kryptiska genvägar som motverkar tydligheten, och de används ofta. Open Source skulle stärkas kraftigt om det fanns en instans som krävde att alla inlämnade arbeten uppfyllde vissa standarder samt åtföljdes av designdokument och planer/kod för testning. En respekterad övervakningsinstans för kodkvaliteten skulle säkerställa att allt som lämnades in var så nära perfektion som bara är möjligt. Fast någon måste ju betala denna person eller organisation för att göra jobbet. Så vitt jag kan bedöma lider så gott som samtliga som skriver egen mjukvara av samma problem. Praktiskt taget ingen tillämpar en disciplinerad utvecklingsprocess. Standarder för inbyggd mjukvara, i den mån sådana finns, ignoreras alltid. Testplaner tenderar att dyka upp som den sista heroiska insatsen, inte som ett resultat av en i förväg genomtänkt design. Jag förvånas ständigt av att så få programmerare av inbyggd mjukvara känner till vilka metoder som branschen har tagit fram för korrekt utveckling av komplexa system. Ett exempel är Capability Maturity Model ( En modell som är ökänd för att vara svår och dyr att implementera. Men den rymmer mycket vishet som vi alla borde ta del av. Slutsatser En av paneldeltagarna som förespråkade kommersiell programvara berättade att han faktiskt ofta använder GNU-verktyg när han bygger en ny kompilator eller liknande. Han utnyttjar öppna koddelar, till exempel en kodgenerator, för att snabbt få ihop sin egen produkt. Sedan skriver han ersättningar för de delar som han tog från GNU tills hela produkten är hans egen. Men innebär inte detta att GNU:s GPLlicens smittar den egna koden? Om applikationen är 50 procent GNU och 50 procent egen, antar jag att det innebär att applikationen måste följa reglerna för GPL. Den måste släppas som en Open Source. Men allteftersom kodningen går vidare och all GNU till slut är borta, är då hela kodbasen verkligen Open Source? Drivet till sin spets, hur kan man vara säker på att kod som hämtats från en annan applikation inte har smittats? Behöver vi tillgripa renrumsmetoder? Är svaret ja, kan vi glömma återanvändning. Open Source ger en massa skickliga programmerare möjlighet att hitta och åtgärda problem. De förstår vad som händer mycket mer i detalj än om de skulle använda komponenter av typen svarta lådor och kan i värsta fall lita till sig själva för support. Men precis som i fallet med copyrightskyddad mjukvara, kan de som arbetar med inbyggda system finna sig inlåsta med en gammal version av en Open Source mjukvara (eftersom inbyggda system verkar ha hur lång livslängd som helst och kräver underhåll i decennier). Det finns ingen garanti för att koden är tillräckligt bra eller att någon kompetent programmerare har tagit sig tid att gå igenom den. Open Source har klara fördelar för användarna och de företag som vet vad de gör. Kommersiell programvara är bra för leverantörerna, och i vissa fall även för användarna (jag tänker bland annat på att hålla bra säkerhetskritisk kod säker). Jag kan inte hjälpa att undra om marknadens fåtaliga aktörer verkligen inte kan få alla fördelarna från Open Source utan att deras verksamheter drabbas. Kanske skulle lösningen i Microsofts antitrustmål vara att kräva att Windows inordnades under någon av modellerna för Open Source. Microsoft skulle fortfarande kunna tjäna enorma pengar på produkten, men med tusentals miljontals ögon som letar buggar till gagn för användarna. Jack Ganssle ser som sin livsuppgift att hjälpa utvecklare att förbättra inbyggda system. Du kan gratis prenumerera på Jack Ganssles månadsbrev på Nr 4 december

10 AV SVEN WENNERSTRÖM Fri programvara valdes till vägtullsystem När Combitech Traffic Systems bytte ut hårdvaran till en standard-pc i en del av vägtullen de tillverkar, öppnade sig nya möjligheter att se över mjukvaruarkitekturen. Efter en teknisk utvärdering och en juridisk utredning föll valet på Linux och fri programvara. När en bil susar igenom en automatiserad vägtull är det mycket som ska hända på kort tid. Bilister med en transponder monterad innanför vindrutan kan i full fart köra rakt igenom tullen. Tullstationen består av en båge gantry över vägbanan och strax innan bilen kommer fram skickas en mikrovågssignal som transpondern i bilen reagerar på. Om vägtullens system får tillbaka en godkänd signal från bilen, debiteras kundens konto. Om bilen som åker genom tullen däremot inte är utrustad med transponder, ska bilen ändå registreras och identifieras. Systemet för VDC Vehicle Detection and Classification träder då i kraft. Framför gantryn sitter kameror i bågar som sträcker sig ut över vägbanan. Kamerorna sitter två och två och ur stereobilderna som registreras beräknas fordonets storlek, höjd och position. När fordonet har nått en given position, tar en lägre monterad kamera en bild av fordonets registreringsskylt. Bytte till Linux Fram tills nyligen har VDC-systemet körts i en miljö speciellt anpassad för realtidstillämpningar. Inför en ny version av tullsystemet, fattades beslutet att överge den dåvarande hårdvaruplattformen för att istället övergå till att använda en standard-pc. Bytet öppnade för flera olika mjukvarualternativ och till slut föll valet på att använda Linux som operativsystem i VDC-systemet. Bo Balder, som är ansvarig för utvecklingen av VDC-systemets programvara, förklarar varför valet föll på Linux: Valet stod mellan att använda Linux eller ett renodlat realtids-os. Det var den tekniska utvärderingen av systemen som blev avgörande. Linux uppfyllde alla de tekniska krav vi ställde på plattformen och var dessutom bättre lämpat än konkurrenterna på att hantera våra grafiska funktioner. Den Linuxdistribution som Combitech Traffic Systems använder kommer från RedHat. På marknaden finns även realtidsanpassade versioner av Linuxkärnan, men Combitech Traffic Systems har valt att inte använda en modifierad variant av kärnan. Systemets prestanda är ändå fullt tillräckliga. Kompletterade med juridisk genomgång Den tekniska utvärderingen kompletterades också av en juridisk genomgång av den licens som Linux omfattas av: GNU GPL (General Public Licence). Licensen är omfattande och innehåller även skrivningar om programvara som länkas till GPL-licensierade program. Vi var osäkra på vilka konsekvenser GPL-avtalet skulle få för oss, förklarar Bo Granstedt, projektledare för VDC. Skulle vi till exempel bli tvungna att publicera vår källkod? För att reda ut frågorna kring licensen, anlitades en advokatbyrå som fick gå igenom GPL-avtalet. En av avtalets konsekvenser var att drivrutinen för instickskortet som fångar bilderna från kamerorna skulle släppas fri, eftersom den länkas till Linux-kärnan. Att släppa delar av koden fri ingår inte i företagets affärsidé, säger Bo Granstedt. Att programvaran omfattas av GPL-licensen är absolut ingen fördel för oss. I de drivrutiner som vi publicerat, har vi sett till att det inte finns något av det som vi anser skapar värde i produkten. Fördel att själva vara i framkant Förutom Linuxkärnan innehåller VDC-systemet också andra fria programvaror, bland annat ACE. ACE är en fri kommunikationsplattform som också innehåller en CORBAimplementation. I utvecklingsarbetet med VDC-systemet använder Combitech Traffic Systems alltid den senaste versionen av ACE Bo Granstedt och Bo Balder på Combitech Traffic Systems framför ett av företagets vägtullsystem. som hämtas ur det fritt tillgängliga kodträdet. Utvecklarna på Traffic Systems har också bidragit till ACE-koden genom att skicka in felrättningar som gjorts i koden. Att istället för att arbeta mot det publika kodträdet sampla koden och underhålla den själv anser Bo Balder är onödigt arbete. Dessutom anser Bo Balder att det finns en fördel med att hålla sig så långt fram som möjligt i utvecklingen av fri programvara: För nyutvecklad fri programvara och för de senaste versionerna är det betydligt lättare att få support än för de äldre versionerna. Det finns ofta gott om information på nätet, i diskussionsforum och e-postlistor. För vissa fria program finns också en marknad för kommersiell support. ACE är till exempel en vitt spridd programvara, med god tillgång till dokumentation och litteratur. På samma sätt är det med Linux; flera företag lever på att sälja Linuxsupport och ibland också support på annan fri programvara. Att på det viset tjäna pengar på fri programvara strider inte mot licensavtalen. Linux och fri programvara som plattform ser både Bo Balder och Bo Granstedt positivt på. Fri programvara används inte bara i målmiljön utan även i utvecklingsmiljön. Verktyg som make och GNU-kompilatorerna är flitigt använda utvecklingsverktyg som håller mycket hög kvalitet. Vi är helt klart nöjda med Linux och ACE som plattform, avslutar Bo Granstedt. 10 Nr 4 december 2002

11 Nr 4 december

12 AV JERRY EPPLIN GPL-licensierad mjukvara i inbyggda applikationer Copyright 2001 DeviceForge LLC.Artikeln är publicerad med tillstånd av LinuxDevices. Ursprungligen publicerad på LinuxDevices.com, med namnet Using GPL software in embedded applications. På Wind River är man bekymrade! I en artikel i Integrated Communications Design intervjuade Mike Downing nyligen Curt Schacker, vice vd med ansvar för marknadsföring på Wind River Systems. I intervjun utrycker Schacker sin oro för att juridiska tveksamheter kring GPL ska hindra utvecklingen på området inbyggd, öppen mjukvara. I Schackers hypotetiska resonemang väljer ett företag som tillverkar Ethernet-switchar, och har Linux som plattform, att inte släppa koden under GPL, eftersom den representerar merparten av produktens tekniska innehåll och värde. Eftersom GPL inte har prövats rättsligt menar Shacker att det hypotetiska företagets projekt kan vara i fara. Tänk dig att en domstol en dag beslutar att all mjukvara som du har utvecklat faller under GPL och nu är att betrakta som allmän egendom, säger han. Skrämselförsök eller verkligt hot? Det finns de som hävdar att Schacker cyniskt sprider rädsla, osäkerhet och tvivel kring en plattform (Linux) och utvecklingsmodell (Open Source) som utgör ett hot mot hans eget företag. Själv föredrar jag att tro att han verkligen är mån om alla som använder Linux i inbyggda applikationer. Därför ska jag göra mitt bästa för att stilla hans oro. Till att börja med kan det vara värt att notera att om Wind River nu är så oroade för GPL, så är detta något helt nytt. Genom åren har företaget utvecklat ett antal GPL-licensierade mjukvarupaket. Jag drar mig till minnes att jag använde, och betalade en rejäl slant för, deras GDBbaserade debugger i mitten av 90-talet. Wind River verkade före många andra leverantörer ha upptäckt fördelarna med att använda, modifiera och sälja mjukvara under GPLlicens. Om Wind River verkligen är så oroade över rättsläget för GPL kan man fråga sig varför de har lagt så stora resurser på att modifiera och marknadsföra GDB som produkt. Vi kan bara anta att andra, med undantag för Schacker, menar att GPL skyddar Wind Rivers rätt att marknadsföra deras modifierade produkter och att det finns åtminstone någon juridisk grund till detta. Fördelarna med ren GPL I den utsträckning det finns några restriktioner, gäller dessa bara mjukvara som inte faller under GPL. När kod publiceras under GPL blir rättsläget ganska enkelt vem som helst får modifiera och publicera i stort sett vad som helst. Det är det som är avsikten. Linux utvecklades och förblir en produkt av de som tror på öppen mjukvara. Det borde inte komma som någon överraskning att de, efter att ha investerat stort i Open Source, vill att de som drar nytta av deras arbete också bidrar. Mycket av Linux framgångar beror på den gradvisa uppbyggnaden av funktionalitet och mogenhet, genom alla användares samlade bidrag. När du publicerar din kod upphör alla restriktioner för hur Linux får användas, vilket har avgörande praktiska fördelar. Så det stämmer verkligen inte att GPL hindrar utvecklingen på området inbyggd, öppen mjukvara. I den mån det finns några hinder gäller dessa kommersiell programvara. Men för att mer direkt stilla Schackers oro kan det vara på plats med en genomgång av GPL och dess implikationer för Linux. Relationen mellan Linux och GPL Linux kan anses ha tre huvudlicenser GPL. Ett anmärkningsvärt klart och välskrivet dokument som jag rekommenderar alla att läsa. Det är inte heller svårt att sammanfatta innehållet. Du får modifiera, kopiera och distribuera mjukvara under GPL, förutsatt att du även licensierar det härledda arbetet under GPL och publicerar källkoden. Villkoren är klara och tydliga: Du får använda GPL-licensierad kod som utgångspunkt för ny och modifierad mjukvara, men du får inte vägra andra samma villkor som du fick när de vill använda din mjukvara som utgångspunkt för sitt arbete. Det är också viktigt att notera att du får använda och modifiera GPL-licensierad kod för eget internt bruk utan att be om lov eller meddela någon det är först när du distribuerar resultatet som reglerna träder i kraft. Det enda problemet är vad som menas med härlett arbete. När modifierar du kod och när skapar du något helt nytt? Om du till exempel redigerar emacs källkod och lägger till ytterligare en funktion, och kallar resultatet för myemacs, råder det knappast någon tvekan om att du har skapat ett härlett arbete. Men vad gäller om du är applikationsleverantör och kör programmet över ett nätverk? Eller kontrollerar det genom någon sorts interprocesskommunikation såsom CORBA? Flera komplicerade fall har dykt upp sedan den andra versionen av GPL släpptes, vilket Free Software Foundation försöker lösa med GPL Version 3. Men sådana fall är fortfarande ganska sällsynta och det normala är att ett härlett arbete är en direkt modifiering av, eller länkat till, originalarbetet. Ditt arbete är ett härlett arbete om det vid exekveringen länkas till ett GPLarbete. Det spelar ingen roll om länkningen är statisk eller dynamisk, så användning av ett GPL-licensierat delat bibliotek skapar ett arbete som är härlett från biblioteket. LGPL. Även kallat Lesser GPL eller Library GPL. Arbeten licensierade under LGPL är vanligtvis byggda som bibliotek som kan länkas till copyrightskyddad mjukvara. LGPL är viktig för Linux eftersom GNU C Library (Glibc) är licensierat under den. Glibc, ett delat bibliotek som följer med de flesta Linux-system, tillhandahåller gränssnittet mellan nästan alla Linux-baserade applikationsprogram och kärnan. Glibc implementeras vanligtvis som ett delat bibliotek, vilket innebär att en applikation länkas till det när den laddas. Applikationerna anropar Glibc-funktioner, 12 Nr 4 december 2002

13 vilka sedan kör systemanrop i Linux-kärnan. Eftersom applikationer i användarrymden bara är länkade till Glibc, och inte direkt till kärnan, omfattas de inte av Linux-licensen. Linus har publicerat ett klarläggande om GPL. Linux-kärnan är licensierad under GPL, men med följande klarläggande: Denna copyright omfattar inte användarprogram som använder kärnfunktioner via normala systemanrop detta anses bara vara normal användning av kärnan som inte betraktas som härlett arbete. Uttalandet klargör att program i användarrymden inte anses vara härledda från Linux. Detta tolkas ibland som att det är tillåtet att använda copyrightskyddade kärnmoduler. Mjukvara i fem klasser Med utgångspunkt från ovanstående kan vi identifiera fem klasser av mjukvara inom ramen för Linux och försöka att avgöra vilken sorts licensiering som krävs för dessa Applikationer som körs i användarrymden under Linux. Laddbara drivrutiner som använder normala kärngränssnitt. Laddbara moduler som använder kärngränssnitt som inte är standard. Fristående kärnmoduler. Modifiering av själva Linux. Låt oss nu titta på var och en av dessa Applikationer som körs i användarrymden under Linux Den första klassens status är entydig. I princip kan varje applikation i användarrymden copyrightskyddas, förutsatt att den inte är härledd från en GPLlicensierad produkt. Det förklarar varför så många av de stora programföretagen, bl.a. Oracle, har släppt Linux-versioner av sina copyrightskyddade produkter. Knappast någon hävdar att bara för att ett program körs under Linux skulle det medföra skyldighet att licensiera mjukvaran under GPL. Denna slutsats understryks även av Linus GPL-klarläggande. Modifiering av själva Linux På liknande sätt är det helt klart att modifieringar enligt den femte klassen faller under GPL. Tar du källkoden till Linux, modifierar den och kompilerar resultatet till en ny kärna, får du ett arbete som är härlett från Linux, och som också är licensierat under GPL. Laddbara drivrutiner som använder normala kärngränssnitt Status för laddbara drivrutiner är inte fullt lika klar. Laddning av en modul är i allt väsentligt en form av dynamisk länkning när modulen är laddad är den länkad till kärnan och filer länkade till GPL-kod måste också vara GPL-licensierade. Det kan därför hävdas att kärnmoduler, såsom drivrutiner, måste vara GPL-licensierade. Men Linus har sagt att det är OK med copyrightskyddade drivrutiner som använder normala gränssnitt mellan sig och kärnan. De som utvecklar kärnan har hela tiden stött denna tolkning genom att tolerera, om än motvilligt, användningen av copyrightskyddade drivrutiner till hårdvaran. Detta tolererande av copyrightskyddade drivrutiner går långt tillbaka och rader av hårdvarutillverkare är beroende av detta. Men vissa kärnutvecklare har ifrågasatt Linus rätt att utfärda detta undantag från GPL. Det kan lugnt hävdas att praktiskt taget ingen av Linux copyrightinnehavare är särskilt förtjust i rent binära drivrutiner så du bör välja denna väg först efter moget övervägande. Laddbara moduler som använder kärngränssnitt som inte är standard Den tredje klassen är den mest problematiska för kommersiell programvarukod. När en Nr 4 december

14 modul väl är laddad blir den i allt väsentligt en del av kärnan. Det går i princip att modifiera Linux för att skapa ett specialgränssnitt till en modul, släppa denna modifierade Linux enligt GPL såsom krävs, och sedan skriva en copyrightskyddad laddbar modul som använder kärngränssnittet du skapade. Resultatet blir i allt väsentligt en egen, skyddad version av Linux helt i strid med GPL:s anda och väl utanför Linus undantag för drivrutiner. Fristående kärnmoduler Kärnmoduler är ganska flexibla och finns för en lång rad användningsområden. De används ibland för syften som är rätt oberoende av kärnans funktionalitet. Applikationer för RTLinux är ett exempel de modifierar inte kärnan på något som helst sätt, utan är bara applikationer som körs i kärnrymden. Detta är den fjärde klassen av Linux-applikationer de som inte använder något av kärnans funktionalitet. Dessa skulle förmodligen kategoriseras på samma sätt som drivrutiner för standardgränssnitt, eftersom det kan hävdas att en modul som inte har något gränssnitt till kärnan inte heller har något gränssnitt som inte är standard. Använd huvudet Trots Schackers oro är det egentligen inte så komplicerat att utveckla för Linux, sett ur licenssynvinkel. Tro det eller ej, men det räcker oftast med vanligt bondförnuft. Använd till exempel inte kärnmoduler som ett sätt att komma förbi Linux copyright. Om du i allt väsentligt implementerar en modifiering av Linux, ska du släppa den under GPL. Erfarenheten visar att det är ganska osannolikt att du får några problem med Linux copyrightinnehavare om du håller dig inom ramen för GPL. Vill du oroa dig för juridiska frågor, kan du oroa dig för det minfält av mjukvarupatent som finns där ute, och som bara blir värre för varje år som går. Kom ihåg att Linux copyrightinnehavare lär ha vad som krävs för att bekämpa missbruk av deras copyright. Men det är mycket troligare att du stäms av någon processlysten, royaltyhungrig patentinnehavare än av exempelvis Linus. Välstrukturerad programmering underlättar Hur som helst, korrekt mjukvarudesign ifrågasätts alltid vid minsta tveksamhet. Användningen av kärnmoduler bör reserveras för lågnivåhantering av hårdvara, med funktionalitet på högre nivå implementerad genom program i användarrymden. Känslig immateriell egendom släpps sällan som lågnivåkod. Men om mervärdet ligger i mjukvaran är denna vanligtvis så avancerad att den ändå bör implementeras i användarrymden. Glöm inte att operativsystemets roll är att tillhandahålla generella tjänster åt alla applikationer applikationsspecifik kod hör inte hemma här. Om din applikation behöver generell OS-funktionalitet som Linux saknar i dag, varför inte lägga till den i kärnan och bidra till den öppna kodbasen? Men om vi talar om inbyggda applikationer då? Inget av det ovanstående förändras för inbyggda applikationer. Den sortens mjukvara är mycket närmare kopplad till operativsystemskärnan än de mer klassiska applikationerna, hävdar Schacker. Nej, reglerna för modulär mjukvarudesign gäller fortfarande. Vill du ha begriplig mjukvara som går att underhålla ska du låta kärnan vara, placera koden för lågnivåhantering av hårdvaran i drivrutiner och applikationernas funktionalitet i användarrymden. Problemet med copyrightskyddade drivrutiner Ett annat problem med copyrightskyddade drivrutiner gäller underhåll. Det binära gränssnittet mellan kärnan och en drivrutin varierar ofta mellan olika versioner av kärnan. I de flesta fallen kräver detta inga förändringar av källkoden, utan det räcker med en omkompilering för att använda en gammal drivrutin med en ny kärna. Om du å andra sidan använder hårdvara från tredje part med copyrightskyddade binära drivrutiner, är det troligt att dessa inte fungerar när du uppgraderar kärnan. Hårdvarutillverkarna måste då ta fram nya binära drivrutiner för varje version av kärnan. Med jämna mellanrum klagar de hårdvarutillverkare som inte lämnar ut sina drivrutiners källkod över att kärnutvecklarnas ändringar i kärnan medför problem för deras binära drivrutiner. Du kan vara lugn för att dessa vädjanden inte väcker någon sympati hos kärnutvecklarna svaret blir undantagslöst: Fram med källkoden, eller stick. Huvudbudskapet är att du ska undvika rent binära drivrutiner från tredje part. Och om du säljer hårdvara ska du tillhandahålla källkoden till dina drivrutiner. Detta är en praktisk fråga som inte har något med licenser att göra. Det gäller även de som utvecklar inbyggda system, om än i något mindre utsträckning eftersom inbyggda system tenderar att ge större kontroll över vilken kärna som används och dessutom är stabilare över systemens livstid. Slutsats För att sammanfatta, är GPL-licensieringen av Linux sällan ett problem för inbyggda applikationer. I de flesta fall ligger produktens tekniska innehåll antingen i hårdvaran eller i mjukvaran på applikationsnivå och båda dessa kan copyrightskyddas. Å andra sidan kan det finnas ett fåtal situationer där utvecklarna vill skydda sin kod på drivrutinsnivå. I dessa fall måste utvecklarna (eller företagen) övertyga sig om att dynamiskt länkade binära drivrutiner faktiskt inte behöver vara GPL-licensierade eftersom detta hamnar i något av en gråzon med hänsyn till Linux GPL-licens. Men innan det går så långt föreslår jag att du tänker om. Är det verkligen nödvändigt att lägga copyrightskyddad funktionalitet i en kärnmodul eller i en modifiering av kärnan själv? Om det är det, skulle det verkligen skada ditt företag om du delade med dig av 14 Nr 4 december 2002

15 denna nya funktionalitet till alla? I de flesta fall är svaret att det nog skulle gynna både ditt företag och Linux-världen. Frågor och svar om GPL från utvecklare av inbyggda applikationer Följande frågor och svar är tänkta att förekomma möjliga frågor från utvecklare, varav inte alla är erfarna Linux-programmerare, kring några av de viktiga punkter som den här artikeln tar upp F: Jag ser ofta termerna modul och drivrutin användas mer eller mindre som synonymer. Kan du reda ut begreppen? S: Moduler är all kod som kan laddas till kärnan med hjälp av insmod eller andra kommandon. Att ladda en modul är i allt väsentligt samma sak som att länka den dynamiskt till kärnan den blir en del av kärnan i samma ögonblick. En drivrutin är en modul som använder ett visst gränssnitt som låter applikationer läsa, skriva och utföra andra filrelaterade operationer. Det finns dock drivrutiner som inte är moduler se nästa fråga. F: Jag har hört termerna dynamisk och statisk användas för att beskriva Linux drivrutiner och moduler, och att den ena typen inte behöver vara GPL-licensierad i Linux. Kan du förklara de två termerna? S: I Linux är det möjligt att kompilera drivrutiner direkt för kärnan. Dessa kompileras då tillsammans med kärnan, länkas med denna och laddas samtidigt som kärnan laddas. Denna modell används för enheter som alltid ska vara tillgängliga, till exempel drivrutiner till nätverkskort i datorer som alltid ska vara nätverksanslutna. I detta fall är drivrutinen alltid tillgänglig i kärnan. Dessa drivrutiner kan kallas statiska, eftersom de är statiskt länkade till kärnan. Och eftersom de är statiskt länkade till Linux, måste de även vara GPL-licensierade. Linux stödjer även dynamiska drivrutiner som laddas vid behov (till exempel med kommandot insmod ). När de har laddats är det egentligen ingen skillnad mellan dessa och de statiska drivrutinerna de uppträder på samma sätt och har samma funktionalitet. En del drivrutiner kan användas på båda sätten. När du konfigurerar kärnan kan du till exempel ange att CDROM-drivrutinen alltid ska vara laddad (statisk drivrutin) eller att den bara ska laddas vid behov (dynamisk drivrutin). Dynamiska drivrutiner kan spara minne eftersom de bara laddas om de behövs. Vissa av Linux copyrightinnehavare menar att båda typerna ska vara GPL-licensierade, eftersom det inte finns någon verklig teoretisk skillnad mellan statiska och dynamiska drivrutiner. Men Linus har infört ett undantag som bara gäller för dynamiska drivrutiner. F: Som jag förstår det har Linus uttryckligen tillåtit användning av copyrightskyddade (ej GPL-licensierade) dynamiskt laddbara moduler (såsom drivrutiner och annan fristående kod) under Linux, trots att GPL normalt kräver att enbart GPL-licensierad kod används, i antingen statiska eller dynamiska drivrutiner/moduler. Stämmer detta? S: Detta hävdas från flera håll, men kräver ett visst förtydligande. Linux informationsfiler innehåller texten till GNU General Public License (GPL), och inleds med en kommentar som innehåller en formulering (citerad i denna artikel) som medger användning av ej GPL-licensierade användarprogram som använder kärnfunktioner via normala systemanrop. Det är dock inte klart om denna formulering även omfattar kärnmoduler den verkar bara klargöra vad som gäller för mjukvara i användarrymden. Så vitt jag kan bedöma har Linus undantag för ej GPL-licensierade moduler bara kommunicerats på andra sätt än genom Linux copyright. Han har till exempel vid flera tillfällen upprepat sitt medgivande att copyrightskyddade (dvs ej GPL-licensierade) moduler tas med på utskickslistan för kärnan. F: Kan du ge mig ett rakt svar på frågan om jag får använda en copyrightskyddad (dvs ej GPL-licensierad) modul i Linux? S: Nej, det kan jag inte. Jag tror att det finns anledning att gå försiktigt fram. En strikt tolkning av GPL-villkoren säger att det inte är tillåtet att släppa några copyrightskyddade kärnmoduler, inklusive drivrutiner. Och vissa av Linux copyrightinnehavare menar att tolkningen ska vara strikt. Jag tror visserligen inte att någon någonsin kommer att bli stämd för att ha släppt copyrightskyddade Linux-drivrutiner, men man kan inte vara säker på detta. Jag misstänker att copyrightinnehavarna föredrar att lämna frågan öppen, eftersom detta får till följd att avskräcka från spridning av rent binära (ej GPL-licensierade) moduler. Jerry Epplin har skrivit inbyggd mjukvara de senaste femton åren, främst för medicinsk-teknisk utrustning. Han kan kontaktas via jerry@linuxdevices.com. Nr 4 december

16 AV SVEN WENNERSTRÖM Fri programvara kortade utvecklingstiden När Kreatel började utveckla en avancerad set-top-box för bredbandstjänster, var det viktigt att snabbt ta fram en fungerande prototyp att visa upp för kunder och investerare. För att korta utvecklingstiden och kostnadseffektivt uppfylla alla tekniska krav valde Kreatel att använda Linux och annan fri programvara i sin produkt. Bredbandsnäten runt om i världen växer sakta men säkert, trots att det inte längre råder samma optimism som för ett par år sedan. I de nya bostadsnät som byggs vill operatörerna utöka antalet tjänster som kunderna kan köpa. Internetåtkomst är bara en liten del av allt som operatörerna vill använda sina nät till, förklarar Joakim Delbom som är utvecklingschef på Kreatel. Först ut av de nya tjänsterna är underhållning som teve, film och musik. För att få tillgång till tjänsterna har Kreatel utvecklat en lösning där kunderna utrustas med tunna klienter i form av set-top-boxar. Boxarna kommunicerar med en centralt placerad server som nätoperatören driver. Eftersom det är underhållningstjänster det handlar om är teven en mer naturlig anslutning än datorn, säger Joakim Delbom. Dessutom är det fler hushåll som har teve än dator. Boxen från Kreatel ska inte upplevas som en dator, gränssnittet påminner om det i en teveapparat och ingen installation mer än att sätta i sladden behövs. Men under huven på Kreatels boxar finns en vanlig X86-kompatibel PC, med komponenter för MPEG-avkodning integrerade med processorn. All programvara som boxen använder hämtas från servern. Använder Linux Bredbandsboxarna började utvecklas För att locka investerare och kunder var målet att snabbt kunna visa upp en fungerande prototyp. För att undvika ett långsamt och dyrt utvecklingsarbete användes i så stor utsträckning som möjligt fri programvara För att snabba på utvecklingen av en fungerande prototyp använde Kreatel fri programvara till bl a operativsystemet i sin set-top-box för bredbandstjänster. som fanns tillgänglig på Internet. Som operativsystem valdes en bantad variant av Linuxkärnan och för den grafiska presentationen används Mozilla, den fria vidareutvecklingen av Netscape. Kravet på att utvecklingen av programvara till boxen ska gå snabbt kvarstår. Operatörerna vill kunna lägga till stöd för nya tjänster och nya lösningar för till exempel kontroll över distribution och användning av tjänsteinnehållet, digital rights management, vilket gör att boxens programvara hela tiden måste kunna hållas uppdaterad. För att möta kraven används en komponentbaserad arkitektur kallad TOA, Terminal Open Architecture. Var och en av komponenterna har en väl definierad uppgift och gränssnitt mot andra komponenter. Komponenternas gränssnitt bildar gemensamt TOI Terminal Open Interface. Applikationer som användaren möter, TIA, Terminal Interactive Application, skrivs mot TOI. API:erna finns tillgängliga även för tredjepartsutvecklare som vill utveckla applikationer. Den hårda uppdelningen och skiktningen av programvaran gör att varje komponent kan utvecklas och testas för sig. Utvecklarna kan välja om komponenten ska vara egenutvecklad, en fri programvara eller en inköpt komponent. Varje komponent granskas Sedan årsskiftet pågår en omfattande översyn av boxens programvara. Vi går igenom samtliga komponenter, säger Joakim Delbom. För varje komponent finns en komponentansvarig. I ansvaret ligger att undersöka vilka alternativ som finns till komponenten och att planera för utveckling och underhåll. Valet står mellan att själva utveckla programvaran, att använda fri programvara eller att licensiera en proprietär mjukvara. Förutom tekniska aspekter, måste även ekonomiska hänsyn tas. Boxen är en volymprodukt som är relativt priskänslig och valet av programvara får direkt genomslag på priset till slutkunden. Både genom utvecklings- och licenskostnader och indirekt genom att lösningarna ställer olika krav på hårdvaran i produkten. För närvarande har vi bara fri och egenutvecklad programvara i boxen, fortsätter Joakim. Tidigare har vi till exempel utvärderat om vi skulle byta ut Mozilla mot en kommersiellt tillgänglig webbläsare, men valet föll till slut på Mozilla av både tekniska och ekonomiska skäl. Ytterligare en aspekt på fri programvara som utvecklarna måste ta hänsyn till, är den uppsjö av olika licenstyper som omgärdar mjukvaran. Den ursprungliga versionen av Kreatels lösning omfattades av ett tjugotal olika licenser, som på olika sätt reglerade rättigheter och skyldigheter. Vad är värdeskapande? Vad gäller utbildning och underhåll anser inte Joakim Delbom att fri programvara som alternativ skiljer sig nämnvärt från egenutvecklad eller inköpt programvara. Kostnaderna är inte större jämfört med proprietära lösningar. Vi har aldrig haft behov av att ta in utomstående support på den fria programvaran. Vi har klarat oss med den information som finns tillgänglig på Internet, säger Joakim, och tillägger att moduler som fungerar problemfritt inte uppdateras eller förändras. Undantaget är Mozilla, vars utveckling kontinuerligt följs, eftersom det är en så pass viktig del av produkten. Kreatels utvecklare 16 Nr 4 december 2002

17 har också bidragit till utvecklingen av Mozilla genom att rätta felaktigheter i koden och publicera förändringarna. Användningen av fri programvara har fått oss att fundera på vad det är i vår produkt som är värdeskapande, säger Joakim. När mjukvaran är fri och tillgänglig för alla att hämta från nätet är det inte den vi kan ta betalt för. Istället är det vårt systemkunnande och vår arkitektur som går att sälja. Användandet av öppen källkod på Kreatel kom alltså underifrån: för att snabbt bygga en prototyp användes fria byggstenar. När arkitekturen formades kom den fria programvaran med som en naturlig och strategiskt viktig del, som på affärsmässiga grunder bedöms tillsammans med egenutvecklad och inköpt programvara. Nr 4 december

18 Nästa nummer Effektiv test i praktiken Dagens system blir allt mer distribuerade till sin natur. Det innebär att komplexiteten ökar markant. Dessutom ökar antalet externa gränssnitt i samma takt som systemen öppnar sig mot omvärlden. Därför blir det en allt större utmaning att hitta felen i dessa system och verifieringen tar allt längre tid. Vi har i allmänhet inte råd att ägna så mycket tid åt verifieringen som vi skulle önska. Av den anledningen måste vi välja vad vi ska verifiera och hur vi ska göra det för att få maximal effektivitet.vi måste också välja om vi ska använda någon typ av hjälpmedel eller verktyg som underlättar arbetet. En stor del av verifieringen består av tester på olika nivåer. Nästa nummer kommer därför att fokusera på hur man i praktiken väljer tester för att maximera effektiviteten. Kommer OnTime till rätt adress? Har du någon kollega som skulle vilja få ett eget exemplar av OnTime? Eller vill du själv ha tidningen skickad till en annan adress? Skicka i så fall ett till info@combitechsystems.com så ordnar vi det. Samma adress går även bra att använda om du vill bli struken från utskickslistan eller om tidningen går till en felaktig adress. 18 Nr 4 december 2002

19 Kursschema VÅREN 2003 Vårt utbildningssystem har skapats för att förmedla praktiskt yrkeskunnande. Därför är samtliga lärare även aktiva systemutvecklare med spetskompetens inom det område de undervisar i.vi känner till alla de situationer och små förtretligheter som faktiskt inträffar i verkligheten. Eva Holmquist, Senior System Engineering Consultant Teknikområde Kurs Antal dagar Linköping Stockholm Jönköping Göteborg Malmö Arkitektur Programvaruarkitektur, 2 4 feb 2 apr inbyggda system Mönster (design Patterns) 2 23 apr 12 feb Metodik Utveckling av realtidssystem 4 11 feb 13 maj 18 maj 20 maj 8 april med UML Workshop utveckling av 5 7 apr realtidssystem med UML Programmering C fortsättning 2 17 feb 24 mar 13 jan 7 apr och språk C Tillämpad programmering av realtidssystem 3 19 feb 26 mar 15 jan 9 apr C Grundkurs 3 8 apr 5 mar C++ Grundkurs 4 14 apr 4 feb QA, verifiering Test av programvara och system 2 12 mar 8 apr 6 maj 21 maj 12 feb och validering Granskningsteknik 2 29 jan 19 feb 5 feb 28 apr Granskningsteknik för 1 granskningsledare Konfigurationsledning av 1 3 apr programvara Mikrovågsteknik Grundläggande mikrovågsteknik 3 8 apr Ledarskap Projektstyrning av programvara 2 26 mar 12 feb

20 Avsändare: Box 1017, Jönköping B Porto betalt Inbjudan till OnTime-seminarium Tema: Open Source som konkurrensmedel i inbyggda system Tjänar vi något på och vågar vi använda Open Source-programvara i vår produktutveckling? Många företag ser fördelarna med att börjar använda Open Source men ställer sig samtidigt frågan: Vågar vi och vari ligger riskerna? Seminariet har som syfte ge en inblick i området samtidigt som vi förmedlar erfarenheter från företag som använt Open Source-programvara i kommersiella produktutvecklingsprojekt. Seminariet omfattar tre delar: - Den första delen omfattar en introduktion i området, samtidigt som vi fördjupar oss i kommersiella och legala frågeställningar som:vad vinner vi och vari ligger riskerna med Open Source? Vilka skyldigheter har vi som företag när vi använder Open Source-komponenter? Hur hittar jag Open Source-komponenter? Hur säkerställer man en långsiktig support? - I den andra delen berättar Axis Communications och Combitech Systems om sina erfarenheter från användning av Open Source-programvara i utvecklingsprojekt. - Till sist kommer Nohau Elektronik, Axis Communications och Combitech Systems att demonstrera ett antal kommersiella produkter relaterade till Open Source bl a Lineo Embedix SDK, Lauterbach TRACE32 med Linux awareness, AXIS Network Camera, AXIS Developer Boards, AXIS ETRAX Chip och StarFREC (en kombinerad CAN- och MOST flight recorder). Seminariet genomförs på följande orter: Malmö Göteborg Stockholm Linköping Lokal meddelas efter anmälan. Seminariet börjar kl och avslutas ca Vi bjuder på frukost mellan kl Anmälan till: ontime@combitechsystems.com, tfn eller fax Meddela, namn, företag, epost-adress, seminarieort samt om du kommer att delta på frukosten. Seminariet är kostnadsfritt, men anmälan är bindande. Var vänlig meddela om du får förhinder. Vi vill ha din anmälan senast Antalet platser är begränsat.