Avoin lähdekoodi ei ole vastuusta luopumista

Julkaistu lähdekoodi muuttaa sen, kuka voi tarkastella, käyttää uudelleen ja parantaa sitä. Se ei poista käytännön työtä sen selvittämisestä, mitä on...

Avoin lähdekoodi ei ole vastuusta luopumista

Repository on avaus, ei päätepiste

Avoimeen lähdekoodiin liittyy lohdullinen pieni tarina. Ryhmä julkaisee koodia. Muut voivat lukea sen. Koodista tulee yhteinen hyödyke tai ainakin hyödyllinen yhteinen riesa. Vastuu haihtuu joukkoon.

Kaksi ensimmäistä virkettä voivat pitää paikkansa. Viimeinen ei. Julkinen repository voi laajentaa tarkastelua, uudelleenkäyttöä ja osallistumista. Se voi antaa organisaatiolle selkeämmän poistumistien kuin suljettu palvelu. Se voi antaa julkiselle toimijalle mahdollisuuden tutkia komponenttia pyytämättä lupaa toimittajalta. Mikään tästä ei vastaa kysymykseen, joka saapuu tavallisena tiistaiaamuna: mikä versio tässä on käynnissä, millä lisenssillä, millä konfiguraatiolla, ja kuka ryhtyy toimiin, jos tietoturvahälytys koskee tätä?

Avoin lähdekoodi muuttaa vastuun muotoa. Se ei tee vastuusta vapaaehtoista. Ylläpitäjällä on edelleen päätöksiä julkaisuista, tietoturvaraporteista, tuetuista versioista ja lisensseistä. Organisaatiolla, joka paketoi komponentin, on edelleen päätöksiä alkuperästä, päivityksistä ja siitä, mitä se kertoo käyttäjilleen. Käyttöönottajalla on edelleen päätöksiä inventaariosta, altistumisesta, konfiguraatiosta, pääsystä ja palautuksesta. Lisenssi antaa oikeuksia ja ehtoja. Se ei tarjoa päivystysvuorolistaa.

Tämä on tärkeää, koska avoimesta lähdekoodista on tullut tavallista infrastruktuuria. Se on käyttöjärjestelmissä, selaimissa, julkisissa palveluissa, tutkimustyökaluissa, teollisissa järjestelmissä ja kirjastoissa, jotka saavat tuotteen näyttämään omavaraisemmalta kuin se on. Kypsä kysymys ei siis ole se, onko organisaatio avointa lähdekoodia vastaan vai sen puolesta. Se on se, pystyykö se kantamaan vastuut, joita sen valitsema riippuvuus tuo mukanaan.

Eurooppalainen politiikka on alkanut kuvata tätä eroa selvemmin. Kyberresilienssisäädös sääntelee digitaalisia elementtejä sisältäviä tuotteita ja sisältää oman reitin vapaan ja avoimen lähdekoodin ohjelmistojen ylläpitäjille. Reitti tunnustaa, että henkilö tai organisaatio, joka tarjoaa jatkuvaa tukea vapaalle ja avoimelle lähdekoodille, voi olla todellinen osa tietoturvaketjua. Se ei tee jokaisesta koodia julkaisevasta vapaaehtoisesta valmistajaa. Se ei myöskään salli kaupallisen toimijan piiloutua julkisen repositoryn taakse, kun toimija tuo tuotteen markkinoille.

Käytännön seuraus on miellyttävän epäromanttinen. Kohtele jokaista riippuvuutta asiana, joka on nimettävä, ymmärrettävä ja hoidettava. Tämä ei ole hyökkäys avointa lähdekoodia vastaan. Se on kurinalaisuutta, joka pitää avoimen lähdekoodin hyödyllisenä, kun uutuudenviehätys on haihtunut.

Mitä julkaiseminen todella muuttaa

Lähdekoodin saatavuus muuttaa useita asioita kerralla. Lukija voi tarkastella toteutusta sen sijaan, että päättelee sen markkinointisivulta. Tiimi voi toistaa buildin, jos build-ohjeet, riippuvuudet ja ympäristö sen sallivat. Toimittaja voidaan korvata helpommin, kun lisenssi ja rajapinnat sen sallivat. Tutkija voi testata väitteen, tietoturvatiimi voi tarkastella korjausta, ja julkinen ostaja voi esittää kysymyksiä kohtelematta mustaa laatikkoa perustuslaillisena periaatteena.

Nämä ovat merkittäviä julkisia hyödykkeitä. Ne ovat myös ehdollisia. Koodi, joka on näkyvää mutta mahdotonta rakentaa, on vähemmän tarkasteltavissa kuin miltä se ensin näyttää. Koodi, joka on rakennettavissa mutta vailla selkeää lisenssiä, jättää uudelleenkäytön epävarmaksi. Koodi, joka on lisensoitu mutta koottu tuntemattomista riippuvuuksista, kantaa alkuperäongelman. Koodi, jota ylläpidetään vain haarassa, jota kukaan ei tunnista, ei tule luotettavaksi siitä, että repository-sivu on olemassa.

Open Source Initiative kuvailee avointa lähdekoodia hyväksytyn lisenssin ja oikeuksien joukon avulla, mukaan lukien pääsyn lähdekoodiin sekä vapauden levittää ja muokata sovittujen ehtojen mukaisesti. Tämä määritelmä koskee tarkoituksellisesti käyttöoikeuksia. Se ei ole palvelutasosopimus, tietoturvasertifikaatti, takuu soveltuvuudesta tiettyyn julkiseen tehtävään eikä lupaus siitä, että komponenttia ylläpidetään toistaiseksi. Näiden lupausten puuttuminen ei ole vika määritelmässä. Se on syy olla tarkka siitä, mihin organisaatio luottaa.

