Atvērtais kods nav atbildības atteikšanās

Publishing source code changes who can inspect, reuse and improve it. It does not remove the practical work of knowing what is deployed, what is maintained,...

Atvērtais kods nav atbildības atteikšanās

Repozitorijs ir sākums, nevis beigas

Par atvērto kodu klīst mierinošs stāsts. Grupa publicē kodu. Citi cilvēki to var lasīt. Kods kļūst par kopējo labumu vai vismaz par noderīgu kopēju traucēkli. Atbildība izšķīst pūlī.

Pirmie divi teikumi var būt patiesi. Pēdējais nav. Publisks repozitorijs var paplašināt pārbaudes, atkārtotas izmantošanas un ieguldījuma iespējas. Tas var dot organizācijai skaidrāku izejas ceļu nekā slēgts pakalpojums. Tas var ļaut publiskai iestādei izvērtēt komponenti, neprasot piegādātājam atļauju. Neviens no šiem aspektiem neatbild uz jautājumu, kas rodas parastā otrdienas rītā: kura versija šeit darbojas, saskaņā ar kuru licenci, ar kādu konfigurāciju, un kurš rīkosies, ja drošības ieteikums attiecas uz šo versiju?

Atvērtais kods maina atbildības formu. Tas nepadara atbildību neobligātu. Uzturētājam joprojām ir jāpieņem lēmumi par laidieniem, drošības ziņojumiem, atbalstītajām versijām un licencēšanu. Organizācijai, kas iekļauj komponenti savā produktā, joprojām ir jāpieņem lēmumi par izcelsmi, atjauninājumiem un to, ko tā stāsta saviem lietotājiem. Izvietotājam joprojām ir jāpieņem lēmumi par inventarizāciju, iedarbību, konfigurāciju, piekļuvi un atkopšanu. Licence piešķir atļaujas un nosacījumus. Tā nenodrošina dežūras grafiku.

Tas ir svarīgi, jo atvērtais kods ir kļuvis par parastu infrastruktūru. Tas atrodas operētājsistēmās, pārlūkprogrammās, publiskajos pakalpojumos, pētniecības rīkos, rūpnieciskajās sistēmās un bibliotēkās, kas liek produktam izskatīties pašpietiekamākam, nekā tas patiesībā ir. Nobriedis jautājums tāpēc nav tas, vai organizācija ir par atvērto kodu vai pret to. Tas ir, vai tā spēj uzņemties atbildību, ko rada programmatūra, no kuras tā izvēlas būt atkarīga.

Eiropas politika ir sākusi skaidrāk aprakstīt šo atšķirību. Kibernoturības akts regulē produktus ar digitāliem elementiem un ietver īpašu ceļu brīvās un atvērtā koda programmatūras uzturētājiem. Šis ceļš atzīst, ka persona vai organizācija, kas sniedz ilgstošu atbalstu brīvajai un atvērtā koda programmatūrai, var ieņemt reālu vietu drošības ķēdē. Tas nepārvērš katru brīvprātīgo, kas publicē kodu, par ražotāju. Tāpat tas neļauj komerciālam dalībniekam slēpties aiz publiska repozitorija, kad šis dalībnieks laiž produktu tirgū.

Praktiskās sekas ir patīkami neromantiskas. Uztveriet katru atkarību kā kaut ko tādu, kas ir jānosauc, jāsaprot un par ko ir jārūpējas. Tas nav uzbrukums atvērtajam kodam. Tā ir disciplīna, kas ļauj atvērtajam kodam palikt noderīgam, kad novitāte ir zudusi.

Ko publikācija patiesībā maina

Avota koda pieejamība maina vairākas lietas vienlaikus. Lasītājs var pārbaudīt ieviešanu, nevis secināt to no mārketinga lapas. Komanda var reproducēt būvējumu, ja būvēšanas instrukcijas, atkarības un vide to atļauj. Piegādātāju var vieglāk nomainīt, ja licence un saskarnes to pieļauj. Pētnieks var pārbaudīt apgalvojumu, drošības komanda var izskatīt ielāpu, un publisks pircējs var uzdot jautājumus, neuztverot melno kasti kā konstitucionālu principu.

Tie ir nozīmīgi sabiedriskie labumi. Tie ir arī nosacīti. Kods, kas ir redzams, bet nav būvējams, ir mazāk pārbaudāms, nekā sākotnēji šķiet. Kods, kas ir būvējams, bet kam trūkst skaidras licences, atstāj atkārtotu izmantošanu neskaidru. Kods, kas ir licencēts, bet salikts no nezināmām atkarībām, rada izcelsmes problēmu. Kods, kas tiek uzturēts tikai zarā, kuru neviens nevar identificēt, nekļūst uzticams tikai tāpēc, ka pastāv repozitorija lapa.

The Open Source Initiative describes open source through an approved licence and a set of rights, including access to source code and the freedom to redistribute and modify under stated terms. That definition is deliberately about permissions. It is not a service-level agreement, a security certification, a warranty of fitness for a particular public task or an assurance that a component will be maintained indefinitely. The absence of those promises is not a defect in the definition. It is a reason to be exact about what an organisation is relying on.

