Hva du trenger å vite om GitHub-lisenser: hvordan velge og legge til

GitHub-lisenser – hva snakker vi om? For å lage programvare må du ikke bare skrive den, men også bestemme hva brukere eller utviklere har rett til å gjøre med den. Hvis noen lager et gratis program for alle, gjør han en god gjerning, men den som bruker det må begrunne hvordan han bruker det. For eksempel, hvis et selskap i sin virksomhet vil jobbe med et hvilket som helst gratis kontor (for eksempel LibreOffice), må det for revisorene kunne bevise at det har rett til å gjøre det. For å gjøre dette vil det være nok å presentere den aktuelle lisensen. Hvis utvikleren glemmer å formulere det, kan firmaet komme i en vanskelig posisjon.
Klassifisering av lisenser og typer lisenser [/ caption] Når du oppretter en applikasjon, må utvikleren bestemme hvilke handlinger med programmet hans som skal tillates og hva som ikke vil. For eksempel kan vi snakke ikke bare om å bruke, men også om å studere tekstene til programmer eller gjøre sine egne justeringer av programvareproduktet. GitHub er en av de største tjenestene for samarbeidsprosjektutvikling. Samtidig kan de jobbe her ikke bare med gratis, men også med kommersielle prosjekter. Ved å spesifisere en passende lisens, vil utviklere eliminere forvirring om hvordan de skal bruke det opprettede produktet. Problemet er at det finnes ulike typer lisenser, og det er ikke alltid lett å avgjøre hvilket alternativ som bør foretrekkes i et bestemt tilfelle. Dessuten er det ikke uvanlig at noen prosjekter ikke har lisens.Det er nødvendig å lære mer om lisensiering for å forstå hvilke rettigheter og plikter brukere har i ulike tilfeller.

Hvorfor trenger jeg å lisensiere Open Source-prosjekter på GitHub

Ved å spesifisere den nødvendige lisensen, kan utvikleren sørge for følgende:

1. Vilkår for bruk av programmet . De kan sørge for betaling av et gebyr eller, i noen eller alle tilfeller, tillate gratis bruk.
2. Noen ganger opprettes programmer for å utvikles av fellesskapet . I dette tilfellet er det viktig at alle som ønsker kan sette seg inn i programtekstene.
3. Når koden er tilgjengelig, kan noen gjøre endringer for å gjøre programmet funksjonelt og så pålitelig som mulig. Noen ganger kan forfatteren la alle gjøre dette, i andre tilfeller tilbyr han å sende en endring til ham, og gjør justeringer i prosjektet på egen hånd.
4. Du må bestemme om tredjeparter kan gjøre endringer i prosjektet og foreslå på deres vegne. I dette tilfellet er det nødvendig å indikere med hvilken lisens produktet deres skal være.

Ved å løse disse og lignende problemer, bestemmer forfatteren av applikasjonen i stor grad den fremtidige skjebnen til programvareproduktet han opprettet.

Hvilke typer lisenser finnes

En lisens er en avtale der den ene parten (lisensgiveren) etablerer en regel for at den andre parten (lisensinnehaveren) skal bruke produktet den oppretter. I praksis snakker vi ikke om signering av et dokument av partene, men om automatisk samtykke med tilsvarende rettigheter og plikter ved bruk av det. Det er praktisk talt ingen begrensninger for å spesifisere rettigheter og plikter. Den eneste betingelsen er at de må følge loven. Å lage dine egne lisenser er en vanskelig jobb da du må sørge for at den er forenlig med andre forskrifter. Det beste alternativet er å velge og bruke en av standardtypene for slike dokumenter. I praksis er det også vanlig å bruke multilisensiering. Oftest brukes i slike tilfeller to lisenser samtidig.Selv om forfatteren av programmet har rett til å selvstendig formulere reglene som brukerne må følge, har det i praksis utviklet seg bruk av et stort antall typer lisenser, hvorfra du kan velge den passende i de fleste tilfeller. Følgende er de mest populære alternativene som brukes på Git Hub i de fleste tilfeller. De vanligste lisensene som brukes på Git Hub er:
Programmereren må kunne velge en som passer til planene hans. For å gjøre dette riktig, må du forstå hvilke funksjoner som er iboende i visse arter.

