Helsinki siirtyy avoimeen koodiin

Helsingin kaupunginhallitus hyväksyi juuri uuden tietotekniikkaohjelman, jossa linjataan avoimen koodin käyttö:

”Kaupungin toimeksiannosta kehitettävä uusi ohjelmistokoodi julkaistaan avoimen lähdekoodin lisenssillä, ellei ole perusteltua syytä muuhun.”

Tämä tarkoittaa, että jatkossa kun kaupunki hankkii uuden tietojärjestelmän, eikä valmiita tuotteita ole ostettavissa, projektissa tehtävä koodi julkaistaan avoimella lisenssillä. Ei enää toimittajaloukkua, vaan sen sijaan järjestelmien laatu parantunee ja hinta laskee pikkuhiljaa. Kyse ei ole ideologisesta periaatteesta, vaan käytännöllisestä tietojärjestelmien hallinnasta. Päätös olikin yksimielinen sekä kaupunginhallituksessa että sen IT-jaostossa.

Tämä ei tarkoita, että kaupunki siirtyisi Linuxiin tai Open Officeen. Valmiita tuotteita hankittaessa valitaan ensi sijassa parasta, ja se voi olla myös Windows tai Office365.

Samassa paperissa linjataan myös, että ennen hankintaa on valittava ja perusteltava hankinnassa käytettävä strategia: ollaanko hankkimassa valmista tuotetta vai teettämässä uutta järjestelmää. Ja kaupunki aloittaa myös koulutusprojektin, jossa IT-hankintoja tekevät virkamiehet koulutetaan siihen, miten hankinnat saadaan onnistumaan.

Ensimmäisenä merkkinä uudesta toimintatavasta, tarjouskilpailu avoimen kehityksen puitesopimukseen on jo käynnissä.

Avoimen koodin kirjaus ei ole ohjelmassa sattumalta, vaan se on vuosien työn tulos.

Tammikuussa 2012 ehdotin edelliseen tietotekniikkaohjelmaan lisäystä:

”Avoin lähdekoodi. Kaupungin tilaama ohjelmistokehitys julkaistaan EU:n avoimen lähdekoodin lisenssillä (EUPL), ellei tästä ole erityisistä syistä tarpeen poiketa”

Silloin ei ollut oikein mitään tapaa käydä poliittista keskustelua aiheesta, eikä virkakunnassa myöskään oikein ymmärretty, mitä edes tarkoitin. Itselläni ei myöskään ollut mitään asemaa, joka pakottaisi minua kuuntelemaan. Olin vain yhden lautakunnan jäsen.

Nyt kolme vuotta myöhemmin molemmat ovat osa uutta ohjelmaa (tosin lisenssiä ei määritellä). Sillä tavoin politiikka toimi. Ensin ehdotetaan, sitten keskustellaan. Usein se vie aikaa, ja joskus se vaatii uusien keskustelukerhojen perustamista. Kun vaan jaksaa keskustella ja perustella asiat, kysyä kysymyksiä ja antaa vastauksia, niin lopulta voi käydä niin, että ehdottamasi muutos hyväksytään yksimielisesti.

Matkalla oli aika monta askelta. Käytiin kuntavaalit 2012 joissa tulin valituksi. Strategianeuvotteluissa olin vihreiden neuvottelijana ja esitimme IT-jaoston perustamista. Syksyllä 2013 se perustettiin, ja minusta tuli sen puheenjohtaja.

Jaosto käsitteli ohjelman valmistelua moneen kertaan, ja vaatimuksestamme se oli myös kahdesti kommentoitavana julkisesti. Kommentoinnit tosin osuivat juhannukseen ja uuteen vuoteen, mutta jostain se on avoimuuskin aloitettava. Ensi kerralle voisimme ehkä ottaa oppia Espoosta.

Helsinki on nyt ottanut merkittävän askeleen kohti toimivampia tietojärjestelmiä. Seuraavaksi sama periaate pitää ottaa käyttöön koko maassa. Intia ehti jo meitä ennen, samaten Britannia ja USA.

