Spring til hovedindhold
SourceTrust
Se andre licenser

MPL-1.1

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

På denne side

Hvad den gør

MPL-1.1 er forgængeren, som MPL-2.0 blev skrevet for at afløse, og de to trækker kildekode-grænsen forskelligt. Efter afsnit 3.2 i MPL-1.1 hænger pligten til at gøre kildekode tilgængelig på enhver Modification, du skaber eller bidrager til. For dækkede filer, du sender ud uændret, beder afsnit 3.6 om en notits om, at deres kildekode er tilgængelig under MPL, og hvor den findes. MPL-2.0 afsnit 3.2 udvidede den pligt til al Covered Software, du distribuerer i eksekverbar form, ændret eller ej. Copyleft betyder her, at licensen kræver, at den kildekode forbliver under MPL, mens dine egne adskilte filer forbliver dine. MPL-1.1 har heller ingen bro til GPL, hvilket er derfor, så meget kode fra Mozilla-tiden blev sendt ud med en tri-licens-header, der nævner MPL, GPL og LGPL sammen.

Detaljer

Du møder MPL-1.1 i gamle hjørner: ældre Java- og .NET-biblioteker og kode fra før omlicenseringsbølgen i 2012. Den praktiske pligt er snævrere end under MPL-2.0. Har du rettet i en dækket fil, skal kildekoden til den rettelse være tilgængelig for alle, der fik din eksekverbare fil. Afsnit 3.2 holder den tilgængelig i tolv måneder efter, den først blev gjort tilgængelig, eller seks måneder efter, du udgiver en senere version af den ændring. Sendte du filerne ud uændret, skylder du notitsen i afsnit 3.6 og en henvisning til kildekoden, ikke en hostingpligt af din egen. Det, der gør ondt, er kompatibiliteten. Indeholder dit produkt også GPL-kode, er en MPL-1.1-fil et reelt problem, medmindre pakken udtrykkeligt er multi-licenseret, så læs filheaderne i stedet for pakkens metadata.

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

Når du distribuerer en binær fil, der indeholder MPL-1.1-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.2, når alle, der modtog din eksekverbare fil, kan få kildekoden til hver dækket fil, du har ændret, og den kildekode forbliver tilgængelig i de tolv måneder, bestemmelsen sætter.

  2. Du har håndteret uændrede dækkede filer, når din eksekverbare fil bærer notitsen fra afsnit 3.6: at deres kildekode er tilgængelig under MPL, og hvordan og hvor den kan hentes.

  3. Du har håndteret GPL-spørgsmålet, når du har læst de faktiske filheadere og ved, om pakken er ren MPL-1.1 eller en tri-licens.

  4. Du har notitserne i orden, når hver dækket fil, du giver videre, stadig bærer sin MPL-1.1-header, og licensteksten følger med distributionen.

De pligter, MPL-1.1 navngiver

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

Hvis du har skabt eller bidraget til en Modification, skal kildekoden til den ændring være tilgængelig for alle, der fik din eksekverbare fil, i den periode afsnit 3.2 fastsætter.

Medtag notice

For dækkede filer, du sender uændret, skal du medtage en notits om, at deres kildekode er tilgængelig under MPL, og hvor den findes.

Det skal du være opmærksom på

  • Teams behandler MPL-1.1 og MPL-2.0 som udskiftelige. Det er de ikke: 1.1 afgrænser kildekode-pligten til dine Modifications og har ingen bro til GPL, så et blandet build afhænger af tri-licens-headeren.
  • Kildekode-arkivet bliver taget ned en måned efter release. Afsnit 3.2 beder om tolv måneder fra, at kildekoden først blev tilgængelig, eller seks efter en senere version af den ændring, så hold det oppe, eller peg på et permanent upstream-tag.
  • En gammel afhængighed antages at være død og bliver sprunget over i gennemgangen. Gammel MPL-1.1-kode ryger stadig med i din binære fil, så den hører til i inventaret som alt andet.

Hvad Mozilla Public License 1.1 ikke gør

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

  • Mozilla Public License 1.1 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 MPL-1.1 adskiller sig fra nærliggende licenser

Disse licenser forveksles ofte med MPL-1.1, 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-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.
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.
CDDL-1.0
Suns filbaserede copyleft. Det er grunden til, at ZFS ligger uden for Linux-kernen: CDDL-kode kan ikke kombineres med 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.

Ofte stillede spørgsmål om Mozilla Public License 1.1

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

Hvad er Mozilla Public License 1.1?

MPL-1.1 er forgængeren, som MPL-2.0 blev skrevet for at afløse, og de to trækker kildekode-grænsen forskelligt. Efter afsnit 3.2 i MPL-1.1 hænger pligten til at gøre kildekode tilgængelig på enhver Modification, du skaber eller bidrager til. For dækkede filer, du sender ud uændret, beder afsnit 3.6 om en notits om, at deres kildekode er tilgængelig under MPL, og hvor den findes. MPL-2.0 afsnit 3.2 udvidede den pligt til al Covered Software, du distribuerer i eksekverbar form, ændret eller ej. Copyleft betyder her, at licensen kræver, at den kildekode forbliver under MPL, mens dine egne adskilte filer forbliver dine. MPL-1.1 har heller ingen bro til GPL, hvilket er derfor, så meget kode fra Mozilla-tiden blev sendt ud med en tri-licens-header, der nævner MPL, GPL og LGPL sammen.

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

Du opfylder afsnit 3.2, når alle, der modtog din eksekverbare fil, kan få kildekoden til hver dækket fil, du har ændret, og den kildekode forbliver tilgængelig i de tolv måneder, bestemmelsen sætter. Du har håndteret uændrede dækkede filer, når din eksekverbare fil bærer notitsen fra afsnit 3.6: at deres kildekode er tilgængelig under MPL, og hvordan og hvor den kan hentes. Du har håndteret GPL-spørgsmålet, når du har læst de faktiske filheadere og ved, om pakken er ren MPL-1.1 eller en tri-licens. Du har notitserne i orden, når hver dækket fil, du giver videre, stadig bærer sin MPL-1.1-header, og licensteksten følger med distributionen.

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

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

MPL-1.1 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-1.1?

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

MPL-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. Mozilla Public License 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. Åbn Mozilla Public License 2.0-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-1.1 til en køber?

MPL-1.1 har sin egen katalogrække, markeret som copyleft, så et punkt om kildekode-tilbud dukker op på projektets tjekliste i konteksterne Distribueret binær og Blandet. Et rent SaaS-projekt ser intet. Hentningen sammenligner den tekst, den finder i pakken, med det angivne id. En tri-licenseret fil lander ofte som mismatch frem for som confirmed match, fordi headeren ikke er den rene MPL-1.1-tekst. Det resultat venter på, at du accepterer eller retter det.

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

MPL-1.1 har sin egen katalogrække, markeret som copyleft, så et punkt om kildekode-tilbud dukker op på projektets tjekliste i konteksterne Distribueret binær og Blandet. Et rent SaaS-projekt ser intet.

Hentningen sammenligner den tekst, den finder i pakken, med det angivne id. En tri-licenseret fil lander ofte som mismatch frem for som confirmed match, fordi headeren ikke er den rene MPL-1.1-tekst.

Det resultat venter på, at du accepterer eller retter det. Læs /docs/reviewing-component om det forløb.

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 1.1 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.