Er det noen forskjell i mening mellom programvarelisensene Boost og MIT?

MIT

MIT-lisensen (MIT)

Copyright (c) < år > < rettighetshavere >

Tillatelse gis herved gratis til enhver person som oppnår en kopi av denne programvaren og tilhørende dokumentasjonsfiler («programvaren») for å håndtere programvaren uten begrensning, inkludert uten begrensning rettighetene til å bruke, kopiere, endre, slå sammen, publisere, distribuere, underlisensiere og / eller selge kopier av programvaren, og for å tillate personer som programvaren leveres til, til å gjøre det, underlagt følgende vilkår:

Ovennevnte copyrightmerknad og denne tillatelsesmeldingen skal være inkludert i alle kopier eller vesentlige deler av programvaren .

PROGRAMVAREN LEVERES «SOM DET ER», UTEN GARANTI FOR NOE SLAG, UDTRYKT ELLER UNDERFORSTÅTT, INKLUDERT MEN IKKE BEGRENSET TIL GARANTIER FOR SALGSMERKELIGHET, EGNETHET FOR ET SÆRLIGT FORMÅL OG IKKE OVERTREDELSE. INGEN HENDELSER SKAL FORFATTERE ELLER INNEHAVER AV RETTIGHETER ANSVARLIG FOR KRAV, SKADER ELLER ANDRE ANSVAR, SOM I HANDLING AV KONTRAKT, VILKÅRING ELLER ANNET, FØLGENDE FRA, UTEN ELLER I FORBINDELSE MED PROGRAMVAREN ELLER BRUKEN ELLER ANDRE FORHANDLINGER I DET PROGRAMVARE.

Boost

Boost Software License – Versjon 1.0 – 17. august 2003

Tillatelse gis herved gratis til enhver person eller organisasjon som skaffer en kopi av programvaren og tilhørende dokumentasjon som dekkes av denne lisensen («programvaren») for å bruke, reprodusere, vise, distribuere, utføre og overføre programvaren, og for å utarbeide avledede verk av programvaren, og for å tillate tredjeparter til hvem Programvaren er innrettet til å gjøre det, alt underlagt følgende:

Merknadene om opphavsrett i programvaren og hele denne erklæringen, inkludert ovennevnte lisensbevilling, denne begrensningen og følgende ansvarsfraskrivelse, må inkluderes i alle kopier av programvaren, helt eller delvis, og alle avledede verk av programvaren, med mindre slike kopier eller avledede verk utelukkende er i form av maskinutførbar objektkode generert av en kildespråkprosessor .

PROGRAMVAREN LEVERES «SOM DET ER» UTEN GARANTI FOR NOE SLAG, UDTRYKT ELLER UNDERFORSTÅTT, INKLUDERT, MEN IKKE BEGRENSET TIL GARANTIER FOR SALGSMERKELIGHET, FITNESS FOR ET SÆRLIG FORMÅL, TITEL OG INFRA INFRING. INGEN HENDELSER SKAL COPYRIGHT-INNEHAVERE ELLER NOEN DISTribuerER PROGRAMVAREN ANSVARLIG FOR SKADER ELLER ANDRE ANSVAR, SOM I KONTRAKT, VIRKELSE ELLER ANNET, OPPFALLT FRA, UTEN ELLER I FORBINDELSE MED PROGRAMVAREN ELLER BRUKEN ELLER ANDRE BEHANDLINGER I PROGRAMMET.


Mens MIT-lisensen siterer at alle kopier av programvaren må ha lisensen ved siden av seg, uttrykker den ikke det som teller som en kopi ( dvs. snakker vi den kjørbare binæren, eller kildekoden?). Det refererer også til «betydelige porsjoner», som virker veldig subjektivt. Boost-programvarelisensen er derimot mye mer spesifikk.


Spørsmålet mitt er, med tanke på ovenstående, er det noen meningsfulle forskjeller mellom de to lisensene? Hvilke implikasjoner kan disse forskjellene ha?

Kommentarer

  • Det er også andre, subtile, endringer som kan eller ikke kan forårsake noen forskjell; for eksempel er listene over tildelte rettigheter forskjellige, og Boost refererer til » personer eller organisasjoner / tredjeparter » mens MIT kun refererer til » personer «.
  • FWIW, Boost gir en begrunnelse for lisensen: boost.org/users/license.html#Rationale

