Boost-licensen, ikke Business Source License. Tilladelig, og den beder udtrykkeligt ikke om en notits inde i kompilerede binære filer.
På denne side
Hvad den gør
BSL-1.0 er Boost Software License, som bruges af Boost C++-bibliotekerne og af projekter, der følger Boost-konventioner. Forveksl den ikke med Business Source License (BUSL-1.1), som er en source available-licens med reelle begrænsninger på produktionsbrug. Udviklere skriver BSL om begge. Boost selv er tilladelig: brug den kommercielt, ændr den, hold dine ændringer lukkede. Én ting er usædvanlig. Licensen kræver notitsen ved kildekode-distributioner og udtrykkeligt ikke ved kopier, der udelukkende er maskinlæsbar objektkode.
Detaljer
To ting følger af den undtagelse. Sender du kun kompilerede binære filer ud, beder licensen selv ikke om noget, hvilket er sjældent og værd at vide. Kataloget registrerer stadig Boost som en notitslicens, så en komponent under den skal have licenstekst, før den tæller som live på din side. Det er bevidst: din attestation-side er et oplysningsdokument til købere, ikke en beregning af minimumspligter. Navnesammenfaldet med BUSL er den anden reelle risiko, fordi det giver forkerte svar i indkøbs-spørgeskemaer.
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.
Hvad BSL-1.0 kræver, når I sender kode ud
Når en kopi, der indeholder BSL-1.0-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, når du distribuerer kildekode, herunder C++-headere, og Boost-licensnotitsen er med i den kildekode.
Du har ikke mere at gøre efter licensen, når dine kopier udelukkende er kompileret objektkode, fordi notitsbetingelsen udtrykkeligt undtager det tilfælde.
Du står solidt ved alligevel at have Boost med i din notitsfil. Det gør de fleste leverandører, det koster én linje, og købere forventer hele inventaret.
Du har svaret rigtigt i et indkøbs-spørgeskema, når dine papirer siger Boost Software License 1.0 og ikke Business Source License.
Du har samme position, efter du har ændret koden, og dine egne ændringer må forblive lukkede. Boost har ingen gensidig pligt af nogen art.
De pligter, BSL-1.0 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.
Det skal du være opmærksom på
- At skrive BSL, når du mener BUSL-1.1. Den ene er tilladelig, og den anden begrænser produktionsbrug, indtil vilkårene skifter på en fastsat dato.
- At læse undtagelsen for objektkode som lov til at udelade Boost fra din oplysningsliste. Licensen og din køber stiller to forskellige spørgsmål.
- At forvente en patenttilladelse som den i Apache-2.0. Boost nævner ikke patenter, så en udtrykkelig tilladelse er ikke en del af det, du får.
Hvad Boost Software License 1.0 ikke gør
Søgeresultater flader ofte Boost Software License 1.0 ud til et slogan. Dette er de sædvanlige fejllæsninger. BSL-1.0 er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.
- Boost Software License 1.0 kræver ikke, at du udgiver din egen kildekode. At kombinere den med lukket kode er selve pointen med tilladelsen.
- Boost Software License 1.0 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 BSL-1.0 adskiller sig fra nærliggende licenser
Disse licenser forveksles ofte med BSL-1.0, 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.
- BSL-1.0
- Boost-licensen, ikke Business Source License. Tilladelig, og den beder udtrykkeligt ikke om en notits inde i kompilerede binære filer.
- 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.
- 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.
- BUSL-1.1
- Source available, ikke open source. Hver version skifter til en åben licens på sin egen Change Date, typisk fire år efter udgivelsen.
Ofte stillede spørgsmål om Boost Software License 1.0
Svar på almindelige spørgsmål om, hvad Boost Software License 1.0 kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.
Hvad er Boost Software License 1.0?
BSL-1.0 er Boost Software License, som bruges af Boost C++-bibliotekerne og af projekter, der følger Boost-konventioner. Forveksl den ikke med Business Source License (BUSL-1.1), som er en source available-licens med reelle begrænsninger på produktionsbrug. Udviklere skriver BSL om begge. Boost selv er tilladelig: brug den kommercielt, ændr den, hold dine ændringer lukkede. Én ting er usædvanlig. Licensen kræver notitsen ved kildekode-distributioner og udtrykkeligt ikke ved kopier, der udelukkende er maskinlæsbar objektkode.
Hvad kræver BSL-1.0, når I sender et produkt ud?
Du opfylder vilkårene, når du distribuerer kildekode, herunder C++-headere, og Boost-licensnotitsen er med i den kildekode. Du har ikke mere at gøre efter licensen, når dine kopier udelukkende er kompileret objektkode, fordi notitsbetingelsen udtrykkeligt undtager det tilfælde. Du står solidt ved alligevel at have Boost med i din notitsfil. Det gør de fleste leverandører, det koster én linje, og købere forventer hele inventaret. Du har svaret rigtigt i et indkøbs-spørgeskema, når dine papirer siger Boost Software License 1.0 og ikke Business Source License. Du har samme position, efter du har ændret koden, og dine egne ændringer må forblive lukkede. Boost har ingen gensidig pligt af nogen art.
Kræver BSL-1.0, 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 BSL-1.0 i et produkt, jeg sender ud?
Kreditering for BSL-1.0 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 BSL-1.0?
Nej. BSL-1.0 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 BSL-1.0-afhængigheder med?
Ja. Betingelsen følger koden, ikke den pakke I valgte ved navn. Hvis lockfilen har trukket BSL-1.0 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 BSL-1.0 sig fra MIT-licensen?
BSL-1.0 kræver dette: Boost-licensen, ikke Business Source License. Tilladelig, og den beder udtrykkeligt ikke om en notits inde i kompilerede binære filer. 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 BSL-1.0 til en køber?
Kataloget registrerer BSL-1.0 som en notitslicens, så en komponent under den skal have licenstekst, før den tæller som live på din side. Det gælder, selvom licensen lader dig springe notitsen over i objektkode. Auto-hentningen leverer normalt teksten fra den udgivne artefakt. Pakker, der kopierer en håndfuld Boost-headere ind, sender ofte ingen egen licensfil med. Et not found-resultat er derfor almindeligt, og så indsætter du selv teksten.
Hvor registrerer jeg BSL-1.0 til en køber?
Kataloget registrerer BSL-1.0 som en notitslicens, så en komponent under den skal have licenstekst, før den tæller som live på din side. Det gælder, selvom licensen lader dig springe notitsen over i objektkode.
Auto-hentningen leverer normalt teksten fra den udgivne artefakt. Pakker, der kopierer en håndfuld Boost-headere ind, sender ofte ingen egen licensfil med.
Et not found-resultat er derfor almindeligt, og så indsætter du selv teksten. 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.
