Spring til hovedindhold
SourceTrust
Se andre licenser

CDDL-1.0

Common Development and Distribution License 1.0

Suns filbaserede copyleft. Det er grunden til, at ZFS ligger uden for Linux-kernen: CDDL-kode kan ikke kombineres med GPL.

På denne side

Hvad den gør

Common Development and Distribution License er Suns omskrivning af MPL-1.1, og den arver filafgrænsningen. Copyleft betyder her, at licensen kræver, at de dækkede filer forbliver tilgængelige under samme licens. Filer med CDDL-header forbliver CDDL, og dine egne adskilte filer gør ikke. Du møder den i OpenZFS, i referenceimplementeringerne af JAXB og JavaMail, i Jersey og Grizzly før flytningen til Jakarta og i de gamle javax.annotation-artefakter. Afsnit 3.1 holder Source Code til de dækkede filer tilgængelig under CDDL, og afsnit 3.5 gør, at en distribution i eksekverbar form skal oplyse, hvor den findes.

Detaljer

Den daglige pligt er mild. Udgiv kildekoden til de dækkede filer, når du sender dem ud, behold headerne, og dine egne filer forbliver lukkede. Det dyre er kompatibiliteten. CDDL og GPL kan ikke kombineres, og derfor er ZFS ikke lagt ind i Linux-kernen, og derfor sender distributioner OpenZFS ud som et separat modul. Blander dit produkt CDDL- og GPL-kode, har du et licensspørgsmål og ikke et pakningsspørgsmål. Mange Jakarta EE-artefakter flyttede desuden fra CDDL til EPL-2.0, da de kom til Eclipse Foundation, så svaret afhænger af den version, du har låst.

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.

Hvad CDDL-1.0 kræver, når I sender kode ud

Når du distribuerer en binær fil, der indeholder CDDL-1.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.

  1. Du opfylder afsnit 3.1, når Source Code til hver dækket fil, du sender ud i eksekverbar form, er tilgængelig under CDDL for den, der modtog den.

  2. Du har klaret notitsdelen, når din distribution i eksekverbar form oplyser, at kildekoden findes, og peger på, hvor den kan hentes, hvilket er det, afsnit 3.5 beder om.

  3. Du holder din egen kode udenfor, når dit arbejde ligger i separate filer og ikke inde i dem med CDDL-header, for licensen afgrænser pr. fil.

  4. Du har besvaret det svære spørgsmål, når du ved, at ingen GPL-licenseret kode i samme produkt er kombineret med disse CDDL-filer.

  5. Du er fri i et hostet produkt, når intet bliver distribueret, for CDDL har ingen klausul, der behandler netværksadgang som distribution.

De pligter, CDDL-1.0 navngiver

Notitsen følger stadig med kopien. Oven i det navngiver CDDL-1.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

Ændringer i dækkede filer, du distribuerer, skal være tilgængelige som kildekode under denne licens.

Samme licens

Gensidigheden bliver på de dækkede moduler. Hvor langt et 'modul' rækker, er det sædvanlige juristspørgsmål.

Det skal du være opmærksom på

  • Et javax.*-artefakt bliver vinket igennem som 'standard Java'. Pakken er licenseret som alt andet, så registrér dens CDDL-tekst og dens kildekode-placering.
  • GPL- og CDDL-komponenter sidder i samme build, og ingen siger noget. Adskil dem, udskift den ene, eller tag kombinationen til en jurist, før du sender ud.
  • Man antager, at CDDL-1.0 og CDDL-1.1 er væsensforskellige. Det er de knap nok, så brug ikke gennemgangstid der; brug den på GPL-spørgsmålet.
  • Kildekode-pligten læses, som om den kun gælder filer, du har rettet. Den følger de dækkede filer, du distribuerer, så udgiv den kildekode i begge tilfælde.

Hvad Common Development and Distribution License 1.0 ikke gør

Søgeresultater flader ofte Common Development and Distribution License 1.0 ud til et slogan. Dette er de sædvanlige fejllæsninger. CDDL-1.0 er en tilladelse med betingelser, ikke en tilladelse til at springe papirarbejdet nedenfor over.

  • Common Development and Distribution License 1.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 CDDL-1.0 adskiller sig fra nærliggende licenser

