GitHub voi estää väärän lisenssin – ominaisuus vaatii Code Securityn

GitHubin 16. lokakuuta 2026 julkaisema tiedote ilmoitti lisenssitarkistuksen yleisestä saatavuudesta GitHub Enterprise Cloudissa, myös dataresidenssiä käyttävissä ympäristöissä. Ominaisuus koskee arkistoja, joissa GitHub Code Security on käytössä. Yrityksen lisenssipolitiikkaan liitetty aktiivinen sääntö voi estää pull requestin yhdistämisen, jos muutos tuo arkistoon riippuvuuden, jonka lisenssi ei ole sallittu.

Ratkaisevaa on sääntöjoukon tila. Evaluate näyttää lisenssiristiriidan pull requestissa, kun taas Active voi tehdä sen ratkaisemisesta yhdistämisen ehdon. Yritys määrittää hyväksytyt lisenssit keskitetysti ja kohdistaa valvonnan valitsemiinsa arkistoihin. Näin sama politiikka voi olla yhdessä arkistossa kokeiltavana ja toisessa jo pakollinen.

Saatavuus ratkaistaan arkistossa

Enterprise Cloud -tilaus ei yksin käynnistä lisenssivalvontaa. GitHubin käyttöönotto-ohje edellyttää GitHub Code Securityä niissä arkistoissa, joihin toimintoa sovelletaan, sekä käytössä olevaa riippuvuuskaaviota. Politiikan ja sääntöjoukkojen määrittäjällä täytyy lisäksi olla oikeudet niiden hallintaan.

Valvonta kohdistuu arkistoon vasta, kun sitä koskee haaran sääntöjoukko, jossa vaaditaan lisenssitarkistuksen tulos ennen yhdistämistä. Sääntöjoukko voidaan luoda yrityksen, organisaation tai arkiston tasolle. Kohteeksi voi valita arkistot suoraan, arkistojen nimikuvion perusteella tai käyttöönottoa ohjaavan mukautetun ominaisuuden avulla. Yrityksen sallintalistan olemassaolo ei siis vielä kerro, estääkö tarkistus juuri tietyn arkiston muutoksia.

SPDX-sallintalista muodostaa yhteisen perustan

Yrityksen politiikka määrittää, mitä avoimen lähdekoodin lisenssejä riippuvuuksissa hyväksytään. Lisenssin voi valita GitHubin luettelosta tai lisätä SPDX-tunnisteella, jos sitä ei löydy valmiista vaihtoehdoista. Aiemmin laaditun politiikan voi tuoda SPDX-lisenssi-ilmausten luettelona. Näin sama hyväksyntäpäätös voidaan soveltaa useaan arkistoon ilman, että jokainen tiimi ylläpitää omaa lisenssilistaansa.

Valmis luettelo luokittelee lisenssejä niiden yleisen yrityskäyttöön liittyvän riskin mukaan, mutta hyväksyttävien lisenssien valinta jää yritykselle. GitHub vertaa havaittuja lisenssejä tähän päätökseen; tarkistus ei ratkaise lisenssiehtojen oikeudellista tulkintaa yrityksen puolesta. Keskitettyyn perustasoon voidaan lisätä poikkeuksia, jolloin arkistossa voimassa oleva kokonaisuus muodostuu politiikasta ja sitä koskevista poikkeuksista.

Tämä ero näkyy esimerkiksi silloin, kun yhtä pakettia tarvitaan rajatussa arkistossa mutta sen lisenssiä ei haluta hyväksyä kaikkien riippuvuuksien yleiseksi ehdoksi. Pakettia koskeva poikkeus voidaan käsitellä erikseen muuttamatta koko sallintalistaa. Arkistoon kirjoitusoikeuden saanut kehittäjä voi nähdä arkiston voimassa olevan politiikan ja poikkeukset sen lisenssipolitiikan asetuksissa.

Pull request näyttää ristiriidan ennen yhdistämistä

Lisenssitarkistus käynnistyy, kun pull request muuttaa pakettien määrittelytiedostoja. GitHub vertaa lähtöhaaran ja ehdotetun haaran riippuvuuksia ja arvioi muutoksen mukana tulevien uusien tai muuttuneiden riippuvuuksien lisenssit. Tarkastelu kattaa suorat riippuvuudet sekä riippuvuuskaaviosta havaitut välilliset riippuvuudet. Politiikan vastainen lisenssi näkyy pull requestin huomautuksena kyseisen riippuvuuden yhteydessä.

