Kiun permesilon elekti en GitHub: tipoj, komparo

Kiel elekti GitHub-licencon kaj kial gravas fari la ĝustan elekton? GitHub estas la plej granda servo por la komuna disvolviĝo de IT-projektoj kaj ilia posta gastigado. Kun la helpo de ĉi tiu retservo, senlima nombro da homoj povas labori pri projekto samtempe, same kiel de absolute ie ajn en la mondo. GitHub ankaŭ havas administradon aŭ kontrolsistemon, kiu ebligas al vi vidi kaj kontroli absolute ĉiujn ŝanĝojn faritajn de programistoj laŭlonge de la tempo, kaj ĝi ankaŭ ebligas al vi reveni al la stato kiu okazis antaŭ la ŝanĝoj.
Sed simple diri, GitHub estas la tiel nomata socia reto por programistoj kaj programistoj, kie vi povas trovi kaj poste praktiki pri kodoj de aliaj programistoj. Vi ankaŭ povas konservi vian biletujon sur GitHub. Ĝenerale, GitHub estas servo bone taŭga por kaj komencaj programistoj kaj spertaj programistoj. Tamen, uzantoj de ĉi tiu servo foje povas havi kelkajn demandojn pri elekto de permesilo, ĉar ilia elekto tie estas sufiĉe diversa.

Kio estas GitHub-licenco

Licenco estas speciala dokumento, kiu estis establita de la ŝtata formo kaj permesas vin okupiĝi pri certa tipo de entreprena agado, kiu senmanke postulas specialan atenton de la ŝtata flanko. Sed, plej ofte, en la praktiko, estas uzataj nur mallongigitaj licencinterkonsentoj aŭ interkonsentoj, kiuj antaŭvidas la emision de privataj juraj licencoj. Ĝenerale, la permesilo celas nur unu, sed la plej gravan celon, ĉi tio estas interkonsento pri devoj kaj rajtoj inter la licencanto kaj la licencito. Tiuj ĉi devoj kaj rajtoj povas esti absolute io ajn, sed nur kadre de la leĝo. Rimarkinda ekzemplo estas ke la licencinto povas postuli la nomon de la posedanto de la kopirajto esti postulata kiam uzado de la laboro de la licencito. Aŭ, ekzemple, permesi kopilaboron, sed malpermesi absolute ajnan modifon de ĝi. Aŭ, por montri tiajn postulojn, ke la verko estu eldonita en ekzakte la samaj kondiĉoj kiel la originala, kaj tiel plu, estas sufiĉe multaj ekzemploj de prezentado de diversaj kondiĉoj. [Caption id = “aldonaĵo_12368” align = “aligncenter” larĝo = “780”]
Ekzemplo de unu el la Apache-licencoj[/caption]

Sed, ankaŭ, ni ne devas forgesi, ke la permesilo protektas la rajtojn de ne nur la licencanto, sed ankaŭ la licencito. Ĉar en ĝi vi povas klare vidi kaj legi ĉiujn kondiĉojn por uzi la verkon, kaj tial li ne bezonas timi, ke la licencanto subite postulos ajnajn deduktojn aŭ alian kompenson por la uzo de sia laboro.

Se vi rifuzas uzi la permesilon asociitan kun la verko, kopirajtoj ankoraŭ validas laŭ la juraj reguloj validaj en aparta lando. Simple dirite, la foresto de permesilo neniel implicas, ke aliaj aŭtoroj povas uzi ĉi tiun projekton kiel ili volas. Ĉio estas ĝuste la malo, ĉar sen iu specifa permesilo, la programisto en neniu kazo rezignas la rajtojn kiuj estis donitaj de leĝo. Ankaŭ gravas ĉiam memori, ke la permesilo regas ĉiujn rajtojn kaj devojn. Ĉi tio estas por protekti la posedanton de la verko kontraŭ atendoj de uzantoj kaj kion implicas ajna garantio. Post ĉio, neniu volas, ke ilia kodo alvenu en tribunalo iel.

Kio estas kopirajto

