Avoimen koodin hankkiminen / B2B ja JIT 2015 - Martin von Willebrand, puheenjohtaja

1. Avoin koodi pähkinänkuoressa
Avoimen koodin hankkiminen
Martin von Willebrand, puheenjohtaja

2. Avoin lähdekoodi
pähkinänkuoressa
• Avoin lähdekoodi eli vapaa ohjelmisto = ohjelmisto, jonka lisenssi
syrjimättömästi sallii käytön, tutkimisen, muokkaamisen sekä
kopioimisen ja levityksen. Voi olla muita ehtoja.
• Ohjelmisto, jonka käyttäminen on samojen lainalaisuuksien alainen
kuin mikä tahansa ohjelmisto:
– Hyviä ja huonoja
– Paljon käytettyjä ja vähän käytettyjä
– Pitkäikäisiä ja lyhytikäisiä
– Sopivia ja epäsopivia
– (Lisensioinniltaan selviä ja sekavia)
• Erityispiirre on avoimuus, joka on käyttäjälle plussa
Gilles Gonthier, CC BY 2.0

3. Avoin lähdekoodi
pähkinänkuoressa
Avoin lähdekoodi on:
•Madaltaa kustannuksia ja nopeuttaa tuotekehitystä, vaikka suljettuakin
•Kevyt yhteistyömekanismi yritysten välillä
•Tehokas ohjelmistokehityksen tapa tai ”metodi”
•Bisnesmahdollisuus
•Ohjelmisto, joka lisensioidaan avoimen lähdekoodin lisenssillä
Gilles Gonthier, CC BY 2.0

4. Avoin lähdekoodi
pähkinänkuoressa
• Compliance tarkoittaa oikein toimimista eli lakien noudattamista,
eettisiä toimintatapoja ja vastuullisuutta
• OSS Compliancen, eli oikein toimimisen kultainen sääntö
On noudatettava samanaikaisesti kaikkien sovellettavien
lisenssien vaatimuksia.
• Jos ei ole mahdollista, ei voi toimia niin.
 Toimintatapaa muutettava
• Käytännössä usein myös riskiarvioita
Gilles Gonthier, CC BY 2.0

5. Avoin lähdekoodi
pähkinänkuoressa
• Linux, linux-jakelut, GNU/Linux, Linus Torvalds
• Apache, voi tarkoittaa Apache Software Foundation, Apache
License (1, 1.1 ja 2), Apache http server
• Copyleft eli vastavuoroisuus (tarttuminen, periytyminen,
virusvaikutus)
• Heikko ja vahva vastavuoroisuus
– GPL, LGPL ja Affero GPL (AGPL)
– MPL
• Salliva eli permissiivinen lisenssi
– BSD, MIT, Apache ja lukuisat muut
• OS, OSS, FOSS
• ASP, SaaS
• DRM
Gilles Gonthier, CC BY 2.0

6. Lisenssejä,
luokittelua
• MIT, BSD, Apache – hyvin helpot (sallivat)
• MPL – helppo, huolellisuutta (heikko copyleft)
• LGPL – huolellisuutta, arkkitehtuuritarkistus (copyleft)
• Eclipse, GPL, EUPL – huolellisuutta, arkkitehtuuritarkistus
– GPL v3: erityisesti ehdot liittyen patentteihin, DRM:ään ja tivoization-ilmiöön
– Vahva copyleft
• Affero GPL yms. – huolellisuutta, arkkitehtuuritarkistus
– Vahva copyleft ja
– Palvelun tarjoaminen verkon yli rinnastuu levittämiseen
• https://opensource.org/licenses/alphabetical
Gilles Gonthier, CC BY 2.0

7. Avoimen koodin hankkiminen
1.Osaksi omaa tuotetta
2.ICT-hankinnassa

8. OSS tuotteen tai
projektin osana
• OSS sopii erinomaisesti yritysten/organisaatioiden käytettäväksi
tietojärjestelmien ja toimitusten osana
– Projektitoimitukset
– Ohjelmistotuotteet
– Verkon yli tarjottavat palvelut
– (Tuotekehitys, muu sisäinen käyttö)
– Liiketoimintamallit
• Tulee kuitenkin käyttää hallitusti
• Organisaatioille OSS ei ole mitään erikoista
– Erilaisia ohjelmistoja / paketteja / komponentteja
– Valitseminen samoilla perusteilla kuin suljetut ohjelmat
– OSS-lisensiointimalli on etu
iStockphoto.com

9. OSS tuotteen tai
projektin osana
• Edut
– Kaupallinen skaalautuvuus
– Tuotekehityksen nopeutuminen
– Mielekäs työskentelytapa kehittäjille
– Kun sopivat teknologiat
– OSS projektien elinvoimaisuus (tarkistettava)
– Julkisuus laadun nostajana (myös haitta)
• Haitat
– Ei 100% kontrollia (vrt. oma kehitys), projektin kääntä(/y)minen hidasta
– Työskentely OSS projekteissa pääosin julkista, vrt. kilpailijat (myös etu)
iStockphoto.com

10. Riskien luokittelua
• Kaupalliset, tekniset ja oikeudelliset riskit
– Oikeudellinen validointi, ns. compliance
– Riskejä ei tule liioitella: vrt. suljetut ohjelmistot
• Kaksi riskityyppiä, jos compliance laiminlyödään
– Yhteisöriski siitä, että ei noudata ehtoja
• Yhteisöön voi kuulua: 1) asiakkaat, asiakkaan työntekijät, 2) muu
downstream, 3) omat työntekijät, 4) ulkopuoliset OSS-kehittäjät jne.
• Toteutuessaan aiheuttaa erilaista badwilliä ja myös juridista riskiä
• Hyvä vai huono kansalainen?
– Juridinen riski siitä, että ei noudata ehtoja
• Oikeudenhaltija puuttuu: työtä, tuotteen muuttamista, tuotteen
peruuttamista/tuhoamista, kuluja, korvauksia
• Oman ohjelmiston lähdekoodin julkaisu on oma valinta
iStockphoto.com

