Otvoreni kod nije odricanje od odgovornosti

Objavljivanje izvornog koda mijenja tko ga može pregledati, ponovno koristiti i poboljšati. Ne uklanja praktičan posao poznavanja onoga što je...

Otvoreni kod nije odricanje od odgovornosti

Repozitorij je početak, a ne kraj

Postoji utješna mala priča o otvorenom kodu. Skupina objavi kod. Drugi ljudi mogu ga čitati. Kod postaje zajedničko dobro ili barem korisna zajednička smetnja. Odgovornost se raspusti u masi.

Prve dvije rečenice možda su istinite. Posljednja nije. Javni repozitorij može proširiti uvid, ponovnu upotrebu i doprinos. Organizaciji može pružiti jasniji izlazni put od zatvorene usluge. Javnom tijelu može omogućiti da ispita komponentu bez traženja dopuštenja od dobavljača. Ništa od toga ne odgovara na pitanje koje stigne običnog utorkom ujutro: koja inačica ovdje radi, pod kojom licencijom, s kojom konfiguracijom i tko će djelovati ako se sigurnosno upozorenje odnosi na nju?

Otvoreni kod mijenja oblik odgovornosti. Ne čini odgovornost neobveznom. Održavatelj i dalje mora donositi odluke o izdanjima, sigurnosnim izvješćima, podržanim inačicama i licenciranju. Organizacija koja pakira komponentu i dalje mora donositi odluke o podrijetlu, ažuriranjima i onome što govori svojim korisnicima. Onaj tko postavlja softver i dalje mora donositi odluke o inventaru, izloženosti, konfiguraciji, pristupu i oporavku. Licencija daje dopuštenja i uvjete. Ne pruža raspored dežurstava.

To je važno jer je otvoreni kod postao obična infrastruktura. Nalazi se u operativnim sustavima, preglednicima, javnim službama, istraživačkim alatima, industrijskim sustavima i knjižnicama koje proizvod čine samodostatnijim nego što jest. Zrelo pitanje stoga nije je li organizacija za ili protiv otvorenog koda. Pitanje je može li nositi odgovornosti koje stvara softver o kojem odluči ovisiti.

Europska politika počela je jasnije opisivati tu razliku. Uredba o kibersigurnosti (Cyber Resilience Act) uređuje proizvode s digitalnim elementima i uključuje poseban put za skrbnike slobodnog softvera otvorenog koda. Taj put priznaje da osoba ili organizacija koja pruža trajnu podršku slobodnom softveru otvorenog koda može zauzeti stvarno mjesto u sigurnosnom lancu. Ne pretvara svakog volontera koji objavi kod u proizvođača. Jednako tako, ne dopušta komercijalnom akteru da se sakrije iza javnog repozitorija kada taj akter donosi proizvod na tržište.

Praktična posljedica ugodno je neromantična. Prema svakoj ovisnosti odnosite se kao prema nečemu što se mora imenovati, razumjeti i čuvati. To nije napad na otvoreni kod. To je disciplina koja omogućuje da otvoreni kod ostane koristan kada novost prođe.

Što objavljivanje zapravo mijenja

Dostupnost izvornog koda mijenja nekoliko stvari odjednom. Čitatelj može ispitati implementaciju umjesto da je zaključuje s marketinške stranice. Tim može ponoviti izradu ako to dopuštaju upute za izradu, ovisnosti i okruženje. Dobavljač se može lakše zamijeniti kada licencija i sučelja to dopuštaju. Istraživač može provjeriti tvrdnju, sigurnosni tim može pregledati zakrpu, a javni kupac može postavljati pitanja bez tretiranja crne kutije kao ustavnog načela.

To su značajna javna dobra. Također su uvjetovana. Kod koji je vidljiv, ali ga je nemoguće izraditi, manje je preglediv nego što se čini. Kod koji se može izraditi, ali nema jasnu licenciju, ostavlja ponovnu upotrebu nesigurnom. Kod koji je licenciran, ali je sastavljen od nepoznatih ovisnosti, nosi problem podrijetla. Kod koji se održava samo u grani koju nitko ne može identificirati ne postaje pouzdan zbog činjenice da stranica repozitorija postoji.

Open Source Initiative opisuje otvoreni kod kroz odobrenu licencu i skup prava, uključujući pristup izvornom kodu te slobodu redistribucije i izmjene pod propisanim uvjetima. Ta je definicija namjerno usmjerena na dopuštenja. Ona nije ugovor o razini usluge, certifikat sigurnosti, jamstvo prikladnosti za određenu javnu zadaću ni jamstvo da će se komponenta održavati neograničeno. Nepostojanje tih jamstava nije nedostatak definicije. To je razlog da se bude precizan oko toga na što se organizacija oslanja.

Korisno je razdvojiti četiri pitanja koja su često spojena u jednu prijateljsku riječ. Je li izvorni kod dostupan? Je li licenciran za namjeravanu upotrebu? Može li organizacija utvrditi odakle kod i njegove ovisnosti potječu? Nosi li netko aktivno operativni posao koji ovo uvođenje zahtijeva? Potvrdan odgovor na prvo pitanje ne odgovara na ostala tri.

To razdvajanje također čini razgovore manje teatralnima. Tim za nabavu ne mora glumiti oduševljenje prema repozitoriju. Treba znati je li komponenta prikladna za sustav koji kupuje ili kojim upravlja. Inženjerski tim ne mora se ispričavati zbog korištenja permisivne licence. Treba znati kako će ispuniti obavijesti o licenci, sačuvati potrebne materijale, ažurirati ovisnosti i odgovoriti na objavljeni problem. Pravni tim ne mora postati voditelj izdanja. Treba put do procesa izdavanja prije nego problem s licencom postane javna ispravka.

Izvorni kod može proći kroz više ruku. Odaberite sloj kako biste razlikovali odgovornosti objave, pakiranja, plasmana proizvoda i uvođenja.

Licenca je granica, a ne vremenska prognoza

Licence se ponekad tretiraju kao administrativni detalj, kao da pravni posao počinje nakon što je inženjerski posao završen. U praksi izbor licence oblikuje inženjerske odluke od samog početka. Utječe na to može li se komponenta kombinirati s drugom komponentom, moraju li obavijesti pratiti distribuciju, mora li se izmijenjeni izvorni kod ponuditi u određenim okolnostima te može li tim ispuniti uvjete vezane uz prava koja želi koristiti.

To ne znači da svaki inženjer mora postati stručnjak za autorska prava. Znači da organizacija treba pouzdan prijevod između softvera koji gradi i obveza koje preuzima kada taj softver distribuira, hosta ili mijenja. Prijevod se mora dogoditi dok su činjenice još dostupne: koji je paket odabran, koja je verzija korištena, je li promijenjen, kako je povezan ili uključen, s čime se isporučuje i koji je namjeravani put distribucije.

Ne postoji univerzalni odgovor o licenci. Permisivna licenca može pojednostaviti ponovnu upotrebu, a istovremeno zahtijevati obavijesti i čuvanje teksta o autorskim pravima. Recipročna licenca može dodati dodatne uvjete distribuciji ili izmjeni. Dvostruko licenciranje može zahtijevati da organizacija odabere komercijalni put ili određeni put otvorenog koda. Organizacija ne bi trebala zaključivati o obvezama na temelju nadimka licence, značke upravitelja paketa ili polovično zapamćene priče kolege iz 2014. Trebala bi pročitati tekst licence, zabilježiti odluku i zatražiti savjet tamo gdje je namjeravana upotreba nesigurna.

Usklađenost s licencama također nije ceremonijalna vježba koja se provodi u tjednu izdavanja. Softverski popis sastavnica, inventar ovisnosti i zapis o izdanju mogu kasnije učiniti odgovorivim pitanje: što je bilo uključeno u ovaj artefakt? No popis je koristan samo ako opisuje definirani artefakt, verziju i datum. Proračunska tablica pod nazivom dependencies-final-final.xlsx nije sustav provjere podrijetla. To je arheološki sloj.

Za javnu instituciju to je više od pukog administrativnog posla. Institucija će možda morati zadržati mogućnost objašnjenja zašto je odabrana određena sastavnica, koji uvjeti njome upravljaju, kako se može zamijeniti i što se događa ako prestane održavanje. Za komercijalnu organizaciju isti zapisi utječu na ugovorne obveze, ažuriranja proizvoda i komunikaciju s kupcima. Za mali tim razmjer je drukčiji, ali logika nije. Ako projekt ne može utvrditi licencu koda koji distribuira, ne može pošteno reći da je pravna granica pod kontrolom.

Odgovoran potez je proporcionalan, a ne grandiozan. Zabilježite izravne ovisnosti. Sačuvajte tekstove licenci i potrebne obavijesti uz izdanje. Zabilježite materijalne izmjene. Odredite točku pregleda za nove ili neobične uvjete licenciranja. Odredite nekoga tko je odgovoran za rješavanje neizvjesnosti. To su skromne kontrole. Njihova je vrijednost u tome što sprječavaju da neizvjesnost postane iznenađenje nakon što je softver otputovao.

