Tilladelig og indbygget i spil, firmware og mobilapps. Tre betingelser: hævd ikke at du skrev den, markér ændrede versioner, behold notitsen i kildekoden.
På denne side
Hvad den gør
zlib-licensen er en kort, tilladelig licens med tre betingelser, der er værd at kende. Giv ikke et forkert billede af softwarens oprindelse, så du må ikke hævde, at du skrev originalen. Markér ændrede kildekode-versioner tydeligt som ændrede, så ingen forveksler din rettede kopi med upstream. Behold notitsen i kildekode-distributioner. Licensen kræver ikke en notits inde i kompileret objektkode, selvom de fleste leverandører tager en med alligevel. zlib selv og mange spilmotorer bruger den, og libpng har sin egen, nært beslægtede licens.
Detaljer
Det er en af de få tilladelige licenser, hvor det at ændre koden tilføjer en betingelse. Det er almindeligt at lægge en rettet zlib ind i et firmware-image eller et spil-build, og at markere den som ændret er det trin, teams overser. Der er også en id-fælde. Varianten zlib-acknowledgement beder om en anerkendelse i din produktdokumentation, og den er et separat SPDX-id med sin egen katalogpost. Tjek hvilken af dem pakken angiver, før du beslutter, at der ikke er noget at gøre.
Fordele
- Nem at lægge ind i et lukket, betalt produkt. Procurement har set denne familie hundredvis af gange.
- Ingen copyleft på dine egne filer. Du holder din kildekode privat.
Ulemper
- Notitspligten er nem at overse i et desktop-, mobil- eller container-build. En webside erstatter ikke notitser inde i artefakten.
- Købere, der vil have en udtrykkelig patenttilladelse, vil bede dig foretrække Apache-2.0 frem for en kort MIT-agtig tekst.
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.
Underlicens
Du må lægge koden ind under dine egne produktvilkår, så længe du stadig opfylder denne licens' betingelser.
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.
Patenttilladelse
Teksten giver ikke patenter. Hvis købere vil have en udtrykkelig patenttilladelse, er Apache-2.0 det sædvanlige alternativ.
Forpligtelser
Medtag copyright
Behold copyright-linjen i hver kopi eller væsentlig del, du distribuerer.
Medtag licens
Behold licensteksten i hver kopi eller væsentlig del, du distribuerer. En webside erstatter ikke notitser inde i en udsendt artefakt.
Angiv ændringer
Markér ændrede filer, så de ikke fremstår som originalen.
Hvad Zlib kræver, når I sender kode ud
Når en kopi, der indeholder Zlib-kode, forlader virksomheden, er tilladelsen bred, og papirarbejdet er nemt at overse. Distribution betyder her en installer, en mobil binær fil, et container-image eller et SDK et andet team bygger ind. Arbejd listen op imod den artefakt, du rent faktisk giver videre, ikke op imod en README. En hostet tjeneste, der aldrig giver en kopi ud, hører stadig hjemme på registreringen, men notitspligten udløses først, når der findes en kopi.
Du opfylder vilkårene for en uændret kopi, når notitsen bliver i den kildekode, du distribuerer. Intet i dit produkt må hævde koden som dit eget værk.
Du opfylder betingelsen om ændrede versioner, når din rettede kopi tydeligt oplyser, at den er ændret, i kildekoden og i versionsstrengen.
Du er færdig for en hostet tjeneste, når komponenten er registreret. zlib har ingen netværksudløser og beder aldrig om, at du udgiver din egen kildekode.
Du opfylder vilkårene for en udsendt binær fil, så snart notitsen står i din licensfil. Licensen kræver den ikke engang i objektkode.
Du har læst id'et rigtigt, når du ved, om pakken angiver Zlib eller zlib-acknowledgement, varianten der også vil have en omtale i din dokumentation.
De pligter, Zlib navngiver
Selve licensteksten er kort. Dette er de navngivne betingelser. De følger koden, også filer I kopierer ind i jeres eget repository og transitive pakker i lockfilen.
Medtag copyright
Behold copyright-linjen i hver kopi eller væsentlig del, du distribuerer.
Medtag licens
Behold licensteksten i hver kopi eller væsentlig del, du distribuerer. En webside erstatter ikke notitser inde i en udsendt artefakt.
Angiv ændringer
Markér ændrede filer, så de ikke fremstår som originalen.
Det skal du være opmærksom på
- At sende en rettet zlib ud uden at markere den som ændret. Det er en af kun to ting, licensen faktisk beder om ud over at beholde notitsen.
- At antage at acknowledgement-varianten og grundlicensen er det samme. Det er separate SPDX-id'er med forskellige pligter i din dokumentation.
- At beslutte at et komprimeringsbibliotek er for lille til at komme på listen. Købere læser hele inventaret, og zlib ligger inde i næsten hver binær fil, I har sendt ud.
Hvad zlib-licensen ikke gør
Søgeresultater flader ofte zlib-licensen ud til et slogan. Dette er de sædvanlige fejllæsninger. Zlib er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.
- zlib-licensen kræver ikke, at du udgiver din egen kildekode. At kombinere den med lukket kode er selve pointen med tilladelsen.
- zlib-licensen betyder ikke "ingen forpligtelser." Copyright-linjen og licensteksten skal stadig følge med kopier, du giver videre.
- Det er ikke en patentlicens, medmindre teksten siger det. MIT-familiens tilladelser nævner ikke patenter.
Hvordan Zlib adskiller sig fra nærliggende licenser
Disse licenser forveksles ofte med Zlib, 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.
- Zlib
- Tilladelig og indbygget i spil, firmware og mobilapps. Tre betingelser: hævd ikke at du skrev den, markér ændrede versioner, behold notitsen i kildekoden.
- MIT
- MIT lader dig sende koden med i et lukket, betalt produkt. Den ene betingelse er, at copyright-linjen og licensteksten følger med hver kopi.
- BSL-1.0
- Boost-licensen, ikke Business Source License. Tilladelig, og den beder udtrykkeligt ikke om en notits inde i kompilerede binære filer.
- MPL-2.0
- Filbaseret copyleft. MPL-filerne forbliver åbne, når du sender en binær fil ud, ændret eller ej. Dine egne adskilte filer er dine.
Ofte stillede spørgsmål om zlib-licensen
Svar på almindelige spørgsmål om, hvad zlib-licensen kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.
Hvad er zlib-licensen?
zlib-licensen er en kort, tilladelig licens med tre betingelser, der er værd at kende. Giv ikke et forkert billede af softwarens oprindelse, så du må ikke hævde, at du skrev originalen. Markér ændrede kildekode-versioner tydeligt som ændrede, så ingen forveksler din rettede kopi med upstream. Behold notitsen i kildekode-distributioner. Licensen kræver ikke en notits inde i kompileret objektkode, selvom de fleste leverandører tager en med alligevel. zlib selv og mange spilmotorer bruger den, og libpng har sin egen, nært beslægtede licens.
Hvad kræver Zlib, når I sender et produkt ud?
Du opfylder vilkårene for en uændret kopi, når notitsen bliver i den kildekode, du distribuerer. Intet i dit produkt må hævde koden som dit eget værk. Du opfylder betingelsen om ændrede versioner, når din rettede kopi tydeligt oplyser, at den er ændret, i kildekoden og i versionsstrengen. Du er færdig for en hostet tjeneste, når komponenten er registreret. zlib har ingen netværksudløser og beder aldrig om, at du udgiver din egen kildekode. Du opfylder vilkårene for en udsendt binær fil, så snart notitsen står i din licensfil. Licensen kræver den ikke engang i objektkode. Du har læst id'et rigtigt, når du ved, om pakken angiver Zlib eller zlib-acknowledgement, varianten der også vil have en omtale i din dokumentation.
Kræver Zlib, at jeg åbner min egen kildekode?
Det er ikke en patentlicens, medmindre teksten siger det. MIT-familiens tilladelser nævner ikke patenter.
Hvordan krediterer jeg Zlib i et produkt, jeg sender ud?
Kreditering for Zlib betyder, at copyright-linjen og licensteksten følger med hver kopi, en modtager rent faktisk får. Det kan være en om-skærm, en licensfil inde i installeren eller en notits i container-imaget. En offentlig side hjælper en køber med at revidere lageret. Den erstatter ikke notitser inde i artefakten. Hvis I har kopieret filer ind i jeres eget repository, skal headeren på de filer stadig blive.
Er en notits på en hjemmeside nok til Zlib?
Nej. Zlib taler om kopier. En offentlig attestation-side er den ærlige liste til procurement. Betingelsen er opfyldt, når notitserne ligger i det materiale, I giver videre. Læg dem i installeren, om-skærmen eller en licensfil inde i den binære fil, og hold derefter de samme tekster på siden.
Tæller transitive Zlib-afhængigheder med?
Ja. Betingelsen følger koden, ikke den pakke I valgte ved navn. Hvis lockfilen har trukket Zlib med transitivt, og I distribuerer det træ, følger de notitser også med. Kun at liste direkte afhængigheder er den måde, teams misser pligten.
Hvordan adskiller Zlib sig fra MIT-licensen?
Zlib kræver dette: Tilladelig og indbygget i spil, firmware og mobilapps. Tre betingelser: hævd ikke at du skrev den, markér ændrede versioner, behold notitsen i kildekoden. MIT-licensen kræver dette: MIT lader dig sende koden med i et lukket, betalt produkt. Den ene betingelse er, at copyright-linjen og licensteksten følger med hver kopi. Åbn MIT-licensen-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 Zlib til en køber?
En rettet kopi er det interessante tilfælde her. Når den udpakkede tekst afviger fra referencen for det angivne id, lander resultatet som modified eller mismatch i stedet for at blive udfyldt. Komponenten venter så på, at et menneske accepterer teksten. Det er dér, du tjekker, om det er en ændret version, og om den er markeret som sådan. zlib er en notitslicens i kataloget, så teksten skal være der, før komponenten tæller som live på din side.
Hvor registrerer jeg Zlib til en køber?
En rettet kopi er det interessante tilfælde her. Når den udpakkede tekst afviger fra referencen for det angivne id, lander resultatet som modified eller mismatch i stedet for at blive udfyldt.
Komponenten venter så på, at et menneske accepterer teksten. Det er dér, du tjekker, om det er en ændret version, og om den er markeret som sådan. zlib er en notitslicens i kataloget, så teksten skal være der, før komponenten tæller som live på din side.
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.