Spring til hovedindhold
SourceTrust
Se andre licenser

OpenSSL

OpenSSL-licensen

OpenSSL-vilkårene før 3.0 er to BSD-lignende licenser med advertising-klausuler, og de er GPL-inkompatible. OpenSSL 3.0 skiftede til Apache-2.0.

På denne side

Hvad den gør

OpenSSL-licensen er licenseringen af OpenSSL før 3.0, og den er to tekster på én gang: OpenSSL License og den oprindelige SSLeay License, begge skrevet i BSD-4-Clause-stil. Tilladelig i almindelig forstand, så du kan sende koden ud inde i et lukket produkt. Begge tekster bærer en advertising-klausul. Markedsføringsmateriale, der nævner funktioner i softwaren, skal anerkende OpenSSL Project, og SSLeay-halvdelen beder om kredit til Eric Young. OpenSSL 3.0 og senere skiftede til Apache-2.0, som dropper alt dette.

Detaljer

Advertising-klausulerne gør denne licens inkompatibel med GPL. Det er grunden til, at tusindvis af GPL-projekter har en udtrykkelig OpenSSL-undtagelse i deres egne headere. Kombinerer dit produkt OpenSSL-licenseret kode med GPL-kode, og der ingen undtagelse er skrevet ned, er det et reelt problem at løse, ikke et papirarbejde. Den mindre klausul gælder stadig: din markedsføring skal kreditere OpenSSL Project, når den nævner krypto-funktionerne. Tjek versionen først, for 3.0 og senere er Apache-2.0, og så gælder intet af dette.

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.

Hvad OpenSSL kræver, når I sender kode ud

Når en kopi, der indeholder OpenSSL-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.

  1. Du opfylder notitsbetingelsen, når begge tekster, OpenSSL License og SSLeay License, følger med hver kopi, du distribuerer.

  2. Du opfylder advertising-klausulerne, når materiale, der nævner softwarens funktioner, anerkender OpenSSL Project og krediterer Eric Young.

  3. Du har afklaret GPL-spørgsmålet, når enten ingen GPL-kode ligger i samme produkt, eller GPL-komponenten har en skriftlig OpenSSL-undtagelse.

  4. Du har måske slet ingen pligt her, når komponenten i virkeligheden er OpenSSL 3.0 eller senere, som udgives under Apache-2.0. Bekræft versionen, før du kopierer den gamle tekst.

De pligter, OpenSSL 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.

Krediter

Reklamemateriale skal indeholde den anerkendelse, licensen nævner.

Det skal du være opmærksom på

  • Teams kopierer kun OpenSSL-halvdelen af teksten. Pakken bærer to licenser, og SSLeay-halvdelen har sin egen copyright-linje og sin egen advertising-klausul.
  • GPL-inkompatibiliteten dukker op under en kundes gennemgang i stedet for din egen. Søg tidligt i dit inventar efter GPL-komponenter i det samme produkt.
  • Et gammelt OpenSSL-id bliver stående på en komponent, der siden er skiftet til Apache-2.0. Bekræft den udsendte version, og hent så licensteksten igen.
  • Advertising-klausulen læses som kun at dække trykte annoncer. Behandl også en funktionsside, et udgivelsesopslag eller en butikstekst som markedsføringsmateriale.

Hvad OpenSSL-licensen ikke gør

Søgeresultater flader ofte OpenSSL-licensen ud til et slogan. Dette er de sædvanlige fejllæsninger. OpenSSL er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.

  • OpenSSL-licensen kræver ikke, at du udgiver din egen kildekode. At kombinere den med lukket kode er selve pointen med tilladelsen.
  • OpenSSL-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 OpenSSL adskiller sig fra nærliggende licenser

Disse licenser forveksles ofte med OpenSSL, 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.

OpenSSL
OpenSSL-vilkårene før 3.0 er to BSD-lignende licenser med advertising-klausuler, og de er GPL-inkompatible. OpenSSL 3.0 skiftede til Apache-2.0.
Apache-2.0
Tilladelig som MIT, plus en udtrykkelig patenttilladelse. Hagen er NOTICE-filen: den skal med inde i de binære filer, du sender ud.
BSD-3-Clause
Tilladelig som MIT, med én ekstra regel: du må ikke bruge forfatternes navne til at promovere dit produkt. Notitser følger med kildekode og binære filer.
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 OpenSSL-licensen

