Puolustussopimusten ohjelmistolisenssit: COTS, auditointi, DFARS

Ohjelmistolisenssien noudattamista pidetään useimmissa organisaatioissa hankintamuodollisuutena. Puolustussopimuksissa se on jotain lähempää sääntelyvelvoitetta, johon liittyy taloudellisia, oikeudellisia ja turvallisuusseurauksia, jotka kasaantuvat jokaiseen ohjelmaan, joita toimittaja ajaa samanaikaisesti. Yksi väärin sovellettu yrityssopimus luokitellun ja luokittelemattoman verkon välillä, GPL-lisensoitu kirjasto upotettuna luovutukseen ilman lähdekoodin julkistamista tai palvelinlisenssi, joka on laskettu pistokkeen eikä ytimen mukaan, voi kukin tuottaa kuuden tai seitsemän numeron täydennysmaksupyyntöjä auditointia suorittavalta toimittajalta, korjaustoimenpidepyynnön DCSA:lta tai kielteisen immateriaalioikeuspäätöksen, joka nollaa luovutuksen oikeustason.

Monimutkaisuus on rakenteellista. Puolustustoimittajat toimivat useissa turva-alueissa, tukevat kymmeniä ohjelmia eri sopimuksin ja ottavat COTS-ohjelmistoja käyttöön kokoonpanoissa — virtualisoiduissa klustereissa, valtion pilvieristehissä, ulkomaan tehtäväjärjestelmissä — joiden käsittelyyn lisenssitoimittajat eivät ole suunnitelleet laskentametrejaan siististi. DFARS-ohjelmisto-oikeuskehys lisää kerroksen valtiolle ominaisia velvoitteita standardien kaupallisten lisenssiehtojen päälle. Avoimen lähdekoodin sisällyttäminen luovutuksiin laukaisee julkistusvaatimuksia, joita useimmat ohjelmistotiimit kohtaavat vasta kun ohjelman turvallisuusvastaava merkitsee ne ennen toimitusta.

Tässä artikkelissa käsitellään koko teknistä ja sääntelymaisemaa: puolustusohjelmille ominaisia lisenssiriskikaavoja, COTS-inventaarion arkkitehtuuria, DFARS-oikeuslausekkeita, auditointitodisteiden valmistelua, avoimen lähdekoodin noudattamisen työkaluja, lisenssien optimointimenetelmiä ja tehtäväkriittisten järjestelmien ohjelmistoescrow-vaatimuksia.

Ohjelmistolisenssien riskit puolustusohjelmissa

Puolustustoimittajat aliarvioivat järjestelmällisesti ohjelmistolisenssien riskejä, koska ohjelmien budjetit huomioivat lisenssien ostokustannuksen mutta harvoin sen kustannuksen, joka aiheutuu niiden ehtojen noudattamisesta, joilla lisenssit on myönnetty. Oston ja noudattamisen välinen ero levenee jokaisen sellaisen ohjelman myötä, joka käyttää COTS-työkalua uudessa sopimuksessa tarkistamatta, salliko olemassa oleva lisenssi sen käytön.

Laajuuden aliarviointikaavat

Yleisin aliarviointikaava koskee palvelin- ja prosessorilisenssimetrejä. Yritysohjelmistotoimittajat siirtyivät palvelinkohtaisesta prosessorikohtaiseen ja edelleen ydinkohtaiseen lisensointiin peräkkäisten tuotosukupolvien aikana. Toimittaja, joka osti palvelinkohtaisen tietokantalisenssin vuonna 2018 ja siirsi työkuorman uuteen moniprosessoripalvelimeen vuonna 2024, voi nyt olla noudattamatta vaatimuksia ilman ohjelmiston muuttamista — laitteistomuutos lisäsi prosessorien määrää, mikä muutti lisenssivelvoitetta nykyisten ydin­tekijälaskentasääntöjen mukaisesti. Harvat ohjelmapäälliköt seuraavat tätä yhteyttä infrastruktuurin päivityskierrosten ja lisenssimetrien muutosten välillä.

