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.
På denne side
Hvad den gør
En proprietær komponent er dækket af en kontrakt frem for af en offentlig licens. Kontrakten kan være en leverandør-EULA, altså den aftale, du accepterer, når du installerer softwaren. Den kan også være en ordrebekræftelse, en abonnementsaftale eller en aftale, dit juridiske team har forhandlet linje for linje. Oracle Database, Microsoft SQL Server, Highcharts, AG Grid Enterprise, FontAwesome Pro og kommercielle API-vilkår hører alle til her. Der findes ingen offentlig tekst at slå op, så intet om vilkårene kan udledes af produktets navn.
Detaljer
Det spørgsmål, din kundes procurement-team stiller, er enkelt: må I give os det her? For en open source-pakke står svaret i en tekst, alle kan læse. Her står det i din kontrakt, og kun de, der har kontrakten, kan svare. Fire klausuler afgør det som regel: om du må redistribuere, hvor mange navngivne brugere der er dækket, hvilke miljøer softwaren må køre i, og om dine kunder skal have deres egen licens. Skriv de fire ned én gang, og spørgsmålet holder op med at være en brandøvelse.
Fordele
- Kommercielle vilkår kan matche det produkt, du faktisk købte: vilkår hos leverandøren bliver hos leverandøren, ikke her.
- At lægge komponenten på attestation-siden viser stadig købere, at I har den i inventaret.
Ulemper
- Intet her kan hentes fra en offentlig licensfil. Nogen skal vedhæfte den rigtige aftale eller et resumé, juristen accepterer.
- Videredistribution, SaaS og OEM-rettigheder er det, ordrebekræftelsen siger. At gætte ud fra et SPDX-agtigt id er fejlen.
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
Brug under EULA
Du må kun bruge softwaren, som leverandørens aftale tillader. Der er ingen generel ret til at ændre eller give underlicens.
Grænser
Ændre
EULA'er forbyder typisk reverse engineering og uautoriseret ændring.
Videredistribuere
Du kan som regel ikke give kopier til andre, undtagen som aftalen beskriver (for eksempel en runtime, du sender med dit produkt).
Holde ansvarlig
Forfatterne fraskriver sig garanti. Modtagere kan ikke holde dem ansvarlige for skader fra softwaren, undtagen hvor loven forbyder den fraskrivelse.
Forpligtelser
Medtag licens
Behold leverandøraftalen og eventuelle påkrævede notitser sammen med den software, du sender ud.
Følg EULA'en
Hvor mange der må bruge den, territorium og brugsområde lever i den aftale, ikke i en SPDX-tilladelse.
Hvad proprietary kræver, når I sender kode ud
De grænser, der betyder noget for proprietary, sidder i den aftale, I har underskrevet, ikke i en offentlig licenstekst. Denne side fortæller, hvad der ikke kan slås op, og hvad der stadig hører hjemme på registreringen, så en køber ser den kommercielle komponent i lageret.
Du ved, hvilket dokument der gælder: EULA'en, ordrebekræftelsen eller et underskrevet tillæg. En marketingside og en prisliste er ikke aftalen.
Du har noteret de grænser, der afgør din brug: redistribution, antallet af navngivne brugere, tilladte miljøer og eventuelle region- eller auditklausuler.
Du har læst redistributions-klausulen, før du lægger komponenten ind i noget, du giver videre til en kunde. De fleste leverandøraftaler forbyder det direkte.
Du har tjekket, om det tæller som forbudt service bureau-brug at hoste komponenten for dine egne kunder, hvis du kører et hostet produkt.
Du inddrager en jurist for enhver komponent, hvis vilkår begrænser, hvordan du leverer eller hoster dit produkt. Ordlyden er som regel til forhandling, og det er her, pengene ligger.
De pligter, proprietary navngiver
Offentlige SPDX-sider kan ikke liste de kommercielle vilkår. Det, der hører hjemme på registreringen, er id'et og teksten fra den aftale, I har underskrevet.
Medtag licens
Behold leverandøraftalen og eventuelle påkrævede notitser sammen med den software, du sender ud.
Følg EULA'en
Hvor mange der må bruge den, territorium og brugsområde lever i den aftale, ikke i en SPDX-tilladelse.
Det skal du være opmærksom på
- Teams noterer leverandørens navn og stopper der. Notér i stedet det gældende dokument og dets dato, for en fornyelse kan stille og roligt erstatte de vilkår, I gennemgik.
- Teams antager, at det at betale for en komponent også køber retten til at give den videre. En brugsret er ikke en redistributionsret, og de to prissættes hver for sig.
- Teams leder efter en forpligtelses-tjekliste på en proprietær komponent og finder ingenting. Den findes ikke, og derfor hører kontraktens grænser hjemme i Team-noter på komponenten.
- Teams indsætter et link til leverandørens vilkårsside og kalder det færdigt. Sider ændrer sig uden varsel, så gem den ordlyd, der gjaldt den dag, I sagde ja.
Hvad Proprietære og kommercielle licenser ikke gør
Søgeresultater flader ofte Proprietære og kommercielle licenser ud til et slogan. Dette er de sædvanlige fejllæsninger. proprietary er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.
- en proprietær EULA er ikke en offentlig licenstekst, du kan slå op. Grænserne står i den aftale, du har underskrevet.
- En katalogrække mærket proprietary opfinder ikke vilkår. Den registrerer kun, at komponenten ikke er under en offentlig SPDX-tilladelse.
Hvordan proprietary adskiller sig fra nærliggende licenser
Disse licenser forveksles ofte med proprietary, 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.
- 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.
- 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.
- licenseref
- Et LicenseRef-id er en henvisning, ikke en licens. Det siger, at teksten står et andet sted i dokumentet, så nogen skal gå hen og læse den.
- no-license
- Kode udgivet uden licens er ikke fri at bruge. Copyright gælder som udgangspunkt, og forfatteren beholder alle rettigheder, de ikke har givet væk.
Ofte stillede spørgsmål om Proprietære og kommercielle licenser
Svar på almindelige spørgsmål om, hvad Proprietære og kommercielle licenser kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.
Hvad er Proprietære og kommercielle licenser?
En proprietær komponent er dækket af en kontrakt frem for af en offentlig licens. Kontrakten kan være en leverandør-EULA, altså den aftale, du accepterer, når du installerer softwaren. Den kan også være en ordrebekræftelse, en abonnementsaftale eller en aftale, dit juridiske team har forhandlet linje for linje. Oracle Database, Microsoft SQL Server, Highcharts, AG Grid Enterprise, FontAwesome Pro og kommercielle API-vilkår hører alle til her. Der findes ingen offentlig tekst at slå op, så intet om vilkårene kan udledes af produktets navn.
Hvad kræver proprietary, når I sender et produkt ud?
Du ved, hvilket dokument der gælder: EULA'en, ordrebekræftelsen eller et underskrevet tillæg. En marketingside og en prisliste er ikke aftalen. Du har noteret de grænser, der afgør din brug: redistribution, antallet af navngivne brugere, tilladte miljøer og eventuelle region- eller auditklausuler. Du har læst redistributions-klausulen, før du lægger komponenten ind i noget, du giver videre til en kunde. De fleste leverandøraftaler forbyder det direkte. Du har tjekket, om det tæller som forbudt service bureau-brug at hoste komponenten for dine egne kunder, hvis du kører et hostet produkt. Du inddrager en jurist for enhver komponent, hvis vilkår begrænser, hvordan du leverer eller hoster dit produkt. Ordlyden er som regel til forhandling, og det er her, pengene ligger.
Kan jeg slå Proprietære og kommercielle licenser-vilkårene op på denne side?
Nej. Proprietære og kommercielle vilkår kommer fra den aftale, I har underskrevet, ikke fra en offentlig licenstekst. De grænser, der betyder noget, står i jeres ordrebekræftelse.
Hvordan adskiller proprietary sig fra Source available-licenser?
proprietary kræver dette: 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. Source available-licenser 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. Åbn Source available-licenser-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 proprietary til en køber?
SourceTrust læser ikke en leverandøraftale og kan ikke fortælle dig, hvad den tillader. En proprietær komponent er manuel. Auto-hentning lander på tilstanden proprietary, når en pakke ikke angiver nogen licens, og der ikke findes nogen licensfil. Den tilstand udfylder aldrig tekst af sig selv. Du indsætter aftaleteksten eller et autoritativt uddrag på komponenten, noterer grænserne i Team-noter og godkender den selv. Derefter står den på din offentlige attestation-side og i hver eksport som enhver anden komponent.
Hvor registrerer jeg proprietary til en køber?
SourceTrust læser ikke en leverandøraftale og kan ikke fortælle dig, hvad den tillader. En proprietær komponent er manuel.
Auto-hentning lander på tilstanden proprietary, når en pakke ikke angiver nogen licens, og der ikke findes nogen licensfil. Den tilstand udfylder aldrig tekst af sig selv.
Du indsætter aftaleteksten eller et autoritativt uddrag på komponenten, noterer grænserne i Team-noter og godkender den selv. Derefter står den på din offentlige attestation-side og i hver eksport som enhver anden komponent.
Læs /docs/reviewing-component.
- Ingen af de seks eksterne forpligtelser gælder for en komponent uden SPDX-id, så en proprietær komponent har slet ingen tjeklistepunkter.
- Team-noter forbliver interne for dem, der kan åbne projektets inventar. De vises aldrig på den offentlige side, så det er stedet til kontraktdetaljer.
- Den licenstekst, du vedhæfter, er præcis den, som den offentlige side og eksportfilerne bærer. Indsæt den ordlyd, du er villig til at lade en køber læse.
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.