Održavanje je posao, čak i kada je darovano

Održavanje otvorenog koda često se opisuje kao da je osobna vrlina. Ponekad i jest. Ljudi pregledavaju zakrpe, odgovaraju na pitanja, pripremaju izdanja i sprječavaju da stare pretpostavke postanu sutrašnji prekid rada jer im je stalo do alata i ljudi koji ga koriste. Ta velikodušnost zaslužuje poštovanje. Ne bi se smjela koristiti kao poslovni model bez poslovne odluke.

Održavanje je operativni posao. Uključuje odlučivanje koje su verzije podržane, pregled doprinosa, objavljivanje sigurnosnih informacija, upravljanje postupkom izdavanja, odgovaranje na prijave, dokumentiranje promjena koje narušavaju kompatibilnost, održavanje infrastrukture za izgradnju uporabljivom i, ponekad, odbijanje. Posljednji dio je podcijenjen. Projekt koji ne može odbiti zahtjev za značajkom, nepodržanu platformu ili nesigurnu prečicu nije nužno otvoreniji. Možda je jednostavno izloženiji.

Strategija Europske komisije za softver otvorenog koda tretira otvoreni kod kao način poboljšanja ponovne uporabe, transparentnosti, suradnje i tehnološke neovisnosti u javnoj upravi. Te koristi ovise o sposobnosti. Ponovna uporaba zahtijeva od organizacije da razumije što ponovno upotrebljava. Transparentnost zahtijeva da netko pročita ono što je objavljeno. Neovisnost zahtijeva više od posjedovanja gumba za kloniranje: zahtijeva praktičnu sposobnost upravljanja softverom, prilagodbe ili nabave podrške za njega kada je izvorni suradnik otišao dalje.

Zato pitanju „je li održavan?” treba dati više oblika. Može značiti da postoje nedavna izdanja. Može značiti da je objavljen sigurnosni kontakt. Može značiti da projekt opisuje podržane verzije, upute za izgradnju i postupak doprinošenja. Može značiti da je organizacija posvetila plaćeno vrijeme tom poslu. Može značiti da onaj tko primjenjuje softver ima vlastitu sposobnost održavati fork ili zamijeniti sastavnicu. To su različite činjenice. Zeleni grafikon aktivnosti može biti koristan dokaz, ali nije ugovor o održavanju.

Odgovoran usvojitelj stoga treba odlučiti kakvu vrstu održavanja treba prije nego što odluči što se nada da će zajednica pružiti. Interni alat niskog rizika može biti kompatibilan s malim projektom i skromnim planom ažuriranja. Sastavnica u središtu proizvoda izloženog vanjskim korisnicima treba jasniji model podrške, bržu procjenu ranjivosti i plan izlaska. Razlika nije u prestižu projekta. Riječ je o posljedicama pogreške.

Postoji jedan mali nizozemski običaj koji vrijedi posuditi: ne miješajte gezellig s upravljanjem. Zajednica koja je gostoljubiva može biti prekrasno mjesto za doprinos. No ona i dalje može imati nikakvu obvezu održavati vaš produkcijski sustav u pogonu. Organizacija koja taj sustav stavlja u produkciju snosi razliku.

Prijava sigurnosnih propusta treba put prije nego slogan

Većina se ljudi, u načelu, slaže da o ranjivostima treba izvještavati odgovorno. Teži dio je manje načelan. Gdje izvjestitelj šalje nalaz? Tko ga prima? Koje su informacije potrebne za reprodukciju? Tko odlučuje utječe li na podržanu verziju? Kako se popravak razvija bez stvaranja nepotrebnog javnog prozora izloženosti? Kako se korisnike obavještava što učiniti? Koji nizvodni paketi trebaju ažuriranje? Što se događa ako izvjestitelj ne dobije odgovor?

Ta pitanja nisu dokaz nepovjerenja prema otvorenom kodu. To je posao tretiranja korisnika kao ljudi kojima treba odgovor. Rad ENISA-e o otkrivanju ranjivosti i koordiniranom otkrivanju ranjivosti opisuje vrijednost definiranih procesa između izvjestitelja, dobavljača i drugih relevantnih strana. Proces ne može jamčiti da je svako izvješće točno ili da je svaki popravak brz. Može smanjiti šansu da ozbiljan problem započne svoj život u nenadziranom sandučiću e-pošte.

