Odprtokodnost ni odpoved odgovornosti

Objava izvorne kode spremeni, kdo jo lahko pregleduje, ponovno uporablja in izboljšuje. Ne odpravi pa praktičnega dela ugotavljanja, kaj je nameščeno, kaj...

Odprtokodnost ni odpoved odgovornosti

Skladišče je odprtje, ne zaključek

Obstaja tolažilna zgodbica o odprtokodni programski opremi. Skupina objavi kodo. Drugi ljudje jo lahko preberejo. Koda postane skupna dobrina ali vsaj uporabna skupna nadloga. Odgovornost se raztopi v množici.

Prvi dve povedi sta lahko resnični. Zadnja ni. Javno skladišče lahko razširi pregled, ponovno uporabo in prispevke. Organizaciji lahko ponudi jasnejšo izhodno pot kot zaprta storitev. Javnemu organu lahko omogoči, da komponento preuči, ne da bi dobavitelja prosil za dovoljenje. Nobeno od tega ne odgovori na vprašanje, ki pride na povsem običajen torek zjutraj: katera različica teče tukaj, pod katero licenco, s katero konfiguracijo in kdo bo ukrepal, če varnostno priporočilo velja zanjo?

Odprtokodnost spremeni obliko odgovornosti. Ne naredi je neobvezne. Vzdrževalec ima še vedno odločitve o izdajah, varnostnih poročilih, podprtih različicah in licenciranju. Organizacija, ki pakira komponento, ima še vedno odločitve o izvoru, posodobitvah in tem, kaj sporoča svojim uporabnikom. Tisti, ki uvaja programsko opremo, ima še vedno odločitve o inventarju, izpostavljenosti, konfiguraciji, dostopu in obnovitvi. Licenca podeljuje dovoljenja in pogoje. Ne zagotavlja dežurstva.

To je pomembno, ker je odprtokodnost postala običajna infrastruktura. Je v operacijskih sistemih, brskalnikih, javnih storitvah, raziskovalnih orodjih, industrijskih sistemih in knjižnicah, zaradi katerih je izdelek videti bolj samozadosten, kot je. Zrelo vprašanje zato ni, ali je organizacija za ali proti odprtokodnosti. Temveč ali zmore nositi odgovornosti, ki jih ustvarja programska oprema, na katero se odloči zanašati.

Evropska politika je to razliko začela opisovati bolj jasno. Akt o kibernetski odpornosti ureja izdelke z digitalnimi elementi in vključuje posebno pot za skrbnike proste in odprtokodne programske opreme. Ta pot priznava, da lahko oseba ali organizacija, ki trajno podpira prosto in odprtokodno programsko opremo, zavzame resnično mesto v varnostni verigi. Vsakega prostovoljca, ki objavi kodo, ne spremeni v proizvajalca. Prav tako komercialnemu akterju ne dovoljuje, da se skriva za javnim skladiščem, ko ta akter na trg prinese izdelek.

Praktična posledica je prijetno neromantična. Vsako odvisnost obravnavajte kot nekaj, kar je treba poimenovati, razumeti in negovati. To ni napad na odprtokodnost. To je disciplina, ki odprtokodnosti omogoča, da ostane uporabna, ko novost izgine.

Kaj objava dejansko spremeni

Razpoložljivost izvorne kode spremeni več stvari hkrati. Bralec lahko preuči implementacijo, namesto da bi jo sklepal s tržne strani. Ekipa lahko ponovi izdelavo, če to omogočajo navodila za izdelavo, odvisnosti in okolje. Dobavitelja je mogoče lažje zamenjati, kadar to dopuščata licenca in vmesniki. Raziskovalec lahko preizkusi trditev, varnostna ekipa lahko pregleda popravek, javni kupec pa lahko postavlja vprašanja, ne da bi črno škatlo obravnaval kot ustavno načelo.

To so pomembne javne dobrine. So pa tudi pogojne. Koda, ki je vidna, a je ni mogoče zgraditi, je manj pregledna, kot se zdi na prvi pogled. Koda, ki jo je mogoče zgraditi, a nima jasne licence, pušča negotovost glede ponovne uporabe. Koda, ki je licencirana, a je sestavljena iz neznanih odvisnosti, nosi težavo z izvorom. Koda, ki se vzdržuje le v veji, ki je nihče ne more prepoznati, zaradi obstoja strani skladišča ni zanesljiva.

Open Source Initiative opisuje odprtokodnost prek odobrene licence in nabora pravic, vključno z dostopom do izvorne kode ter svobodo redistribucije in spreminjanja pod določenimi pogoji. Ta definicija je namenoma osredotočena na dovoljenja. Ni sporazum o ravni storitev, varnostno potrdilo, jamstvo za primernost za določeno javno nalogo niti zagotovilo, da bo komponenta vzdrževana v nedogled. Odsotnost teh obljub ni pomanjkljivost definicije. Je razlog, da smo natančni glede tega, na kaj se organizacija zanaša.