Svar

De største forskjellene:

  • MIT har en generell «avtale i programvaren uten begrensning» -klausul, der Boost oppregner ting en bruker har lov til å gjøre. For de slags ting som gjennomsnittlig bruker sannsynligvis vil bruke programvaren til, er det kanskje ikke noen praktisk forskjell, men MIT-lisensen er betydelig bredere.
  • En kopi av Boost-lisensen trenger ikke å bli inkludert i en kjørbar binær, mens en kopi av MIT-lisensen gjør det.
  • Ansvarsfraskrivelsen fra Boost dekker «alle som distribuerer programvaren» i tillegg til forfattere og rettighetshavere; MIT-lisensen gjør det ikke.

Andre mulige forskjeller forskjeller:

  • En organisasjon som ikke er en bedrift, kan ikke være i stand til å håndtere MIT-lisensiert programvare som en organisasjon, selv om jeg er usikker på dette. Du kan sannsynligvis holde en hær av advokater som krangler om dette poenget i årevis.
  • MIT-lisensen krever kanskje ikke inkludering av ansvarsfraskrivelsen med lisenserklæringen. Det er uklart om ansvarsfraskrivelsen er en del av «denne tillatelsesmeldingen» eller ikke.

Kommentarer

  • takk! Hva gjør mener du med » ikke-bedrifts-person » del?
  • Bedriftens personlighet : i USA regnes et selskap som en ‘ person ‘ for mange formål. Andre organisasjonsstrukturer er ikke.
  • Så i England og Wales er ikke et partnerskap en juridisk person (bare de enkelte partnerne). Tilsvarende er en ikke-innlemmet klubb ikke en juridisk person (vanligvis er styringskomiteen personlig ansvarlig.
  • Når det gjelder organisasjoner som ikke er bedriftspersoner: er det forsvarlig å endre MIT-lisensen for å være klarere, slik den er gjort av Boost-en, forutsatt en begrenset kostnad? Sider som choosealicense.com/licenses/mit anbefaler MIT-lisensen som et rimelig alternativ.

Svar

Det vil hjelpe å ha konteksten til spørsmålet om hvorfor det betyr noe for deg om MIT- og Boost-lisensene er eller ikke er likeverdige .

For illustrasjonsformål, tenk at OpenBSD er kjent for å være ganske streng med lov om opphavsrett. OpenBSD-prosjektet har dette å si på forskjellene mellom 2-klausul BSD-lisensen og ISC-lisensen (som i dag er kjent som OpenBSD-lisensen):

http://www.openbsd.org/policy.html

ISC-opphavsretten tilsvarer funksjonelt to-sikt BSD copyright med språk fjernet som blir unødvendig av Bernkonvensjonen. Dette er den foretrukne lisensen for ny kode innlemmet i OpenBSD. En eksemplellisens er tilgjengelig i filen /usr/share/misc/license.template .

I utgangspunktet kommer svaret på spørsmålet ditt sannsynligvis alt sammen til Bernkonvensjonen også.

Når det gjelder det andre svaret, om du må inkludere teksten til MIT-lisensen eller eventuell resulterende distribusjon, er jeg for eksempel lite skeptisk, for ofte, med de kortere lisensene, er ofte hele teksten av lisensen inkludert i hver enkelt fil med lisensen (dette er vanligvis tilfelle innen BSD-fellesskapet, og OpenBSD og NetBSD-kildetrær, for eksempel, har ikke engang en egen COPYRIGHT -fil i roten i det hele tatt – NetBSD flyttet den til share/legal/ , men OpenBSD har ikke en i det hele tatt, bortsett fra license.template , som er ment bare for den nye torsken e). Fra et praktisk synspunkt i den BSD-kompatible verden tror jeg at den opprinnelige lisensen effektivt blir kildekoden på dette punktet, og at du ikke trenger å oppgi kildekoden med kjørbare filer, så kanskje Boost-lisensen er bare en avklaring som er ment å lette tankegangen gitt den brede konteksten biblioteket brukes i.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *