Watter lisensie om op GitHub te kies: tipes, vergelyking

Hoe om ‘n GitHub-lisensie te kies en hoekom is dit belangrik om die regte keuse te maak? GitHub is die grootste diens vir die gesamentlike ontwikkeling van IT-projekte en die daaropvolgende hosting daarvan. Met die hulp van hierdie webdiens kan ‘n onbeperkte aantal mense gelyktydig aan ‘n projek werk, sowel as van absoluut enige plek in die wêreld. GitHub het ook ‘n bestuur- of beheerstelsel wat jou toelaat om absoluut alle veranderinge wat deur ontwikkelaars oor tyd gemaak is te sien en te beheer, en dit laat jou ook toe om terug te keer na die toestand wat voor die veranderinge plaasgevind het.
Maar om dit eenvoudig te stel, GitHub is die sogenaamde sosiale netwerk vir programmeerders en ontwikkelaars, waar jy kodes van ander ontwikkelaars kan vind en later kan oefen. Jy kan ook jou portefeulje op GitHub stoor. Oor die algemeen is GitHub ‘n diens wat goed geskik is vir beide beginner ontwikkelaars en ervare programmeerders. Gebruikers van hierdie diens kan egter soms vrae hê oor die keuse van ‘n lisensie, aangesien hul keuse daar redelik uiteenlopend is.

Wat is ‘n GitHub-lisensie

‘N Lisensie is ‘n spesiale dokument wat deur die staatsvorm opgestel is en u toelaat om betrokke te raak by ‘n sekere soort entrepreneuriese aktiwiteit, wat sonder versuim spesiale aandag van die staatskant vereis. Maar in die praktyk word meestal slegs verkorte lisensie-ooreenkomste of ooreenkomste gebruik wat voorsiening maak vir die uitreiking van privaatregtelike lisensies. Oor die algemeen streef die lisensie net na een, maar die belangrikste doelwit, dit is ‘n ooreenkoms oor verpligtinge en regte tussen die lisensiegewer en die lisensiehouer. Hierdie pligte en regte kan absoluut enigiets wees, maar slegs binne die raamwerk van die wet. ‘n Noemenswaardige voorbeeld is dat die lisensiegewer kan vereis dat die naam van die kopiereghouer vereis word wanneer die werk deur die lisensiehouer gebruik word. Of laat byvoorbeeld kopieerwerk toe, maar verbied absoluut enige wysiging daarvan. Of, om sulke vereistes na vore te bring dat die werk op presies dieselfde voorwaardes as die oorspronklike een vrygestel word, ensovoorts, is daar heelwat voorbeelde van die voorstelling van verskeie voorwaardes.

Maar ons moet ook nie vergeet dat die lisensie die regte van nie net die lisensiegewer beskerm nie, maar ook die lisensiehouer. Aangesien u daarin duidelik al die voorwaardes vir die gebruik van die werk kan sien en lees, en daarom hoef hy nie bang te wees dat die lisensiegewer skielik enige aftrekkings of enige ander vergoeding vir die gebruik van sy werk sal eis nie.

As jy weier om die lisensie te gebruik wat met die werk geassosieer word, geld kopiereg steeds in ooreenstemming met die wetlike reëls wat in ‘n spesifieke land van krag is. Eenvoudig gestel, die afwesigheid van ‘n lisensie impliseer geensins dat ander skrywers hierdie projek kan gebruik op enige manier wat hulle wil nie. Alles is presies die teenoorgestelde, want sonder enige spesifieke lisensie doen die programmeerder in geen geval afstand van die regte wat deur die wet toegestaan ​​is nie. Dit is ook belangrik om altyd te onthou dat die lisensie alle regte en verpligtinge beheer. Dit is om die eienaar van die werk te beskerm teen gebruikersverwagtinge en wat enige waarborg impliseer. Niemand wil immers hê hul kode moet op enige manier in die hof beland nie.

