Hvilken lisens å velge på GitHub: typer, sammenligning

Hvordan velge en GitHub-lisens og hvorfor er det viktig å ikke ta feil valg? GitHub er den største tjenesten for felles utvikling av IT-prosjekter og deres påfølgende hosting. Ved hjelp av denne nettjenesten kan et ubegrenset antall mennesker jobbe på et prosjekt samtidig, så vel som fra absolutt hvor som helst i verden. Også i GitHub er det et styringssystem eller kontroll som lar deg se og kontrollere absolutt alle endringer av utviklere til enhver tid, og det lar deg også gå tilbake til tilstanden som skjedde før endringene.
Men for å si det enkelt er GitHub et såkalt sosialt nettverk for programmerere og utviklere, hvor du kan finne og deretter øve deg på å bruke koder fra andre utviklere. Du kan også lagre porteføljen din i GitHub. Alt i alt er GitHub en tjeneste som er godt egnet for både nybegynnere og erfarne programmerere. Imidlertid kan brukere av denne tjenesten noen ganger ha noen spørsmål om valg av lisens, siden valget deres der er ganske variert.

Hva er en GitHub-lisens

En lisens er et spesielt dokument som ble etablert av statsformen og lar en delta i en viss type gründeraktivitet, som nødvendigvis krever spesiell oppmerksomhet fra statsparten. Men som oftest brukes i praksis bare forkortede lisensavtaler eller avtaler som sørger for utstedelse av privatrettslige lisenser. Generelt forfølger lisensen kun ett, men det viktigste målet er en avtale om forpliktelser og rettigheter mellom lisensgiver og lisenstaker. Disse pliktene og rettighetene kan være absolutt hva som helst, men bare innenfor lovens rammer. Et slående eksempel er at lisensgiver kan kreve obligatorisk angivelse av navnet på rettighetshaveren ved bruk av verket av lisensinnehaveren. Eller for eksempel for å tillate kopiering av verket,men forby absolutt enhver modifikasjon av den. Eller, for å utlede slike krav om at verket skal produseres på absolutt samme betingelser som originalen, og så videre, det er mange eksempler på at ulike betingelser er fremmet.
Et eksempel på en av Apache-lisensene [/ caption]

Men vi må heller ikke glemme at lisensen beskytter rettighetene til ikke bare lisensgiveren, men også lisensinnehaveren. Siden i den kan du tydelig se og lese alle vilkårene for bruk av verket, og derfor trenger han ikke å være redd for at lisensgiveren plutselig vil kreve royalties eller annen kompensasjon for bruken av verket hans.

Hvis du velger bort en lisens som er knyttet til et verk, vil opphavsretten fortsatt gjelde i samsvar med gjeldende juridiske regler i det landet. Enkelt sagt, fraværet av en lisens betyr ikke på noen måte at andre forfattere kan bruke dette prosjektet slik de vil. Alt, absolutt, tvert imot, for uten noen spesifikk lisens frasier en programmerer seg på ingen måte rettighetene som ble gitt ved lov. Det er også viktig å alltid huske at lisensen styrer alle rettigheter og plikter. Dette for å beskytte eieren av verket mot brukernes forventninger og hva en eventuell garanti innebærer. Tross alt er det ingen som ønsker at koden hans skal gå til retten på noen måte.

Hva er opphavsrett

Opphavsrett vises for en person bare når han, som et resultat av intellektuell aktivitet, skaper et verk som vil være unikt, men samtidig nyttig, som et eksempel kan du ta skrivingen av det samme programmet. Når alt det ovennevnte er gjort, blir personen forfatteren og nå har han absolutt all opphavsrett til dette verket. Det må også sies at opphavsrett er proprietære og ikke-proprietære. Forskjellen deres er at eiendomsrett kan overføres til hvem som helst, men ikke eiendomsrett vil alltid bare forbli hos forfatteren i enhver situasjon. Å være forfatter er tross alt en umistelig og umistelig rettighet.

Hva er en åpen kildekode-lisens for?

Dette er også et ganske populært spørsmål blant nybegynnere og programmerere, siden de rett og slett ikke forstår hvorfor de skal knytte noen lisens til prosjektene sine, for uten det kan prosjektet også lett eksistere. Dette er imidlertid ikke helt sant, for hvis for eksempel en nybegynner utvikler skrev en ganske viktig og nyttig kode, men ikke beskyttet den med en lisens, så har andre brukere spørsmål. Og nettopp på grunn av dette, når klienter kommer til ham og vil bruke denne kodebiten til sine kommersielle formål, ser de at koden ikke har noen lisens og nekter den rett og slett. Dette skyldes det faktum at selskaper rett og slett ikke vil bruke koden uten lisens, fordi de ikke trenger problemer med loven og advokater.
Og det er grunnen til at selv det mest nyttige og praktiske prosjektet aldri vil bli realisert. Og utvikleren som ønsket å ta denne kodebiten, må se etter og bruke et alternativ eller fullstendig omskrive koden som allerede ble skrevet av en nybegynner utvikler tidligere. Derfor vil det være best å forsikre seg om på forhånd at programmereren bruker riktig, og viktigst av alt, passende lisens. Utforsk GitHub i en videoopplæring på 15 minutter: https://youtu.be/JfpCicDUMKc