Kopirajto aperas en homo nur kiam, kiel rezulto de intelekta agado, li kreas certan verkon, kiu estos unika, sed samtempe utila, ekzemple, vi povas preni la verkadon de la sama programo. Kiam ĉio supre estas farita, la persono fariĝas la aŭtoro kaj nun li havas absolute ĉiujn kopirajtojn al ĉi tiu verko. Oni ankaŭ devas diri, ke kopirajtoj estas posedaĵo kaj ne-posedaĵo. Ilia diferenco estas, ke posedrajtoj povas esti transdonitaj al iu ajn, sed nepropraj rajtoj ĉiam restos nur ĉe la aŭtoro en ajna situacio. Ja esti aŭtoro estas netransdonebla kaj neforigebla rajto.

Por kio estas Malferma Fonta permesilo?

Ĉi tio ankaŭ estas sufiĉe populara demando inter komencaj programistoj kaj programistoj, ĉar ili simple ne komprenas kial permesilo devas esti alfiksita al siaj projektoj, ĉar sen ĝi la projekto ankaŭ povas ekzisti trankvile. Tamen tio ne estas tute vera, ĉar se, ekzemple, iu komencanta programisto skribis iun sufiĉe gravan kaj utilan kodon, sed ne protektis ĝin per permesilo, tiam aliaj uzantoj havas demandojn. Kaj ĝuste pro tio, kiam klientoj venas al li kaj volas uzi ĉi tiun kodon por siaj komercaj celoj, ili vidas, ke la kodo ne havas neniun permesilon kaj simple rifuzas ĝin. Ĉi tio estas pro la fakto, ke kompanioj simple ne uzos la kodon sen permesilo, ĉar ili ne bezonas problemojn kun la leĝo kaj advokatoj.
Kaj tial eĉ la plej utila kaj oportuna projekto neniam estos efektivigita. Kaj la programisto, kiu volis preni ĉi tiun pecon de kodo, devos serĉi kaj uzi alternativon, aŭ tute reverki la kodon, kiu estis jam skribita de la komencanto ellaboranto pli frue. Tial estas plej bone certigi anticipe, ke la programisto uzas la ĝustan, kaj plej grave, taŭgan permesilon. Esplorante GitHub en unu videolernilo en 15 minutoj: https://youtu.be/JfpCicDUMKc

Kiu GitHub-licenco taŭgas en certaj kondiĉoj – kiel elekti?

Ne povas esti preciza respondo al ĉi tiu demando, ĉar la elekto de permesilo dependas nur de la celoj de la projekto kaj de la personaj preferoj kaj deziroj de la programisto mem. Kiel vi povas vidi, estas multaj diversaj licencoj sur GitHub, kaj plej grave, ili ĉiuj estas senpagaj kaj en la publika havaĵo, kio signifas, ke ĉiu programisto povas trovi la
Malfermfontan permesilon, kiu certe konvenos al sia projekto. Sed, plej grave, ni ne devas forgesi, ke Malfermfonta permesilo ne estas nur kodo sen permesilo.

Kun iom da esploro, vi povas kolekti ĉiujn Malfermfontajn permesilojn kaj dividi ilin en tri grandajn ĉefajn grupojn:

1. Forte protekta.
2. Malforte protekta.
3. Permesa.

forte protekta

Forte protektaj permesiloj estas plej ofte variaĵoj de la GPL. Ĉi tiuj permesiloj postulas la licencon de la projekto same kiel la malkaŝon de fontkodoj, sendepende de kiel iu kodo aŭ projekto estos uzata aŭ jam estis uzata.

Malforte protekta

Malforte protektaj permesiloj estas plej ofte variaĵoj de la Malgranda GPL. En kiu la ĉefa diferenco de permesaj permesiloj estas, ke ĉi tie estas simple necese ankaŭ licenci la programon sub la GPL-licenco, kaj ankaŭ provizi la fontkodojn senmanke. Samtempe, se ekzistas biblioteko en la projekto de la programisto, tio estas, statika ligo aŭ dinamika ligo sub la LGPL-licenco, tiam ĝi ankaŭ estos kongrua kun iu ajn el la permesiloj de la projekto de ĉi tiu programisto. [Caption id=”attachment_12364″ align=”aligncenter” width=”698″]
Kie la GitHub-licenca tipo estas specifita[/caption]