Projekt može objaviti sigurnosnu politiku, adresu za prijavu i informacije o podržanim verzijama. To su korisni signali, osobito kada opisuju što izvjestitelj može očekivati. Projekt također može biti premalen da pruži vrijeme odgovora koje važna implementacija treba. To nije moralni neuspjeh. To je činjenica planiranja za organizaciju koja odabire ovisnost.

Isto vrijedi i nizvodno. Proizvođač ne može razumno reći da je ranjivost tuđi problem samo zato što je ranjiva komponenta započela u otvorenom spremištu. Ako proizvođač stavlja proizvod s digitalnim elementima na tržište Unije, Akt o kibersigurnosti postavlja zahtjeve o postupanju s ranjivostima i isporuci sigurnosnih ažuriranja u okviru koji se primjenjuje na proizvod. Pravni detalj ovisi o proizvodu i ulozi. Operativna je poanta jednostavnija: strana koja čini proizvod dostupnim treba način da zna utječe li promjena uzvodno na ono što je isporučila.

Ovdje inventar postaje aktivan, a ne dekorativan. Mora povezati komponentu s verzijom, izradom, izdanjem proizvoda i vlasnikom koji može procijeniti izvješće. Vlasnik ne mora sam popraviti svaki uzvodni nedostatak. Mora odlučiti hoće li ažurirati, ublažiti, onemogućiti, obavijestiti, kompenzirati ili prestati koristiti komponentu. „Koristimo otvoreni kod” opis je ulaza. To nije plan odgovora.

Razmotrimo izričito hipotetski primjer. Tim uključuje biblioteku u uslugu za obradu dokumenata. Mjesecima kasnije, sigurnosno izvješće identificira ranjivi raspon. Ako je tim zabilježio komponentu, verziju i usluge u kojima je ugrađena, može započeti procjenu. Ako može reproducirati izrade i testirati ažuriranje, može odlučiti je li lijek nadogradnja, promjena konfiguracije ili privremeno ograničenje. Ako nema ni zapis ni vlasnika, prvi je zadatak detektivski posao. Ranjivost može biti identična u oba slučaja. Operativni rizik nije.

Put otkrivanja ne obećava da je svaki problem malen. Čini sljedeću odgovornu radnju vidljivom kada se problem pronađe.

Podrijetlo je odgovor na pitanje „što točno pokrećemo?”

Podrijetlo softvera može zvučati kao riječ posuđena s muzejskog postava. Temeljno je pitanje sasvim obično: odakle je došao ovaj artefakt i možemo li pokazati put? Za softver, taj put može uključivati spremišta izvornog koda, objavljene arhive, registre ovisnosti, alate za izgradnju, konfiguraciju, ključeve za potpisivanje, okruženja za izgradnju i sustave za objavu. Odgovor rijetko kada predstavlja jednu elegantnu činjenicu. To je zbirka zapisa koji se moraju dovoljno dobro slagati da bi osoba mogla donijeti odluku.

Podrijetlo ne zahtijeva od organizacije da tvrdi kako posjeduje savršeno znanje. Zahtijeva da kaže što se zna, što je provjereno i gdje ostaje nesigurnost. Ponovljiva izgradnja može pružiti snažan dokaz da su definirani izvor i definirano okruženje proizveli odgovarajući artefakt. Potpisano izdanje može pomoći u prepoznavanju ključa korištenog za potvrdu izdanja. Popis softverskih sastavnica može opisati deklarirane komponente. Nijedan od ovih elemenata sam po sebi ne dokazuje da je kod bezopasan, da je svaka tranzitivna ovisnost pregledana ili da je izdanje prikladno za određenu upotrebu. Zajedno, oni mogu učiniti kasniju istragu znatno manje spekulativnom.

Ova je razlika važna jer se podrijetlo često prodaje kao čarobni pečat. Ono to nije. Hash vam može reći da se dva niza bajtova podudaraju. Ne može vam reći da bi se podudarajućem programu trebalo dopustiti obradu osjetljivih zapisa. Potpis može povezati izdanje s ključem. Ne može vam reći da je osoba koja kontrolira ključ slijedila dobar postupak pregleda. Inventar može imenovati komponentu. Ne može vam reći je li komponenta sigurno konfigurirana. Dokazi su i dalje dokazi, a ne zamjena za prosudbu.

