Spring til hovedindhold
Se andre licenser

source-available

Source available-licenser

Du kan læse koden. Det er ikke det samme som lov til at bruge den, som du vil. Source available er ikke open source.

På denne side

Hvad den gør

Source available er en familie snarere end én licens, og medlemmerne deler én vane: de udgiver koden og begrænser derefter, hvad du må gøre med den. Fire former dækker næsten dem alle. Tidsforsinkede licenser skifter til en åben licens senere (BUSL-1.1 efter cirka fire år, Functional Source License efter to, til MIT eller Apache-2.0). Forbud mod konkurrerende tjenester skifter aldrig (Elastic-2.0, Confluent Community). Én tager netværks-copyleft til det yderste (SSPL-1.0). Brugsafgrænsede tilladelser skriver det tilladte omfang ind i selve licensnavnet, hvilket er PolyForm-familien: Noncommercial, Small Business, Internal Use, Perimeter, Shield, Strict og Free Trial.

Detaljer

Ingen af disse licenser er open source, og begrundelsen er præcis frem for politisk. Open Source-definitionen tillader ingen begrænsning af anvendelsesområdet, og hver licens her har en. Hvad det betyder for dig, afhænger af, hvordan du leverer. Intern brug er tilladt af de fleste af dem, så de fleste af disse afhængigheder er fine, hvor de sidder. De ikke-kommercielle PolyForm-varianter er undtagelsen: der er en kommerciel virksomheds interne brug netop det forbudte tilfælde. At tilbyde selve softwaren til tredjeparter som en tjeneste er den begrænsning, de næsten alle deler. Et bibliotek eller SDK, du giver videre til andre udviklere, er som regel det, der spærrer, fordi dine kunder arver en begrænsning, de aldrig har sagt ja til.

Fordele

  • Du kan læse koden, spore fejl og ofte bruge den til ikke-produktion under de offentliggjorte vilkår.
  • Nogle licenser konverterer til OSI-vilkår efter en forsinkelse, hvilket er en planlagt sti snarere end en overraskelse.

Ulemper

  • En SaaS- eller konkurrentklausul kan gøre det "gratis" download ubrugeligt til det produkt, du faktisk bygger.
  • Procurement vil ikke behandle den som open source. Din attestation-side bør sige det klart.

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

  • Privat brug

    Brug inde i virksomheden, også interne forks, udløser ikke i sig selv distributionspligter.

  • Ændre

    Du kan som regel læse og ændre kilden. Produktionsbrug efter skæringsdatoen, eller i en konkurrerende tjeneste, er dér, disse licenser bider.

Hvad source-available kræver, når I sender kode ud

source-available er læsbar kildekode med brugsgrænser. Arbejdet er at matche jeres brug med den skrevne tilladelse og derefter holde teksten på registreringen, så procurement kan læse den. Behandl ikke et source-available-id som OSI-agtig open source, bare fordi koden ligger på GitHub.

  1. Du har læst det pågældende projekts faktiske tekst frem for familienavnet. De fleste af disse licenser har felter, der udfyldes, så to projekter under ét id kan give forskellige rettigheder.

  2. Du bruger softwaren inde i dine egne systemer. Intern produktionsbrug er tilladt af de fleste af disse licenser, men ikke af de ikke-kommercielle: under PolyForm Noncommercial er en kommerciel virksomheds interne brug netop det forbudte tilfælde.

  3. Du tilbyder ikke selve softwaren til tredjeparter som en hostet eller managed tjeneste, hvilket er den begrænsning, næsten alle licenser i denne familie deler.

  4. Du har tjekket, om dine kunder ville arve begrænsningen, før du lægger en af disse i et bibliotek eller et SDK, du giver videre til andre udviklere.

  5. Du har noteret versionen og de vilkår, du læste. Et licensskift upstream rammer ikke den version, du allerede har, men din næste opgradering er en ny beslutning.

De pligter, source-available navngiver

Den skrevne tilladelse er kilden til grænserne. Disse rækker er de sædvanlige betingelser, teams skal matche op imod deres faktiske brug og derefter holde på registreringen.

Medtag licens

Behold licensteksten sammen med den kilde, du har modtaget.

Det skal du være opmærksom på

  • Teams kalder det open source, fordi kildekoden ligger på GitHub. Offentliggjort kildekode og en open source-licens er to forskellige ting, og købere kender i stigende grad forskellen.
  • Teams antager, at en meddelelse om licensskift gælder den version, der allerede står i deres lockfil. Det gør den ikke. Opgraderingen er der, hvor beslutningen reelt træffes.
  • Teams forventer, at hver licens i denne familie bliver markeret for dem. Dækningen er ujævn, og FSL- og Confluent Community-id'erne udløser slet ingenting.
  • Teams behandler familien som ensartet. Et BUSL-projekt skifter til en åben licens på en dato, mens et Elastic-2.0-projekt aldrig skifter.

Hvad Source available-licenser ikke gør

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

  • en source-available-licens er ikke en OSI-godkendt open source-licens. Læsbar kildekode er ikke det samme som tilladelse til at køre en konkurrerende tjeneste eller bruge den i produktion uden de betalte vilkår.
  • Den bliver ikke tilladelig, fordi SPDX-id'et ser bekendt ud. Læs klausulerne om anvendelsesområde, produktion eller konvertering.

Hvordan source-available adskiller sig fra nærliggende licenser

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

source-available
Du kan læse koden. Det er ikke det samme som lov til at bruge den, som du vil. Source available er ikke open source.
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.
Elastic-2.0
Source available med tre forbud: du må ikke tilbyde den som managed service, ikke omgå licensnøglerne og ikke fjerne notitser.
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.

Ofte stillede spørgsmål om Source available-licenser

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

Hvad er Source available-licenser?

Source available er en familie snarere end én licens, og medlemmerne deler én vane: de udgiver koden og begrænser derefter, hvad du må gøre med den. Fire former dækker næsten dem alle. Tidsforsinkede licenser skifter til en åben licens senere (BUSL-1.1 efter cirka fire år, Functional Source License efter to, til MIT eller Apache-2.0). Forbud mod konkurrerende tjenester skifter aldrig (Elastic-2.0, Confluent Community). Én tager netværks-copyleft til det yderste (SSPL-1.0). Brugsafgrænsede tilladelser skriver det tilladte omfang ind i selve licensnavnet, hvilket er PolyForm-familien: Noncommercial, Small Business, Internal Use, Perimeter, Shield, Strict og Free Trial.

Hvad kræver source-available, når I sender et produkt ud?

Du har læst det pågældende projekts faktiske tekst frem for familienavnet. De fleste af disse licenser har felter, der udfyldes, så to projekter under ét id kan give forskellige rettigheder. Du bruger softwaren inde i dine egne systemer. Intern produktionsbrug er tilladt af de fleste af disse licenser, men ikke af de ikke-kommercielle: under PolyForm Noncommercial er en kommerciel virksomheds interne brug netop det forbudte tilfælde. Du tilbyder ikke selve softwaren til tredjeparter som en hostet eller managed tjeneste, hvilket er den begrænsning, næsten alle licenser i denne familie deler. Du har tjekket, om dine kunder ville arve begrænsningen, før du lægger en af disse i et bibliotek eller et SDK, du giver videre til andre udviklere. Du har noteret versionen og de vilkår, du læste. Et licensskift upstream rammer ikke den version, du allerede har, men din næste opgradering er en ny beslutning.

Er source-available open source?

Ikke i OSI-forstand. source-available er source-available: du kan læse koden, men tilladelsen begrænser, hvordan du må bruge den. Læs selve teksten.

Hvordan adskiller source-available sig fra Business Source License 1.1?

source-available kræver dette: Du kan læse koden. Det er ikke det samme som lov til at bruge den, som du vil. Source available er ikke open source. Business Source License 1.1 kræver dette: Source available, ikke open source. Hver version skifter til en åben licens på sin egen Change Date, typisk fire år efter udgivelsen. Åbn Business Source License 1.1-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 source-available til en køber?

Ingen licens i denne familie lander nogensinde på confirmed. Verifikationen afviser det udfald for dem alle, så hver enkelt når frem til et menneske med den udpakkede tekst vedhæftet. En udfyldt skabelon mærkes som licensen med pakkespecifikke parametre frem for som en ændring. Derefter er dækningen ujævn. BUSL-1.1, Elastic-2.0, SSPL-1.0 og to PolyForm-varianter har katalogrækker, så et punkt om gennemgang af netværksdistribution kan dukke op på tjeklisten. FSL- og Confluent Community-id'erne har ingen.

Hvor registrerer jeg source-available til en køber?

Ingen licens i denne familie lander nogensinde på confirmed. Verifikationen afviser det udfald for dem alle, så hver enkelt når frem til et menneske med den udpakkede tekst vedhæftet.

En udfyldt skabelon mærkes som licensen med pakkespecifikke parametre frem for som en ændring. Derefter er dækningen ujævn.

BUSL-1.1, Elastic-2.0, SSPL-1.0 og to PolyForm-varianter har katalogrækker, så et punkt om gennemgang af netværksdistribution kan dukke op på tjeklisten. FSL- og Confluent Community-id'erne har ingen.

Læs /docs/inventory-compliance.

  • Hvert skabelon-id, fra BUSL-1.1 og SSPL-1.0 over Elastic-2.0, Confluent Community til FSL- og PolyForm-familierne, holdes bevidst ude af den bane, der udfylder tekst automatisk.
  • Der findes ingen ekstern forpligtelse for en brugsbegrænsning som sådan. Det ene tjeklistepunkt, der kan udløses her, er gennemgang af netværksdistribution, og kun for en licens, kataloget markerer som en, hvor et netværks-deployment ikke er undtaget. PolyForm-, CC-BY-NC- og CC-BY-ND-id'erne rejser dog en kompatibilitetsadvarsel om begrænset brug på komponentsiden, i alle deployment-kontekster.
  • Intet i denne familie bliver afgjort for dig. Gennemgangen er din, og den tekst, der gemmes på komponenten, er den, din attestation-side bærer.

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 Source available-licenser 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.