ღია კოდის პროგრამული უზრუნველყოფის ლიცენზიები ნიდერლანდებისა და ევროკავშირის კანონმდებლობის შესაბამისად

თითქმის ყველა კომერციული პროგრამული პროდუქტი შეიცავს ღია კოდის კომპონენტებს, როგორც წესი, ასობითს, რომლებსაც იურისტების ნაცვლად დეველოპერები ირჩევენ. ეს პრობლემად იქცევა, როდესაც ვერავინ იტყვის, რომელი ლიცენზიები გამოიყენება, რა არის საჭირო და შეესაბამება თუ არა პროდუქტი მოთხოვნებს. ეს სტატია განმარტავს, თუ როგორ მუშაობს ღია კოდის ლიცენზიები ნიდერლანდებისა და ევროკავშირის კანონმდებლობის შესაბამისად, სად დევს რისკი და რა უნდა იყოს გათვალისწინებული.

რა არის ღია კოდის ლიცენზია იურიდიული თვალსაზრისით

ღია კოდის ლიცენზია არის საავტორო უფლებების ლიცენზია, რომელიც გაიცემა პირობებით. ეს არ არის უარის თქმა, არ არის საჯარო დომენისთვის მიძღვნა, არ არის უფლებების მიტოვება და ამ მხრივ ის მუშაობს ისევე, როგორც ნებისმიერი სხვა პროგრამული უზრუნველყოფის ლიცენზია ჰოლანდიური კანონმდებლობის შესაბამისად . ავტორი ინარჩუნებს საავტორო უფლებებს Aw-ის 1-ლი და მე-10 მუხლების შესაბამისად, რომლებიც იცავს კომპიუტერულ პროგრამებს, როგორც ნაწარმოებებს, და ლიცენზია იძლევა ქმედებების ნებართვას, რომლებიც სხვაგვარად დაარღვევდა Aw-ის 12-ე და მე-13 მუხლებით გათვალისწინებულ ექსკლუზიურ უფლებებს.

შედეგი უფრო მნიშვნელოვანია, ვიდრე განმარტება. თუ დაიცავთ ნებართვას, თქვენი კოპირება და გავრცელება კანონიერია. თუ არ დაიცავთ ნებართვას, ნებართვა არ ვრცელდება თქვენს ქმედებებზე: თქვენი გამოყენება საავტორო უფლებების დარღვევაა და არა ხელშეკრულების დარღვევა. საავტორო უფლებების ლიცენზიების უმეტესობა ამას აძლიერებს დარღვევის შემთხვევაში ავტომატურად შეწყვეტით — GPLv2 გამოსწორების პერიოდის გარეშე, ხოლო GPLv3 და AGPLv3 აღადგენს უფლებებს, თუ დარღვევა გამოსწორდება შეტყობინების შემდეგ განსაზღვრული ვადის განმავლობაში.

ნიდერლანდების სასამართლოები ამ მსჯელობას იყენებენ. საქმეში Rb. Amsterdam 2020 წლის 22 სექტემბერს, ECLI:NL:RBAMS:2020:4717, დისტრიბუტორი, რომელმაც ლიცენზიის ტექსტი და საავტორო უფლებების შესახებ შეტყობინება გაყოფილი კოდის ბაზიდან ამოიღო, ნებართვის დაკარგვისა და საავტორო უფლებების დარღვევის ფაქტად იქნა მიჩნეული. ახალი კოდის დიდი რაოდენობით დამატებამ დამოუკიდებელი ნამუშევარი არ შექმნა: ორიგინალი შესამჩნევად რჩებოდა, ამიტომ ვალდებულებებიც მას თან ახლდა.

ორი ოჯახი: პერმისიული და საავტორო უფლებების დამცველი

ნებართვითი ლიცენზიები — MIT, BSD ლიცენზიები, Apache 2.0 — იძლევა გამოყენების, მოდიფიკაციისა და ხელახალი გადანაწილების საშუალებას, მათ შორის დახურული კოდის პროდუქტებში, იმ პირობით, რომ დაიცავთ საავტორო უფლებების შეტყობინებებს და ლიცენზიის ტექსტს.

