Tutustu yleisiin avoimen lähdekoodin käyttöoikeuksiin

  • 8 minuuttia

Avoimen lähdekoodin lisenssejä on satoja, mutta useimmat avoimen lähdekoodin ohjelmistot käyttävät suhteellisen pientä määrää suosittuja lisenssejä. Näiden yleisten lisenssien, niiden ehtojen ja niiden vaikutusten ymmärtäminen auttaa organisaatioita tekemään tietoon perustuvia päätöksiä siitä, mitä avoimen lähdekoodin komponentteja ne voivat turvallisesti sisällyttää ohjelmistoihinsa.

Lisenssin taajuus

Avoimen lähdekoodin lisenssejä on olemassa erittäin sallivista vahvasti copyleftiin:

Näyttökuva käyttöoikeustaajuudesta.

Sallivat (attribuutio) lisenssit

Spektrin vasemmalla puolella ovat sallivat lisenssit, jotka asettavat vähimmäisrajoituksia:

  • Ominaisuudet: Salli koodin käyttö omassa ohjelmistossa ilman, että patentoitu ohjelmisto on avoimen lähdekoodin.
  • Ensisijainen vaatimus: Nimeäminen – säilytä tekijänoikeusilmoitukset ja lisenssiteksti.
  • Kaupallinen käyttö: Täysin yhteensopiva omien kaupallisten ohjelmistojen rakentamisen ja myynnin kanssa.
  • Vapaus loppupäässä: Käyttäjät voivat valita, haluavatko he avoimen lähdekoodin johdannaisteoksia.

Esimerkkejä: MIT-lisenssi, Apache-lisenssi 2.0, BSD-lisenssit.

Copyleft-lisenssit

Spektrin oikealla puolella ovat copyleft-lisenssit, joilla on vahvat vastavuoroiset vaatimukset:

  • Ominaisuudet: Vaadi johdannaisteoksia ja yhdistettyjä teoksia käyttämään samaa lisenssiä.
  • Viruksen luonne: Lisenssi "leviää" ohjelmistoon, joka sisältää lisensoidun koodin tai on yhdistetty siihen.
  • Lähdekoodin vaatimus: Binäärien jakelu edellyttää lähdekoodin asettamista saataville.
  • Vapauden säilyttäminen: Varmista, että ohjelmistot pysyvät avoimen lähdekoodin ohjelmistoina, kun ne kehittyvät ja sisällytetään muihin projekteihin.

Esimerkkejä: GNU General Public License (GPL v2 ja v3), GNU Affero General Public License (AGPL).

Heikot copyleft-lisenssit

Keskellä spektriä ovat heikot copyleft-lisenssit, jotka tasapainottavat avoimuuden ja kaupallisen kannattavuuden:

  • Ominaisuudet: Edellyttävät, että lisensoidun komponentin muutokset ovat avoimen lähdekoodin mukaisia, mutta sallivat komponentin sisällyttämisen suurempiin omiin teoksiin.
  • Kirjastoystävällinen: Suunniteltu kirjastoille, joita voidaan käyttää patentoiduissa sovelluksissa.
  • Tiedostotason tai moduulitason copyleft: Vaatimukset koskevat itse lisensoitua komponenttia, eivät koko sovellusta.
  • Käytännön tasapaino: Ota kaupallinen käyttö käyttöön ja varmista samalla, että komponentin parannukset pysyvät avoimen lähdekoodin.

Esimerkkejä: GNU Lesser General Public License (LGPL), Mozilla Public License (MPL), Eclipse Public License (EPL).

Yleiset sallivat lisenssit

MIT-lisenssi

MIT-lisenssi on yksi yksinkertaisimmista ja sallivimmista avoimen lähdekoodin lisensseistä:

Keskeiset termit:

  • Käyttöoikeudet: Käyttää, kopioida, muokata, yhdistää, julkaista, jakaa, alilisensoida ja myydä ohjelmistoa.
  • Olosuhteet: Sisällytä tekijänoikeusilmoitus ja lisenssiteksti kaikkiin kopioihin tai merkittäviin osiin.
  • Rajoitukset: Ei takuuta, ei vastuuta vahingoista.

