ტექნოლოგიურ პროდუქტს შეიძლება უკავშირდებოდეს სამართლებრივი ვალდებულება, რომლის შესახებაც კომპანიის კომერციულ გუნდს წარმოდგენაც არ ჰქონდეს. ასეთი ვალდებულება შესაძლოა პროგრამის შემუშავებისას მიღებული ჩვეულებრივი გადაწყვეტილების შედეგად წარმოიშვას: დეველოპერი სამუშაოს ხანგრძლივობის ერთი კვირით შესამცირებლად პროექტს უფასო ბიბლიოთეკას ამატებს. ბიბლიოთეკა გამოქვეყნებულია ისეთი ლიცენზიით, როგორიცაა GNU-ს გენერალური საჯარო ლიცენზიის მე-2 ვერსია (GPL-2.0). პროდუქტი ბაზარზე გამოდის. წლების შემდეგ, ტექნიკური შემოწმებისას (due diligence), მომხმარებელთან დავისას ან უფლებამფლობელისგან წერილის მიღებისას, კომპანია აღმოაჩენს, რომ ამ გადაწყვეტილებით მიღებულ სარგებელს თან ახლდა ლიცენზიით განსაზღვრული პირობები, რომელთა დარღვევაც პროდუქტის პირველივე გამოშვებიდან გრძელდება.
წინამდებარე სტატიაში განხილულია ამ პირობების შინაარსი, მიზეზები, რომელთა გამოც Cisco-სა და Linksys-ის შემთხვევა ამ საკითხზე ყველაზე ცნობილ გამაფრთხილებელ მაგალითად რჩება, სასამართლოების მიერ ამ ლიცენზიების შეფასება უახლეს პრაქტიკაში და იმ კომპანიისთვის საჭირო მოქმედებები, რომელიც პროგრამულ პროდუქტს ქმნის ან იძენს.
რას წარმოადგენს ღია კოდი:
პროგრამა ორი ნაწილისგან შედგება: საწყისი კოდი (რასაც დეველოპერი წერს) და მზა პროგრამა(რასაც მომხმარებელი იყენებს). ღია კოდის შემთხვევაში ავტორი საწყის კოდს ყველას უზიარებს და ნებას რთავს, გამოიყენონ, შეცვალონ და გაავრცელონ. ეს ნებართვა ლიცენზიაშია ჩაწერილი და ყოველთვის პირობებით მოდის.
სამი შეცდომა, რაც ხშირად ხდება:
„ღია კოდი = ყველას შეუძლია რაც უნდა, ის გააკეთოს“. არა. პროგრამა საავტორო უფლებით დაცულია და ლიცენზიის პირობების დარღვევისას ნებართვაც ქრება.
„უფასოა, ესე იგი უპირობოა“. ღირებულების გადახდის ვალდებულება მასზე არ ვრცელდება, მაგრამ გამოყენების კონკრეტული პირობები გააჩნია.
„ყველა ღია კოდი ერთნაირია“. არა. ლიცენზიები ძალიან განსხვავდება და სწორედ ეს განსხვავება წყვეტს, რამდენად სარისკოა კომპონენტი.
2. „უფასო“ არ ნიშნავს „უპირობოს“
ღია კოდის პროგრამული უზრუნველყოფა, როგორც წესი, უსასყიდლოა, თუმცა მისი გამოყენება სამართლებრივი პირობების დაცვას მოითხოვს. ასეთი პროგრამა კვლავ საავტორო უფლებით არის დაცული, ხოლო ლიცენზია ერთადერთი საფუძველია, რომელიც მესამე პირს მისი კოპირების, შეცვლისა თუ გავრცელების უფლებას ანიჭებს. თუ ლიცენზიის პირობები დაცული არ არის, ნებართვაც აღარ არსებობს და პროგრამის გამოყენება საავტორო უფლების დარღვევად იქცევა. ქართული სამართალიც იმავე მიდგომას ეფუძნება: „საავტორო და მომიჯნავე უფლებების შესახებ“ საქართველოს კანონის მე-6 მუხლის პირველი პუნქტის „ა“ ქვეპუნქტის თანახმად, კომპიუტერული პროგრამა ლიტერატურულ ნაწარმოებად მიიჩნევა, ხოლო მე-19 მუხლის თანახმად, ავტორს აქვს მისი რეპროდუცირებისა და ადაპტირების ნებართვის გაცემის ან აკრძალვის განსაკუთრებული უფლება. კანონში არ არსებობს დებულება, რომლის თანახმადაც პროგრამა დაცვას დაკარგავდა მხოლოდ იმის გამო, რომ ავტორმა იგი ღიად გამოაქვეყნა.
GPL „კოპილეფტის“ (copyleft) ტიპის ლიცენზიაა. მისი ძირითადი წესი GPL-2.0-ის მე-2 განყოფილების „ბ“ პუნქტშია ასახული: ნებისმიერი ნაწარმოები, რომელიც ვრცელდება და მთლიანად ან ნაწილობრივ შეიცავს პროგრამას ან მისგან მომდინარეობს, მესამე პირებს მთლიანად, უსასყიდლოდ და იმავე ლიცენზიით უნდა გადაეცეს. მე-3 განყოფილება დამატებით პრაქტიკულ ვალდებულებას ადგენს: პროგრამას შესრულებადი ფორმით გავრცელებისას თან უნდა ახლდეს სრული შესაბამისი საწყისი კოდი ან მისი მიწოდების წერილობითი შეთავაზება, რომელიც სულ მცირე სამი წლის განმავლობაში მოქმედებს.
მარტივად რომ ვთქვათ, თუ კომპანიის პროდუქტში GPL-ით ლიცენზირებული კოდია ჩაშენებული და კომპანია პროდუქტს ავრცელებს, მას შესაძლოა დაეკისროს მომხმარებლებისთვის არა მხოლოდ გამოყენებული კომპონენტის, არამედ საკუთარი პროდუქტის საწყისი კოდის გადაცემის ვალდებულებაც.
ორი გარემოება ხშირად არასწორად არის გაგებული. პირველი: ვალდებულება წარმოიშობა გავრცელებისას და არა გამოყენებისას. ლიცენზიის ტექსტში პირდაპირ არის მითითებული, რომ პროგრამის გაშვება შეზღუდული არ არის. მეორე: სანქცია მკაცრია. მე-4 განყოფილების მიხედვით, პროგრამის კოპირების, შეცვლის, ქველიცენზირების ან გავრცელების ნებისმიერი მცდელობა, რომელიც ლიცენზიით დაშვებულ ფარგლებს სცდება, ბათილია და ავტომატურად იწვევს ლიცენზიით მინიჭებული უფლებების შეწყვეტას. ამგვარად, დამრღვევი კომპანია არა მხოლოდ ხელშეკრულების პირობას არღვევს, არამედ ისეთ პროგრამასაც ავრცელებს, რომლის გავრცელების ლიცენზიაც აღარ აქვს.
3. Cisco-სა და Linksys-ის ქეისი
2003 წლის მარტში Cisco შეთანხმდა საშინაო ქსელური მოწყობილობების ბაზრის ლიდერის, Linksys-ის, შეძენაზე 500 მილიონი აშშ დოლარის ღირებულების აქციების სანაცვლოდ. Linksys-ის ყველაზე გაყიდვადი როუტერი WRT54G Linux-ზე დაფუძნებულ პროგრამულ უზრუნველყოფას იყენებდა. რამდენიმე თვეში Linux-ის ბირთვის დეველოპერთა ელექტრონულ სადისკუსიო ჯგუფში (mailing list) აღინიშნა, რომ Linksys GPL-ით მოთხოვნილ საწყის კოდს არ აწვდიდა მომხმარებლებს. საკითხის განხილვაში თავისუფალი პროგრამული უზრუნველყოფის ფონდიც (Free Software Foundation, FSF) ჩაერთო. Linksys-მა პროგრამული უზრუნველყოფის საწყისი კოდი 2003 წლის ზაფხულში გამოაქვეყნა. ეს ეპიზოდი დღეს იმის მაგალითად განიხილება, თუ რატომ უნდა მოიცავდეს ტექნიკური ჯეროვანი შემოწმება თავად კოდსაც: ხარვეზი გარიგების დასრულების შემდეგ გამოვლინდა.
არასწორი იქნებოდა ამ შემთხვევის უბრალო დაუდევრობად შეფასება. ღია კოდის სამართლის წამყვანმა სპეციალისტმა, ჰეზერ მიკერმა, იმხანად აღნიშნა, რომ Cisco-ს „ჯეროვანი შემოწმება პროდუქტის ინტეგრაციის სამ დონეზე მოუწევდა ჩაეტარებინა“: Linksys ჩიპსეტებს Broadcom-ისგან ყიდულობდა, Broadcom-მა კი პროგრამული უზრუნველყოფის შემუშავება უცხოელ დეველოპერს მიანდო. პრობლემა მიწოდების ჯაჭვში წარმოიშვა და სწორედ ამიტომ არის მისი გამოვლენა რთული.
საქმე 2003 წლით არ დასრულებულა. 2008 წლის დეკემბერში FSF-მა Cisco-ს სარჩელი შიეტანა Linksys-ის იმ პროდუქტების გამო, რომლებიც FSF-ის კუთვნილ პროგრამებს შეიცავდა, ხოლო 2009 წლის მაისში დავა მორიგებით დასრულდა. მორიგების პირობების თანახმად, Cisco-მ Linksys-ში დანიშნა თავისუფალი პროგრამული უზრუნველყოფის დირექტორი ლიცენზიის პირობების დაცვაზე ზედამხედველობისთვის. კომპანიამ ასევე იკისრა ვალდებულება, პროდუქტის ადრინდელი მიმღებებისთვის ეცნობებინა GPL-ით მინიჭებული უფლებების შესახებ, უზრუნველეყო საწყისი კოდის ხელმისაწვდომობა და FSF-ისთვის გადაეხადა დაუზუსტებელი ოდენობის თანხა. იურისტებისთვის საგულისხმოა, რომ მორიგების შედეგი უპირატესად დარღვეული მდგომარეობის აღდგენასა და რეპუტაციას უკავშირდებოდა და არა ზიანის ერთჯერადად, დიდი ოდენობით ანაზღაურებას. ამასთან, მორიგება უვადო ვალდებულებებს ითვალისწინებდა და შემძენს ლიცენზიის პირობების დაცვის თანმიმდევრული პროგრამის დანერგვას ავალდებულებდა.
დეველოპერთან ან აუთსორსინგის კომპანიასთან ხელშეკრულების გაფორმებისას ღია კოდის გამოყენების წესები წინასწარ და ცალსახად უნდა განისაზღვროს, რადგან პრობლემა, როგორც წესი, სწორედ დეველოპმენტის ეტაპზე წარმოიშობა: დეველოპერი ბიბლიოთეკას ირჩევს, კომპანიის იურისტი კი ამ არჩევანის შესახებ ხშირად მხოლოდ პროდუქტის გამოშვების შემდეგ იგებს. აქ საკითხის ზუსტად ფორმულირებაა მნიშვნელოვანი: ღია კოდის გამოყენება თავისთავად კოდს საჯაროს არ ხდის. GPL-ის ვალდებულებები წარმოიშობა პროგრამის გავრცელებისას და არა გამოყენებისას.
ხოლო ლიბერალური ლიცენზიები, მაგალითად MIT, საკუთარი კოდის გახსნას საერთოდ არ მოითხოვს. თუმცა კოპილეფტის ტიპის ლიცენზიის კომპონენტის ჩაშენებული პროდუქტის გავრცელებისას კომპანიას შეიძლება მოეთხოვოს საკუთარი პროდუქტის საწყისი კოდის მიმღებისთვის გადაცემა, ხოლო მიმღებს ამ კოდის შემდგომი გავრცელების უფლება აქვს. ამიტომ ხელშეკრულება უნდა მიმართავდეს არა ზოგადად „ღია კოდს“, არამედ კონკრეტულად იმ ლიცენზიებს, რომლებიც თქვენი პროდუქტის გავრცელების მოდელისთვის საფრთხეს წარმოადგენს.
პრაქტიკაში ხელშეკრულება სამ ძირითად პირობას უნდა ითვალისწინებდეს. პირველი, დეველოპერს უნდა ეკრძალებოდეს GPL-ის, LGPL-ის, AGPL-ის ან მსგავსი კოპილეფტის ლიცენზიით გავრცელებული კოდის გამოყენება შემკვეთის წერილობითი თანხმობის გარეშე. წინასწარი თანხმობის მოთხოვნა უნდა ვრცელდებოდეს ნებისმიერი უცნობი ან არასტანდარტული ლიცენზიით გავრცელებული კოდის გამოყენებაზეც.
მეორე, დეველოპერს უნდა ევალებოდეს შემკვეთისთვის გამოყენებული ღია კოდის ყველა კომპონენტის სრული ჩამონათვალის გადაცემა, თითოეული მათგანის ვერსიისა და ლიცენზიის მითითებით. ეს ჩამონათვალი პროდუქტის მიღება-ჩაბარების დოკუმენტის ნაწილი უნდა იყოს. აღნიშნული მოთხოვნა განსაკუთრებით მნიშვნელოვანია, რადგან ღია კოდის კომპონენტები, რომლებსაც დეველოპერი ავტომატურად ან სხვა კომპონენტებზე დამოკიდებულების გამო ამატებს, ტრადიციული შემოწმებისას ხშირად შეუმჩნეველი რჩება. Black Duck-ის 2026 წლის ანგარიშის მიხედვით, ღია კოდის კომპონენტების 17% კოდის ბაზაში სტანდარტული პაკეტების მენეჯერების გამოყენების გარეშე ხვდება, მათ შორის კოპირებული ფრაგმენტებისა და ხელოვნური ინტელექტის მიერ გენერირებული კოდის სახით.
მესამე, ხელშეკრულებით უნდა განისაზღვროს ხელოვნური ინტელექტის გამოყენებით შექმნილი კოდის სამართლებრივი რეჟიმიც: დეველოპერმა უნდა გაამჟღავნოს ასეთი ინსტრუმენტების გამოყენება და მიღებული შედეგი იმავე წესით შეამოწმოს, რადგან ინფორმაცია კოდის წარმომავლობისა და შესაბამისი ლიცენზიის შესახებ შესაძლოა დაკარგული იყოს.
ამ პირობების აღსრულებისთვის აუცილებელია შესაბამისი სახელშეკრულებო მექანიზმებიც. დეველოპერმა უნდა დაადასტუროს და გარანტია გასცეს, რომ გადაცემული პროდუქტი არ შეიცავს მიუთითებელ ღია კოდის კომპონენტებს და არ არღვევს მესამე პირთა უფლებებს. დარღვევის შემთხვევაში მას უნდა დაეკისროს შემკვეთისთვის ზიანის ანაზღაურება. შემკვეთს უნდა ჰქონდეს აუდიტისა და საწყისი კოდის სკანირების უფლებაც, როგორც პროდუქტის მიღებისას, ისე მისი გადაცემიდან გარკვეული პერიოდის განმავლობაში.
ეს მიდგომა უშუალოდ გამომდინარეობს Linksys-ის გამოცდილებიდან: პრობლემა მიწოდების ჯაჭვის მესამე და მეოთხე რგოლებშიც შეიძლება წარმოიშვას. ამიტომ სახელშეკრულებო პირობები და გარანტიები მხოლოდ უშუალო კონტრაჰენტით არ უნდა შემოიფარგლებოდეს და დეველოპერის მიერ დაქირავებულ ქვეკონტრაქტორებზეც უნდა ვრცელდებოდეს. ამ დაცვის გარეშე ლიცენზიის დარღვევის შედეგები შემკვეთს ეკისრება მაშინაც კი, როდესაც დარღვევა მისი ნების გარეშე ხდება.