No, izostanak podrijetla čini prosudbu lošijom. Kada tim ne može utvrditi koja je revizija izvora stvorila implementirani paket, ne može sa sigurnošću povezati ispravak od strane dobavljača sa svojom vlastitom uslugom. Kada ne može identificirati tranzitivnu ovisnost, ne može procijeniti obavijest ili savjet bez prethodne rekonstrukcije opskrbnog lanca. Kada izgradnja daje različite rezultate bez objašnjenja, ne može utvrditi je li se binarni zapis promijenio zbog izvora, okruženja ili ometanja. To su praktična ograničenja, a ne testovi čistoće.

Europski digitalni suverenitet često se svodi na lokaciju poslužitelja. Lokacija je važna. No, ona nije dovoljna. Sustav može raditi u Europi dok se oslanja na cjevovod za izgradnju, registar ovisnosti ili kanal za ažuriranja koje operater ne može pregledati, kontrolirati ili zamijeniti. S druge strane, otvoreni kod može ponuditi stvaran put do provjere i prenosivosti, dok i dalje ostavlja korisnika odgovornim za sposobnost potrebnu za korištenje tog puta. Suverenitet je sposobnost djelovanja pod pritiskom, a ne zastava pričvršćena na sliku spremnika.

Koristan zapis o podrijetlu trebao bi tehnički kompetentnom kolegi omogućiti praćenje izdanja unatrag i unaprijed. Unatrag: koji su izvor, ovisnosti i postupak izgradnje doveli do ovoga? Unaprijed: koje usluge, proizvodi i korisnici mogu biti pogođeni ako se ova komponenta promijeni ili povuče? Zapis može biti proporcionalan. Mali interni alat ne treba mehanizme programa za zrakoplove. No, treba dovoljno istine da podrži posljedice svoje upotrebe.

Zakon o kibersigurnosnoj otpornosti povlači crtu bez pretvaranja da je svijet jednostavan

Zakon o kibersigurnosnoj otpornosti često se sažima kao novi skup zahtjeva za kibersigurnost za povezane proizvode. To je točno, ali nepotpuno. Njegov korisniji doprinos ovoj raspravi jest razlika koju uspostavlja između uloga. Skrbnik slobodnog softvera otvorenog koda može biti subjekt koji pruža kontinuiranu podršku razvoju proizvoda s digitalnim elementima kvalificiranima kao slobodni softver otvorenog koda i koji je osmišljen kako bi osigurao održivost tih proizvoda. Uredba postavlja uvjete oko te uloge. Ne tretira svakog suradnika kao da nosi iste obveze kao proizvođač.

Ova razlika priznaje kako otvoreni kod zapravo funkcionira. Projekt može imati pojedinačne suradnike, udrugu, zakladu, tvrtku koja nudi podršku, distribuciju koja pakira softver, integratore i proizvođača koji ga ugrađuje u proizvod. Njihove su odgovornosti povezane, ali ne i zamjenjive. Suradnik može ispraviti grešku. Skrbnik može koordinirati projekt. Distributer ga može pakirati. Proizvođač može staviti proizvod na tržište. Implementator može odlučiti kako taj proizvod postupa sa stvarnim podacima i stvarnim ljudima. Javno spremište mjesto je susreta tih uloga, a ne pravni miješalica.

Za organizacije, najsigurnije je tumačenje ne pretvoriti propis u folklor prije nego što stupi na snagu. Akt ima fazne datume primjene i odredbe specifične za pojedine uloge. Pravno tumačenje treba preuzeti iz primjenjivog teksta i stručnog savjeta, osobito kada su u pitanju proizvod, komercijalna djelatnost ili stavljanje na tržište. Operativna priprema, međutim, ne mora čekati seminar s hladnom kavom i slajdom pod naslovom „pregled“. Inventarizirajte komponente. Utvrdite tko je vlasnik ažuriranja. Čuvajte dokaze o izdanjima. Postavite put za prijavu sigurnosnih propusta. Odredite što znači podržano. Te su radnje korisne bez obzira na to primjenjuje li se pojedina odredba danas, sljedeće godine ili nikada.

Akt se također opire lažnom izboru. Ne tvrdi da je otvoreni kod nesiguran. Niti tvrdi da objavljivanje oslobađa komercijalni proizvod obveze sigurnosnog rada. Priznaje da sigurnost softvera koji se koristi u proizvodima ima javne posljedice te da lanac aktera treba jasnije odgovornosti. Točne obveze zaslužuju pažljivo pravno čitanje. Načelo je jasno: softver koji do ljudi dolazi kroz proizvod treba nekoga tko može poduzeti odgovornu mjeru kada rizik postane poznat.