Käyttäjäkohtainen lisenssien laskenta tuo esiin erilaisen aliarviointikaavan. Nimitettyjen käyttäjien lisenssejä luokitelluissa ympäristöissä otetaan usein liikaa käyttöön, koska turvallisuusluvan haltijat vaihtuvat ohjelmien välillä. Käyttäjä, joka lopettaa työn ohjelmassa A ja siirtyy ohjelmaan B, on yhä aktiivinen ohjelman A ohjelmistojärjestelmissä, kunnes joku hallinnollisesti poistaa sen. SAM-työkalut, jotka laskevat aktiiviset käyttäjätilit todennettujen aktiivisten käyttäjien sijaan, raportoivat enemmän käytössä olevia paikkoja kuin todella on, mikä paisuttaa näkyvää noudattamiseroa — mutta organisaatiot, jotka laskevat vain samanaikaiset istunnot, saattavat huomata olevansa noudattamatta vaatimuksia piikkikausina, jolloin käyttäjämäärät nousevat.

Pilvilisenssinteko valtion pilvessä

Pilvilisenssinteko GovCloud-ympäristöissä (IL4-, IL5-, IL6-eristehet) tuo esiin lisenssiriskiluokan, johon useimmat paikalliset hankintatiimit eivät ole valmiita. Standardit kaupalliset COTS-lisenssit eivät usein salli käyttöönottoa kolmannen osapuolen isännöimässä ympäristössä ilman pilvilisäystä. Toimittajat, jotka havaitsevat käytön valtion pilvuokralaisessa — IP-telemetrian, auditoinnin yhteydessä toimitettujen käyttölokkien tai jälleenmyyjien raporttien kautta — kohtelevat käyttöönottoa erillisenä lisenssivaatimuksena paikallisesta käyttöoikeudesta. Puolustustoimittajat, jotka siirsivät paikallisia työkuormia IL5-pilviympäristöihin käyttäen olemassa olevia pysyviä lisenssejä tarkistamatta pilvikäytön oikeuksia, kantavat julkistamatonta noudattamisriskiä jokaisessa kosketellussa ohjelmassa.

Laajempaan näkymään siitä, miten ohjelmiston toimitusketjun hallintakeinot vuorovaikuttavat lisensoinnin kanssa, katso analyysimme SBOM-pakottamisesta puolustusputkissa, joka käsittelee samasta noudattamisasemasta johtuvia alavirran komponenttien avoimuusvaatimuksia.

COTS-lisenssi-inventaarion hallinta

COTS-lisenssi-inventaario on minkä tahansa ohjelmistojen noudattamisen ohjelman perusta. Sillä on kaksi osaa, jotka on pidettävä synkronisoituna: käyttöoikeustietokanta (mitä lisenssejä toimittaja on ostanut) ja käyttöönototietokanta (mitä ohjelmistoja on todella asennettu ja käytössä). Noudattamisero on niiden välinen ero. Eron hallinta edellyttää sekä tarkkoja tietoja että prosessia ristiriitojen ratkaisemiseksi.

SAM-työkalun valinta puolustusympäristöihin

Ohjelmistovarojen hallinnan työkalujen on täytettävä vaatimukset, jotka poistavat useimmat kuluttajatason tai pelkästään SaaS-muotoiset tuotteet harkinnasta. Luokiteltuihin verkkoihin SAM-työkalun on:

• Toimittava kokonaan paikallisesti ilman kotiinsoittotelemetriaa ulkoisiin päätteisiin
• Tuetun agenttipohjaisen inventaroinnin Windows- ja Linux-päätelaitteissa ilman internetkäyttöä agenttipäivityksiin
• Tuotettava löydettävä inventario vietävissä muodoissa (CSV, SPDX tai XML) ilman pilvivälittäjiä
• Ylläpitänyt erillisiä inventarointi-instansseja kullekin turva-alueelle (luokittelematon, CUI, luokiteltu) ilman raja-alueiden välistä tietovuotoa
• Normalisoinut tuotenimet ja versiot offline-lisenssikirjastoon, jota voidaan päivittää hallitulla medialla

Työkalut, jotka täyttävät nämä vaatimukset, ovat yleensä yritystason SAM-alustojen paikallisia käyttöönottoja. Lisenssikirjaston normalointikyky on erityisen tärkeä: raaka inventarointituloste luettelee satoja tuotevariantteja ja versiomerkkijonoja, jotka on ratkaistava kanonisiin tuoteidentiteetteihin ennen kuin käyttöoikeuksien vertailu on merkityksellistä.

Automaattinen inventarointi vs manuaalinen inventario