Koristno je ločiti štiri vprašanja, ki so pogosto združena v eno prijazno besedo. Ali je izvorna koda na voljo? Ali je licencirana za predvideno uporabo? Ali lahko organizacija ugotovi, od kod izvirajo koda in njene odvisnosti? Ali nekdo aktivno opravlja operativno delo, ki ga ta namestitev zahteva? Pritrdilen odgovor na prvo vprašanje ne odgovori na ostala tri.

Ta ločitev tudi naredi pogovore manj teatralne. Nabavna ekipa ne potrebuje navdušenja nad repozitorijem. Vedeti mora, ali je komponenta primerna za sistem, ki ga kupuje ali upravlja. Inženirska ekipa se ne mora opravičevati za uporabo permisivne licence. Vedeti mora, kako bo izpolnila obvestila o licenci, ohranila zahtevano gradivo, posodabljala odvisnosti in se odzvala na razkrito težavo. Pravna ekipa ne mora postati vodja izdaj. Potrebuje pa pot v proces izdajanja, preden težava z licenco postane javna poprava.

Izvorna koda lahko gre skozi več rok. Izberite plast, da ločite odgovornosti objave, pakiranja, umestitve v izdelek in namestitve.

Licenca je meja, ne vremenska napoved

Z licencami se včasih ravna kot z administrativno podrobnostjo, kot da se pravno delo začne šele po končanem inženirskem delu. V praksi izbire licenc oblikujejo inženirske odločitve že od začetka. Vplivajo na to, ali je komponento mogoče kombinirati z drugo komponento, ali morajo obvestila spremljati distribucijo, ali je treba spremenjeno izvorno kodo ponuditi v določenih okoliščinah in ali lahko ekipa izpolni pogoje, povezane s pravicami, ki jih želi uporabiti.

To ne pomeni, da mora vsak inženir postati strokovnjak za avtorske pravice. Pomeni, da organizacija potrebuje zanesljiv prevod med programsko opremo, ki jo gradi, in zavezami, ki jih sprejema, ko to programsko opremo distribuira, gosti ali spreminja. Prevajanje mora potekati, dokler so dejstva še na voljo: kateri paket je bil izbran, katera različica je bila uporabljena, ali je bil spremenjen, kako je bil povezan ali vključen, s čim se dobavlja in kakšna je predvidena pot distribucije.

Ni univerzalnega odgovora glede licence. Permisivna licenca lahko poenostavi ponovno uporabo, hkrati pa še vedno zahteva obvestila in ohranitev besedila o avtorskih pravicah. Vzajemna licenca lahko distribuciji ali spreminjanju doda dodatne pogoje. Dvojna licenca lahko od organizacije zahteva, da izbere komercialno pot ali določeno odprtokodno pot. Organizacija ne sme sklepati o obveznostih iz vzdevka licence, značke v upravitelju paketov ali napol pozabljene zgodbe sodelavca iz leta 2014. Prebrati mora besedilo licence, zabeležiti odločitev in poiskati nasvet, kadar je predvidena uporaba negotova.

Skladnost z licencami tudi ni zgolj ceremonialno opravilo, ki se izvede v tednu pred izdajo. Seznam programskih komponent, popis odvisnosti in evidenca izdaj lahko pozneje omogočijo odgovor na vprašanje: kaj je vključeval ta izdelek? Toda seznam je uporaben le, če opisuje natančno določen izdelek, različico in datum. Preglednica z imenom dependencies-final-final.xlsx ni sistem za sledenje izvoru. Je arheološka plast.

Za javno ustanovo je to več kot le urejanje evidence. Ustanova bo morda morala ohraniti zmožnost pojasniti, zakaj je bila izbrana določena komponenta, kateri pogoji jo urejajo, kako jo je mogoče zamenjati in kaj se zgodi, če se vzdrževanje preneha. Za gospodarsko družbo iste evidence vplivajo na pogodbene obveznosti, posodobitve izdelkov in komuniciranje s strankami. Za manjšo ekipo je obseg drugačen, a logika ni. Če projekt ne more ugotoviti licence kode, ki jo razširja, ne more pošteno trditi, da ima pravni okvir pod nadzorom.

Odgovorno ravnanje je sorazmerno, ne veličastno. Zabeležite neposredne odvisnosti. Shranite besedila licenc in zahtevana obvestila skupaj z izdajo. Zabeležite vsebinske spremembe. Določite točko pregleda za nove ali nenavadne licenčne pogoje. Določite osebo, odgovorno za razreševanje nejasnosti. To so skromni ukrepi. Njihova vrednost je v tem, da preprečijo, da bi nejasnost postala presenečenje, potem ko je programska oprema že zaokrožila.