It helps to separate four questions that are often bundled into one friendly word. Is the source code available? Is it licensed for the intended use? Can the organisation establish where the code and its dependencies came from? Is somebody actively carrying the operational work that this deployment requires? A yes to the first question does not answer the other three.

That separation also makes conversations less theatrical. A procurement team does not need to perform enthusiasm for a repository. It needs to know whether the component is appropriate for the system it is buying or operating. An engineering team does not need to apologise for using a permissive licence. It needs to know how it will meet licence notices, preserve required materials, update dependencies and respond to a disclosed issue. A legal team does not need to become a release manager. It does need a route into the release process before a licence problem becomes a public correction.

Source code may travel through several hands. Select a layer to distinguish publication, packaging, product placement and deployment responsibilities.

The licence is a boundary, not a weather forecast

Licences are sometimes treated as an administrative detail, as though the legal work begins after the engineering work has finished. In practice, licence choices shape engineering decisions from the beginning. They affect whether a component can be combined with another component, whether notices must accompany a distribution, whether modified source must be offered in particular circumstances, and whether a team can meet the conditions attached to the rights it wants to use.

That does not mean every engineer must become a copyright specialist. It means the organisation needs a dependable translation between the software it builds and the commitments it makes when it distributes, hosts or modifies that software. The translation must happen while the facts are still available: which package was selected, which version was used, whether it was changed, how it was linked or included, what it is shipped with, and what the intended distribution route is.

There is no universal licence answer. A permissive licence can make reuse straightforward while still requiring notices and preservation of copyright text. A reciprocal licence can attach additional conditions to distribution or modification. A dual-licence arrangement may require an organisation to choose a commercial route or a particular open-source route. An organisation should not infer obligations from a licence nickname, a package-manager badge or a colleague's half-remembered story from 2014. It should read the licence text, record the decision and ask for advice where the intended use is uncertain.

Licences atbilstība nav arī tikai ceremonija, ko veic izlaišanas nedēļā. Programmatūras materiālu saraksts, atkarību inventarizācija un izlaišanas ieraksts var padarīt vēlāko jautājumu atbildamu: kas bija iekļauts šajā artefaktā? Bet saraksts ir noderīgs tikai tad, ja tas apraksta konkrētu artefaktu, versiju un datumu. Izklājlapa ar nosaukumu dependencies-final-final.xlsx nav izcelsmes sistēma. Tā ir arheoloģiska kārta.

Valsts iestādei tas ir vairāk nekā iekšējā kārtība. Iestādei var būt nepieciešams saglabāt spēju izskaidrot, kāpēc komponents tika izvēlēts, kādi noteikumi to regulē, kā to var aizstāt un kas notiek, ja uzturēšana beidzas. Komercorganizācijai šie paši ieraksti ietekmē līgumsaistības, produktu atjauninājumus un saziņu ar klientiem. Mazai komandai mērogs ir citāds, bet loģika nav. Ja projekts nevar identificēt tā izplatītā koda licenci, tas nevar godīgi apgalvot, ka juridiskā robeža ir kontrolēta.

Atbildīga rīcība ir samērīga, nevis grandioza. Reģistrējiet tiešās atkarības. Saglabājiet licenču tekstus un prasītos paziņojumus kopā ar izlaišanu. Reģistrējiet būtiskas izmaiņas. Nosakiet pārskatīšanas punktu jauniem vai neparastiem licencēšanas noteikumiem. Uzdodiet kādam atbildību par neskaidrību novēršanu. Tie ir pieticīgi kontroles pasākumi. To vērtība ir tāda, ka tie neļauj neskaidrībai kļūt par pārsteigumu pēc tam, kad programmatūra ir izplatīta.

Uzturēšana ir darbs, pat ja tā ir ziedota

Atvērtā koda uzturēšana bieži tiek aprakstīta tā, it kā tā būtu personiska tikums. Dažreiz tā ir. Cilvēki pārskata ielāpus, atbild uz jautājumiem, sagatavo izlaišanas un neļauj veciem pieņēmumiem kļūt par rītdienas pārtraukumiem, jo viņiem rūp rīks un cilvēki, kas to lieto. Šī dāsnuma ir pelnījusi cieņu. To nevajadzētu izmantot kā biznesa modeli bez biznesa lēmuma.

Uzturēšana ir operacionāls darbs. Tajā ietilpst lēmums par to, kuras versijas tiek atbalstītas, ieguldījumu pārskatīšana, drošības informācijas publicēšana, izlaišanas procesa pārvaldība, atbildēšana uz ziņojumiem, dokumentēšana par pārtraucošām izmaiņām, būvēšanas infrastruktūras uzturēšana lietošanas kārtībā un dažreiz atteikšanās. Pēdējā daļa ir nenovērtēta. Projekts, kas nevar noraidīt funkciju pieprasījumu, neatbalstītu platformu vai nedrošu saīsinājumu, ne vienmēr ir atvērtāks. Tas var vienkārši būt vairāk pakļauts riskam.

