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.
På denne side
Hvad den gør
LGPL er GPL med én stor lempelse: et program må bruge biblioteket uden selv at blive GPL. Prisen er udskiftelighed. Den, der modtager dit program, skal kunne skifte biblioteket ud med sit eget build, og det står i afsnit 6. Copyleft betyder her, at licensen kræver, at ændringer i selve biblioteket kommer ud igen under samme licens, mens din egen adskilte applikationskode ikke bliver berørt. Du møder LGPL-2.1 i glibc, GTK og kernen i FFmpeg, så den kommer typisk som et kompileret native-bibliotek og ikke som kildekode, du retter i.
Detaljer
Hvordan dit produkt når frem til folk, afgør alt her. En hostet tjeneste, der aldrig udleverer en binær fil, har ingen kildekode-pligt, for LGPL har ingen netværksklausul. Sender du en desktop-app, en mobilapp, firmware eller et SDK, som andre udviklere bygger ind, opstår der to pligter. Bibliotekets kildekode skal kunne skaffes, og modtageren skal kunne genlinke dit program mod en ændret udgave. Statisk linking, hvor biblioteket er kompileret ind i din binære fil, er det, der gør den anden pligt dyr. Jurister er stadig uenige om, hvorvidt dynamisk linking overhovedet skaber et samlet værk. Tag en sag, hvor der er meget på spil, til en jurist.
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å.
Hvad LGPL-2.1-or-later kræver, når I sender kode ud
Når du distribuerer en binær fil, der indeholder LGPL-2.1-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 linking-betingelsen, når biblioteket indlæses ved kørsel som en separat fil, for så kan brugeren udskifte den fil med sit eget build.
Med statisk linking opfylder du den kun, når du også udleverer dine objektfiler eller en anden mekanisme, der lader brugeren genlinke programmet mod et ændret bibliotek.
Du har dækket kildekode-pligten, når enhver modtager af din binære fil kan få bibliotekets fulde kildekode. En URL, du udgiver, eller et skriftligt tilbud, der følger med download, fungerer begge.
Du er på den rigtige side af afsnit 6, når dine egne slutbrugervilkår ikke forbyder den reverse engineering, der skal til for at fejlfinde en ændret udgave af biblioteket.
Du har styr på dine egne ændringer, når enhver rettelse, du har lavet i selve biblioteket, udgives under LGPL, når du distribuerer det, uanset om du har ændret dets grænseflade.
De pligter, LGPL-2.1-or-later navngiver
Notitsen følger stadig med kopien. Oven i det navngiver LGPL-2.1-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å.
Det skal du være opmærksom på
- Teams statisk-linker et LGPL-bibliotek ind i en mobilapp og sender intet andet med. Skift enten til et dynamisk framework, eller udgiv de objektfiler, der lader en bruger genlinke.
- Teams læser svag copyleft som slet ingen pligter. Svag betyder, at pligten stopper ved biblioteket, så find bibliotekets kildekode-placering, før du sender, ikke bagefter.
- En standard slutbrugeraftale forbyder reverse engineering, hvilket støder sammen med afsnit 6. Tag LGPL-delene ud af den formulering, før juristen godkender aftalen.
- Nogen retter biblioteket i en vendored kopi og glemmer, at det er en ændring i LGPL-kode. Registrér den kopi som en ændret komponent, og udgiv rettelsen.
Hvad GNU LGPL v2.1 eller senere ikke gør
Søgeresultater flader ofte GNU LGPL v2.1 eller senere ud til et slogan. Dette er de sædvanlige fejllæsninger. LGPL-2.1-or-later er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.
- LGPL-2.1-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-2.1-or-later adskiller sig fra nærliggende licenser
Disse licenser forveksles ofte med LGPL-2.1-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-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.
- LGPL-2.1-only
- LGPL-2.1-only er bibliotek-copyleft låst til 2.1. Brugere skal kunne skifte biblioteket. Ingen opgradering til LGPL-3.0.
- LGPL-3.0-or-later
- Svag copyleft skrevet som et tillæg til GPLv3. Forbrugerenheder skylder også installationsinformation til et ændret bibliotek.
- 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.
Ofte stillede spørgsmål om GNU LGPL v2.1 eller senere
Svar på almindelige spørgsmål om, hvad GNU LGPL v2.1 eller senere kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.
Hvad er GNU LGPL v2.1 eller senere?
LGPL er GPL med én stor lempelse: et program må bruge biblioteket uden selv at blive GPL. Prisen er udskiftelighed. Den, der modtager dit program, skal kunne skifte biblioteket ud med sit eget build, og det står i afsnit 6. Copyleft betyder her, at licensen kræver, at ændringer i selve biblioteket kommer ud igen under samme licens, mens din egen adskilte applikationskode ikke bliver berørt. Du møder LGPL-2.1 i glibc, GTK og kernen i FFmpeg, så den kommer typisk som et kompileret native-bibliotek og ikke som kildekode, du retter i.
Hvad kræver LGPL-2.1-or-later, når I sender et produkt ud?
Du opfylder linking-betingelsen, når biblioteket indlæses ved kørsel som en separat fil, for så kan brugeren udskifte den fil med sit eget build. Med statisk linking opfylder du den kun, når du også udleverer dine objektfiler eller en anden mekanisme, der lader brugeren genlinke programmet mod et ændret bibliotek. Du har dækket kildekode-pligten, når enhver modtager af din binære fil kan få bibliotekets fulde kildekode. En URL, du udgiver, eller et skriftligt tilbud, der følger med download, fungerer begge. Du er på den rigtige side af afsnit 6, når dine egne slutbrugervilkår ikke forbyder den reverse engineering, der skal til for at fejlfinde en ændret udgave af biblioteket. Du har styr på dine egne ændringer, når enhver rettelse, du har lavet i selve biblioteket, udgives under LGPL, når du distribuerer det, uanset om du har ændret dets grænseflade.
Udløser det ekstra pligter at hoste et produkt, der bruger LGPL-2.1-or-later?
Hosting alene udløser som regel ikke kildekodepligten for LGPL-2.1-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-2.1-or-later?
LGPL-2.1-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-2.1-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-2.1-or-later sig fra GNU LGPL v2.1 kun?
LGPL-2.1-or-later kræver dette: 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. GNU LGPL v2.1 kun kræver dette: LGPL-2.1-only er bibliotek-copyleft låst til 2.1. Brugere skal kunne skifte biblioteket. Ingen opgradering til LGPL-3.0. Åbn GNU LGPL v2.1 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-2.1-or-later til en køber?
Kataloget markerer LGPL-2.1 som copyleft, så SourceTrust lægger et punkt om kildekode-tilbud på projektets tjekliste, når projektet sender en Distribueret binær ud eller står som Blandet. Et LGPL-linking-punkt kommer til i konteksterne Bibliotek eller SDK, Distribueret binær og Blandet. Et rent SaaS-projekt ser ingen af dem. Ingen af punkterne bliver sat for dig: en på dit team bekræfter hvert punkt, og publicering er spærret, indtil det sker. Markeringen gemmes pr. forpligtelse på komponenten. Hvem der godkendte komponenten, og hvornår, registreres på komponentens godkendelsesbeslutning. SourceTrust kontrollerer ikke, at du sendte kildekoden eller byggede genlink-vejen.
Hvor registrerer jeg LGPL-2.1-or-later til en køber?
Kataloget markerer LGPL-2.1 som copyleft, så SourceTrust lægger et punkt om kildekode-tilbud på projektets tjekliste, når projektet sender en Distribueret binær ud eller står som Blandet. Et LGPL-linking-punkt kommer til i konteksterne Bibliotek eller SDK, Distribueret binær og Blandet.
Et rent SaaS-projekt ser ingen af dem. Ingen af punkterne bliver sat for dig: en på dit team bekræfter hvert punkt, og publicering er spærret, indtil det sker.
Markeringen gemmes pr. forpligtelse på komponenten. Hvem der godkendte komponenten, og hvornår, registreres på komponentens godkendelsesbeslutning.
SourceTrust kontrollerer ikke, at du sendte kildekoden eller byggede genlink-vejen. Læs /docs/reviewing-component om gennemgangsforløbet.
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.