Svar på almindelige spørgsmål om, hvad OpenSSL-licensen kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.

Hvad er OpenSSL-licensen?

OpenSSL-licensen er licenseringen af OpenSSL før 3.0, og den er to tekster på én gang: OpenSSL License og den oprindelige SSLeay License, begge skrevet i BSD-4-Clause-stil. Tilladelig i almindelig forstand, så du kan sende koden ud inde i et lukket produkt. Begge tekster bærer en advertising-klausul. Markedsføringsmateriale, der nævner funktioner i softwaren, skal anerkende OpenSSL Project, og SSLeay-halvdelen beder om kredit til Eric Young. OpenSSL 3.0 og senere skiftede til Apache-2.0, som dropper alt dette.

Hvad kræver OpenSSL, når I sender et produkt ud?

Du opfylder notitsbetingelsen, når begge tekster, OpenSSL License og SSLeay License, følger med hver kopi, du distribuerer. Du opfylder advertising-klausulerne, når materiale, der nævner softwarens funktioner, anerkender OpenSSL Project og krediterer Eric Young. Du har afklaret GPL-spørgsmålet, når enten ingen GPL-kode ligger i samme produkt, eller GPL-komponenten har en skriftlig OpenSSL-undtagelse. Du har måske slet ingen pligt her, når komponenten i virkeligheden er OpenSSL 3.0 eller senere, som udgives under Apache-2.0. Bekræft versionen, før du kopierer den gamle tekst.

Kræver OpenSSL, 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 OpenSSL i et produkt, jeg sender ud?

Kreditering for OpenSSL 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 OpenSSL?

Nej. OpenSSL 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 OpenSSL-afhængigheder med?

Ja. Betingelsen følger koden, ikke den pakke I valgte ved navn. Hvis lockfilen har trukket OpenSSL 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 OpenSSL sig fra Apache-licensen 2.0?

OpenSSL kræver dette: OpenSSL-vilkårene før 3.0 er to BSD-lignende licenser med advertising-klausuler, og de er GPL-inkompatible. OpenSSL 3.0 skiftede til Apache-2.0. Apache-licensen 2.0 kræver dette: Tilladelig som MIT, plus en udtrykkelig patenttilladelse. Hagen er NOTICE-filen: den skal med inde i de binære filer, du sender ud. Åbn Apache-licensen 2.0-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 OpenSSL til en køber?

SourceTrust henter den udgivne artefakt, pakker licensfilerne ud og sammenligner dem med det angivne SPDX-id. En pakke, der bærer både OpenSSL- og SSLeay-teksten, beholder begge på komponentens registrering. Den registrering er det, attestation-siden viser, og det, hver eksportfil gentager, dannet ud fra det frosne, offentliggjorte øjebliksbillede og ikke live-data. SourceTrust fortæller dig ikke, om to licenser i dit produkt passer sammen, så GPL-spørgsmålet forbliver menneskeligt.

Hvor registrerer jeg OpenSSL til en køber?

SourceTrust henter den udgivne artefakt, pakker licensfilerne ud og sammenligner dem med det angivne SPDX-id. En pakke, der bærer både OpenSSL- og SSLeay-teksten, beholder begge på komponentens registrering.

Den registrering er det, attestation-siden viser, og det, hver eksportfil gentager, dannet ud fra det frosne, offentliggjorte øjebliksbillede og ikke live-data. SourceTrust fortæller dig ikke, om to licenser i dit produkt passer sammen, så GPL-spørgsmålet forbliver menneskeligt.

Læs /docs/export-sbom om formaterne.

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.

Send beviset med.

Importér OpenSSL-licensen og resten af det, I sender i produktion. Gratis at importere og gennemgå. I betaler først, når I udgiver.

Start gratis

Cookies på sourcetrust.dev

Vi bruger nødvendige cookies af hensyn til sikkerhed, herunder til at forhindre misbrug af vores sitescan og formularen til anmodning om en livegennemgang. Med din tilladelse bruger vi også valgfri analyse og diagnostik (Google Tag Manager på denne side, og Sentry browser-SDK'en i SourceTrust-programmet, når den er konfigureret). Se vores cookiepolitik.