Hvilken GitHub-lisens er riktig for visse forhold – hvordan velge?

Det kan ikke være noe eksakt svar på dette spørsmålet, siden valget av en lisens bare avhenger av målene for prosjektet og av utviklerens personlige preferanser og ønsker. Som du kan se, er det mange forskjellige lisenser på GitHub, og viktigst av alt, de er alle gratis og offentlig tilgjengelige, noe som betyr at enhver programmerer kan finne
Open Source -lisensen som passer akkurat for prosjektet hans. Men viktigst av alt, vi må ikke glemme at en åpen kildekode-lisens ikke bare er en kode uten lisens.
Familie av lisenser på GitHub [/ caption] Etter litt research, kan du samle alle åpen kildekode-lisenser og dele dem inn i tre store hovedgrupper:

1. Sterkt beskyttende.
2. Svak forsvar.
3. Permissive.

Sterkt beskyttende

Sterkt defensive lisenser er oftest varianter av GPL. Disse lisensene krever nødvendigvis lisensiering av prosjektet, så vel som avsløring av kildekoder, selv på tross av hvordan en kode eller et prosjekt vil bli brukt eller allerede har blitt brukt.

Svak forsvar

Svake defensive lisenser er oftest varianter av Lesser GPL. Der hovedforskjellen fra tillate lisenser er at det ganske enkelt er nødvendig å lisensiere programmet under GPL-lisensen, samt å gi kildekodene uten feil. Dessuten, hvis en programmerers prosjekt inneholder et bibliotek, det vil si statisk kobling eller dynamisk kobling under LGPL-lisensen, vil det også være kompatibelt med hvilken som helst av programmererens prosjektlisens.
Der lisenstypen på GitHub er angitt [/ caption]

Permissive

Det er et stort antall tillate lisenser, blant dem er de mest populære lisensene MIT, Apache 2.0 og BSD. Med små variasjoner har disse lisensene muligheten til å tillate bruk av koden både i Open Source-prosjekter og til kommersielle formål og prosjekter. Men i dette tilfellet er det viktig å huske at det er nødvendig å indikere forfatterskapet til det originale programmet.

Andre populære GitHub-lisenser

I tillegg til disse tre lisensgruppene er det andre, for eksempel er en annen av de mest nyttige lisensene GPLv2 med klassebaneutvidelser. Denne lisensen kan også brukes både i åpen kildekode-prosjekter og i kommersielle prosjekter og formål. Det mest populære utseendet er på Oracle, dette selskapet bruker GPLv2 med klassestiutvidelser for å lisensiere Open Source-prosjekter og -løsninger. Denne lisensen er ganske viktig og nyttig, da vanlige GPL-lisenser for eksempel aldri kan håndtere bytekode. Det vil si at de har en spesiell beskrivelse av kompilerings- og koblingsprosessen, som er helt upassende for andre tolkede programmeringsspråk, slike språk inkluderer det mest populære Java-språket.Det er for slike tilfeller at en spesiell GPLv2-lisens med klassebaneutvidelser ble utgitt. Tross alt står det veldig klart og tydelig at biblioteket som ble utgitt under denne lisensen kan brukes i kommersielle prosjekter og formål med absolutt alle andre lisenser.
Hva annet du trenger å vite om
GitHub-lisenser .

Legger til en lisens

Etter at den endelige lisensen til slutt er valgt, gjenstår det bare å legge den til selve prosjektroten. For å utføre denne handlingen, må du legge til den valgte lisensen under prosjektroten under opprettelsen av selve prosjektet, eller generelt når som helst. Men selv i denne handlingen klarte GitHub-netttjenesten å ta vare på brukerne sine, og de gjorde en ganske praktisk måte å legge til den endelige lisensen selv i starten av selve prosjektet.
Imidlertid er dette dessverre ikke alt, siden utvikleren eller programmereren må sjekke absolutt alle avhengighetene som ble brukt i ideen eller prosjektet hans. Det vil si at selv om en av avhengighetene er utgitt under GPL-lisensen, så må absolutt hele utviklerens prosjekt være GPL-kompatibelt. For slik verifisering brukes vanligvis de tiltenkte tidligere opprettede programmene eller verktøyene til dette. For eksempel er det et verktøy for denne https://github.com/pivotal/LicenseFinder:
Vi kan si at lisensiering er en ganske tidkrevende oppgave, men samtidig en nødvendig handling for livet til et prosjekt eller en hvilken som helst idé om en programmerer. For å velge riktig lisens må du dessverre bruke mye tid, men det er verdt det for at prosjektet skal lykkes. Det er best å sette valget av en lisens i første omgang når du skriver et program, siden du har gjort dette helt i begynnelsen, kan du rette all innsats i riktig retning og skrive et program som vil være vellykket og praktisk for de fleste brukere.