Eiropas Komisijas atvērtā koda programmatūras stratēģija uzskata atvērto kodu par veidu, kā uzlabot atkārtotu izmantošanu, pārredzamību, sadarbību un tehnoloģisko neatkarību valsts pārvaldē. Šie ieguvumi ir atkarīgi no spējām. Atkārtota izmantošana prasa, lai organizācija saprastu, ko tā izmanto atkārtoti. Pārredzamība prasa, lai kāds izlasītu to, kas ir atklāts. Neatkarība prasa vairāk nekā klonēšanas pogas esamību: tā prasa praktisku spēju darbināt, pielāgot vai iegādāties atbalstu programmatūrai, kad sākotnējais ieguldītājs ir aizgājis.

Tāpēc jautājumam “vai tas tiek uzturēts?” ir vajadzīga lielāka precizitāte. Tas var nozīmēt, ka pastāv nesenās izlaišanas. Tas var nozīmēt, ka ir publicēts drošības kontaktpunkts. Tas var nozīmēt, ka projekts apraksta atbalstītās versijas, būvēšanas instrukcijas un ieguldījumu procesu. Tas var nozīmēt, ka organizācija ir apņēmusies veltīt apmaksātu laiku šim darbam. Tas var nozīmēt, ka izvietotājam ir sava spēja uzturēt atzaru vai aizstāt komponentu. Tie ir dažādi fakti. Zaļš aktivitātes grafiks var būt noderīgs pierādījums, bet tas nav uzturēšanas līgums.

Atbildīgam adoptētājam tāpēc būtu jāizlemj, kāda veida uzturēšana tam ir nepieciešama, pirms tas izlemj, ko tas cer, ka kopiena nodrošinās. Zema riska iekšējais rīks var būt saderīgs ar nelielu projektu un pieticīgu atjaunināšanas plānu. Komponents ārēji pakļauta produkta centrā prasa skaidrāku atbalsta modeli, ātrāku ievainojamības novērtējumu un izejas plānu. Atšķirība nav par projekta prestižu. Tā ir par kļūdīšanās sekām.

Ir vērts pārņemt vienu mazu holandiešu paradumu: nejaukt gezellig ar pārvaldītu. Viesmīlīga kopiena var būt brīnišķīga vieta, kur dot savu ieguldījumu. Tai tomēr var nebūt pienākuma uzturēt jūsu ražošanas sistēmu darbībā. Organizācija, kas šo sistēmu ievieš ražošanā, ir atbildīga par šo atšķirību.

Drošības atklāšanai vispirms ir vajadzīgs maršruts, nevis sauklis

Lielākā daļa cilvēku abstrakti piekrīt, ka ievainojamības būtu jāatklāj atbildīgi. Sarežģītākā daļa ir mazāk abstrakta. Kur ziņotājam jānosūta atradums? Kurš to saņem? Kāda informācija ir nepieciešama, lai to reproducētu? Kurš izlemj, vai tas ietekmē atbalstīto versiju? Kā tiek izstrādāts labojums, neradot nevajadzīgu publiskas iedarbības logu? Kā lietotāji tiek informēti par rīcību? Kurām pakotnēm tālāk ķēdē ir nepieciešams atjauninājums? Kas notiek, ja ziņotājs nesaņem atbildi?

Šie jautājumi nav pierādījums neuzticībai atvērtajam kodam. Tie ir darbs, lai izturētos pret lietotājiem kā pret cilvēkiem, kuriem nepieciešama atbilde. ENISA darbs pie ievainojamību atklāšanas un koordinētas ievainojamību atklāšanas apraksta definētu procesu vērtību starp ziņotājiem, pārdevējiem un citām attiecīgajām pusēm. Process nevar garantēt, ka katrs ziņojums ir pareizs vai katrs labojums ir ātrs. Tas var samazināt iespēju, ka nopietna problēma sāk savu dzīvi neuzraudzītā pastkastītē.

Projekts var publicēt drošības politiku, ziņošanas adresi un atbalstīto versiju informāciju. Tie ir noderīgi signāli, īpaši, ja tie apraksta, ko ziņotājs var sagaidīt. Projekts var būt arī pārāk mazs, lai nodrošinātu atbildes laiku, kāds nepieciešams svarīgai ieviešanai. Tā nav morāla neveiksme. Tas ir plānošanas fakts organizācijai, kas izvēlas atkarību.

Tas pats attiecas uz lejupējo ķēdi. Ražotājs nevar pamatoti apgalvot, ka ievainojamība ir kāda cita problēma tikai tāpēc, ka ievainojamā sastāvdaļa radās atvērtā repozitorijā. Ja ražotājs laiž Savienības tirgū produktu ar digitāliem elementiem, Kibernoturības akts nosaka prasības par ievainojamību apstrādi un drošības atjauninājumu piegādi produktam piemērojamajā regulējumā. Juridiskās detaļas ir atkarīgas no produkta un lomas. Darbības jautājums ir vienkāršāks: pusei, kas padara produktu pieejamu, ir nepieciešams veids, kā uzzināt, vai augšupējas izmaiņas ietekmē to, ko tā ir piegādājusi.

Šeit inventarizācija kļūst aktīva, nevis dekoratīva. Tai ir jāsavieno sastāvdaļa ar versiju, būvējumu, produkta laidienu un īpašnieku, kurš spēj izvērtēt ziņojumu. Īpašniekam nav jālabo katrs augšupējs trūkums vienam pašam. Tam ir jāizlemj, vai atjaunināt, mazināt risku, atspējot, paziņot, kompensēt vai pārtraukt sastāvdaļas lietošanu. “Mēs izmantojam atvērto kodu” ir ievades apraksts. Tas nav reakcijas plāns.

Apsveriet skaidri hipotētisku piemēru. Komanda iekļauj bibliotēku dokumentu apstrādes pakalpojumā. Pēc mēnešiem drošības paziņojums identificē ievainojamu diapazonu. Ja komanda ir reģistrējusi sastāvdaļu, versiju un pakalpojumus, kuros tā ir iebūvēta, tā var sākt izvērtēšanu. Ja tā var reproducēt būvējumus un pārbaudīt atjauninājumu, tā var izlemt, vai risinājums ir jauninājums, konfigurācijas izmaiņa vai pagaidu ierobežojums. Ja tai nav ne reģistra, ne īpašnieka, pirmais uzdevums ir izmeklēšana. Ievainojamība abos gadījumos var būt identiska. Darbības risks nav.

Atklāšanas maršruts nesola, ka katra problēma ir maza. Tas padara redzamu nākamo atbildīgo rīcību, kad problēma tiek atklāta.

Provenance ir atbilde uz jautājumu “ko tieši mēs izpildām?”

Programmatūras provenance var izklausīties kā vārds, kas aizgūts no muzeja eksponāta apraksta. Pamatā esošais jautājums ir ikdienišķs: no kurienes šis artefakts nācis, un vai mēs varam parādīt tā ceļu? Programmatūras gadījumā ceļš var ietvert avota krātuves, izlaistas arhīvu kopijas, atkarību reģistrus, būvēšanas rīkus, konfigurāciju, parakstīšanas atslēgas, būvēšanas vides un publicēšanas sistēmas. Atbilde reti ir viens elegants fakts. Tā ir ierakstu kopa, kurai jāsaskan pietiekami labi, lai cilvēks varētu pieņemt lēmumu.

Provenance neprasa organizācijai apgalvot, ka tai ir pilnīgas zināšanas. Tā prasa pateikt, kas ir zināms, kas ir pārbaudīts un kur paliek neskaidrība. Atkārtojama būvēšana var sniegt spēcīgus pierādījumus, ka noteikts avots un noteikta vide radīja atbilstošu artefaktu. Parakstīts laidiens var palīdzēt identificēt atslēgu, kas izmantota laidiena apliecināšanai. Programmatūras materiālu saraksts var aprakstīt deklarētās sastāvdaļas. Neviens no šiem elementiem atsevišķi nepierāda, ka kods ir nekaitīgs, ka katra pārejošā atkarība ir pārskatīta vai ka laidiens ir piemērots konkrētam lietojumam. Kopā tie var padarīt vēlāku izmeklēšanu daudz mazāk spekulatīvu.

Šī atšķirība ir svarīga, jo provenance bieži tiek pārdota kā maģisks zīmogs. Tā tāds nav. Hešs var pateikt, ka divas baitu secības sakrīt. Tas nevar pateikt, vai atbilstošajai programmai būtu jāļauj apstrādāt sensitīvus ierakstus. Paraksts var saistīt laidienu ar atslēgu. Tas nevar pateikt, vai persona, kas kontrolē atslēgu, ievēroja labu pārskatīšanas procesu. Inventarizācija var nosaukt sastāvdaļu. Tā nevar pateikt, vai sastāvdaļa ir droši konfigurēta. Pierādījumi joprojām ir pierādījumi, nevis sprieduma aizstājējs.

Tomēr provenance trūkums padara spriedumu vājāku. Ja komanda nevar noteikt, kura avota versija radīja izvietoto pakotni, tā nevar droši saistīt augšupstraumes labojumu ar savu pakalpojumu. Ja tā nevar identificēt pārejošo atkarību, tā nevar izvērtēt paziņojumu vai ieteikumu, vispirms nerekonstruējot piegādes ķēdi. Ja būvēšana bez izskaidrojuma dod atšķirīgus rezultātus, tā nevar pateikt, vai binārais fails ir mainījies avota, vides vai iejaukšanās dēļ. Tie ir praktiski ierobežojumi, nevis tīrības pārbaudes.

Eiropas digitālā suverenitāte bieži tiek reducēta līdz servera atrašanās vietai. Atrašanās vietai ir nozīme. Ar to nepietiek. Sistēma var darboties Eiropā, vienlaikus paļaujoties uz būvēšanas cauruļvadu, atkarību reģistru vai atjauninājumu kanālu, ko operators nevar pārbaudīt, kontrolēt vai aizstāt. Un otrādi, atvērtais kods var piedāvāt reālu ceļu uz pārbaudāmību un pārnesamību, tomēr atstājot adoptētājam atbildību par spējām, kas vajadzīgas šī ceļa izmantošanai. Suverenitāte ir spēja rīkoties spiediena apstākļos, nevis karogs, kas piestiprināts konteinera attēlam.

