Spring til hovedindhold
SourceTrust
Se andre licenser

SSPL-1.0

Server Side Public License 1.0

SSPL er MongoDBs omskrivning af AGPL. Tilbyder du softwaren som en tjeneste, kræver dens afsnit 13 kildekoden til hele din tjeneste-stak.

På denne side

Hvad den gør

Server Side Public License er MongoDBs omskrivning af AGPL fra 2018. Den beholder AGPL-teksten og erstatter afsnit 13 med en langt bredere. Tilbyder du softwarens funktionalitet som en tjeneste til tredjeparter, skal du udgive kildekoden til alt det, du brugte til at gøre den tjeneste tilgængelig, under SSPL. Det omfatter administrationssoftware, overvågning, backup, orkestrering og API'erne omkring det. OSI har ikke godkendt licensen, og indsendelsen blev trukket tilbage i 2019, så source available er den præcise mærkat frem for open source.

Detaljer

Grænsen, der afgør din sag, er, om SSPL-softwaren er den tjeneste, du sælger, eller en database bag et produkt, du sælger. At tilbyde et hostet MongoDB er præcis det scenarie, licensen blev skrevet for at stoppe. At køre MongoDB under din egen applikation er den diskutable sag, og diskutabel er ikke det samme som afklaret. Tjek også versionsgrænsen: Elasticsearch og Kibana skiftede til SSPL ved 7.11 og Redis ved 7.4, og begge tilføjede siden en AGPL-mulighed, så svaret afhænger af versionen i din lockfil.

Fordele

  • Lukker SaaS-smutvejen: du kan ikke tage koden, køre den som en tjeneste og aldrig dele dine ændringer.
  • Gør netværksudløseren eksplicit, så et hostet produkt har et ja-eller-nej-spørgsmål i stedet for en distributionsdebat.

Ulemper

  • Et SaaS-produkt, der indeholder denne kode, kan skulle tilbyde tilhørende kildekode til tjenesten, ikke kun til en downloadbar binær fil.
  • Procurement og investorer behandler denne familie som høj opmærksomhed. Forvent ekstra gennemgang, før du publicerer en side, der lister den.

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.

Hvad SSPL-1.0 kræver, når I sender kode ud

For SSPL-1.0 kan det at tilbyde softwaren som en hostet tjeneste udløse samme kildekodepligt, som det at give nogen en binær fil ville. Bekræft det, I kører, ikke kun det, I sender ud som en fil. Netværks-copyleft er skrevet til det hul. Trinene nedenfor er forsendelses- og hostingarbejdet, i den rækkefølge en reviewer typisk går dem.

  1. Du er uden for afsnit 13, så længe softwaren kører til dine egne formål, og du ikke tilbyder nogen dens funktionalitet som en tjeneste.

  2. Du opfylder afsnit 13, når kildekoden til hvert program, du bruger til at tilbyde den tjeneste, inklusive administration, overvågning, backup og orkestrering, er offentlig under SSPL.

  3. Du opfylder de sædvanlige copyleft-vilkår, når en binær fil, du overdrager, bærer den komplette tilsvarende kildekode til det dækkede værk under samme licens.

  4. Du har lavet hele gennemgangen, når du også har set på alternativerne: Valkey erstattede Redis og OpenSearch erstattede Elasticsearch for mange teams, begge under OSI-godkendte licenser.

  5. Du har versionssvaret, når lockfilen, og ikke projektets hjemmeside, fortæller dig, hvilken licens der gælder for præcis den udgivelse, du installerer.

De pligter, SSPL-1.0 navngiver

Notitsen følger stadig med enhver kopi. SSPL-1.0 navngiver også en kildekodepligt, der kan udløses, når I tilbyder softwaren som en hostet tjeneste. Dette er betingelserne i teksten.

Medtag copyright

Behold copyright-notitser på distribuerede kopier.

Medtag licens

Giv modtagere en kopi af licensen sammen med programmet.

Offentliggør kildekode

Når du distribuerer en binær fil af et dækket værk, skal tilsvarende kildekode tilbydes på den måde, licensen beskriver.

Samme licens

Det samlede værk, du distribuerer, skal blive under denne licens. Du kan ikke lukke det dækkede værk med en mere restriktiv tilladelse.

Hostet tjeneste

SSPLs tjenesteklausul rækker til den software, du bruger til at tilbyde programmet som en tjeneste, ikke kun programmet selv. Mange købere behandler den som source-available, ikke OSI-godkendt open source.

Det skal du være opmærksom på

  • At kalde SSPL open source, fordi koden ligger på GitHub. OSI har ikke godkendt den, og Debian og Fedora afviser den, og derfor spørger købere til den ved navn.
  • At antage, at en SSPL-database bag dit eget hostede produkt er afklaret. Det er den diskutable sag, ikke den klare, og afsnit 13 blev formuleret til at blive læst bredt.
  • At opgradere hen over en relicensering uden at opdage det. Et mindre versionsspring flyttede Elasticsearch og Redis væk fra deres gamle licenser, og en lockfil advarer dig ikke.
  • At arkivere SSPL ved siden af AGPL og genbruge den samme analyse. AGPL afsnit 13 beder om det ændrede program; SSPL afsnit 13 beder om hele den stak, du kører det med.

Hvad Server Side Public License 1.0 ikke gør

Søgeresultater flader ofte Server Side Public License 1.0 ud til et slogan. Dette er de sædvanlige fejllæsninger. SSPL-1.0 er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.

  • SSPL er ikke OSI-godkendt open source. At tilbyde softwaren som en tjeneste kan kræve, at du udgiver management-stakken, ikke kun SSPL-programmet.
  • Det er ikke AGPL. Tjeneste-klausulen er bredere end AGPLs netværks-copyleft.

Hvordan SSPL-1.0 adskiller sig fra nærliggende licenser

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

SSPL-1.0
SSPL er MongoDBs omskrivning af AGPL. Tilbyder du softwaren som en tjeneste, kræver dens afsnit 13 kildekoden til hele din tjeneste-stak.
AGPL-3.0-only
AGPL er GPLv3 plus afsnit 13: lader du brugere nå din ændrede version over et netværk, kan de bede dig om dens kildekode.
Elastic-2.0
Source available med tre forbud: du må ikke tilbyde den som managed service, ikke omgå licensnøglerne og ikke fjerne notitser.

Ofte stillede spørgsmål om Server Side Public License 1.0

Svar på almindelige spørgsmål om, hvad Server Side Public License 1.0 kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.

Hvad er Server Side Public License 1.0?

Server Side Public License er MongoDBs omskrivning af AGPL fra 2018. Den beholder AGPL-teksten og erstatter afsnit 13 med en langt bredere. Tilbyder du softwarens funktionalitet som en tjeneste til tredjeparter, skal du udgive kildekoden til alt det, du brugte til at gøre den tjeneste tilgængelig, under SSPL. Det omfatter administrationssoftware, overvågning, backup, orkestrering og API'erne omkring det. OSI har ikke godkendt licensen, og indsendelsen blev trukket tilbage i 2019, så source available er den præcise mærkat frem for open source.

Hvad kræver SSPL-1.0, når I sender et produkt ud?

Du er uden for afsnit 13, så længe softwaren kører til dine egne formål, og du ikke tilbyder nogen dens funktionalitet som en tjeneste. Du opfylder afsnit 13, når kildekoden til hvert program, du bruger til at tilbyde den tjeneste, inklusive administration, overvågning, backup og orkestrering, er offentlig under SSPL. Du opfylder de sædvanlige copyleft-vilkår, når en binær fil, du overdrager, bærer den komplette tilsvarende kildekode til det dækkede værk under samme licens. Du har lavet hele gennemgangen, når du også har set på alternativerne: Valkey erstattede Redis og OpenSearch erstattede Elasticsearch for mange teams, begge under OSI-godkendte licenser. Du har versionssvaret, når lockfilen, og ikke projektets hjemmeside, fortæller dig, hvilken licens der gælder for præcis den udgivelse, du installerer.

Udløser det kildekodepligten at køre SSPL-1.0 som en hostet tjeneste?

Ja. For SSPL-1.0 kan det at tilbyde softwaren som en hostet tjeneste udløse samme kildekodepligt som distribution. Det er pointen med denne familie.

Hvad er tilsvarende kildekode for SSPL-1.0?

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 SSPL-1.0 sig fra GNU AGPL v3.0?

SSPL-1.0 kræver dette: SSPL er MongoDBs omskrivning af AGPL. Tilbyder du softwaren som en tjeneste, kræver dens afsnit 13 kildekoden til hele din tjeneste-stak. GNU AGPL v3.0 kræver dette: AGPL er GPLv3 plus afsnit 13: lader du brugere nå din ændrede version over et netværk, kan de bede dig om dens kildekode. Åbn GNU AGPL v3.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 SSPL-1.0 til en køber?

Kataloget markerer SSPL-1.0 som en licens, hvor netværksbrug ikke er undtaget, så et punkt om netværks-gennemgang dukker op på projektets tjekliste for SaaS- og Blandet-projekter. Et punkt om kildekode-tilbud kommer til, når projektet også sender binære filer ud. SSPL er samtidig en skabelon-licens: den udgivne tekst har udfyldningsfelter, så hentningen lander den aldrig som confirmed. Den vises som SSPL-1.0 med pakkespecifikke parametre og venter på, at du læser den faktiske ordlyd. Komponentsiden viser desuden en kritisk kompatibilitetsadvarsel, når en SSPL-komponent ligger i et projekt, hvis kontekst er SaaS eller Blandet.

Hvor registrerer jeg SSPL-1.0 til en køber?

Kataloget markerer SSPL-1.0 som en licens, hvor netværksbrug ikke er undtaget, så et punkt om netværks-gennemgang dukker op på projektets tjekliste for SaaS- og Blandet-projekter. Et punkt om kildekode-tilbud kommer til, når projektet også sender binære filer ud.

SSPL er samtidig en skabelon-licens: den udgivne tekst har udfyldningsfelter, så hentningen lander den aldrig som confirmed. Den vises som SSPL-1.0 med pakkespecifikke parametre og venter på, at du læser den faktiske ordlyd.

Komponentsiden viser desuden en kritisk kompatibilitetsadvarsel, når en SSPL-komponent ligger i et projekt, hvis kontekst er SaaS eller Blandet. Læs /docs/auto-fetch-license om hvordan hentningen fungerer.

  • Når en pakke angiver et OR-udtryk som SSPL-1.0 OR Elastic-2.0, holder SourceTrust komponenten tilbage, indtil en gennemgang vælger den ene arm, dit produkt skal leve under.
  • At bekræfte netværks-gennemgangen gemmer dit teams attestation på komponenten. Det er ikke en kontrol af, at din tjeneste-stak ligger uden for afsnit 13.

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 Server Side Public License 1.0 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.