Vzdrževanje je delo, tudi kadar je darovano

Vzdrževanje odprtokodne programske opreme je pogosto opisano, kot da bi šlo za osebno vrlino. Včasih tudi je. Ljudje pregledujejo popravke, odgovarjajo na vprašanja, pripravljajo izdaje in preprečujejo, da bi stare predpostavke postale jutrišnja okvara, ker jim je mar za orodje in ljudi, ki ga uporabljajo. Ta radodarnost si zasluži spoštovanje. Ne bi smela biti uporabljena kot poslovni model brez poslovne odločitve.

Vzdrževanje je operativno delo. Vključuje odločanje o tem, katere različice so podprte, pregledovanje prispevkov, objavljanje varnostnih informacij, vodenje postopka izdajanja, odzivanje na poročila, dokumentiranje nezdružljivih sprememb, ohranjanje uporabne infrastrukture za gradnjo in včasih tudi zavrnitev. Zadnji del je podcenjen. Projekt, ki ne more zavrniti zahtevka za funkcijo, nepodprte platforme ali nevarne bližnjice, ni nujno bolj odprt. Morda je le bolj izpostavljen.

Strategija Evropske komisije za odprtokodno programsko opremo obravnava odprto kodo kot način za izboljšanje ponovne uporabe, preglednosti, sodelovanja in tehnološke neodvisnosti v javni upravi. Te koristi so odvisne od zmožnosti. Ponovna uporaba zahteva, da organizacija razume, kaj ponovno uporablja. Preglednost zahteva, da nekdo prebere, kar je razkrito. Neodvisnost zahteva več kot le posedovanje gumba za kloniranje: zahteva praktično zmožnost upravljanja, prilagajanja ali zagotavljanja podpore za programsko opremo, ko se prvotni prispevalec umakne.

Zato je treba vprašanje »ali je vzdrževano?« natančneje opredeliti. Lahko pomeni, da obstajajo nedavne izdaje. Lahko pomeni, da je objavljen varnostni kontakt. Lahko pomeni, da projekt opisuje podprte različice, navodila za gradnjo in postopek prispevanja. Lahko pomeni, da je organizacija delu namenila plačan čas. Lahko pomeni, da ima uporabnik lastno zmožnost vzdrževanja razcepa ali zamenjave komponente. To so različna dejstva. Zelen graf dejavnosti je lahko koristen dokaz, ni pa pogodba o vzdrževanju.

Odgovoren uporabnik bi se moral zato odločiti, kakšno vrsto vzdrževanja potrebuje, preden se odloči, kaj upa, da bo zagotovila skupnost. Orodje za notranjo uporabo z nizkim tveganjem je lahko združljivo z manjšim projektom in skromnim načrtom posodabljanja. Komponenta v središču izdelka, izpostavljenega navzven, potrebuje jasnejši model podpore, hitrejšo oceno ranljivosti in načrt za izhod. Razlika ni v prestižu projekta. Gre za posledice napake.

Obstaja majhna nizozemska navada, ki si jo je vredno sposoditi: ne zamenjujte prijetnosti z upravljanjem. Prijazna skupnost je lahko čudovit kraj za prispevanje. Kljub temu morda nima obveznosti, da vaš produkcijski sistem ohranja v delovanju. Organizacija, ki ta sistem postavi v produkcijo, je lastnica te razlike.

Pot za prijavo varnostnih ranljivosti je pomembnejša od slogana

Večina se na abstraktni ravni strinja, da je treba ranljivosti razkrivati odgovorno. Težji del je manj abstrakten. Kam naj prijavitelj pošlje ugotovitev? Kdo jo prejme? Katere informacije so potrebne za reprodukcijo? Kdo odloči, ali vpliva na podprto različico? Kako se razvije popravek, ne da bi nastalo nepotrebno javno okno izpostavljenosti? Kako so uporabniki obveščeni, kaj naj storijo? Kateri paketi v nadaljnji verigi potrebujejo posodobitev? Kaj se zgodi, če prijavitelj ne prejme odgovora?

Ta vprašanja niso dokaz nezaupanja do odprte kode. So delo obravnavanja uporabnikov kot ljudi, ki potrebujejo odgovor. Delo agencije ENISA o razkritju ranljivosti in usklajenem razkritju ranljivosti opisuje vrednost opredeljenih postopkov med prijavitelji, prodajalci in drugimi ustreznimi stranmi. Postopek ne more zagotoviti, da je vsako poročilo pravilno ali da je vsak popravek hiter. Lahko zmanjša možnost, da resna težava začne svojo pot v nenadzorovanem nabiralniku.