Automaattinen inventarointi on tarkempaa ja johdonmukaisempaa kuin manuaalinen inventario päätelaitteiden ohjelmistoille, mutta sillä on sokeita pisteitä puolustusympäristöissä: ohjelmisto, joka on asennettu järjestelmiin, jotka eivät ole verkkoon kytkettyjä (erilliset luokitellut työasemat, käytössä olevat järjestelmät, testausalustat), laiteohjelmistoon upotettu tai osana alustan integraatiota toimitettu ohjelmisto sekä ohjelmisto, joka toimii vain tiettyinä tehtävävaiheina eikä ole aktiivinen inventarointiskannauksien aikana. Manuaalinen inventario täydentää automaattista inventarointia näissä luokissa käyttäen dokumentoituja tarkastusmenettelyjä ja ajoittaisia fyysisiä kartoituksia ei-verkkoon kytketyistä järjestelmistä.

Lisenssien käyttöoikeustietokannan arkkitehtuuri

Käyttöoikeustietokannan on tallennettava jokaiselle lisenssitietueelle:

• Tuotenimi ja versio (normalisoituna toimittajan kanoniseen muotoon)
• Lisenssimetriikka (käyttäjäkohtainen, ydin­kohtainen, palvelinkohtainen, samanaikaiskäyttö, tilausyksikkö)
• Käyttöoikeuksien määrä ja metriikkaa vastaava mittayksikkö
• Käyttöoikeuden todiste: ostotilauksen numero, laskun numero, lisenssitodistuksen sarjanumero, ELA-aikataulun viite
• Ohjelma ja sopimus, joita lisenssi tukee (kustannusten kohdistamiseen ja auditoinnin jäljitykseen)
• Käyttöönoton laajuusrajoitukset (vain paikallisesti, pilvilisäys mukana, luokiteltu verkko sallittu)
• Uusimispäivä tai pysyvä tila
• Valtion käyttöön liittyvä lisäys tai erityiset liittovaltion lisäysehdot

Vastaavuuskysely, joka tuottaa noudattamiseroraportin, on liitettävä käyttöoikeustietokanta inventarointitietokantaan normaloidun tuoteidentiteetin perusteella ja summattava käyttöönotot käyttöoikeuksiin metriikkayksiköittäin. Ristiriidat, joissa käyttöönotot ylittävät käyttöoikeudet, vaativat välittömän seulonnan: vahvista käyttöönottojen määrä olevan tarkka ja osta sitten joko lisäkäyttöoikeuksia tai poista luvattomat asennukset.

DFARS-ohjelmisto-oikeuslausekkeet

DFARS:n osa 227 vahvistaa kehyksen, jonka mukaan Yhdysvaltain hallitus hankkii oikeuksia puolustussopimusten nojalla kehitettyyn tai niiden täytäntöönpanossa käytettyyn ohjelmistoon. Puolustustoimittajille sovellettavat lausekkeet vaihtelevat sen mukaan, onko ohjelmisto kaupallista (DFARS 227.7202) vai ei-kaupallista (DFARS 227.7103 ja siihen liittyvä sopimuslauseke DFARS 252.227-7014).

DFARS 252.227-7014: oikeudet ei-kaupalliseen ohjelmistoon

DFARS 252.227-7014 koskee puolustussopimuksen nojalla erityisesti valtion rahoituksella kokonaan tai osittain kehitettyä ohjelmistoa. Lauseke vahvistaa neljä vakiollista oikeustasoa:

• Rajoittamattomat oikeudet: Valtio voi käyttää, jäljentää, muokata, julkaista tai paljastaa ohjelmiston ilman rajoituksia. Koskee kokonaan valtion kustannuksella kehitettyä ohjelmistoa.
• Valtion käyttötarkoituksen oikeudet (GPR): Siirtymätaso sekarahoituksella kehitetylle ohjelmistolle. Valtio voi käyttää ohjelmistoa mihin tahansa valtion tarkoitukseen, mutta se ei saa luovuttaa sitä kaupallisille osapuolille GPR-kauden aikana (tyypillisesti viisi vuotta). GPR-kauden päätyttyä oikeudet muuttuvat rajoittamattomiksi.
• Rajoitetut oikeudet: Koskee kokonaan yksityisin varoin kehitettyä ohjelmistoa. Valtio voi käyttää ohjelmistoa vain sisäisiin valtion tarkoituksiin eikä saa luovuttaa sitä kolmansille ilman toimittajan suostumusta.
• Nimenomaisesti neuvotellut lisenssioikeudet: Mikä tahansa oikeusjärjestely, joka ei kuulu vakiotasoihin ja joka kirjataan sopimukseenkohtaiseen lisenssilisäykseen. Käytetään hybridi­tilanteisiin, joita vakiotasot eivät ratkaise siististi.