Wat is kopiereg

Kopiereg verskyn slegs in ‘n persoon wanneer hy, as gevolg van intellektuele aktiwiteit, ‘n sekere werk skep wat uniek sal wees, maar terselfdertyd nuttig, byvoorbeeld, jy kan die skryf van dieselfde program neem. Wanneer al die bogenoemde gedoen is, word die persoon die outeur en nou het hy absoluut al die kopiereg op hierdie werk. Daar moet ook gesê word dat kopiereg eiendom en nie-eiendom is. Hulle verskil is dat eiendomsreg aan enigiemand oorgedra kan word, maar nie-eiendomsregte sal altyd net by die outeur bly in enige situasie. Om skrywer te wees is immers ‘n nie-oordraagbare en onvervreembare reg.

Waarvoor is ‘n oopbronlisensie?

Dit is ook ‘n redelik gewilde vraag onder beginner ontwikkelaars en programmeerders, aangesien hulle eenvoudig nie verstaan ​​hoekom ‘n lisensie aan hul projekte gekoppel moet word nie, want daarsonder kan die projek ook stilweg bestaan. Dit is egter nie heeltemal waar nie, want as, byvoorbeeld, een of ander beginner ontwikkelaar een of ander redelik belangrike en nuttige stukkie kode geskryf het, maar dit nie met ‘n lisensie beskerm het nie, dan het ander gebruikers vrae. En juis daarom, wanneer kliënte na hom toe kom en hierdie stukkie kode vir hul kommersiële doeleindes wil gebruik, sien hulle dat die kode geen lisensie het nie en weier dit eenvoudig. Dit is te wyte aan die feit dat maatskappye eenvoudig nie die kode sonder ‘n lisensie sal gebruik nie, omdat hulle nie probleme met die wet en prokureurs nodig het nie.
En dit is hoekom selfs die nuttigste en gerieflikste projek nooit geïmplementeer sal word nie. En die ontwikkelaar wat hierdie stukkie kode wou neem, sal ‘n alternatief moet soek en gebruik, of die kode wat reeds vroeër deur die beginner ontwikkelaar geskryf is, heeltemal herskryf. Daarom is dit die beste om vooraf seker te maak dat die programmeerder die korrekte, en die belangrikste, geskikte lisensie gebruik. Verken GitHub in een video-tutoriaal in 15 minute: https://youtu.be/JfpCicDUMKc

Watter GitHub-lisensie is geskik in sekere toestande – hoe om te kies?

Daar kan geen presiese antwoord op hierdie vraag wees nie, aangesien die keuse van ‘n lisensie slegs afhang van die doelwitte van die projek en van die persoonlike voorkeure en begeertes van die ontwikkelaar self. Soos u kan sien, is daar baie verskillende lisensies op GitHub, en die belangrikste is, hulle is almal gratis en in die publieke domein, wat beteken dat elke programmeerder die
Open Source -lisensie kan vind wat beslis by sy projek sal pas. Maar die belangrikste is dat ons nie moet vergeet dat ‘n oopbronlisensie nie net ‘n kode sonder lisensie is nie.

Met ‘n bietjie navorsing kan jy alle oopbronlisensies versamel en in drie groot hoofgroepe verdeel:

1. Sterk beskermend.
2. Swak beskermend.
3. Permissief.

sterk beskermend

Sterk beskermende lisensies is meestal variasies van die GPL. Hierdie lisensies vereis die lisensiëring van die projek sowel as die openbaarmaking van bronkodes, ongeag hoe enige kode of projek gebruik gaan word of reeds gebruik is.

Swak beskermend