11. Riskien hallinta
YRITYSNÄKÖKULMA
•Yhteisöriski: kehitä hyvä suhde OS-yhteisöön
•Luo ja tiedota yhteyspiste OS-lisensiointiasioita varten
•Noudata edelleen levittämisen ehtoja - toimi oikein, kunnioita tekijöitä,
ole aktiivinen
•Vastavuoroisuusvelvoitteet: luo järkevä politiikka ja järkevät rajanvedot
– Huolehdi arkkitehtuurista (ns. linkityskysymykset)
– Tarvittaessa hyödynnä requirement-menettelyä
• Ei oikeudellisesti levitystä
iStockphoto.com

12. OSS tuotteen tai
projektin osana
• Copyleft ja arkkitehtuuri
iStockphoto.com

13. OSS tuotteen tai
projektin osana
• GPL-lisensioitu ajuri
• Selvät alueet
– Suora lähdekoodin ja tai objektikoodin muokkaus on copyleftin piirissä
– Erikseen ajettavat prosessit ovat ulkopuolella
• Keskustelu protokollan yli; yhteiset tietokannat, tallennuspisteet tmv.
– Ei varmuutta tuomioistuimen tulkinnasta
• Epäselvät alueet
– Staattinen linkitys
• Binääri todennäköisesti copyleftin piirissä
• Sorsalevitys erikseen: ehkä ei
– Dynaaminen linkitys: näkemykset jakautuvat
• Toiminnallisuuksilla ehkä merkitystä
• Levitystavalla ehkä merkitystä
iStockphoto.com

14. OSS ICT-
hankinnassa
• Noudata tavallisia, hyvän ICT-hankinnan pelisääntöjä
• Käsittele avoimen koodin toimituksia samoin kuin
muitakin toimituksia:
– Osaksi normaalia hankintamenettelyä
• Hankintamenettelyyn tiettyjä tarkennuksia
– Edellytä hyvää/sopivaa teknologiaa, tarkista elinvoimaisuus
– Edellytä sovellustukea ja käyttötukea tarpeen mukaan
– Avoin koodi ≠ harrastelijapuuhastelu  edellytä ammattimaisuutta koko
toimituksessa
– Hinnoittelu muulla kuin lisensseissä
iStockphoto.com

15. OSS ICT-
hankinnassa
• Älä kiellä avoimen koodin käyttöä hankintasopimuksissa
• Ennemmin vaadi avointa koodia
– Esim. toimittaja ei saa itse kehittää koodia, johon vastaavat olisi saatavilla avoimena
– Esim. toimittajan toimitus pitää luovuttaa tilaajalle avoimen koodin ehdoin
• Kokonaisuus, tietyt osat v. toimittajan tekemät osat
– Esim. toimittajan on julkaistava koodi ja ylläpidettävä julkista projektia tietyn aikaa
• Älä vaadi tiettyä lisenssiä ilman painavaa syytä
• Älä sulje mitään lisenssejä pois (= älä sulje GPL-lisenssejä pois)
– GPL-pelot perustuvat väärinkäsityksiin
• Edellytä, että toimittaja tekee mahdolliset muutokset avoimen koodiin osiin ko.
projekteihin (ns. upstream-projektit)
– Salli muutoksien tekeminen upstreamiin oman projektin aikana
• Edellytä, että toimittaja on huolellinen, ammattimainen ja noudattaa avoimen koodin
lisenssiehtoja
iStockphoto.com

16. OSS ICT-
hankinnassa
• Edut
– Toimittajan arvonmuodostus kytkeytyy vahvemmin asiakkaan
arvonmuodostukseen  palveluajattelu ostajankin etu
– Lukkojen väheneminen, mahdollisuus vaihtaa toimittajaa parempi
– Skaalautuvuus toiminnan mukaan
– Kustannusten laskeminen
– Julkisuus, läpinäkyvyys, laatukontrolli helpompaa
• Haitat
– Joillain teknologioilla ei vielä paljon tarjoajia
– Omaksuttava uusia toimintatapoja
iStockphoto.com

17. GPL v2 huomioita
• Paljon väärinkäsityksiä
• GPLv2 ei tartu, vaan sisältää vastavuoroisuusehdon (eli copyleft)
– Jotta saa levittää edelleen, on noudatettava vastavuoroisuutta
• Ei sisällä mitään mekanismia, jolla yritys asettaisi oman teoksensa jotenkin
automaattisesti GPL:n alle
• Tällaista vaatimusta ei koskaan ole esitettykään
– Kohta 2 (johtolause + alakohta b)
• GPL-lisenssin copyleft-ehdosta
– Soveltuu vain levittämiseen (ei omaan käyttöön)
– Ei sovellu tarjoamiseen palveluna
• Copyleft-ehdossa kylläkin tulkinnanvaraisuutta
– GPL-ohjelmiston levitys proprietary ohjelmiston kanssa
– Milloin noudatettava copyleft ehtoa? Jotta oikeus levittää säilyy.
– Eli lokeroitavissa ja ratkaistavissa oleva kysymys
iStockphoto.com

18. Kiitos!
iStockphoto.com