On hyödyllistä erottaa toisistaan neljä kysymystä, jotka usein niputetaan yhden ystävällisen sanan alle. Onko lähdekoodi saatavilla? Onko se lisensoitu aiottuun käyttöön? Voiko organisaatio selvittää, mistä koodi ja sen riippuvuudet ovat peräisin? Kantako joku aktiivisesti operatiivista vastuuta, jota tämä käyttöönotto edellyttää? Kyllä-vastaus ensimmäiseen kysymykseen ei vastaa kolmeen muuhun.

Tämä erottelu tekee myös keskusteluista vähemmän teatraalisia. Hankintatiimin ei tarvitse esittää innostusta repositoriota kohtaan. Sen on tiedettävä, soveltuuko komponentti järjestelmään, jota se ostaa tai operoi. Suunnittelutiimin ei tarvitse pyytää anteeksi sallivan lisenssin käyttöä. Sen on tiedettävä, miten se täyttää lisenssi-ilmoitukset, säilyttää vaaditut materiaalit, päivittää riippuvuudet ja reagoi julkistettuun ongelmaan. Lakitiimin ei tarvitse ryhtyä julkaisupäälliköksi. Sen tarvitsee saada reitti julkaisuprosessiin ennen kuin lisenssiongelmasta tulee julkinen korjausliike.

Lähdekoodi voi kulkea useiden toimijoiden kautta. Valitse kerros erottaaksesi julkaisu-, paketointi-, tuotesijoittelu- ja käyttöönottovastuut toisistaan.

Lisenssi on raja, ei sääennuste

Lisenssejä kohdellaan joskus hallinnollisena yksityiskohtana, ikään kuin juridinen työ alkaisi vasta suunnittelutyön päätyttyä. Käytännössä lisenssivalinnat muovaavat suunnittelupäätöksiä alusta alkaen. Ne vaikuttavat siihen, voidaanko komponentti yhdistää toiseen komponenttiin, onko ilmoituksia liitettävä jakeluun, onko muokattua lähdekoodia tarjottava tietyissä tilanteissa ja pystyykö tiimi täyttämään ehdot, jotka liittyvät oikeuksiin, joita se haluaa käyttää.

Tämä ei tarkoita, että jokaisen insinöörin on tultava tekijänoikeusasiantuntijaksi. Se tarkoittaa, että organisaatio tarvitsee luotettavan käännöksen rakentamansa ohjelmiston ja niiden sitoumusten välillä, jotka se tekee jakaessaan, isännöidessään tai muokatessaan ohjelmistoa. Käännös on tehtävä silloin, kun tosiasiat ovat vielä saatavilla: mikä paketti valittiin, mitä versiota käytettiin, muutettiinko sitä, miten se linkitettiin tai sisällytettiin, minkä kanssa se toimitetaan ja mikä on aiottu jakelureitti.

Yleispätevää lisenssivastausta ei ole. Salliva lisenssi voi tehdä uudelleenkäytöstä suoraviivaista mutta edellyttää silti ilmoituksia ja tekijänoikeustekstin säilyttämistä. Vastavuoroinen lisenssi voi liittää lisäehtoja jakeluun tai muokkaamiseen. Kaksilisenssijärjestely voi edellyttää, että organisaatio valitsee kaupallisen reitin tai tietyn avoimen lähdekoodin reitin. Organisaation ei pitäisi päätellä velvoitteita lisenssin lempinimestä, paketinhallinnan merkistä tai kollegan vuodelta 2014 puoliksi muistamasta tarinasta. Sen pitäisi lukea lisenssiteksti, kirjata päätös ja pyytää neuvoa, kun aiottu käyttö on epävarmaa.

Lisenssivaatimusten noudattaminen ei ole myöskään seremonia, joka suoritetaan julkaisuviikolla. Ohjelmiston materiaaliluettelo, riippuvuusluettelo ja julkaisutietue voivat tehdä myöhemmästä kysymyksestä vastattavan: mitä tämä artefakti sisälsi? Mutta luettelo on hyödyllinen vain, jos se kuvaa määritellyn artefaktin, version ja päivämäärän. Taulukkolaskentatiedosto nimeltä dependencies-final-final.xlsx ei ole alkuperänhallintajärjestelmä. Se on arkeologinen kerrostuma.

Julkiselle laitokselle tämä on enemmän kuin taloudenhoitoa. Laitoksen on ehkä säilytettävä kyky selittää, miksi komponentti valittiin, mitkä ehdot sitä säätelevät, miten se voidaan korvata ja mitä tapahtuu, jos ylläpito loppuu. Kaupalliselle organisaatiolle samat tietueet vaikuttavat sopimusvelvoitteisiin, tuotepäivityksiin ja asiakasviestintään. Pienelle tiimille mittakaava on erilainen, mutta logiikka ei ole. Jos projekti ei pysty tunnistamaan jakamansa koodin lisenssiä, se ei voi rehellisesti sanoa, että oikeudellinen raja on hallinnassa.

Vastuullinen toiminta on oikeasuhtaista, ei mahtipontista. Kirjaa suorat riippuvuudet. Säilytä lisenssitekstit ja vaaditut ilmoitukset julkaisun yhteydessä. Kirjaa olennaiset muutokset. Aseta tarkistuspiste uusille tai epätavallisille lisenssiehdoille. Nimeä joku vastaamaan epävarmuuden ratkaisemisesta. Nämä ovat vaatimattomia hallintakeinoja. Niiden arvo on siinä, että ne estävät epävarmuutta muuttumasta yllätykseksi sen jälkeen, kun ohjelmisto on lähtenyt matkaan.

