Spring til hovedindhold
SourceTrust
Se andre licenser

JSON

JSON-licensen

JSON-licensen er MIT plus én sætning: softwaren må bruges til Godt, ikke Ondt. Den brugsbegrænsning er grunden til, at politikker afviser den.

På denne side

Hvad den gør

JSON-licensen er Douglas Crockfords MIT-tekst med én sætning tilføjet: softwaren må bruges til Godt, ikke Ondt. Alt andet læses som MIT. Du må bruge, kopiere, ændre, udgive, distribuere, give underlicens til og sælge koden, så længe copyright-notitsen og hele tilladelsesnotitsen, inklusive den sætning, følger med. Den tilføjede sætning er en brugsbegrænsning: den begrænser, hvad du må bruge softwaren til. Det er dét, der placerer den uden for Open Source Definition, som ikke tillader en licens at begrænse anvendelsesområder.

Detaljer

Klausulen lyder som en spøg og opfører sig som en blokering i procurement. Free Software Foundation behandler licensen som ikke-fri, Debian anser den for at falde uden for sine retningslinjer, og Fedora afviser den. Apache Software Foundation satte den på sin forbudsliste, hvilket tvang reelle kodeændringer i Apache-projekter. En køber med en licenspolitik kan altså afvise komponenten, selv om tilladelsen nedenunder har MIT-form. Der er heller ingen måde at vise, at brugsbetingelsen er opfyldt, fordi Godt og Ondt er udefinerede, og der findes ingen objektiv prøve.

Fordele

  • At navngive situationen (ingen licens, dual license, undtagelse, egen tekst) er bedre end at tvinge et nært SPDX-id.
  • Når filerne er læst, ligner resten af gennemgangen enhver anden komponent.

Ulemper

  • Auto-hentning og SPDX-match afslutter ikke dette for dig. Et menneske skal læse, hvad der fulgte med.
  • Forkert SPDX på en dual-license- eller LicenseRef-pakke er en almindelig attestation-fejl.

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

JSON er en situation mere end en standardtilladelse. Læs det, der faktisk står på komponenten, og registrer det, i stedet for at håbe at et nærliggende SPDX-id dækker. Trinene nedenfor er, hvordan I holder registreringen bundet til den tekst, I faktisk har.

  1. Du opfylder notitsbetingelsen, når copyright-linjen og hele tilladelsesnotitsen, inklusive sætningen om Godt og Ondt, følger med hver kopi, du distribuerer.

  2. Du er så tæt på, som denne licens tillader, på brugsklausulen, når den, der ejer licenspolitikken, har set på den og skrevet en beslutning ned, fordi intet her kan efterprøves objektivt.

  3. Du fjerner spørgsmålet helt, når du udskifter afhængigheden. I Java har org.json alternativer under Apache-2.0, for eksempel Jackson og Gson, mod at kaldestederne skrives om.

  4. Du er klar til en kundegennemgang, når din komponentregistrering angiver licensen som JSON og ikke som MIT, så køberens egen politik kan anvendes på den.

De pligter, JSON navngiver

Der er ingen standardtilladelse at scanne. Registrer id'et og den tekst, der faktisk står på komponenten, og behandl nærliggende SPDX-id'er som andre sider, ikke som erstatninger.

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å

  • Licensen læses som MIT, fordi de første 95 procent af teksten er MIT. Den tilføjede sætning er den eneste del, der betyder noget for en gennemgang mod licenspolitikken.
  • En SBOM registrerer komponenten som MIT-agtig, og den slipper gennem en tilladelsesliste, der ville have afvist den. Registrér id'et som JSON, og lad køberen afgøre det.
  • Udskiftningen udskydes, indtil en kunde protesterer. Skiftet til en Apache-2.0-parser er en omskrivning af kaldestederne, og det er billigere, før en aftale ligger på bordet.

Hvad JSON-licensen ikke gør

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

  • JSON-licensen er ikke Open Source. Sætningen "used for Good, not Evil" er en begrænsning af anvendelsesområdet.
  • Den opfører sig ikke som MIT, bare fordi resten af teksten ser bekendt ud.

Hvordan JSON adskiller sig fra nærliggende licenser

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

JSON
JSON-licensen er MIT plus én sætning: softwaren må bruges til Godt, ikke Ondt. Den brugsbegrænsning er grunden til, at politikker afviser den.
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.
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.
proprietary
Ikke open source. Den aftale, du har underskrevet, sætter vilkårene, så teksten du vedhæfter og grænserne du noterer, er hele grundlaget.

Ofte stillede spørgsmål om JSON-licensen

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

Hvad er JSON-licensen?

JSON-licensen er Douglas Crockfords MIT-tekst med én sætning tilføjet: softwaren må bruges til Godt, ikke Ondt. Alt andet læses som MIT. Du må bruge, kopiere, ændre, udgive, distribuere, give underlicens til og sælge koden, så længe copyright-notitsen og hele tilladelsesnotitsen, inklusive den sætning, følger med. Den tilføjede sætning er en brugsbegrænsning: den begrænser, hvad du må bruge softwaren til. Det er dét, der placerer den uden for Open Source Definition, som ikke tillader en licens at begrænse anvendelsesområder.

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

Du opfylder notitsbetingelsen, når copyright-linjen og hele tilladelsesnotitsen, inklusive sætningen om Godt og Ondt, følger med hver kopi, du distribuerer. Du er så tæt på, som denne licens tillader, på brugsklausulen, når den, der ejer licenspolitikken, har set på den og skrevet en beslutning ned, fordi intet her kan efterprøves objektivt. Du fjerner spørgsmålet helt, når du udskifter afhængigheden. I Java har org.json alternativer under Apache-2.0, for eksempel Jackson og Gson, mod at kaldestederne skrives om. Du er klar til en kundegennemgang, når din komponentregistrering angiver licensen som JSON og ikke som MIT, så køberens egen politik kan anvendes på den.

Hvorfor ligger JSON under særlige tilfælde?

JSON er en situation snarere end en standard offentlig tilladelse: ingen licens, et valg mellem licenser, en undtagelse, et eget id, eller en tekst der ikke passer ind i familierne ovenfor. Hver af dem afgøres ved at læse, hvad der faktisk står.

Hvordan adskiller JSON sig fra MIT-licensen?

JSON kræver dette: JSON-licensen er MIT plus én sætning: softwaren må bruges til Godt, ikke Ondt. Den brugsbegrænsning er grunden til, at politikker afviser den. 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 JSON til en køber?

SourceTrust henter den udgivne artefakt, pakker licensfilerne ud og sammenligner teksten med det angivne SPDX-id, så den ekstra sætning står foran dig i stedet for at ligge begravet i en jar-fil. Der findes ingen ekstern forpligtelse for en brugsbegrænsning, så intet lander på projektets tjekliste, og publicering holdes ikke tilbage for det. Licenskataloget registrerer stadig denne licens som tilladelig, så komponentsiden grupperer den sådan. Beslutningen her er en beslutning om jeres licenspolitik, og den forbliver din.

Hvor registrerer jeg JSON til en køber?

SourceTrust henter den udgivne artefakt, pakker licensfilerne ud og sammenligner teksten med det angivne SPDX-id, så den ekstra sætning står foran dig i stedet for at ligge begravet i en jar-fil. Der findes ingen ekstern forpligtelse for en brugsbegrænsning, så intet lander på projektets tjekliste, og publicering holdes ikke tilbage for det.

Licenskataloget registrerer stadig denne licens som tilladelig, så komponentsiden grupperer den sådan. Beslutningen her er en beslutning om jeres licenspolitik, og den forbliver din.

Læs /docs/inventory-compliance for at finde hvert projekt, der bærer 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 JSON-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.