# GitHub-kode i et kommersielt produkt: lisenser og hva du bør sjekke
> Tillatende MIT-, Apache- og BSD-lisenser, copyleft-lisensene GPL/AGPL, fraværet av en LICENSE-fil og kontroll av hvor kode lagt til av AI kommer fra.
Source: https://ailoot.ai/blog/nb/github-code-commercial-licenses/
Canonical: https://ailoot.ai/blog/nb/github-code-commercial-licenses/
Language: nb
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-177
Revision: sha256-f752f76e60a5afe5d1800696839da25ac44baf6e01fbd5215cf3cf5756fc0174
Du bygger et produkt og finner noe ferdig på GitHub: et bibliotek, en mal eller et helt prosjekt som gjør akkurat det du trenger. Claude foreslår å legge det til i prosjektet ditt. Så stopper du opp: Koden ser ut til å være offentlig tilgjengelig, men kan du faktisk bruke den, for ikke å snakke om å selge et produkt som inneholder den? Kan forfatteren komme etter deg senere?
Jeg går gjennom dette i rekkefølge: hvorfor åpen kode på GitHub ikke i seg selv gir tillatelse, hvilke lisenser som lar deg bruke kode og selge et produkt, hvilke copyleft-vilkår som kan kreve tilhørende kildekode for et dekket verk, og hvordan du kan sjekke en lisens på ett minutt før du bruker koden. Ingen «det kommer an på situasjonen».
[Praktisk informasjon om å jobbe med Ailoot finner du i dokumentasjonen](https://ailoot.ai/docs/).
Viktig
Dette materialet er til informasjon; jeg er ikke advokat. Nedenfor beskriver jeg vilkårene for populære lisenser og regler, med lenker til primærkilder, men sjekk din konkrete situasjon opp mot lisensteksten og, hvis produktet er stort og kommersielt, med en advokat. Du tar avgjørelsen selv.
## Stemmer det at du kan bruke kode gratis hvis den ligger på GitHub?
Hovedpoeng
Nei. At koden er tilgjengelig for visning, betyr ikke at du har lov til å bruke den i ditt eget arbeid. Som standard er all kode beskyttet av opphavsrett, og du kan ikke bruke den med mindre forfatteren har gitt særskilt tillatelse. Publisering på GitHub gir i seg selv bare andre mulighet til å se repositoriet og lage en kopi innenfor GitHub. Retten til å legge koden inn i produktet ditt kommer fra lisensen forfatteren har knyttet til repositoriet. GitHub gir ikke denne retten.
Den største fellen her er ordet «åpen». Du kan se kildekoden, så det virker som om du har lov til å bruke den fordi den ikke er skjult. Den logikken er feil. «Åpen for lesing» og «lisensiert for bruk» er to forskjellige ting.
Som standard er ethvert kreativt verk, også kode, beskyttet av opphavsrett fra det øyeblikket det blir skapt. Du kan ikke bruke det før forfatteren uttrykkelig gir tillatelse. Slik beskriver GitHub det på sin egen side med lisensinformasjon.
Når du skaper et kreativt verk (og kode er også et kreativt verk), er det som standard beskyttet av eksklusiv opphavsrett. Med mindre du legger ved en lisens som sier noe annet, kan ingen andre kopiere, distribuere eller endre verket ditt uten å risikere et krav eller søksmål.
— choosealicense.com (GitHubs referanseprosjekt), https://choosealicense.com/no-permission/
Det andre laget er GitHub selv. Folk tror at de, fordi de godtok GitHubs regler da de publiserte kode, også kan bruke andres kode derfra. Reglene sier det motsatte. Når forfatteren gjør et repositorium offentlig, gir vedkommende andre bare lov til å se og forke det – altså lage en kopi innenfor GitHub. Det gir ikke tillatelse til å bruke koden i eget arbeid.
Når du gjør et repositorium offentlig, gir du andre brukere en ikke-eksklusiv, verdensomspennende lisens til å bruke, vise og reprodusere (ved å forke) materialet ditt gjennom tjenesten, innenfor GitHubs funksjoner. Du kan gi ytterligere rettigheter ved å legge ved en lisens.
— GitHubs tjenestevilkår, del D, https://docs.github.com/en/site-policy/github-terms/github-terms-of-service
Nøkkelordene står i den siste setningen: «innenfor GitHubs funksjoner» og «ytterligere rettigheter følger av en lisens». En fork forblir innenfor GitHub. Så snart du vil bruke koden i ditt eget produkt, for ikke å snakke om å selge det, trenger du en egen lisens fra forfatteren. Ingen lisens, ingen rett – selv om koden ligger der i full åpenhet.
## Hva avgjør om du kan bruke andres kode?
Hovedpoeng
Det er lisensfilen i repositoriet, som vanligvis heter LICENSE eller LICENSE.md. Den er forfatterens tillatelse og angir hva du kan og ikke kan gjøre med koden. Lisensen besvarer tre spørsmål: Kan du bruke koden i et kommersielt produkt, kan du endre den, og kan du holde din egen kildekode lukket? Ulike lisenser besvarer disse spørsmålene forskjellig. Derfor bør du sjekke denne filen først og åpne selve koden etterpå.
Alt koker ned til én fil. Et godt vedlikeholdt repositorium inneholder en lisensfil – vanligvis LICENSE, noen ganger LICENSE.md, eller en omtale direkte i README. Dette er forfatterens tillatelse, som angir vilkårene for hvordan du kan bruke koden. GitHub viser vanligvis lisensnavnet i sidepanelet på repositoriets side, før du åpner selve filen.
For å unngå å gå deg vill i juridisk språk er det nyttig å lese lisensen med utgangspunkt i tre spørsmål om din situasjon:
1. **Kan du bruke denne koden i et kommersielt produkt** som folk betaler for?
2. **Kan du endre koden** etter behovene dine?
3. **Må du åpne kildekoden til produktet ditt etterpå**, eller kan du holde den lukket?
Nesten alle forskjellene mellom lisenser handler om ulike svar på det tredje spørsmålet. På de to første svarer populære åpne lisenser som oftest «ja»: bruk den, endre den, selg den. Det er spørsmålet om lisensen tvinger deg til å åpne din egen kode, folk snubler i. Deretter går vi gjennom hovedtypene med disse tre spørsmålene som utgangspunkt.
## Hvilke lisenser lar deg bruke kode og selge et produkt?
Hovedpoeng
De mest praktiske for et kommersielt produkt er tillatende lisenser: MIT, Apache 2.0 og BSD. De tillater nesten alt: å bruke koden, endre den, selge produktet og holde din egen kildekode lukket. Det er én forpliktelse: å bevare lisensteksten og krediteringen. Apache 2.0 beskytter også mot patentkrav og krever at du merker endrede filer. Hvis andres kode har en av disse lisensene, kan du trygt bruke den i et kommersielt produkt.
La oss begynne med gode nyheter. For deg som bygger et produkt for salg, er det beste valget en gruppe lisenser som kalles tillatende lisenser. Det finnes flere, men tre er mest vanlige: MIT, Apache 2.0 og BSD. Alle tre svarer «ja» på de to første spørsmålene og lar deg holde din egen kildekode lukket.
Den vanligste og enkleste er MIT. Teksten får plass i ett avsnitt.
Det gis herved gratis tillatelse til enhver som får en kopi av denne programvaren, til å bruke den uten begrensninger, inkludert retten til å bruke, kopiere, endre, slå sammen, publisere, distribuere, viderelisensiere og selge kopier, forutsatt at ovennevnte opphavsrettsmerknad og denne tillatelsesmerknaden tas med i alle kopier.
— MIT-lisensen, opensource.org, https://opensource.org/license/mit
Enklere sagt lar MIT deg gjøre nesten hva som helst med koden, inkludert å selge produktet og holde din egen kildekode lukket. Den eneste forpliktelsen er å ta med lisensteksten og linjen med kreditering. Babel, .NET og Rails er for eksempel utgitt under MIT, så du har nesten helt sikkert allerede brukt kode med denne lisensen.
Apache 2.0 fungerer på lignende måte, men legger til to viktige punkter. For det første gir den uttrykkelig beskyttelse mot patentkrav: forfatterne av koden lover å ikke saksøke deg for patenter på denne koden. For det andre har den noen flere formelle krav til bruk.
Du kan reprodusere og distribuere kopier av verket eller avledede verk i ethvert medium, med eller uten endringer, forutsatt at du gir mottakerne en kopi av denne lisensen, merker endrede filer, beholder opphavsretts- og patentmerknader og legger ved en leselig kopi av NOTICE-filen, hvis den finnes.
— Apache-lisensen 2.0, del 4, https://www.apache.org/licenses/LICENSE-2.0
BSD (i versjonene med 2 og 3 klausuler) ligner i hovedsak på MIT: bruk den, endre den, selg den og behold opphavsrettsmerknaden. Jeg har satt alle tre i en tabell, så du kan se forskjellen med et blikk.
| Lisens | Selge produktet | Holde kildekoden lukket | Hva du må gjøre | Patentbeskyttelse |
|----|----|----|----|----|
| MIT | ja | ja | beholde opphavsrettsmerknad og lisenstekst | ingen klausul |
| Apache 2.0 | ja | ja | opphavsrettsmerknad, NOTICE-fil, merke endringer | ja |
| BSD (2 og 3 klausuler) | ja | ja | beholde opphavsrettsmerknaden | nei |
Slik kan du bruke dette i din egen situasjon: Ser du MIT, Apache 2.0 eller BSD på andres kode, kan du senke skuldrene: Du kan bruke den i et kommersielt produkt, endre den og holde din egen kildekode lukket. Du må bare passe på at du ikke fjerner lisensfilen og krediteringen fra delen du tok med.
## Hvordan gjelder kildekodepliktene i GPL og AGPL?
Hovedpoeng
GPL og AGPL tillater kommersiell bruk. GPL-kildeplikter oppstår når et dekket verk overdras; vanlig serverbruk uten kopioverføring er ikke utløseren. AGPLv3 legger til krav om kildetilbud til brukere som samhandler eksternt med en endret versjon. Avklar hvilket kombinert verk som dekkes. Separate uavhengige komponenter inngår ikke automatisk alle sammen.
Copyleft holder et dekket verk og avledninger under samme lisens når relevante vilkår gjelder. Under GPLv3 krever distribusjon av kilde- eller objektkodekopier av dekket eller kombinert avledet verk etterlevelse av lisens og tilhørende kildeplikter. Det gjelder ikke automatisk hvert uavhengig program i samme produkt eller server.
I nettjenesteeksemplet krever hosting av et GPL-bibliotek på egen server uten brukerkopier ikke i seg selv publisering av hele tjenesten. Distribusjon av en dekket kombinert applikasjon til kunder kan utløse GPL-plikter. Kontroller integrasjon og lisens før du avgjør hvilken kilde som må følge med. En nettleserklient levert til brukere er et separat distribusjonsspørsmål.
AGPLv3 legger til nettverksvilkår: Hvis programmet endres og brukere samhandler med den versjonen eksternt, må det tydelig tilby disse brukerne tilhørende kildekode. Det er mer presist enn at hosting av enhver AGPL-komponent åpner alle uavhengige tjenestedeler.
For proprietært produkt undersøker du dekket verk, komponentkombinasjon, kopidistribusjon og eventuell AGPL-nettverkssamhandling. Velg kompatibelt tillatende alternativ eller skaff separat tillatelse hvis pliktene ikke kan oppfylles. Kommersiell bruk er tillatt. Spørsmålet er etterlevelse av faktisk lisens og integrasjon.
## Hva bør du gjøre hvis repositoriet ikke har noen lisensfil?
Hovedpoeng
Uten lisensfil kan du ikke bruke koden. Det betyr ikke «den er gratis»: Tvert imot er kode uten lisens fortsatt fullt beskyttet av forfatterens opphavsrett, og du har ingen rett til å bruke, kopiere eller endre den. Tillatelsen til å se og forke koden innenfor GitHub hjelper ikke her – den gir deg ikke rett til å legge koden inn i produktet ditt. Hvis du virkelig trenger koden, er den eneste ryddige veien å skrive til forfatteren og be om tillatelse, eller vente til vedkommende legger til en lisens.
En vanlig feil er å anta at det ikke finnes noen begrensninger når det ikke finnes en lisens, og at du derfor kan bruke koden fritt. Det er motsatt. Ingen lisens betyr ikke tillatelse; som standard betyr det at du ikke har tillatelse. Kode uten lisens er fortsatt fullt beskyttet av forfatterens opphavsrett, og du kan ikke røre den.
Regelen vi begynte med gjelder igjen: Som standard er kode beskyttet av opphavsrett, og uten uttrykkelig tillatelse kan du ikke kopiere, endre eller distribuere den. Muligheten til å se og forke den innenfor GitHub bryter ikke gjennom denne barrieren – den gir deg ikke rett til å bruke koden i ditt eget produkt.
Dette kan du gjøre i praksis hvis koden ikke har lisens, men du virkelig trenger den:
1. **Skriv til forfatteren.** Spør direkte i diskusjonsdelen av repositoriet eller på e-post om du kan bruke koden, og på hvilke vilkår. Noen ganger har forfatteren bare glemt å legge til en lisens og gjør det når noen spør.
2. **Se etter en erstatning.** For nesten enhver oppgave finnes det et andre, tredje og tiende lignende repositorium – blant dem finner du ett med en ordentlig MIT- eller Apache-lisens.
3. **Ikke bruk den.** Hvis du ikke har tillatelse og det ikke finnes noen erstatning, er ikke koden din, og du kan ikke legge den inn i et produkt du har tenkt å selge. Fristelsen til å tenke «hvem kommer til å oppdage det?» ender dårlig akkurat når produktet begynner å tjene penger og tiltrekke seg oppmerksomhet.
## Hva om Claude selv la til andres kode i prosjektet?
Hovedpoeng
Dette er et eget tilfelle, og det er viktig å ikke forveksle det med å kopiere et repositorium direkte. Når du selv henter kode fra et bestemt repositorium, må du følge lisensen. Når Claude eller en annen AI genererer kode som svar på forespørselen din, produserer den vanligvis sin egen tekst, satt sammen for oppgaven, heller enn en kopi av en fil fra noen andre. Da dreier spørsmålet seg om rettighetene til den genererte koden. Men hvis AI tydelig har gjengitt et gjenkjennelig stykke lisensiert kode fra noen andre, gjelder lisensvilkårene fortsatt. Det er lurt å kontrollere kilden i begge tilfeller.
Det finnes et andre lag her, som det er lett å forveksle med det første. Det er én ting å gå til et repositorium og kopiere en fil derfra: Da er du direkte forpliktet til alt ovenfor om lisensen. Det er noe annet når Claude skriver kode for deg som svar på en forespørsel.
I vanlige tilfeller produserer AI sin egen tekst, satt sammen for oppgaven din, heller enn en kopi av filen til noen andre. Da dreier spørsmålet seg om et annet område: Hvem eier den genererte koden, og kan du selge den? Det er et stort tema i seg selv, og jeg har behandlet det i en artikkel om hvem som eier kode skrevet av AI.
Men det finnes et unntak du bør huske på. Noen ganger produserer AI et gjenkjennelig stykke av andres kode nesten ord for ord – for eksempel en hel funksjon fra et kjent bibliotek. I så fall gjelder bibliotekets lisens fortsatt, uansett hvem som fysisk trykket på tastene. Store, ferdiglagde kodeblokker Claude har tatt med i sin helhet, bør derfor kontrolleres som om du selv hadde kopiert dem.
## Slik kontrollerer du en lisens før du bruker kode: fremgangsmåte
Hovedpoeng
Fremgangsmåten er: Åpne repositoriets side og sjekk lisensnavnet i sidepanelet, åpne selve LICENSE-filen, finn ut hvilken type det er – tillatende (MIT, Apache, BSD) eller copyleft (GPL, AGPL) – sammenlign den med din situasjon, og bestem om du skal bruke koden eller finne en erstatning. Hvis det ikke finnes noen lisens, skal du ikke bruke koden. Hele kontrollen tar et par minutter og bør skje før koden kommer inn i prosjektet ditt, ikke etterpå.
La oss samle alt i en kort sjekkliste for kontroll av tredjepartskode før du tar den inn i prosjektet. Gå gjennom punktene ovenfra og ned.
1. ### Finn lisensnavnet på repositoriets side
Åpne repositoriet på GitHub. Lisensnavnet er vanligvis synlig i høyre kolonne eller under fillisten – for eksempel «MIT License», «Apache-2.0» eller «GPL-3.0». Hvis feltet er tomt og det ikke finnes noen lisensfil, er det allerede et varselsignal; kom tilbake til det i siste steg.
2. ### Åpne selve lisensfilen
Finn LICENSE, LICENSE.md eller COPYING i fillisten, og åpne den. Kontroller at navnet stemmer med det som vises i sidepanelet, og at lisensen gjelder koden du bruker, ikke bare en separat del av repositoriet.
3. ### Finn ut hvilken type det er: tillatende eller copyleft
MIT, Apache 2.0 og BSD er tillatende; du kan bruke koden i et lukket kommersielt produkt. GPL og AGPL er copyleft. Kontroller dekket verk, distribusjon og eventuelt AGPL-nettverksvilkår før kildeplikter avgjøres. Navnet alene fastslår ikke hvilke uavhengige komponenter som dekkes.
4. ### Sammenlign med din situasjon
Svar på tre spørsmål: Selger du produktet, endrer du koden, og vil du holde kildekoden lukket? MIT, Apache og BSD passer for et lukket produkt som selges. For GPL og AGPL må du avgjøre hvilket dekket eller kombinert verk som trenger tilhørende kildekode, og når plikten utløses. Vurder om vilkårene kan oppfylles.
5. ### Ingen lisens betyr at du ikke skal bruke koden
Hvis det ikke finnes noen lisensfil og README ikke sier noe om tillatelse, kan du ikke bruke koden. Skriv til forfatteren og be om tillatelse, eller finn en tilsvarende løsning med en ordentlig lisens. «Den er offentlig tilgjengelig» er ikke tillatelse.
Denne kontrollen virker omstendelig helt fram til første gang produktet ditt vokser, begynner å tjene penger, og noen spør om tredjepartskoden i det. To minutter i starten koster mindre enn å håndtere en tvist senere. Jeg tar for meg separat hva du bør gjøre med produktet etterpå, så det ikke stopper opp etter lanseringen: [Jeg bygde et produkt med AI; hva nå](https://ailoot.ai/blog/nb/ai-product-maintenance-after-launch/).
### Ofte stilte spørsmål
Kan du selge et produkt som inneholder andres kode fra GitHub?
Ja, hvis koden har en tillatende lisens – MIT, Apache 2.0 eller BSD. De lar deg bruke koden i et kommersielt produkt, selge det og holde din egen kildekode lukket. Det eneste kravet er at du beholder lisensteksten og krediteringen. GPL og AGPL tillater også kommersiell bruk, men kildeplikter avhenger av dekket verk og distribusjon eller relevant AGPL-nettverksutløser. Uten en lisensfil kan du ikke bruke koden i det hele tatt.
Hva betyr det hvis et GitHub-repositorium ikke har noen lisens?
Det betyr at du ikke kan bruke koden. Ingen lisens betyr som standard ingen tillatelse; det betyr ikke «gratis». Koden er fortsatt fullt beskyttet av forfatterens opphavsrett. At du kan se og forke repositoriet innenfor GitHub, gir deg ikke rett til å bruke koden i produktet ditt. Hvis du trenger koden, kan du skrive til forfatteren og be om tillatelse eller finne en tilsvarende løsning med en åpen lisens.
Hva er forskjellen på MIT og GPL for produktet mitt?
MIT lar deg bruke og endre koden, selge produktet og holde din egen kildekode lukket – den eneste forpliktelsen er å beholde lisensteksten. GPL tillater også kommersiell bruk, men overdragelse av et dekket kombinert eller avledet verk krever etterlevelse av tilhørende kilde- og sammelisensplikter. Ren hosting uten kopioverføring er annerledes, og separate uavhengige komponenter dekkes ikke automatisk.
Må jeg gjøre noe hvis jeg bruker kode under MIT-lisensen?
Ja, én liten ting: Behold MIT-lisensteksten og linjen med kreditering fra koden du brukte i prosjektet. Vanligvis er det den samme LICENSE-filen som fulgte med originalen. MIT krever ikke noe annet – du kan endre koden, selge produktet og holde kildekoden din lukket.
Hva om Claude selv la til andres kode, i stedet for at jeg gjorde det?
Du bør fortsatt sjekke kilden. AI lager vanligvis sin egen tekst til oppgaven din, og da dreier spørsmålet seg om rettighetene til generert kode – et eget tema. Men hvis AI gjenga et gjenkjennelig stykke kode fra noen andre i et kjent bibliotek nesten ord for ord, gjelder lisensen til biblioteket fortsatt. Kontroller store, ferdiglagde kodeblokker som er tatt med i sin helhet, på samme måte som om du selv hadde kopiert og limt dem inn.
### Kilder
- [choosealicense.com - GitHubs referanseprosjekt for valg av lisens](https://choosealicense.com/)
- [choosealicense.com - hva det betyr å ikke ha en lisens](https://choosealicense.com/no-permission/)
- [GitHubs tjenestevilkår, del D (lisens til andre brukere)](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service)
- [MIT-lisensen (opensource.org)](https://opensource.org/license/mit)
- [Apache-lisensen 2.0 (apache.org)](https://www.apache.org/licenses/LICENSE-2.0)
- [GNU General Public License v3.0 (gnu.org)](https://www.gnu.org/licenses/gpl-3.0.en.html)
- [GNU Affero General Public License v3.0 (gnu.org)](https://www.gnu.org/licenses/agpl-3.0.en.html)
[Åpne Ailoot](https://ailoot.ai/).
## Spørsmål om denne veiledningen: GitHub-kode i et kommersielt produkt: lisenser og hva du bør sjekke
### Tvinger hosting av et GPL-bibliotek meg til å publisere hele nettjenesten?
Hosting alene uten kopioverføring er ikke GPL-distribusjonsutløser. Distribueres en dekket kombinert eller avledet applikasjon, kan kildeplikter gjelde det verket. Uavhengige komponenter dekkes ikke automatisk.
### Hvilket ekstra vilkår legger AGPLv3 til en nettjeneste?
Et endret AGPL-program med fjerninteraksjon over nett må tilby tilhørende kildekode til disse brukerne. Kontroller dekket program og integrasjon fremfor å anta at ingen kilde trengs eller at enhver uavhengig tjeneste må åpnes.
## Ailoot · Selskapet og dets prosjektportefølje
Ailoot bygger på etablert driftserfaring, en stor kundebase, stabil tjeneste og løpende KPI-kontroll.
Selskapet og dets prosjektportefølje: millioner av kunder; månedlig salg for milliarder.
Ailoot bruker denne driftserfaringen til API-tilgang til AI-funksjoner i kundenes produkter, agenter, applikasjoner og automatiseringer.