Vilken licens att välja på GitHub: typer, jämförelse

Hur väljer man en GitHub-licens och varför är det viktigt att inte göra fel val? GitHub är den största tjänsten för gemensam utveckling av IT-projekt och deras efterföljande hosting. Med hjälp av denna webbtjänst kan ett obegränsat antal personer arbeta på ett projekt samtidigt, såväl som från absolut var som helst i världen. Också i GitHub finns det ett ledningssystem eller kontroll som låter dig se och kontrollera absolut alla förändringar av utvecklare när som helst, och det låter dig också återgå till det tillstånd som inträffade före ändringarna.
Men för att uttrycka det enkelt så är GitHub ett så kallat socialt nätverk för programmerare och utvecklare, där du kan hitta och sedan öva på att använda koder från andra utvecklare. Du kan också lagra din portfölj i GitHub. Sammantaget är GitHub en tjänst som är väl lämpad för både nybörjare och erfarna programmerare. Däremot kan användare av denna tjänst ibland ha några frågor om att välja en licens, eftersom deras val där är ganska olika.

Vad är en GitHub-licens

En licens är ett speciellt dokument som upprättades av statens form och tillåter en att engagera sig i en viss typ av entreprenörsverksamhet, vilket nödvändigtvis kräver särskild uppmärksamhet från den statliga parten. Men oftast används i praktiken endast förkortade licensavtal eller avtal som föreskriver utfärdande av privaträttsliga licenser. Generellt sett eftersträvar licensen endast ett, men det viktigaste målet är ett avtal om skyldigheter och rättigheter mellan licensgivaren och licenstagaren. Dessa skyldigheter och rättigheter kan vara absolut vad som helst, men bara inom ramen för lagen. Ett slående exempel är att licensgivaren kan kräva obligatorisk uppgift om upphovsrättsinnehavarens namn vid användning av verket av licenstagaren. Eller, till exempel, för att tillåta kopiering av verket,men förbjud absolut all modifiering av den. Eller, för att härleda sådana krav att verket ska produceras på absolut samma villkor som originalet och så vidare, det finns en hel del exempel på att olika villkor förs fram.
Ett exempel på en av Apache-licenserna [/ caption]

Men vi får inte heller glömma att licensen skyddar rättigheterna för inte bara licensgivaren utan även licenstagaren. Eftersom du i den tydligt kan se och läsa alla användarvillkor för verket och därför behöver han inte vara rädd för att licensgivaren plötsligt kommer att kräva några royalties eller någon annan ersättning för användningen av hans verk.

Om du väljer bort en licens som är kopplad till ett verk, kommer upphovsrätten fortfarande att gälla i enlighet med gällande lagregler i det landet. Enkelt uttryckt innebär frånvaron av en licens inte på något sätt att andra författare kan använda detta projekt hur de vill. Allt, absolut, tvärtom, för utan någon specifik licens avsäger sig en programmerare inte på något sätt de rättigheter som beviljades enligt lag. Det är också viktigt att alltid komma ihåg att licensen styr alla rättigheter och skyldigheter. Detta för att skydda ägaren av verket från användarnas förväntningar och vad eventuell garanti innebär. Ingen vill ju att hans kod ska gå till domstol på något sätt.

Vad är upphovsrätt

Upphovsrätt visas för en person endast när han, som ett resultat av intellektuell aktivitet, skapar ett verk som kommer att vara unikt, men samtidigt användbart, som ett exempel kan du ta skrivandet av samma program. När allt ovanstående är gjort blir personen författare och nu har han absolut all upphovsrätt för detta verk. Det måste också sägas att upphovsrätten är egendomsskyddad och icke-proprietär. Deras skillnad är att äganderätten kan överföras till vem som helst, men inte äganderätten kommer alltid att finnas kvar hos författaren i alla situationer. Att vara författare är trots allt en omistlig och oförytterlig rättighet.

Vad är en öppen källkodslicens för?

Detta är också en ganska populär fråga bland nybörjare utvecklare och programmerare, eftersom de helt enkelt inte förstår varför de ska koppla någon licens till sina projekt, för utan den kan projektet också enkelt existera. Detta är dock inte helt sant, för om till exempel någon nybörjare skrev någon ganska viktig och användbar kod, men inte skyddade den med en licens, så har andra användare frågor. Och just därför, när kunder kommer till honom och vill använda denna kodbit för sina kommersiella ändamål, ser de att koden inte har någon licens och vägrar helt enkelt den. Detta beror på det faktum att företag helt enkelt inte kommer att använda koden utan licens, eftersom de inte behöver problem med lagen och advokater.
Och det är därför, även det mest användbara och bekväma projektet kommer aldrig att realiseras. Och utvecklaren som vill ta den här biten kod måste leta efter och använda ett alternativ eller helt skriva om koden som redan skrevs av en nybörjare tidigare. Det är därför det vore bäst att i förväg se till att programmeraren använder rätt, och viktigast av allt, lämplig licens. Utforska GitHub i en videotutorial på 15 minuter: https://youtu.be/JfpCicDUMKc

