Hvad du behøver at vide om GitHub-licenser: hvordan man vælger og tilføjer

GitHub-licenser – hvad taler vi om? For at skabe software skal du ikke kun skrive det, men også beslutte, hvad brugere eller udviklere har ret til at gøre med det. Hvis nogen laver et gratis program for alle, gør han en god gerning, men den, der bruger det, bliver nødt til at begrunde, hvordan han bruger det. For eksempel, hvis en virksomhed i sine aktiviteter vil arbejde med et hvilket som helst gratis kontor (for eksempel LibreOffice), så skal det for revisorerne være i stand til at bevise, at det har ret til det. For at gøre dette vil det være nok at præsentere den relevante licens. Hvis udvikleren glemmer at formulere det, kan virksomheden komme i en vanskelig situation.
Klassificering af licenser og typer af licenser [/ caption] Når du opretter en applikation, skal udvikleren beslutte, hvilke handlinger med hans program, der vil være tilladt, og hvad der ikke vil. For eksempel kan vi tale ikke kun om at bruge, men også om at studere tekster i programmer eller foretage deres egne justeringer af softwareproduktet. GitHub er en af ​​de største tjenester til samarbejdsprojektudvikling. Samtidig kan de arbejde her ikke kun på gratis, men også på kommercielle projekter. Ved at angive en passende licens, vil udviklere eliminere forvirring om, hvordan man bruger det oprettede produkt. Problemet er, at der er forskellige typer licenser, og det er ikke altid nemt at afgøre, hvilken mulighed der skal foretrækkes i et bestemt tilfælde. Desuden er det ikke ualmindeligt, at nogle projekter ikke har nogen licens.Det er nødvendigt at lære mere om licensering for at forstå, hvilke rettigheder og forpligtelser brugere har i forskellige tilfælde.

Hvorfor skal jeg licensere Open Source-projekter på GitHub

Ved at specificere den påkrævede licens kan udvikleren sørge for følgende:

1. Vilkår for brug af programmet . De kan sørge for betaling af et gebyr eller i nogle eller alle tilfælde tillade gratis brug.
2. Nogle gange er programmer skabt til at blive udviklet af samfundet . I dette tilfælde er det vigtigt, at alle, der har lyst, kan sætte sig ind i programteksterne.
3. Når koden er tilgængelig, kan nogle foretage ændringer for at gøre programmet funktionelt og så pålideligt som muligt. Nogle gange kan forfatteren tillade alle at gøre dette, i andre tilfælde tilbyder han at sende en ændring til ham og foretager justeringer af projektet på egen hånd.
4. Du skal beslutte, om tredjeparter kan foretage ændringer i projektet og foreslå på deres vegne. I dette tilfælde er det nødvendigt at angive, med hvilken licens deres produkt skal være.

Ved at løse disse og lignende problemer bestemmer forfatteren af ​​applikationen faktisk i vid udstrækning den fremtidige skæbne for det softwareprodukt, han oprettede.

Hvilke typer licenser er der

En licens er en aftale, hvor den ene part (licensgiveren) etablerer en regel for, at den anden part (licenstageren) skal bruge det produkt, den opretter. I praksis taler vi ikke om parternes underskrift af et dokument, men om automatisk samtykke med de tilsvarende rettigheder og forpligtelser ved brugen af ​​det. Der er praktisk talt ingen begrænsninger for at specificere rettigheder og forpligtelser. Den eneste betingelse er, at de skal overholde loven. At oprette dine egne licenser er en vanskelig opgave, da du skal sikre dig, at den er kompatibel med andre regler. Den bedste mulighed er at vælge og bruge en af ​​standardtyperne af sådanne dokumenter. I praksis er det også kutyme at bruge multilicensering. Oftest bruges i sådanne tilfælde to licenser samtidigt.Selvom forfatteren af ​​programmet har ret til selvstændigt at formulere de regler, som brugerne skal følge, er der i praksis ikke desto mindre udviklet brugen af ​​et stort antal typer licenser, hvorfra du i de fleste tilfælde kan vælge den passende. Følgende er de mest populære muligheder, der bruges på Git Hub i de fleste tilfælde. De mest almindelige licenser brugt på Git Hub er:
Programmøren skal være i stand til at vælge en, der passer til hans planer. For at gøre dette korrekt skal du forstå, hvilke funktioner der er iboende i visse arter.

