Avoimen lähdekoodin lisenssien noudattaminen

Tämä sivu on yleistä tietoa, ei oikeudellista neuvontaa. Kun teet päätöksiä tietystä tuotteesta, keskustele juristin kanssa.

Avoimen lähdekoodin lisenssityypit

Tyyppi	Esimerkkejä	Mitä se yleensä edellyttää
Salliva	MIT, BSD, Apache-2.0	Säilytä tekijänoikeus- ja lisenssimerkinnät. Apache-2.0:ssa on myös patenttiehtoja.
Heikko copyleft	LGPL, MPL-2.0	Jaa itse lisensoituun komponenttiin tekemäsi muutokset
Vahva copyleft	GPL-2.0, GPL-3.0	Sen kanssa jaettu ohjelmisto on tarjottava samoin ehdoin lähdekoodeineen
Verkko-copyleft	AGPL-3.0	Kuten vahva copyleft, ja se pätee myös, kun käyttäjät käyttävät ohjelmistoa verkon yli
Source-available	BUSL, SSPL	Ei avointa lähdekoodia: lähdekoodi on nähtävissä, mutta käyttöä on rajoitettu

Mikä on copyleft-lisenssi?

Copyleft-lisenssi antaa käyttää, muuttaa ja jakaa ohjelmistoa sillä ehdolla, että se, mitä jaat, pysyy samojen ehtojen alaisena. Se pitää avoimen lähdekoodin avoimena. Kaupallisen tuotteen riski on, että koodiisi linkitetty vahvan copyleftin komponentti voi nostaa esiin kysymyksen siitä, pitääkö myös oma koodisi julkaista.

Se, päteekö tämä, riippuu siitä, miten komponenttia käytetään ja miten tuote toimitetaan. Asiakkaille jaettava ohjelmisto on alttiimpi kuin sisäinen työkalu, ja SaaS-tuote välttää yleensä GPL:n jakeluehdot, mutta ei AGPL:n ehtoja.

Yleiset riskit lisenssien noudattamisessa

• Transitiiviset lisenssit. Salliva paketti voi riippua copyleft-paketista. Jos tarkistat vain suorat riippuvuudet, tämä jää huomaamatta.
• Puuttuvat merkinnät. Useimmat lisenssit edellyttävät, että tekijätiedot säilytetään, ja unohtunut merkintätiedosto on yleisin virhe.
• Muuttuneet lisenssit. Projekti voi vaihtaa lisenssiä uudessa versiossa, joten päivitys voi muuttaa ehtojasi.
• Ilmoitettu vs. todellinen. Paketin metatiedot voivat olla virheellisiä tai puutteellisia, ja vendoroidulla koodilla voi olla oma lisenssinsä.
• Due diligence. Ostajat ja suuret asiakkaat pyytävät lisenssi-inventaariota, yleensä lyhyellä varoitusajalla.

Miten pysyt ehtojen mukaisena

1. Kirjoita käytäntö. Päätä tuotetyypeittäin, mitkä lisenssit ovat sallittuja, mitkä vaativat tarkistuksen ja mitkä on kielletty.
2. Kokoa inventaario. SBOM listaa jokaisen komponentin lisensseineen, transitiiviset riippuvuudet mukaan lukien.
3. Tarkista automaattisesti. Valvo käytäntöä CI:ssä, jotta uusi riippuvuus kaatuu jo silloin, kun se lisätään, eikä vasta auditoinnissa.
4. Täytä velvoitteet. Generoi merkintätiedostot ja toimita lähdekoodi, kun lisenssi sitä edellyttää.
5. Säilytä kirjaukset. Tallenna inventaario jokaisesta julkaisusta, koska kysymys koskee yleensä versiota, jonka olet jo toimittanut.

Mitä lisenssienhallinnan ohjelmistot tekevät

Lisenssien noudattaminen on vakiintunut osa ohjelmistokoostumuksen analyysia (SCA). Työkalut tunnistavat komponentit, raportoivat niiden lisenssit ja merkitsevät käytäntösi rikkomukset. Ne eroavat syvyydeltään:

• Ilmoitetut lisenssit: useimmat työkalut lukevat, mitä kukin paketti ilmoittaa metatiedoissaan. Tämä on nopeaa ja kattaa tavallisen tapauksen.
• Syvä lisenssiskannaus: FOSSA ja Black Duck analysoivat myös koodissa olevan lisenssitekstin ja auttavat tekijätietoraporteissa ja oikeudellisessa tarkastuksessa. Katso CRACI vs. FOSSA ja CRACI vs. Black Duck.
• Ilmaiset työkalut: monet SBOM-generaattorit ja SCA-skannerit raportoivat ilmoitetut lisenssit maksutta. Katso parhaat SCA-työkalut.

Mihin CRACI sopii

CRACI käsittelee ilmoitetut lisenssit buildissa. GitHub Actions -runnerinasi se tallentaa jokaisen paketin, jonka jobi hakee, ja jokaisella on mukanaan ilmoitettu lisenssinsä, joten copyleft-lisenssit huomataan ennen kuin ne päätyvät tuotteeseen. Lisenssikäytännön säännöt voivat estää buildin lisenssin perusteella, ja CycloneDX- ja SPDX-muotoiset SBOM-viennit sisältävät kunkin komponentin ilmoitetun lisenssin. CRACI toimii sen pohjalta, mitä paketit ilmoittavat, joten jos tarvitset oikeudellisen tarkastuksen työnkulkuja tai lisenssitekstin analyysia, käytä sen rinnalla erikoistyökalua.

Avoimen lähdekoodin lisenssit: usein kysytyt kysymykset

Mitä avoimen lähdekoodin lisenssien noudattaminen tarkoittaa?

Sitä, että tiedät, mitkä avoimen lähdekoodin lisenssit koskevat käyttämääsi ohjelmistoa, ja täytät niiden ehdot, kuten merkintöjen säilyttämisen tai lähdekoodin jakamisen.

Mikä on copyleft-lisenssi?

Lisenssi, joka antaa käyttää ja muuttaa ohjelmistoa sillä ehdolla, että se, mitä jaat, pysyy samojen ehtojen alaisena. GPL on tunnetuin esimerkki.

Voiko GPL-koodia käyttää kaupallisessa ohjelmistossa?

Kyllä, mutta jos jaat ohjelmistoa, joka sisältää sitä, saatat joutua tarjoamaan kyseisen ohjelmiston lähdekoodin GPL:n ehdoin. Sillä on merkitystä, miten koodi yhdistetään, joten pyydä oikeudellista neuvontaa omaan tapaukseesi.

Koskeeko copyleft SaaS-palveluja?

GPL:n ehdot käynnistyvät yleensä jakelusta, jota SaaS yleensä välttää. AGPL sulkee tämän aukon laajentamalla ehdot käyttäjiin, jotka käyttävät ohjelmistoa verkon yli.

Mikä on turvallisin avoimen lähdekoodin lisenssi kaupalliseen käyttöön?

Sallivat lisenssit, kuten MIT, BSD ja Apache-2.0, vaativat vähiten. Niidenkin merkinnät on silti säilytettävä.

Miten riippuvuuksien lisenssit tarkistetaan?

Generoi SBOM, joka sisältää transitiiviset riippuvuudet ja ilmoitetut lisenssit, tai käytä SCA-työkalua. Valvo käytäntöäsi CI:ssä, jotta uudet rikkomukset kaatavat buildin.