Vilken GitHub-licens är rätt för vissa villkor – hur väljer man?

Det kan inte finnas något exakt svar på denna fråga, eftersom valet av en licens endast beror på projektets mål och på utvecklarens personliga preferenser och önskemål. Som du kan se finns det många olika licenser på GitHub, och viktigast av allt, de är alla gratis och allmänt tillgängliga, vilket innebär att varje programmerare kan hitta den
Open Source -licens som är exakt lämplig för hans projekt. Men viktigast av allt, vi får inte glömma att en Open Source-licens inte bara är en kod utan licens.
Licensfamilj på GitHub [/ caption] Efter lite forskning kan du samla alla Open Source-licenser och dela in dem i tre stora huvudgrupper:

1. Starkt skyddande.
2. Svagt försvarande.
3. Tolerant.

Starkt skyddande

Starkt defensiva licenser är oftast varianter av GPL. Dessa licenser kräver med nödvändighet licensiering av projektet, såväl som avslöjande av källkoder, även trots hur kod eller projekt kommer att användas eller redan har använts.

Svagt försvarande

Svagt defensiva licenser är oftast varianter av Lesser GPL. Där den största skillnaden från tillåtande licenser är att det helt enkelt är nödvändigt att licensiera programmet under GPL-licensen, samt att tillhandahålla källkoder utan att misslyckas. Dessutom, om en programmerares projekt innehåller ett bibliotek, det vill säga statisk länkning eller dynamisk länkning under LGPL-licensen, kommer det också att vara kompatibelt med någon av programmerarens projektlicenser.
Där typen av licens på GitHub anges [/ caption]

Tolerant

Det finns ett stort antal tillåtande licenser, bland dem är de mest populära licenserna MIT, Apache 2.0 och BSD. Med små variationer har dessa licenser möjlighet att tillåta användning av koden både i Open Source-projekt och för kommersiella ändamål och projekt. Men i det här fallet är det viktigt att komma ihåg att det är nödvändigt att ange författarskapet till det ursprungliga programmet.

Andra populära GitHub-licenser

Utöver dessa tre grupper av licenser finns det andra, till exempel är en annan av de mest användbara licenserna GPLv2 med classpath-tillägg. Denna licens kan också användas både i Open source-projekt och i kommersiella projekt och syften. Dess mest populära utseende är på Oracle, detta företag använder GPLv2 med classpath-tillägg för att licensiera sina Open Source-projekt och lösningar. Denna licens är ganska viktig och användbar, eftersom vanliga GPL-licenser till exempel aldrig kan hantera bytekod. Det vill säga, de har en speciell beskrivning av kompilerings- och länkningsprocessen, vilket är helt olämpligt för andra tolkade programmeringsspråk, sådana språk inkluderar det mest populära Java-språket.Det är för sådana fall som en speciell GPLv2-licens med classpath-tillägg släpptes. När allt kommer omkring står det väldigt tydligt och tydligt att biblioteket som släpptes under denna licens kan användas i kommersiella projekt och syften med absolut vilken annan licens som helst.
Vad mer du behöver veta om
GitHub-licenser .

Lägger till en licens

Efter att den slutliga licensen slutligen har valts återstår bara att lägga till den i själva projektroten. För att utföra denna åtgärd måste du lägga till den valda licensen under projektroten under skapandet av själva projektet, eller i allmänhet när som helst. Men även i denna åtgärd lyckades GitHub-webbtjänsten ta hand om sina användare och de gjorde ett ganska bekvämt sätt att lägga till den slutliga licensen även i början av själva projektet.
Men tyvärr är detta inte allt, eftersom utvecklaren eller programmeraren måste kontrollera absolut alla beroenden som användes i hans idé eller projekt. Det vill säga, även om ett av beroenden släpps under GPL-licensen måste absolut hela utvecklarens projekt vara GPL-kompatibelt. För sådan verifiering används vanligtvis de avsedda tidigare skapade programmen eller verktygen för detta. Till exempel finns det ett verktyg för detta https://github.com/pivotal/LicenseFinder:
Vi kan säga att licensiering är en ganska tidskrävande uppgift, men samtidigt en nödvändig åtgärd för livet av ett projekt eller någon idé om en programmerare. För att välja rätt licens måste man tyvärr lägga ner mycket tid, dock är det värt det för att projektet ska bli framgångsrikt. Det är bäst att sätta valet av en licens i första hand när du skriver ett program, eftersom du har gjort detta i början kan du rikta alla dina ansträngningar i rätt riktning och skriva ett program som kommer att vara framgångsrikt och bekvämt för de flesta användare.