Föredraget på Internetdagarna 2010 som hölls av Daniel Stenberg, Björn Stenberg och Daniel Melin.

1. Att leva med Öppen Källkod

2. synvinklar
Licensen
Användare Producent

3. synvinklar
Daniel Melin
Björn
Stenberg
Daniel
Stenberg

4. Frågor
●
Klargörande? Avbryt!
●
Lite större? Frågestund i slutet!

5. Innehåll
●
Vad är öppen källkod?
●
Varför använda öppen källkod?
●
Drivkrafter
●
Strategier

6. Vad är öppen källkod?
●
Programvara öppen för...
●
granskning
●
ändring
●
vidaredistribution
●
Ibland med villkor

7. Varför välja öppen källkod?
●
Inga licenskostnader
●
Ingen leverantörsinlåsning
●
Full insyn
●
Full kontroll
●
“Köp svenskt”

8. Drivkrafter
●
Funktion
●
Prestanda
●
Teknisk elegans
●
Ära

9. Vanliga tankefel
●
“Kunder”
●
“Marknadsandelar”

10. Strategi: Uppgradering
●
Stanna på en fungerande version
eller
●
Uppgradera löpande

11. Stanna
●
“Pilla inte på det som funkar”
+ Enkelt
+ Billigt
- Kan bli jobbigt om man ändrar sig

12. Uppgradera
●
“Hänga med i utvecklingen”
+ Fixade buggar
+ Nya funktioner
+ Bättre prestanda
- Kostar tid
- Risk för regressioner

13. Strategi: Ändringar
●
Håll ändringar privata
eller
●
Donera ändringar

14. Håll ändringar privata
+ Enkelt och billigt på kort sikt
- Långsiktigt underhållsansvar
- Jobbigare uppgraderingar
- Tillåter licensen?

15. Donera ändringar
+ Underhållet överlämnas
+ Smärtfria uppgraderingar
- Andra har åsikter om ditt arbete
- Mer jobb initialt

16. Sammanfattning
●
Ett annat tankesätt
●
Mer frihet
●
Förstå licensen!

17. Juridik & öppen källkod
daniel.melin@kammarkollegiet.se

18. Vem är jag?
 Upphandlare på Kammarkollegiet
 Ansvarar bl.a. för upphandlingen ”Öppna
programvaror 2010”
 Hållit på med öppen källkod sen sent 90-tal
 Inte programmerare, inte jurist
 Stort intresse av immaterialrätt förutom öppen källkod
och LOU

19. Öppen eller stängd?
 En ”stängd” eller ”proprietär” programvara ger endast
användaren en nyttjanderätt men i princip inga andra
rättigheter.
 En ”öppen” eller “fri” programvara ger en mängd olika
rättigheter, vilka dessa är definieras av
programvarans licensvillkor.
 Alla licenser syftar till samma sak; definiera vilka
skyldigheter och rättigheter som hänger samman
med en viss upphovsrättsskyddad mjukvara.

20. Alla dessa licenser
 Två ytterligheter, BSD och GPL:
 BSD säger i princip ”Ta koden och gör vad du vill med
den, inklusive licensiera om den och stoppa in den i
proprietär programvara”.
 GPL säger i princip ”Ta koden och gör vad du vill med
den, men om du sprider koden till någon annan på
något sätt så måste du publicera koden”.
 Således kan BSD bli GPL men inte tvärtom.
 Således är BSD, men inte GPL, mer populär bland
proprietära leverantörer.

21. Öppen källkod och juridik
 Öppen källkodslicenser bygger på upphovsrätten där
upphovsmannen avsäger sig stora delar av sina
rättigheter.
 Generellt är patent och FRAND-villkor (Fair,
Reasonable And Non-Discriminating) oförenliga med
öppen källkod.

22. Öppen källkod och svensk rätt (1)
 Upphovsrättslagen är den legala basen.
 Att inte uppfylla villkoren i en öppen källkodslicens är
ett upphovsrättsintrång och inte att avtalsbrott.
 Ett öppen källkodsprogram som erbjuds utan
motprestation är att beteckna som ett benefikt avtal
( = gåva).
 Många lagar kan spela in beroende på
omständigheterna, t.ex. Upphovsrättslagen,
Avtalslagen, Köplagen, Konsumentköplagen,
Gåvolagen, Skadeståndslagen och
Distansavtalslagen.

23. Öppen källkod och svensk rätt (2)
 Klausuler som ”befintligt skick” eller ”as is” är inte
