7.2.2017
”Open source” -termin käyttötavat ovat niin moniulotteisia ja jopa ideologisia, että niistä syntyy väkisinkin vääriä mielleyhtymiä ja käsityksiä. Puimme näitä North Patrolin kahvipöydässä ja ajattelimme, että korjataan nyt väärinkäsityksistä karkeimmat:
Väärinkäsitys 1: Avoimeen lähdekoodiin perustuva tuote = ilman lisenssiä
Vaikka jokin ohjelmisto (kuten WordPress, Drupal, Joomla tai Liferayn ’Community Edition’) perustuu avoimeen lähdekoodiin, ohjelmistoon liittyy sen tekijöiden sille asettama lisenssi. Ohjelmiston ”avoin lähdekoodi” on julkaistu määrätyn lisenssin alaisena (kuten ”GNU General Public License”, GPL), ja lisenssi määrittelee tyypillisesti mm. sen, mihin tuotetta saa käyttää, mistä lähdekoodin kirjoittajat kantavat vastuun, millaisia rajoituksia sen käytölle on, ja millaisia velvoitteita sen käyttäjille asetetaan.
Väärinkäsitys 2: Avoimesta lähdekoodista tunnettu ohjelmistotuote = ilmainen
Avoimen lähdekoodin julkaisujärjestelmät (Drupal, WordPress, Liferay ym.) tunnetaan yleisesti maksuttomina, ilmaisina ohjelmistotuotteina. Avoimen koodin julkaisujärjestelmien vakio-ominaisuudet tai ’ydin’ onkin maksutonta koodia, mutta usein niiden ominaisuuksia on tarpeen parantaa erilaisilla laajennuksilla, lisäosilla tai pilvipalveluilla, jotka voivat olla maksullisia. Laajennukset voivat olla hinnoiltaan hyvin maltillisia, mutta toisinaan niiden hinnoista voi vuosien mittaan kertyä ihan tuntuvakin lisäkustannus.
Useista avoimen koodin julkaisujärjestelmistä on olemassa myös kaupalliset versiot, jotka maksua vastaan tarjoavat esim. laajempaa toiminnallisuutta tai parempia tukipalveluja. Esimerkiksi Liferayn ’Enterprise Edition’ on jo melko kallis investointi, jonka kustannus on helposti kymmeniä tuhansia (tai jopa satoja tuhansia euroja) verkkopalvelun elinkaaren aikana.
Kenelläkään ei liene sitä väärinkäsitystä, että uuden verkkopalvelun saisi ilmaiseksi, vaikka ohjelmistotuote olisikin maksuton: ohjelmistotuotteen käyttöönotosta ja verkkopalvelun rakentamisesta ”sen päälle” syntyy tietenkin työkustannuksia ja ylläpitokustannuksia.
Väärinkäsitys 3: Avoimeen lähdekoodiin perustuvalla tuotteella toteuttaminen = edullinen projekti
Maksullisten, kaupallisesti lisensoitujen julkaisujärjestelmätuotteiden käyttämistä epäröidään usein siitä syystä, että pitää maksaa ”kalliita tuotelisenssejä”. Tässä mielessä avoimeen lähdekoodiin perustuvan julkaisujärjestelmän lisenssihinta 0 euroa vaikuttaa itsestään selvästi edullisemmalta.
Avoimeen lähdekoodiin perustuva julkaisujärjestelmä voi kuitenkin vaatia niin paljon projektikohtaista konfigurointia, räätälöintiä ja laajentamista, että projektin työkustannukset nousevat yllättävän suuriksi.
Verkkopalveluprojektin luonteesta riippuen ”kallislisenssinen julkaisujärjestelmätuote” voi tarjota suoraan paketista niin paljon tarpeellisia valmisominaisuuksia, että sen käyttöönotto on itse asiassa edullisempaa kuin vastaavien ominaisuuksien räätälöinti avoimen lähdekoodin julkaisujärjestelmällä.
Väärinkäsitys 4: Avoimen lähdekoodin käyttämisestä syntyy avointa lähdekoodia
Jos yhteistyökumppanisi rakentaa verkkopalvelun avoimeen lähdekoodiin perustuvalla julkaisujärjestelmällä, tehdään siihen todennäköisesti asiakaskohtaisia räätälöintejä, skriptejä, laajennuksia ja muita ohjelmallisia ratkaisuja, joiden lähdekoodi ei ole ”avointa”, vaan lähtökohtaisesti sen immateriaalioikeudet kuuluvat yhteistyökumppanillesi. Yhteistyökumppanisi kanssa laadit sopimuksen siitä, millaiset käyttöoikeudet sinulla tilaajana on tähän lähdekoodiin.
Mikäli tilaaja on ostamassa sellaista ohjelmallista sovellusta, jonka hyödyntämismahdollisuus halutaan tarjota muillekin osapuolille, sidosryhmille tai kumppaneille, voidaan yhteistyökumppanin kanssa sopia siitä, että projektissa syntyvästä lähdekoodista tehdään ”avointa lähdekoodia”: lähdekoodi siis julkaistaan kehitystyön jälkeen siten, että kuka tahansa voi kopioida koodin ja käyttää sitä vastaavien sovellusten luomiseen. Esimerkiksi Helsingin kaupunki on linjannut periaatteekseen, että kaikki kaupungin toimeksiannosta kehitettävä uusi ohjelmistokoodi julkaistaan tällä tavoin avoimen lähdekoodin lisenssillä.
Lähdekoodin julkaiseminen tarkoittaa verkkopalvelujen toteuttajille sitä, että heidän projektissa tuottamansa ohjelmistokoodi myydään julkisesti käytettäväksi — tämä epäilemättä näkyy projektin hinnoittelussa, kun toteuttajakumppani myy projektityönsä lisäksi ”liikesalaisuutensa” eli oikeudet asiantuntijatyönsä tuloksiin.
Väärinkäsitys 5: ”JIT 2015 – Tilaajan sovellukset avoin lähdekoodi” on oikea sopimusmalli, kun projekti tehdään avoimeen lähdekoodiin perustuvalla julkaisujärjestelmällä
Kun julkisen hallinnon IT-hankintojen yleiset sopimusehdot (JIT 2015) uudistuivat, luotiin sovellushankintoja varten kolme erilaista erityisehtojen liitettä:
- Erityisehtoja tilaajan sovellushankinnoista muulla kuin avoimella lähdekoodilla (JIT 2015 – Tilaajan sovellukset ei-avoin)
- Erityisehtoja tilaajan sovellushankinnoista avoimen lähdekoodin ehdoin (JIT 2015 – Tilaajan sovellukset avoin lähdekoodi)
- Erityisehtoja ketterillä menetelmillä toteutettavista projekteista (JIT 2015 – Ketterät menetelmät)
Kaikki nämä ehdot mahdollistavat avoimen lähdekoodin alustojen käyttämisen, mutta kaksi jälkimmäistä edellyttävät myös lopputulosten julkaisemista avoimena lähdekoodina.
Kun verkkopalveluprojektissa hyödynnetään avoimeen lähdekoodiin perustuvaa julkaisujärjestelmää (WordPress, Drupal, Joomla, Liferay CE), mutta lopputulokset jäävät vain tilaajan omaan käyttöön, tarjoaa sopivat erityisehdot sopimukselle tyypillisimmin ”Tilaajan sovellukset ei-avoin”.
Ja erityisehdot ”JIT 2015 – Tilaajan sovellukset avoin lähdekoodi” tai ”JIT 2015 – Ketterät menetelmät” on syytä ottaa käyttöön vain silloin, kun toimittajan kanssa nimenomaan sovitaan siitä, että projektin lopputulokset julkaistaan ”avoimena lähdekoodina”.
7.2.2017 at 10:31
Hmm, on tässä virhe? ”…mutta kaksi jälkimmäistä edellyttävät myös lopputulosten julkaisemista avoimena lähdekoodina”. Ketterästi saa tehdä suljettuakin koodia, jos niin on sovittu, eikö? Siis JIT 2015 -ehtoja sovellettaessakin.
TykkääTykkää
7.2.2017 at 10:44
Hämmentävää, eikö totta? Noissa JIT-erityisehdoissa ketterien menetelmien projekteista on lähtökohtaisesti (luvussa 17) esitetty, että ”Toimittaja julkaisee sovelluksen kolmenkymmenen (30) päivän sisällä toimituksen kohteen hyväksynnästä sopivaksi katsomallaan tavalla, ellei erikseen muuta ole sovittu”, joten lähdekoodin julkaisemista niissä kyllä suositaan. Mutta tottakai saa sopia muutakin, tehdessä ketterästi tai millä menetelmillä vain.
TykkääLiked by 2 people
7.2.2017 at 12:22
Siis tarkoitin, että tuossa kirjoituksessasi, lainaamassani virkkeessä lienee virhe, koska erityisehdot eivät EDELLYTÄ koodin julkaisemista avoimena koodina. Kyseessähän on sopimusmallit, jotka tulisi sovittaa aina kulloinkin kyseessä olevaan hankintaan sopiviksi.
TykkääTykkää
7.2.2017 at 12:41
Ilman muuta näkemyksesi on täsmälleen oikea: oli sopimusmalli mikä tahansa, se pitää lukea ja sovittaa omaan hankintaan sopivaksi. Ikävä kyllä monet ostajat eivät siihen vaivaudu eikä ”valmiita” sopimusmalleja muokata omaan tarpeeseen. Ja tästä seuraa tarkoittamani tilanne: jos mitään muuta ei sovita, ”JIT 2015 – Ketterät menetelmät” edellyttää koodin julkaisemista.
TykkääLiked by 2 people