საავტორო უფლებების ლიცენზიები მოითხოვს, რომ პროგრამული უზრუნველყოფის ან მასზე აგებული რაიმეს გავრცელებისას, ეს ერთი და იგივე ლიცენზიით განახორციელოთ და შესაბამისი წყარო ხელმისაწვდომი გახადოთ. ისინი განსხვავდებიან ხელმისაწვდომობის მიხედვით.

საავტორო უფლებების ტრიგერი და ბმულის კითხვა

საავტორო უფლებების ვალდებულებები გავლენას ახდენს გავრცელებაზე და არა გამოყენებაზე. კომპანია, რომელიც GPL პროგრამულ უზრუნველყოფას შიდა დონეზე იყენებს, რამდენადაც არ უნდა იყოს ის მნიშვნელოვნად მოდიფიცირებული, არაფერს ავრცელებს და არც არაფერს ვალდებულია. „გავავრცელეთ?“ ყოველთვის პირველი კითხვაა და სწორედ ამიტომ არის კონტეინერები, მოწყობილობები, firmware და SDK-ები უფრო მნიშვნელოვანი, ვიდრე შიდა ინსტრუმენტები.

მეორე კითხვა უფრო რთულია. GPL საუბრობს „პროგრამაზე დაფუძნებულ ნაშრომზე“, რაც ამერიკული წარმოებული ნაწარმოების კონცეფციას ნასესხებია. ნიდერლანდების კანონმდებლობაში ასეთი ტერმინი არ არსებობს: ანალიზი მოიცავს რეპროდუცირებისა და ადაპტაციის უფლებებს და სვამს კითხვას, რეპროდუცირებულია თუ არა ორიგინალიდან დაცული გამოთქმა.

პრაქტიკული შემთხვევა ბმულია. ჰოლანდიის სასამართლოს არასდროს გადაუწყვეტია, ქმნის თუ არა საკუთრების მოდულის GPL ბიბლიოთეკასთან ბმული ერთ ნამუშევარს, რომელიც ექვემდებარება საავტორო უფლებების მინიჭებას და არ არსებობს ევროკავშირის სავალდებულო უფლებამოსილება. თავისუფალი პროგრამული უზრუნველყოფის ფონდის მოსაზრება, რომ ბმული ქმნის კომბინირებულ ნამუშევარს, ლიცენზიის მმართველის ინტერპრეტაციაა და არა კანონი, ხოლო საპირისპირო მოსაზრება ასევე შეუმოწმებელია. ინტერნეტის საყვარელ პასუხს - დინამიური ბმული უსაფრთხოა, სტატიკური - არა - არ აქვს საფუძველი ჰოლანდიის საავტორო უფლებების კანონმდებლობაში, რომელიც არ სვამს კითხვას, თუ როგორ იქცევა კომპილატორი. უფრო დასაბუთებული ანალიზი სვამს კითხვას, თუ რამდენად მჭიდროდ არის კომპონენტები გაერთიანებული: იზიარებენ თუ არა ისინი მისამართების სივრცეს და მონაცემთა სტრუქტურებს, არის თუ არა კომბინაცია ერთი პროდუქტის სახით, შეუძლია თუ არა ცალკე ფუნქციონირება, ახდენს თუ არა საკუთრების მხარე სათაურების, მაკროების ან ჩასმული კოდის რეპროდუცირებას საავტორო უფლებების მინიჭების მხრიდან? ეს კითხვები, როგორც წესი, წყვეტს რისკს. თუ ისინი არ ქმნიან პრობლემას, კომპონენტი იზოლირებულია პროცესის საზღვრის მიღმა, იცვლება იგი ან იღება კომერციული ლიცენზია.

AGPL და ქსელის გამოყენება

AGPL არსებობს იმიტომ, რომ საავტორო უფლებები დისტრიბუციის შედეგად ირთვება და SaaS პროვაიდერები არ ავრცელებენ. მისი ქსელური პუნქტი მოითხოვს, რომ თუ თქვენ პროგრამულ უზრუნველყოფას შეცვლით და მას დისტანციურად ურთიერთქმედების მქონე მომხმარებლებისთვის ხელმისაწვდომს გახდით, მათ შესთავაზოთ თქვენი შეცვლილი ვერსიის შესაბამისი წყარო.