Ylläpito on työtä, myös lahjoitettuna

Avoimen lähdekoodin ylläpitoa kuvataan usein kuin se olisi henkilökohtainen hyve. Joskus se on. Ihmiset arvioivat korjauksia, vastaavat kysymyksiin, paketoivat julkaisuja ja estävät vanhoja oletuksia muuttumasta huomisen häiriöiksi, koska he välittävät työkalusta ja sen käyttäjistä. Tämä anteliaisuus ansaitsee kunnioituksen. Sitä ei pitäisi käyttää liiketoimintamallina ilman liiketoimintapäätöstä.

Ylläpito on operatiivista työtä. Siihen kuuluu päätös siitä, mitä versioita tuetaan, osallistumisten arviointi, tietoturvatietojen julkaiseminen, julkaisuprosessin hallinta, ilmoituksiin vastaaminen, yhteensopivuutta rikkovien muutosten dokumentointi, rakennusinfrastruktuurin käyttökelpoisena pitäminen ja joskus kieltäytyminen. Viimeinen osa on aliarvostettu. Projekti, joka ei voi kieltäytyä ominaisuuspyynnöstä, tuesta tuesta tai turvattomasta oikotiestä, ei välttämättä ole avoimempi. Se voi yksinkertaisesti olla alttiimpi.

Euroopan komission avoimen lähdekoodin ohjelmistostrategia käsittelee avointa lähdekoodia tapana parantaa uudelleenkäyttöä, läpinäkyvyyttä, yhteistyötä ja teknologista riippumattomuutta julkishallinnossa. Nämä hyödyt riippuvat kyvykkyydestä. Uudelleenkäyttö edellyttää, että organisaatio ymmärtää, mitä se käyttää uudelleen. Läpinäkyvyys edellyttää, että joku lukee, mitä on julkistettu. Riippumattomuus edellyttää enemmän kuin kloonauspainikkeen hallussapitoa: se edellyttää käytännön kykyä käyttää, mukauttaa tai hankkia tukea ohjelmistolle, kun alkuperäinen avustaja on siirtynyt eteenpäin.

Siksi kysymys "onko se ylläpidetty?" kaipaa lisää muotoa. Se voi tarkoittaa, että viimeaikaisia julkaisuja on olemassa. Se voi tarkoittaa, että tietoturvayhteystieto on julkaistu. Se voi tarkoittaa, että projekti kuvaa tuetut versiot, rakennusohjeet ja osallistumisprosessin. Se voi tarkoittaa, että organisaatio on sitoutunut palkallista aikaa työhön. Se voi tarkoittaa, että käyttöönottajalla on oma kyvykkyys ylläpitää haarukkaa tai korvata komponentti. Nämä ovat erilaisia asioita. Vihreä aktiivisuuskaavio voi olla hyödyllistä näyttöä, mutta se ei ole ylläpitosopimus.

Vastuullisen käyttöönottajan tulisi siksi päättää, millaista ylläpitoa se tarvitsee, ennen kuin se päättää, mitä se toivoo yhteisön tarjoavan. Matalan riskin sisäinen työkalu voi olla yhteensopiva pienen projektin ja vaatimattoman päivityssuunnitelman kanssa. Komponentti ulkoisesti näkyvän tuotteen keskiössä tarvitsee selkeämmän tukimallin, nopeamman haavoittuvuusarvioinnin ja poistumissuunnitelman. Ero ei liity projektin arvovaltaan. Se liittyy siihen, mitä seurauksia on siitä, että ollaan väärässä.

Suomalaisista tavoista lainattava pieni oivallus: älä sekoita kodikkuutta hallintaan. Kutsuva yhteisö voi olla hieno paikka osallistua. Sillä ei silti välttämättä ole velvollisuutta pitää tuotantojärjestelmääsi toiminnassa. Eron määrittelee organisaatio, joka ottaa järjestelmän tuotantoon.

Tietoturvailmoituksille tarvitaan reitti ennen iskulausetta

Useimmat ovat periaatteessa yhtä mieltä siitä, että haavoittuvuuksista tulisi ilmoittaa vastuullisesti. Vaikea osuus on vähemmän periaatteellinen. Mihin ilmoittaja lähettää havaintonsa? Kuka sen vastaanottaa? Mitä tietoja sen toistamiseen tarvitaan? Kuka päättää, koskeeko se tuettua versiota? Miten korjaus kehitetään luomatta tarpeetonta julkista altistumisikkunaa? Miten käyttäjille kerrotaan, mitä heidän tulee tehdä? Mitkä alavirran paketit tarvitsevat päivityksen? Mitä tapahtuu, jos ilmoittaja ei saa vastausta?

Nämä kysymykset eivät ole merkki epäluottamuksesta avoimeen lähdekoodiin. Ne ovat työtä, jossa käyttäjiä kohdellaan ihmisinä, jotka tarvitsevat vastauksen. ENISA:n työ haavoittuvuuksien ilmoittamisesta ja koordinoidusta haavoittuvuuksien ilmoittamisesta kuvaa määriteltyjen prosessien arvoa ilmoittajien, toimittajien ja muiden asianomaisten osapuolten välillä. Prosessi ei voi taata, että jokainen ilmoitus on oikea tai jokainen korjaus nopea. Se voi vähentää todennäköisyyttä, että vakava ongelma alkaa elämänsä valvomattomassa sähköpostilaatikossa.

