Svag copyleft skrevet som et tillæg til GPLv3. Forbrugerenheder skylder også installationsinformation til et ændret bibliotek.
På denne side
Hvad den gør
LGPL-3.0 er ikke en selvstændig licens. Den er et kort sæt ekstra tilladelser oven på GPLv3, så du læser de to sammen. Qt's open source-udgave er det bedst kendte eksempel. Lempelsen er den samme som i version 2.1: din lukkede applikation må linke mod biblioteket. Copyleft-pligten, altså at ændringer kommer ud igen under samme licens, bliver på selve biblioteket. Den ekstra vægt ligger i afsnit 4, der lister, hvad et Combined Work skal bære. GPLv3 afsnit 6 lægger derefter Installation Information til for forbrugerenheder. Sender du biblioteket ud inde i hardware, en forbruger køber, skal køberen kunne installere sit eget build af biblioteket.
Detaljer
For en hostet tjeneste kræver LGPL-3.0 intet: der er ingen netværksklausul, og intet bliver distribueret. For software, du sender ud, opfører den sig som version 2.1 med ét ekstra scenarie. En router, en tv-boks, et infotainmentsystem i en bil eller enhver låst forbrugerenhed trækker Installation Information-pligten med sig, og de fleste teams har ingen plan for den. App store-distribution er det næste argument, du vil høre. Kravene om genlink og installation læses bredt som svære at opfylde under butikkens vilkår, men den læsning er ikke afgjort. Tag det spørgsmål til en jurist, før du bygger på det.
Fordele
- Du kan linke biblioteket fra lukket kode på den måde, licensen beskriver.
- Fil-niveau gensidighed er lettere at isolere end GPL-agtig copyleft på hele værket.
Ulemper
- At vendorere eller linke statisk kan trække mere af dit træ ind i det dækkede sæt, end et dynamisk link ville.
- Kildekode-tilbuddet er reelt, i det øjeblik du distribuerer binære filer, der indeholder ændrede dækkede filer.
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.
Patentbrug
Disse licenser indeholder typisk en patenttilladelse, der dækker de licenserede filer. Læs tilladelsen, før du læner dig op ad den i en sag med høj indsats.
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 på fil- eller biblioteks-niveau tvinger dig ikke, på tekstens ord, til at åbne hele din applikation. Gensidigheden bliver på de dækkede filer.
Forpligtelser
Medtag copyright
Behold copyright-notitser på de dækkede filer, du distribuerer.
Medtag licens
Behold licensteksten sammen med de dækkede filer, og sig at de filer er under denne licens.
Offentliggør kildekode
Kildekode til biblioteket, inklusive dine ændringer af det, skal være tilgængelig for dem, der fik en binær fil.
Hold udskiftelig
Modtagere skal kunne skifte biblioteket ud med eget build. Dynamisk linking er den sædvanlige vej. Statisk linking betyder, at du også giver en måde at genlinke på.
Installation Information
Or later bærer stadig GPLv3 Installation Information på et User Product. Modtagere må også tage en fremtidig LGPL fra FSF.
Hvad LGPL-3.0-or-later kræver, når I sender kode ud
Når du distribuerer en binær fil, der indeholder LGPL-3.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 afsnit 4, når dit Combined Work nævner biblioteket, sender LGPL- og GPL-teksterne med og viser copyright-notitserne, hvor en bruger kan se dem.
Du opfylder genlink-betingelsen, når biblioteket indlæses ved kørsel som en separat fil, eller når du leverer objektkode, der lader en bruger genbygge kombinationen.
Du har håndteret en forbrugerenhed, når køberen får den Installation Information, der skal til for at lægge sit eget build af biblioteket på den hardware, de har købt.
Du har dækket kildekode-pligten, når alle, der modtager din binære fil, kan få bibliotekets fulde kildekode under LGPL, fra en offentlig URL eller et skriftligt tilbud.
Du har taget hånd om dine egne rettelser, når hver ændring, du har lavet inde i biblioteket, kommer ud igen under LGPL, når du distribuerer det, adskilt fra din applikationskode.
De pligter, LGPL-3.0-or-later navngiver
Notitsen følger stadig med kopien. Oven i det navngiver LGPL-3.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å de dækkede filer, du distribuerer.
Medtag licens
Behold licensteksten sammen med de dækkede filer, og sig at de filer er under denne licens.
Offentliggør kildekode
Kildekode til biblioteket, inklusive dine ændringer af det, skal være tilgængelig for dem, der fik en binær fil.
Hold udskiftelig
Modtagere skal kunne skifte biblioteket ud med eget build. Dynamisk linking er den sædvanlige vej. Statisk linking betyder, at du også giver en måde at genlinke på.
Installation Information
Or later bærer stadig GPLv3 Installation Information på et User Product. Modtagere må også tage en fremtidig LGPL fra FSF.
Det skal du være opmærksom på
- Firmware-teams signerer imaget og låser bootloaderen, hvilket sætter Installation Information-pligten ud af kraft. Afgør licensspørgsmålet, før hardwaredesignet er låst.
- Teams behandler LGPL-2.1 og LGPL-3.0 som samme licens. De adskiller sig præcis der, hvor det koster penge: forbrugerhardware og blanding med GPLv2-only-kode.
- Et iOS-build statisk-linker biblioteket og sender ud uden nogen genlink-vej. Send et dynamisk framework, eller vælg et bibliotek med en anden licens før release-branchen.
Hvad GNU LGPL v3.0 eller senere ikke gør
Søgeresultater flader ofte GNU LGPL v3.0 eller senere ud til et slogan. Dette er de sædvanlige fejllæsninger. LGPL-3.0-or-later er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.
- LGPL-3.0-or-later tvinger dig ikke til at åbne hele din applikation. Den gensidige pligt bliver på de dækkede filer.
- Det er ikke "tilladelig med ekstra papirarbejde." Ændrer du en dækket fil og sender den ud, skal den fils kildekode være tilgængelig under samme licens.
Hvordan LGPL-3.0-or-later adskiller sig fra nærliggende licenser
Disse licenser forveksles ofte med LGPL-3.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.
- LGPL-3.0-or-later
- Svag copyleft skrevet som et tillæg til GPLv3. Forbrugerenheder skylder også installationsinformation til et ændret bibliotek.
- LGPL-3.0-only
- LGPL-3.0-only er bibliotek-copyleft låst til version 3. Samme udskiftelighedsregel, med GPLv3-patent- og User Product-vilkår, og ingen senere LGPL.
- 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.
- 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.
Ofte stillede spørgsmål om GNU LGPL v3.0 eller senere
Svar på almindelige spørgsmål om, hvad GNU LGPL v3.0 eller senere kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.
Hvad er GNU LGPL v3.0 eller senere?
LGPL-3.0 er ikke en selvstændig licens. Den er et kort sæt ekstra tilladelser oven på GPLv3, så du læser de to sammen. Qt's open source-udgave er det bedst kendte eksempel. Lempelsen er den samme som i version 2.1: din lukkede applikation må linke mod biblioteket. Copyleft-pligten, altså at ændringer kommer ud igen under samme licens, bliver på selve biblioteket. Den ekstra vægt ligger i afsnit 4, der lister, hvad et Combined Work skal bære. GPLv3 afsnit 6 lægger derefter Installation Information til for forbrugerenheder. Sender du biblioteket ud inde i hardware, en forbruger køber, skal køberen kunne installere sit eget build af biblioteket.
Hvad kræver LGPL-3.0-or-later, når I sender et produkt ud?
Du opfylder afsnit 4, når dit Combined Work nævner biblioteket, sender LGPL- og GPL-teksterne med og viser copyright-notitserne, hvor en bruger kan se dem. Du opfylder genlink-betingelsen, når biblioteket indlæses ved kørsel som en separat fil, eller når du leverer objektkode, der lader en bruger genbygge kombinationen. Du har håndteret en forbrugerenhed, når køberen får den Installation Information, der skal til for at lægge sit eget build af biblioteket på den hardware, de har købt. Du har dækket kildekode-pligten, når alle, der modtager din binære fil, kan få bibliotekets fulde kildekode under LGPL, fra en offentlig URL eller et skriftligt tilbud. Du har taget hånd om dine egne rettelser, når hver ændring, du har lavet inde i biblioteket, kommer ud igen under LGPL, når du distribuerer det, adskilt fra din applikationskode.
Udløser det ekstra pligter at hoste et produkt, der bruger LGPL-3.0-or-later?
Hosting alene udløser som regel ikke kildekodepligten for LGPL-3.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.
Kan jeg holde min applikation lukket, hvis jeg bruger LGPL-3.0-or-later?
LGPL-3.0-or-later er bibliotek-copyleft. Jeres applikation kan forblive lukket, hvis modtagere kan skifte biblioteket ud med deres eget build. Statisk linking gør det dyrt. Biblioteket selv skal stadig følge med tilsvarende kildekode og notitser. Bekræft linking-historien på komponenten, og registrer den.
Hvad er tilsvarende kildekode for LGPL-3.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 LGPL-3.0-or-later sig fra GNU LGPL v3.0 kun?
LGPL-3.0-or-later kræver dette: Svag copyleft skrevet som et tillæg til GPLv3. Forbrugerenheder skylder også installationsinformation til et ændret bibliotek. GNU LGPL v3.0 kun kræver dette: LGPL-3.0-only er bibliotek-copyleft låst til version 3. Samme udskiftelighedsregel, med GPLv3-patent- og User Product-vilkår, og ingen senere LGPL. Åbn GNU LGPL v3.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 LGPL-3.0-or-later til en køber?
SourceTrust behandler hvert SPDX-id, der starter med LGPL, ens. Kataloget markerer den som copyleft, så et punkt om kildekode-tilbud lander på projektets tjekliste i konteksterne Distribueret binær og Blandet. Et LGPL-linking-punkt lander i Bibliotek eller SDK, Distribueret binær og Blandet. Begge venter på, at en person bekræfter dem, og publicering er spærret, indtil det sker. Intet her afgør din linking-model eller efterser dit device-build. Sender du en binær fil til en app-butik, så
Hvor registrerer jeg LGPL-3.0-or-later til en køber?
SourceTrust behandler hvert SPDX-id, der starter med LGPL, ens. Kataloget markerer den som copyleft, så et punkt om kildekode-tilbud lander på projektets tjekliste i konteksterne Distribueret binær og Blandet.
Et LGPL-linking-punkt lander i Bibliotek eller SDK, Distribueret binær og Blandet. Begge venter på, at en person bekræfter dem, og publicering er spærret, indtil det sker.
Intet her afgør din linking-model eller efterser dit device-build. Sender du en binær fil til en app-butik, så læs /docs/mobile-app-licenses om distributionskontekst og in-app-notitsskærmen.
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.