Hvis forfatteren nægter at formulere dokumentet, vil ophavsretten i dette tilfælde gælde, som er leveret som standard af lovgivningen i hans land. Fraværet af en licens på denne måde betyder ikke, at du kan gøre, hvad du vil med programmet. Faktisk kan denne situation betragtes som en af ​​licenstyperne.

Sådan vælger du en Github-licens

Før du begynder at søge efter en passende mulighed, er det nødvendigt, at programmøren formulerer sine krav, hvorfra han vil fortsætte med yderligere licensering. Dernæst bør du sætte dig ind i de typiske muligheder, der svarer til anmodningen. Derefter skal du omhyggeligt studere den juridiske formulering og træffe en endelig beslutning om, hvad licensen skal være. For at kunne træffe et informeret valg skal du forstå, hvilke rettigheder og forpligtelser der er bestemt af en bestemt type licens. For at træffe det rigtige valg kan du bruge specielle tjenester kaldet komparatorer. Her er nogle eksempler:

1. https://choosealicense.com/. Dette websted indeholder vejledende spørgsmål til at vælge den rigtige mulighed og detaljerede råd, der hjælper dig med at forstå de specifikke brug.
2. Siden https://opensource.org/licenses er dedikeret til at gennemgå forskellige gratis softwareløsninger.
3. Webstedet https://tldrlegal.com/ kan ses som en encyklopædi for forskellige licensmuligheder. Den indeholder både et præcist juridisk sprog og detaljerede kommentarer.

Sammenlign licenser på https://choosealicense.com/ [[]] Det mest produktive valg er dog omhyggeligt at læse de relevante juridiske dokumenter. Selvom dette er en tidskrævende aktivitet, vil studie af teksterne ikke desto mindre give udvikleren alle de svar, han har brug for.

Sådan tilføjer du en licens til Github

På trods af et omfattende udvalg af licensmuligheder, som i praksis har bevist deres effektivitet og pålidelighed, kan udvikleren have deres egne ideer om, hvad licensen skal være for det program, han har lavet. I dette tilfælde giver tjenesten mulighed for at tilføje din egen version eller justere den eksisterende. For at tilføje en licens til Github skal du følge disse trin:

1. Du skal gå til hovedsiden af ​​dit lager.
2. Du skal klikke på knappen for at tilføje en fil og derefter vælge “Opret ny fil”.
3. Dernæst skal du indtaste filnavnet. For en licens kan det være en af ​​to muligheder: LICENS eller LICENS.md. Her er brug af store bogstaver obligatorisk.
4. Til højre for indtastningsfeltet for filnavnet skal du klikke for at vælge en licensskabelon.
5. I menuen til venstre på siden skal du vælge linjen “Tilføj en licens til dit projekt”. I dette tilfælde vælges en mulighed fra eksisterende dokumenter.
6. Klik derefter på linjen “Gennemgå og indsend”. Indtast derefter deres aftaleoplysninger.
7. Derefter er det nødvendigt at afklare, hvilke tilføjelser eller ændringer der blev foretaget. Dernæst angiver de, om det valgte dokument blev rettet, eller om vi taler om at oprette en anden version af licensen.

Efter at have bekræftet ændringerne, fuldfører udvikleren proceduren for at lave ændringer til listen over licenser på Git Hub-tjenesten.

Vælg en licens Github – Eksempler på populære licenser på Git Hub

Dernæst vil vi overveje de muligheder, der er de mest populære. Efter at have forstået deres styrker og svagheder, vil programmøren være i stand til at finde den rigtige mulighed eller forstå, hvordan man effektivt søger.

GPL

Denne licens kan kaldes en af ​​de mest populære. Det er klassisk for dem, der laver gratis software. Et af hovedkravene i dette dokument er, at det
giver tredjeparter mulighed for frit at ændre programmet , men samtidig har de ret til kun at distribuere resultatet under den samme licens. Denne licens kan have forskellige versioner. Den seneste er den tredje. GPL blev brugt af udviklere af programmer som Drupal webindholdsstyringssystem, MariaDB-databasestyringssystemet, vektorgrafikeditoren InkSkape og flere andre. Det er interessant at bemærke, at SQL ikke kun bruger GPL, men også en kommerciel licens.

LGPL