ხშირად სამი პუნქტი გამოტოვებულია. ვალდებულება სერვისის მომხმარებლებს ეკისრებათ, რაც ღია რეგისტრაციის პროდუქტში დიდად არ არის კომფორტული. ის მოდიფიკაციით აქტიურდება, ამიტომ შეუცვლელი კომპონენტი მას არ ჩართავს, მაგრამ პატჩირებული ვერსია შეიძლება ჩაერთოს. და ეს იგივე კომბინირებულ სამუშაო კითხვას ბადებს, რასაც GPL თქვენი სტეკის დანარჩენი ნაწილისთვის - სწორედ ამიტომ კრძალავს ბევრი კომპანია AGPL-ს საწარმოო კოდში.

ლიცენზიის თავსებადობა

თავსებადობა არის კომპონენტების გაერთიანების პრობლემა, რომელთა ლიცენზიებიც აკისრებს ვალდებულებებს, რომელთა ორივეს შესრულება ერთ დისტრიბუციაში შეუძლებელია: ნებართვის ლიცენზიები თავსებადია თითქმის ყველაფერთან, საავტორო უფლებების ლიცენზიები კი მხოლოდ იმასთან, რასაც მათივე პირობები იძლევა. სტანდარტული შემთხვევაა Apache 2.0 და GPLv2. Apache Software Foundation და Free Software Foundation თანხმდებიან, რომ კომბინაცია დაუშვებელია, რადგან Apache 2.0-ის პატენტის შეწყვეტისა და ანაზღაურების დებულებები დამატებითი შეზღუდვებია, რომლებსაც GPLv2 არ იძლევა. GPLv3 შეიქმნა მათ მისაღებად. თავსებადობა ასევე მიმართულების მატარებელია: Apache კოდი შეიძლება ინტეგრირებული იყოს GPLv3 პროექტში, მაგრამ არა პირიქით. ერთი GPL კომპონენტი არასწორ ადგილას შეიძლება აიძულოს არჩევანი გააკეთოს ხელახალ ლიცენზირებას, რეინჟინერიას ან ამოღებას შორის - გაცილებით იაფია გამოშვებამდე, ვიდრე გამოშვების შემდეგ.

ატრიბუციისა და შეტყობინების ვალდებულებები

ყველაზე ხშირად დარღვევილი ვალდებულებები ყველაზე ნაკლებად დრამატულია: საავტორო უფლებების შეტყობინებების, ლიცენზიის ტექსტების, პასუხისმგებლობის შეზღუდვის განცხადებების და, Apache 2.0-ის მიხედვით, დისტრიბუციასთან დაკავშირებულ მასალებში NOTICE შინაარსის რეპროდუცირება. ყველა ოჯახი აკისრებს მათ, მათ შორის MIT-სა და BSD-ს. ისინი ირღვევა, რადგან არავის ეკუთვნის და მათი გამოსწორება ყველაზე მარტივია — როგორც წესი, პროდუქტთან ერთად გამოგზავნილი გენერირებული ატრიბუციის ფაილის მეშვეობით. ზემოთ მოყვანილი ჰოლანდიური საქმე სწორედ ამ წარუმატებლობას ეფუძნება.

პატენტის მინიჭება და პატენტის შურისძიება

MIT-ი და BSD არაფერს ამბობენ პატენტებზე და შეიძლება თუ არა პატენტის ლიცენზიის ირიბი გამოყენება, გაურკვეველია. Apache 2.0-მა დაამატა თითოეული კონტრიბუტორისგან ექსპრეს, ჰონორარის გარეშე პატენტის ლიცენზია, რომელსაც თან ახლავს საპასუხო პუნქტი: დაიწყეთ საპატენტო სასამართლო დავა იმის მტკიცებით, რომ ნამუშევარი არღვევს თქვენს უფლებებს და თქვენი პატენტის ლიცენზია შეწყდება. GPLv3 შეიცავს შესადარებელ გრანტს და საკუთარ პატენტის დებულებებს.

ორი შედეგი პატენტების პორტფელის მქონე კომპანიებისთვის. თუ თქვენი ინჟინრები მონაწილეობენ Apache-ის ან GPLv3-ლიცენზირებულ პროექტებში, თქვენ ლიცენზიებს გასცემთ თქვენივე პატენტებით. და თუ ოდესმე პატენტებს მოითხოვთ კომპანიის წინააღმდეგ, რომელიც დამოკიდებულია იმავე Apache-ლიცენზირებულ კომპონენტებზე, რომლებსაც იყენებთ, შურისძიებამ შეიძლება ლიცენზიის დაკარგვა დაგიჯდეთ.

