GPL-2.0 kræver kildekode, når du giver nogen en binær fil. At køre den på egne servere udløser intet. Triggeren er at levere en kopi, ikke blot at bruge den.
På denne side
Hvad den gør
Du kan køre GPL-2.0-kode på dine egne servere, ændre den og holde din egen kildekode privat. Pligten starter, når du overdrager en binær fil, altså giver en kopi af softwaren til nogen uden for din egen organisation. Fra det øjeblik kan hver modtager bede om den komplette tilsvarende kildekode til hele det kombinerede program, under samme licens, byggescripts inklusive. Det er dét, copyleft betyder: licensen kræver, at det du giver videre, forbliver lige så åbent som det, du selv fik. WordPress, Drupal og MediaWiki er de bedst kendte eksempler.
Detaljer
GPL-spørgsmålet i dit inventar er sjældent 'bruger vi GPL-kode'. Det er 'giver vi nogensinde en kopi videre til nogen'. En hostet tjeneste, der aldrig sender en artefakt ud, svarer nej, og det svar er reelt beroligende. Et Docker-image, som en kunde henter, en on-prem-appliance, et mobil-build eller et firmware-image svarer ja. Så er hele det program, du har sendt ud, omfattet, ikke kun GPL-filen, og kildekode-tilbuddet skal findes, før udgivelsen gør.
Fordele
- Tydelige regler for at dele forbedringer. Modtagere af en binær fil kan bede om den tilhørende kildekode.
- Bredt forstået af legal og engineering. Kompatibilitetsspørgsmål har et stort offentligt spor.
Ulemper
- At sende en kombineret binær fil ud betyder som regel at tilbyde tilhørende kildekode under samme licens.
- At blande med Apache-2.0 eller andre patentbærende licenser er en kendt kompatibilitetsfælde på ældre GPL-versioner.
Hvad den tillader og kræver
Vælg en kategori for at se hele tilladelsen i én overskuelig liste. Tilladelser viser, hvad licensen giver lov til, grænser viser, hvad den tilbageholder, og forpligtelser viser de betingelser, jeres releaseproces skal opfylde.
Tilladelser
Kommerciel brug
Du må sende koden med i et betalt produkt. Licensen begrænser ikke kommerciel brug.
Ændre
Du må ændre koden, også holde ændringerne private, medmindre en senere pligt siger noget andet.
Distribuere
Du må give kopier til andre. Distribution er det, der typisk gør notits- og kildekodepligter til reelt arbejde.
Privat brug
Brug inde i virksomheden, også interne forks, udløser ikke i sig selv distributionspligter.
Grænser
Holde ansvarlig
Forfatterne fraskriver sig garanti. Modtagere kan ikke holde dem ansvarlige for skader fra softwaren, undtagen hvor loven forbyder den fraskrivelse.
Bruge varemærke
Licensen er ikke en varemærkelicens. Navne, logoer og produktmærker bliver hos ejerne, medmindre en separat tilladelse siger noget andet.
Åbne dit produkt
Copyleft kan nå et samlet værk, du distribuerer, ikke kun de originale filer. Hvor langt det rækker i dit stack, er et juristspørgsmål.
Netværks-copyleft
Klassisk GPL har ingen netværksklausul. At tilbyde programmet som en hostet tjeneste, uden at uddele en kopi, udløser ikke i sig selv kildekode-tilbuddet.
Forpligtelser
Medtag copyright
Behold copyright-notitser på distribuerede kopier.
Medtag licens
Giv modtagere en kopi af licensen sammen med programmet.
Offentliggør kildekode
Når du distribuerer en binær fil af et dækket værk, skal tilsvarende kildekode tilbydes på den måde, licensen beskriver.
Samme licens
Det samlede værk, du distribuerer, skal blive under denne licens. Du kan ikke lukke det dækkede værk med en mere restriktiv tilladelse.
Senere GPL
Or later lader en modtager tage GPLv3-vilkår. Indtil de gør det, skal kopien, du sender ud, stadig opfylde GPL-2.0s regler om tilsvarende kildekode.
Hvad GPL-2.0-or-later kræver, når I sender kode ud
Når du distribuerer en binær fil, der indeholder GPL-2.0-or-later-kode, følger notitsen stadig med kopien, og den tilsvarende kildekode skal være tilgængelig under samme licens. Intern brug uden at en kopi forlader virksomheden er en anden situation. Listen nedenfor er forsendelsesarbejdet: det en modtager af den binære fil kan kræve, og det du registrerer, så en køber kan se det.
Du opfylder vilkårene, så længe ingen uden for dit team modtager en kopi. At køre og ændre GPL-2.0-kode på egne servere udløser ingen kildekode-pligt, for version 2 har ingen netværksklausul.
Du opfylder dem ved en leveret binær fil, når hver modtager kan få den komplette tilsvarende kildekode til det kombinerede program. Samme leverance eller et skriftligt tilbud, der gælder i tre år, fungerer begge.
Du opfylder notits-vilkårene, når de oprindelige copyright-linjer og licensteksten følger med kopien, og hver fil, du har ændret, bærer en note om, at du har ændret den, og hvornår.
Du læser tilladelsen rigtigt, når du behandler 'only' og 'or later' som to forskellige licenser. 'Or later' lader en modtager gå til GPLv3-vilkår, og det er dét, der i praksis gør Apache-2.0-kode kombinerbar.
Du har lukket linking-spørgsmålet, når en jurist har svaret på det. FSF læser både statisk og dynamisk linking som ét kombineret værk, og den læsning er aldrig blevet afgjort ved en domstol.
De pligter, GPL-2.0-or-later navngiver
Notitsen følger stadig med kopien. Oven i det navngiver GPL-2.0-or-later en kildekodepligt. Dette er betingelserne i teksten. Vejledningen ovenfor er, hvornår de bliver til reelt arbejde.
Medtag copyright
Behold copyright-notitser på distribuerede kopier.
Medtag licens
Giv modtagere en kopi af licensen sammen med programmet.
Offentliggør kildekode
Når du distribuerer en binær fil af et dækket værk, skal tilsvarende kildekode tilbydes på den måde, licensen beskriver.
Samme licens
Det samlede værk, du distribuerer, skal blive under denne licens. Du kan ikke lukke det dækkede værk med en mere restriktiv tilladelse.
Senere GPL
Or later lader en modtager tage GPLv3-vilkår. Indtil de gør det, skal kopien, du sender ud, stadig opfylde GPL-2.0s regler om tilsvarende kildekode.
Det skal du være opmærksom på
- At sige 'vi bruger den kun på serveren, så GPL er ligegyldig' og derefter sende et Docker-image eller et on-prem-build ud. Stil spørgsmålet per artefakt, du giver fra dig, ikke én gang per virksomhed.
- At tilbyde kildekode for GPL-pakken alene. Forpligtelsen dækker den tilsvarende kildekode til hele det program, du har sendt ud, inklusive byggescripts og de filer, der skal til for at bygge det igen.
- At skrive et kildekode-tilbud, som ingen ejer. Navngiv repositoriet eller postadressen før udgivelse, og sæt en person på at holde det tilgængeligt i alle tre år.
- At antage, at pakken er 'GPL-2.0', når dens headere siger 'only'. Git og BusyBox er GPL-2.0-only, de to tilladelser er forskellige, og en pakke, der angiver den ene og leverer den anden tekst, lander som mismatch i stedet for confirmed.
Hvad GNU GPL v2.0 eller senere ikke gør
Søgeresultater flader ofte GNU GPL v2.0 eller senere ud til et slogan. Dette er de sædvanlige fejllæsninger. GPL-2.0-or-later er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.
- GPL-2.0-or-later lader dig ikke holde det samlede program lukket, hvis du distribuerer det. Den gensidige pligt rækker til værket som helhed.
- Netværksbrug alene er ikke distribution for GPL-familien. At køre et GPL-program som SaaS, uden AGPL, udløser ikke i sig selv kildekode-pligten.
Hvordan GPL-2.0-or-later adskiller sig fra nærliggende licenser
Disse licenser forveksles ofte med GPL-2.0-or-later, men deres pligter ved en release er forskellige. Hver række opsummerer, hvad licensen kræver, når I sender kode ud. Åbn den linkede side for den fulde tjekliste.
- GPL-2.0-or-later
- GPL-2.0 kræver kildekode, når du giver nogen en binær fil. At køre den på egne servere udløser intet. Triggeren er at levere en kopi, ikke blot at bruge den.
- GPL-2.0-only
- GPL-2.0-only er stærk copyleft låst til version 2. Modtagere kan ikke flytte værket til GPLv3, så Apache-2.0 kombinerer ikke med den.
- GPL-3.0-only
- GPL-3.0 beholder kildekode-pligten ved binær distribution og tilføjer et patentbrev, en anti-lockdown-regel for forbrugerenheder og en frist til at rette.
- LGPL-2.1-or-later
- Svag copyleft for biblioteker. Din egen kode kan forblive lukket, så længe brugere kan skifte biblioteket ud med eget build. Statisk linking er dyrt.
Ofte stillede spørgsmål om GNU GPL v2.0 eller senere
Svar på almindelige spørgsmål om, hvad GNU GPL v2.0 eller senere kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.
Hvad er GNU GPL v2.0 eller senere?
Du kan køre GPL-2.0-kode på dine egne servere, ændre den og holde din egen kildekode privat. Pligten starter, når du overdrager en binær fil, altså giver en kopi af softwaren til nogen uden for din egen organisation. Fra det øjeblik kan hver modtager bede om den komplette tilsvarende kildekode til hele det kombinerede program, under samme licens, byggescripts inklusive. Det er dét, copyleft betyder: licensen kræver, at det du giver videre, forbliver lige så åbent som det, du selv fik. WordPress, Drupal og MediaWiki er de bedst kendte eksempler.
Hvad kræver GPL-2.0-or-later, når I sender et produkt ud?
Du opfylder vilkårene, så længe ingen uden for dit team modtager en kopi. At køre og ændre GPL-2.0-kode på egne servere udløser ingen kildekode-pligt, for version 2 har ingen netværksklausul. Du opfylder dem ved en leveret binær fil, når hver modtager kan få den komplette tilsvarende kildekode til det kombinerede program. Samme leverance eller et skriftligt tilbud, der gælder i tre år, fungerer begge. Du opfylder notits-vilkårene, når de oprindelige copyright-linjer og licensteksten følger med kopien, og hver fil, du har ændret, bærer en note om, at du har ændret den, og hvornår. Du læser tilladelsen rigtigt, når du behandler 'only' og 'or later' som to forskellige licenser. 'Or later' lader en modtager gå til GPLv3-vilkår, og det er dét, der i praksis gør Apache-2.0-kode kombinerbar. Du har lukket linking-spørgsmålet, når en jurist har svaret på det. FSF læser både statisk og dynamisk linking som ét kombineret værk, og den læsning er aldrig blevet afgjort ved en domstol.
Udløser det ekstra pligter at hoste et produkt, der bruger GPL-2.0-or-later?
Hosting alene udløser som regel ikke kildekodepligten for GPL-2.0-or-later. At sende en binær fil, et container-image eller et on-prem-build ud gør. Notitsen følger stadig med hver kopi, I giver videre.
Tvinger linking til GPL-2.0-or-later mig til at åbne min applikation?
For stærk copyleft som GPL-2.0-or-later læser FSF statisk og dynamisk linking som ét samlet værk, når I distribuerer resultatet. At sende en binær fil, der indeholder GPL-2.0-or-later-kode, er den sædvanlige udløser. Intern brug, hvor ingen kopi forlader virksomheden, er en anden situation. Læs den faktiske tekst, ikke familienavnet.
Hvad er tilsvarende kildekode for GPL-2.0-or-later?
Tilsvarende kildekode er den kilde, en modtager skal bruge for at bygge og køre den samme binære fil, inklusive scripts og interfacefiler, licensen nævner. At hoste en repository-URL kan være et tilbud. Tilbuddet skal matche det, I faktisk har sendt ud. SourceTrust registrerer, at en på jeres team har bekræftet tilbuddet. Den udgiver ikke jeres kildekode og hoster ikke et spejl.
Hvordan adskiller GPL-2.0-or-later sig fra GNU GPL v2.0 kun?
GPL-2.0-or-later kræver dette: GPL-2.0 kræver kildekode, når du giver nogen en binær fil. At køre den på egne servere udløser intet. Triggeren er at levere en kopi, ikke blot at bruge den. GNU GPL v2.0 kun kræver dette: GPL-2.0-only er stærk copyleft låst til version 2. Modtagere kan ikke flytte værket til GPLv3, så Apache-2.0 kombinerer ikke med den. Åbn GNU GPL v2.0 kun-siden for, hvad den licens kræver, når I sender kode ud. Behandl ikke SPDX-id'erne som udskiftelige, bare fordi de korte navne ligner hinanden.
Hvor registrerer jeg GPL-2.0-or-later til en køber?
Kataloget markerer GPL-2.0-or-later som copyleft, så et punkt om kildekode-tilbud dukker op på projektets tjekliste, når projektets distributionskontekst er Distribueret binær eller Blandet. Et rent SaaS-projekt ser intet punkt for den, hvilket matcher licensen. Punktet bliver ikke sat for dig: en på dit team bekræfter det, og publicering er spærret, indtil hvert relevant punkt er bekræftet. SourceTrust udgiver ikke din kildekode og hoster ikke et spejl.
Hvor registrerer jeg GPL-2.0-or-later til en køber?
Kataloget markerer GPL-2.0-or-later som copyleft, så et punkt om kildekode-tilbud dukker op på projektets tjekliste, når projektets distributionskontekst er Distribueret binær eller Blandet. Et rent SaaS-projekt ser intet punkt for den, hvilket matcher licensen.
Punktet bliver ikke sat for dig: en på dit team bekræfter det, og publicering er spærret, indtil hvert relevant punkt er bekræftet. SourceTrust udgiver ikke din kildekode og hoster ikke et spejl.
Læs /docs/mobile-app-licenses, når den binære fil er en mobilapp.
- Hentningen sammenligner licensteksten i den udgivne artefakt med det id, pakken angiver. En pakke, der siger 'only', men leverer 'or later'-teksten, lander som mismatch, som et menneske skal afgøre.
- Den gemte licenstekst er den, din offentliggjorte attestation-side og hver eksportfil bærer, inklusive THIRD_PARTY_LICENSES.md og SBOM-formaterne.
Se også
Hubben er søjlen for denne klynge. Søskendelicenser er de andre eger. Produkt-FAQ-links forklarer, hvordan SourceTrust registrerer pligten, ikke selve licensteksten.
Praktisk vejledning til procurement-gennemgang, ikke juridisk rådgivning. Bekræft brug med høj risiko med jurist.