Spring til hovedindhold
SourceTrust
Se andre licenser

RPL-1.5

Reciprocal Public License 1.5

RPL-1.5 behandler deployment som distribution: at bruge den til at betjene andre kan udløse kildekode-pligten, selv når du aldrig sender en fil.

På denne side

Hvad den gør

Reciprocal Public License 1.5 er den strengeste reciprokke licens i almindelig SPDX-brug. Sædvanlig copyleft venter på, at du giver en kopi fra dig. Det gør RPL ikke. Den definerer deployment, og at bruge softwaren til at betjene tredjeparter eller til at drive din forretning tæller som deployment, hvilket bærer en pligt til at udgive kildekoden til programmet og til dine ændringer. Personlig brug og intern forskning og udvikling er de undtagelser, licensen nævner. Læs teksten i præcis den version, du har, for det er her, den skiller sig ud fra alt andet i dit inventar.

Detaljer

For en SaaS-leverandør er det den licens, der bryder den vante tankegang. Med GPL kan du berolige dig selv med, at du aldrig sender en binær fil. Med RPL er den sætning ikke et forsvar, for licensen rammer selve det at deploye. Sidder en RPL-komponent inde i en tjeneste, dine kunder bruger, forventes dine ændringer i den at være offentlige, og det er en kommerciel beslutning snarere end en pakke-detalje. Hvor grænsen for dine ændringer går, er omstridt, så eskalér denne komponent tidligt.

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 RPL-1.5 kræver, når I sender kode ud

For RPL-1.5 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 den reciprokke pligt, så længe brugen er personlig eller intern forskning og udvikling, som er de undtagelser, licensen selv nævner.

  2. Du opfylder vilkårene ved en deployment, når kildekoden til programmet og til dine ændringer er udgivet, under RPL, til de personer, licensen peger på.

  3. Du opfylder dem ved en leveret binær fil, som du ville ved enhver stærk copyleft: modtagere får den komplette tilsvarende kildekode til det, du gav dem.

  4. Du er rettidig, når udgivelsen sker efter den tidsplan, licensen sætter, som er knyttet til deploymentet og ikke til din næste udgivelse. Tjek ordlyden i din egen kopi.

  5. Du har håndteret blandingen, når ingen RPL-kode sidder i et GPL-værk eller et lukket produkt. RPL er ikke GPL-kompatibel og tillader ikke en proprietær kombination.

De pligter, RPL-1.5 navngiver

Notitsen følger stadig med enhver kopi. RPL-1.5 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.

Offentliggør kildekode

RPL er deployment-copyleft. At bruge softwaren, ikke kun at distribuere en binær fil, kan udløse den gensidighed, licensen beskriver.

Det skal du være opmærksom på

  • At arkivere RPL som 'bare endnu en GPL'. GPL-ræsonnementet om, at en hostet tjeneste ikke sender noget ud, holder ikke, for RPL knytter sig i stedet til deployment.
  • At læse SourceTrust-tjeklisten som hele billedet. Katalogrækken markerer RPL som en, netværksbrug ikke udløser, så et hostet projekt får intet netværkspunkt for den.
  • At holde en privat fork af en RPL-komponent i en kundevendt tjeneste. Er deploymentet omfattet, er netop den fork, hvad licensen beder dig udgive.
  • At afgøre spørgsmålet om intern brug på et stand-up-møde. RPL rækker længere ind i intern deployment end GPL gør, og ordlyden belønner en grundig læsning med en jurist.

Hvad Reciprocal Public License 1.5 ikke gør

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

  • Reciprocal Public License 1.5 venter ikke på, at du sender en fil ud. At tilbyde softwaren over et netværk er nok til at udløse kildekode-pligten.
  • Det er ikke det samme som GPL. At behandle AGPL eller SSPL som "GPL til servere" uden at læse den ekstra klausul er den sædvanlige fejl.

Hvordan RPL-1.5 adskiller sig fra nærliggende licenser

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

RPL-1.5
RPL-1.5 behandler deployment som distribution: at bruge den til at betjene andre kan udløse kildekode-pligten, selv når du aldrig sender en fil.
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.
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.
GPL-3.0-only
GPL-3.0 beholder kildekode-pligten ved binær distribution og tilføjer et patentbrev, en anti-lockdown-regel for forbrugerenheder og en frist til at rette.

Ofte stillede spørgsmål om Reciprocal Public License 1.5

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

Hvad er Reciprocal Public License 1.5?

Reciprocal Public License 1.5 er den strengeste reciprokke licens i almindelig SPDX-brug. Sædvanlig copyleft venter på, at du giver en kopi fra dig. Det gør RPL ikke. Den definerer deployment, og at bruge softwaren til at betjene tredjeparter eller til at drive din forretning tæller som deployment, hvilket bærer en pligt til at udgive kildekoden til programmet og til dine ændringer. Personlig brug og intern forskning og udvikling er de undtagelser, licensen nævner. Læs teksten i præcis den version, du har, for det er her, den skiller sig ud fra alt andet i dit inventar.

Hvad kræver RPL-1.5, når I sender et produkt ud?

Du er uden for den reciprokke pligt, så længe brugen er personlig eller intern forskning og udvikling, som er de undtagelser, licensen selv nævner. Du opfylder vilkårene ved en deployment, når kildekoden til programmet og til dine ændringer er udgivet, under RPL, til de personer, licensen peger på. Du opfylder dem ved en leveret binær fil, som du ville ved enhver stærk copyleft: modtagere får den komplette tilsvarende kildekode til det, du gav dem. Du er rettidig, når udgivelsen sker efter den tidsplan, licensen sætter, som er knyttet til deploymentet og ikke til din næste udgivelse. Tjek ordlyden i din egen kopi. Du har håndteret blandingen, når ingen RPL-kode sidder i et GPL-værk eller et lukket produkt. RPL er ikke GPL-kompatibel og tillader ikke en proprietær kombination.

Udløser det kildekodepligten at køre RPL-1.5 som en hostet tjeneste?

Ja. For RPL-1.5 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 RPL-1.5?

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

RPL-1.5 kræver dette: RPL-1.5 behandler deployment som distribution: at bruge den til at betjene andre kan udløse kildekode-pligten, selv når du aldrig sender en fil. 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 RPL-1.5 til en køber?

Kataloget registrerer RPL-1.5 som copyleft, og det registrerer også netværksbrug som noget, der ikke rejser en forpligtelse for denne licens. I praksis betyder det ét punkt: et kildekode-tilbud på projektets tjekliste, når distributionskonteksten er Distribueret binær eller Blandet. Et rent SaaS-projekt får slet intet tjeklistepunkt for en RPL-komponent, så deployment-spørgsmålet ovenfor er et, du selv skal køre og skrive ind i komponentens noter.

Hvor registrerer jeg RPL-1.5 til en køber?

Kataloget registrerer RPL-1.5 som copyleft, og det registrerer også netværksbrug som noget, der ikke rejser en forpligtelse for denne licens. I praksis betyder det ét punkt: et kildekode-tilbud på projektets tjekliste, når distributionskonteksten er Distribueret binær eller Blandet.

Et rent SaaS-projekt får slet intet tjeklistepunkt for en RPL-komponent, så deployment-spørgsmålet ovenfor er et, du selv skal køre og skrive ind i komponentens noter. Læs /docs/reviewing-component om hvor de noter ligger.

  • Denne guide klassificerer RPL som netværks-copyleft, mens katalogrækken klassificerer den som stærk copyleft. Forskellen er bevidst, og den er grunden til, at der ikke dukker et netværkspunkt op.
  • Vent ikke på, at et tjeklistepunkt fortæller dig, at en RPL-komponent kræver en beslutning. Skriv deployment-analysen i komponentens noter, så den næste gennemgang kan se den.

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 Reciprocal Public License 1.5 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.