populära i svensk rätt och skulle sannolikt inte hålla i
en rättslig prövning.
 Köplagen kan sannolikt inte användas för att kräva
upphovsmannen bakom en öppen källkods-
programvara på något.
 Konsumentköplagen skulle kunna användas.

24. GNU GPL (General Public License)
 GPL kräver att källkoden görs tillgänglig för mottagarna
ifall upphovsmannen väljer att distribuera mjukvaran.
 Det går inte att licensiera om GPL-källkod.
 Om mjukvaran körs på en server och endast resultatet
av exekveringen tillgängliggörs för tredje part sker
ingen distribution enligt GPL. Källkoden till mjukvaran
behöver då inte göras tillgänglig.
 Modifikationer av mjukvaran för eget bruk behöver inte
göras tillgängliga för andra.

25. GPL
 Om en mjukvara distribueras i kompilerad form och den
innehåller delar licensierade under GPL så måste all
källkod som krävs för att kompilera programvaran
tillgängliggöras.
 Ett upphörande av distribution förändrar inget, all källkod
måste fortfarande tillgängliggöras.
 Den som distribuerar källkod får inte ställa några krav på
vad mottagarna gör med källkoden så länge GPL uppfylls.

26. GPL och AGPL (Affero GPL)
 Om upphovsmannen vill täppa till ”the ASP loophole” kan
AGPL användas.
 AGPL är identisk med GPL, men med tillagda klausuler
som reglerar att all källkod måste tillgängliggöras även om
distributionen endast innebär presentation av
exekveringen.

27. GPLv3
 Senaste versionen av GPL.
 En moderniserad version av GPLv2.
 Tydligare regler för inbyggda system.
 Helt omgjort gällande patent.
 Svagt intresse i början, men har snabbt accepterats.

28. GPLv3 och inbyggda system
 Om mjukvaran är inlåst i en krets och inte på något sätt
kan modifieras krävs endast tillgängliggörande av
källkoden.
 Om mjukvaran kan modifieras måste mottagaren av det
inbyggda systemet äga rätt att modifiera mjukvaran.

29. GPLv3 och patent
 Det är möjligt att distribuera källkod licensierad med
GPLv3 samtidigt som relevanta patent finns.
 Måste vara ”royalty free”, FRAND funkar inte.
 En patentlicens som ges till en mottagare måste
automatiskt utsträckas till alla potentiella mottagare.

30. Tack för mig!
daniel.melin@kammarkollegiet.se

31. curl, ett öppen källkodsprojekt
http://curl.haxx.se/

32. Agenda
En känsla av hur det kan fungera
En insikt i hur projektet tänker
Det är vanliga människor bakom
Du kan hjälpa till
Alla projekt är unika, det här är ett
exempel

33. Daniel Stenberg
●
öppen källkodshacker sedan
början av 90­talet
●
Leder 5­nånting öppen källkods­
projekt
●
Konsult på Haxx inom inbyggda
system

34. cURL
●
Ett projekt, två delar: curl och libcurl
●
Laddar data ner och upp
●
DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3,
POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET och TFTP
●
Lågnivå, folk bygger saker “ovanpå”
●
Finns med “överallt”
●
Historia från 1997
●
Mål: Vara det bästa “datatransfer­alternativet”

35. Företag
16 Software, Adara Networks, Adobe, Aditiva, Adknowledge, alaTEST, AOL, Apple, Archivas, ATX, Bietfuchs,
Bitcartel, Bloglines, Blue Digits, Blue Security, bwin, Candel Technologies, Canonical, Cascade Data Systems,
Carestream Health, CatchFIRE Systems, CERN, Cisco, Chronos, CLAAS Tractor SAS, Contactor Data,
Cybernetica AS,
Datasphere, Digium, EdelWeb, EFS Technology, Eiffel Software, Emsoft, Euroling, Eye­Fi, Facebook, F­Secure,
Friendfeed, FMWebschool, GRIN, Focuseek, Garmin, GipsyMedia, Google, Haxx, inSORS, IBM, Ideelabor, Idruna
Software, Infomedia Business Systems Division, Information Handling Services, Internet Security Systems, JET, Jlynx
Software, Kajala Group, Karelia, Kencast, Lassosoft, Linden Labs, Machina Networks, MandrakeSoft,
McAfee/Network Associates, MediaAnalys, Micromuse, MokaFive, Motorola, Neptune Labs,
Network Mail, Neuros Technology, Nortel, Office2office, Oktet Labs, One Laptop per child, On Technology,
OpenLogic, Optimsys, Oracle, Palm/HP, Panasonic, Pandigital, Polaroid Corporation, RBS, Retarus Network
Services, Rolltech, RSA Security, RSSS, SanDisk, SAS Institute, SEB, Siemens, Silicon Landmark, Sony, Source
Remoting, Spotify, Steambird, Sun, Swisscom, Symantec, System Garden, Tilgin, Toshiba Coroporation,
Tribalmedia, Tiempo de Espera, Visonsys, Vivisimo, Vmware, Voddler, Wump Research, Yahoo, Zimbra, Zixcorp
Med flera

