Mida peate teadma GitHubi litsentside kohta: kuidas valida ja lisada

GitHubi litsentsid – millest me räägime? Tarkvara loomiseks ei pea mitte ainult seda kirjutama, vaid ka otsustama, mida kasutajatel või arendajatel on õigus sellega peale hakata. Kui keegi teeb kõigile tasuta programmi, teeb ta heateo, aga kes seda kasutab, peab põhjendama, kuidas ta seda kasutab. Näiteks kui ettevõte hakkab oma tegevuses töötama mõne tasuta kontoriga (näiteks LibreOffice), siis peab ta suutma inspektoritele tõestada, et tal on selleks õigus. Selleks piisab vastava litsentsi esitamisest. Kui arendaja unustab selle sõnastada, võib ettevõte sattuda raskesse olukorda.

Rakenduse loomisel peab arendaja otsustama, millised toimingud tema programmiga on lubatud ja millised mitte. Näiteks saame rääkida mitte ainult kasutamisest, vaid ka programmide tekstide uurimisest või tarkvaratootes oma muudatuste tegemisest. GitHub on üks suurimaid koostööprojektide arendamise teenuseid. Samal ajal saavad nad siin töötada mitte ainult tasuta, vaid ka kommertsprojektides. Sobiva litsentsi määramisega kõrvaldavad arendajad loodud toote kasutamise osas ebaselgused. Probleem on selles, et litsentse on palju erinevaid ja alati ei ole lihtne kindlaks teha, millist valikut konkreetsel juhul valida. Samuti pole haruldane, et mõnel projektil puudub litsents.

Miks peate GitHubis avatud lähtekoodiga projekte litsentsima?

Nõutava litsentsi määramisel saab arendaja selles esitada järgmise:

1. Programmi kasutustingimused . Need võivad hõlmata tasu või mõnel või kõigil juhtudel lubada tasuta kasutamist.
2. Mõnikord luuakse programme kogukonna poolt väljatöötamiseks . Sel puhul on oluline, et saatetekstidega tutvuksid kõik soovijad.
3. Kui programmi tekstid on saadaval, võivad mõned programmi funktsionaalseks ja võimalikult töökindlaks muutmiseks teha muudatusi . Mõnikord võib autor lubada seda kõigil teha, teistel juhtudel pakub ta muudatuse saatmist talle ja teeb projektis ise muudatusi.
4. Peate otsustama, kas kolmandad osapooled saavad nende nimel projekti ja pakkumisi teha. Seda tehes peate määrama, millise litsentsiga nende toode peaks olema.

Neid ja sarnaseid küsimusi lahendades määrab rakenduse autor tegelikult suuresti enda loodud tarkvaratoote edasise saatuse.

Mis tüüpi litsentsid on olemas

Litsents on leping, milles üks pool (litsentsiandja) kehtestab reegli, mille kohaselt teine ​​pool (litsentsiaat) kasutab enda loodud toodet. Praktikas ei räägi me dokumendile pooltepoolsest allkirjastamisest, vaid automaatsest nõustumisest vastavate õiguste ja kohustustega selle kasutamisel. Õiguste ja kohustuste täpsustamisel praktiliselt puuduvad piirangud. Ainus tingimus on see, et nad peavad järgima seadust. Enda litsentside loomine on keeruline töö, kuna see peab ühilduma teiste eeskirjadega. Parim võimalus on valida ja kasutada üht sellistest dokumentidest. Praktikas on tavaks kasutada ka multilitsentsimist. Kõige sagedamini kasutatakse sellistel juhtudel korraga kahte litsentsi. Kuigi programmi autoril on õigus iseseisvalt sõnastada reeglid, mida kasutajad peavad järgima, on sellest hoolimata praktikas välja kujunenud suure hulga litsentsitüüpide kasutamine, mille hulgast saab enamikul juhtudel valida õige. Järgmised on Git Hubis kõige populaarsemad võimalused, mida enamikul juhtudel kasutatakse. Git Hubis kõige sagedamini kasutatavad litsentsid on järgmised:
Programmeerija peab saama valida ühe, mis sobib tema plaanidega. Selle korrektseks tegemiseks peate mõistma, millised omadused on teatud liikidele omased.

Kui autor keeldub dokumenti vormistamast, kehtivad sel juhul autoriõigused, mis on vaikimisi tema riigi õigusaktidega ette nähtud. Litsentsi puudumine sel viisil ei tähenda, et programmiga saaks midagi teha. Tegelikult võib sellist olukorda pidada üheks litsentsitüübiks.