Hvis forfatteren nekter å formulere dokumentet, vil i dette tilfellet opphavsrett gjelde, som leveres som standard av lovgivningen i landet hans. Fraværet av en lisens på denne måten betyr ikke at du kan gjøre hva du vil med programmet. Faktisk kan denne situasjonen betraktes som en av typene lisenser.

Hvordan velge en Github-lisens

Før du begynner å søke etter et passende alternativ, er det nødvendig at programmereren formulerer kravene sine, hvorfra han skal fortsette med videre lisensiering. Deretter bør du gjøre deg kjent med de typiske alternativene som tilsvarer forespørselen. Etter det må du studere den juridiske formuleringen nøye og ta en endelig beslutning om hva lisensen skal være. For å ta et informert valg, må du forstå hvilke rettigheter og plikter som bestemmes av en bestemt type lisens. For å gjøre det riktige valget kan du bruke spesielle tjenester kalt komparatorer. Her er noen eksempler:

1. https://choosealicense.com/. Denne siden inneholder veiledende spørsmål for å velge det riktige alternativet og detaljerte råd for å hjelpe deg med å forstå spesifikasjonene ved bruk.
2. https://opensource.org/licenses-siden er dedikert til å gjennomgå ulike gratis programvareløsninger.
3. Nettstedet https://tldrlegal.com/ kan sees på som et leksikon for ulike lisensalternativer. Den inneholder både presist juridisk språk og detaljerte kommentarer.

Sammenlign lisenser på https://choosealicense.com/ [[]] Det mest produktive valget er imidlertid å lese de relevante juridiske dokumentene nøye. Selv om dette er en tidkrevende aktivitet, vil likevel å studere tekstene gi utvikleren alle svarene han trenger.

Hvordan legge til en lisens til Github

Til tross for et omfattende utvalg av lisensalternativer, som i praksis har bevist sin effektivitet og pålitelighet, kan utvikleren ha sine egne ideer om hva lisensen skal være for programmet han har laget. I dette tilfellet gir tjenesten muligheten til å legge til din egen versjon eller justere den eksisterende. For å legge til en lisens til Github, må du følge disse trinnene:

1. Du må gå til hovedsiden til depotet ditt.
2. Du må klikke på knappen for å legge til en fil, og deretter velge «Opprett ny fil».
3. Deretter må du skrive inn filnavnet. For en lisens kan det være ett av to alternativer: LICENSE eller LICENCE.md. Store bokstaver er obligatorisk her.
4. Klikk for å velge en lisensmal til høyre for inndatafeltet for filnavn.
5. I menyen til venstre på siden velger du linjen «Legg til en lisens til prosjektet ditt». I dette tilfellet velges et alternativ fra eksisterende dokumenter.
6. Klikk deretter på «Gjennomgå og send inn»-linjen. Skriv deretter inn avtaleopplysningene deres.
7. Etter det er det nødvendig å avklare hva tilleggene eller endringene ble gjort. Deretter angir de om det valgte dokumentet ble rettet eller om vi snakker om å lage en annen versjon av lisensen.

Etter å ha bekreftet endringene, fullfører utvikleren prosedyren for å gjøre endringer i listen over lisenser på Git Hub-tjenesten.

Velg en lisens Github – Eksempler på populære lisenser på Git Hub

Deretter vil vi vurdere de alternativene som er de mest populære. Etter å ha forstått deres styrker og svakheter, vil programmereren kunne finne det riktige alternativet eller forstå hvordan man effektivt søker.

GPL

Denne lisensen kan kalles en av de mest populære. Det er klassisk for de som lager gratis programvare. Et av hovedkravene i dette dokumentet er at det
lar tredjeparter fritt endre programmet , men samtidig har de rett til å distribuere resultatet kun under samme lisens. Denne lisensen kan ha forskjellige versjoner. Den siste er den tredje. GPL ble brukt av utviklere av programmer som Drupal web content management system, MariaDB database management system, vektorgrafikk editor InkSkape og flere andre. Det er interessant å merke seg at SQL ikke bare bruker GPL, men også en kommersiell lisens.

LGPL

Denne tittelen oversettes til GNU Lesser General Public License GPL. For noen utviklere er GPL ikke egnet, da det skaper en forpliktelse for dem til å distribuere modifiserte produkter under samme lisens. Det særegne ved å bruke dette alternativet kan illustreres ved hvordan prosessen med å lisensiere bruken av biblioteker opprettet av en programmerer foregår. I dette tilfellet er det vanlig å vurdere følgende tre alternativer:

1. Når et bibliotek gir nye funksjoner, og ingen kommersielle biblioteker kan utføre en lignende oppgave, er bruken av GPL optimal.
2. Utvikleren i gratisbiblioteket har allerede implementert den eksisterende standarden. I dette området er det kommersielle alternativer med lignende funksjoner. I dette tilfellet vil det være praktisk å velge LGPL.
3. Når det kommer til en ny standard som faktisk konkurrerer med en kommersiell, er Apache-lisensen passende.

Denne standarden
tillater kommersiell bruk av bibliotekene . Hvis det gjøres endringer, må de samme vilkårene og betingelsene brukes for distribusjon. Enkel kodebruk lar imidlertid forholdene endre seg.

Eclipse Public License

Dette dokumentet
tillater distribusjon under andre lisenser, inkludert kommersielle . Hovedbetingelsen er at i de modifiserte verkene vil innovasjonene bli plassert i en egen modul. Denne lisensen har vunnet popularitet i utviklingen av Java-produkter. Et eksempel er programmeringsspråket Clojure, et rammeverk for testing av java-applikasjoner.

Mozilla offentlig lisens

Noen ser på dette dokumentet som et kompromiss mellom GPL og kommersielle lisenser. Det er et krav fra MPL å
ha offentlig tilgang til visse filer . Programvaren kan inneholde noen filer under denne lisensen, og andre uten den. Etter endringen er det tillatt å legge inn lisensen som er nødvendig (for eksempel kan det være en kommersiell), men dette er bare mulig under forutsetning av at tilgangen til filene utgitt under MPL fortsatt er åpen. I dette tilfellet bør sluttbrukeren gis informasjon om forfatterne av den originale programvaren. LibreOffice office, Mozilla-nettleser og andre programvareprodukter ble utgitt i samsvar med dette dokumentet.

Apache-lisens Github

AL kalles en liberal fri lisens. Denne funksjonen skyldes det faktum at det ikke er
noe krav om å frigi et derivatprodukt under de samme forholdene som før . Dette dokumentet brukes aktivt av Apache Software Foundation. Når du bruker det, er følgende tillatt:

1. Programvaren kan fortsatt brukes til kommersielle formål.
2. Endringer i søknader er tillatt.
3. Påfølgende redistribusjoner må inneholde navnet på den opprinnelige forfatteren.

Ved opprettelse av en ny variant har lisenshavere ingen forpliktelse til å oppgi den originale produktkoden. Denne lisensen har fått betydelig popularitet. Dette kan demonstreres ved å liste opp de velkjente programvareproduktene som utgis under denne typen lisens: Android-operativsystemet, rammeverket for å lage bedriftsapplikasjoner i Java, Apache-nettserveren. https://youtu.be/wyZq-EazOmU

MIT-lisens

Noen mennesker synes dette alternativet for gratis programvarelisens er det mest populære. Noen anser dens viktigste fordel for å være god kompatibilitet med ulike typer gratis eller kommersielle lisenser. De viktigste funksjonene er
muligheten til å endre koden, samt tillatelsen til å omdistribuere under andre lisenser etter valg av personen som gjorde endringene . Programvareproduktene som bruker dette dokumentet er: et JavaScript-bibliotek kalt JQuiery, en Atom-tekstredigerer, AngularJS – et rammeverk for utvikling i JavaScript.
Sammenligning av lisenser for Git Hub [/ caption]

Undervanns steiner

Noen ganger velger forfatteren først én versjon av lisensen, og ønsker senere å endre den. Hvis han opprettet programmet alene, vil en slik endring ikke være vanskelig. Men i tilfeller hvor det var mange deltakere i utviklingen, vil det ikke fungere uten deres samtykke. For eksempel vil skaperen av Linux, selv om han faktisk laget grunnlaget for operativsystemet, ikke kunne endre lisensen uten samtykke fra alle de programmererne som deltok i videreutviklingen. Ved omdistribuering under MPL kan ikke de som har gjort endringer i koden tilby filer under MPL under en annen lisens. Bruken av det nye dokumentet vil gjelde for andre programvaremoduler.