Evaluate-tilassa sääntöjoukko suorittaa tarkistuksen ja näyttää havainnon, mutta lisenssiehto ei itsessään estä yhdistämistä. Active-tilassa samaan sääntöjoukkoon kuuluva lisenssituloksen vaatimus estää politiikan vastaisen riippuvuuden sisältävän muutoksen yhdistämisen, kunnes ristiriita on ratkaistu. Molemmat tilat edellyttävät, että sääntöjoukossa on otettu käyttöön lisenssitarkistuksen tulosta vaativa ehto.

Evaluate-tilallakin voi olla vaikutus yhdistämiseen, jos arkiston muu haarasuojaus vaatii kommenttien ratkaisemista. Mail Studion katsaus kuvaa tämän poikkeuksen: myös Evaluate-tilassa syntyvä lisenssihuomautus voi kuulua haarasuojauksen ratkaistaviin kommentteihin. Tällöin yhdistämisen este johtuu kyseisestä suojaussäännöstä, vaikka lisenssisääntö on arviointitilassa.

Poikkeus voidaan rajata pakettiin tai arkistoon

Lisenssihuomautus ei tee poikkeuspyyntöä automaattisesti. Kehittäjä voi poistaa riippuvuuden, vaihtaa sen hyväksyttyyn vaihtoehtoon tai pyytää politiikan muuttamista. Jos riippuvuus halutaan säilyttää, kehittäjä voi perustella poikkeuspyynnön. Näin yksittäinen ristiriita tulee erikseen ratkaistavaksi sen sijaan, että jokainen havainto muuttaisi yrityksen yhteistä politiikkaa.

GitHub tarjoaa käsittelyyn Enterprise Open-Source License Manager -yritysroolin. Rooliin nimetyt henkilöt tai tiimit saavat ilmoituksia odottavista pyynnöistä ja voivat hyväksyä tai hylätä ne yrityksen hallintanäkymässä. Hyväksyjä voi kohdistaa poikkeuksen pakettiin, lisenssiin tai pakettimalliin ja valita, koskeeko ratkaisu yhtä arkistoa vai koko yritystä. Poikkeuksen laajuus määrää, missä myöhemmissä muutoksissa sama lisenssihavainto käsitellään hyväksyttynä.

Hyväksytty poikkeus sulkee sitä koskevan hälytyksen ja voi vapauttaa pull requestin lisenssisäännön aiheuttamasta estosta. Muut pakolliset tarkistukset voivat edelleen estää yhdistämisen. Hylätty pyyntö jättää ristiriidan ratkaistavaksi riippuvuutta vaihtamalla tai erillisellä politiikkapäätöksellä.

Valvonta ulottuu myös riippuvuuden valintaan

Yleiseen saatavuuteen kuuluu rajapinta, jolla paketin sopivuutta yrityksen politiikkaan voi kysyä ennen sen lisäämistä arkistoon. Lisäksi rajapinnat mahdollistavat yrityksen lisenssipolitiikan lataamisen, päivittämisen ja korvaamisen. Politiikan muutoksista syntyy auditointilokin tapahtumia, joten sallittujen lisenssien muutoksia voidaan seurata osana yrityksen muuta hallintaa.

Dataresidenssiä käyttävässä Enterprise Cloudissa lisenssitiedot täydentävät myös riippuvuuskaaviota ja ohjelmiston osaluettelon vientiä. Pull requestin kannalta päätöspolku pysyy arkistokohtaisena: Code Security, riippuvuuskaavio, sallintalista ja kohdistettu sääntöjoukko tuovat havainnon näkyviin; Active-tila tekee ratkaisemattomasta ristiriidasta yhdistämisen esteen. Pakettia koskeva hyväksyntä vaikuttaa tämän jälkeen vain valitussa laajuudessa.

Lue myös:

• GitHub Actions vai GitLab CI? Minuutit peittävät todellisen laskun
• Jira vai Linear? Hallintatyö voi ratkaista ennen lisenssihintaa
• Microsoft 365 vai Google Workspace? Halpa lisenssi ei takaa säästöä