EUPL და ნიდერლანდების საჯარო სექტორი

ევროკავშირის საჯარო ლიცენზიის ვერსია 1.2, რომელიც ევროკომისიამ 2017 წლის მაისში განმახორციელებელი გადაწყვეტილებით დაამტკიცა, არის OSI-ს მიერ დამტკიცებული საავტორო უფლებების ლიცენზია სამი განმასხვავებელი მახასიათებლით.

• Ენა. ის არსებობს ევროკავშირის ოფიციალურ ენებზე, ყველა დამტკიცებულ ვერსიას იდენტური ღირებულება აქვს, ამიტომ ნიდერლანდების ხელისუფლებას შეუძლია ხელშეკრულების დადება ნიდერლანდურ ენაზე.
• თავსებადობა დანართში ჩამოთვლილია თავსებადი ლიცენზიები — მათ შორის GPLv2 და v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL და CeCILL — და ამის ნაცვლად, ამ ლიცენზიით გავრცელების საშუალებას იძლევა წარმოებული ნაშრომი, რომელიც აერთიანებს EUPL კოდს ჩამოთვლილი ლიცენზიით გათვალისწინებულ კოდთან.
• მიღწევა. გავრცელების მისი განმარტება მოიცავს ნამუშევრის ონლაინ ან ოფლაინ ხელმისაწვდომობას. ან მის ძირითად ფუნქციებზე წვდომის უზრუნველყოფადა EUPL-ის მე-5 მუხლი საავტორო უფლებების ვალდებულებას დისტანციურ ურთიერთქმედებამდეც ახდენს, რომლის დროსაც იგივე ფუნქციონალია შემოთავაზებული. ამრიგად, ის სერვისის სახით მიწოდებულ პროგრამულ უზრუნველყოფას აღწევს ისე, როგორც GPL არ აკეთებს ამას.

ნიდერლანდების საჯარო სექტორის მომხმარებელს შეიძლება EUPL დასჭირდეს პოლიტიკის და არა კანონის თვალსაზრისით. „ურთიერთთავსებადი ევროპის შესახებ“ კანონი, რეგულაცია (EU) 2024/903, ავალებს საჯარო სექტორის ორგანოებს, პრიორიტეტი მიანიჭონ ურთიერთქმედების გადაწყვეტილებებს შემზღუდავი ლიცენზირების პირობების გარეშე, როგორიცაა ღია კოდი, სადაც ეს ექვივალენტურია; ეროვნულ დონეზე, ღია კოდის პრინციპი ეფუძნება კაბინეტის გადაწყვეტილებებსა და პოლიტიკის ხაზებს და არა კანონს: ციფრული იდენტობის ინფრასტრუქტურა ხელს უწყობს, მაგრამ არ აკისრებს აღსრულებად ვალდებულებას ყველა საწყისი კოდის გამოქვეყნების შესახებ. წაიკითხეთ სატენდერო დოკუმენტები: EUPL მოთხოვნა ავალდებულებს თქვენს მიერ მიწოდებულ პროდუქტს და შეიძლება შეუთავსებელი იყოს იმ საკუთრების კოდთან, რომლის ხელახლა გამოყენებასაც აპირებდით.

აღსრულება პრაქტიკაში

ვის შეუძლია სარჩელის შეტანა. საავტორო უფლებების მფლობელი — ინდივიდუალური კონტრიბუტორები, ან ფონდი ან კომპანია, რომელსაც აქვს მინიჭებული საავტორო უფლებები. ფრაგმენტული ავტორობა პრაქტიკული მუხრუჭია: მოსარჩელემ უნდა დაამტკიცოს სადავო კოდის საკუთრება. ამან დაამარცხა ყველაზე ცნობილი ევროპული GPL საქმე, სადაც ბირთვის დეველოპერის სარჩელი ვირტუალიზაციის მომწოდებლის წინააღმდეგ ავტორობის დამადასტურებელი საბუთების არარსებობის გამო ჩაიშალა (LG Hamburg 2016 წლის 8 ივლისი, 310 O 89/15; დაკმაყოფილდა OLG Hamburg 2019 წლის 28 თებერვალი, 5 U 146/16).