Noderīgam provenance ierakstam būtu jāļauj tehniski kompetentam kolēģim izsekot laidienu gan atpakaļ, gan uz priekšu. Atpakaļ: kurš avots, atkarības un būvēšanas process noveda līdz šim? Uz priekšu: kurus pakalpojumus, produktus un lietotājus var ietekmēt, ja šī sastāvdaļa tiek mainīta vai atsaukta? Ieraksts var būt samērīgs. Mazam iekšējam rīkam nav vajadzīga lidmašīnu programmas mehānika. Bet tam ir vajadzīgs pietiekami daudz patiesības, lai pamatotu tā lietošanas sekas.

Likums par kibernoturību novelk līniju, neizliekoties, ka pasaule ir vienkārša

Likums par kibernoturību bieži tiek apkopots kā jauns kiberdrošības prasību kopums savienotiem produktiem. Tas ir patiesi, bet nepilnīgi. Tā noderīgākais ieguldījums šajā diskusijā ir nošķīrums starp lomām. Brīvas un atvērtā koda programmatūras pārvaldnieks var būt vienība, kas nodrošina ilgstošu atbalstu tādu produktu izstrādei ar digitāliem elementiem, kuri kvalificējami kā brīva un atvērtā koda programmatūra, un kas ir veidota, lai nodrošinātu šo produktu dzīvotspēju. Regula nosaka nosacījumus šai lomai. Tā neuzskata katru ieguldītāju par tādu, kam ir tādi paši pienākumi kā ražotājam.

Šī atšķirība atzīst, kā atvērtais kods patiesībā darbojas. Projektā var būt individuāli līdzautori, biedrība, fonds, uzņēmums, kas piedāvā atbalstu, distribūcija, kas iekļauj programmatūru, integrators un ražotājs, kas to iekļauj produktā. Viņu pienākumi ir saistīti, bet ne savstarpēji aizvietojami. Līdzautors var novērst kļūdu. Pārvaldnieks var koordinēt projektu. Distributors var to iekļaut komplektācijā. Ražotājs var laist produktu tirgū. Ieviesējs var izlemt, kā šis produkts apstrādā reālus datus un reālus cilvēkus. Publiskā krātuve ir šo lomu satikšanās vieta, nevis juridisks maisītājs.

Organizācijām drošākā pieeja ir nevis pārvērst aktu folklorā, pirms tas vēl stājies spēkā. Aktam ir pakāpeniski piemērošanas datumi un atsevišķiem lomu veidiem paredzēti noteikumi. Juridiskā interpretācija jāgūst no piemērojamā teksta un kompetenta padoma, jo īpaši, ja iesaistīts produkts, komercdarbība vai laišana tirgū. Tomēr operacionālajai sagatavošanai nav jāgaida seminārs ar aukstu kafiju un slaidu ar nosaukumu “pārskats”. Apziniet komponentus. Nosakiet, kam pieder atjauninājumi. Saglabājiet laidienu pierādījumus. Izveidojiet drošības ziņošanas ceļu. Izlemiet, ko nozīmē atbalstīts. Šīs darbības ir noderīgas neatkarīgi no tā, vai konkrētā klauzula attiecas šodien, nākamgad vai nemaz.

Ats arī noraida mākslīgu izvēli. Tas neapgalvo, ka atvērtais kods ir nedrošs. Tas arī neapgalvo, ka publicēšana atbrīvo komerciālu produktu no drošības darba. Tas atzīst, ka produktos izmantotās programmatūras drošībai ir publiskas sekas un ka darbību ķēdei ir vajadzīgas skaidrākas atbildības. Precīzie pienākumi prasa rūpīgu juridisku izvērtējumu. Princips ir vienkāršs: programmatūrai, kas līdz cilvēkiem nonāk caur produktu, ir vajadzīgs kāds, kurš spēj uzņemties atbildīgu rīcību, kad risks kļūst zināms.

Šis princips jau ir pazīstams citās jomās. Publicēta recepte neatbrīvo restorānu no pārtikas drošības prasībām. Publicēts būvnormatīvs neatbrīvo būvuzņēmēju no pienākuma to kompetenti piemērot. Salīdzinājumam ir robežas: programmatūras licencēm, atjauninājumu kanāliem un izstrādes kopienām ir sava struktūra. Bet pamatatziņa paliek spēkā. Publiski pieejamas zināšanas var padarīt iespējamu neatkarīgu pārbaudi. Tās nenovērš atbildību tam, kurš pasniedz maltīti vai atver durvis.

Ko ieviesēji ir parādā paši sev