Rahoituspäätös — oliko kehitys valtion kustannuksella, yksityisin varoin vai sekarahoituksella — on eniten kiistelty näkökulma oikeusvaatimuksiin. Toimittajien on pidettävä yksityiskohtaisia rahoitustietoja jokaisesta ohjelmistokomponentista kehityksen ajankohtana tuekseen oikeusvaatimuksiaan teknisten tietojen oikeuksien tarkastelun aikana.

Kaupallisen ohjelmistolisenssin siirto

COTS-ohjelmistolle DFARS 227.7202-1 velvoittaa valtion hankkimaan vain toimittajan vakaissa kaupallisissa lisenssisopimuksissa saatavilla olevat oikeudet edellyttäen, että nämä ehdot ovat yhteensopivia liittovaltion lain kanssa eivätkä muuten kiellettyjä. Tämä tarkoittaa, että COTS-toimittajan lisenssisopimus siirtyy valtion asiakkaalle muuttamattomana DFARS-oikeuskehyksen kautta — valtio ei voi vedota rajoittamattomien oikeuksien määräyksiin COTS-toimittajaa vastaan, jonka vakiolliset ehdot rajoittavat valtion käyttöä.

Päätoimittajille tämä luo alihankintavelvoitteen: kun COTS-ohjelmisto sisällytetään luovutettavaan järjestelmään, päätoimittajan on tunnistettava COTS-komponentit, liitettävä tai viitattava niiden kaupallisiin lisenssiehtoihin ja varmistettava, että valtio ymmärtää saavansa toimittajan ehdot, eikä DFARS-oikeuksiin perustuvaa käyttöoikeutta. COTS-komponenttien tunnistamatta jättäminen ja niiden kaupallisen lisenssiaseman vahvistamatta jättäminen sopimuksen täytäntöönpanon aikana voi johtaa siihen, että valtio vaatii myöhemmin rajoittamattomia oikeuksia DFARS-oletuksen perusteella — riita, jonka oikeudenkäynti on kallista.

Ymmärrys siitä, miten ohjelmisto-oikeudet vuorovaikuttavat laajemman puolustushankinnan täydellisen oppaan kanssa, auttaa toimittajia rakentamaan immateriaalistrategiansa ennen sopimuksen myöntämistä, jolloin neuvotteluvaltti on suurin.

Auditointivalmius toimittaja- ja DCSA-auditointeihin

Ohjelmistolisenssiauditoinnin voi aloittaa kaupallinen toimittaja käyttäen yrityslisenssisopimuksen auditointioikeuksia tai DCSA osana turvallisuusluvan tarkastusta, johon sisältyy tietoturvahallinnan arviointi. Auditointityypit eroavat laajuudeltaan ja toimivallaltaan, mutta molemmat vaativat saman perustavanlaatuisen todistepaketin.

Auditointitodistepaketin valmistelu

Auditointitodistepaketti on valmisteltava etukäteen ja pidettävä sellaisessa tilassa, että se voidaan tuottaa lisenssisopimuksessa määrätyssä ilmoitusajassa — usein 30 päivässä, joskus jopa 10 arkipäivässä. Paketin on sisällettävä:

• Lisenssien käyttöoikeustodistukset kaikille auditoinnin laajuuteen kuuluville tuotteille
• Ostotilaukset ja laskut ristiinviitattuna kunkin tuotteen ja version mukaan, jotka kattavat kaikki lisenssiostot auditorin määrittelemälle takautuvalle kaudelle (tyypillisesti kolmesta viiteen vuoteen)
• Yrityslisenssisopimuksen (ELA) aikataulut voimassaoloaikoineen, katettuine tuoteluetteloineen ja valtuutettuine käyttäjämäärineen
• SAM-työkalun inventarointiraportit, jotka on päivätty 30 päivän sisällä auditointipyynnöstä ja jotka näyttävät käytössä olevat tuoteversiot ja määrät
• Vastaavuuslaskentataulukko, joka kuvaa käyttöoikeudet käyttöönotoiksi kullekin kohteena olevalle tuotteelle
• Valtion käyttöön liittyvät lisäykset tai liittovaltion täydennykset, jotka muuttavat vakaaita kaupallisia ehtoja
• Käytöstäpoistoraportit auditointikauden aikana poistetulle ohjelmistolle