Miksi projektit valitsevat MIT:n:

  • Enimmäiskäyttö: Vähimmäisrajoitukset kannustavat laajaan käyttöön.
  • Yksinkertainen ja selkeä: Lyhyt lisenssiteksti, joka on helppo ymmärtää.
  • Kaupallinen ystävällinen: Ei esteitä MIT:n lisensoidun koodin sisällyttämiselle omiin ohjelmistoihin.
  • Joustavuus: Käyttäjillä on täysi vapaus ohjelmiston käytössä ja jakelussa.

Suosittuja MIT-lisensoituja projekteja: React, Angular, Node.js, jQuery, Rails, .NET Core.

Vaikutukset organisaatioihin:

  • Turvallinen kaupalliseen käyttöön: Voi sisällyttää MIT-lisensoituja komponentteja omiin ohjelmistoihin ilman rajoituksia.
  • Attribuutio vaaditaan: Tekijänoikeusilmoitukset on säilytettävä – yleensä se täytetään sisällyttämällä käyttöoikeusteksti sovelluksen dokumentaatioon tai Tietoja-valintaikkunoihin.
  • Ei patentin myöntämistä: MIT-lisenssi ei nimenomaisesti käsittele patentteja, mikä luo mahdollista epäselvyyttä.

Apache-lisenssi 2.0

Apache License 2.0 on salliva lisenssi, jolla on nimenomainen patenttisuoja:

Keskeiset termit:

  • Käyttöoikeudet: Käytä, jäljennä, valmistele johdannaisteoksia, näytä, esitä, alilisensoi ja jaa.
  • Olosuhteet: Sisällytä tekijänoikeusilmoitus, lisenssiteksti ja ilmoitus muutoksista; patentti-ilmoitusten säilyttäminen; anna attribuutio.
  • Patentin myöntäminen: Patenttioikeuksien nimenomainen myöntäminen avustajilta.
  • Patentin vastatoimet: Patenttimyönteet päättyvät, jos lisenssinsaaja aloittaa patenttioikeudenkäynnin avustajia vastaan.
  • Rajoitukset: Ei takuuta, ei vastuuta, ei tavaramerkkioikeuksia.

Miksi projektit valitsevat Apache 2.0:n:

  • Patentin selkeys: Nimenomaiset patenttimyönnykset tuovat oikeusvarmuutta.
  • Muutosten läpinäkyvyys: Vaatimus muutosten dokumentoinnista edistää läpinäkyvyyttä.
  • Yritysten luottamus: Selkeät ehdot ja patenttisuojat tekevät yrityksistä mukavan osallistua.
  • Yhteensopivuus: Yhteensopiva GPL v3:n kanssa (mutta ei GPL v2:n).

Suosittuja Apache 2.0 -projekteja: Kubernetes, TensorFlow, Android, Spring Framework, Apache Hadoop, Apache Kafka.

Vaikutukset organisaatioihin:

  • Patenttisuoja: Eksplisiittinen patentin myöntäminen vähentää avustajien patenttioikeudenkäyntien riskiä.
  • Muutosilmoitus: On ilmoitettava, kun tiedostoja on muokattu.
  • Attribuutiovaatimukset: Hieman monimutkaisempi kuin MIT, joka vaatii NOTICE-tiedostojen säilyttämistä.
  • Puolustava irtisanominen: Patenttimyönnykset päättyvät, jos haastat avustajat oikeuteen patenttirikkomuksista, mikä kannustaa rauhanomaiseen rinnakkaiseloon.

BSD-lisenssit (2-lausekkeen ja 3-lausekkeen)

BSD (Berkeley Software Distribution) -lisenssit ovat MIT:n kaltaisia sallivia lisenssejä:

BSD 2 -lauseke (yksinkertaistettu BSD):

  • Käyttöoikeudet: Uudelleenjakelu ja käyttö lähde- ja binäärimuodoissa, muutoksilla tai ilman.
  • Olosuhteet: Säilytä tekijänoikeusilmoitus, ehtoluettelo ja vastuuvapauslauseke; Säilytä attribuutio binäärijakelujen dokumentaatiossa.
  • Rajoitukset: Ei takuuta, ei vastuuta.

