LGPL-2.1-only er bibliotek-copyleft låst til 2.1. Brugere skal kunne skifte biblioteket. Ingen opgradering til LGPL-3.0.
På denne side
Hvad den gør
GNU LGPL v2.1 only er bibliotek-copyleft uden et 'or later'-token. Et program må bruge biblioteket uden at blive GPL, hvis modtagere kan skifte til eget build. Det står i afsnit 6. Statisk linking gør det dyrt. SPDX listede den tidligere som LGPL-2.1. Only-formen kan ikke læses som LGPL-3.0, så GPLv3-patentvilkår og Installation Information kommer ikke med denne tilladelse. Du møder stadig 2.1-only-headere på ældre native-biblioteker, også når glibc selv er or-later.
Detaljer
En hostet tjeneste, der aldrig udleverer en binær fil, har ingen kildekode-pligt. Sender du en desktop-app, en mobilapp, firmware eller et SDK, opstår der to pligter: bibliotekets kildekode og en genlink-vej. Fordi tilladelsen er låst til 2.1, kan en modtager ikke vælge LGPL-3.0 for at få Installation Information til User Products. Behandl en pakke, der angiver only, men leverer or-later-tekst, som et mismatch.
Fordele
- Du kan linke biblioteket fra lukket kode på den måde, afsnit 6 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 biblioteket.
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.
Gå til LGPL-3.0
LGPL-2.1-only låser version 2.1. Modtagere kan ikke vælge LGPL-3.0, så GPLv3-patent- og Installation Information-vilkår kommer ikke med denne tilladelse.
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-only kræver, når I sender kode ud
Når du distribuerer en binær fil, der indeholder LGPL-2.1-only-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 LGPL-2.1 afsnit 6, når biblioteket indlæses ved kørsel som en separat fil, så brugeren kan udskifte den fil med sit eget 2.1-licenserede build.
Med statisk linking opfylder du den kun, når du også udleverer objektfiler eller en anden mekanisme, der lader brugeren genlinke mod et ændret 2.1-bibliotek.
Du har dækket kildekode-pligten, når enhver modtager af din binære fil kan få bibliotekets fulde kildekode under LGPL-2.1-only. En URL eller et skriftligt tilbud, der følger med download, fungerer begge.
Du bliver på version 2.1, når headere, SPDX og den medsendte tekst alle siger only, så ingen behandler dette som en vej til LGPL-3.0.
Du er på den rigtige side af afsnit 6, når dine slutbrugervilkår ikke forbyder den reverse engineering, der skal til for at fejlfinde en ændret udgave af biblioteket.
De pligter, LGPL-2.1-only navngiver
Notitsen følger stadig med kopien. Oven i det navngiver LGPL-2.1-only 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å
- At registrere glibc som LGPL-2.1-only, fordi SPDX tidligere sagde LGPL-2.1. Læs headeren. Mange GNU-biblioteker er or-later.
- At forvente Installation Information, fordi du sendte biblioteket ud i en tv-boks. Den pligt kommer fra GPLv3 via LGPL-3.0, ikke fra 2.1-only.
- Teams statisk-linker biblioteket ind i en mobilapp og sender intet andet med. Skift til et dynamisk framework, eller udgiv de objektfiler, der lader en bruger genlinke.
Hvad GNU LGPL v2.1 kun ikke gør
Søgeresultater flader ofte GNU LGPL v2.1 kun ud til et slogan. Dette er de sædvanlige fejllæsninger. LGPL-2.1-only er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.
- LGPL-2.1-only tvinger dig ikke til at åbne hele din applikation. Den gensidige pligt bliver på biblioteket, under version 2.1.
- Den indeholder ikke et 'or later'-token. Modtagere kan ikke vælge LGPL-3.0, og Installation Information fra GPLv3 følger ikke med.
Hvordan LGPL-2.1-only adskiller sig fra nærliggende licenser
Disse licenser forveksles ofte med LGPL-2.1-only, 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-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-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-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.
- 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.
Ofte stillede spørgsmål om GNU LGPL v2.1 kun
Svar på almindelige spørgsmål om, hvad GNU LGPL v2.1 kun kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.
Hvad er GNU LGPL v2.1 kun?
GNU LGPL v2.1 only er bibliotek-copyleft uden et 'or later'-token. Et program må bruge biblioteket uden at blive GPL, hvis modtagere kan skifte til eget build. Det står i afsnit 6. Statisk linking gør det dyrt. SPDX listede den tidligere som LGPL-2.1. Only-formen kan ikke læses som LGPL-3.0, så GPLv3-patentvilkår og Installation Information kommer ikke med denne tilladelse. Du møder stadig 2.1-only-headere på ældre native-biblioteker, også når glibc selv er or-later.
Hvad kræver LGPL-2.1-only, når I sender et produkt ud?
Du opfylder LGPL-2.1 afsnit 6, når biblioteket indlæses ved kørsel som en separat fil, så brugeren kan udskifte den fil med sit eget 2.1-licenserede build. Med statisk linking opfylder du den kun, når du også udleverer objektfiler eller en anden mekanisme, der lader brugeren genlinke mod et ændret 2.1-bibliotek. Du har dækket kildekode-pligten, når enhver modtager af din binære fil kan få bibliotekets fulde kildekode under LGPL-2.1-only. En URL eller et skriftligt tilbud, der følger med download, fungerer begge. Du bliver på version 2.1, når headere, SPDX og den medsendte tekst alle siger only, så ingen behandler dette som en vej til LGPL-3.0. Du er på den rigtige side af afsnit 6, når dine slutbrugervilkår ikke forbyder den reverse engineering, der skal til for at fejlfinde en ændret udgave af biblioteket.
Udløser det ekstra pligter at hoste et produkt, der bruger LGPL-2.1-only?
Hosting alene udløser som regel ikke kildekodepligten for LGPL-2.1-only. 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-only?
LGPL-2.1-only 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-only?
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-only sig fra GNU LGPL v2.1 eller senere?
LGPL-2.1-only 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. GNU LGPL v2.1 eller senere 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. Åbn GNU LGPL v2.1 eller senere-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-only til en køber?
Kataloget markerer LGPL-2.1-only som copyleft, så et punkt om kildekode-tilbud dukker op, når projektet sender en Distribueret binær ud eller står som Blandet. Et LGPL-linking-punkt kommer til i Bibliotek eller SDK, Distribueret binær og Blandet. Et rent SaaS-projekt ser ingen af dem. Hentningen sammenligner den medsendte tekst med det angivne id, så en or-later-tekst under et only-id lander som mismatch. SourceTrust kontrollerer ikke, at du sendte kildekoden eller byggede genlink-vejen.
Hvor registrerer jeg LGPL-2.1-only til en køber?
Kataloget markerer LGPL-2.1-only som copyleft, så et punkt om kildekode-tilbud dukker op, når projektet sender en Distribueret binær ud eller står som Blandet. Et LGPL-linking-punkt kommer til i Bibliotek eller SDK, Distribueret binær og Blandet.
Et rent SaaS-projekt ser ingen af dem. Hentningen sammenligner den medsendte tekst med det angivne id, så en or-later-tekst under et only-id lander som mismatch.
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.