Kuidas valida Githubi litsentsi

Enne sobiva variandi otsimist on vaja, et programmeerija sõnastaks oma nõuded, millest lähtudes ta edasise litsentsimisega jätkab. Järgmisena peaksite tutvuma tüüpiliste valikutega, mis vastavad päringule. Pärast seda peate hoolikalt uurima juriidilist keelt ja tegema lõpliku otsuse selle kohta, milline peaks olema litsents. Teadliku valiku tegemiseks peate mõistma, millised õigused ja kohustused on teatud tüüpi litsentsiga seotud. Õige valiku tegemiseks võite kasutada eriteenuseid, mida nimetatakse komparaatoriteks. siin on mõned näidised:

1. https://choosealicence.com/. Sellel saidil on juhivad küsimused õige valiku valimiseks ja üksikasjalikud nõuanded, mis aitavad teil mõista kasutusfunktsioone.
2. Leht https://opensource.org/licenses on pühendatud erinevate tasuta tarkvaralahenduste ülevaatamisele.
3. Saiti https://tldrlegal.com/ võib pidada erinevate litsentsivalikute entsüklopeediaks. Seal on nii täpsed juriidilised sõnastused kui ka üksikasjalikud kommentaarid.

Kõige produktiivsem viis valida on asjakohaste juriidiliste dokumentide hoolikas läbi lugemine . Kuigi me räägime töömahukatest tegevustest, annab tekstide uurimine arendajale kõik vajalikud vastused.

Kuidas Githubile litsentsi lisada

Vaatamata laiale litsentsivalikute valikule, mis on praktikas osutunud tõhusaks ja usaldusväärseks, võib arendajal olla oma ideid selle kohta, milline peaks olema tema loodud programmi litsents. Sel juhul annab teenus võimaluse lisada oma versioon või kohandada olemasolevat. Githubile litsentsi lisamiseks peate järgima neid samme.

1. Peate minema oma hoidla avalehele.
2. Faili lisamiseks peate klõpsama nuppu ja seejärel valima “Loo uus fail”.
3. Järgmisena peate sisestama faili nime. Litsentsi puhul võib see olla üks kahest valikust: LICENSE või LICENCE.md. Siin on suurtähtede kasutamine kohustuslik.
4. Litsentsimalli valimiseks klõpsake failinime sisestusväljast paremal.
5. Valige lehe vasakpoolsest menüüst rida “Lisage oma projektile litsents”. Sel juhul valitakse variant olemasolevate dokumentide hulgast.
6. Seejärel klõpsake real “Vaata üle ja esitage”. Seejärel sisestage oma lepingu andmed.
7. Pärast seda on vaja selgitada, mis täiendusi või muudatusi tehti. Järgmisena märkige, kas valitud dokumenti parandati või on tegemist litsentsi teise versiooni loomisega.

Pärast muudatuste kinnitamist viib arendaja läbi Git Hubi teenuse litsentside loendis muudatuste tegemise protseduuri.

Valige Githubi litsents – Git Hubi populaarsete litsentside näited

Järgmised on kõige populaarsemad valikud. Mõistes nende tugevaid ja nõrku külgi, suudab programmeerija leida õige valiku või mõista, kuidas tõhusalt otsida.

GPL

Seda litsentsi võib nimetada üheks populaarsemaks. See on klassikaline neile, kes toodavad tasuta tarkvara. Selle dokumendi üks peamisi nõudeid on see, et see võimaldab kolmandatel isikutel programmi vabalt muuta , kuid samal ajal on neil õigus levitada tulemust ainult sama litsentsi alusel. Sellel litsentsil võivad olla erinevad versioonid. Viimane neist on kolmas. GPL-i on kasutanud selliste programmide arendajad nagu Drupali veebisisuhaldussüsteem, MariaDB andmebaasihaldussüsteem, InkSkape vektorgraafika redaktor ja mõned teised. Huvitav on märkida, et SQL ei kasuta mitte ainult GPL-i, vaid ka kommertslitsentsi.

LGPL

See nimi tähendab tõlkes “GNU GPL Lesser General Public License”. Mõnele arendajale ei sobi GPL, kuna see loob neile kohustuse levitada muudetud tooteid sama litsentsi alusel. Selle valiku rakenduse funktsioone saab illustreerida sellega, kuidas toimub programmeerija loodud teekide kasutamise litsentsimise protsess. Sel juhul kaalutakse järgmist kolme võimalust:

1. Kui teek pakub uusi funktsioone, kus ükski teine ​​kaubanduslik raamatukogu ei saa sama teha, on GPL parim valik.
2. Tasuta raamatukogu arendaja on olemasoleva standardi juba juurutanud. Selles piirkonnas on sarnaste funktsioonidega kaubanduslikke võimalusi. Sel juhul on mugav valida LGPL.
3. Kui tegemist on uue standardiga, mis tegelikult konkureerib kaubandusliku standardiga, on Apache litsents õige tee.

See standard lubab raamatukogude ärilist kasutamist . Kui tehakse muudatusi, tuleb levitamisel kasutada samu tingimusi. Koodi lihtne kasutamine võimaldab aga tingimusi muuta.

Eclipse’i avalik litsents

See dokument lubab levitamist teiste litsentside, sealhulgas kaubanduslike litsentside alusel . Peamine tingimus on, et muudetud töödes paigutatakse uuendused eraldi moodulisse. See litsents on kogunud populaarsust Java-toodete arendamisel. Näiteks on programmeerimiskeel Clojure, Java rakenduste testimise raamistik.

Mozilla avalik litsents

Mõned peavad seda dokumenti kompromissiks GPL-i ja kommertslitsentside vahel. MPL nõuab avatud juurdepääsu teatud failidele . Tarkvaratoode võib sisaldada mõningaid selle litsentsi alla kuuluvaid faile ja teisi ilma selleta. Pärast muudatust on lubatud panna vajalik litsents (see võib olla näiteks kommertslik), kuid see on võimalik ainult tingimusel, et juurdepääs MPL-i alusel välja antud failidele on endiselt avatud. Sel juhul tuleb lõppkasutajale edastada teave originaaltarkvara autorite kohta. Selle dokumendi kohaselt lasti välja LibreOffice’i kontor, Mozilla brauser ja muud tarkvaratooted.

Apache litsents Github

AL-i nimetatakse liberaalseks vabalitsentsiks. See funktsioon on tingitud asjaolust, et ei ole nõuet tuletistoote vabastamist samadel tingimustel kui varem . Seda dokumenti kasutab aktiivselt Apache Software Foundation. Kasutamisel on lubatud järgmine:

1. Tarkvaratoodet on lubatud edasi kasutada ärilistel eesmärkidel.
2. Rakenduse muudatused on lubatud.
3. Hilisemad levitused peaksid sisaldama algse autori nime.

Uue variandi loomisel ei ole litsentsisaajatel kohustust esitada algset tootekoodi. Selline litsents on saavutanud märkimisväärse populaarsuse. Seda saab näidata, loetledes tuntud tarkvaratooted, mis on seda tüüpi litsentsi alusel välja antud: Androidi operatsioonisüsteem, Javas ettevõtterakendusi loov raamistik ja Apache veebiserver. https://youtu.be/wyZq-EazOmU

MIT litsents

Mõned peavad seda tasuta tarkvara litsentsi võimalust kõige populaarsemaks. Mõned peavad selle peamiseks eeliseks head ühilduvust erinevat tüüpi tasuta või kommertslitsentsidega. Kõige olulisemad funktsioonid on koodi muutmise võimalus, aga ka muude litsentside alusel levitamise luba muudatuste teinud isiku valikul . Seda dokumenti kasutavad tarkvaratooted: JavaScripti teek nimega JQuiery, Atomi tekstiredaktor, AngularJS, JavaScripti arendusraamistik.

Veealused kivid

Mõnikord valib autor algul ühe litsentsi versiooni ja soovib hiljem seda muuta. Kui ta koostaks programmi üksi, poleks selline muudatus keeruline. Kui aga arenduses oli palju osalejaid, siis ilma nende nõusolekuta see ei toimi. Näiteks Linuxi looja, kuigi ta tegelikult lõi operatsioonisüsteemi aluse, ei saa litsentsi muuta ilma kõigi edasises arenduses osalenud programmeerijate nõusolekuta. MPL-i alusel levitamisel ei saa koodi muutnud isikud pakkuda MPL-i alla kuuluvaid faile teise litsentsi all. Uue dokumendi kasutamine viitab teistele programmimoodulitele.