BSD 3 -lauseke (muokattu BSD):

  • Lisäehto: Ei saa käyttää tekijänoikeuksien haltijoiden nimiä johdettujen tuotteiden tukemiseen ilman lupaa.
  • Tavaramerkin suoja: Estää alkuperäisten kirjoittajien hyväksynnän.

Suosittuja BSD-lisensoituja projekteja: FreeBSD, OpenBSD, macOS:n ja iOS:n osat.

Vaikutukset organisaatioihin:

  • Samanlainen kuin MIT: Minimaaliset rajoitukset, kaupallinen ystävällinen.
  • Nimen käyttörajoitus: 3-lausekkeen BSD estää projektien nimien käytön markkinointiin ilman lupaa.
  • Vakiintunut: Pitkä historia akateemisten ja kaupallisten ohjelmistojen parissa.

Yleiset copyleft-lisenssit

GNU General Public License (GPL) v2 ja v3

GNU General Public License on tunnetuin copyleft-lisenssi:

GPL v2:n keskeiset termit:

  • Käyttöoikeudet: Käyttää, muokata ja jakaa ohjelmistoa.
  • Olosuhteet: Lähdekoodin jakaminen binäärien avulla; johdannaisteosten on käytettävä GPL v2:ta; säilyttää tekijänoikeusilmoitukset.
  • Copyleftin laajuus: Koskee johdannaisteoksia ja yhdistettyjä teoksia, jotka linkittävät GPL-koodiin.
  • Rajoitukset: Ei takuuta, ei vastuuta.

GPL v3 -parannukset:

  • Patenttisuoja: Apache 2.0:n kaltaiset eksplisiittiset patenttimyönnykset.
  • Tivoizationin ehkäisy: Estää laitteistorajoitusten käytön, jotta käyttäjät eivät voi suorittaa muokattuja ohjelmistoja.
  • Kansainvälinen yhteensopivuus: Kansainvälisten lainkäyttöalueiden oikeudellinen selkeys paranee.
  • Apache 2.0 -yhteensopivuus: Voi yhdistää GPL v3 -koodin Apache 2.0 -koodiin.

Miksi projektit valitsevat GPL:n:

  • Vapauden varmistaminen: GPL varmistaa, että muutokset pysyvät avoimen lähdekoodin mukaisina, mikä estää patentoidut haarukat.
  • Yhteisön rakentaminen: Kannustaa jakamaan parannuksia takaisin yhteisölle.
  • Filosofinen suuntaus: On linjassa vapaiden ohjelmistojen filosofian kanssa, jonka mukaan ohjelmistojen tulisi pysyä ilmaisina.

Suosittuja GPL-lisensoituja projekteja: Linux-ydin (GPL v2), Git (GPL v2), WordPress (GPL v2), GCC (GPL v3), Bash (GPL v3).

Vaikutukset organisaatioihin:

  • Johdannaistyön vaatimukset: Jos muokkaat GPL:n koodia tai luot johdannaisteoksia, sinun on käytettävä niitä avoimen lähdekoodin GPL:ssä, kun niitä jaetaan.
  • Linkittämiseen liittyvät huolenaiheet: Oman koodin linkittäminen GPL-kirjastoihin voi laukaista copyleft-vaatimukset (tulkinta vaihtelee).
  • Kaupallinen jakelu: Voi myydä GPL:n piiriin kuuluvia ohjelmistoja, mutta heidän on annettava lähdekoodi asiakkaille.
  • SaaS-näkökohdat: GPL v2 ja v3 eivät vaadi lähdekoodin paljastamista ohjelmistolle palveluna, ellei AGPL:ää käytetä.

GNU Affero General Public License (AGPL)

AGPL laajentaa GPL v3:a verkon käyttöehdolla:

AGPL:n lisävaatimukset:

  • Verkko copyleft: Jos muokkaat AGPL-ohjelmistoa ja käyttäjät ovat vuorovaikutuksessa sen kanssa verkon (SaaS) kautta, sinun on annettava lähdekoodi näille käyttäjille.
  • ASP-porsaanreiän sulkeminen: Estää yrityksiä muokkaamasta ohjelmistoja ja tarjoamasta niitä palveluna jakamatta muutoksia.

Miksi projektit valitsevat AGPL:n:

  • SaaS-suojaus: Varmistaa, että pilvipalvelut eivät voi käyttää avoimen lähdekoodin ohjelmistoja osallistumatta takaisin.
  • Vahvempi copyleft: Maksimaalinen suoja patentoitua käyttöä vastaan.

Suosittuja AGPL-lisensoituja projekteja: MongoDB (muutettu AGPL:stä), RocketChat, Grafana.

Vaikutukset organisaatioihin:

  • Vältä SaaS: Useimmat organisaatiot välttävät AGPL-lisensoituja ohjelmistoja palvelutarjonnassa, koska ne edellyttävät avoimen lähdekoodin muutoksia.
  • Sisäinen käyttö: Voidaan käyttää sisäisesti ilman vaatimuksia, jos se ei ole alttiina käyttäjille verkon kautta.
  • Riskinarviointi: Arvioi huolellisesti, täyttääkö ohjelmisto "vuorovaikutuksen verkon kautta".

Yleiset heikot copyleft-lisenssit

GNU Lesser General Public License (LGPL)

LGPL sallii linkittämisen kirjastoihin ilman täydellisiä GPL-vaatimuksia:

Keskeiset termit:

  • Kirjaston käyttö: Voi linkittää LGPL:n kirjastoihin omista ohjelmistoista ilman avointa lähdekoodia omalle sovellukselle.
  • Kirjaston muutokset: Itse LGPL:n kirjastoon tehtyjen muutosten on oltava avoimen lähdekoodin mukaisia.
  • Dynaaminen linkitys: LGPL sallii nimenomaisesti dynaamisen linkityksen omaan koodiin.
  • Johdannaisteokset: Täydelliset sovellukset eivät ole johdannaisteoksia vain siksi, että ne käyttävät LGPL:n kirjastoja.

Miksi projektit valitsevat LGPL:n:

  • Kirjaston käyttöönotto: Kannustaa käyttämään patentoiduissa ohjelmistoissa ja suojaa samalla itse kirjastoa.
  • Kompromissikanta: Tasapainottaa avoimuuden ja kaupallisen kannattavuuden.
  • Kirjaston vakiosoveltuvuus: Sopii kirjastoihin, jotka on tarkoitettu vakiokomponenteiksi.

Suosittuja LGPL-lisensoituja projekteja: Qt (kaksoislisensoitu kaupallisella vaihtoehdolla), GTK, GStreamer, monet C-kirjastot.

Vaikutukset organisaatioihin:

  • Voidaan käyttää patentoiduissa sovelluksissa: Turvallinen käyttää LGPL-kirjastoja kaupallisissa sovelluksissa.
  • On annettava kirjaston lähde: Jos muokkaat LGPL-kirjastoa, anna lähdekoodi muokkauksia varten.
  • Staattisen linkityksen monimutkaisuus: Staattinen linkitys saattaa laukaista tiukempia vaatimuksia; Dynaaminen linkitys on turvallisempaa.

Mozillan julkinen lisenssi (MPL) 2.0

MPL 2.0 tarjoaa tiedostotason copyleftin:

Keskeiset termit:

  • Tiedostotason copyleft: Vaatimukset koskevat vain tiedostoja, jotka olivat alun perin MPL:n alaisuudessa.
  • Suurempi työpoikkeus: Voi yhdistää MPL-tiedostoja omiin tiedostoihin samassa sovelluksessa.
  • Lähdekoodin paljastaminen: On annettava lähdekoodi MPL-tiedostoille.
  • Patentin myöntäminen: Sisältää nimenomaisen patentin myöntämisen ja puolustavan irtisanomisen.
  • GPL-yhteensopivuus: MPL 2.0 on yhteensopiva GPL:n kanssa.