Noderīgākā atvērtā koda politika bieži vien ir darbības politika, kas maskējas par saprātīgu kontrolsarakstu. Tai būtu jāatbild, kas drīkst ieviest atkarību, kāda informācija jāreģistrē, kā tiek izvērtētas licences, kā tiek novērtēti atjauninājumi, kā tiek virzīti drošības ziņojumi un kurš var apstiprināt izņēmumu. Tai būtu arī jāatbild, kas notiek, kad atbalsts beidzas. Politika, kas izskaidro atlasi, bet neko nesaka par izņemšanu, ir tikai puse politikas.

Sāciet ar vienību, kurai patiesībā ir nozīme: izvietoto artefaktu vai pakalpojumu, nevis abstraktu iecienītu projektu katalogu. Katram būtiskam komponentam organizācijai būtu jāspēj atrast versiju, avota vai reģistra ceļu, licenci, atbildīgo iekšējo lomu, sistēmu, kurā tas tiek izmantots, un atjaunināšanas ceļu. Detalizācijas līmenim būtu jāseko neveiksmes sekām. Mērķis nav pārvērst katru izstrādātāju par ierēdni. Mērķis ir nepieļaut, ka svarīgi fakti kļūst par privātām zināšanām vienā klēpjdatorā vai viena cilvēka atmiņā.

Pēc tam izlemiet, kādi pierādījumi mainīs lēmumu. Publicēts drošības paziņojums var izraisīt novērtējumu. Jauns laidiens var izraisīt saderības testu. Licences maiņa var izraisīt juridisku izvērtējumu. Pamesta atbalstīta versija var izraisīt migrācijas plānu. Būvējums, ko vairs nevar atkārtot, var izraisīt izmeklēšanu. Bez šiem iedarbinātājiem krājumi mēdz kļūt par vēstures dokumentiem: precīzi eksportēšanas dienā, vēlāk pieklājīgi ignorēti.

Īpašumtiesības jānostiprina tuvu darbībai. Centrālā pārvaldības komanda var noteikt politiku un sniegt ekspertīzi. Tā nevar pārvaldīt katru pakalpojumu. Produkta komanda var pārzināt savas izvietošanas arhitektūru. Tai var nebūt iespēju interpretēt katru licenci. Šāda kārtība darbojas, ja nodošana ir skaidri noteikta: produkta īpašnieks izvērtē ietekmi, drošības speciālisti sniedz atzinumu par risku un rīcību, juridiskā vai atbilstības nodaļa vajadzības gadījumā izvērtē licences nosacījumus, iepirkums reģistrē ārējās saistības, un noteikts lēmumu pieņēmējs pieņem vai noraida būtisku risku. Vārdi var atšķirties. Problēma ir tad, ja vārdu nav vispār.

Jāsaglabā izejas ceļš. Atvērtais kods var mazināt piesaisti vienam piegādātājam, bet tikai tad, ja organizācija spēj pārbūvēt, atzarot, aizstāt vai iegādāties atbalstu, kad apstākļi mainās. Repozitorija spogulis, būvēšanas instrukcijas, kešota atkarību ceļš un nepieciešamās konfigurācijas ieraksts var šķist garlaicīgs darbs, līdz sākotnējais pakalpojums kļūst nepieejams vai attiecības beidzas. Garlaicīgam darbam ir laba reputācija ārkārtas situācijās.

Visbeidzot, jābūt godīgiem par atlikušo risku. Neviena atkarību pārvaldības programma nevar garantēt, ka katra ievainojamība tiks atklāta pirmā, ka katrs augšupstraumes projekts paliks aktīvs vai ka katrs licences jautājums būs vienkāršs. Pārvaldības mērķis nav solīt neiespējamo. Tās mērķis ir padarīt nenoteiktību redzamu pietiekami agri, lai atbildīga persona varētu izlemt, kā rīkoties.

Ko uzturētāji var pamatoti piedāvāt

Uzturētāji nav parādā pasaulei neierobežotu darbu tikai tāpēc, ka ir publicējuši noderīgu kodu. Šādas cerības ir gan negodīgas, gan nedrošas. Projekts var būt dāsns attiecībā uz atkārtotu izmantošanu, vienlaikus skaidri norādot savas iespējas. Tas var pateikt, kuras versijas tiek atbalstītas, kur ziņot par drošības problēmām, kā tiek pieņemti lēmumi par laidieniem, kādus ieguldījumus tas var izskatīt un ko tas nesolīs. Skaidri ierobežojumi adoptētājiem ir labāki nekā siltā neskaidrība.

Pat neliels projekts var uzlabot operatīvo nodošanu ar dažiem ilgnoturīgiem dokumentiem: licences fails, saprotams laidiena process, drošības kontaktpersona vai atklāšanas politika, versiju informācija, atkarību norādījumi, ja tie ir būtiski, un skaidrs paziņojums par to, vai uzturēšana ir aktīva, ierobežota vai pabeigta. Neviens no tiem nerada garantiju. Katrs palīdz lejupstraumes lietotājam pieņemt apzinātāku lēmumu.