რას ადგენს სასამართლო პრაქტიკა. გერმანიის სასამართლოებმა არაერთხელ აღიარეს, რომ ღია კოდის ლიცენზიები ვალიდურია და რომ დარღვევა დისტრიბუციას უკანონოს ხდის, დაწყებული GPL-ის პირველი აკრძალვით (LG München I 19 მაისი 2004, 21 O 6123/04). აშშ-ის ფედერალური საოლქო სასამართლო იმავე დასკვნამდე მივიდა Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008) საქმეში: ლიცენზიის პირობები წარმოადგენს გრანტის ფარგლებს და არა მხოლოდ შეთანხმებებს, ამიტომ დარღვევა საავტორო უფლებების დარღვევის სარჩელს და აკრძალვის ზომებს უჭერს მხარს. აშშ-ის სასამართლო დავა იკვლევს, შეუძლია თუ არა მიმღებს GPL-ის აღსრულება, როგორც მესამე მხარის ბენეფიციარს. ეს არის ცენტრალური კითხვა კალიფორნიის უზენაეს სასამართლოში Software Freedom Conservancy v Vizio-ს საქმეში: შეუძლიათ თუ არა მომხმარებლებს, როგორც მესამე მხარის ბენეფიციარებს, მოითხოვონ საწყისი კოდის გაცემა GPLv2-ის შესაბამისად. 2025 წლის 23 დეკემბერს სასამართლომ შემაჯამებელ გადაწყვეტილებასთან დაკავშირებით ერთი საკითხის გადაწყვეტა გადაწყვიტა და დაადგინა, რომ GPLv2 და LGPLv2.1 მოითხოვს წყაროს, რომლის მოპოვება და გადამუშავება შესაძლებელია სხვაგან გამოსაყენებლად და არა წყაროს, რომლის ხელახლა ინსტალაცია შესაძლებელია მოწყობილობაზე მისი ფუნქციონალურობის შენარჩუნებით. მესამე მხარის ბენეფიციარის საკითხი თავად სასამართლო პროცესზე დარჩა, რომელიც არაერთხელ გადაიდო. ნებისმიერ შემთხვევაში, ეს კალიფორნიის სახელშეკრულებო სამართლის საკითხია, ამიტომ ის ნიდერლანდებში არაფერს ავალდებულებს; რაც ეს შეცვლიდა, არის საჩივრის შეტანის შესაძლებლობის მქონე პირთა რაოდენობა.

როგორ მიუდგებოდა ამას ნიდერლანდების სასამართლო. საავტორო უფლებების დარღვევა „ავტორთა შესახებ“ კანონის თანახმად: მოსარჩელე ამტკიცებს საკუთრებას და რეპროდუცირებას ან გადაცემას; მოპასუხე წამოჭრის ლიცენზიას; მოსარჩელე პასუხობს, რომ მისი პირობები არ იყო დაკმაყოფილებული, ამიტომ დაცვა წარუმატებელია. BW მუხლის 6:265-ის შესაბამისად, სახელშეკრულებო საშუალებები პარალელურად მიმდინარეობს, მაგრამ საავტორო უფლებები უფრო ძლიერი გზაა.

საშუალებები. აკრძალვა BW მუხლის 3:296-ის შესაბამისად, როგორც წესი, ჯარიმის გადახდით და ხელმისაწვდომია შემაჯამებელი სამართალწარმოების დროს; ზიანის ანაზღაურება კანონის 27-ე მუხლის შესაბამისად და მოგების ანგარიში კანონის 27ა მუხლის შესაბამისად; უკან გამოწვევა, გადაცემა ან განადგურება კანონის 28-ე მუხლის შესაბამისად; და გონივრული და პროპორციული სასამართლო ხარჯების სრული ანაზღაურება კანონის 1019h მუხლის შესაბამისად. იმ შემთხვევებში, როდესაც პროგრამული უზრუნველყოფა უფასოდ ვრცელდებოდა, ზარალის რაოდენობრივი შეფასება რთულია და გერმანიის სააპელაციო სასამართლომ უარი თქვა ზიანის ანაზღაურების მინიჭებაზე, თუმცა ძალაში დატოვა აკრძალვა (OLG Hamm 13 ივნისი 2017, 4 U 72/16). რაც კბენს, იშვიათად არის ზიანი: ეს არის აკრძალვა, უკან გამოწვევა, ხარჯების შესახებ გადაწყვეტილება და წყაროს გამოქვეყნების აუცილებლობა, რომლის გამოქვეყნებაც არასდროს გქონიათ განზრახული.

