როგორ ავირჩიოთ GitHub ლიცენზია და რატომ არის მნიშვნელოვანი, რომ არ გააკეთოთ არასწორი არჩევანი? GitHub არის ყველაზე დიდი სერვისი IT პროექტების ერთობლივი განვითარებისთვის და მათი შემდგომი ჰოსტინგისთვის. ამ ვებ სერვისის დახმარებით შეუზღუდავი რაოდენობის ადამიანს შეუძლია ერთდროულად იმუშაოს პროექტზე, ისევე როგორც მსოფლიოს აბსოლუტურად ნებისმიერი ადგილიდან. ასევე GitHub-ში არის მართვის სისტემა ან კონტროლი, რომელიც საშუალებას გაძლევთ ნახოთ და აკონტროლოთ აბსოლუტურად ყველა ცვლილება დეველოპერების მიერ ნებისმიერ დროს, და ასევე საშუალებას გაძლევთ დაბრუნდეთ იმ მდგომარეობამდე, რომელიც მოხდა ცვლილებებამდე.
მაგრამ მარტივად რომ ვთქვათ, GitHub არის ეგრეთ წოდებული სოციალური ქსელი პროგრამისტებისა და დეველოპერებისთვის, სადაც შეგიძლიათ იპოვოთ და შემდეგ ივარჯიშოთ სხვა დეველოპერების კოდების გამოყენებით. თქვენ ასევე შეგიძლიათ შეინახოთ თქვენი პორტფოლიო GitHub-ში. მთლიანობაში, GitHub არის სერვისი, რომელიც კარგად შეეფერება როგორც დამწყებ დეველოპერებს, ასევე გამოცდილ პროგრამისტებს. თუმცა, ამ სერვისის მომხმარებლებს ზოგჯერ შეიძლება ჰქონდეთ კითხვები ლიცენზიის არჩევასთან დაკავშირებით, რადგან მათი არჩევანი იქ საკმაოდ მრავალფეროვანია.
რა არის GitHub ლიცენზია
ლიცენზია არის სპეციალური დოკუმენტი, რომელიც შეიქმნა სახელმწიფო ფორმით და საშუალებას აძლევს ადამიანს ეწეოდეს გარკვეული ტიპის სამეწარმეო საქმიანობა, რაც აუცილებლად მოითხოვს მონაწილე სახელმწიფოს განსაკუთრებულ ყურადღებას. მაგრამ, ყველაზე ხშირად, პრაქტიკაში გამოიყენება მხოლოდ შემოკლებული სალიცენზიო ხელშეკრულებები ან ხელშეკრულებები, რომლებიც ითვალისწინებს კერძო სამართლის ლიცენზიების გაცემას. ზოგადად, ლიცენზია მხოლოდ ერთს, მაგრამ ყველაზე მნიშვნელოვან მიზანს ისახავს მიზნად, ეს არის შეთანხმება ვალდებულებებისა და უფლებების შესახებ ლიცენზიანტსა და ლიცენზიატს შორის. ეს მოვალეობები და უფლებები შეიძლება იყოს აბსოლუტურად ნებისმიერი, მაგრამ მხოლოდ კანონის ფარგლებში. თვალსაჩინო მაგალითია ის, რომ ლიცენზიანტმა შეიძლება მოითხოვოს საავტორო უფლებების მფლობელის სახელის სავალდებულო მითითება ლიცენზიატის მიერ ნაწარმოების გამოყენებისას. ან, მაგალითად, დაუშვას ნაწარმოების კოპირება,მაგრამ აიკრძალოს მისი აბსოლუტურად ნებისმიერი ცვლილება. ან, რომ გამოვიტანოთ ისეთი მოთხოვნები, რომ ნამუშევარი უნდა იყოს წარმოებული აბსოლუტურად იგივე პირობებით, როგორც ორიგინალი და ა.შ., უამრავი მაგალითია მოყვანილი სხვადასხვა პირობების შესახებ.
Apache-ს ერთ-ერთი ლიცენზიის მაგალითი [/ წარწერა]
მაგრამ ასევე არ უნდა დაგვავიწყდეს, რომ ლიცენზია იცავს არა მხოლოდ ლიცენზიატის, არამედ ლიცენზიანტის უფლებებსაც. ვინაიდან მასში ნათლად შეგიძლიათ ნახოთ და წაიკითხოთ ნაწარმოების გამოყენების ყველა პირობა და ამიტომ მას არ უნდა ეშინოდეს, რომ ლიცენზიანტი მოულოდნელად მოითხოვს რაიმე ჰონორარს ან რაიმე სხვა კომპენსაციას მისი ნამუშევრის გამოყენებისთვის.
თუ თქვენ უარი თქვით ლიცენზიაზე, რომელიც ასოცირდება ნამუშევართან, საავტორო უფლებები კვლავ იმოქმედებს ამ ქვეყანაში მოქმედი სამართლებრივი წესების შესაბამისად. მარტივად რომ ვთქვათ, ლიცენზიის არარსებობა არანაირად არ ნიშნავს, რომ სხვა ავტორებს შეუძლიათ გამოიყენონ ეს პროექტი ისე, როგორც სურთ. ყველაფერი, აბსოლუტურად, პირიქით, რადგან რაიმე კონკრეტული ლიცენზიის გარეშე პროგრამისტი არანაირად არ იტყვის უარს კანონით მინიჭებულ უფლებებზე. ასევე მნიშვნელოვანია გვახსოვდეს, რომ ლიცენზია არეგულირებს ყველა უფლებასა და ვალდებულებას. ეს არის ნამუშევრის მფლობელის დაცვა მომხმარებლის მოლოდინებისგან და ნებისმიერი გარანტიისგან. არავის არ უნდა, რომ მისი კოდექსი სასამართლომდე მივიდეს.
რა არის საავტორო უფლება
საავტორო უფლება ადამიანს მხოლოდ მაშინ უჩნდება, როდესაც ინტელექტუალური აქტივობის შედეგად ქმნის ნაწარმოებს, რომელიც იქნება უნიკალური, მაგრამ ამავე დროს სასარგებლო, მაგალითად, შეგიძლიათ აიღოთ იგივე პროგრამის დაწერა. როცა ყოველივე ზემოთქმული კეთდება, ადამიანი ხდება ავტორი და ახლა მას აქვს აბსოლუტურად ყველა საავტორო უფლება ამ ნამუშევარზე. ისიც უნდა ითქვას, რომ საავტორო უფლებები არის საკუთრება და არა საკუთრება. მათი განსხვავება ისაა, რომ საკუთრების უფლება ნებისმიერს შეიძლება გადაეცეს, მაგრამ არა საკუთრების უფლება ყოველთვის დარჩება მხოლოდ ავტორს ნებისმიერ სიტუაციაში. ავტორი ხომ განუყოფელი და განუყოფელი უფლებაა.
რისთვის არის ღია კოდის ლიცენზია?
ეს ასევე საკმაოდ პოპულარული კითხვაა ახალბედა დეველოპერებსა და პროგრამისტებს შორის, რადგან მათ უბრალოდ არ ესმით, რატომ უნდა დაურთონ რაიმე ლიცენზია თავიანთ პროექტებს, რადგან ამის გარეშე პროექტი ასევე ადვილად იარსებებს. თუმცა, ეს მთლად ასე არ არის, რადგან თუ, მაგალითად, ზოგიერთმა ახალბედა დეველოპერმა დაწერა რამდენიმე საკმაოდ მნიშვნელოვანი და სასარგებლო კოდი, მაგრამ არ დაიცავს მას ლიცენზიით, მაშინ სხვა მომხმარებლებს აქვთ კითხვები. და ზუსტად ამის გამო, როდესაც კლიენტები მასთან მიდიან და სურთ ამ კოდის გამოყენება კომერციული მიზნებისთვის, ხედავენ, რომ კოდს არავითარი ლიცენზია არ აქვს და უბრალოდ უარს ამბობენ მასზე. ეს გამოწვეულია იმით, რომ კომპანიები უბრალოდ არ გამოიყენებენ კოდს ლიცენზიის გარეშე, რადგან მათ არ სჭირდებათ პრობლემები კანონთან და იურისტებთან.
და ამიტომ, ყველაზე სასარგებლო და მოსახერხებელი პროექტიც კი არასოდეს განხორციელდება. და დეველოპერს, რომელსაც სურდა კოდის ამ ნაწილის აღება, მოუწევს მოძებნოს და გამოიყენოს ალტერნატივა ან მთლიანად გადაწეროს კოდი, რომელიც ადრე უკვე დაწერილი იყო ახალბედა დეველოპერის მიერ. სწორედ ამიტომ, უმჯობესია წინასწარ დარწმუნდეთ, რომ პროგრამისტი იყენებს სწორ და რაც მთავარია, შესაფერის ლიცენზიას. გამოიკვლიეთ GitHub ერთ ვიდეო გაკვეთილში 15 წუთში: https://youtu.be/JfpCicDUMKc
რომელი GitHub ლიცენზია არის შესაფერისი გარკვეული პირობებისთვის – როგორ ავირჩიოთ?
ამ კითხვაზე ზუსტი პასუხი არ შეიძლება იყოს, რადგან ლიცენზიის არჩევანი დამოკიდებულია მხოლოდ პროექტის მიზნებზე და თავად დეველოპერის პირად პრეფერენციებსა და სურვილებზე. როგორც ხედავთ, GitHub-ზე უამრავი სხვადასხვა ლიცენზიაა და რაც მთავარია, ისინი ყველა უფასო და საჯაროა, რაც ნიშნავს, რომ ყველა პროგრამისტს შეუძლია იპოვნოს
ღია კოდის ლიცენზია, რომელიც ზუსტად შეესაბამება მის პროექტს. მაგრამ, რაც მთავარია, არ უნდა დაგვავიწყდეს, რომ ღია კოდის ლიცენზია არ არის მხოლოდ კოდი ლიცენზიის გარეშე.
ლიცენზიების ოჯახი GitHub-ზე [/ caption] მცირედი კვლევის შემდეგ, შეგიძლიათ შეაგროვოთ ყველა ღია კოდის ლიცენზია და დაყოთ ისინი სამ დიდ ძირითად ჯგუფად:
- ძლიერად დამცავი.
- სუსტად დაცვა.
- დასაშვები.
ძლიერად დამცავი
ძლიერი თავდაცვითი ლიცენზიები ყველაზე ხშირად GPL-ის ვარიაციებია. ეს ლიცენზიები აუცილებლად მოითხოვს პროექტის ლიცენზირებას, ისევე როგორც წყაროს კოდების გამჟღავნებას, მიუხედავად იმისა, თუ როგორ იქნება გამოყენებული ან უკვე გამოყენებული ნებისმიერი კოდი ან პროექტი.
სუსტად დაცვა
სუსტი თავდაცვითი ლიცენზიები ყველაზე ხშირად Lesser GPL-ის ვარიაციებია. რაშიც მთავარი განსხვავება დასაშვები ლიცენზიებისგან არის ის, რომ უბრალოდ აუცილებელია პროგრამის ლიცენზირება GPL ლიცენზიით, ასევე წყაროს კოდების უშეცდომოდ მიწოდება. უფრო მეტიც, თუ პროგრამისტის პროექტი შეიცავს ბიბლიოთეკას, ანუ სტატიკურ კავშირს ან დინამიურ კავშირს LGPL ლიცენზიით, მაშინ ის ასევე თავსებადია პროგრამისტის ნებისმიერი პროექტის ლიცენზიასთან.
სადაც მითითებულია GitHub-ზე ლიცენზიის ტიპი [/ წარწერა]
დასაშვები
არსებობს ნებადართული ლიცენზიების დიდი რაოდენობა, მათ შორის ყველაზე პოპულარული ლიცენზიებია MIT, Apache 2.0 და BSD. მცირე ვარიაციებით, ამ ლიცენზიებს აქვთ შესაძლებლობა დაუშვან კოდის გამოყენება როგორც ღია კოდის პროექტებში, ასევე კომერციული მიზნებისთვის და პროექტებისთვის. მაგრამ, ამ შემთხვევაში, მნიშვნელოვანია გვახსოვდეს, რომ აუცილებელია ორიგინალური პროგრამის ავტორის მითითება.
სხვა პოპულარული GitHub ლიცენზიები
ლიცენზიების ამ სამი ჯგუფის გარდა, არის სხვა, მაგალითად, კიდევ ერთი ყველაზე სასარგებლო ლიცენზია არის GPLv2 classpath გაფართოებებით. ეს ლიცენზია ასევე შეიძლება გამოყენებულ იქნას როგორც ღია კოდის პროექტებში, ასევე კომერციულ პროექტებსა და მიზნებში. მისი ყველაზე პოპულარული გარეგნობა არის Oracle-ში, ეს კომპანია იყენებს GPLv2-ს classpath გაფართოებებით, რათა ლიცენზირდეს თავისი ღია კოდის პროექტები და გადაწყვეტილებები. ეს ლიცენზია საკმაოდ მნიშვნელოვანი და სასარგებლოა, რადგან ჩვეულებრივი GPL ლიცენზიები, მაგალითად, ვერასოდეს ამუშავებენ ბაიტეკოდს. ანუ მათ აქვთ შედგენისა და დაკავშირების პროცესის სპეციალური აღწერა, რაც სრულიად შეუსაბამოა სხვა ინტერპრეტირებული პროგრამირების ენებისთვის, ასეთ ენებში შედის ყველაზე პოპულარული Java ენა.სწორედ ასეთი შემთხვევებისთვის გამოიცა სპეციალური GPLv2 ლიცენზია classpath გაფართოებით. ყოველივე ამის შემდეგ, ძალიან ნათლად და ნათლად ნათქვამია, რომ ბიბლიოთეკა, რომელიც გამოვიდა ამ ლიცენზიით, შეიძლება გამოყენებულ იქნას კომერციულ პროექტებში და მიზნებში აბსოლუტურად ნებისმიერი სხვა ლიცენზიით.
კიდევ რა უნდა იცოდეთ
GitHub ლიცენზიების შესახებ .
ლიცენზიის დამატება
საბოლოო ლიცენზიის საბოლოოდ შერჩევის შემდეგ, რჩება მხოლოდ მისი დამატება პროექტის root-ში. ამ მოქმედების შესასრულებლად, თქვენ უნდა დაამატოთ არჩეული ლიცენზია პროექტის root ქვეშ თავად პროექტის შექმნისას, ან ზოგადად ნებისმიერ სხვა დროს. მაგრამ ამ ქმედებაშიც კი GitHub-ის ვებ სერვისმა მოახერხა მომხმარებლებზე ზრუნვა და მათ საკმაოდ მოსახერხებელი გზა გააკეთეს საბოლოო ლიცენზიის დასამატებლად თვით პროექტის დასაწყისშიც კი.
თუმცა, სამწუხაროდ, ეს ყველაფერი არ არის, რადგან დეველოპერმა ან პროგრამისტმა უნდა შეამოწმოს აბსოლუტურად ყველა დამოკიდებულება, რომელიც გამოიყენებოდა მის იდეაში ან პროექტში. ანუ, თუნდაც ერთ-ერთი დამოკიდებულების გამოშვება GPL ლიცენზიით, მაშინ აბსოლუტურად მთელი დეველოპერის პროექტი უნდა იყოს GPL თავსებადი. ასეთი გადამოწმებისთვის, ჩვეულებრივ, გამოიყენება ადრე შექმნილი პროგრამები ან ინსტრუმენტები. მაგალითად, ამისთვის არის ინსტრუმენტი https://github.com/pivotal/LicenseFinder:
შეიძლება ითქვას, რომ ლიცენზირება საკმაოდ შრომატევადი ამოცანაა, მაგრამ ამავდროულად აუცილებელი მოქმედება პროექტის ან პროგრამისტის ნებისმიერი იდეის სიცოცხლისთვის. სწორი ლიცენზიის ასარჩევად, სამწუხაროდ, დიდი დრო უნდა დახარჯო, თუმცა, ამად ღირს, რომ პროექტი წარმატებული იყოს. უმჯობესია, პროგრამის დაწერისას პირველ რიგში დააყენოთ ლიცენზიის არჩევანი, რადგან თავიდანვე ამის გაკეთების შემდეგ, შეგიძლიათ მთელი თქვენი ძალისხმევა სწორი მიმართულებით მიმართოთ და დაწეროთ პროგრამა, რომელიც წარმატებული და მოსახერხებელი იქნება უმეტესობისთვის. მომხმარებლები.