En sjælden forskningslicens med gensidige kildekode-pligter. Læs den faktiske tekst: der findes kun lidt fast praksis om dens præcise rækkevidde.
På denne side
Hvad den gør
OCLC Research Public License 2.0 kommer fra OCLC, biblioteksservice-kooperativet, og dækker den forskningssoftware, de har udgivet. Den er gensidig, hvilket betyder, at licensen kræver, at den dækkede kode og dine ændringer i den forbliver tilgængelige under samme vilkår, når du distribuerer. Den bærer også sin egen attribution- og notitsformulering plus en bestemmelse mod at bruge OCLC's navn til at anbefale dit produkt. Licensen er stort set fraværende fra de gængse pakkeregistre, så dukker en op i dit inventar, er den som regel kommet ind via en vendored kopi eller en intern fork.
Detaljer
To ting gør denne værd at læse grundigt frem for at klassificere hurtigt. Den er sjælden, så der er meget lidt fast praksis at læne sig op ad. Den præcise grænse for dens gensidighed er ikke noget, man kan antage ud fra den familie, den ligner. Kører du kun koden på dine egne servere, udløses intet her, for der er ingen netværksklausul. Sender du den ud eller giver den videre til en anden udvikler som del af et bibliotek, så planlæg kildekode-tilgængeligheden for den dækkede kode. Åbn den faktiske licenstekst frem for et resumé af den.
Fordele
- Du kan linke biblioteket fra lukket kode på den måde, licensen beskriver.
- Fil-niveau gensidighed er lettere at isolere end GPL-agtig copyleft på hele værket.
Ulemper
- At vendorere eller linke statisk kan trække mere af dit træ ind i det dækkede sæt, end et dynamisk link ville.
- Kildekode-tilbuddet er reelt, i det øjeblik du distribuerer binære filer, der indeholder ændrede dækkede filer.
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.
Patentbrug
Disse licenser indeholder typisk en patenttilladelse, der dækker de licenserede filer. Læs tilladelsen, før du læner dig op ad den i en sag med høj indsats.
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.
Åbne dit produkt
Copyleft på fil- eller biblioteks-niveau tvinger dig ikke, på tekstens ord, til at åbne hele din applikation. Gensidigheden bliver på de dækkede filer.
Forpligtelser
Medtag copyright
Behold copyright-notitser på de dækkede filer, du distribuerer.
Medtag licens
Behold licensteksten sammen med de dækkede filer, og sig at de filer er under denne licens.
Offentliggør kildekode
Dækkede filer, du ændrer og distribuerer, skal have kildekode tilgængelig under samme licens.
Hvad OCLC-2.0 kræver, når I sender kode ud
Når du distribuerer en binær fil, der indeholder OCLC-2.0-kode, følger notitsen stadig med kopien, og den tilsvarende kildekode skal være tilgængelig under samme licens. Intern brug uden at en kopi forlader virksomheden er en anden situation. Listen nedenfor er forsendelsesarbejdet: det en modtager af den binære fil kan kræve, og det du registrerer, så en køber kan se det.
Du opfylder kildekode-betingelsen, når den dækkede kode og dine ændringer i den er tilgængelige under OCLC-licensen for alle, du har distribueret til.
Du har styr på notitserne, når OCLC's copyright- og attributionsformulering følger med hver kopi, i den form licensteksten beder om.
Du holder dig på den rigtige side af endorsement-klausulen, når intet i din markedsføring antyder, at OCLC står bag eller sponsorerer dit produkt.
Du har gjort det arbejde, denne licens kræver, når nogen har læst hele teksten og skrevet ned, hvilke dele af dit build gensidigheden rækker ind i.
De pligter, OCLC-2.0 navngiver
Notitsen følger stadig med kopien. Oven i det navngiver OCLC-2.0 en kildekodepligt. Dette er betingelserne i teksten. Vejledningen ovenfor er, hvornår de bliver til reelt arbejde.
Medtag copyright
Behold copyright-notitser på de dækkede filer, du distribuerer.
Medtag licens
Behold licensteksten sammen med de dækkede filer, og sig at de filer er under denne licens.
Offentliggør kildekode
Dækkede filer, du ændrer og distribuerer, skal have kildekode tilgængelig under samme licens.
Det skal du være opmærksom på
- En forskningslicens behandles som MIT, fordi den er ukendt og lille. Læs teksten; gensidige vilkår bliver ikke tilladelige af, at de er sjældne.
- Rækkevidden bliver gættet ud fra en lignende licens. Intet her er afklaret nok til at kopiere over fra MPL, så skriv ned, hvad du kom frem til, og hvorfor.
Hvad OCLC Research Public License 2.0 ikke gør
Søgeresultater flader ofte OCLC Research Public License 2.0 ud til et slogan. Dette er de sædvanlige fejllæsninger. OCLC-2.0 er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.
- OCLC Research Public License 2.0 tvinger dig ikke til at åbne hele din applikation. Den gensidige pligt bliver på de dækkede filer.
- Det er ikke "tilladelig med ekstra papirarbejde." Ændrer du en dækket fil og sender den ud, skal den fils kildekode være tilgængelig under samme licens.
Hvordan OCLC-2.0 adskiller sig fra nærliggende licenser
Disse licenser forveksles ofte med OCLC-2.0, 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.
- OCLC-2.0
- En sjælden forskningslicens med gensidige kildekode-pligter. Læs den faktiske tekst: der findes kun lidt fast praksis om dens præcise rækkevidde.
- MPL-1.1
- Mozilla-licensen fra 1998. Kildekode-pligten hænger på de filer, du har ændret, ikke på hver MPL-fil, du sender ud, og den har ingen bro til GPL.
Ofte stillede spørgsmål om OCLC Research Public License 2.0
Svar på almindelige spørgsmål om, hvad OCLC Research Public License 2.0 kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.
Hvad er OCLC Research Public License 2.0?
OCLC Research Public License 2.0 kommer fra OCLC, biblioteksservice-kooperativet, og dækker den forskningssoftware, de har udgivet. Den er gensidig, hvilket betyder, at licensen kræver, at den dækkede kode og dine ændringer i den forbliver tilgængelige under samme vilkår, når du distribuerer. Den bærer også sin egen attribution- og notitsformulering plus en bestemmelse mod at bruge OCLC's navn til at anbefale dit produkt. Licensen er stort set fraværende fra de gængse pakkeregistre, så dukker en op i dit inventar, er den som regel kommet ind via en vendored kopi eller en intern fork.
Hvad kræver OCLC-2.0, når I sender et produkt ud?
Du opfylder kildekode-betingelsen, når den dækkede kode og dine ændringer i den er tilgængelige under OCLC-licensen for alle, du har distribueret til. Du har styr på notitserne, når OCLC's copyright- og attributionsformulering følger med hver kopi, i den form licensteksten beder om. Du holder dig på den rigtige side af endorsement-klausulen, når intet i din markedsføring antyder, at OCLC står bag eller sponsorerer dit produkt. Du har gjort det arbejde, denne licens kræver, når nogen har læst hele teksten og skrevet ned, hvilke dele af dit build gensidigheden rækker ind i.
Udløser det ekstra pligter at hoste et produkt, der bruger OCLC-2.0?
Hosting alene udløser som regel ikke kildekodepligten for OCLC-2.0. At sende en binær fil, et container-image eller et on-prem-build ud gør. Notitsen følger stadig med hver kopi, I giver videre.
Kan jeg holde min applikation lukket, hvis jeg bruger OCLC-2.0?
OCLC-2.0 er bibliotek-copyleft. Jeres applikation kan forblive lukket, hvis modtagere kan skifte biblioteket ud med deres eget build. Statisk linking gør det dyrt. Biblioteket selv skal stadig følge med tilsvarende kildekode og notitser. Bekræft linking-historien på komponenten, og registrer den.
Hvad er tilsvarende kildekode for OCLC-2.0?
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 OCLC-2.0 sig fra Mozilla Public License 1.1?
OCLC-2.0 kræver dette: En sjælden forskningslicens med gensidige kildekode-pligter. Læs den faktiske tekst: der findes kun lidt fast praksis om dens præcise rækkevidde. Mozilla Public License 1.1 kræver dette: Mozilla-licensen fra 1998. Kildekode-pligten hænger på de filer, du har ændret, ikke på hver MPL-fil, du sender ud, og den har ingen bro til GPL. Åbn Mozilla Public 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 OCLC-2.0 til en køber?
OCLC-2.0 har en katalogrække markeret som copyleft, så et punkt om kildekode-tilbud dukker op på projektets tjekliste i konteksterne Distribueret binær og Blandet. Fordi licensen er sjælden, finder hentningen ofte ingen matchende referencetekst, og resultatet lander som unconfirmed eller not found frem for som et confirmed match. Det er det ærlige udfald, og det venter på dig. Indsæt teksten fra pakken, accepter resultatet, og komponenten opfører sig som alle andre.
Hvor registrerer jeg OCLC-2.0 til en køber?
OCLC-2.0 har en katalogrække markeret som copyleft, så et punkt om kildekode-tilbud dukker op på projektets tjekliste i konteksterne Distribueret binær og Blandet. Fordi licensen er sjælden, finder hentningen ofte ingen matchende referencetekst, og resultatet lander som unconfirmed eller not found frem for som et confirmed match.
Det er det ærlige udfald, og det venter på dig. Indsæt teksten fra pakken, accepter resultatet, og komponenten opfører sig som alle andre.
Læs /docs/reviewing-component om forlø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.