Projekt lahko objavi varnostno politiko, naslov za prijave in informacije o podprtih različicah. To so uporabni signali, zlasti kadar opisujejo, kaj lahko prijavitelj pričakuje. Projekt je lahko tudi premajhen, da bi zagotovil odzivni čas, ki ga potrebuje pomembna namestitev. To ni moralni neuspeh. To je načrtovalno dejstvo za organizacijo, ki izbira odvisnost.

Enako velja v nadaljnji verigi. Proizvajalec ne more razumno trditi, da je ranljivost problem nekoga drugega, zgolj zato, ker se je ranljiva komponenta začela v odprtem repozitoriju. Če proizvajalec na trg Unije da izdelek z digitalnimi elementi, uredba o kibernetski odpornosti določa zahteve glede obravnave ranljivosti in zagotavljanja varnostnih posodobitev v okviru, ki velja za izdelek. Pravne podrobnosti so odvisne od izdelka in vloge. Operativna poanta je preprostejša: stranka, ki daje izdelek na voljo, mora imeti način, kako ugotoviti, ali sprememba v zgornjem delu verige vpliva na to, kar je dobavila.

Tu inventar postane dejaven in ne zgolj okrasen. Povezati mora komponento z različico, gradnjo, izdajo izdelka in lastnikom, ki lahko oceni poročilo. Lastniku ni treba samemu odpraviti vsake napake v zgornjem delu verige. Mora pa se odločiti, ali bo komponento posodobil, ublažil tveganje, onemogočil, prijavil, nadomestil ali prenehal uporabljati. »Uporabljamo odprto kodo« je opis vhoda. Ni načrt odzivanja.

Razmislite o izrecno hipotetičnem primeru. Ekipa vključi knjižnico v storitev za obdelavo dokumentov. Mesece pozneje varnostno priporočilo opredeli ranljiv obseg. Če je ekipa zabeležila komponento, različico in storitve, v katere je vgrajena, lahko začne z oceno. Če lahko ponovi gradnje in preizkusi posodobitev, se lahko odloči, ali je rešitev nadgradnja, sprememba konfiguracije ali začasna omejitev. Če nima niti evidence niti lastnika, je prva naloga detektivsko delo. Ranljivost je v obeh primerih lahko enaka. Operativno tveganje ni.

Pot razkritja ne obljublja, da je vsaka težava majhna. Ko je težava odkrita, naredi naslednje odgovorno dejanje vidno.

Izvor je odgovor na vprašanje »kaj točno izvajamo?«

Izvor programske opreme lahko zveni kot beseda, izposojena z muzejskih etiket. Temeljno vprašanje je povsem običajno: od kod ta artefakt izvira in ali lahko pokažemo pot? Pri programski opremi lahko pot vključuje repozitorije izvorne kode, objavljene arhive, registre odvisnosti, orodja za gradnjo, konfiguracijo, podpisne ključe, okolja za gradnjo in sisteme za objavo. Odgovor je le redko en sam eleganten podatek. Gre za zbirko zapisov, ki se morajo dovolj dobro ujemati, da lahko človek sprejme odločitev.

Izvor od organizacije ne zahteva, da trdi, da ima popolno znanje. Zahteva, da pove, kaj je znano, kaj je bilo preverjeno in kje ostaja negotovost. Ponovljiva gradnja lahko zagotovi močne dokaze, da sta določena izvorna koda in določeno okolje ustvarila ustrezen artefakt. Podpisana objava lahko pomaga prepoznati ključ, uporabljen za potrditev objave. Seznam sestavnih delov programske opreme lahko opiše prijavljene komponente. Nobena od teh stvari sama po sebi ne dokazuje, da je koda neškodljiva, da je bila pregledana vsaka tranzitivna odvisnost ali da je objava primerna za določeno uporabo. Skupaj pa lahko poznejšo preiskavo naredijo precej manj špekulativno.

To razlikovanje je pomembno, ker se izvor pogosto prodaja kot čarobni žig. Ni. Zgoščena vrednost vam lahko pove, da se dva niza bajtov ujemata. Ne more vam povedati, ali sme ujemajoči se program obdelovati občutljive zapise. Podpis lahko objavo poveže s ključem. Ne more vam povedati, ali je oseba, ki nadzoruje ključ, upoštevala dober postopek pregleda. Inventar lahko poimenuje komponento. Ne more vam povedati, ali je komponenta varno konfigurirana. Dokazi so še vedno dokazi, ne nadomestilo za presojo.