Projekti voi julkaista tietoturvakäytännön, ilmoitusosoitteen ja tuettuja versioita koskevat tiedot. Nämä ovat hyödyllisiä signaaleja, erityisesti kun ne kuvaavat, mitä ilmoittaja voi odottaa. Projekti voi myös olla liian pieni tarjoamaan vastausajan, jota tärkeä käyttöönotto tarvitsee. Tämä ei ole moraalinen epäonnistuminen. Se on suunnittelun tosiasia organisaatiolle, joka valitsee riippuvuuden.

Sama pätee alavirtaan. Valmistaja ei voi kohtuudella väittää, että haavoittuvuus on jonkun muun ongelma vain siksi, että haavoittuva komponentti sai alkunsa avoimesta arkistosta. Jos valmistaja saattaa digitaalisia elementtejä sisältävän tuotteen unionin markkinoille, kyberturvallisuussäädös asettaa vaatimuksia haavoittuvuuksien käsittelylle ja tietoturvapäivitysten toimittamiselle tuotteeseen sovellettavassa kehyksessä. Lain yksityiskohdat riippuvat tuotteesta ja roolista. Toiminnallinen asia on yksinkertaisempi: tuotteen saataville asettavan osapuolen on pystyttävä selvittämään, vaikuttaako ylävirran muutos siihen, mitä se on toimittanut.

Tässä kohtaa inventaariosta tulee aktiivinen koristeen sijaan. Sen on yhdistettävä komponentti versioon, koontiversioon, tuotejulkaisuun ja omistajaan, joka pystyy arvioimaan ilmoituksen. Omistajan ei tarvitse korjata jokaista ylävirran vikaa yksin. Sen on kuitenkin päätettävä, päivitetäänkö, lievennetäänkö, poistetaanko käytöstä, ilmoitetaanko, kompensoidaanko vai lopetetaanko komponentin käyttö. "Käytämme avointa lähdekoodia" on kuvaus syötteestä. Se ei ole toimintasuunnitelma.

Tarkastellaan nimenomaisesti hypoteettista esimerkkiä. Tiimi sisällyttää kirjaston dokumentinkäsittelypalveluun. Kuukausia myöhemmin tietoturvatiedote tunnistaa haavoittuvan versioalueen. Jos tiimi on kirjannut komponentin, version ja palvelut, joihin se on rakennettu, se voi aloittaa arvioinnin. Jos se pystyy toistamaan koontiversiot ja testaamaan päivityksen, se voi päättää, onko korjaus päivitys, konfiguraatiomuutos vai väliaikainen rajoitus. Jos sillä ei ole kirjausta eikä omistajaa, ensimmäinen tehtävä on etsiväntyö. Haavoittuvuus voi olla sama molemmissa tapauksissa. Toiminnallinen riski ei ole.

Ilmoitusreitti ei lupaa, että jokainen ongelma on pieni. Se tekee seuraavan vastuullisen toimen näkyväksi, kun ongelma löytyy.

Alkuperäketju vastaa kysymykseen ”mitä me oikein ajamme?”

Ohjelmiston alkuperäketju voi kuulostaa sanalta, joka on lainattu museon esinetarrasta. Taustalla oleva kysymys on arkinen: mistä tämä artefakti on peräisin, ja voimmeko osoittaa sen reitin? Ohjelmiston kohdalla reitti voi sisältää lähdekoodivarastoja, julkaistuja arkistoja, riippuvuusrekistereitä, rakennustyökaluja, konfiguraatiota, allekirjoitusavaimia, rakennusympäristöjä ja julkaisujärjestelmiä. Vastaus on harvoin yksi tyylikäs tosiasia. Se on kokoelma tietueita, joiden on täsmättävä riittävän hyvin, jotta ihminen voi tehdä päätöksen.

Alkuperäketju ei edellytä organisaatiolta täydellistä tietämystä. Se edellyttää, että organisaatio kertoo, mitä tiedetään, mitä on tarkistettu ja missä epävarmuus säilyy. Toistettava rakennusprosessi voi tarjota vahvaa näyttöä siitä, että määritelty lähdekoodi ja määritelty ympäristö tuottivat vastaavan artefaktin. Allekirjoitettu julkaisu voi auttaa tunnistamaan avaimen, jolla julkaisu on vahvistettu. Ohjelmiston koostumusluettelo voi kuvata ilmoitetut komponentit. Mikään näistä ei yksinään todista, että koodi on vaaratonta, että kaikki välilliset riippuvuudet on tarkastettu tai että julkaisu soveltuu tiettyyn käyttötarkoitukseen. Yhdessä ne voivat tehdä myöhemmästä tutkimuksesta huomattavasti vähemmän spekulatiivista.

Tämä erottelu on tärkeä, koska alkuperäketjua myydään usein taikaleimana. Se ei ole sellainen. Hash kertoo, että kaksi tavusarjaa täsmäävät. Se ei kerro, että täsmäävän ohjelman pitäisi saada käsitellä arkaluonteisia tietueita. Allekirjoitus voi yhdistää julkaisun avaimeen. Se ei kerro, että avainta hallinnoiva henkilö noudatti hyvää tarkistusprosessia. Inventaario voi nimetä komponentin. Se ei kerro, onko komponentti konfiguroitu turvallisesti. Näyttö on edelleen näyttöä, ei korvike harkinnalle.

