Hvordan vælger man en GitHub-licens, og hvorfor er det vigtigt ikke at træffe det forkerte valg? GitHub er den største service til fælles udvikling af IT-projekter og deres efterfølgende hosting. Ved hjælp af denne webservice kan et ubegrænset antal mennesker arbejde på et projekt på én gang, såvel som fra absolut hvor som helst i verden. Også i GitHub er der et ledelsessystem eller kontrol, der giver dig mulighed for at se og kontrollere absolut alle ændringer af udviklere til enhver tid, og det giver dig også mulighed for at vende tilbage til den tilstand, der skete før ændringerne.
Men for at sige det enkelt, så er GitHub et såkaldt socialt netværk for programmører og udviklere, hvor du kan finde og derefter øve dig i at bruge koder fra andre udviklere. Du kan også gemme din portefølje i GitHub. Alt i alt er GitHub en tjeneste, der er velegnet til både nybegyndere og erfarne programmører. Brugere af denne tjeneste kan dog nogle gange have nogle spørgsmål om valg af licens, da deres valg der er ret forskelligt.
Hvad er en GitHub-licens
En licens er et særligt dokument, der blev oprettet af statsformularen og giver en mulighed for at deltage i en bestemt type iværksætteraktivitet, som nødvendigvis kræver særlig opmærksomhed fra statsparten. Men oftest bruges der i praksis kun forkortede licensaftaler eller aftaler, der giver mulighed for udstedelse af privatretlige licenser. Generelt forfølger licensen kun ét, men det vigtigste mål er en aftale om forpligtelser og rettigheder mellem licensgiver og licenstager. Disse pligter og rettigheder kan være absolut hvad som helst, men kun inden for lovens rammer. Et slående eksempel er, at licensgiveren kan kræve obligatorisk angivelse af navn på ophavsretsindehaveren ved brug af værket af licenstager. Eller for eksempel at tillade kopiering af værket,men forbyd absolut enhver ændring af den. Eller for at udlede sådanne krav om, at værket skal være produceret på absolut samme betingelser som originalen, og så videre, er der en masse eksempler på, at forskellige betingelser bliver fremført.
Et eksempel på en af Apache-licenserne [/ caption]
Men vi må heller ikke glemme, at licensen beskytter rettighederne for ikke kun licensgiveren, men også licenstageren. Da du i den tydeligt kan se og læse alle vilkårene for brugen af værket, og derfor behøver han ikke at være bange for, at licensgiveren pludselig vil kræve nogen royalties eller anden kompensation for brugen af hans værk.
Hvis du fravælger en licens, der er knyttet til et værk, vil ophavsretten stadig gælde i overensstemmelse med de juridiske regler, der er gældende i det pågældende land. Kort sagt betyder fraværet af en licens ikke på nogen måde, at andre forfattere kan bruge dette projekt, som de vil. Alt, absolut, tværtimod, for uden nogen specifik licens giver en programmør på ingen måde afkald på de rettigheder, der blev givet ved lov. Det er også vigtigt altid at huske, at licensen regulerer alle rettigheder og forpligtelser. Dette er for at beskytte ejeren af værket mod brugernes forventninger og hvad en eventuel garanti indebærer. Der er jo ingen, der ønsker, at hans kodeks skal gå i retten på nogen måde.
Hvad er ophavsret
Copyright vises kun for en person, når han som et resultat af intellektuel aktivitet skaber et værk, der vil være unikt, men samtidig nyttigt, som et eksempel kan du tage skrivningen af det samme program. Når alt ovenstående er gjort, bliver personen forfatter, og nu har han absolut al ophavsretten til dette værk. Det skal også siges, at ophavsrettigheder er proprietære og ikke-proprietære. Deres forskel er, at ejendomsrettigheder kan overføres til enhver, men ikke ejendomsrettigheder vil altid kun forblive hos forfatteren i enhver situation. At være forfatter er jo en umistelig og umistelig ret.
Hvad er en Open Source-licens til?
Dette er også et ret populært spørgsmål blandt nybegyndere og programmører, da de simpelthen ikke forstår, hvorfor de skal knytte nogen licens til deres projekter, for uden det kan projektet også sagtens eksistere. Det er dog ikke helt rigtigt, for hvis for eksempel en nybegynder udvikler skrev et ret vigtigt og nyttigt stykke kode, men ikke beskyttede det med en licens, så har andre brugere spørgsmål. Og netop derfor, når klienter kommer til ham og vil bruge dette stykke kode til deres kommercielle formål, ser de, at koden ikke har nogen licens og nægter det simpelthen. Dette skyldes, at virksomheder simpelthen ikke vil bruge koden uden en licens, fordi de ikke har brug for problemer med loven og advokater.
Og det er derfor, selv det mest nyttige og bekvemme projekt vil aldrig blive realiseret. Og udvikleren, der ønskede at tage dette stykke kode, bliver nødt til at lede efter og bruge et alternativ eller fuldstændigt omskrive koden, der allerede blev skrevet af en nybegynder udvikler tidligere. Det er derfor, det ville være bedst at sikre sig på forhånd, at programmøren bruger den korrekte, og vigtigst af alt, passende licens. Udforsk GitHub i en videotutorial på 15 minutter: https://youtu.be/JfpCicDUMKc
Hvilken GitHub-licens er den rigtige for visse forhold – hvordan vælger man?
Der kan ikke være noget nøjagtigt svar på dette spørgsmål, da valget af en licens kun afhænger af projektets mål og af udviklerens personlige præferencer og ønsker. Som du kan se, er der en masse forskellige licenser på GitHub, og vigtigst af alt er de alle gratis og offentligt tilgængelige, hvilket betyder, at enhver programmør kan finde den
Open Source -licens, der er præcist egnet til hans projekt. Men vigtigst af alt må vi ikke glemme, at en Open Source-licens ikke bare er en kode uden licens.
Familie af licenser på GitHub [/ caption] Efter lidt research kan du samle alle Open Source-licenser og opdele dem i tre store hovedgrupper:
- Stærkt beskyttende.
- Svagt forsvarende.
- Tilladende.
Stærkt beskyttende
Stærkt defensive licenser er oftest variationer af GPL. Disse licenser kræver nødvendigvis licensering af projektet, såvel som offentliggørelse af kildekoder, selv på trods af, hvordan enhver kode eller projekt vil blive brugt eller allerede er blevet brugt.
Svagt forsvarende
Svagt defensive licenser er oftest variationer af Lesser GPL. I hvilken den største forskel fra tilladelige licenser er, at det simpelthen er nødvendigt at licensere programmet under GPL-licensen, samt at levere kildekoderne uden fejl. Desuden, hvis en programmørs projekt indeholder et bibliotek, det vil sige statisk linking eller dynamisk linking under LGPL-licensen, så vil det også være kompatibelt med enhver af programmørens projektlicenser.
Hvor licenstypen på GitHub er angivet [/ caption]
Tilladende
Der er et stort antal tilladelige licenser, blandt dem er de mest populære licenser MIT, Apache 2.0 og BSD. Med små variationer har disse licenser mulighed for at tillade brug af koden både i Open Source-projekter og til kommercielle formål og projekter. Men i dette tilfælde er det vigtigt at huske, at det er nødvendigt at angive forfatterskabet af det originale program.
Andre populære GitHub-licenser
Ud over disse tre grupper af licenser er der andre, for eksempel er en anden af de mest nyttige licenser GPLv2 med klassestiudvidelser. Denne licens kan også bruges både i Open source-projekter og i kommercielle projekter og formål. Dets mest populære udseende er hos Oracle, denne virksomhed bruger GPLv2 med klassestiudvidelser til at licensere sine Open Source-projekter og -løsninger. Denne licens er ret vigtig og nyttig, da almindelige GPL-licenser for eksempel aldrig kan håndtere bytekode. Det vil sige, at de har en særlig beskrivelse af kompilerings- og linkprocessen, som er fuldstændig upassende for andre fortolkede programmeringssprog, sådanne sprog inkluderer det mest populære Java-sprog.Det er til sådanne tilfælde, at en speciel GPLv2-licens med klassestiudvidelser blev frigivet. Når alt kommer til alt, står der meget klart og tydeligt, at biblioteket, der blev udgivet under denne licens, kan bruges i kommercielle projekter og formål med absolut enhver anden licens.
Hvad du ellers behøver at vide om
GitHub-licenser .
Tilføjelse af en licens
Når den endelige licens endelig er valgt, er der kun tilbage at tilføje den til selve projektroden. For at udføre denne handling skal du tilføje den valgte licens under projektroden under oprettelsen af selve projektet eller generelt på et hvilket som helst andet tidspunkt. Men selv i denne handling formåede GitHub-webtjenesten at tage sig af sine brugere, og de lavede en ret bekvem måde at tilføje den endelige licens på selv i starten af selve projektet.
Men desværre er dette ikke alt, da udvikleren eller programmøren skal kontrollere absolut alle de afhængigheder, der blev brugt i hans idé eller projekt. Det vil sige, at selvom en af afhængighederne er frigivet under GPL-licensen, så skal absolut hele udviklerens projekt være GPL-kompatibelt. Til en sådan verifikation bruges de påtænkte tidligere oprettede programmer eller værktøjer normalt til dette. For eksempel er der et værktøj til denne https://github.com/pivotal/LicenseFinder:
Vi kan sige, at licensering er en ret tidskrævende opgave, men samtidig en nødvendig handling for livet af et projekt eller enhver idé om en programmør. For at vælge den rigtige licens skal du desværre bruge meget tid, dog er det det værd for at projektet bliver en succes. Det er bedst at sætte valget af en licens i første række, når du skriver et program, da du har gjort dette i begyndelsen, kan du rette alle dine bestræbelser i den rigtige retning og skrive et program, der vil være vellykket og praktisk for de fleste brugere.