როდესაც აღმოაჩენთ შესაბამისობის პრობლემას

აღმოჩენა, როგორც წესი, ხდება მომხმარებლის უსაფრთხოების კითხვარის, სათანადო შემოწმების დროს სკანირების ან საავტორო უფლებების მფლობელის წერილის საფუძველზე. შემდეგ გამოსწორება შემდეგნაირად ხორციელდება: შეაჩერეთ დაზარალებული ვერსიის გავრცელება, თუ ზემოქმედება სერიოზულია. დაადგინეთ რომელი კომპონენტი, რომელი ვერსია, რომელი ლიცენზია, რომელი პროდუქტები და გამოშვებები, რა პერიოდის განმავლობაში. გაარკვიეთ, თუ რას მოითხოვს ლიცენზია სინამდვილეში - ხშირად ატრიბუციის ფაილი წყაროს გამოშვების ნაცვლად. მოამზადეთ არტეფაქტები: შეტყობინებები, ლიცენზიის ტექსტები, სრული შესაბამისი წყარო, მათ შორის ვერსიის სკრიპტები და წერილობითი შეთავაზება, სადაც გამოყენებულია. გააგზავნეთ შესაბამისი გამოშვება, შემდეგ კი უთხარით საავტორო უფლებების მფლობელს, რა გააკეთეთ, იმის ნაცვლად, რომ იკამათოთ იმაზე, დაგჭირდათ თუ არა ამის გაკეთება.

GPLv3-ისა და AGPLv3-ის მიხედვით, გამოსწორების ფანჯარა სიჩქარეს იურიდიულ ღირებულებას ანიჭებს; GPLv2-ის მიხედვით, გამოსწორების უფლება არ არსებობს, რის გამოც აღსრულების უმეტესობა მოლაპარაკებით დადებული შესაბამისობის ვალდებულებით მთავრდება. ასევე გაითვალისწინეთ, რომ პრივილეგია ენიჭება თქვენი ადვოკატის რჩევას და არა შიდა საინჟინრო ანგარიშს.

ღია კოდი შერწყმებსა და შესყიდვებში და სათანადო შემოწმებაში

პროგრამული უზრუნველყოფის შეძენისას, ღია კოდი წარმოადგენს სტანდარტულ სამუშაო ნაკადს, ხოლო ძირითად პროდუქტში გამოუცხადებელი საავტორო უფლებების კომპონენტი ერთ-ერთია იმ მცირერიცხოვან აღმოჩენებს შორის, რომელიც ნამდვილად გადამწყვეტ როლს თამაშობს გარიგებაში: თუ პროდუქტის გავრცელება შეუძლებელია მისი წყაროს გამჟღავნების გარეშე, მყიდველი იძენს ფასისგან განსხვავებულ აქტივს.

ველით კოდის ბაზის სკანირებას, კომპონენტების ინვენტარს ლიცენზიებით და კითხვებს კონტრიბუტორებისა და კონტრაქტორების შეთანხმებებთან დაკავშირებით. ტიპიური შედეგებია კონკრეტული კომპენსაცია, შეკავება გამოსწორებამდე, წინაპირობა, რომელიც მოითხოვს მოხსნას ან ღია კოდის გარანტია. გამყიდველებმა ჯერ უნდა დაასკანირონ: თქვენს მიერ გამჟღავნებული დასკვნები მოლაპარაკებაა, მყიდველის მრჩევლის მიერ გაკეთებული დასკვნები კი - ბერკეტი. მყიდველებმა უნდა მოძებნონ არა „კომპანია ფლობს თავის ინტელექტუალურ საკუთრებას“, არამედ განცხადება, რომ არცერთი პროდუქტი არ შეიცავს ღია კოდის შემცველობას, რომელიც მოითხოვს საკუთრების კოდის გამჟღავნებას.

მასალების ჩამონათვალი, სკანირება და კიბერმდგრადობის შესახებ კანონი