Lisenssien vastaavuusvertailun menetelmä

Auditointitodisteiden valmisteluun käytettävän vastaavuusvertailun menetelmän on oltava johdonmukaista ja dokumentoitavissa. Käyttäjäkohtaisille lisensseille menetelmän tulisi käyttää todennettujen aktiivisten käyttäjien määriä määritellyllä mittauskaudella (tyypillisesti 90 päivän huippukäyttökausi ennen auditointia), ei hetkellistä laskentaa yhtenä päivänä. Ydin­kohtaisille lisensseille menetelmän on dokumentoitava kunkin ohjelmaa ajavan palvelimen tai virtuaaliklusterin fyysinen ydinmäärä soveltaen toimittajan julkaisemaa ydin­tekijätaulukkoa tarvittaessa. Tauslisensseille menetelmän on huomioitava käytön aktiivinen kausi, ei vain nykyinen hetkelliskuva, koska takautuvat täydennykset koskevat historiallista käyttöä, joka ylitti käyttöoikeusmäärät tilauskauden aikana.

Tyypilliset auditointihavainnot puolustusympäristöissä

Puolustustoimittajien auditoinnit paljastavat johdonmukaisesti joukon toistuvia havaintoja, jotka hyvin suunniteltu noudattamisohjelma poistaa ennaltaehkäisevästi:

• Luvattomat asennukset: Ohjelmisto, joka on löydetty päätelaitteilta ilman vastaavaa käyttöoikeustietuetta — tyypillisesti yksittäisten käyttäjien kätevyyden vuoksi ilman hankintahyväksyntää asentamaa.
• Lisenssimetriikan virheellinen soveltaminen: Käyttäjäkohtaisia lisenssejä käytetty prosessoripohjaisissa ympäristöissä tai samanaikaiskäyttölisenssejä laskettu ikään kuin ne olisivat nimitettyjen käyttäjien lisenssejä.
• Versiopäivitysten aukot: Ohjelmisto päivitetty uuteen pääversioon ilman päivitysoikeuksien ostamista ylläpitosopimuksesta, joka oli ehtinyt raueta.
• Pilvikäyttöönotto ilman pilvilisäystä: Paikallisia lisenssejä sovellettu valtion pilvikäyttöönotoihin, joissa toimittajan ehdot vaativat erillisen pilvikäytön oikeuden.
• Puuttuvat käyttöoikeusasiakirjat: Lisenssit ostettu ja asennettu vuosia sitten ilman lisenssitodistuksen tai ostotilauksen säilyttämistä, jolloin toimittaja ei pysty todistamaan käyttöoikeuttaan.

Ohjelmistolisenssien noudattamisen toimitusketjuulottuvuus liittyy suoraan laajempiin toimitusketjun riskien hallintaan puolustuksessa -hallintakeinoihin, joita puolustusohjelmien on toteutettava — luvaton ohjelmisto on sekä noudattamisvirhe että turvallisuusriski.

Avoimen lähdekoodin lisenssien noudattaminen

Puolustusluovutuksiin sisällytetty avoimen lähdekoodin ohjelmisto (OSS) luo noudattamisvelvoitteita, jotka eroavat laadultaan COTS-lisenssien velvoitteista. COTS:n noudattamatta jättäminen luo taloudellisen vastuun toimittajaa kohtaan. OSS:n noudattamatta jättäminen — erityisesti copyleft-lisenssiehtojen rikkominen — voi luoda velvoitteen paljastaa omistusoikeuden alainen lähdekoodi kenelle tahansa ohjelman vastaanottajalle, mukaan lukien valtio, joka ei ehkä pysty enää rajoittamaan jatkuvaa paljastamista.

GPL/LGPL-copyleft-riski puolustusluovutuksiin