Alkuperäketjun puuttuminen kuitenkin heikentää harkintaa. Kun tiimi ei pysty selvittämään, mikä lähdekoodiversio loi käyttöönotetun paketin, se ei voi luotettavasti yhdistää ylävirran korjausta omaan palveluunsa. Kun tiimi ei pysty tunnistamaan välillistä riippuvuutta, se ei voi arvioida ilmoitusta tai varoitusta rekonstruoimatta ensin toimitusketjua. Kun rakennusprosessi tuottaa erilaisia tuloksia ilman selitystä, tiimi ei voi sanoa, onko binääri muuttunut lähdekoodin, ympäristön vai häiriön vuoksi. Nämä ovat käytännön rajoitteita, eivät puhtauskokeita.

Euroopan digitaalinen suvereniteetti typistetään usein palvelimen sijaintiin. Sijainnilla on merkitystä. Se ei kuitenkaan riitä. Järjestelmä voi toimia Euroopassa, vaikka se tukeutuu rakennusputkeen, riippuvuusrekisteriin tai päivityskanavaan, jota operaattori ei voi tarkastaa, hallita tai korvata. Toisaalta avoin lähdekoodi voi tarjota aidon reitin tarkastettavuuteen ja siirrettävyyteen, mutta se jättää käyttöönottajan vastuuseen kyvystä, jota tämän reitin käyttö edellyttää. Suvereniteetti on kykyä toimia paineen alla, ei lippu, joka on kiinnitetty konttikuvaan.

Hyödyllisen alkuperäketjutietueen avulla teknisesti pätevä kollega pystyy jäljittämään julkaisun sekä taaksepäin että eteenpäin. Taaksepäin: mikä lähdekoodi, mitkä riippuvuudet ja mikä rakennusprosessi johtivat tähän? Eteenpäin: mitkä palvelut, tuotteet ja käyttäjät voivat kärsiä, jos tämä komponentti muuttuu tai poistetaan? Tietue voi olla oikeasuhteinen. Pieni sisäinen työkalu ei tarvitse lentokoneohjelman koneistoa. Mutta sen on sisällettävä riittävästi totuutta tukeakseen sen käytön seurauksia.

Kyberresilienssisäädös vetää rajan teeskentelemättä, että maailma olisi yksinkertainen

Kyberresilienssisäädös tiivistetään usein uusiksi kyberturvallisuusvaatimuksiksi verkkoon kytketyille tuotteille. Tämä on totta mutta epätäydellistä. Sen hyödyllisempi panos tähän keskusteluun on erottelu, jonka se tekee roolien välillä. Vapaan ja avoimen lähdekoodin ohjelmiston ylläpitäjä voi olla yhteisö, joka tarjoaa jatkuvaa tukea digitaalisia elementtejä sisältävien, vapaana ja avoimena lähdekoodina luokiteltujen tuotteiden kehittämiselle ja jonka tarkoituksena on varmistaa näiden tuotteiden elinkelpoisuus. Säädös asettaa ehtoja tämän roolin ympärille. Se ei kohtele jokaista avustajaa samoin velvoittein kuin valmistajaa.

Tämä erottelu tunnustaa, miten avoin lähdekoodi todellisuudessa toimii. Projektissa voi olla yksittäisiä avustajia, yhdistys, säätiö, yritys joka tarjoaa tukea, jakelu joka paketoi ohjelmiston, integraattori ja valmistaja joka sisällyttää sen tuotteeseen. Näiden vastuut liittyvät toisiinsa, mutta eivät ole vaihtokelpoisia. Avustaja voi korjata virheen. Ylläpitäjä voi koordinoida projektia. Jakelija voi paketoida sen. Valmistaja voi saattaa tuotteen markkinoille. Käyttöönottaja voi päättää, miten tuote käsittelee oikeaa dataa ja oikeita ihmisiä. Julkinen säilytyspaikka on näiden roolien kohtaamispaikka, ei oikeudellinen sekoitin.

Organisaatioille turvallisin tulkinta ei ole muuttaa asetusta kansanperinteeksi ennen kuin se tulee sovellettavaksi. Asetuksessa on porrastetut soveltamispäivämäärät ja roolikohtaiset säännökset. Oikeudellinen tulkinta tulee ottaa sovellettavasta tekstistä ja asiantuntevasta neuvonnasta, erityisesti kun kyseessä on tuote, kaupallinen toiminta tai markkinoille saattaminen. Toiminnallinen valmistautuminen ei kuitenkaan tarvitse odottaa seminaaria, jossa on kylmää kahvia ja kalvo otsikolla ”yleiskatsaus”. Inventoi komponentit. Selvitä, kuka omistaa päivitykset. Säilytä julkaisutodisteet. Määritä tietoturvailmoitusten käsittelyreitti. Päätä, mitä tuettu tarkoittaa. Nämä toimet ovat hyödyllisiä riippumatta siitä, sovelletaanko tiettyä säännöstä tänään, ensi vuonna vai ei koskaan.

Asetus myös vastustaa väärää valintaa. Se ei sano, että avoin lähdekoodi on turvatonta. Se ei myöskään sano, että julkaiseminen vapauttaa kaupallisen tuotteen tietoturvatyöstä. Se tunnustaa, että tuotteissa käytetyn ohjelmiston tietoturvalla on julkisia seurauksia ja että toimijaketju tarvitsee selkeämmät vastuut. Tarkat velvoitteet ansaitsevat huolellisen oikeudellisen lukemisen. Periaate on selvä: ohjelmisto, joka tavoittaa ihmiset tuotteen kautta, tarvitsee jonkun, joka pystyy toimimaan vastuullisesti, kun riski tulee tunnetuksi.