permesema

Estas sufiĉe granda nombro da permesaj permesiloj, en iliaj rangoj la plej popularaj permesiloj estas MIT, Apache 2.0 kaj BSD. Kun etaj varioj, ĉi tiuj permesiloj havas la kapablon permesi la uzon de la kodo kaj en Open Source projektoj kaj por komercaj celoj kaj projektoj. Sed, en ĉi tiu kazo, estas grave memori, ke necesas indiki la aŭtorecon de la originala programo.

Aliaj popularaj GitHub-licencoj

Krom ĉi tiuj tri grupoj de permesiloj, ekzistas ankaŭ aliaj, ekzemple, alia el la plej utilaj permesiloj estas GPLv2 kun klasvojaj etendoj. Ĉi tiu permesilo ankaŭ povas esti uzata por kaj Malfermfontaj projektoj kaj komercaj projektoj kaj celoj. Ĝia plej populara aspekto estas ĉe Oracle, kiu uzas GPLv2 kun klasvojetendaĵoj por licenci siajn Malfermfontajn projektojn kaj solvojn. Ĉi tiu permesilo estas sufiĉe grava kaj utila, ĉar regulaj GPL-licencoj, ekzemple, neniam povos trakti bajtkodon. Tio estas, ili havas specialan priskribon de la kompilo kaj ligprocezo, kiu estas tute maltaŭga por aliaj interpretitaj programlingvoj, la plej populara Java lingvo estas inter tiaj lingvoj. Estas por tiaj kazoj, ke speciala permesilo GPLv2 kun klasvojetendaĵoj estis liberigita. Post ĉio, ĝi diras tre klare kaj klare, ke la biblioteko kiu estis liberigita sub ĉi tiu permesilo povas esti uzata por komercaj projektoj kaj celoj kun absolute ajna alia permesilo.
Kion alian vi bezonas scii pri
GitHub-licencoj .

Aldonante permesilon

Post kiam la fina permesilo estas finfine elektita, restas nur aldoni ĝin al la projekta radiko mem. Por plenumi ĉi tiun agon, vi devas simple aldoni la elektitan permesilon sub la projekta radiko dum la kreado de la projekto mem aŭ en ajna alia momento. Sed eĉ en ĉi tiu ago, la retservo de GitHub sukcesis prizorgi siajn uzantojn kaj ili faris sufiĉe oportunan manieron aldoni la finan permesilon eĉ ĉe la komenco de la projekto mem.
Tamen, bedaŭrinde, ĉi tio ne estas ĉio, ĉar la programisto aŭ programisto bezonas kontroli absolute ĉiujn dependecojn, kiuj estis uzataj en sia ideo aŭ projekto. Tio estas, se eĉ unu el la dependecoj kiuj estas liberigitaj sub la GPL-licenco, tiam absolute la tuta ellaboranto projekto devas esti GPL kongrua. Por tia konfirmo, antaŭe desegnitaj programoj aŭ iloj estas kutime uzataj por tio. Ekzemple, ekzistas ilo por ĉi tiu https://github.com/pivotal/LicenseFinder:
Ni povas diri, ke licencado estas sufiĉe tempopostula tasko, sed samtempe necesa ago por la vivo de projekto aŭ ajna ideo de programisto. Por elekti la ĝustan permesilon, bedaŭrinde vi devas elspezi sufiĉe da tempo, tamen, indas, ke la projekto sukcesu. Plej bone estas meti la elekton de permesilo en la unua loko kiam vi verkas iun ajn programon, ĉar farante tion ĉe la komenco, vi povas direkti absolute ĉiujn viajn klopodojn en la ĝusta direkto kaj skribi programon, kiu estos sukcesa kaj oportuna por plej multaj. uzantoj.