Kion vi bezonas scii pri GitHub-licencoj: kiel elekti kaj aldoni

GitHub-licencoj – pri kio ni parolas? Por krei programaron, oni devas ne nur skribi ĝin, sed ankaŭ decidi, kion uzantoj aŭ programistoj rajtas fari kun ĝi. Se iu kreas senpagan programon por ĉiuj, li faras bonan agon, sed kiu ĝin uzas, tiu devos pravigi kiel li ĝin uzas. Ekzemple, se firmao en siaj agadoj laboros kun iu senpaga oficejo (ekzemple, LibreOffice), tiam ĝi devas povi pruvi al inspektistoj ke ĝi havas la rajton fari tion. Por fari tion, sufiĉos prezenti la taŭgan permesilon. Se la programisto forgesas formuli ĝin, tiam la kompanio povas esti en malfacila pozicio. [Caption id = “aldonaĵo_11854” align = “aligncenter” larĝo = “1024”]
Klasifiko de permesiloj kaj specoj de permesiloj[/caption] Kreante aplikaĵon, la programisto devas decidi kiuj agoj kun sia programo estos permesitaj kaj kiuj ne. Ekzemple, ni povas paroli ne nur pri uzado, sed ankaŭ pri studado de la tekstoj de programoj aŭ fari viajn proprajn ĝustigojn al la programaro. GitHub estas unu el la plej grandaj servoj por kunlabora projekto-disvolviĝo. Samtempe ili povas labori ĉi tie ne nur senpage, sed ankaŭ pri komercaj projektoj. Specifante la taŭgan permesilon, la programistoj forigos ambiguecojn pri kiel uzi la kreitan produkton. La problemo estas, ke ekzistas multaj malsamaj specoj de permesiloj, kaj ne ĉiam estas facile determini kiun opcion elekti en aparta kazo. Ankaŭ ne malofte iuj projektoj ne havas permesilon.

Kial vi bezonas licenci Open Source-projektojn sur GitHub

Kiam oni specifas la bezonatan permesilon, la programisto povas provizi la jenon en ĝi:

1. Kondiĉoj de uzo de la programo . Ili povas impliki kotizon aŭ, en iuj aŭ ĉiuj kazoj, permesi liberan uzon.
2. Kelkfoje programoj estas kreitaj por esti disvolvitaj de la komunumo . En ĉi tiu kazo, gravas, ke ĉiuj, kiuj volas konatiĝi kun la programtekstoj.
3. Kiam la tekstoj de la programo disponeblas, iuj povus fari ŝanĝojn por ke la programo estu funkcia kaj kiel eble plej fidinda. Foje la aŭtoro povas permesi al ĉiuj fari tion, en aliaj kazoj li proponas sendi la ŝanĝon al li, kaj faras alĝustigojn al la projekto memstare.
4. Vi devas decidi ĉu triaj povas fari ŝanĝojn al la projekto kaj oferti en sia nomo. Farante tion, vi devas specifi per kiu permesilo devas esti ilia produkto.

Solvante ĉi tiujn kaj similajn demandojn, la aŭtoro de la aplikaĵo fakte plejparte determinas la estontan sorton de la programaro, kiun li kreis.

Kiaj specoj de permesiloj ekzistas

Licenco estas interkonsento en kiu unu partio (la licencanto) establas regulon por la alia partio (la licencito) por uzi la produkton kreitan de li. En la praktiko, ni ne parolas pri subskribo de dokumento de la partioj, sed pri aŭtomata interkonsento kun la respondaj rajtoj kaj devoj sur ĝia uzo. Preskaŭ ne ekzistas limigoj pri specifado de rajtoj kaj devoj. La sola kondiĉo estas, ke ili devas plenumi la leĝon. Krei viajn proprajn permesilojn estas kompleksa laboro, ĉar ĝi devas esti kongrua kun aliaj regularoj. La plej bona elekto estas elekti kaj uzi unu el la normaj varioj de tiaj dokumentoj. Praktike, ankaŭ kutimas uzi multilicencadon. Plej ofte, en tiaj kazoj, du permesiloj estas uzataj samtempe. Kvankam la aŭtoro de la programo havas la rajton sendepende formuli la regulojn, kiujn uzantoj devas sekvi, tamen, en la praktiko, disvolviĝis la uzo de granda nombro da specoj de licencoj, el kiuj vi povas elekti la ĝustan plejofte. La jenaj estas la plej popularaj elektoj uzataj ĉe Git Hub en la plej multaj kazoj. La licencoj plej ofte uzataj en Git Hub estas:
La programisto devos povi elekti unu, kiu kongruas kun siaj planoj. Por fari tion ĝuste, vi devas kompreni, kiaj trajtoj estas propraj al iuj specioj.

