Spring til hovedindhold
SourceTrust
Se andre licenser

MPL-2.0

Mozilla Public License 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.

På denne side

Hvad den gør

MPL-2.0 trækker sin copyleft-grænse omkring filer, ikke omkring dit produkt. Copyleft betyder, at licensen kræver, at den dækkede kode forbliver tilgængelig under samme licens. Hver fil med MPL-header forbliver under MPL, og det, du selv skriver i dine egne adskilte filer, gør ikke. Sådan ender kode fra Firefox-tiden inde i lukkede produkter uden at trække dem åbne. Afsnit 3.1 giver modtagerne Source Code Form af Covered Software under MPL, og afsnit 3.2 siger, at en distribution i eksekverbar form skal fortælle dem, hvordan de får fat i den. Covered Software betyder de licenserede filer, som du distribuerer dem, så pligten afhænger ikke af, om du har rettet noget.

Detaljer

To læsninger koster teams penge her. Den første er, at MPL trækker hele produktet åbent, hvilket den ikke gør: dine adskilte filer er dine, og linking er ikke det afgørende. Den anden er, at du intet skylder, fordi du ikke har ændret noget. Den er forkert. Pligten i afsnit 3.1 og 3.2 hænger på de dækkede filer, du distribuerer, rettet eller urørt. Ændringer flytter, hvad den kildekode indeholder, ikke om du skylder den. Afsnit 3.3 er broen til GPL. Et Larger Work, der kombinerer MPL-filer med GPL-, LGPL- eller AGPL-kode, må også gå ud under den Secondary License, medmindre filerne er markeret Incompatible With Secondary Licenses. En hostet tjeneste skylder ingenting, for distribution betyder at give nogen en kopi, og MPL har ingen netværksklausul.

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

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

  1. Du opfylder afsnit 3.1 og 3.2, når alle, der får din eksekverbare fil, kan få kildekoden til MPL-filerne, uanset om du har rørt dem.

  2. Du har klaret oplysningsdelen, når din distribution siger, hvor den kildekode ligger, for afsnit 3.2 beder dig informere modtagerne og ikke bare have den liggende.

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

  4. Du har styr på notitserne, når MPL-headeren bliver stående i hver dækket fil, du giver videre, og licensteksten følger med distributionen.

  5. Du er fri for pligter i et hostet produkt, når intet forlader dine servere, for MPL har ingen klausul, der behandler netværksadgang som distribution.

De pligter, MPL-2.0 navngiver

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

Covered Software, du distribuerer i eksekverbar form, skal have kildekode tilgængelig under MPL, ændret eller ej.

Samme licens

Dækkede filer bliver under MPL. Dine egne adskilte filer kan blive under andre vilkår.

Det skal du være opmærksom på

  • Teams afskriver det hele med 'vi har ikke ændret noget, så det gælder ikke'. Udgiv kildekoden til de dækkede filer alligevel, eller link til det upstream-release, du byggede fra.
  • Teams antager, at MPL trækker hele deres kodebase åben, og river afhængigheden ud. Tjek filgrænsen først; adskilte filer forbliver lukkede efter designet.
  • Ingen fortæller modtagerne, hvor kildekoden er, så afsnit 3.2 bliver overset, selvom koden er offentlig. Skriv URL'en i release-noterne og i notitsfilen.
  • En pakke angiver MPL-2.0-no-copyleft-exception og bliver behandlet som almindelig MPL-2.0. Den variant fjerner muligheden for at omlicensere et større værk under GPL, så læs det angivne id.

Hvad Mozilla Public License 2.0 ikke gør

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

  • MPL-2.0 trækker ikke hele din applikation åben. Gensidigheden stopper ved filer, der bærer MPL-headeren.
  • Den venter ikke på, at du ændrer en dækket fil. Afsnit 3.1 og 3.2 hæfter på Covered Software, du distribuerer i eksekverbar form, rettet eller urørt.

Hvordan MPL-2.0 adskiller sig fra nærliggende licenser

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

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.
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-2.0
Eclipse-familiens copyleft afgrænset til hvert Contribution. Den bliver GPL-kompatibel, kun når projektet udpeger en Secondary License.
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 Mozilla Public License 2.0

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

Hvad er Mozilla Public License 2.0?

MPL-2.0 trækker sin copyleft-grænse omkring filer, ikke omkring dit produkt. Copyleft betyder, at licensen kræver, at den dækkede kode forbliver tilgængelig under samme licens. Hver fil med MPL-header forbliver under MPL, og det, du selv skriver i dine egne adskilte filer, gør ikke. Sådan ender kode fra Firefox-tiden inde i lukkede produkter uden at trække dem åbne. Afsnit 3.1 giver modtagerne Source Code Form af Covered Software under MPL, og afsnit 3.2 siger, at en distribution i eksekverbar form skal fortælle dem, hvordan de får fat i den. Covered Software betyder de licenserede filer, som du distribuerer dem, så pligten afhænger ikke af, om du har rettet noget.

Hvad kræver MPL-2.0, når I sender et produkt ud?

Du opfylder afsnit 3.1 og 3.2, når alle, der får din eksekverbare fil, kan få kildekoden til MPL-filerne, uanset om du har rørt dem. Du har klaret oplysningsdelen, når din distribution siger, hvor den kildekode ligger, for afsnit 3.2 beder dig informere modtagerne og ikke bare have den liggende. Du holder din egen kode udenfor, når dit arbejde ligger i separate filer og ikke inde i dem med MPL-header, for licensen afgrænser pr. fil. Du har styr på notitserne, når MPL-headeren bliver stående i hver dækket fil, du giver videre, og licensteksten følger med distributionen. Du er fri for pligter i et hostet produkt, når intet forlader dine servere, for MPL har ingen klausul, der behandler netværksadgang som distribution.

Udløser det ekstra pligter at hoste et produkt, der bruger MPL-2.0?

Hosting alene udløser som regel ikke kildekodepligten for MPL-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 MPL-2.0?

MPL-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 MPL-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 MPL-2.0 sig fra Mozilla Public License 1.1?

MPL-2.0 kræver dette: Filbaseret copyleft. MPL-filerne forbliver åbne, når du sender en binær fil ud, ændret eller ej. Dine egne adskilte filer er dine. 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 MPL-2.0 til en køber?

MPL-filer bærer deres licens i en header, så hentningen finder som regel rigtig MPL-tekst inde i pakkens artefakt og sammenligner den med det angivne id. Et confirmed match udfylder teksten; alt andet venter på, at en person accepterer det. Kataloget markerer MPL-2.0 som copyleft, så et punkt om kildekode-tilbud dukker op på tjeklisten i konteksterne Distribueret binær og Blandet, og aldrig for et rent SaaS-projekt. SourceTrust udgiver ikke din kildekode og hoster ikke et spejl.

Hvor registrerer jeg MPL-2.0 til en køber?

MPL-filer bærer deres licens i en header, så hentningen finder som regel rigtig MPL-tekst inde i pakkens artefakt og sammenligner den med det angivne id. Et confirmed match udfylder teksten; alt andet venter på, at en person accepterer det.

Kataloget markerer MPL-2.0 som copyleft, så et punkt om kildekode-tilbud dukker op på tjeklisten i konteksterne Distribueret binær og Blandet, og aldrig for et rent SaaS-projekt. SourceTrust udgiver ikke din kildekode og hoster ikke et spejl.

Læs /docs/auto-fetch-license om hvordan hentningen og sammenligningen fungerer.

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 Mozilla Public License 2.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.