Miksi projektit valitsevat MPL 2.0:n:

  • Vaaka: Vahvempi kuin sallivat lisenssit, joustavampi kuin GPL.
  • Kaupallinen käyttö: Mahdollistaa kaupallisen käytön ja suojaa avoimen lähdekoodin komponenttia.
  • Tiedostojen seuranta: Tiedostotason copyleft helpottaa vaatimustenmukaisuuden seurantaa.

Suosittuja MPL-lisensoituja projekteja: Firefox, Thunderbird, LibreOffice.

Vaikutukset organisaatioihin:

  • Voidaan sekoittaa oman koodin kanssa: Helpompi integrointi GPL:ää patentoituihin ohjelmistoihin.
  • Tiedostotason seuranta: On säilytettävä selkeät rajat MPL-tiedostojen ja omistusoikeudellisten tiedostojen välillä.
  • Jaetut muutokset: MPL-tiedostoihin tehdyt muutokset on jaettava, mutta erillisiin tiedostoihin tehdyt lisäykset eivät.

Lisenssien yhteensopivuus

Eri lisensseillä on erilaiset yhteensopivuussäännöt:

Yhteensopivat yhdistelmät

  • MIT + Apache 2.0: Yhteensopiva – voidaan yhdistää samaan projektiin.
  • MIT + GPL v3: Yhteensopiva – voi sisällyttää MIT-lisensoitua koodia GPL v3 -projekteihin.
  • Apache 2.0 + GPL v3: Yhteensopiva – GPL v3 voi sisältää Apache 2.0 -koodin.
  • LGPL + GPL: Yhteensopiva – voi päivittää LGPL:n GPL:ksi.

Yhteensopimattomat yhdistelmät

  • GPL v2 + Apache 2.0: Yhteensopimaton – ei voi yhdistää samassa työssä.
  • GPL + patentoitu: Yhteensopimaton – GPL edellyttää, että johdannaisteokset ovat GPL:ää.
  • Erilaiset copyleft-lisenssit: Yleensä yhteensopimaton – ei yleensä voi yhdistää GPL-, AGPL- ja LGPL-koodia eri copyleft-lisensseihin tavoilla, jotka täyttävät molemmat.

Yhteensopivuusongelmat

Kun valitset riippuvuuksia:

  • Lisenssien inventaario: Tunne kaikkien riippuvuuksien käyttöoikeudet.
  • Yhteensopivuuden tarkistus: Varmista, että eri komponenttien lisenssit ovat yhteensopivia.
  • Oikeudellinen tarkastelu: Monimutkaiset tapaukset edellyttävät oikeudellista asiantuntemusta yhteensopivuuden arvioimiseksi.

Kaksoislisensointistrategiat

Joissakin projekteissa on useita lisensointivaihtoehtoja:

Avoimen lähdekoodin + kaupallinen

  • Strategia: Tarjous GPL:llä (copyleft) tai kaupallisella lisenssillä.
  • Perustelut: Yritykset, jotka haluavat sisällyttää omiin ohjelmistoihin, ostavat kaupallisen lisenssin; avoimen lähdekoodin yhteisö käyttää GPL-versiota.
  • Esimerkkejä: Qt, MySQL, MongoDB (muuttunut lähestymistapa).

Useita avoimen lähdekoodin lisenssejä

  • Strategia: Salli käyttäjien valita useista yhteensopivista käyttöoikeuksista.
  • Perustelut: Maksimoi yhteensopivuus eri projektien kanssa.
  • Esimerkkejä: Jotkut kirjastot tarjoavat Apache 2.0- tai MIT-lisensointivaihtoehtoja.

Yleisten avoimen lähdekoodin lisenssien, niiden ehtojen ja yhteensopivuuden ymmärtäminen auttaa organisaatioita tekemään tietoon perustuvia päätöksiä siitä, mitä avoimen lähdekoodin komponentteja käytetään ja miten ohjelmistot rakennetaan lisenssien noudattamisen ylläpitämiseksi. Seuraavassa luvussa tarkastellaan lisenssivaikutuksia ja luokituksia, jotka auttavat arvioimaan riskejä ja tekemään päätöksiä.