A vendar odsotnost izvora poslabša presojo. Ko ekipa ne more ugotoviti, katera revizija izvorne kode je ustvarila nameščeni paket, ne more z gotovostjo povezati popravka pri nadrejenem projektu s svojo storitvijo. Ko ne more prepoznati tranzitivne odvisnosti, ne more oceniti obvestila ali priporočila, ne da bi najprej rekonstruirala dobavno verigo. Ko gradnja brez pojasnila daje različne rezultate, ne more ugotoviti, ali se je binarna datoteka spremenila zaradi izvorne kode, okolja ali vmešavanja. To so praktične omejitve, ne testi čistosti.

Evropska digitalna suverenost se pogosto skrči na lokacijo strežnika. Lokacija je pomembna. A ni dovolj. Sistem lahko deluje v Evropi, medtem ko se zanaša na cevovod za gradnjo, register odvisnosti ali kanal za posodobitve, ki ga upravljavec ne more pregledati, nadzorovati ali zamenjati. Po drugi strani lahko odprta koda ponudi resnično pot do preglednosti in prenosljivosti, a hkrati uporabniku pusti odgovornost za zmogljivosti, potrebne za uporabo te poti. Suverenost je sposobnost delovanja pod pritiskom, ne zastava, pripeta k vsebniku.

Uporaben zapis o izvoru bi moral tehnično usposobljenemu sodelavcu omogočiti, da objavo zasleduje v obe smeri. Nazaj: katera izvorna koda, odvisnosti in postopek gradnje so pripeljali do tega? Naprej: katere storitve, izdelki in uporabniki so lahko prizadeti, če se ta komponenta spremeni ali umakne? Zapis je lahko sorazmeren. Majhno notranje orodje ne potrebuje mehanizmov programa za letala. Potrebuje pa dovolj resnice, da podpre posledice svoje uporabe.

Akt o kibernetski odpornosti potegne črto, ne da bi se pretvarjal, da je svet preprost

Akt o kibernetski odpornosti se pogosto povzema kot nov niz zahtev za kibernetsko varnost povezanih izdelkov. To je res, a nepopolno. Njegov koristnejši prispevek k tej razpravi je razlikovanje med vlogami. Skrbnik proste in odprtokodne programske opreme je lahko subjekt, ki zagotavlja stalno podporo razvoju izdelkov z digitalnimi elementi, opredeljenih kot prosta in odprtokodna programska oprema, in je zasnovan tako, da zagotavlja sposobnost preživetja teh izdelkov. Uredba določa pogoje za to vlogo. Vsakega prispevajočega ne obravnava, kot da nosi enake obveznosti kot proizvajalec.

To razlikovanje priznava, kako odprta koda dejansko deluje. Projekt ima lahko posamezne prispevnike, društvo, fundacijo, podjetje, ki nudi podporo, distribucijo, ki pakira programsko opremo, integratorja in proizvajalca, ki jo vključi v izdelek. Njihove odgovornosti so povezane, a ne zamenljive. Prispevnik lahko odpravi napako. Skrbnik lahko usklajuje projekt. Distributer ga lahko pakira. Proizvajalec lahko da izdelek na trg. Uvajalec se lahko odloči, kako ta izdelek obravnava resnične podatke in resnične ljudi. Javno skladišče je prostor srečanja teh vlog, ne pravni mešalnik.

Za organizacije je najvarneje, da uredbe ne spremenijo v folkloro, preden začne veljati. Akt ima postopne datume začetka uporabe in določbe, specifične za posamezne vloge. Pravno razlago je treba črpati iz veljavnega besedila in strokovnega nasveta, zlasti kadar gre za izdelek, gospodarsko dejavnost ali dajanje na trg. Operativne priprave pa ni treba odlagati na seminar s hladno kavo in prosojnico z naslovom »pregled«. Popišite komponente. Ugotovite, kdo je lastnik posodobitev. Shranjujte dokaze o izdajah. Vzpostavite pot za prijavo varnostnih težav. Opredelite, kaj pomeni podpora. Ta dejanja so koristna, ne glede na to, ali posamezna določba velja danes, prihodnje leto ali sploh ne.

Akt se tudi upira lažni izbiri. Ne pravi, da je odprta koda nevarna. Prav tako ne pravi, da objava komercialnega izdelka odvezuje varnostnega dela. Priznava, da ima varnost programske opreme, uporabljene v izdelkih, javne posledice in da veriga akterjev potrebuje jasnejše odgovornosti. Natančne obveznosti si zaslužijo skrbno pravno branje. Načelo je preprosto: programska oprema, ki do ljudi pride prek izdelka, potrebuje nekoga, ki lahko odgovorno ukrepa, ko tveganje postane znano.