GPL-versiot 2 ja 3 asettavat copyleft-vaatimuksen: kolmannelle osapuolelle levitetty johdettu tai yhdistetty työ on lisensoitava samoilla GPL-ehdoilla ja siihen on liitettävä (tai tarjottava) täydellinen vastaava lähdekoodi. Puolustustoimittajalle, joka luovuttaa ohjelmistojärjestelmän valtiolle, toimitus on jakotapahtuma, joka laukaisee GPL-julkistusvelvoitteen kaikille luovutukseen sisälletyille GPL-lisensoituille komponenteille.

Käytännön riski ei ole harmittomien apukoodien paljastaminen — se on omistusoikeuden alaisten algoritmisten toteutusten paljastaminen, jotka sattuvat olemaan staattisesti linkitetty GPL-kirjastoon. Jos toimittajan kohdennusalgorimmin moduuli käännetään samaan binääriin GPL-lisensoitua tietojäsittelykirjaston kanssa, GPL:n copyleft-määräykset voivat vaatia koko yhdistetyn työn paljastamisen, kohdennusalgorimi mukaan lukien, kun binääri luovutetaan. Riippuuko tämä tulos tarpeellisuudesta, määräytyy GPL-version, integrointitavan (staattinen vs dynaaminen linkitys) ja siitä, miten GPL-komponenttia käytetään — mutta riski on arvioitava ennen luovutusta, ei löydetty jälkikäteen turvallisuustarkastelun aikana.

LGPL (Lesser GPL) soveltaa heikompaa copyleft-sääntöä, joka sallii omistusoikeuden alaisen ohjelmiston linkittävän dynaamisesti LGPL-kirjastoon laukaisematta copyleft-velvoitetta omistusoikeuden alaiseen koodiin. Staattinen linkitys LGPL-kirjastoon kantaa yhä riskin. Turvallisen dynaamisen linkityksen ja riskialttiin staattisen sisällyttämisen raja on arvioitava käännöskokoonpanon tasolla, ei lähdekoodin tasolla.

Lisenssiskannerin integrointi

Lisenssiskannerit — FOSSA, Black Duck (Synopsys), SCANOSS ja vastaavat paikalliset työkalut — automatisoivat OSS-tunnistuksen ja lisenssien havaitsemisen koodivaroissa, käännöstuotoksissa ja konttikuvissa. Integrointi CI/CD-putkeen pakottaa lisenssipolitiikan kohtaan, jossa OSS otetaan käyttöön: kun kehittäjä lisää uuden riippuvuuden, skanneri tunnistaa lisenssin, tarkistaa sen hyväksyttyä lisenssipolitiikkaa vasten ja estää käännöksen, jos lisenssi luokitellaan korkean riskin ilman dokumentoitua poikkeamaa.

Luokitelluille varastoille skannerin on toimittava eristetyssä tilassa paikallisesti ylläpidettyä komponenttitietokantaa vasten — pilvipohjaiset lisenssihaku-API:t eivät ole käytettävissä luokitelluissa verkoissa. Paikallinen tietokanta on päivitettävä hallitulla ylläpitokierroksella ja versioitava, jotta skannauksen tulokset ovat toistettavissa ja auditointikelpoisia. Skannerin tulokset kullekin toimitukselle on arkistoitava osaksi ohjelman teknistä peruslinjaa, koska OSS-julkistusvelvoitteita arvioidaan kunkin toimituksen sisältämien komponenttien, eikä koodikannan nykytilan perusteella.

OSS-julkistusvelvoitteet

Kun puolustussopimus vaatii SBOM:n (Software Bill of Materials) toimittamista, lisenssiskannerin tuottama OSS-inventaario syötetään suoraan SBOM-tulokseen. NTIA:n vähimmäiselementtimuoto ja SPDX-määritys molemmat vaativat komponenttitason lisenssintunnistuksen, jonka skanneri tarjoaa. Mutta SBOM on julkistusasiakirja, ei noudattamistodistus — toimittajan on lisäksi varmistettava, että kaikki copyleft-julkistusvelvoitteet täyttyvät erillisenä vaiheena SBOM-tuotannosta. Tarkan SBOM:n tuottaminen, joka luettelee GPL-komponentin paljastamatta lähdekoodia, täyttää avoimuusvaatimuksen mutta ei lisenssivelvoitteen.

Lisenssien optimointistrategiat