Disse licenser forveksles ofte med CDDL-1.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.

CDDL-1.0
Suns filbaserede copyleft. Det er grunden til, at ZFS ligger uden for Linux-kernen: CDDL-kode kan ikke kombineres med GPL.
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.
EPL-1.0
Den ældre Eclipse-licens. Samme Contribution-baserede pligt som EPL-2.0, men uden bro til GPL, så en blanding med GPL-kode er et reelt problem.
GPL-2.0-or-later
GPL-2.0 kræver kildekode, når du giver nogen en binær fil. At køre den på egne servere udløser intet. Triggeren er at levere en kopi, ikke blot at bruge den.

Ofte stillede spørgsmål om Common Development and Distribution License 1.0

Svar på almindelige spørgsmål om, hvad Common Development and Distribution License 1.0 kræver, hvornår pligterne gælder, og hvilken dokumentation der skal følge med en release.

Hvad er Common Development and Distribution License 1.0?

Common Development and Distribution License er Suns omskrivning af MPL-1.1, og den arver filafgrænsningen. Copyleft betyder her, at licensen kræver, at de dækkede filer forbliver tilgængelige under samme licens. Filer med CDDL-header forbliver CDDL, og dine egne adskilte filer gør ikke. Du møder den i OpenZFS, i referenceimplementeringerne af JAXB og JavaMail, i Jersey og Grizzly før flytningen til Jakarta og i de gamle javax.annotation-artefakter. Afsnit 3.1 holder Source Code til de dækkede filer tilgængelig under CDDL, og afsnit 3.5 gør, at en distribution i eksekverbar form skal oplyse, hvor den findes.

Hvad kræver CDDL-1.0, når I sender et produkt ud?

Du opfylder afsnit 3.1, når Source Code til hver dækket fil, du sender ud i eksekverbar form, er tilgængelig under CDDL for den, der modtog den. Du har klaret notitsdelen, når din distribution i eksekverbar form oplyser, at kildekoden findes, og peger på, hvor den kan hentes, hvilket er det, afsnit 3.5 beder om. Du holder din egen kode udenfor, når dit arbejde ligger i separate filer og ikke inde i dem med CDDL-header, for licensen afgrænser pr. fil. Du har besvaret det svære spørgsmål, når du ved, at ingen GPL-licenseret kode i samme produkt er kombineret med disse CDDL-filer. Du er fri i et hostet produkt, når intet bliver distribueret, for CDDL har ingen klausul, der behandler netværksadgang som distribution.

Udløser det ekstra pligter at hoste et produkt, der bruger CDDL-1.0?

Hosting alene udløser som regel ikke kildekodepligten for CDDL-1.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 CDDL-1.0?

CDDL-1.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 CDDL-1.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 CDDL-1.0 sig fra Mozilla Public License 1.1?

CDDL-1.0 kræver dette: Suns filbaserede copyleft. Det er grunden til, at ZFS ligger uden for Linux-kernen: CDDL-kode kan ikke kombineres med GPL. 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 CDDL-1.0 til en køber?

CDDL-1.0 og CDDL-1.1 har begge katalogrækker markeret som copyleft, så et punkt om kildekode-tilbud dukker op på projektets tjekliste i konteksterne Distribueret binær og Blandet, og aldrig for et rent SaaS-projekt. Punktet venter på et menneske, og publicering er spærret, indtil nogen bekræfter det. SourceTrust fortæller dig ikke, om en CDDL-komponent og en GPL-komponent i samme build kan leve sammen. Den læsning er din.

Hvor registrerer jeg CDDL-1.0 til en køber?

CDDL-1.0 og CDDL-1.1 har begge katalogrækker markeret som copyleft, så et punkt om kildekode-tilbud dukker op på projektets tjekliste i konteksterne Distribueret binær og Blandet, og aldrig for et rent SaaS-projekt. Punktet venter på et menneske, og publicering er spærret, indtil nogen bekræfter det.

SourceTrust fortæller dig ikke, om en CDDL-komponent og en GPL-komponent i samme build kan leve sammen. Den læsning er din.

Læs /docs/inventory-compliance om den oversigt, der viser hvert projekt, en komponent optræder i.

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 Common Development and Distribution License 1.0 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.