პროგრამული უზრუნველყოფის მასალების სია პროდუქტის კომპონენტების ინვენტარიზაციაა ვერსიებითა და ლიცენზიებით. ცოტა ხნის წინ ის მხოლოდ სახელშეკრულებო ხასიათისა იყო, ახლა კი მარეგულირებელიც.

კიბერმდგრადობის შესახებ კანონი, რეგულაცია (EU) 2024/2847, ძალაში შევიდა 2024 წლის 10 დეკემბერს და თანდათანობით ამოქმედდება. ის ნიდერლანდების კიბერუსაფრთხოების შესახებ კანონთან ერთად მუშაობს, რომელიც ორგანიზაციას ეხება და არა პროდუქტს. CRA-ს მე-14 მუხლში აქტიურად გამოყენებული დაუცველობებისა და სერიოზული ინციდენტების შესახებ ანგარიშგების ვალდებულებები ძალაში შედის 2026 წლის 11 სექტემბრიდან; შესაბამისობის შეფასების ორგანოების შეტყობინების შესახებ დებულებები - 2026 წლის 11 ივნისიდან; რეგულაცია სრულად - 2027 წლის 11 დეკემბრიდან (CRA-ს მე-71 მუხლი). CRA-ს დანართი I მოითხოვს მწარმოებლებისგან პროდუქტის კომპონენტების იდენტიფიცირებას და დოკუმენტირებას, მათ შორის პროგრამული უზრუნველყოფის მასალების ჩამონათვალის შედგენით ფართოდ გამოყენებულ და მანქანით წასაკითხ ფორმატში, რომელიც მოიცავს სულ მცირე უმაღლესი დონის დამოკიდებულებებს. მისი გამოქვეყნება საჭირო არ არის; ბაზრის ზედამხედველობის ორგანოებს შეუძლიათ მოითხოვონ იგი.

კომერციული საქმიანობის გარეთ მოწოდებული თავისუფალი და ღია კოდის პროგრამული უზრუნველყოფა CRA-ს კომპეტენციის მიღმა ხვდება. რეგულაცია ადგენს ღია კოდის პროგრამული უზრუნველყოფის მენეჯერს - იურიდიულ პირს, რომელიც მუდმივ მხარდაჭერას უწევს კომერციული საქმიანობისთვის განკუთვნილი ღია კოდის პროგრამული უზრუნველყოფის შემუშავებას - 24-ე მუხლით უფრო მსუბუქი ვალდებულებებით. CRA: დოკუმენტირებული კიბერუსაფრთხოების პოლიტიკა, თანამშრომლობა ბაზრის ზედამხედველობის ორგანოებთან და ანგარიშგება. თუ თქვენ კომერციალიზებთ ღია კოდის კოდს ან აფინანსებთ პროექტს, რომელსაც სხვები კომერციალიზებენ, დაადგინეთ, რა როლი გიკავიათ. კომისიამ თავისი პირველი სახელმძღვანელო მითითებები 2026 წლის 27 ივლისს მიიღო: კომისიის სახელმძღვანელო კიბერმდგრადობის აქტის (CRA) გამოყენების შესახებ, რომელიც თან ერთვის C(2026) 5252 შეტყობინებას, რომელიც სხვა საკითხებთან ერთად განსაზღვრავს, თუ როდის ხვდება თავისუფალი და ღია კოდის პროგრამული უზრუნველყოფა ამ სფეროში. არ არის მიღებული არცერთი განმახორციელებელი აქტი, რომელიც განსაზღვრავს პროგრამული უზრუნველყოფის მასალების ჩამონათვალის ფორმატს, ამიტომ რეგულაციის საკუთარი სტანდარტი - ფართოდ გამოყენებული, მანქანით წასაკითხი ფორმატი - ამ დროისთვის კვლავ რჩება ზომად.

CI-ში გაშვებული პროგრამული უზრუნველყოფის შემადგენლობის ანალიზი ერთდროულად ქმნის ინვენტარს, რომელიც ემსახურება შესაბამისობას, ლიცენზიის განხილვას და გულმოდგინებას. ასეთი ინსტრუმენტები ვერ ახერხებენ მომწოდებლის კოდის გამოტოვებას, არასწორად ახდენენ ორმაგი ლიცენზიის მქონე პროექტების იდენტიფიცირებას და არ შეუძლიათ ლიცენზიის პირობების წაკითხვა: გამომავალს განიხილავენ როგორც მიმოხილვის დასაწყისს და არა თავად მიმოხილვას.