Tämä periaate on jo tuttu muilla aloilla. Julkaistu resepti ei vapauta ravintolaa elintarviketurvallisuudesta. Julkaistu rakennusstandardi ei vapauta urakoitsijaa velvollisuudesta käyttää sitä ammattitaitoisesti. Vertailulla on rajansa: ohjelmistolisensseillä, päivityskanavilla ja kehittäjäyhteisöillä on omat rakenteensa. Mutta perusajatus siirtyy. Julkiseksi tehty tieto voi mahdollistaa riippumattoman tarkistamisen. Se ei poista vastuuta siltä, joka tarjoilee aterian tai avaa oven.

Mitä käyttöönottajat ovat velkaa itselleen

Hyödyllisin avoimen lähdekoodin käytäntö on usein toimintakäytäntö, joka on naamioitu järkeväksi tarkistuslistaksi. Sen tulisi vastata, kuka saa lisätä riippuvuuden, mitä tietoja on kirjattava, miten lisenssit tarkistetaan, miten päivitykset arvioidaan, miten tietoturvailmoitukset ohjataan ja kuka voi hyväksyä poikkeuksen. Sen tulisi myös vastata, mitä tapahtuu, kun tuki päättyy. Käytäntö, joka selittää valinnan mutta ei sano mitään poistamisesta, on vain puolikas käytäntö.

Aloita yksiköstä, jolla on todella merkitystä: käyttöönotetusta artefaktista tai palvelusta, ei abstraktista luettelosta suosikkiprojekteista. Jokaisesta merkittävästä komponentista organisaation tulisi pystyä paikantamaan versio, lähde- tai rekisterireitti, lisenssi, vastuullinen sisäinen rooli, järjestelmä jossa sitä käytetään ja päivityspolku. Yksityiskohtaisuuden tason tulisi seurata epäonnistumisen seurauksia. Tavoitteena ei ole muuttaa jokaista kehittäjää virkailijaksi. Tavoitteena on estää tärkeiden tietojen jääminen yksityiseksi tiedoksi yhteen kannettavaan tietokoneeseen tai yhden ihmisen muistiin.

Päätä sitten, mikä näyttö muuttaa päätöstä. Julkaistu tiedote voi käynnistää arvioinnin. Uusi julkaisu voi käynnistää yhteensopivuustestin. Lisenssimuutos voi käynnistää oikeudellisen tarkastelun. Hylätty tuettu versio voi käynnistää siirtymäsuunnitelman. Rakennus, jota ei voi enää toistaa, voi käynnistää tutkinnan. Ilman näitä laukaisimia inventaariot muuttuvat helposti historiallisiksi asiakirjoiksi: tarkkoja sinä päivänä kun ne vietiin, ja kohteliaasti huomiotta jätettyjä sen jälkeen.

Aseta omistajuus lähelle toimintaa. Keskitetty hallintatiimi voi asettaa politiikan ja tarjota asiantuntemusta. Se ei voi operoida jokaista palvelua. Tuotetiimi voi tuntea oman käyttöönottoarkkitehtuurinsa. Sillä ei välttämättä ole valmiuksia tulkita jokaista lisenssiä. Järjestely toimii, kun luovutus on yksiselitteinen: tuoteomistaja arvioi vaikutuksen, tietoturva neuvoo altistumisessa ja vasteessa, lakiasiat tai compliance arvioi lisenssiehdot tarvittaessa, hankinta kirjaa ulkoiset sitoumukset ja nimetty päättäjä hyväksyy tai hylkää olennaisen riskin. Nimet vaihtelevat. Nimien puuttuminen on toistuva ongelma.

Pidä yllä poistumisreittiä. Avoin lähdekoodi voi vähentää toimittajariippuvuutta, mutta vain jos organisaatio voi rakentaa uudelleen, forkata, korvata tai hankkia tukea olosuhteiden muuttuessa. Repositorion peilaus, rakennusohjeet, välimuistitettu riippuvuusreitti ja vaadittujen asetusten kirjaus voivat olla tylsää työtä, kunnes alkuperäinen palvelu ei ole käytettävissä tai suhde päättyy. Tylsällä työllä on hyvä maine hätätilanteissa.

Lopuksi ole rehellinen jäännösriskistä. Mikään riippuvuusohjelma ei voi taata, että jokainen haavoittuvuus löydetään ensimmäisenä, että jokainen ylävirran projekti pysyy aktiivisena tai että jokainen lisenssikysymys on yksinkertainen. Hallinnon tarkoitus ei ole luvata mahdotonta. Se on tehdä epävarmuudesta näkyvää riittävän varhain, jotta vastuullinen henkilö voi päättää, mitä sille tekee.

Mitä ylläpitäjät voivat kohtuudella tarjota

Ylläpitäjät eivät ole velkaa maailmalle rajattomasti työtä vain siksi, että he julkaisivat hyödyllistä koodia. Tämä odotus on sekä epäreilu että turvaton. Projekti voi olla antelias uudelleenkäytön suhteen ja samalla selkeä kapasiteetistaan. Se voi kertoa, mitä versioita tuetaan, minne tietoturvaongelmat ilmoitetaan, miten julkaisupäätökset tehdään, minkälaisia kontribuutioita se voi arvioida ja mitä se ei lupaa. Selkeät rajat ovat adoptoreille parempia kuin lämmin epämääräisyys.