Se la aŭtoro rifuzas formuli la dokumenton, tiam en ĉi tiu kazo aplikiĝos kopirajtoj, kiuj estas defaŭlte antaŭviditaj de la leĝaro de sia lando. La foresto de permesilo tiamaniere ne signifas, ke io ajn povas esti farita kun la programo. Fakte, tia situacio povas esti konsiderata kiel unu el la specoj de permesilo.

Kiel elekti Github-licencon

Antaŭ ol vi komencas serĉi taŭgan opcion, necesas, ke la programisto formulu siajn postulojn, de kiuj li daŭrigos plian licencadon. Poste, vi devus konatiĝi kun la tipaj elektoj, kiuj kongruas kun la peto. Post tio, vi devos zorge studi la juran lingvon kaj fari finan decidon pri kio estu la permesilo. Por fari informitan elekton, vi devas kompreni, kiaj rajtoj kaj devoj estas asociitaj kun aparta tipo de permesilo. Por fari la ĝustan elekton, vi povas uzi specialajn servojn nomitajn kompariloj. Jen kelkaj ekzemploj:

1. https://choosealicense.com/. Ĉi tiu retejo havas ĉefajn demandojn por elekti la ĝustan opcion kaj detalajn konsilojn por helpi vin kompreni la funkciojn de uzo.
2. La paĝo https://opensource.org/licenses estas dediĉita al revizio de diversaj solvoj pri libera programaro.
3. La retejo https://tldrlegal.com/ povas esti konsiderata kiel enciklopedio por diversaj licencaj elektoj. Estas kaj precizaj juraj formuliĝoj kaj detalaj komentoj.

Tamen, la plej produktiva maniero elekti estas zorge legi la koncernajn jurajn dokumentojn . Kvankam ni parolas pri laborintensaj agadoj, tamen studi la tekstojn donos al la programisto ĉiujn necesajn respondojn.

Kiel aldoni permesilon al Github

Malgraŭ la ampleksa elekto de licencaj elektoj, kiuj pruvis esti efikaj kaj fidindaj en la praktiko, la programisto povas havi siajn proprajn ideojn pri kio devus esti la permesilo por la programo, kiun li kreis. En ĉi tiu kazo, la servo disponigas la kapablon aldoni vian propran version aŭ alĝustigi la ekzistantan. Por aldoni permesilon al Github, vi devos sekvi ĉi tiujn paŝojn:

1. Vi devas iri al la ĉefa paĝo de via deponejo.
2. Vi devas alklaki la butonon por aldoni dosieron, tiam elektu “Krei novan dosieron”.
3. Poste, vi devas enigi dosiernomon. Por permesilo, ĉi tio povas esti unu el du opcioj: LICENSE aŭ LICENCE.md. Ĉi tie la uzo de majuskloj estas deviga.
4. Dekstre de la dosiernomo eniga kampo, alklaku por elekti permesilan ŝablonon.
5. En la menuo maldekstre de la paĝo, elektu la linion “Aldonu permesilon al via projekto”. En ĉi tiu kazo, varianto estas elektita el ekzistantaj dokumentoj.
6. Poste alklaku la linion “Revizii kaj sendi”. Poste enigu viajn interkonsentodetalojn.
7. Post tio, necesas klarigi, kiaj la aldonoj aŭ ŝanĝoj estis faritaj. Poste, indiku ĉu la elektita dokumento estis korektita aŭ ĉu temas pri kreado de alia versio de la permesilo.

Post konfirmi la ŝanĝojn, la programisto kompletigas la proceduron por fari ŝanĝojn al la listo de permesiloj en la servo Git Hub.

Elektu permesilon GitHub – ekzemploj de popularaj permesiloj en Git Hub

La jenaj estas la plej popularaj elektoj. Komprenante iliajn fortojn kaj malfortojn, la programisto povos trovi la ĝustan opcion aŭ kompreni kiel efike serĉi.

GPL

Ĉi tiu permesilo povas esti nomita unu el la plej popularaj. Ĝi estas klasika por tiuj, kiuj produktas liberan programaron. Unu el la ĉefaj postuloj de ĉi tiu dokumento estas, ke ĝi
permesas al triaj partioj libere modifi la programon , sed samtempe ili rajtas distribui la rezulton nur sub la sama permesilo. Ĉi tiu permesilo povas havi malsamajn versiojn. La lasta el ĉi tiuj estas la tria. La GPL estis uzita fare de programistoj de programoj kiel ekzemple la Drupalo retejo enhavadministradsistemo, la MariaDB datumbaza administradsistemo, la InkSkape vektora grafikredaktilo, kaj kelkaj aliaj. Estas interese rimarki, ke SQL uzas ne nur la GPL, sed ankaŭ komercan permesilon.

LGPL

Ĉi tiu nomo tradukiĝas al “GNU GPL Lesser General Public License”. Por iuj programistoj, la GPL ne taŭgas, ĉar ĝi kreas devigon por ili distribui modifitajn produktojn sub la sama permesilo. La funkcioj de la apliko de ĉi tiu opcio povas esti ilustritaj per kiel okazas la procezo de licencado de la uzo de bibliotekoj kreitaj de la programisto. En ĉi tiu kazo, la sekvaj tri elektoj estas konsiderataj:

1. Kiam biblioteko disponigas novan funkciecon kie neniu alia komerca biblioteko povas fari la samon, tiam la GPL estas la plej bona elekto.
2. La programisto en la senpaga biblioteko jam efektivigis la ekzistantan normon. En ĉi tiu areo, ekzistas komercaj opcioj kun similaj funkcioj. Por ĉi tiu kazo, estos oportune elekti LGPL.
3. Kiam temas pri nova normo, kiu efektive konkuras kun la komerca, la Apache-licenco estas la vojo por iri.

Ĉi tiu normo
permesas komercan uzon de bibliotekoj . Se modifoj estas faritaj, la samaj terminoj kaj kondiĉoj devas esti uzataj por distribuado. Tamen, la simpla uzo de la kodo permesas ŝanĝi la kondiĉojn.

Eclipse Publika Permesilo

Ĉi tiu dokumento
permesas distribuadon sub aliaj permesiloj, inkluzive de komercaj . La ĉefa kondiĉo estas, ke en la modifitaj verkoj, novigoj estos metitaj en apartan modulon. Ĉi tiu permesilo gajnis popularecon en la disvolviĝo de produktoj en Java. Ekzemplo estas la programlingvo Clojure, kadro por testi java-aplikojn.

Mozilo Publika Permesilo

Iuj vidas ĉi tiun dokumenton kiel kompromison inter la GPL kaj komercaj permesiloj. La MPL postulas
malferman aliron al certaj dosieroj . La programaro povas enhavi kelkajn dosierojn sub ĉi tiu permesilo kaj aliajn sen ĝi. Post la modifo, estas permesite meti la necesan permesilon (ekzemple ĝi povas esti komerca), sed tio eblas nur kondiĉe, ke aliro al dosieroj liberigitaj sub MPL ankoraŭ estos malfermita. En ĉi tiu kazo, la finuzanto devas ricevi informojn pri la aŭtoroj de la originala programaro. Konforme al ĉi tiu dokumento, la oficejo de LibreOffice, la retumilo Mozilla kaj aliaj softvaraĵoj estis publikigitaj.

Apache-Licenco Github

AL estas nomita la liberala libera permesilo. Ĉi tiu funkcio estas pro la fakto ke ne estas
postulo liberigi derivitan produkton sub la samaj kondiĉoj kiel antaŭe . Ĉi tiu dokumento estas aktive uzata de la Apache Software Foundation. Kiam estas uzata, la sekvanta estas permesita:

1. La programaro rajtas esti plu uzata por komercaj celoj.
2. Aplikaj modifoj estas permesitaj.
3. Postaj distribuoj devus inkluzivi la nomon de la origina aŭtoro.

Kreante novan varianton, ne estas devigo por licencitoj disponigi la originan produktkodon. Tia permesilo akiris konsiderindan popularecon. Ĉi tio povas esti pruvita listigante konatajn softvarajn produktojn, kiuj estas publikigitaj sub ĉi tiu speco de permesilo: la Android-operaciumo, kadro kiu kreas entreprenajn aplikaĵojn en Java, kaj la Apache-retservilo. https://youtu.be/wyZq-EazOmU

Licenco MIT

Iuj konsideras ĉi tiun liberprogramaran licencan opcion kiel la plej populara. Ĝia ĉefa avantaĝo estas konsiderata de iuj kiel bona kongruo kun diversaj specoj de liberaj aŭ komercaj permesiloj. La plej gravaj funkcioj estas la
kapablo modifi la kodon, same kiel la permeso distribui sub aliaj permesiloj laŭ la elekto de tiu, kiu faris la ŝanĝojn . La softvaraĵoj kiuj uzas ĉi tiun dokumenton estas: JavaScript-biblioteko nomita JQuiery, Atom tekstredaktilo, AngularJS, JavaScript-disvolva kadro. [Caption id = “attachment_11851” align = “aligncenter” width = “1906”]
Komparo de permesilo de Git Hub[/caption]

Subakvaj rokoj

Kelkfoje la aŭtoro unue elektas unu version de la permesilo, kaj poste volas ŝanĝi ĝin. Se li kreus la programon sole, tiam tia ŝanĝo ne estus malfacila. Tamen, en kazoj kie estis multaj partoprenantoj en la evoluo, tiam sen ilia konsento ĉi tio ne funkcios. Ekzemple, la kreinto de Linukso, kvankam li efektive faris la bazon de la operaciumo, ne povos ŝanĝi la permesilon sen la konsento de ĉiuj tiuj programistoj, kiuj partoprenis en plua evoluo. Dum distribuado sub la MPL, tiuj kiuj faris ŝanĝojn al la kodo ne povas oferti dosierojn sub la MPL sub malsama permesilo. La uzo de la nova dokumento raportos al aliaj programmoduloj.