Swak beskermende lisensies is meestal variasies van die Lesser GPL. Waarin die belangrikste verskil van permissiewe lisensies is dat dit hier eenvoudig nodig is om ook die program onder die GPL-lisensie te lisensieer, asook die bronkodes sonder versuim te verskaf. Terselfdertyd, as daar ‘n biblioteek in die programmeerder se projek is, dit wil sê statiese koppeling of dinamiese koppeling onder die LGPL-lisensie, dan sal dit ook versoenbaar wees met enige van die lisensies van die projek van hierdie programmeerder.

permissief

Daar is ‘n redelike groot aantal permissiewe lisensies, in hul geledere is die gewildste lisensies MIT, Apache 2.0 en BSD. Met geringe variasies het hierdie lisensies die vermoë om die gebruik van die kode beide in Oopbronprojekte en vir kommersiële doeleindes en projekte toe te laat. Maar in hierdie geval is dit belangrik om te onthou dat dit nodig is om die outeurskap van die oorspronklike program aan te dui.

Ander gewilde GitHub-lisensies

Benewens hierdie drie groepe lisensies, is daar ook ander, byvoorbeeld, nog een van die nuttigste lisensies is GPLv2 met klaspad-uitbreidings. Hierdie lisensie kan ook vir beide Oopbronprojekte en kommersiële projekte en doeleindes gebruik word. Sy gewildste voorkoms is by Oracle, wat GPLv2 met klaspaduitbreidings gebruik om sy oopbronprojekte en -oplossings te lisensieer. Hierdie lisensie is baie belangrik en nuttig, aangesien gewone GPL-lisensies byvoorbeeld nooit greepkode sal kan hanteer nie. Dit wil sê, hulle het ‘n spesiale beskrywing van die samestelling en koppelingsproses, wat heeltemal ongeskik is vir ander geïnterpreteerde programmeertale, die gewildste Java-taal is onder sulke tale. Dit is vir sulke gevalle dat ‘n spesiale lisensie GPLv2 met klaspad-uitbreidings vrygestel is. Dit sê immers baie duidelik en duidelik dat die biblioteek wat onder hierdie lisensie vrygestel is vir kommersiële projekte en doeleindes met absoluut enige ander lisensie gebruik kan word.
Wat anders moet jy weet oor
GitHub-lisensies .

Voeg ‘n lisensie by

Nadat die finale lisensie uiteindelik gekies is, bly dit net om dit by die projekwortel self te voeg. Om hierdie aksie uit te voer, moet u eenvoudig die geselekteerde lisensie onder die projekwortel byvoeg tydens die skepping van die projek self of op enige ander tydstip. Maar selfs in hierdie aksie het die GitHub-webdiens daarin geslaag om vir sy gebruikers te sorg en hulle het ‘n redelik gerieflike manier gemaak om die finale lisensie by te voeg, selfs aan die begin van die projek self.
Ongelukkig is dit egter nie al nie, aangesien die ontwikkelaar of programmeerder absoluut al die afhanklikhede wat in sy idee of projek gebruik is, moet nagaan. Dit wil sê, as selfs een van die afhanklikhede wat onder die GPL-lisensie vrygestel word, dan moet absoluut die hele ontwikkelaar se projek GPL-versoenbaar wees. Vir sulke verifikasie word voorheen ontwerpte programme of gereedskap gewoonlik hiervoor gebruik. Daar is byvoorbeeld ‘n instrument hiervoor https://github.com/pivotal/LicenseFinder:
Ons kan sê dat lisensiëring ‘n taamlik tydrowende taak is, maar terselfdertyd ‘n noodsaaklike aksie vir die lewe van ‘n projek of enige idee van ‘n programmeerder. Om die regte lisensie te kies, moet jy ongelukkig nogal baie tyd spandeer, maar dit is die moeite werd vir die projek om suksesvol te wees. Dit is die beste om die keuse van lisensie in die eerste plek te plaas wanneer u enige program skryf, aangesien deur dit heel aan die begin te doen, kan u absoluut al u pogings in die regte rigting rig en ‘n program skryf wat suksesvol en gerieflik sal wees vir die meeste gebruikers.