Spring til hovedindhold
SourceTrust
Se andre licenser

EPL-2.0

Eclipse Public License 2.0

Eclipse-familiens copyleft afgrænset til hvert Contribution. Den bliver GPL-kompatibel, kun når projektet udpeger en Secondary License.

På denne side

Hvad den gør

EPL-2.0 er licensen bag Eclipse IDE, Jakarta EE-artefakter og JUnit 5 og den ene gren af Jettys dobbeltlicens med EPL-2.0 eller Apache-2.0. Dens gensidighed hænger på hvert Contribution og på det Program, du distribuerer i objektform. Gensidighed betyder her, at den dækkede kode skal forblive tilgængelig under samme licens, hvilket er et lidt bredere net end MPL's afgrænsning pr. fil. Et separat modul, du selv har skrevet og distribuerer ved siden af Programmet, forbliver dit. To bestemmelser afgør de fleste virkelige sager. Afsnit 3.1 gør kildekoden til Programmet tilgængelig for den, der modtager objektkoden. Afsnit 4 gør, at du skal forsvare de øvrige bidragydere, hvis du sælger garanti eller support, og nogen sagsøger på den baggrund.

Detaljer

Kompatibilitetslinjen er der, hvor denne licens bliver citeret forkert. EPL-2.0 kan kombineres med GPL-kode, men kun gennem Secondary Licenses-mekanismen, og den mekanisme udpeger GNU General Public License version 2.0 eller enhver senere version. Udpegningen foretages af projektet i dets egen notitsfil. Du kan ikke selv vælge den for en andens pakke, så tjek projektets notits, før du planlægger en blanding. Den anden overraskelse er kommerciel: sælger du et Eclipse-baseret værktøj videre med en supportaftale, lægger afsnit 4 forsvaret af de øvrige bidragydere over på dig.

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

Når du distribuerer en binær fil, der indeholder EPL-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, når alle, der modtager Programmet i objektform, kan få dets kildekode og får at vide, hvor de finder den.

  2. Du holder dit eget modul uden for gensidigheden, når det er reelt selvstændigt arbejde, der distribueres ved siden af Programmet, og ikke en ændring inde i det.

  3. Du har håndteret dine egne Contributions, når de ændringer, du har lavet i EPL-kode, kommer ud igen under EPL-2.0 med notitserne i behold.

  4. Du har læst kompatibilitetsspørgsmålet rigtigt, når du har åbnet projektets notitsfil og set, om den udpeger en Secondary License.

  5. Du har styr på den kommercielle bestemmelse, når de, der sælger support, ved, at afsnit 4 gør sælgeren ansvarlig for at forsvare de øvrige bidragydere.

De pligter, EPL-2.0 navngiver

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

Æ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å

  • Folk gentager, at EPL-2.0 er GPL-kompatibel, punktum. Den er kun kompatibel, hvor projektet udpeger en Secondary License, og udpegningen dækker GPL version 2.0 eller enhver senere version, GPLv3 inklusive.
  • EPL beskrives som filbaseret ligesom MPL. Den afgrænser efter Contribution og efter det Program, du sender ud, så hold grænsen op mod dit build-output.
  • En forhandler underskriver en supportaftale uden at læse afsnit 4. Regn den forsvarspligt ind i prisen, eller hold support adskilt fra de EPL-artefakter, du sender ud.

Hvad Eclipse Public License 2.0 ikke gør

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

  • Eclipse 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 EPL-2.0 adskiller sig fra nærliggende licenser

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

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

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

Hvad er Eclipse Public License 2.0?

EPL-2.0 er licensen bag Eclipse IDE, Jakarta EE-artefakter og JUnit 5 og den ene gren af Jettys dobbeltlicens med EPL-2.0 eller Apache-2.0. Dens gensidighed hænger på hvert Contribution og på det Program, du distribuerer i objektform. Gensidighed betyder her, at den dækkede kode skal forblive tilgængelig under samme licens, hvilket er et lidt bredere net end MPL's afgrænsning pr. fil. Et separat modul, du selv har skrevet og distribuerer ved siden af Programmet, forbliver dit. To bestemmelser afgør de fleste virkelige sager. Afsnit 3.1 gør kildekoden til Programmet tilgængelig for den, der modtager objektkoden. Afsnit 4 gør, at du skal forsvare de øvrige bidragydere, hvis du sælger garanti eller support, og nogen sagsøger på den baggrund.

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

Du opfylder afsnit 3.1, når alle, der modtager Programmet i objektform, kan få dets kildekode og får at vide, hvor de finder den. Du holder dit eget modul uden for gensidigheden, når det er reelt selvstændigt arbejde, der distribueres ved siden af Programmet, og ikke en ændring inde i det. Du har håndteret dine egne Contributions, når de ændringer, du har lavet i EPL-kode, kommer ud igen under EPL-2.0 med notitserne i behold. Du har læst kompatibilitetsspørgsmålet rigtigt, når du har åbnet projektets notitsfil og set, om den udpeger en Secondary License. Du har styr på den kommercielle bestemmelse, når de, der sælger support, ved, at afsnit 4 gør sælgeren ansvarlig for at forsvare de øvrige bidragydere.

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

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

EPL-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 EPL-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 EPL-2.0 sig fra Eclipse Public License 1.0?

EPL-2.0 kræver dette: Eclipse-familiens copyleft afgrænset til hvert Contribution. Den bliver GPL-kompatibel, kun når projektet udpeger en Secondary License. Eclipse Public License 1.0 kræver dette: 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. Åbn Eclipse Public License 1.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 EPL-2.0 til en køber?

EPL-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, og ikke for en hostet tjeneste. Punktet venter på et menneske, og publicering er spærret, indtil nogen bekræfter det. SourceTrust fortæller dig ikke, om et EPL-artefakt og et GPL-artefakt i samme build passer sammen; det er en læsning af to licenstekster, ikke et opslag. Det, den gør, er at bære den gemte tekst med over i hver eksportfil.

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

EPL-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, og ikke for en hostet tjeneste. Punktet venter på et menneske, og publicering er spærret, indtil nogen bekræfter det.

SourceTrust fortæller dig ikke, om et EPL-artefakt og et GPL-artefakt i samme build passer sammen; det er en læsning af to licenstekster, ikke et opslag. Det, den gør, er at bære den gemte tekst med over i hver eksportfil.

Læs /docs/export-sbom om formaterne.

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