To je načelo već poznato u drugim područjima. Objavljeni recept ne oslobađa restoran obveza sigurnosti hrane. Objavljeni građevinski standard ne oslobađa izvođača dužnosti da ga stručno primijeni. Usporedba ima ograničenja: softverske licence, kanali ažuriranja i razvojne zajednice imaju vlastite strukture. No osnovna poanta prenosi se. Javno dostupno znanje može omogućiti neovisnu provjeru. Ono ne uklanja odgovornost strane koja poslužuje obrok ili otvara vrata.

Što korisnici duguju samima sebi

Najkorisnija politika otvorenog koda često je operativna politika prerušena u razuman popis provjera. Trebala bi odgovoriti tko smije uvesti ovisnost, koje informacije moraju biti zabilježene, kako se licence pregledavaju, kako se ažuriranja procjenjuju, kako se sigurnosni izvještaji usmjeravaju i tko može odobriti iznimku. Trebala bi također odgovoriti što se događa kada podrška prestane. Politika koja objašnjava odabir, a nema ništa o uklanjanju, samo je pola politike.

Počnite s jedinicom koja zapravo ima značaj: implementiranim artefaktom ili uslugom, a ne apstraktnim katalogom omiljenih projekata. Za svaku bitnu komponentu organizacija bi trebala moći locirati verziju, put do izvora ili registra, licencu, odgovornu unutarnju ulogu, sustav u kojem se koristi i put ažuriranja. Razina detalja trebala bi pratiti posljedice kvara. Cilj nije pretvoriti svakog programera u službenika. Cilj je spriječiti da važne činjenice postanu privatno znanje na jednom prijenosniku ili u sjećanju jedne osobe.

Zatim odlučite koji će dokazi promijeniti odluku. Objavljeno upozorenje može pokrenuti procjenu. Novo izdanje može pokrenuti test kompatibilnosti. Promjena licence može pokrenuti pravni pregled. Napuštena podržana verzija može pokrenuti plan migracije. Izgradnja koja se više ne može reproducirati može pokrenuti istragu. Bez tih okidača, inventari često postaju povijesni dokumenti: točni na dan izvoza, a poslije pristojno ignorirani.

Postavite vlasništvo blizu mjesta djelovanja. Središnji tim za upravljanje može postaviti politiku i pružiti stručnost. Ne može upravljati svakom uslugom. Produktni tim može poznavati arhitekturu vlastitog okruženja. No možda nije opremljen za tumačenje svake licence. Dogovor funkcionira kada je primopredaja jasna: vlasnik proizvoda procjenjuje utjecaj, sigurnost savjetuje o izloženosti i odgovoru, pravna služba ili služba za usklađenost procjenjuje uvjete licence gdje je to potrebno, nabava bilježi vanjske obveze, a imenovani donositelj odluka prihvaća ili odbija materijalni rizik. Imena će se razlikovati. Izostanak imena je problem koji se ponavlja.

Zadržite izlazni put. Otvoreni kod može smanjiti ovisnost o dobavljaču, ali samo ako organizacija može ponovno izgraditi, razdvojiti, zamijeniti ili ugovoriti podršku kada se okolnosti promijene. Zrcalo repozitorija, upute za izgradnju, predmemorirani put ovisnosti i zapis potrebne konfiguracije mogu biti dosadan posao sve dok izvorna usluga ne postane nedostupna ili odnos ne završi. Dosadan posao ima dobru evidenciju u hitnim situacijama.

Naposljetku, budite iskreni o preostalom riziku. Nijedan program upravljanja ovisnostima ne može jamčiti da će svaka ranjivost biti otkrivena prva, da će svaki projekt gornjeg toka ostati aktivan ili da će svako pitanje licence biti jednostavno. Svrha upravljanja nije obećati nemoguće. Svrha je učiniti neizvjesnost vidljivom dovoljno rano da odgovorna osoba može odlučiti što će s njom učiniti.

Što održavatelji razumno mogu ponuditi

Održavatelji ne duguju svijetu neograničen rad samo zato što su objavili koristan kod. Takvo očekivanje je i nepravedno i nesigurno. Projekt može biti velikodušan u pogledu ponovne upotrebe, a istovremeno jasan u pogledu svojih kapaciteta. Može reći koje su verzije podržane, gdje prijaviti sigurnosne probleme, kako se donose odluke o izdanjima, koje vrste doprinosa može pregledati i što neće obećati. Jasna ograničenja bolja su za korisnike od tople dvosmislenosti.