Lisenssien noudattaminen on lattia. Lisenssien optimointi on katto — järjestelmällinen pyrkimys vähentää lisenssikustannuksia poistamalla hukkaa, kohdistamalla käyttöoikeudet tehokkaammin uudelleen ja korvaamalla edullisemmilla vaihtoehdoilla teknisten vaatimusten salliessa. Puolustussopimusten ympäristöissä, joissa on suuria, pitkäkestoisia ohjelmia ja hitaita hankintasyklejä, merkittäviä säästöjä kertyy optimoinnista, jotka eivät koskaan näy yhden ohjelman näkymässä.

Käyttämättömien lisenssien takaisinkeruu

Lisenssien takaisinkeruu on prosessi, jossa otetaan takaisin lisenssejä, jotka on osoitettu käyttäjille tai järjestelmille, jotka eivät enää ole aktiivisia kuluttajia. SAM-työkalut, jotka seuraavat käyttötiheyttä — eivät vain asennusmäärää — tunnistavat lisenssit, jotka on osoitettu mutta joita ei ole käytetty määritellyllä kaudella (tyypillisesti 60–90 päivää). Nämä lisenssit ovat ehdokkaita takaisinkeruulle ja uudelleenkohdistukselle aktiivisille käyttäjille, jotka tarvitsevat niitä. Suurissa puolustustoimittajaympäristöissä takaisinkeruukierrokset palauttavat johdonmukaisesti 15–25 prosenttia käytössä olevista käyttäjäkohtaisista lisensseistä yritystuottavuuden ja insinöörityökalujen luokissa, mikä merkitsee olennaista kustannusten välttämistä uusimisen yhteydessä.

Virtualisoinnin lisenssi­vaikutukset

Virtualisointi luo lisenssien optimointimahdollisuuksia ja -riskejä samanaikaisesti. Mahdollisuus: fyysisten palvelimien konsolidointi vähentää fyysistä ydinmäärää, johon ydin­kohtaisia lisenssejä on sovellettava, mikä saattaa vähentää lisenssivelvoitetta. Riski: virtuaalikoneiden siirto-ominaisuudet (live-migraatio, korkean saatavuuden klusterointi) voivat aiheuttaa sen, että lisensoitua ohjelmistoa ajava VM siirtyy isäntään, jossa on enemmän fyysisiä ytimiä, mikä lisää lisenssivelvoitetta ilman ihmisen toimintaa. Tämän riskin hallinta edellyttää joko VM-siirtokäytäntöjen määrittämistä rajoittamaan liike ennalta lisensoituihin isäntäpooleihin tai riittävien lisenssien ostamista koko siirtotietueen kattamiseen — lähestymistapa, jota toimittajat suosivat, koska se poistaa siirtokäytäntöjen hallintataakan.

Hybridinen kaupallinen/avoin korvausanalyysi

Ei-luokitelluille, ei-tehtäväkriittisille työkaluluokille — kehitysympäristöt, dokumentaatiotyökalut, projektinseurantajärjestelmät, data-analyysialustat — avoimen lähdekoodin vaihtoehdot täyttävät usein toiminnalliset vaatimukset merkittävästi edullisemmin. Korvausanalyysi vertaa nykyisen COTS-lisenssin kokonaisomistuskustannusta (lisenssimaksut, tukikustannukset, koulutuskustannukset, integrointikustannukset) OSS-vaihtoehdon kokonaisomistuskustannukseen (toteutuskustannus, tarvittaessa tukisopimus, koulutus, integrointi). Analyysin on myös arvioitava OSS-vaihtoehdon lisenssiehtoja sen varmistamiseksi, että korvaus ei tuo mukanaan uutta copyleft-noudattamisvelvoitetta.

Korvauspäätökset puolustusympäristöissä vaativat lisäksi turvallisuusarvion: luokitelluissa ympäristöissä käytettävät OSS-tuotteet on hyväksyttävä käytettäväksi luokitelluissa järjestelmissä asianmukaisella akkreditointiprosessilla, mikä lisää lyijyaikaa ja kustannuksia korvaushankkeelle, joita pelkkä lisenssikustannusten vertailu ei huomioi.

Ohjelmistoescrow ja jatkuvuus