Ja projektam ir organizatorisks atbalsts, saruna var turpināties. Organizācija var publicēt atbalstīto versiju politiku, aprakstīt savu pārvaldību, dokumentēt laidienu parakstīšanas praksi, uzturēt ievainojamību reaģēšanas ceļu un izskaidrot, kā lietotāji var saņemt atbalstu. Tie nav nozīmītes mājaslapai. Tās ir operatīvi solījumi, un tie jāraksta tikai tad, ja organizācija ir gatava tos pildīt.

Godīgākais uzturēšanas vēstījums reizēm var būt “mēs to nevaram uzņemties”. Tas var nozīmēt, ka funkcija ir ārpus darbības jomas, platformu nevar testēt, drošības ziņojumam nepieciešama papildu informācija, atzars vairs netiek atbalstīts vai laidiena datumu nevar solīt. Skaidrs atteikums dod adoptētājiem kaut ko, ap ko plānot. Klusums dod viņiem stāstu, ko stāstīt pašiem sev, un tas parasti ir dārgāks ieguldījums.

Ir arī atbildība lietotājiem, kuri paļaujas uz projektu. Ziņojiet par defektiem ar pietiekami daudz informācijas, lai tos varētu reproducēt. Ievērojiet drošības ceļu, ja tāds pastāv. Sniedziet ieguldījumu testēšanā, dokumentācijā, finansējumā vai pārskatīšanā, ja iespējams. Neprasiet pakalpojumu attiecības no brīvprātīga projekta, vienlaikus atsakoties atzīt, ka pakalpojumu attiecības maksā naudu. Savstarpīgums neatceļ dažādās lomas, bet tas var padarīt ķēdi mazāk trauslu.

Atvērtais kods var stiprināt atbildību

Pēc visu šo pienākumu uzskaitīšanas rodas kārdinājums secināt, ka atvērtais kods rada pārāk daudz darba. Tā nav. Darbs pastāv neatkarīgi no tā, vai avots ir redzams. Arī slēgtajām atkarībām ir nepieciešams inventārs, licenču apzināšanās, ievainojamību pārvaldība, izcelsmes izsekojamība un iziešanas plāns. Tās vienkārši padara daļu pierādījumu grūtāk pārbaudāmus un dažas alternatīvas grūtāk īstenojamas.

Atvērtais kods var ļaut izveidot stingrāku atbildības pozīciju. Pircējs var pārbaudīt arhitektūru. Operators var saglabāt avota kopiju un būvēšanas instrukcijas. Neatkarīgs recenzents var pārbaudīt apgalvojumu. Publiska iestāde var izvairīties no situācijas, kad piegādātāja privātais ceļvedis ir vienīgais veids, kā panākt labojumu. Kopiena var atrast un novērst problēmu, ko viena organizācija palaidusi garām. Tās ir būtiskas priekšrocības, īpaši Eiropas apstākļos, kur publiskā vērtība, nepārtrauktība un apstrīdamība nav tikai dekoratīvi papildinājumi.

Taču iespēja nav tas pats, kas pabeigts darbs. Pārbaudāmība palīdz tikai tam, kurš spēj un ir pilnvarots pārbaudīt. Pārnesamība palīdz tikai tam, kurš ir saglabājis artefaktus un zina, kā tos pārvietot. Atzarošana ir iziešanas stratēģija tikai tad, ja ir komanda, budžets un juridisks ceļš, kas spēj to īstenot. “Kods ir GitHub” nav nepārtrauktības plāns, tāpat kā “faili atrodas skapī” nav arhīva stratēģija.

Mūsu atvērtā koda darbs uzņēmumā Dweve patur šo robežu redzeslokā. Knot mūsu publicētajos materiālos ir aprakstīts kā parakstīts, pret manipulācijām aizsargāts AI aģentu darbību revīzijas pieraksts ar saņemtā ieraksta bezsaistes verifikāciju, izmantojot publisko atslēgu. Tas padara apgalvojumu vieglāk pārbaudāmu. Tas neizlemj, kas organizācijai būtu jāreģistrē, kam ir piekļuve ierakstam, cik ilgi tas būtu jāsaglabā vai kurš izmeklē negaidītu rezultātu. Tie joprojām ir pārvaldības lēmumi ap rīku. Rīks var saglabāt pierādījumus. Tas nevar kļūt par atbildīgo organizāciju neviena vārdā.

Tas ir pieticīgais solījums, ko ir vērts turēt. Atvērtais kods var dot cilvēkiem vairāk pierādījumu, vairāk iespēju un vairāk vietas ieguldījumam. No tā nevajadzētu prasīt fiktīvu atbrīvojumu no uzturēšanas, drošības, licencēšanas vai darbības sprieduma.

Atbildība nepazūd pēc publicēšanas pogas nospiešanas

Avota koda publicēšana ir noderīga rīcība. Tā var piesaistīt pārbaudi, pazemināt atkārtotas izmantošanas šķēršļus un padarīt tehnisku izvēli vieglāk apstrīdamu. Veselīgā tehnoloģiju kultūrā publiskām iestādēm un uzņēmumiem būtu jābūt normai nopietni apsvērt atvērto kodu, to pienācīgi atbalstīt un izskaidrot savas izvēles bez māņticības.