36. Användare
●
En miljon nerladdningar per år
●
Miljoner användare
●
Hundratals företag
●
Hundratals öppen källkods­
produkter

37. Började litet
●
“vore bra men en grej som ...”
●
“inget som finns passar mig...”
●
“hur svårt kan det vara...”
●
“hej allihop, jag har gjort det här...”
●
“visst, skicka din patch bara...”
●
“release early, release often...”
●
drygt 100 000 rader kod idag, efter tolv år

38. Licenstänk
●
Så öppet som möjligt
●
Så fritt som möjligt för alla att använda till
vad som helst
●
Företagsvänligt
●
Det var en resa över de tidiga åren innan vi
landade hos...
●
BSD

39. Frivilliga
●
Inget företag stöder direkt
●
Alla är med som frivilliga på eget initiativ
●
Nästan ingen får betalt för att hacka curl
●
Utveckling, debugging, releaser, support
etc sker på fritid
●
De flesta som hackar curl är professionella
utvecklare någonstans

40. Versionshantering
●
En självklarhet
●
Distribuerad utveckling över
världen kräver det
●
All kod, allting, alltid publikt
●
CVS de första tolv åren, nu git

41. Litet core­team
●
En handful människor som hängt kvar
●
De får “pusha” commits till git
●
Alla får säga sin mening, reviewa patchar,
diskutera designs, posta patch etc
●
Över 800 listade bidragare
●
Väldigt få människor hänger kvar

42. Email tack
●
1000 pers på mailinglistan
●
Patchar tar vi helst via mail
●
Buggrapporter tar vi gärna per mail
●
Designdiskussioner sker alltid per mail
●
Frågor är bäst tagna på maillistan
●
Klagomål tas bäst på listan

43. Copyright
●
Individuella copyrights
●
Daniel har de flesta
●
Större ändringar berättigar till en
egen
●
Blanda inte ihop copyright med
licens

44. Vad går in ?
●
Push­rättighet == bestämmanderätt
●
Buggfixar går in
●
Nya features/funktioner måste diskuteras
●
Feature­creep måste bekämpas
●
Test­fall och dokumentation måste till

45. Releaser
●
Vi releasar ofta
●
I snitt var 60:e dag med 26 buggfixar per
release
●
Ett 20­tal personer bakom varje release
●
Vi släpper enbart kod. Binärpaket byggs av
folk och organisationer utanför projektet.

46. Test
●
Vi har en test­svit
●
Vi vill testa allt i den
●
Vi testar automatiskt hela tiden på massor med
plattformar
●
Vi sammanställer alla tester på sajten
●
Portabel automatisk test är svårt
●
Debugga avlägsna testfails är svårt
●
Ingen enskild person har alla target­miljöer

47. Supporta gamla releaser
●
Nä
●
Vi har svårt nog att hantera den
senaste releasen
●
Distros får hantera backports etc
●
Om någon betalade så vore det
förstås en annan sak...

48. Betala för en feature
●
Vi tar emot nya features och buggfixar på
samma sätt oavsett betalning
●
Att betala en existerande utvecklare i teamet
säkerställer att den nya funktionen eller
buggfixen görs på ett sätt som kan gå in
●
Projektet är ingen juridisk person och tar inte
emot betalningar
●
Personer i projektet gör som de vill

49. Säkerhet
●
Granskar alla ändringar
●
Testar alla ändringar
●
Stängd rapportera­säkerhets­problem email­
adress
●
Hanterar säkerhetsproblem enligt öppen
källkod “best practises”
●
Publicerar säkerhetsnotiser för alla säkerhetsfel
vi hittat eller fått rapporterat

50. Summering
●
Hur du kan jobba mot öppen
källkod
●
Hur licenserna fungerar
●
Hur ett öppen källkodprojekt
funkar

51. Frågor eller funderingar

52. Tack för oss
Björn Stenberg <bjorn@haxx.se>
Daniel Melin <daniel.melin@kammarkollegiet.se>
Daniel Stenberg <daniel@haxx.se>