Denne titel oversættes til GNU Lesser General Public License GPL. For nogle udviklere er GPL ikke egnet, da det skaber en forpligtelse for dem til at distribuere modificerede produkter under samme licens. Det særlige ved at bruge denne mulighed kan illustreres ved, hvordan processen med at licensere brugen af ​​biblioteker oprettet af en programmør foregår. I dette tilfælde er det sædvanligt at overveje følgende tre muligheder:

1. Når et bibliotek giver nye funktioner, og ingen kommercielle biblioteker kan udføre en lignende opgave, så er brugen af ​​GPL’en optimal.
2. Udvikleren i det gratis bibliotek har allerede implementeret den eksisterende standard. På dette område er der kommercielle muligheder med lignende funktioner. I dette tilfælde vil det være praktisk at vælge LGPL.
3. Når det kommer til en ny standard, der faktisk konkurrerer med en kommerciel, er Apache-licensen passende.

Denne standard
tillader kommerciel brug af bibliotekerne . Hvis der foretages ændringer, skal de samme vilkår og betingelser anvendes til distribution. Enkel kodebrug tillader dog, at forholdene ændres.

Eclipse Public License

Dette dokument
tillader distribution under andre licenser, herunder kommercielle licenser . Hovedbetingelsen er, at innovationerne i de modificerede værker vil blive placeret i et separat modul. Denne licens har vundet popularitet i udviklingen af ​​Java-produkter. Et eksempel er programmeringssproget Clojure, en ramme til test af java-applikationer.

Mozilla Public License

Nogle ser dette dokument som et kompromis mellem GPL og kommercielle licenser. Det er et krav fra MPL at
have offentlig adgang til visse filer . Softwareproduktet kan indeholde nogle filer under denne licens, og andre uden. Efter ændringen er det tilladt at lægge den nødvendige licens (det kan for eksempel være en kommerciel), men dette er kun muligt på betingelse af, at adgangen til de filer, der er frigivet under MPL, stadig er åben. I dette tilfælde skal slutbrugeren have oplysninger om forfatterne til den originale software. LibreOffice office, Mozilla browser og andre softwareprodukter blev frigivet i overensstemmelse med dette dokument.

Apache-licens Github

AL kaldes en liberal fri licens. Denne funktion skyldes, at der ikke er
noget krav om at frigive et afledt produkt under de samme betingelser som før . Dette dokument bruges aktivt af Apache Software Foundation. Når du bruger det, er følgende tilladt:

1. Softwareproduktet må fortsat bruges til kommercielle formål.
2. Ændringer af applikationer er tilladt.
3. Efterfølgende videredistributioner skal indeholde navnet på den oprindelige forfatter.

Når du opretter en ny variant, har licenstagere ingen forpligtelse til at oplyse den originale produktkode. Denne licens har vundet betydelig popularitet. Dette kan demonstreres ved at liste de velkendte softwareprodukter, der udgives under denne type licens: Android-operativsystemet, rammen til at skabe virksomhedsapplikationer i Java, Apache-webserveren. https://youtu.be/wyZq-EazOmU

MIT-licens

Nogle mennesker synes, at denne gratis softwarelicensmulighed er den mest populære. Nogle anser dens største fordel for at være god kompatibilitet med forskellige typer gratis eller kommercielle licenser. De vigtigste funktioner er
muligheden for at ændre koden, samt tilladelsen til at videredistribuere under andre licenser efter valg af den person, der har foretaget ændringerne . Softwareprodukterne, der bruger dette dokument, er: et JavaScript-bibliotek kaldet JQuiery, en Atom-teksteditor, AngularJS – en ramme til udvikling i JavaScript.
Sammenligning af licenser til Git Hub [/ caption]

Undersøiske sten

Sommetider vælger forfatteren først én version af licensen og ønsker senere at ændre den. Hvis han oprettede programmet alene, vil en sådan ændring ikke være vanskelig. Men i de tilfælde, hvor der var mange deltagere i udviklingen, så vil det ikke fungere uden deres samtykke. For eksempel vil skaberen af ​​Linux, selvom han faktisk lavede grundlaget for operativsystemet, ikke være i stand til at ændre licensen uden samtykke fra alle de programmører, der deltog i den videre udvikling. Ved videredistribution under MPL kan de, der har foretaget ændringer i koden, ikke tilbyde filer under MPL under en anden licens. Brugen af ​​det nye dokument vil gælde for andre softwaremoduler.