To načelo je že znano na drugih področjih. Objavljen recept ne odvezuje restavracije predpisov o varnosti hrane. Objavljen gradbeni standard ne razbremeni izvajalca dolžnosti, da ga strokovno uporablja. Primerjava ima meje: licence programske opreme, kanali posodobitev in razvojne skupnosti imajo svoje strukture. Toda osnovno sporočilo se prenese. Javno znanje lahko omogoči neodvisno preverjanje. Ne odstrani odgovornosti strani, ki postreže obrok ali odpre vrata.

Kaj si sprejemniki dolgujejo samim sebi

Najbolj uporabna politika odprte kode je pogosto operativna politika, preoblečena v razumen kontrolni seznam. Odgovoriti mora, kdo lahko uvede odvisnost, katere informacije je treba zabeležiti, kako se pregledujejo licence, kako se ocenjujejo posodobitve, kako se usmerjajo varnostna poročila in kdo lahko odobri izjemo. Odgovoriti mora tudi, kaj se zgodi, ko podpora preneha. Politika, ki pojasnjuje izbiro, o odstranitvi pa nima ničesar povedati, je le polovična politika.

Začnite z enoto, ki dejansko šteje: z uvedenim artefaktom ali storitvijo, ne z abstraktnim katalogom priljubljenih projektov. Za vsako pomembno komponento bi morala organizacija znati poiskati različico, pot do izvorne kode ali registra, licenco, odgovorno notranjo vlogo, sistem, v katerem se uporablja, in pot posodabljanja. Raven podrobnosti naj sledi posledicam napake. Cilj ni spremeniti vsakega razvijalca v pisarniškega uslužbenca. Cilj je preprečiti, da bi pomembna dejstva postala zasebno znanje v enem prenosniku ali spominu ene osebe.

Nato določite, kateri dokazi bodo spremenili odločitev. Objavljeno priporočilo lahko sproži oceno. Nova izdaja lahko sproži preizkus združljivosti. Sprememba licence lahko sproži pravni pregled. Opuščena podprta različica lahko sproži načrt selitve. Gradnja, ki je ni več mogoče ponoviti, lahko sproži preiskavo. Brez teh sprožilcev popisi pogosto postanejo zgodovinski dokumenti: natančni na dan izvoza, pozneje pa vljudno spregledani.

Postavite lastništvo blizu dejanja. Osrednja ekipa za upravljanje lahko določa politike in zagotavlja strokovno znanje. Ne more upravljati vsake storitve. Produktna ekipa lahko pozna arhitekturo lastne namestitve. Morda ni opremljena za razlago vsake licence. Dogovor deluje, ko je predaja izrecna: lastnik produkta oceni vpliv, varnost svetuje glede izpostavljenosti in odziva, pravna ali skladnostna služba po potrebi oceni licenčne pogoje, nabava zabeleži zunanje obveznosti, imenovani odločevalec pa sprejme ali zavrne materialno tveganje. Imena se bodo razlikovala. Odsotnost imen je ponavljajoča se težava.

Ohranite izhodno pot. Odprta koda lahko zmanjša zaklenjenost, vendar le, če lahko organizacija ob spremenjenih okoliščinah sistem obnovi, razcepi, zamenja ali najame podporo zanj. Zrcalo repozitorija, navodila za izdelavo, predpomnjena pot do odvisnosti in zapis zahtevane konfiguracije so lahko dolgočasno delo, dokler prvotna storitev ni nedosegljiva ali se razmerje ne konča. Dolgočasno delo ima v izrednih razmerah dober ugled.

Nazadnje bodite iskreni glede preostalega tveganja. Noben program za upravljanje odvisnosti ne more zagotoviti, da bo vsaka ranljivost odkrita prva, da bo vsak projekt pri nadrejenih ostal aktiven ali da bo vsako licenčno vprašanje preprosto. Namen upravljanja ni obljubljati nemogočega. Namen je narediti negotovost vidno dovolj zgodaj, da se odgovorna oseba lahko odloči, kaj storiti z njo.

Kaj lahko vzdrževalci razumno ponudijo

Vzdrževalci svetu ne dolgujejo neomejenega dela samo zato, ker so objavili uporabno kodo. To pričakovanje je tako nepravično kot nevarno. Projekt je lahko radodaren glede ponovne uporabe, hkrati pa jasen glede svojih zmožnosti. Lahko pove, katere različice so podprte, kam prijaviti varnostne težave, kako se sprejemajo odločitve o izdajah, kakšne vrste prispevkov lahko pregleda in česa ne obljublja. Jasne meje so za uporabnike boljše kot topla dvoumnost.

Tudi majhen projekt lahko izboljša operativno predajo z nekaj trajnimi dokumenti: datoteko z licenco, berljivim postopkom izdajanja, varnostnim kontaktom ali politiko razkritja, informacijami o različicah, po potrebi smernicami o odvisnostih in jasno izjavo o tem, ali je vzdrževanje aktivno, omejeno ali zaključeno. Nobena od teh stvari ne ustvarja jamstva. Vsaka pomaga uporabniku v nadaljevanju sprejeti bolj informirano odločitev.

Kadar ima projekt organizacijsko podporo, lahko pogovor seže dlje. Organizacija lahko objavi politiko podprtih različic, opiše svoje upravljanje, zabeleži prakso podpisovanja izdaj, vzdržuje pot za odzivanje na ranljivosti in pojasni, kako lahko uporabniki dobijo podporo. To niso značke za uvodno stran. To so operativne obljube, ki jih je treba zapisati le tam, kjer jih je organizacija pripravljena izpolniti.

Najbolj iskreno sporočilo o vzdrževanju je lahko včasih »tega ne moremo prevzeti«. To lahko pomeni, da je funkcija zunaj obsega, da platforme ni mogoče preizkusiti, da varnostno poročilo potrebuje več informacij, da veja ni več podprta ali da datuma izdaje ni mogoče obljubiti. Jasna zavrnitev daje uporabnikom nekaj, na kar se lahko naslonijo pri načrtovanju. Molk jim daje zgodbo, ki si jo pripovedujejo sami, kar je na splošno dražji vložek.

Odgovornost obstaja tudi za uporabnike, ki so odvisni od projekta. Prijavite napake z dovolj podrobnostmi za reprodukcijo. Upoštevajte varnostno pot, če obstaja. Prispevajte s testiranjem, dokumentacijo, financiranjem ali pregledom, kjer je to mogoče. Ne zahtevajte razmerja storitve od prostovoljnega projekta, hkrati pa ne priznavajte, da razmerje storitve stane denar. Vzajemnost ne odpravlja različnih vlog, lahko pa naredi verigo manj krhko.

Odprta koda lahko okrepi odgovornost

Po naštevanju vseh teh dolžnosti se človek morda skuša zaključiti, da odprta koda ustvarja preveč dela. Ne ustvarja. Delo obstaja ne glede na to, ali je koda vidna ali ne. Zaprte odvisnosti prav tako potrebujejo popis, poznavanje licenc, odzivanje na ranljivosti, sledljivost izvora in izhodni načrt. Le nekatere dokaze naredijo težje pregledne in nekatere alternative težje izvedljive.

Odprta koda lahko omogoči močnejši položaj odgovornosti. Kupec lahko pregleda arhitekturo. Upravljavec lahko obdrži kopijo kode in navodila za izdelavo. Neodvisni ocenjevalec lahko preizkusi trditev. Javni organ se lahko izogne temu, da bi bil zasebni načrt dobavitelja edina pot do popravka. Skupnost lahko najde in odpravi težavo, ki jo je ena organizacija spregledala. To so pomembne prednosti, zlasti v evropskem okolju, kjer javna vrednost, kontinuiteta in izpodbojnost niso neobvezen okras.

Toda možnost ni dokončanje. Preglednost pomaga le tistemu, ki je sposoben in pooblaščen za pregled. Prenosljivost pomaga le tistemu, ki je ohranil artefakte in ve, kako jih premakniti. Razcep je izhodna strategija le, kadar obstajajo ekipa, proračun in pravna pot, ki ga lahko nosijo. »Koda je na GitHubu« ni načrt kontinuitete, prav tako kot »datoteke so v omari« ni arhivska strategija.

Naše delo z odprto kodo pri Dweve ohranja to mejo v vidnem polju. Knot je v naših objavljenih gradivih opisan kot podpisana, zaščitena pred posegi revizijska sled za izvajanja agentov AI, s preverjanjem prejetega zapisa brez povezave z uporabo javnega ključa. To naredi trditev bolj pregledno. Ne odloča o tem, kaj naj organizacija beleži, kdo lahko dostopa do zapisa, kako dolgo naj ga hrani ali kdo preiskuje nepričakovan rezultat. To ostajajo upravljavske odločitve okoli orodja. Orodje lahko ohrani dokaze. Ne more postati odgovorna organizacija v imenu kogar koli.

To je skromna obljuba, ki jo je vredno držati. Odprta koda lahko ljudem da več dokazov, več možnosti in več prostora za prispevanje. Od nje ne bi smeli pričakovati, da ponudi izmišljeno odvezo od vzdrževanja, varnosti, licenciranja ali operativne presoje.

Odgovornost preživi gumb za objavo

Objavljanje izvorne kode je koristno dejanje. Lahko spodbudi pregled, zniža ovire za ponovno uporabo in olajša izpodbijanje tehnične odločitve. V zdravi tehnološki kulturi bi moralo biti običajno, da javne institucije in podjetja odprto kodo jemljejo resno, jo ustrezno podpirajo in svoje odločitve pojasnjujejo brez vraževerja.

Gumb za objavo pa ni past pod odgovornostjo. Ne odpravlja potrebe po poznavanju vsebine izdelka. Ne popravi nameščene storitve. Ne ohranja obvestila o licenci, ne razvršča razkritja, ne vzdržuje izdelave in ne odloča o tem, ali naj sistem ostane v uporabi. Te naloge še vedno pripadajo ljudem in organizacijam z vlogami, proračuni, pooblastili in posledicami.

Dobra novica je, da odgovorna praksa ni mistična. Poimenujte odvisnost. Preberite licenco. Ohranite sledljivost izvora. Odločite, kdo je lastnik posodobitve. Dajte varnostnim poročilom pot. Ohranite izhod. Jasno povejte, kaj je podprto in kaj ni. Ko so te navade prisotne, odprta koda postane več kot gesta k preglednosti. Postane infrastruktura, ki jo je mogoče pregledati, vzdrževati in ji zaupati iz razlogov, ki preživijo tudi težak dan.

Vprašanje pod vprašanjem

Ko ekipa vpraša, ali je komponenta odprtokodna, pogosto hkrati postavlja več tišjih vprašanj. Ali ji lahko zaupamo? Ali jo lahko zapustimo? Ali jo lahko spremenimo? Ali jo lahko kdo drug preveri? Ali dobimo pomoč, ko se kaj pokvari? Licenca in repozitorij lahko prispevata k odgovoru, a nobeden od njiju ne more odgovoriti sam. Zaupanje izhaja iz dokazov, usposobljenosti, spodbud in načina upravljanja posamezne namestitve. Zapustitev je odvisna od vmesnikov, podatkovnih formatov, znanja o izdelavi in virov. Spreminjanje je odvisno od tehnične zmogljivosti in pogojev, pod katerimi je spremembo mogoče narediti. Pomoč je odvisna od dejanskega razmerja podpore ali zmožnosti delovanja brez nje.

Ta razlikovanja so obramba tako pred cinizmom kot pred željnim mišljenjem. Cinizem pravi, da je odprta koda zgolj neplačano delo. Željno mišljenje pravi, da je samodejno varnejša, ker bi jo lahko pregledalo veliko oči. Nobena od teh trditev operaterju ne pove, kaj naj stori naprej. Operater mora vedeti, katere oči so dejansko pregledale ustrezno različico, kdo lahko preizkusi popravek, katera pooblastila obstajajo za spremembo in kako rezultat doseže prizadeti sistem. Varnost je veriga preverjenih dejanj, ne pregovor o množicah.

Enaka zadržanost velja za javna naročila. Zahtevati od dobavitelja odprtokodno komponento ne pomeni, da je pogodba manj pomembna. Spremeni vprašanja, ki jih lahko postavi dobra pogodba: katere nadrejene komponente so vključene, kako bodo obravnavana obvestila in obveznosti glede izvorne kode, katere različice so podprte, kateri dokazi spremljajo izdajo, kaj se zgodi s popravki v času podpore in katero gradivo lahko stranka obdrži za zagotavljanje kontinuitete. Kupec bi moral ceniti zmožnost pregleda in selitve. Prav tako bi moral ovrednotiti zmogljivost, potrebno za uporabo te zmožnosti.

Ni nobene vrline v ustvarjanju obsežnega postopka za majhen pripomoček in ni nobene preudarnosti v uporabi enega samega diagrama aktivnosti kot modela upravljanja za kritično storitev. Sorazmernost je tu praktična veščina. Širša kot je izpostavljenost, pomembnejši kot so podatki, težje kot je okrevanje in bolj osrednja kot je komponenta, močnejši naj bodo zapisi in operativni dogovori. To ni birokracija sama sebi namen. Je poskus, da se resnična odločitev ohrani blizu resnične posledice.

Odprta koda si zasluži svoje mesto v evropski digitalni infrastrukturi, ko institucijam pomaga ostati zmožne: zmožne preverjati, zmožne spreminjati, zmožne pojasnjevati in zmožne nadaljevati. Zmogljivost se pridobiva počasneje kot navdušenje. Potrebuje čas, ljudi, dokumentacijo, testiranje in občasno pripravljenost financirati delo, ki nikoli ne bo postalo uvodno predavanje na konferenci. Je tudi tisto, kar ostane, ko se priljubljen repozitorij, razmerje z dobaviteljem ali načrt izdaj spremeni brez vprašanja za dovoljenje.

To je odgovornost v svoji uporabni, neugledni, povsem javni obliki.

Viri