Jopa pieni projekti voi parantaa operatiivista luovutusta muutamalla kestävällä dokumentilla: lisenssitiedosto, luettava julkaisuprosessi, tietoturvakontakti tai ilmoituskäytäntö, versiointitiedot, riippuvuusohjeistus tarvittaessa ja selkeä ilmoitus siitä, onko ylläpito aktiivista, rajoitettua vai päättynyttä. Mikään näistä ei luo takuuta. Jokainen auttaa loppukäyttäjää tekemään tietoisemman valinnan.

Kun projektilla on organisaation tuki, keskustelua voidaan viedä pidemmälle. Organisaatio voi julkaista tuettujen versioiden politiikan, kuvata hallintonsa, kirjata julkaisujen allekirjoituskäytäntönsä, ylläpitää haavoittuvuusvastekanavaa ja kertoa, miten käyttäjät voivat saada tukea. Nämä eivät ole laskeutumissivun kunniamerkkejä. Ne ovat operatiivisia lupauksia, ja ne tulisi kirjoittaa vain, jos organisaatio on valmis pitämään ne.

Rehellisin ylläpitoviesti voi joskus olla "emme voi ottaa tätä vastaan". Se voi tarkoittaa, että ominaisuus on laajuuden ulkopuolella, alustaa ei voida testata, tietoturvaraportti vaatii lisätietoja, haaraa ei enää tueta tai julkaisupäivää ei voida luvata. Selkeä kieltäytyminen antaa adoptoreille jotakin, jonka ympärille suunnitella. Hiljaisuus antaa heille tarinan kerrottavaksi itselleen, mikä on yleensä kalliimpi panos.

Vastuuta on myös käyttäjillä, jotka ovat riippuvaisia projektista. Ilmoita vioista riittävän yksityiskohtaisesti, jotta ne voidaan toistaa. Noudata tietoturvareittiä, jos sellainen on olemassa. Osallistu testaukseen, dokumentointiin, rahoitukseen tai arviointiin, kun mahdollista. Älä vaadi palvelusuhdetta vapaaehtoisprojektista samalla kun kieltäydyt tunnustamasta, että palvelusuhde maksaa. Vastavuoroisuus ei poista erilaisia rooleja, mutta se voi tehdä ketjusta vähemmän hauraan.

Avoin lähdekoodi voi vahvistaa vastuullisuutta

Kaikkien näiden velvollisuuksien luetteloimisen jälkeen on houkutus päätellä, että avoin lähdekoodi aiheuttaa liikaa työtä. Näin ei ole. Työ on olemassa riippumatta siitä, onko lähdekoodi näkyvissä vai ei. Suljetut riippuvuudet vaativat myös inventaarion, lisenssitietoisuuden, haavoittuvuuksiin reagoinnin, alkuperän selvittämisen ja poistumissuunnitelman. Ne vain tekevät osasta todisteita vaikeammin tarkastettavia ja osasta vaihtoehtoja vaikeammin hyödynnettäviä.

Avoin lähdekoodi voi mahdollistaa vahvemman vastuullisuusasenteen. Ostaja voi tarkastella arkkitehtuuria. Operaattori voi säilyttää kopion lähdekoodista ja rakennusohjeista. Riippumaton arvioija voi testata väitteen. Julkinen viranomainen voi välttää sen, että toimittajan yksityinen tiekartta on ainoa reitti korjaukseen. Yhteisö voi löytää ja korjata ongelman, jonka yksi organisaatio on jättänyt huomaamatta. Nämä ovat merkittäviä etuja erityisesti eurooppalaisissa ympäristöissä, joissa julkinen arvo, jatkuvuus ja haastettavuus eivät ole valinnaista koristelua.

Mutta mahdollisuus ei ole valmius. Tarkastettavuus auttaa vain sellaista, joka kykenee ja on valtuutettu tarkastamaan. Siirrettävyys auttaa vain sellaista, joka on säilyttänyt artefaktit ja osaa siirtää ne. Fork on poistumisstrategia vain silloin, kun on olemassa tiimi, budjetti ja oikeudellinen reitti, jotka kykenevät viemään sen läpi. "Koodi on GitHubissa" ei ole jatkuvuussuunnitelma, sen enempää kuin "tiedostot ovat kaapissa" on arkistointistrategia.

Avoimen lähdekoodin työmme Dwevella pitää tämän rajan näkyvissä. Knot kuvataan julkaisumateriaaleissamme allekirjoitettuna, peukaloinnin paljastavana auditointijälkenä tekoälyagenttien suorituksille, ja vastaanotetun tallenteen offline-varmennus tapahtuu julkisella avaimella. Tämä tekee väitteestä paremmin tarkastettavan. Se ei päätä, mitä organisaation tulisi lokittaa, kenellä on oikeus käyttää tallennetta, kuinka kauan sitä tulisi säilyttää tai kuka tutkii odottamattoman tuloksen. Nämä pysyvät hallintopäätöksinä työkalun ympärillä. Työkalu voi säilyttää todisteita. Se ei voi tulla kenenkään puolesta vastuulliseksi organisaatioksi.

Tämä on se vaatimaton lupaus, joka kannattaa pitää. Avoin lähdekoodi voi antaa ihmisille enemmän todisteita, enemmän vaihtoehtoja ja enemmän tilaa osallistua. Sitä ei pitäisi pyytää tarjoamaan kuvitteellista synninpäästöä ylläpidosta, tietoturvasta, lisensoinnista tai operatiivisesta harkinnasta.

Vastuu säilyy julkaisupainikkeen jälkeenkin