Publicēšanas poga tomēr nav lūka, caur kuru atbildība izkrīt. Tā nenovērš nepieciešamību zināt, ko produkts satur. Tā nelabo izvietotu pakalpojumu. Tā nesaglabā licences paziņojumu, neapstrādā atklātās ievainojamības, neuztur būvi un neizlemj, vai sistēmai būtu jāpaliek lietošanā. Šie uzdevumi joprojām pieder cilvēkiem un organizācijām ar lomām, budžetiem, pilnvarām un sekām.

Labā ziņa ir tā, ka atbildīga prakse nav mistiska. Nosauciet atkarību. Izlasiet licenci. Saglabājiet izcelsmi. Izlemiet, kam pieder atjauninājums. Dodiet drošības ziņojumiem ceļu. Saglabājiet iziešanas iespēju. Skaidri pasakiet, kas tiek atbalstīts un kas netiek. Kad šie ieradumi ir klāt, atvērtais kods kļūst par vairāk nekā žestu caurspīdīguma virzienā. Tas kļūst par infrastruktūru, ko var pārbaudīt, uzturēt un kurai var uzticēties iemeslu dēļ, kas pārdzīvo grūtu dienu.

Jautājums zem jautājuma

Kad komanda jautā, vai komponents ir atvērtā pirmkoda, tā bieži vien vienlaikus uzdod vairākus klusākus jautājumus. Vai mēs tam varam uzticēties? Vai mēs to varam pamest? Vai mēs to varam mainīt? Vai kāds cits to var auditēt? Vai mēs varam saņemt palīdzību, kad kaut kas sabojājas? Licence un repozitorijs var palīdzēt rast atbildi, taču neviens no tiem atsevišķi nespēj uz to atbildēt. Uzticēšanās izriet no pierādījumiem, kompetences, stimuliem un tā, kā tiek pārvaldīta konkrētā izvietošana. Pamestība ir atkarīga no saskarnēm, datu formātiem, būvēšanas zināšanām un resursiem. Mainīšana ir atkarīga no tehniskajām spējām un nosacījumiem, ar kādiem izmaiņas var veikt. Palīdzība ir atkarīga no faktiskas atbalsta attiecības vai spējas darboties bez tās.

Šie nošķīrumi ir aizsardzība gan pret cinismu, gan vēlmju domāšanu. Cinisms apgalvo, ka atvērtais pirmkods ir tikai neapmaksāts darbs. Vēlmju domāšana apgalvo, ka tas automātiski ir drošāks, jo daudzas acis, iespējams, to var pārbaudīt. Neviens no šiem apgalvojumiem operatoram nepastāsta, ko darīt tālāk. Operatoram ir jāzina, kuras acis faktiski pārskatīja attiecīgo versiju, kurš var testēt labojumu, kāda pastāv pilnvaras veikt izmaiņas un kā rezultāts nonāk līdz skartajai sistēmai. Drošība ir pārbaudītu darbību ķēde, nevis sakāmvārds par pūli.

Tā pati atturība attiecas uz iepirkumu. Pieprasīt no piegādātāja atvērtā pirmkoda komponentu nepadara līgumu mazāk svarīgu. Tas maina jautājumus, ko labs līgums var uzdot: kuri augšupstraumes komponenti ir iekļauti, kā tiks apstrādāti paziņojumi un pirmkoda saistības, kuras versijas tiek atbalstītas, kādi pierādījumi pavada laidienu, kas notiek ar labojumiem atbalsta termiņa laikā un kādus materiālus klients var paturēt, lai saglabātu nepārtrauktību. Pircējam būtu jānovērtē spēja pārbaudīt un pārvietot. Tam būtu arī jānovērtē spējas, kas vajadzīgas, lai izmantotu šo spēju.

Nav nekāda tikuma radīt plašu procesu sīkam utilītam, un nav nekādas apdomības izmantot vienu darbību diagrammu kā pārvaldības modeli kritiskam pakalpojumam. Proporcionalitāte šeit ir praktiskā māksla. Jo plašāka iedarbība, jo nozīmīgāki dati, jo grūtāka atkopšana un jo centrālāks komponents, jo stingrākiem jābūt ierakstiem un darbības kārtībai. Tā nav birokrātija pašas dēļ. Tas ir mēģinājums noturēt reālo lēmumu tuvu reālajām sekām.

Atvērtais pirmkods iegūst savu vietu Eiropas digitālajā infrastruktūrā, kad tas palīdz iestādēm saglabāt spējas: spēju pārbaudīt, spēju mainīt, spēju izskaidrot un spēju turpināt. Spējas iegūst lēnāk nekā entuziasmu. Tām vajadzīgs laiks, cilvēki, dokumentācija, testēšana un reizēm gatavība finansēt darbu, kas nekad nekļūs par konferences atklāšanas runu. Tās ir arī tas, kas paliek, kad populārs repozitorijs, piegādātāja attiecības vai laidienu grafiks mainās, neprasot atļauju.

Tā ir atbildība tās lietderīgajā, neizskatīgajā, pilnībā publiskajā formā.

Avoti