Čak i mali projekt može poboljšati operativnu primopredaju s nekoliko trajnih dokumenata: datotekom licence, čitljivim procesom izdavanja, sigurnosnim kontaktom ili politikom otkrivanja, informacijama o verzioniranju, smjernicama o ovisnostima gdje je to relevantno te jasnom izjavom o tome je li održavanje aktivno, ograničeno ili završeno. Ništa od toga ne stvara jamstvo. Svaki dokument pomaže korisniku nizvodno da donese informiraniju odluku.

Tamo gdje projekt ima organizacijsku podršku, razgovor može ići dalje. Organizacija može objaviti politiku podržanih verzija, opisati svoje upravljanje, zabilježiti praksu potpisivanja izdanja, održavati put za odgovor na ranjivosti i objasniti kako korisnici mogu dobiti podršku. To nisu značke za početnu stranicu. To su operativna obećanja i treba ih pisati samo tamo gdje je organizacija spremna ispuniti ih.

Najiskrenija poruka o održavanju ponekad može biti „ovo ne možemo preuzeti". To može značiti da je značajka izvan opsega, da se platforma ne može testirati, da sigurnosno izvješće treba više informacija, da grana više nije podržana ili da se datum izdanja ne može obećati. Jasno odbijanje daje korisnicima nešto oko čega mogu planirati. Šutnja im daje priču koju će sami ispričati, što je općenito skuplji ulaz.

Postoji i odgovornost za korisnike koji ovise o projektu. Prijavite nedostatke s dovoljno detalja za reprodukciju. Slijedite sigurnosni put ako postoji. Doprinesite testiranjem, dokumentacijom, financiranjem ili pregledom gdje je to moguće. Ne zahtijevajte uslužni odnos od volonterskog projekta dok odbijate priznati da uslužni odnos košta novac. Reciprocitet ne ukida različite uloge, ali može učiniti lanac manje krhkim.

Otvoreni kod može ojačati odgovornost

Postoji iskušenje da se, nakon nabrajanja svih tih dužnosti, zaključi kako otvoreni kod stvara previše posla. Ne stvara. Posao postoji bez obzira na to je li kod vidljiv ili nije. Zatvorene ovisnosti također zahtijevaju inventar, svijest o licencama, odgovor na ranjivosti, podrijetlo i plan izlaska. One jednostavno čine dio dokaza težim za pregled, a dio alternativa težim za provedbu.

Otvoreni kod može omogućiti snažniji položaj odgovornosti. Kupac može pregledati arhitekturu. Operater može zadržati kopiju koda i upute za izgradnju. Neovisni recenzent može provjeriti tvrdnju. Javno tijelo može izbjeći situaciju u kojoj je privatni plan dobavljača jedini put do ispravka. Zajednica može pronaći i riješiti problem koji je jedna organizacija propustila. To su značajne prednosti, osobito u europskom okruženju gdje javna vrijednost, kontinuitet i mogućnost osporavanja nisu opcionalan ukras.

Ali mogućnost nije dovršenost. Preglednost pomaže samo onome tko je sposoban i ovlašten pregledati. Prenosivost pomaže samo onome tko je sačuvao artefakte i zna kako ih premjestiti. Račvanje je strategija izlaska samo kada postoji tim, proračun i pravni put koji to mogu nositi. „Kod je na GitHubu” nije plan kontinuiteta, baš kao što „datoteke su u ormaru” nije arhivska strategija.

Naš rad na otvorenom kodu u Dweveu drži tu granicu na vidiku. Knot je u našim objavljenim materijalima opisan kao potpisani revizijski trag otporan na neovlaštene izmjene za izvođenja AI agenata, s izvanmrežnom provjerom zaprimljenog zapisa pomoću javnog ključa. To čini tvrdnju preglednijom. Ne odlučuje što bi organizacija trebala bilježiti, tko smije pristupiti zapisu, koliko dugo ga treba čuvati niti tko istražuje neočekivani rezultat. To ostaju upravljačke odluke oko alata. Alat može sačuvati dokaze. Ne može postati odgovorna organizacija u ime bilo koga.

To je skromno obećanje koje vrijedi zadržati. Otvoreni kod može ljudima dati više dokaza, više mogućnosti i više prostora za doprinos. Od njega se ne bi trebalo tražiti da pruži fiktivno oslobođenje od održavanja, sigurnosti, licenciranja ili operativnog prosuđivanja.

Odgovornost preživljava gumb za objavu

Objavljivanje izvornog koda koristan je čin. Može potaknuti nadzor, smanjiti prepreke ponovnoj uporabi i učiniti tehnički izbor lakšim za osporavanje. U zdravoj tehnološkoj kulturi trebalo bi biti normalno da javne institucije i tvrtke ozbiljno razmotre otvoreni kod, pravilno ga podrže i objasne svoje izbore bez praznovjerja.