Lähdekoodin julkaiseminen on hyödyllinen teko. Se voi kutsua tarkastelua, madaltaa uudelleenkäytön esteitä ja tehdä teknisestä valinnasta helpommin haastettavan. Terveessä teknologiakulttuurissa julkisten laitosten ja yritysten pitäisi voida harkita avointa lähdekoodia vakavasti, tukea sitä asianmukaisesti ja selittää valintansa ilman taikauskoa.

Julkaisupainike ei kuitenkaan ole luukku, josta vastuu putoaa pois. Se ei poista tarvetta tietää, mitä tuote sisältää. Se ei korjaa käytössä olevaa palvelua. Se ei säilytä lisenssi-ilmoitusta, priorisoi tietoturvailmoitusta, ylläpidä rakennusta tai päätä, pitäisikö järjestelmä pitää käytössä. Nämä tehtävät kuuluvat edelleen ihmisille ja organisaatioille, joilla on roolit, budjetit, valtuudet ja seuraukset.

Hyvä uutinen on, että vastuullinen käytäntö ei ole mystiikkaa. Nimeä riippuvuus. Lue lisenssi. Säilytä alkuperä. Päätä, kuka omistaa päivityksen. Anna tietoturvailmoituksille reitti. Säilytä poistumistie. Kerro selvästi, mitä tuetaan ja mitä ei. Kun nämä tavat ovat olemassa, avoimesta lähdekoodista tulee enemmän kuin ele läpinäkyvyyden suuntaan. Siitä tulee infrastruktuuria, jota voidaan tarkastaa, ylläpitää ja luottaa syistä, jotka kestävät vaikean päivän.

Kysymys kysymyksen takana

Kun tiimi kysyy, onko komponentti avointa lähdekoodia, se kysyy usein samalla useita hiljaisempia kysymyksiä. Voimmeko luottaa siihen? Voimmeko jättää sen? Voimmeko muuttaa sitä? Voiko joku muu auditoida sen? Saammeko apua, kun jokin hajoaa? Lisenssi ja säilytyspaikka voivat osaltaan vastata kysymykseen, mutta kumpikaan ei yksin riitä. Luottamus seuraa todisteista, osaamisesta, kannustimista ja siitä, miten tiettyä käyttöönottoa hallinnoidaan. Lähteminen riippuu rajapinnoista, tietomuodoista, rakennusosaamisesta ja resursseista. Muuttaminen riippuu teknisestä kyvykkyydestä ja ehdoista, joilla muutos voidaan tehdä. Apu riippuu todellisesta tukisuhteesta tai kyvystä toimia ilman sellaista.

Nämä erottelut ovat puolustus sekä kyynisyyttä että toiveajattelua vastaan. Kyynisyys sanoo, että avoin lähdekoodi on vain palkatonta työtä. Toiveajattelu sanoo, että se on automaattisesti turvallisempaa, koska monet silmät saattavat pystyä tarkastamaan sen. Kumpikaan väite ei kerro käyttäjälle, mitä seuraavaksi tehdä. Käyttäjän on tiedettävä, mitkä silmät todella tarkastivat kyseisen version, kuka voi testata korjauksen, millä toimivallalla muutos tehdään ja miten tulos saavuttaa kyseisen järjestelmän. Turvallisuus on ketju varmennettuja toimia, ei sananlasku joukosta.

Sama pidättyväisyys koskee hankintaa. Avoimen lähdekoodin komponentin pyytäminen toimittajalta ei vähennä sopimuksen merkitystä. Se muuttaa kysymyksiä, joita hyvä sopimus voi esittää: mitkä ylävirran komponentit sisältyvät, miten ilmoitukset ja lähdekoodivelvoitteet hoidetaan, mitä versioita tuetaan, mitä todisteita julkaisun mukana toimitetaan, mitä korjauksille tapahtuu tukikauden aikana ja mitä aineistoa asiakas voi säilyttää jatkuvuuden turvaamiseksi. Ostajan kannattaa arvostaa kykyä tarkastaa ja siirtyä. Sen on myös hinnoiteltava kyvykkyys, jota tämän kyvyn käyttäminen edellyttää.

Ei ole hyveellistä luoda laajaa prosessia pienelle apuohjelmalle, eikä ole varovaista käyttää yhtä toimintakaaviota kriittisen palvelun hallintamallina. Oikeasuhtaisuus on tässä käytännön taitoa. Mitä laajempi altistus, mitä merkittävämmät tiedot, mitä vaikeampi palautuminen ja mitä keskeisempi komponentti, sitä vahvemmat kirjaukset ja toimintajärjestelyt tarvitaan. Tämä ei ole byrokratiaa byrokratian vuoksi. Se on yritys pitää todellinen päätös lähellä todellista seurausta.

Avoin lähdekoodi ansaitsee paikkansa eurooppalaisessa digitaalisessa infrastruktuurissa, kun se auttaa instituutioita säilymään kykenevinä: kykenevinä tarkastamaan, kykenevinä muuttamaan, kykenevinä selittämään ja kykenevinä jatkamaan. Kyvykkyys hankitaan hitaammin kuin innostus. Se vaatii aikaa, ihmisiä, dokumentaatiota, testausta ja toisinaan valmiutta rahoittaa työtä, josta ei koskaan tule konferenssin pääpuheenvuoroa. Se on myös se asia, joka jää jäljelle, kun suosittu säilytyspaikka, toimittajasuhde tai julkaisuaikataulu muuttuu ilman lupaa.

Se on vastuullisuutta hyödyllisessä, epäglamourissa ja täysin julkisessa muodossaan.

Lähteet