Hoe kinne jo in GitHub-lisinsje kieze en wêrom is it wichtich om de juste kar te meitsjen? GitHub is de grutste tsjinst foar de mienskiplike ûntwikkeling fan IT-projekten en har folgjende hosting. Mei help fan dizze webtsjinst kinne in ûnbeheind oantal minsken tagelyk oan in projekt wurkje, lykas fan absolút oeral yn ‘e wrâld. GitHub hat ek in behear- of kontrôlesysteem wêrmei jo absolút alle wizigingen kinne besjen en kontrolearje dy’t makke binne troch ûntwikkelders yn ‘e rin fan’ e tiid, en it lit jo ek weromgean nei de steat dy’t barde foar de wizigingen.
Mar om it gewoan te sizzen, GitHub is it saneamde sosjale netwurk foar programmeurs en ûntwikkelders, wêr’t jo kinne fine, en letter oefenje op koades fan oare ûntwikkelders. Jo kinne jo portfolio ek opslaan op GitHub. Yn ‘t algemien is GitHub in tsjinst dy’t goed geskikt is foar sawol begjinnende ûntwikkelders as erfarne programmeurs. Brûkers fan dizze tsjinst kinne lykwols soms fragen hawwe oer it kiezen fan in lisinsje, om’t har kar dêr frij ferskaat is.
Wat is in GitHub-lisinsje
In lisinsje is in spesjaal dokumint dat waard fêststeld troch de steat foarm en kinne jo meidwaan oan in bepaald soarte fan ûndernimmende aktiviteit, dy’t sûnder mis fereasket spesjale oandacht fan de steat kant. Mar yn ‘e praktyk wurde meastentiids allinich ôfkoarte lisinsjeôfspraken of oerienkomsten brûkt dy’t soargje foar it útjaan fan priveerjochtlike lisinsjes. Yn it algemien, de lisinsje neistribbet mar ien, mar it wichtichste doel, dit is in oerienkomst oer ferplichtings en rjochten tusken de lisinsjejouwer en de lisinsjenimmer. Dizze plichten en rjochten kinne absolút alles wêze, mar allinich binnen it ramt fan ‘e wet. In opmerklik foarbyld is dat de lisinsjegever easkje kin dat de namme fan ‘e auteursrjochthâlder ferplicht is by it brûken fan it wurk troch de lisinsjenimmer. Of bygelyks kopiearjen fan wurk tastean, mar ferbiede absolút elke wiziging derfan. Of, om sokke easken út te bringen dat it wurk op krekt deselde betingsten útbrocht wurdt as it orizjinele, ensafuorthinne, der binne nochal in protte foarbylden fan it foardragen fan ferskate betingsten.
Mar wy moatte ek net ferjitte dat de lisinsje de rjochten beskermet fan net allinich de lisinsjegever, mar ek de lisinsjenimmer. Sûnt dêryn kinne jo dúdlik sjen en lêze alle betingsten foar it brûken fan it wurk, en dêrom hoecht hy net te wêzen bang dat de lisinsjejouwer ynienen easkje gjin ôftrek of in oare kompensaasje foar it brûken fan syn wurk.
As jo wegerje de lisinsje te brûken dy’t ferbûn is mei it wurk, dan jilde auteursrjochten noch yn oerienstimming mei de wetlike regels dy’t jilde yn in bepaald lân. Simpelwei betsjuttet it ûntbrekken fan in lisinsje op gjin inkelde manier dat oare auteurs dit projekt kinne brûke op elke manier dy’t se wolle. Alles is krekt it tsjinoerstelde, om’t sûnder spesifike lisinsje de programmeur yn gjin gefal ôfwiist fan ‘e rjochten dy’t troch de wet ferliend binne. It is ek wichtich om altyd te ûnthâlden dat de lisinsje alle rjochten en ferplichtingen regelet. Dit is om de eigner fan it wurk te beskermjen tsjin ferwachtingen fan brûkers en wat elke garânsje ymplisearret. Nimmen wol ommers dat har koade op ien of oare manier foar de rjochtbank einiget.
Wat is auteursrjocht
Copyright ferskynt yn in persoan allinich as hy, as gefolch fan yntellektuele aktiviteit, in bepaald wurk makket dat unyk sil wêze, mar tagelyk nuttich, bygelyks kinne jo it skriuwen fan itselde programma nimme. As al it boppesteande dien is, wurdt de persoan de auteur en no hat hy absolút alle auteursrjochten op dit wurk. It moat ek sein wurde dat auteursrjochten eigendom binne en net-eigendom. Har ferskil is dat eigendomsrjochten kinne wurde oerdroegen oan elkenien, mar net-eigendomsrjochten sille altyd allinich by de auteur bliuwe yn elke situaasje. Skriuwer wêze is ommers in net oerdraachber en ûnferfrjember rjocht.
Wat is in Open Source lisinsje foar?
Dit is ek in frij populêre fraach ûnder begjinnende ûntwikkelders en programmeurs, om’t se gewoan net begripe wêrom’t in lisinsje oan har projekten oanbean wurde moat, om’t sûnder it it projekt ek rêstich kin bestean. Dit is lykwols net hielendal wier, want as bygelyks in begjinnende ûntwikkelder wat frij wichtich en brûkber stikje koade skreau, mar it net beskerme mei in lisinsje, dan hawwe oare brûkers fragen. En krekt dêrom, as kliïnten by him komme en dit stik koade brûke wolle foar har kommersjele doelen, sjogge se dat de koade gjin lisinsje hat en wegerje it gewoan. Dit komt troch it feit dat bedriuwen de koade gewoan net sûnder lisinsje sille brûke, om’t se gjin problemen hawwe mei de wet en advokaten.
En dat is wêrom sels it meast brûkbere en handige projekt sil nea wurde útfierd. En de ûntwikkelder dy’t dit stik koade nimme woe, sil in alternatyf sykje en brûke, of de koade dy’t al earder skreaun is troch de begjinnende ûntwikkelder folslein oerskriuwe. Dêrom is it it bêste om foarôf te soargjen dat de programmeur de juste, en it wichtichste, passende lisinsje brûkt. GitHub ferkenne yn ien fideo-tutorial yn 15 minuten: https://youtu.be/JfpCicDUMKc
Hokker GitHub-lisinsje is geskikt yn bepaalde betingsten – hoe te kiezen?
D’r kin gjin krekte antwurd op dizze fraach wêze, om’t de kar fan in lisinsje allinich hinget fan ‘e doelen fan it projekt en op’ e persoanlike foarkarren en winsken fan ‘e ûntwikkelder sels. Sa’t jo sjen kinne, binne d’r in protte ferskate lisinsjes op GitHub, en it wichtichste binne se allegear fergees en yn it publike domein, wat betsjut dat elke programmeur de
Open Source -lisinsje kin fine dy’t perfoarst past by syn projekt. Mar, it wichtichste, moatte wy net ferjitte dat in Open Source-lisinsje net allinich in koade is sûnder lisinsje. Mei in bytsje ûndersyk kinne jo alle Open Source-lisinsjes sammelje en se ferdiele yn trije grutte haadgroepen:
- Sterk beskermjend.
- Weakly beskermjende.
- Permissive.
sterk beskermjende
Sterk beskermjende lisinsjes binne meastentiids fariaasjes fan ‘e GPL. Dizze lisinsjes fereaskje de lisinsje fan it projekt en ek de iepenbiering fan boarnekoades, nettsjinsteande hoe’t elke koade of projekt sil wurde brûkt of al brûkt.
Weakly beskermjende
Swak beskermjende lisinsjes binne meast farianten fan ‘e Lesser GPL. Dêryn is it wichtichste ferskil fan permissive lisinsjes dat hjir gewoan nedich is om it programma ek te fergunnen ûnder de GPL-lisinsje, en ek de boarnekoades sûnder mis te leverjen. Tagelyk, as d’r in bibleteek is yn it projekt fan ‘e programmeur, dat is, statyske keppeling of dynamyske keppeling ûnder de LGPL-lisinsje, dan sil it ek kompatibel wêze mei ien fan’ e lisinsjes fan it projekt fan dizze programmeur.
Wêr’t it GitHub-lisinsjetype oantsjutte is[/ caption]
permissive
D’r binne in frij grut oantal permissive lisinsjes, yn har rigen binne de populêrste lisinsjes MIT, Apache 2.0, en BSD. Mei lytse fariaasjes hawwe dizze lisinsjes de mooglikheid om it gebrûk fan ‘e koade te tastean sawol yn Open Source-projekten as foar kommersjele doelen en projekten. Mar yn dit gefal is it wichtich om te betinken dat it nedich is om it auteurskip fan it orizjinele programma oan te jaan.
Oare populêre GitHub-lisinsjes
Neist dizze trije groepen fan lisinsjes, der binne ek oaren, Bygelyks, in oare fan de meast brûkbere lisinsjes is GPLv2 mei classpath extensions. Dizze lisinsje kin ek brûkt wurde foar sawol iepen boarne-projekten as kommersjele projekten en doelen. It populêrste uterlik is by Oracle, dy’t GPLv2 brûkt mei classpath-útwreidings om syn Open Source-projekten en oplossingen te lisinsje. Dizze lisinsje is frij wichtich en nuttich, om’t gewoane GPL-lisinsjes bygelyks noait mei bytekoade kinne omgean. Dat is, se hawwe in spesjale beskriuwing fan it kompilaasje- en keppelingsproses, dat folslein net geskikt is foar oare ynterpretearre programmeartalen, de populêrste Java-taal is ûnder sokke talen. It is foar sokke gefallen dat in spesjale lisinsje GPLv2 mei classpath tafoegings waard útbrocht. Der stiet ommers hiel dúdlik en dúdlik dat de bibleteek dy’t ûnder dizze lisinsje frijjûn is brûkt wurde kin foar kommersjele projekten en doelen mei absolút elke oare lisinsje.
Wat jo oars moatte witte oer
GitHub-lisinsjes .
It tafoegjen fan in lisinsje
Nei’t de definitive lisinsje úteinlik is selektearre, bliuwt it allinich om it ta te foegjen oan ‘e projektroot sels. Om dizze aksje út te fieren, moatte jo gewoan de selekteare lisinsje tafoegje ûnder de projektroot by it oanmeitsjen fan it projekt sels of op in oar momint. Mar sels yn dizze aksje slagge de GitHub-webtsjinst om har brûkers te fersoargjen en se makken in frij handige manier om de definitive lisinsje ta te foegjen, sels oan it begjin fan it projekt sels.
Spitigernôch is dit lykwols net alles, om’t de ûntwikkelder of programmeur perfoarst alle ôfhinklikens moat kontrolearje dy’t brûkt waarden yn syn idee of projekt. Dat is, as sels ien fan ‘e ôfhinklikens dy’t is frijjûn ûnder de GPL-lisinsje, dan moat perfoarst it hiele projekt fan ‘e ûntwikkelder GPL-kompatibel wêze. Foar sa’n ferifikaasje wurde hjirfoar meastentiids ûntwurpen programma’s of ark brûkt. Bygelyks, d’r is in ark foar dit https://github.com/pivotal/LicenseFinder:
Wy kinne sizze dat fergunningferliening in nochal tiidslinend taak is, mar tagelyk in needsaaklike aksje foar it libben fan in projekt as elk idee fan in programmeur. Om de juste lisinsje te kiezen, moatte jo spitigernôch in protte tiid besteegje, mar it is it wurdich foar it projekt om suksesfol te wêzen. It is it bêste om de kar fan lisinsje op it earste plak te setten by it skriuwen fan in programma, om’t troch dit oan it begjin te dwaan, kinne jo absolút al jo ynspanningen yn ‘e goede rjochting rjochtsje en in programma skriuwe dat suksesfol en handich sil wêze foar de measte brûkers.