თუ საკუთარ კოდს გამოაქვეყნებთ: CLA-ები და DCO

კომპანიამ, რომელიც ავრცელებს კოდს და იღებს გარე წვლილის შემქმნელებს, უნდა იცოდეს, რომ მას აქვს უფლებები იმ პროდუქტებზე, რომლებსაც აერთიანებს. კონტრიბუტორის ლიცენზიის ხელშეკრულება არის ხელშეკრულება პროექტსა და კონტრიბუტორს შორის, რომელიც, როგორც წესი, ანიჭებს ფართო საავტორო უფლებების ლიცენზიას და ექსპრეს პატენტის ლიცენზიას, ორიგინალურობისა და ავტორიტეტის გარანტიებით. ეს არის ის, რაც კომპანიას საშუალებას აძლევს მოგვიანებით ხელახლა ლიცენზირება მოახდინოს თავისი პროექტისთვის ან შესთავაზოს კომერციული ლიცენზიები ღია კოდის ლიცენზიასთან ერთად. მისი ღირებულება ხახუნის ხარჯზეა.

Linux-ის ბირთვისა და სხვა მრავალი პროექტის მიერ გამოყენებული დეველოპერის წარმოშობის სერტიფიკატი არ არის ლიცენზიის გრანტი, არამედ მსუბუქი დამოწმებაა, რომელიც ემატება თითოეულ ვალდებულებას, როგორც დამადასტურებელი ხაზი, რომ კონტრიბუტორს შეუძლია წარადგინოს კოდი პროექტის ლიცენზიით. ნაკლებად დამღლელი და ნაკლებად დამცავი: არ არის პატენტის ლიცენზია, არ არის ხელახალი ლიცენზირება.

თუ ორმაგი ლიცენზირება ან მომავალში ხელახალი ლიცენზირება დასაშვებია, გამოიყენეთ CLA; თუ პროექტი ნამდვილი საერთო საკუთრებაა, DCO, როგორც წესი, საკმარისია. ნებისმიერ შემთხვევაში, დარწმუნდით, რომ თქვენი დასაქმებისა და კონტრაქტორის ხელშეკრულებები საავტორო უფლებებს ანიჭებს თქვენი თანამშრომლების მიერ დაწერილ კოდს.

პრაქტიკული პოლიტიკის საკონტროლო სია

• თითოეული პროდუქტისთვის შექმენით კომპონენტების ინვენტარი და გამოუშვით შექმნის პროცესში, ხელით არა.
• გამოაქვეყნეთ შიდა პოლიტიკა: დაშვებული სია, აკრძალული სია და დამტკიცების გზა ყველა დანარჩენისთვის.
• წერილობით განსაზღვრეთ, რა ითვლება დისტრიბუციად — ადგილობრივი ინსტალაციები, მოწყობილობები, კონტეინერები, SDK-ები, მობილური აპლიკაციები, firmware.
• ყველა პროდუქტთან ერთად გააგზავნეთ გენერირებული ატრიბუციის ფაილი.
• ლიცენზიის არჩევანი დაამტკიცეთ დიზაინის დროს, კომპონენტის არჩევისას და არა გამოშვებისას.
• გადაწყვიტეთ, საჭიროებს თუ არა გარე პროექტებში შეტანილ წვლილს დამტკიცებას, შესაბამისი საპატენტო გრანტების გათვალისწინებით, და პირველი გარე წვლილის შეტანამდე აირჩიეთ CLA ან DCO.
• ინტელექტუალური საკუთრების გარანტიების, ანაზღაურებისა და ესქროს პირობები პროდუქტში არსებულ ღია კოდთან შეუსაბამეთ.
• მიმოხილვა ჩაატარეთ სახსრების მოზიდვის ან გაყიდვის პროცესის დაწყებამდე და არა მის დროს.

Law & More ურჩევს პროგრამული უზრუნველყოფის კომპანიებს და მათ ინვესტორებს Eindhoven მდე Amsterdam ღია კოდის შესაბამისობაზე, ლიცენზიის განხილვაზე, კონტრიბუტორების შეთანხმებებსა და ღია კოდის სამუშაო ნაკადზე ტრანზაქციაში.