20 thoughts on “Helsinki siirtyy avoimeen koodiin”

  1. Minulta on kysytty mutamaan kertaan, millä lisensillä kaupunki koodinsa tulee julkaisemaan.

    Lisenssiä ei ole vielä päätetty. Keskusteluissa on ollut esillä GPL/EUPL ja toisena vaihtoehtona BSD. Argumentteja kumpaankin suuntaan (tai jonkin muun puolesta) saa esittää. Kysymys ei ole täysin itsestäänselvä, enkä ole itse ainakaan vielä vahvasti kummankaan kannalla.

    1. Hyvää työtä!

      EUPL on ihan mainio, koska se on GPL-yhteensopiva, mutta kirjoitettu EU:n ja sitä kautta Suomen lainsäädännön kanssa yhteensopivaksi. Lisäksi copyleft on hyvä ominaisuus. Tarvittaessa, jos halutaan erityisesti kannustaa kehittämään myös suljettuja versioita, niin voi poiketa kaavasta tuplalisensoimalla, vaikkapa EUPL+BSD.

    2. EUPL:n osalta kannattaa huomata, että EUPL:n GPL-yhteensopivuus kulkee vain yhteen suuntaan, eli GPL-softaa *ei* voi yhdistää samaan teokseen EUPL-softan kanssa ja levittää uutta teosta EUPL:n alla (toisin päin onnistuu). Tästä voi seurata ihan turhaa kompleksisuutta ja epävarmuutta esim. silloin, kun ohjelmistoa täydennetään GPLv2-koodilla tavalla, joka vaatii jatkossa kaiken ohjelmistoon läheisesti kuuluvan EUPL-koodin käyttämistä GPLv2:n alla. Lopputuloksena voi olla, että suuri osa kokonaisuutta joka tapauksessa lopulta gravitoituu GPLv2:n alle, eikä ole enää käytettävissä EUPL:n alla.

      Silloin kun halutaan vahvaa copyleftiä, GPLv2:n käyttäminen sellaisenaan on mielestäni suositeltavampaa. GPLv2 on suosittu ja vakiintunut lisenssi, eikä sen yhteensopivuudessa EU:n ja Suomen tekijänoikeuslainsäädännön kanssa pitäisi olla minkäänlaista ongelmaa. Valinnalle sallivan (esim. BSD, MIT, Apache) ja copyleft-lisenssin (esim. GPL, MPL, EUPL) välillä pitäisi myös mielestäni jättää tapauskohtaista harkinnanvaraa.

      Sallivien lisenssien osalta joku mainitsikin, että Apachessa on kaupallisia toimijoita miellyttävät patenttiehdot. Se on etu. Huono puoli lisenssissä on, että se ei ole GPLv2-yhteensopiva, joten samoihin projekteihin niitä ei voi ainakaan suositella.

  2. Hienoa työtä. Suosittelisin BSD-lisenssin sijaan käyttämään Apache 2 -lisenssiä, koska siinä on eksplisiittinen patenttipykälä.

    Pelkkä lähdekoodi tosin ei vielä takaa kaikkea. Onko näkemystä siitä miten versionhallintahistoria toimii? Parhaassa tapauksessa versionhallintaserveriä pyörittäisi kaupunki ja kaikki työ tehtäisiin siellä. Parin vuoden välein tapahtuvat koodin pudotukset eivät ole oikein optimaalisia jatkokehityksen kannalta.

    1. Hienoa työtä Otso. GitHub on mainio mutta onko tosiaan niin, että sille ei löydy suomalaista vaihtoehtoa? Näkisin Helsingin tukemassa mieluusti suomalaista yritystä. Voi kyllä olla että näitä ei ole. GitHub nähdään niin dominattina pelurina ettei kukaan uskalla kilpailla.

      P.S Tämä kommenttikenttäsi layout on muuten aika pahasti rikki 😉

    2. Vielä täydennyksenä, nimenomaan tarkoitan tässä suomalaista SaaS-tuotetta. En tarkoita sitä, että pitäisi tukea jotain suomalaista integraattoripumppua joka tekisi ja integroisi jonkun muun tuotteen. GitHub on mainio vaihtoehto ja SaaS täydellinen valinta tälläiseen käyttöön.

  3. Non-copyleft lisenssin (esim. BSD) etuna olisi se, että avaisi mahdollisuudet mm. startupeille tehdä liiketoimintaa vapaasti ohjelmistoilla. Olisi erittäin positiivista, jos julkisin varoin kehitettyjä palveluita kyettäisiin hyödyntämään esim. viennissä. Vaikka vientituotteen syntyminen näistä hankkeista onkin epätodennäköistä, niin mahdotonta se ei ole. Mitkä tekijät puhuvat copyleft-lisenssin puolesta?

    1. Copyleft-lisenssin puolesta puhuu se, että ohjelmistoa jatkokehittävien on julkaistava myös kehitystyön lopputuloksena oleva lähdekoodi samalla lisenssillä, eli koodin alkuperäinen tilaaja, siis tässä Helsingin kaupunki saa kerättyä hyödyt siitä, että antaa koodin avoimesti muille käyttöön.

      Tämä tietysti jossain määrin heikentää toki yksityisten firmojen halukkuutta kehittää edelleen koodipohjaa, koska he eivät pääse hyötymään työnsä tuloksista yksinoikeudella. Kyse on balanssin hakemisesta: copyleft tuo alkuperäiselle tilaajalle hyötyjä, koska saa ”koodin avoimeksi lahjoittamisesta” hyödyt myös itselleen, mutta samalla se heikentää kaupallisten toimijoiden kiinnostusta. Copyleftitön lisenssi taas innostaa yksityisiä jatkokehittämään koodia, mutta alkuperäiselle tilaajalle ei ole tästä välttämättä mitään iloa.

  4. Hienoa työtä Otso! Helsinkihän on ollut pioneeri jo esim vuonna 2012 kun hakemisto.kirjastot.fi tilattiin Seravo Oy:ltä ja lopputulos julkaistiin avoimella lisenssillä, katsokaa huomautus sivun http://hakemisto.kirjastot.fi/ alalaidassa. Tietohallintoon on myös onnistuttu palkkaamaan fiksua väkeä ja kaupungilla on sekä avoimen datan että avoimen koodin asiat hyvillä raiteilla. Esimerkkinä myös http://dev.hel.fi/

  5. Hei, loistavaa, että tämä asia on edennyt näin pitkälle 🙂 Kiinnostaisi tosiaan tietää, onko jostakin syystä välttämätöntä tehdä pysyväisluontoinen valinta copyleft-lisenssin ja BSD-henkisen lisenssin välillä eli estääkö jokin käyttämästä tapauskohtaista harkintaa?

  6. Hienoa että myös Helsingin osalta OpenSource etenee. Minusta mikä lisenssi valitaan on toisarvoinen juttu. Tärkeintä on asiaa etenee. Tutustuin tähän Blokiin ja selvittelin muutenkin Helsingin tilannanne. Olen jo 10+ sitten sekaantunut työni puolesta kaupungin IT- kuvuihin. Toin myös OpenSource ajatusta kaupingin IT:lle vähän toisesti kulmasta. Silloin seurattiin ja mietitiin Turun yristystä saada Linux- työasemia. Tuohon aikaan sidokset ”Windows- only” ja muihin suljetteuihin ratkaisuihin olivat hyvin vahvat.

    Muutenkin Helsinki on ollut jotenkin kankea. Eikä todellakaan ole kulkenut IT- ratkaisuissa eturintamassa. Esimerkisksi voidaan ottaa keskustan avoin Wifi- verkko (Oulun tyyliin). Helsingissä hyvin yksiselitteisesti törpattiin moiset ajatukset. Ehkä poliittinen vaikuttaminen voisi olla tie saada tilennetta muutettua.

  7. En olisi lisenssistä kovin huolissani, oli se EUPL tai GPL. Lähdekoodin omistaja (eli Helsingin kaupunki) voi aina halutessaan lisenssoida koodin toisellakin lisenssillä jos on joku selkeä perusteltu syy ja se on veronmaksajien etu. Avattua koodia ei voi vetää takaisin, mutta helpotuksia ehtoihin voi tarvittaessa myöntää.

    Se on ns. positiivinen ongelma jos avatulle koodille ilmestyy hyötykäyttäjiä niin paljon että lisenssi meinaa rajoittaa hyödyntämistä.

    Hyvä linjaus. Tässä maassa ei kannata tuhlata panoksia siihen että samat ratkaisut ostetaan ja teetetään moneen kertaan.

    1. Lähdekoodin oikeuksien omistaja on Helsingin kaupunki vain, jos näin sovitaan. Tuo puhuttu linjaus ei vielä ainakaan välttämättä siihen johda, sillä yhtä hyvin toimittaja voi jäädä oikeuksien haltijaksi kunhan antaa oikeuksiensa nojalla (avoimen) lisenssin.

  8. Mielenkiintoinen valinta, eikä varmaan yhtään hullumpi sellainen. Sopii tähän Helsingin avoimemmaksi muuttuvaan linjaan kyllä mainiosti.

    Tätä uuden linjauksen perusteella tehtyä ensimmäistä tarjouspyyntöä joudun kuitenkin hieman ihmettelemään. Ensinnäkin siinä lähdetään siitä ajatuksesta, että tarjoajaorganisaatiolla on tullut olla organisaatiotili julkisessa versionhallintaympäristössä 1.2.2015. On vaikea nähdä, mikä tämän yhteys todelliseen open source -kompetenssiin on. Voihan open source -kontribuutioita tehdä vaikka miten ilman, että järjestäytyy _organisaatiotasolla_ avoimen lähdekoodin tarjoajaksi. Epäilemättä Helsingin esimerkki kannustaa jatkossa perustamaan sen tilin, mutta tässä vaiheessa tuo ehto tuntuu siltä, että sillä pyritään rajaamaan valinta käytännössä tiettyyn tai tiettyihin tarjoajiin. Suoraa yhteyttä hankinnan kohteen onnistumiseen on ainakin huomattavan vaikea nähdä.

    Toisekseen ihmettelen, miksi Helsingin kaupunki ostaa ”ketteriä ohjelmistokehityspalveluita” geneerisellä otsikolla kohdetta tai hankintalaajuutta kovin tarkasti määrittelemättä, mutta kuitenkin edellyttää tarjoajilta käytännössä tiettyihin teknologioihin kiinnittyvää kompetenssia. Osaamiskyselylomakehan on suunniteltu siten, että kilpailussa ei ole jakoa, vaikka osaisi tehdä kuinka loistavaa avoimen lähdekoodin modernia webiä esimerkiksi Microsoft-alustalla.

    Siitä, miten halukkaita perinteiset Microsoft-alustalla toimivat sovellustoimittajat olisivat lähtemään mukaan tällaisiin kilpailutuksiin, on vaikea sanoa mitään. Mutta noin lähtökohtaisella tasolla on vaikea tarjouspyynnön perusteella ymmärtää teknologiarajauksia. On harmillista, jos Helsingin nimenomaan räätälöidyn koodin IPR:ää koskeva linjaus (”_Kaupungin toimeksiannosta kehitettävä uusi ohjelmistokoodi_ julkaistaan avoimen lähdekoodin lisenssillä, ellei ole perusteltua syytä muuhun.”) toteuttaa samalla myös teknologiarajauksia. Mielestäni avoimen lähdekoodin henki sisältää myös ”paras teknologia voittakoon”-aspektin.

    Avoimuusseloste: Olen työkseni paljon tekemisissä Suomen Microsoft-kentän kanssa, ja se vaikuttaa tarkastelukulmaani. Toisaalta omalla yritykselläni on linjana, ettemme osallistu julkisiin tarjouskilpailuihin, joten välitöntä omaa lehmää ei ole ojassa.

  9. GPL ja BSD linsenssien eroilla ei ole suurta väliä verkkopalveluiden kohdalla. GPL:n copyleft nimittäin laukeaa vasta kun ohjelmaa levitetään eikä esimerkiksi silloin kun ohjelmaa ajetaan palvelimella jonkin palvelun tuottamiseksi. Minkä tahansa GPL lisensoidun ohjelman voi forkata, tehdä siihen muutoksia ja tarjota sitä omalta palvelimeltaan SaaS palveluna ilman, että copyleft vaatimus laukeaa.

    EUPLv1.1 on GPLv2 yhteensopiva ja EUPLv1.2 on GPLv3 yhteensopiva. Versioilla on väliä koska GPL:n versiot ovat keskenään yhteensopimattomia ellei käytetä esimerkiksi ”GPL version 2 or later” ilmaisua. EUPL yhteensopivuus taitaa kuitenkin toimia vain yhteen suuntaan niin, että koodia yhdistettäessä vain GPL jää voimaan. Jos näin on niin miksi edes vaivautua käyttämään EUPL:ä? GPL on kuitenkin oikeudessa asti koeteltu lisenssi mm. Saksassa.

    Itse suosisin BSD lisenssiä jotta muut tahot pystyisivät maksimaalisesti hyödyntämään julkaistua koodia. GPL ei kuitenkaan tarjoa paljoa suojaa palvelinohjelmistoille ja rajoittaa yhdisteltävyyttä suljetun koodin kanssa asiakaspään ohjelmissa. Molemmat lisenssit ovat kuitenkin valtava parannus suljettuun tai jaettuun koodiin verrattuna.

    Jos jossain projektissa tuotetaan muita ohjelmia tukevia kirjastoja niin myös LGPL on varsin varteenotettava vaihtoehto. Muutokset itse kirjastoon tulee julkaista (ohjelmaa levitettäessä), mutta kirjastoa saa käyttää muun lisenssin ohjelmista rajoituksetta.

    Lopulta on aika tapauskohtaista mitä avointa lisenssiä kannattaa käyttää. Valitsisin kuitenkin vakiintuneiden lisenssien joukosta: BSD, Simplified BSD, MIT, GPL, LGPL tai Apache2.

  10. Copyleftin soveltuvuus web-sovelluksiin on vähän kyseenalaista. GPLv2:n mukaan lisenssi ulottuu kaikkiin teoksiin, jotka sisältävät kyseistä ohjelmakoodia. Tulkitsisin tämän ulottuvan myös WWW-sivuilla olevaan tekstiin silloin, kun ohjelmakoodia kulkee sen mukana. Kaupungilla itselläänkin saattaa olla tarvetta julkaista esim. Intranetissä dokumentteja, joita ei ole tarkoitus levittää vapaasti, alkuperäisenä tai muunneltuna, missä tahansa mediassa. Silloin niiden kanssa samalla WWW-sivulla ei saisi olla GPL-lisensoituja käyttäjän selaimessa pyöriviä komponentteja.

    1. käsitääkseni GPL:ää ei yleensä ole tapana tulkita noin. Oletko nähnyt yhtään oikeustapausta, tai ede sjonkin merkittävän tahon väitettä, että sitä pitäisi tulkita noin?

      GPL v3:ssa on kappale:

      ”A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.”

      Minusta on melko selkeää, että koodin kanssa selaimelle jaeltu teksti on ”other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program”

    2. Kun samassa tiedostossa on koodia, tekstiä ja dataa, minulla ei ole riittävää lakiteknistä osaamista arpoa, voiko lisenssin tulkita koskemaan vain osaa tiedostosta. Yrityksen kannalta kyse ei ole oikeastaan siitä, onko joku joskus tulkinnut lisenssiä harmillisen laajasti, vaan siitä, mikä takaa ettei kukaan voi tehdä niin jatkossa. Jos se on arvoitus joka selviää vain oikeudessa, on parempi olla koskematta koodiin.

      Kaupunki itse voi varmasti julkaista ja käyttää omaa softaansa millä lisensseillä haluaa, mutta ulkopuolisena en uskaltaisi aina hyödyntää sitä. Koko Node.js -yhteisö pohjautuu MIT- ja BSD-lisensseihin joissa ei ole vastaavia ongelmia, mutta kaupunki käyttää Githubissa julkaisemassaan koodissa paljon AGPLv3- ja EUPL-lisenssejä. Niihin en uskalla koskea kun kyse on web-sovelluksesta. EUPL sanoo seuraavaa:

      – Derivative Works: the works or software that could be created by the Licensee,
      based upon the Original Work or modifications thereof. This Licence does not define
      the extent of modification or dependence on the Original Work required in order to
      classify a work as a Derivative Work; this extent is determined by copyright law
      applicable in the country mentioned in Article 15.

      15. Applicable Law

      This Licence shall be governed by the law of the European Union country where the
      Licensor resides or has his registered office.

      Lähde:
      https://github.com/City-of-Helsinki/openahjo/blob/master/LICENSE.txt

      Jos siis toteutan projektin ulkomaalaiselle asiakkaalle ja käytän siinä tuota Helsingin kaupungin koodia, syntyvät oikeudelliset ongelmat riippuvat asiakkaan maan lainsäädännöstä (tai Belgian, jos asiakas on EU:n ulkopuolelta). Sopimusteknisesti toimittajasta johtuvat asiakkaan niskaan satavat ongelmat siirtyvät helposti toimittajalle ja en usko, että pienillä toimijoilla on resursseja selvittää muiden maiden lakikuvioita (jotka voivan muuttua milloin vain). Tuota softaa ei siis ainakaan voi käyttää osana vientituotteita.

      Tekstin seassa on myös yleensä HTML-koodia joten näkyvän sivun ”lähdekoodi” on osittain JavaScript-sovellusta ja osittain HTML-lähdekoodia joka on melko kiinteä osa tekstiä. Voitko varmasti luvata, että oikeudessa kaikissa EU:n jäsenvaltioissa lähdekoodin Turing-yhteensopivuus tai muu vastaava määrittelee sen, mitä lisenssiä siihen sovelletaan? Tai että lähdekoodin lomassa oleva teksti ei ole osa lähdekoodia?

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *