En licens i Artistic-1.0-stil til Open Groups conformance-suites. Fri at køre og ændre, men ændrede tests skal omdøbes, og selve suiten må ikke sælges.
På denne side
Hvad den gør
Open Group Test Suite License dækker conformance-testsuites udgivet af The Open Group. Den bygger på Artistic License 1.0, ikke på BSD, og låner den licens' ordforråd: Package, Standard Version og den Copyright Holder, der beholder den kunstneriske kontrol. Du må køre suiten, kopiere den, ændre den og give den videre, og du må bundle den i en større kommerciel distribution. Tre ting adskiller den fra en tilladelig licens. Klausul 5 siger, at du ikke må tage penge for selve pakken, kun et rimeligt kopieringsgebyr eller betaling for support. Klausul 3 siger, at en ændret fil skal have en tydelig notits om, hvordan og hvornår du ændrede den. Klausul 3 og 4 siger, at ikke-standard eksekverbare filer og testcases skal omdøbes, sendes sammen med Standard Version og dokumenteres.
Detaljer
Intern brug er det nemme tilfælde. At køre en Open Group-suite i din egen build-pipeline giver intet videre til nogen, så der er intet at udgive. Betingelserne bider, når suiten, eller en ændret kopi af den, forlader din organisation. En rettet testcase, du deler med en partner, skal have et nyt navn, originalen ved siden af og en manualside, der forklarer forskellen. Gebyrreglen betyder noget for enhver, der sælger testværktøj. Suiten må følge med i et større betalt produkt, men den må ikke være produktet, og du må ikke markedsføre den som din egen. En testsuite er let at forveksle med et almindeligt bibliotek, så læs teksten, før du bygger et produkt på den.
Fordele
- Nem at lægge ind i et lukket, betalt produkt. Procurement har set denne familie hundredvis af gange.
- Ingen copyleft på dine egne filer. Du holder din kildekode privat.
Ulemper
- Notitspligten er nem at overse i et desktop-, mobil- eller container-build. En webside erstatter ikke notitser inde i artefakten.
- Købere, der vil have en udtrykkelig patenttilladelse, vil bede dig foretrække Apache-2.0 frem for en kort MIT-agtig tekst.
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.
Grænser
Holde ansvarlig
Forfatterne fraskriver sig garanti. Modtagere kan ikke holde dem ansvarlige for skader fra softwaren, undtagen hvor loven forbyder den fraskrivelse.
Bruge varemærke
Licensen er ikke en varemærkelicens. Navne, logoer og produktmærker bliver hos ejerne, medmindre en separat tilladelse siger noget andet.
Patenttilladelse
Teksten giver ikke patenter. Hvis købere vil have en udtrykkelig patenttilladelse, er Apache-2.0 det sædvanlige alternativ.
Forpligtelser
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.
Hvad OGTSL kræver, når I sender kode ud
Når en kopi, der indeholder OGTSL-kode, forlader virksomheden, er tilladelsen bred, og papirarbejdet er nemt at overse. Distribution betyder her en installer, en mobil binær fil, et container-image eller et SDK et andet team bygger ind. Arbejd listen op imod den artefakt, du rent faktisk giver videre, ikke op imod en README. En hostet tjeneste, der aldrig giver en kopi ud, hører stadig hjemme på registreringen, men notitspligten udløses først, når der findes en kopi.
Du er på plads ved intern test, når suiten bliver inden for din organisation, fordi betingelserne knytter sig til kopier, du distribuerer til andre.
Du opfylder klausul 3, når hver fil, du har ændret, bærer en tydelig notits om, hvordan og hvornår du ændrede den, og de oprindelige notitser bliver stående.
Du opfylder klausul 3 og 4, når ikke-standard eksekverbare filer og testcases har navne, der ikke kolliderer med standardens, sendes sammen med Standard Version og har en manualside, der dokumenterer forskellene.
Du opfylder klausul 5, når du ikke tager penge for selve pakken. Et kopieringsgebyr, betaling for support eller bundling i en større kommerciel distribution er tilladt, så længe du ikke markedsfører den som dit eget produkt.
Du respekterer klausul 8, når intet, du udgiver, bruger rettighedshaverens navn til at anbefale eller promovere et produkt afledt af suiten uden skriftlig tilladelse.
De pligter, OGTSL navngiver
Selve licensteksten er kort. Dette er de navngivne betingelser. De følger koden, også filer I kopierer ind i jeres eget repository og transitive pakker i lockfilen.
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å
- En conformance-suite arkiveres som tilladelig i BSD-stil og pakkes om i et betalt produkt. Gebyrreglen og omdøbningspligterne er hele pointen med denne licens.
- En ændret testcase deles med en partner under sit oprindelige navn og uden ændringsnotits. Omdøb den, send Standard Version med ved siden af, og dokumentér hvad der er anderledes.
- En bestået kørsel bliver til markedsføring, der bruger The Open Groups navn. Hold testresultater faktuelle, og hold rettighedshaverens navn ude af anbefalingsformuleringer.
Hvad Open Group Test Suite License ikke gør
Søgeresultater flader ofte Open Group Test Suite License ud til et slogan. Dette er de sædvanlige fejllæsninger. OGTSL er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.
- Open Group Test Suite License kræver ikke, at du udgiver din egen kildekode. At kombinere den med lukket kode er selve pointen med tilladelsen.
- Open Group Test Suite License betyder ikke "ingen forpligtelser." Copyright-linjen og licensteksten skal stadig følge med kopier, du giver videre.
- Det er ikke en patentlicens, medmindre teksten siger det. MIT-familiens tilladelser nævner ikke patenter.
Hvordan OGTSL adskiller sig fra nærliggende licenser
Disse licenser forveksles ofte med OGTSL, 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.
- OGTSL
- En licens i Artistic-1.0-stil til Open Groups conformance-suites. Fri at køre og ændre, men ændrede tests skal omdøbes, og selve suiten må ikke sælges.
- BSD-3-Clause
- Tilladelig som MIT, med én ekstra regel: du må ikke bruge forfatternes navne til at promovere dit produkt. Notitser følger med kildekode og binære filer.
- MPL-2.0
- Filbaseret copyleft. MPL-filerne forbliver åbne, når du sender en binær fil ud, ændret eller ej. Dine egne adskilte filer er dine.
Ofte stillede spørgsmål om Open Group Test Suite License
Svar på almindelige spørgsmål om, hvad Open Group Test Suite License kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.
Hvad er Open Group Test Suite License?
Open Group Test Suite License dækker conformance-testsuites udgivet af The Open Group. Den bygger på Artistic License 1.0, ikke på BSD, og låner den licens' ordforråd: Package, Standard Version og den Copyright Holder, der beholder den kunstneriske kontrol. Du må køre suiten, kopiere den, ændre den og give den videre, og du må bundle den i en større kommerciel distribution. Tre ting adskiller den fra en tilladelig licens. Klausul 5 siger, at du ikke må tage penge for selve pakken, kun et rimeligt kopieringsgebyr eller betaling for support. Klausul 3 siger, at en ændret fil skal have en tydelig notits om, hvordan og hvornår du ændrede den. Klausul 3 og 4 siger, at ikke-standard eksekverbare filer og testcases skal omdøbes, sendes sammen med Standard Version og dokumenteres.
Hvad kræver OGTSL, når I sender et produkt ud?
Du er på plads ved intern test, når suiten bliver inden for din organisation, fordi betingelserne knytter sig til kopier, du distribuerer til andre. Du opfylder klausul 3, når hver fil, du har ændret, bærer en tydelig notits om, hvordan og hvornår du ændrede den, og de oprindelige notitser bliver stående. Du opfylder klausul 3 og 4, når ikke-standard eksekverbare filer og testcases har navne, der ikke kolliderer med standardens, sendes sammen med Standard Version og har en manualside, der dokumenterer forskellene. Du opfylder klausul 5, når du ikke tager penge for selve pakken. Et kopieringsgebyr, betaling for support eller bundling i en større kommerciel distribution er tilladt, så længe du ikke markedsfører den som dit eget produkt. Du respekterer klausul 8, når intet, du udgiver, bruger rettighedshaverens navn til at anbefale eller promovere et produkt afledt af suiten uden skriftlig tilladelse.
Kræver OGTSL, at jeg åbner min egen kildekode?
Det er ikke en patentlicens, medmindre teksten siger det. MIT-familiens tilladelser nævner ikke patenter.
Hvordan krediterer jeg OGTSL i et produkt, jeg sender ud?
Kreditering for OGTSL betyder, at copyright-linjen og licensteksten følger med hver kopi, en modtager rent faktisk får. Det kan være en om-skærm, en licensfil inde i installeren eller en notits i container-imaget. En offentlig side hjælper en køber med at revidere lageret. Den erstatter ikke notitser inde i artefakten. Hvis I har kopieret filer ind i jeres eget repository, skal headeren på de filer stadig blive.
Er en notits på en hjemmeside nok til OGTSL?
Nej. OGTSL taler om kopier. En offentlig attestation-side er den ærlige liste til procurement. Betingelsen er opfyldt, når notitserne ligger i det materiale, I giver videre. Læg dem i installeren, om-skærmen eller en licensfil inde i den binære fil, og hold derefter de samme tekster på siden.
Tæller transitive OGTSL-afhængigheder med?
Ja. Betingelsen følger koden, ikke den pakke I valgte ved navn. Hvis lockfilen har trukket OGTSL med transitivt, og I distribuerer det træ, følger de notitser også med. Kun at liste direkte afhængigheder er den måde, teams misser pligten.
Hvordan adskiller OGTSL sig fra BSD 3-Clause-licensen?
OGTSL kræver dette: En licens i Artistic-1.0-stil til Open Groups conformance-suites. Fri at køre og ændre, men ændrede tests skal omdøbes, og selve suiten må ikke sælges. BSD 3-Clause-licensen kræver dette: Tilladelig som MIT, med én ekstra regel: du må ikke bruge forfatternes navne til at promovere dit produkt. Notitser følger med kildekode og binære filer. Åbn BSD 3-Clause-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 OGTSL til en køber?
SourceTrust henter den udgivne artefakt, hvor suiten distribueres som en pakke, pakker licensfilerne ud og sammenligner teksten med det angivne SPDX-id. Testsuites leveres ofte uden om et pakkeregister, så hentningen finder måske intet, og komponenten venter på, at du indsætter teksten. Licenskataloget registrerer denne licens som tilladelig, så komponentsiden grupperer den sådan. Der findes ingen ekstern forpligtelse for gebyrreglen eller omdøbningspligterne, så der dukker intet op på projektets tjekliste, og læsningen er din opgave.
Hvor registrerer jeg OGTSL til en køber?
SourceTrust henter den udgivne artefakt, hvor suiten distribueres som en pakke, pakker licensfilerne ud og sammenligner teksten med det angivne SPDX-id. Testsuites leveres ofte uden om et pakkeregister, så hentningen finder måske intet, og komponenten venter på, at du indsætter teksten.
Licenskataloget registrerer denne licens som tilladelig, så komponentsiden grupperer den sådan. Der findes ingen ekstern forpligtelse for gebyrreglen eller omdøbningspligterne, så der dukker intet op på projektets tjekliste, og læsningen er din opgave.
Læs /docs/reviewing-component om gennemgangsforløbet.
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.