Ohjelmistoescrow on jatkuvuusmekanismi, joka suojaa valtion — ja toimittajan — kykyä ylläpitää ja muokata räätälöityä ohjelmistoa, jos alkuperäinen kehittäjä ei enää kykene tukemaan sitä. Puolustusohjelmilla, joiden käyttöikä on pitkä (monissa alustaohjelmissa 15–30 vuotta), todennäköisyys siihen, että alkuperäinen ohjelmiston kehittäjä on yhä saatavilla ja halukas tukemaan ohjelmistoa koko ohjelman elinkaaren ajan, ei ole suuri. Escrow käsittelee tätä riskiä varmistamalla pääsyn lähdekoodiin ja käännösmateriaaleihin, kun määritellyt laukaisutapahtumat toteutuvat.

Escrow-vaatimukset räätälöidylle puolustusohjelmistolle

Räätälöityä tehtäväkriittistä ohjelmistoa koskeviin puolustussopimuksiin sisältyy yhä useammin escrow-lausekkeita, jotka määrittelevät:

• Escrow-edunvalvojan (nimetty kaupallinen escrow-palveluntarjoaja, ei valtion laitos)
• Talletusaikataulun — tyypillisesti sopimuksen myöntämisen yhteydessä tapahtuva alkuperäinen talletus, sitten päivitys jokaisen merkittävän julkaisun virstanpylvään yhteydessä ja sen jälkeen vuosittain
• Talletuksen sisältövaatimukset: lähdekoodi kaikille räätälöidyille komponenteille, käännöskriptit, kolmannen osapuolen riippuvuuksien määritykset, käännösympäristön dokumentaatio (kääntäjien versiot, käännöstyökalujen versiot, asetustiedostot)
• Varmistustestauksen vaatimukset — edunsaajan oikeus testata talletusta sen vahvistamiseksi, että se on täydellinen ja käännettävissä
• Escrow-julkaisun laukaisutapahtumat: toimittajan maksukyvyttömyys, tuen lakkauttaminen ohjelmistolle, ylläpitosopimuksen olennainen rikkominen tai toimittajan laiminlyönti

Escrow-talletusten varmistustestaus

Escrow-talletus, jota ei ole koskaan testattu, on oikeudellinen asiakirja, ei käytettävissä oleva varallisuuserä. Varmistustestaus vahvistaa, että talletetut materiaalit ovat täydelliset ja riittävät ohjelman uudelleenrakentamiseen ilman viittausta kehittäjän sisäisiin järjestelmiin. Mielekäs varmistustestaus rakentaa käännösympäristön uudelleen talletetuista määrityksistä, asentaa talletetut riippuvuudet, ajaa käännöskriptit talletettua lähdekoodia vasten ja suorittaa toiminnallisen testisarjan tuloksena olevaa käännöstuotosta vasten. Mikä tahansa aukko talletuksessa — puuttuva riippuvuus, dokumentoimaton käännöstyökalun versio, kovakoodattu polku kehittäjän sisäiseen järjestelmään — nousee esiin varmistustestauksessa ja voidaan korjata täydentävällä talletuksella ennen kuin escrowa tarvitaan todellisessa jatkuvuustilanteessa.

Escrow-julkaisun laukaisutapahtumat

Escrow-julkaisua säätelevät escrow-sopimuksen laukaisutapahtumamääritykset, ja se on aloitettava muodollisen pyyntöprosessin kautta. Yleisimmät laukaisutapahtumat puolustusohjelmistojen escrow-sopimuksissa ovat toimittajan maksukyvyttömyys (konkurssihakemus tai selvitysmiehen nimitys), kilpailijan ostama toimittaja, joka lakkauttaa tuotteen, ylläpidon lakkauttaminen ja olennainen ohjelmiston ylläpitosopimuksen rikkominen, joka jää korjaamatta ilmoitus- ja korjauskauden jälkeen. Julkaisupyynnön prosessiin kuuluu tyypillisesti kirjallinen ilmoitus escrow-edunvalvojalle laukaisutapahtuman tunnistamiseksi, odotuskausi, jonka aikana kehittäjä voi riitauttaa julkaisun, ja puolueeton päätös, jos julkaisu kiistetään. Toimittajien tulisi tarkistaa escrow-sopimuksensa sen varmistamiseksi, että laukaisutapahtumamääritykset ovat riittävän tarkkoja, jotta niihin voidaan vedota ilman oikeudenkäyntiä — epämääräiset määritykset tuottavat epäselvyyttä, joka hidastaa pääsyä talletettuihin materiaaleihin juuri silloin, kun nopeus on tärkeintä.