Gumb za objavu, međutim, nije otvor za bijeg od odgovornosti. Ne uklanja potrebu da se zna što proizvod sadrži. Ne zakrpa implementiranu uslugu. Ne čuva obavijest o licenci, ne trijažira prijavu ranjivosti, ne održava izgradnju niti odlučuje treba li sustav ostati u uporabi. Ti zadaci i dalje pripadaju ljudima i organizacijama s ulogama, proračunima, ovlastima i posljedicama.

Dobra vijest je da odgovorna praksa nije mistična. Imenujte ovisnost. Pročitajte licencu. Zadržite podrijetlo. Odlučite tko je vlasnik ažuriranja. Dajte sigurnosnim izvješćima put. Sačuvajte izlaz. Jasno recite što je podržano, a što nije. Kada su te navike prisutne, otvoreni kod postaje više od geste prema transparentnosti. Postaje infrastruktura koja se može pregledati, održavati i kojoj se može vjerovati iz razloga koji preživljavaju i težak dan.

Pitanje ispod pitanja

Kad tim pita je li neka komponenta otvorenog koda, često istovremeno postavlja nekoliko tiših pitanja. Možemo li joj vjerovati? Možemo li je napustiti? Možemo li je mijenjati? Može li je netko drugi revidirati? Možemo li dobiti pomoć kad se nešto pokvari? Licencija i repozitorij mogu pridonijeti odgovoru, ali ni jedno ni drugo ne može odgovoriti samo. Povjerenje proizlazi iz dokaza, stručnosti, poticaja i načina na koji se upravlja određenom implementacijom. Napuštanje ovisi o sučeljima, formatima podataka, znanju o izgradnji i resursima. Promjena ovisi o tehničkoj sposobnosti i uvjetima pod kojima se promjena može napraviti. Pomoć ovisi o stvarnom odnosu podrške ili sposobnosti rada bez nje.

Te su razlike obrana i od cinizma i od željnog razmišljanja. Cinizam kaže da je otvoreni kod tek neplaćeni rad. Željno razmišljanje kaže da je on automatski sigurniji jer bi ga mnoge oči mogle pregledati. Nijedna od tih tvrdnji ne govori operateru što dalje učiniti. Operater mora znati koje su oči zapravo pregledale relevantnu verziju, tko može testirati zakrpu, koji autoritet postoji za uvođenje promjene i kako rezultat stiže do pogođenog sustava. Sigurnost je lanac provjerenih radnji, a ne poslovica o mnoštvu.

Ista se suzdržanost odnosi na nabavu. Tražiti od dobavljača komponentu otvorenog koda ne čini ugovor manje važnim. To mijenja pitanja koja dobar ugovor može postaviti: koje su nadređene komponente uključene, kako će se postupati s obavijestima i obvezama izvornog koda, koje su verzije podržane, koji dokazi prate izdanje, što se događa s ispravcima tijekom razdoblja podrške i koji materijal kupac može zadržati radi očuvanja kontinuiteta. Kupac bi trebao cijeniti mogućnost uvida i prelaska na drugi sustav. Također bi trebao vrednovati sposobnost potrebnu za korištenje te mogućnosti.

Nema vrline u stvaranju razgranatog procesa za sitan alat, niti je razborito koristiti jedan dijagram aktivnosti kao model upravljanja za kritičnu uslugu. Proporcionalnost je ovdje praktična vještina. Što je šira izloženost, što su podaci važniji, što je oporavak teži i što je komponenta središnija, to bi zapisi i operativni aranžmani trebali biti čvršći. To nije birokracija radi nje same. To je pokušaj da se stvarna odluka zadrži blizu stvarne posljedice.

Otvoreni kod zaslužuje svoje mjesto u europskoj digitalnoj infrastrukturi kad pomaže institucijama da ostanu sposobne: sposobne provjeravati, sposobne mijenjati, sposobne objašnjavati i sposobne nastaviti. Sposobnost se stječe sporije od entuzijazma. Treba joj vrijeme, ljudi, dokumentacija, testiranje i ponekad spremnost na financiranje rada koji nikada neće postati glavno izlaganje na konferenciji. To je također ono što ostaje kad popularni repozitorij, odnos s dobavljačem ili raspored izdanja promijene smjer bez traženja dopuštenja.

To je odgovornost u svom korisnom, neuglednom i posve javnom obliku.

Izvori