GitHub-koodi kaupallisessa tuotteessa: lisenssit ja tarkistettavat asiat
MarkdownSallivat lisenssit MIT, Apache ja BSD, copyleft-lisenssit GPL/AGPL, LICENSE-tiedoston puuttuminen ja tekoälyn lisäämän koodin alkuperän tarkistaminen.
Lue koko artikkeli
Rakennat tuotetta ja löydät GitHubista valmiin osan: kirjaston, mallipohjan tai kokonaisen projektin, joka tekee juuri sen, mitä tarvitset. Claude ehdottaa sen lisäämistä projektiisi. Sitten pysähdyt: koodi näyttää olevan julkisesti saatavilla, mutta saatko todella käyttää sitä, saati myydä sitä sisältävää tuotetta? Voiko tekijä vaatia sinut myöhemmin vastuuseen?
Käyn asiat läpi järjestyksessä: miksi GitHubissa oleva avoin koodi ei itsessään anna lupaa, mitkä lisenssit sallivat koodin käytön ja tuotteen myymisen, mitkä copyleft-ehdot voivat vaatia vastaavan lähdekoodin lisenssin kattamasta teoksesta ja miten lisenssin voi tarkistaa minuutissa ennen koodin käyttöä. Ei mitään ”riippuu tilanteesta” -vastauksia.
Käytännön tietoa Ailootin käytöstä on dokumentaatiossa.
Huomio
Tämä materiaali on tarkoitettu taustatiedoksi; en ole lakimies. Kuvailen alla suosittujen lisenssien ja sääntöjen ehtoja ja linkitän alkuperäislähteisiin, mutta tarkista oma tilanteesi lisenssitekstistä ja suuren kaupallisen tuotteen tapauksessa myös lakimiehen kanssa. Päätät itse.
Pitääkö paikkansa, että GitHubissa olevaa koodia saa käyttää ilmaiseksi?
Pääasia
Ei. Se, että koodi on nähtävissä, ei tarkoita, että saat käyttää sitä omassa työssäsi. Tekijänoikeus suojaa oletusarvoisesti kaikkea koodia, etkä saa käyttää sitä, ellei tekijä ole erikseen antanut siihen lupaa. Koodin julkaiseminen GitHubissa antaa muille itsessään vain mahdollisuuden katsella repositoriota ja tehdä siitä kopion GitHubin sisällä. Oikeus sisällyttää koodi tuotteeseesi perustuu lisenssiin, jonka tekijä on liittänyt repositorioon. GitHub ei anna tätä oikeutta.
Suurin ansa on sana ”avoin”. Näet lähdekoodin, joten vaikuttaa siltä, että saat käyttää sitä, koska sitä ei ole piilotettu. Tämä logiikka on väärä. ”Avoin luettavaksi” ja ”lisensoitu käytettäväksi” tarkoittavat eri asioita.
Tekijänoikeus suojaa oletusarvoisesti kaikkia luovia teoksia, myös koodia, heti niiden luomisesta alkaen. Et saa käyttää teosta, ennen kuin tekijä on nimenomaisesti antanut siihen luvan. Näin GitHub kuvailee asiaa omalla lisenssien viitesivullaan.
Kun luot luovan teoksen (myös koodi on luova teos), tekijänoikeus suojaa sitä oletusarvoisesti yksinoikeudella. Jos et liitä mukaan toisin määräävää lisenssiä, kukaan muu ei saa kopioida, levittää tai muokata teostasi ilman, että hän ottaa riskin vaatimuksesta tai oikeusjutusta.
Toinen taso on itse GitHub. Ihmiset luulevat, että koska he hyväksyivät GitHubin säännöt julkaistessaan koodia, he saavat myös käyttää muiden koodia siellä. Säännöissä sanotaan täsmälleen päinvastaista. Kun tekijä tekee repositoriosta julkisen, hän antaa muille luvan vain katsella ja forkata sitä eli tehdä kopion GitHubin sisällä. Se ei anna lupaa käyttää koodia omassa työssäsi.
Tekemällä repositoriosta julkisen annat muille käyttäjille ei-yksinomaisen, maailmanlaajuisen lisenssin käyttää, näyttää ja jäljentää (forkkaamalla) aineistoasi palvelun kautta ja GitHubin ominaisuuksien puitteissa. Voit myöntää lisäoikeuksia liittämällä mukaan lisenssin.
Avainsanat ovat viimeisessä virkkeessä: ”GitHubin ominaisuuksien puitteissa” ja ”lisäoikeudet myönnetään lisenssillä”. Fork pysyy GitHubin sisällä. Heti kun haluat käyttää koodia omassa tuotteessasi, saati myydä tuotetta, tarvitset tekijältä erillisen lisenssin. Ei lisenssiä, ei oikeutta – vaikka koodi olisi aivan kaikkien nähtävillä.
Mikä ratkaisee, saatko käyttää jonkun toisen koodia?
Pääasia
Ratkaiseva tekijä on repositorion lisenssitiedosto, jonka nimi on yleensä LICENSE tai LICENSE.md. Se on tekijän antama lupa, joka määrittää, mitä saat ja et saa tehdä koodilla. Lisenssi vastaa kolmeen kysymykseen: saatko käyttää koodia kaupallisessa tuotteessa, saatko muokata sitä ja saatko pitää oman lähdekoodisi suljettuna? Eri lisenssit vastaavat näihin eri tavoin, joten tarkista ensin tämä tiedosto ja avaa vasta sitten itse koodi.
Kaikki riippuu yhdestä tiedostosta. Hyvin ylläpidetyssä repositoriossa on lisenssitiedosto – yleensä LICENSE, joskus LICENSE.md tai maininta suoraan README-tiedostossa. Se on tekijän lupa, joka kertoo, millä ehdoilla saat käyttää koodia. GitHub näyttää lisenssin nimen yleensä repositoriosivun sivupalkissa jo ennen kuin avaat itse tiedoston.
Jotta et eksyisi lakikieleen, lisenssiä kannattaa tarkastella oman tilanteesi kannalta kolmen kysymyksen kautta:
- Saatko käyttää tätä koodia kaupallisessa tuotteessa, josta ihmiset maksavat?
- Saatko muokata koodia tarpeidesi mukaan?
- Onko sinun myöhemmin avattava tuotteesi lähdekoodi, vai saatko pitää sen suljettuna?
Lähes kaikki lisenssien väliset erot kiteytyvät kolmanteen kysymykseen annettaviin erilaisiin vastauksiin. Kahden ensimmäisen kohdalla suositut avoimet lisenssit vastaavat useimmiten ”kyllä”: käytä, muokkaa, myy. Ongelmia syntyy siitä, vaatiiko lisenssi avaamaan oman koodisi. Seuraavaksi käymme tärkeimmät lisenssityypit läpi näiden kolmen kysymyksen avulla.
Millä lisensseillä koodia saa käyttää ja tuotteen myydä?
Pääasia
Kaupalliseen tuotteeseen sopivimpia ovat sallivat lisenssit: MIT, Apache 2.0 ja BSD. Ne sallivat lähes kaiken: koodin käytön ja muokkaamisen, tuotteen myymisen sekä oman lähdekoodin pitämisen suljettuna. Velvollisuutena on säilyttää lisenssiteksti ja tekijätiedot. Apache 2.0 suojaa lisäksi patenttivaatimuksilta ja edellyttää muutettujen tiedostojen merkitsemistä. Jos jonkun toisen koodilla on jokin näistä lisensseistä, voit käyttää sitä turvallisesti kaupallisessa tuotteessa.
Aloitetaan hyvistä uutisista. Tuotetta myyntiin rakentavalle paras vaihtoehto on joukko lisenssejä, joita kutsutaan salliviksi lisensseiksi. Niitä on useita, mutta kolme ovat yleisimpiä: MIT, Apache 2.0 ja BSD. Kaikki kolme vastaavat kahteen ensimmäiseen kysymykseen ”kyllä” ja antavat sinun pitää oman lähdekoodisi suljettuna.
Yleisin ja yksinkertaisin on MIT. Sen teksti mahtuu yhteen kappaleeseen.
Täten myönnetään maksutta kaikille, jotka saavat kopion tästä ohjelmistosta, oikeus käyttää sitä rajoituksetta, mukaan lukien oikeus käyttää, kopioida, muokata, yhdistää, julkaista, levittää, alilisensoida ja myydä kopioita, edellyttäen että yllä oleva tekijänoikeusilmoitus ja tämä lupailmoitus sisällytetään kaikkiin kopioihin.
Yksinkertaisemmin sanottuna MIT antaa sinun tehdä koodilla lähes mitä tahansa, myös myydä tuotteen ja pitää oman lähdekoodisi suljettuna. Ainoa velvollisuus on sisällyttää lisenssiteksti ja tekijätietoja koskeva rivi. Esimerkiksi Babel, .NET ja Rails on julkaistu MIT-lisenssillä, joten olet lähes varmasti jo käyttänyt tällä lisenssillä julkaistua koodia.
Apache 2.0 toimii samalla tavoin, mutta siihen sisältyy kaksi tärkeää lisäystä. Ensinnäkin se suojaa nimenomaisesti patenttivaatimuksilta: koodin tekijät lupaavat, etteivät he haasta sinua oikeuteen tähän koodiin liittyvien patenttien perusteella. Toiseksi käyttöön liittyy muutama lisämuodollisuus.
Saat jäljentää ja levittää teoksesta tai siitä johdetuista teoksista kopioita missä tahansa muodossa, muutoksin tai ilman, edellyttäen että annat vastaanottajille kopion tästä lisenssistä, merkitset muutetut tiedostot, säilytät tekijänoikeus- ja patentti-ilmoitukset sekä sisällytät luettavan kopion NOTICE-tiedostosta, jos sellainen on olemassa.
BSD (2- ja 3-lausekkeen versiot) muistuttaa olennaisesti MIT-lisenssiä: käytä, muokkaa ja myy koodia sekä säilytä tekijänoikeusilmoitus. Olen koonnut kaikki kolme taulukkoon, jotta näet erot yhdellä silmäyksellä.
| Lisenssi | Tuotteen myyminen | Lähdekoodin pitäminen suljettuna | Mitä sinun on tehtävä | Patenttisuoja |
|---|---|---|---|---|
| MIT | kyllä | kyllä | säilytä tekijänoikeusilmoitus ja lisenssiteksti | ei ehtoa |
| Apache 2.0 | kyllä | kyllä | tekijänoikeusilmoitus, NOTICE-tiedosto, muutosten merkitseminen | kyllä |
| BSD (2 ja 3 lauseketta) | kyllä | kyllä | säilytä tekijänoikeusilmoitus | ei |
Näin voit tulkita tätä omassa tilanteessasi: jos jonkun toisen koodilla on MIT-, Apache 2.0- tai BSD-lisenssi, voit olla huoletta: saat käyttää sitä kaupallisessa tuotteessa, muokata sitä ja pitää oman lähdekoodisi suljettuna. Muista vain olla poistamatta ottamastasi osasta lisenssitiedostoa ja tekijätietoja.
Miten GPL:n ja AGPL:n lähdekoodivelvoitteet soveltuvat?
Tärkein asia
GPL ja AGPL sallivat kaupallisen käytön. GPL:n lähdekoodivelvoitteet syntyvät lisenssin kattaman teoksen luovutuksesta; tavallinen palvelinkäyttö ilman kopion siirtämistä ei ole tämä laukaisin. AGPLv3 lisää velvoitteen tarjota lähdekoodi käyttäjille, jotka ovat etäyhteydessä muokattuun versioon. Selvitä, mikä yhdistelmäteos kuuluu lisenssin piiriin: erilliset itsenäiset osat eivät automaattisesti kaikki kuulu siihen.
Copyleft pitää kattamansa teoksen ja sen johdannaiset saman lisenssin alaisina asiaankuuluvien ehtojen täyttyessä. GPLv3:n kattaman tai yhdistetyn johdannaisteoksen lähde- tai objektikoodikopioiden jakelu edellyttää lisenssin ja vastaavaa lähdekoodia koskevien velvoitteiden noudattamista. Se ei automaattisesti koske jokaista saman tuotteen tai palvelimen itsenäistä ohjelmaa.
Verkkopalveluesimerkissä GPL-kirjaston ylläpitäminen omalla palvelimella antamatta käyttäjille kopioita ei itsessään vaadi koko palvelun julkaisemista. Lisenssin kattaman yhdistetyn sovelluksen jakelu asiakkaille voi laukaista GPL-velvoitteet. Tarkista koodin yhdistäminen ja lisenssi ennen päätöstä mukana toimitettavasta lähdekoodista. Käyttäjille toimitettava selainasiakas on erillinen jakelukysymys.
AGPLv3 lisää verkkoehdon: jos muokkaat ohjelmaa ja käyttäjät ovat etäyhteydessä tähän versioon, sen on tarjottava heille näkyvästi vastaava lähdekoodinsa. Tämä on täsmällisempää kuin väite, että minkä tahansa AGPL-osan hosting avaisi palvelun kaikki itsenäiset osat.
Suljetussa tuotteessa tutki lisenssin kattama teos, osien yhdistäminen, kopioiden jakelu ja mahdollinen AGPL:n verkkovuorovaikutus. Valitse yhteensopiva salliva vaihtoehto tai hanki erillinen lupa, jos et pysty täyttämään velvoitteita. Kaupallinen käyttö itsessään on sallittua; kyse on todellisen lisenssin ja yhdistämistavan ehtojen noudattamisesta.
Mitä tehdä, jos repositoriossa ei ole lainkaan lisenssitiedostoa?
Pääasia
Jos lisenssitiedostoa ei ole, et saa käyttää koodia. Tämä ei tarkoita, että ”se on ilmaista”: päinvastoin, ilman lisenssiä tekijänoikeus kuuluu kokonaisuudessaan tekijälle, eikä sinulla ole oikeutta käyttää, kopioida tai muokata koodia. Lupa katsella ja forkata koodia GitHubissa ei auta tässä – se ei anna oikeutta sisällyttää koodia tuotteeseesi. Jos todella tarvitset koodia, ainoa selkeä ratkaisu on kirjoittaa tekijälle ja pyytää lupaa tai odottaa, että hän lisää lisenssin.
Yleinen virhe on olettaa, ettei rajoituksia ole ja että koodia saa käyttää vapaasti, jos lisenssi puuttuu. Asia on päinvastoin. Lisenssin puuttuminen ei ole lupa; oletusarvoisesti se tarkoittaa, ettei lupaa ole. Lisensoimaton koodi kuuluu kokonaan tekijänoikeuden haltijalle, etkä saa koskea siihen.
Alussa esittelemämme sääntö pätee jälleen: tekijänoikeus suojaa koodia oletusarvoisesti, etkä ilman nimenomaista lupaa saa kopioida, muokata tai levittää sitä. Mahdollisuus katsella ja forkata koodia GitHubissa ei poista tätä estettä – se ei anna sinulle oikeutta käyttää koodia omassa tuotteessasi.
Mitä voit tehdä käytännössä, jos koodilla ei ole lisenssiä mutta tarvitset sitä todella:
- Kirjoita tekijälle. Kysy suoraan repositorion keskusteluosiossa tai sähköpostitse, saatko käyttää koodia ja millä ehdoilla. Joskus tekijä on vain unohtanut lisätä lisenssin ja tekee sen pyynnöstä.
- Etsi korvaava vaihtoehto. Lähes mihin tahansa tehtävään löytyy toinen, kolmas ja kymmenes vastaava repository – niiden joukosta löydät sellaisen, jolla on asianmukainen MIT- tai Apache-lisenssi.
- Älä käytä koodia. Jos sinulla ei ole lupaa eikä vaihtoehtoa löydy, koodi ei ole sinun, etkä saa sisällyttää sitä tuotteeseen, jonka aiot myydä. Ajatus ”kuka tästä saa tietää?” johtaa huonoon lopputulokseen juuri silloin, kun tuote alkaa tuottaa rahaa ja herättää huomiota.
Entä jos Claude itse lisäsi jonkun toisen koodia projektiin?
Pääasia
Tämä on erillinen tapaus, eikä sitä pidä sekoittaa repositorion suoraan kopioimiseen. Kun otat itse koodia tietystä repositoriosta, sinun on noudatettava sen lisenssiä. Kun Claude tai toinen tekoäly tuottaa koodia pyyntösi perusteella, se yleensä luo tehtävää varten omaa tekstiään eikä kopioi jonkun toisen tiedostoa. Tällöin kysymys siirtyy tuotetun koodin oikeuksiin. Jos tekoäly kuitenkin selvästi jäljentää tunnistettavan osan jonkun toisen lisensoidusta koodista, lisenssin ehdot pätevät yhä. Lähde kannattaa tarkistaa molemmissa tapauksissa.
Tässä on toinen taso, joka on helppo sekoittaa ensimmäiseen. On eri asia käydä repositoriossa ja kopioida sieltä tiedosto: silloin kaikki yllä lisenssistä kerrottu koskee sinua suoraan. Toista on se, että Claude kirjoittaa sinulle koodia pyyntösi perusteella.
Tavallisissa tapauksissa tekoäly tuottaa omaa tekstiään, joka on koottu tehtävääsi varten, eikä kopioi jonkun toisen tiedostoa. Silloin kysymys siirtyy toiseen aiheeseen: kuka omistaa tuotetun koodin, ja saatko myydä sen? Se on laaja aihe itsessään, ja käsittelin sitä artikkelissa kuka omistaa tekoälyn kirjoittaman koodin.
On kuitenkin yksi poikkeus, joka kannattaa muistaa. Joskus tekoäly tuottaa lähes sanasta sanaan tunnistettavan osan jonkun toisen koodista, esimerkiksi kokonaisen funktion tunnetusta kirjastosta. Tällöin kirjaston lisenssi pätee edelleen riippumatta siitä, kuka fyysisesti painoi näppäimiä. Siksi suuret valmiit koodilohkot, jotka Claude on tuonut mukaan sellaisinaan, pitää tarkistaa samalla tavalla kuin itse kopioimasi koodi.
Näin tarkistat lisenssin ennen koodin käyttämistä: ohjeet
Pääasia
Toimi näin: avaa repository-sivu ja tarkista lisenssin nimi sivupalkista, avaa itse LICENSE-tiedosto, tunnista lisenssityyppi – salliva (MIT, Apache, BSD) tai copyleft (GPL, AGPL) – vertaa sitä omaan tilanteeseesi ja päätä, käytätkö koodia vai etsitkö vaihtoehdon. Jos lisenssiä ei ole, älä käytä koodia. Koko tarkistukseen menee pari minuuttia, ja se pitää tehdä ennen kuin koodi tulee osaksi projektiasi, ei jälkikäteen.
Kootaan tähän lyhyt tarkistuslista, jonka avulla voit tarkistaa kaiken kolmannen osapuolen koodin ennen sen lisäämistä projektiisi. Etene kohta kohdalta ylhäältä alas.
Etsi lisenssin nimi repository-sivulta
Avaa repository GitHubissa. Lisenssin nimi näkyy yleensä oikeassa sarakkeessa tai tiedostoluettelon alla – esimerkiksi ”MIT License”, ”Apache-2.0” tai ”GPL-3.0”. Jos kohta on tyhjä eikä lisenssitiedostoa ole, se on jo varoitusmerkki; palaa asiaan viimeisessä vaiheessa.
Avaa itse lisenssitiedosto
Etsi tiedostoluettelosta LICENSE, LICENSE.md tai COPYING ja avaa se. Varmista, että nimi vastaa sivupalkissa näkyvää ja että lisenssi koskee käyttämääsi koodia eikä vain erillistä osaa repositoriosta.
Tunnista lisenssityyppi: salliva vai copyleft
MIT, Apache 2.0 ja BSD ovat sallivia: koodia saa käyttää suljetussa kaupallisessa tuotteessa. GPL ja AGPL ovat copyleft-lisenssejä. Tarkista kattama teos, jakelu ja mahdollinen AGPL:n verkkoehto ennen lähdekoodivelvoitteiden määrittämistä. Pelkkä nimi ei ratkaise, mitkä itsenäiset osat kuuluvat piiriin.
Vertaa lisenssiä omaan tilanteeseesi
Vastaa kolmeen kysymykseen: myytkö tuotetta, muokkaatko koodia ja haluatko pitää lähdekoodin suljettuna? MIT, Apache ja BSD sopivat suljettuun myytävään tuotteeseen. Selvitä GPL:n ja AGPL:n kohdalla, mikä lisenssin kattama tai yhdistetty teos vaatisi vastaavan lähdekoodin ja milloin velvoite syntyy, ja arvioi pystytkö täyttämään ehdot.
Jos lisenssiä ei ole, älä käytä koodia
Jos lisenssitiedostoa ei ole eikä README kerro luvasta, et saa käyttää koodia. Kirjoita tekijälle ja pyydä lupa tai etsi vastaava koodi asianmukaisella lisenssillä. ”Se on julkisesti saatavilla” ei tarkoita, että sen käyttöön olisi lupa.
Tarkistus tuntuu vaivalloiselta siihen asti, kunnes tuotteesi kasvaa, alkaa tuottaa rahaa ja joku kysyy, mitä kolmannen osapuolen koodia se sisältää. Kahden minuutin tarkistus alussa maksaa vähemmän kuin myöhemmän kiistan selvittäminen. Kerron erikseen, mitä tuotteellasi kannattaa tehdä seuraavaksi, jotta se ei pysähdy julkaisun jälkeen: Rakensin tuotteen tekoälyn avulla – mitä seuraavaksi.
Usein kysytyt kysymykset
Saako myydä tuotteen, joka sisältää jonkun toisen GitHubista peräisin olevaa koodia?
Kyllä, jos koodilla on salliva lisenssi – MIT, Apache 2.0 tai BSD. Ne sallivat koodin käytön kaupallisessa tuotteessa, sen myymisen ja oman lähdekoodin pitämisen suljettuna. Sinun tarvitsee vain säilyttää lisenssiteksti ja tekijätiedot. Myös GPL ja AGPL sallivat kaupallisen käytön, mutta lähdekoodivelvoitteet riippuvat katetusta teoksesta sekä jakelusta tai soveltuvasta AGPL:n verkkoehdosta. Jos lisenssitiedostoa ei ole, et saa käyttää koodia lainkaan.
Mitä tarkoittaa, jos GitHub-repositoriossa ei ole lisenssiä?
Se tarkoittaa, ettet saa käyttää koodia. Lisenssin puuttuminen tarkoittaa oletusarvoisesti, ettei lupaa ole; se ei tarkoita ”ilmaista”. Koodi on edelleen täysin tekijänoikeuden haltijan suojaama. Mahdollisuus katsella ja forkata repositoriota GitHubissa ei anna oikeutta käyttää koodia tuotteessasi. Jos tarvitset koodia, kirjoita tekijälle ja pyydä lupa tai etsi vastaava koodi avoimella lisenssillä.
Miten MIT eroaa GPL:stä tuotteeni kannalta?
MIT antaa sinun käyttää ja muokata koodia, myydä tuotteen ja pitää oman lähdekoodisi suljettuna – ainoa velvollisuus on lisenssitekstin säilyttäminen. GPL sallii myös kaupallisen käytön, mutta katetun yhdistetyn tai johdannaisteoksen luovutus edellyttää vastaavan lähdekoodin ja saman lisenssin velvoitteiden noudattamista. Pelkkä hosting ilman kopion siirtämistä on eri asia, eivätkä erilliset itsenäiset osat automaattisesti kuulu piiriin.
Pitääkö minun tehdä jotakin, jos käytän MIT-lisensoitua koodia?
Kyllä, yksi pieni asia: säilytä projektissasi käyttämästäsi koodista MIT-lisenssiteksti ja tekijätietoja koskeva rivi. Yleensä se on sama LICENSE-tiedosto, joka sisältyy alkuperäiseen koodiin. MIT ei edellytä muuta – saat muokata koodia, myydä tuotteen ja pitää lähdekoodisi suljettuna.
Entä jos Claude itse lisäsi jonkun toisen koodia eikä minulla ollut siihen osuutta?
Lähde kannattaa silti tarkistaa. Tekoäly tuottaa tavallisesti omaa tekstiä tehtävääsi varten, jolloin kysymys siirtyy tuotetun koodin oikeuksiin – se on erillinen aihe. Jos tekoäly kuitenkin jäljensi lähes sanasta sanaan tunnistettavan osan jonkun toisen tunnetusta kirjastosta, kirjaston lisenssi pätee edelleen. Tarkista suuret valmiit koodilohkot, jotka on tuotu mukaan sellaisinaan, samalla tavalla kuin itse kopioimasi ja liittämäsi koodi.
Lähteet
- choosealicense.com - GitHubin viiteprojekti lisenssin valintaan
- choosealicense.com - mitä lisenssin puuttuminen tarkoittaa
- GitHubin käyttöehdot, kohta D (lisenssin myöntäminen muille käyttäjille)
- MIT-lisenssi (opensource.org)
- Apache License 2.0 (apache.org)
- GNU General Public License v3.0 (gnu.org)
- GNU Affero General Public License v3.0 (gnu.org)
Lisätietoja
Kysymyksiä tästä oppaasta: GitHub-koodi kaupallisessa tuotteessa: lisenssit ja tarkistettavat asiat
Pakottaako GPL-kirjaston hosting julkaisemaan koko verkkopalveluni?
Pelkkä hosting ilman kopioiden siirtämistä ei laukaise GPL:n jakeluvelvoitetta. Jos jaat lisenssin kattamaa yhdistettyä tai johdannaissovellusta, lähdekoodivelvoitteet voivat koskea sitä. Itsenäiset osat eivät automaattisesti kuulu piiriin.
Minkä lisäehdon AGPLv3 tuo verkkopalveluun?
Muokatun AGPL-ohjelman, joka tukee etävuorovaikutusta verkon kautta, on tarjottava vastaava lähdekoodi näille käyttäjille. Tarkista katettu ohjelma ja yhdistämistapa sen sijaan, että olettaisit lähdekoodia tarpeettomaksi tai kaikkien itsenäisten palvelujen avaamista pakolliseksi.