Բաց կոդով ծրագրային ապահովման լիցենզիաներ՝ համաձայն Նիդեռլանդների և ԵՄ օրենսդրության

Գրեթե յուրաքանչյուր առևտրային ծրագրային ապահովում պարունակում է բաց կոդով բաղադրիչներ, սովորաբար հարյուրավոր, որոնք ընտրվում են մշակողների կողմից, այլ ոչ թե իրավաբանների կողմից: Սա խնդիր է դառնում, երբ ոչ ոք չի կարող ասել, թե որ լիցենզիաներն են կիրառելի, ինչ են պահանջում և արդյոք արտադրանքը համապատասխանում է պահանջներին: Այս հոդվածը բացատրում է, թե ինչպես են բաց կոդով լիցենզիաները գործում Նիդեռլանդների և ԵՄ օրենսդրության համաձայն, որտեղ է գտնվում ռիսկը և ինչ պետք է ունենալ:

Ի՞նչ է բաց կոդով լիցենզիան՝ իրավական առումով

Բաց կոդով լիցենզիան հեղինակային իրավունքի լիցենզիա է, որը տրամադրվում է որոշակի պայմաններով: Այն հրաժարում չէ, հանրային սեփականությանը նվիրվածություն չէ, իրավունքներից հրաժարում չէ, և այդ առումով այն գործում է ինչպես հոլանդական օրենսդրության համաձայն ցանկացած այլ ծրագրային ապահովման լիցենզիա : Հեղինակը պահպանում է հեղինակային իրավունքը օրենքի 1-ին և 10-րդ հոդվածների համաձայն, որոնք պաշտպանում են համակարգչային ծրագրերը որպես ստեղծագործություններ, և լիցենզիան թույլ է տալիս գործողություններ, որոնք այլապես կխախտեին օրենքի 12-րդ և 13-րդ հոդվածների համաձայն բացառիկ իրավունքները:

Հետևանքն ավելի կարևոր է, քան սահմանումը։ Համապատասխանության դեպքում ձեր պատճենումն ու տարածումը օրինական են։ Չհամապատասխանելու դեպքում թույլտվությունը չի տարածվում ձեր արածի վրա. ձեր օգտագործումը հեղինակային իրավունքի խախտում է, այլ ոչ թե պայմանագրի խախտում։ Հեղինակային իրավունքի լիցենզիաների մեծ մասը ամրապնդում է սա՝ խախտման դեպքում ավտոմատ կերպով դադարեցնելով գործողությունը՝ GPLv2 առանց որևէ վերականգնման ժամկետի, մինչդեռ GPLv3-ը և AGPLv3-ը վերականգնում են իրավունքները, եթե խախտումը շտկվում է ծանուցումից հետո սահմանված ժամկետում։

Հոլանդական դատարանները կիրառում են այս դատողությունը։ Ռբ. գործում։ Amsterdam 2020 թվականի սեպտեմբերի 22-ին, ECLI:NL:RBAMS:2020:4717, դիստրիբյուտորը, որը հեռացրել էր լիցենզիայի տեքստը և հեղինակային իրավունքի ծանուցումը ճյուղավորված կոդային բազայից, ճանաչվեց որպես թույլտվությունը կորցրած և հեղինակային իրավունքի խախտում կատարող։ Մեծ քանակությամբ նոր կոդի ավելացումը չստեղծեց անկախ աշխատանք. բնօրինակը մնաց ճանաչելիորեն առկա, ուստի պարտավորությունները ուղեկցեցին դրան։

Երկու ընտանիքներ՝ թույլատրողական և հեղինակային իրավունքի պաշտպան

Թույլատրողական լիցենզիաները ՝ MIT-ը, BSD լիցենզիաները, Apache 2.0-ը, թույլ են տալիս օգտագործել, փոփոխել և վերաբաշխել, այդ թվում՝ փակ կոդով արտադրանքի ներսում, եթե դուք պահպանում եք հեղինակային իրավունքի մասին ծանուցումները և լիցենզիայի տեքստը։

Հեղինակային իրավունքի լիցենզիաները պահանջում են, որ երբ դուք տարածում եք ծրագիրը կամ դրա վրա կառուցված որևէ բան, դա անեք նույն լիցենզիայով և հասանելի դարձնեք համապատասխան աղբյուրը։ Դրանք տարբերվում են իրենց հասանելիությամբ։

Հեղինակային իրավունքի ակտիվացուցիչը և հղումների հարցը

Հեղինակային իրավունքի պարտավորությունները ազդում են տարածման, այլ ոչ թե օգտագործման վրա: GPL ծրագրակազմը ներքին կարգով օգտագործող ընկերությունը, որքան էլ խիստ փոփոխված լինի, ոչինչ չի տարածում և ոչինչ պարտք չէ: «Մենք տարածե՞լ ենք» հարցը միշտ առաջին հարցն է, և այդ պատճառով կոնտեյներները, սարքերը, ներկառուցված ծրագրերը և 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 պահանջել որպես քաղաքականության հարց, այլ ոչ թե օրենքի: «Ինտերակտիվ Եվրոպայի մասին» օրենքը, (ԵՄ) 2024/903 կանոնակարգը, պետական ​​հատվածի մարմիններին հրահանգում է առաջնահերթություն տալ փոխգործունակության լուծումներին՝ առանց սահմանափակող լիցենզավորման պայմանների, ինչպիսիք են բաց կոդը, որտեղ դրանք համարժեք են. ազգային մակարդակով բաց կոդի սկզբունքը հիմնված է կաբինետի որոշումների և քաղաքականության գծերի վրա, այլ ոչ թե օրենքի. թվային ինքնության ենթակառուցվածքը հեշտացնում է թվային ինքնության ենթակառուցվածքը, բայց չի սահմանում որևէ կիրառելի պարտավորություն՝ հրապարակելու բոլոր կոդերը: Կարդացեք մրցույթային փաստաթղթերը. EUPL պահանջը պարտադիր է ձեր արդյունքի համար և կարող է անհամատեղելի լինել այն սեփական կոդի հետ, որը դուք մտադիր էիք վերօգտագործել:

Կիրառումը գործնականում

Ո՞վ կարող է դատի տալ։ Հեղինակային իրավունքի տերը՝ անհատ մասնակիցներ, կամ հիմնադրամ կամ ընկերություն, որը տիրապետում է հեղինակային իրավունքի փոխանցմանը։ Մասնատված հեղինակությունը գործնականում արգելակ է. հայցվորը պետք է ապացուցի վիճելի կոդի սեփականությունը։ Դրանով մերժվեց եվրոպական ամենահայտնի GPL գործը, որտեղ միջուկի մշակողի հայցը վիրտուալիզացիայի մատակարարի դեմ մերժվեց հեղինակության ապացույցների բացակայության պատճառով (LG Hamburg 8 July 2016, 310 O 89/15; հաստատվեց OLG Hamburg 28 February 2019, 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 հոդվածի, որը սովորաբար ներառում է տուգանք և հասանելի է ամփոփ դատավարության ընթացքում։ Վնասի փոխհատուցում՝ համաձայն Aw 27 հոդվածի և շահույթի հաշվետվություն՝ համաձայն Aw 27a հոդվածի։ Հետկանչ, հանձնում կամ ոչնչացում՝ համաձայն Aw 28 հոդվածի։ և ողջամիտ և համաչափ դատական ​​ծախսերի լրիվ փոխհատուցում՝ համաձայն 1019h Rv հոդվածի։ Երբ ծրագրային ապահովումը տարածվել է անվճար, վնասը դժվար է քանակապես որոշել, և Գերմանիայի վերաքննիչ դատարանը հրաժարվել է փոխհատուցում շնորհել՝ միաժամանակ պահպանելով արգելքը (OLG Hamm 13 հունիսի 2017թ., 4 U 72/16)։ Հազվադեպ է վնասը վնասում. դա արգելքն է, հետկանչը, դատական ​​ծախսերի կարգադրությունը և այն աղբյուրը հրապարակելու անհրաժեշտությունը, որը դուք երբեք չեք մտադրվել հրապարակել։

Երբ դուք հայտնաբերում եք համապատասխանության խնդիր

Հայտնաբերումը սովորաբար կատարվում է հաճախորդի անվտանգության հարցաթերթիկից, ուսումնասիրության ընթացքում կատարված սկանավորումից կամ իրավատիրոջ նամակից: Այնուհետև շտկումը կատարվում է հետևյալ կերպ. դադարեցրեք ազդակիր տարբերակի տարածումը, եթե վտանգը լուրջ է: Սահմանեք, թե որ բաղադրիչը, որ տարբերակը, որ լիցենզիան, որ ապրանքներն ու թողարկումները ինչ ժամանակահատվածում: Պարզեք, թե իրականում ինչ է պահանջում լիցենզիան՝ հաճախ վերագրման ֆայլ, այլ ոչ թե աղբյուրի թողարկում: Պատրաստեք արտեֆակտները՝ ծանուցումներ, լիցենզիայի տեքստեր, համապատասխան աղբյուրի ամբողջական տարբերակը, ներառյալ կառուցման սկրիպտները, և գրավոր առաջարկ, որտեղ օգտագործվել է: Ուղարկեք համապատասխան թողարկում, ապա իրավատիրոջը պատմեք, թե ինչ եք արել, այլ ոչ թե վիճեք այն մասին, թե արդյոք պետք է դա անեիք:

GPLv3 և AGPLv3 համաձայն՝ վերականգնման պատուհանը արագությանը տալիս է իրավական արժեք. GPLv2 համաձայն՝ վերականգնման իրավունք չկա, այդ իսկ պատճառով կիրարկման մեծ մասն ավարտվում է բանակցային համապատասխանության պարտավորություններով: Նկատի ունեցեք նաև, որ արտոնությունը վերաբերում է ձեր փաստաբանի խորհրդատվությանը, այլ ոչ թե ներքին ինժեներական զեկույցին:

Բաց կոդը միաձուլումների և ձեռքբերումների և ուսումնասիրությունների մեջ

Ծրագրային ապահովման ձեռքբերման դեպքում բաց կոդը ստանդարտ աշխատանքային հոսք է, և հիմնական արտադրանքի մեջ չբացահայտված հեղինակային իրավունքի բաղադրիչը այն քիչ հայտնագործություններից մեկն է, որն իսկապես առաջընթաց է գրանցում գործարքի հարցում. եթե արտադրանքը չի կարող տարածվել առանց իր աղբյուրը հրապարակելու, գնորդը ձեռք է բերում գնվածից տարբերվող ակտիվ։

Ակնկալեք կոդի բազայի սկանավորում, բաղադրիչների գույքագրում՝ լիցենզիաներով, և հարցեր մասնակիցների և կապալառուների պայմանավորվածությունների վերաբերյալ: Տիպիկ արդյունքներն են՝ որոշակի փոխհատուցում, պահպանում՝ մինչև շտկումը, հեռացման պահանջող նախադեպային պայման կամ բաց կոդով պատվերով երաշխիք: Վաճառողները պետք է նախ սկանավորեն. ձեր բացահայտած եզրակացությունները բանակցություն են, գնորդի խորհրդատուի կողմից արված եզրակացությունները՝ լծակներ: Գնորդները պետք է փնտրեն ոչ թե «ընկերության սեփականությունը իր մտավոր սեփականության», այլ հավաստիացում, որ ոչ մի ապրանք չի ներառում բաց կոդ, որը պահանջում է սեփական կոդի բացահայտում:

Նյութերի ցանկը, սկանավորումը և կիբերդիմադրողականության մասին օրենքը

Ծրագրային ապահովման նյութերի ցանկը ապրանքի բաղադրիչների ցանկ է՝ տարբերակներով և լիցենզիաներով։ Մինչև վերջերս այն զուտ պայմանագրային էր, իսկ այժմ՝ նաև կարգավորող։

«Կիբերդիմակայունության մասին» օրենքը՝ (ԵՄ) 2024/2847 կանոնակարգը, ուժի մեջ է մտել 2024 թվականի դեկտեմբերի 10-ին և աստիճանաբար ուժի մեջ է մտնում։ Այն գործում է « Նիդեռլանդների կիբերանվտանգության մասին» օրենքի հետ մեկտեղ , որը վերաբերում է կազմակերպությանը, այլ ոչ թե արտադրանքին։ Համապատասխանության գնահատման մասին օրենքի 14-րդ հոդվածում ակտիվորեն շահագործվող խոցելիությունների և լուրջ միջադեպերի մասին հաշվետվություն ներկայացնելու պարտավորությունները կիրառվում են 2026 թվականի սեպտեմբերի 11-ից, համապատասխանության գնահատման մարմիններին ծանուցման վերաբերյալ դրույթները՝ 2026 թվականի հունիսի 11-ից, իսկ կանոնակարգն ամբողջությամբ՝ 2027 թվականի դեկտեմբերի 11-ից (ՀԿԱ 71-րդ հոդված)։ ՀԿԱ I հավելվածը պահանջում է, որ արտադրողները նույնականացնեն և փաստաթղթավորեն արտադրանքի բաղադրիչները, այդ թվում՝ կազմելով ծրագրային ապահովման նյութերի ցանկ՝ լայնորեն օգտագործվող և մեքենայական ընթերցման ձևաչափով, որը ներառում է առնվազն վերին մակարդակի կախվածությունները։ Այն հրապարակելու կարիք չկա. շուկայի վերահսկողության մարմինները կարող են այն պահանջել։

Առևտրային գործունեությունից դուրս մատակարարվող անվճար և բաց կոդով ծրագրային ապահովումը չի ընկնում CRA-ի իրավասության տակ: Կանոնակարգը ներկայացնում է բաց կոդով ծրագրային ապահովման կառավարչին՝ իրավաբանական անձ, որը կայուն աջակցություն է ցուցաբերում առևտրային գործունեության համար նախատեսված բաց կոդով ծրագրային ապահովման մշակմանը՝ 24-րդ հոդվածում ավելի թեթև պարտավորություններով: CRA. փաստաթղթավորված կիբերանվտանգության քաղաքականություն, շուկայի վերահսկողության մարմինների հետ համագործակցություն և հաշվետվություն: Եթե դուք առևտրայնացնում եք բաց կոդը կամ ֆինանսավորում եք ուրիշների կողմից առևտրայնացվող նախագիծ, նշեք, թե ինչ դեր եք զբաղեցնում: Հանձնաժողովն իր առաջին ուղեցույցն ընդունել է 2026 թվականի հուլիսի 27-ին՝ Կիբերդիմակայունության մասին օրենքի (CRA) կիրառման վերաբերյալ Հանձնաժողովի ուղեցույցը, որը կցված է C(2026) 5252 հաղորդագրությանը, որը, ի թիվս այլ հարցերի, անդրադառնում է, թե երբ է ազատ և բաց կոդով ծրագրային ապահովումը ընկնում գործողության մեջ: Ծրագրային ապահովման նյութերի ցանկի ձևաչափ սահմանող որևէ կիրարկող ակտ չի ընդունվել, ուստի Կանոնակարգի սեփական ստանդարտը՝ լայնորեն օգտագործվող, մեքենայական ընթերցման ձևաչափը, առայժմ մնում է որպես միջոց:

CI-ում իրականացվող ծրագրային ապահովման կազմի վերլուծությունը ստեղծում է միաժամանակ համապատասխանության, լիցենզիայի վերանայման և մանրակրկիտ աշխատանքի համար նախատեսված գույքագրում: Նման գործիքները բաց են թողնում մատակարարի կոդը, սխալմամբ նույնականացնում են կրկնակի լիցենզավորված նախագծերը և չեն կարող կարդալ լիցենզիայի պայմանները. արդյունքը համարեք վերանայման սկիզբ, այլ ոչ թե վերանայում:

Եթե ​​հրապարակում եք ձեր սեփական կոդը՝ CLA-ները և DCO-ն

Ընկերությունը, որը թողարկում է կոդ և ընդունում է արտաքին ներդրումներ, պետք է իմանա, որ ունի իր իրավունքները այն բանի նկատմամբ, ինչը միավորում է: Մասնակցի լիցենզիոն պայմանագիրը նախագծի և մասնակցի միջև կնքված պայմանագիր է, որը սովորաբար տրամադրում է լայն հեղինակային իրավունքի լիցենզիա և հստակ արտոնագրային լիցենզիա՝ օրիգինալության և հեղինակության երաշխիքներով: Այն է, ինչը թույլ է տալիս ընկերությանը հետագայում վերալիցենզավորել իր նախագիծը կամ առաջարկել առևտրային լիցենզիաներ բաց կոդով լիցենզիաների հետ մեկտեղ: Դրա արժեքը շփման գործընթացն է:

Linux միջուկի և շատ այլ նախագծերի կողմից օգտագործվող մշակողի ծագման վկայականը լիցենզիայի տրամադրում չէ, այլ թեթև հավաստագիր, որը յուրաքանչյուր «commit»-ին ավելացվում է որպես ստորագրման տող, որում նշվում է, որ մասնակիցը կարող է կոդը ներկայացնել նախագծի լիցենզիայով։ Ավելի քիչ ծանրաբեռնված և պակաս պաշտպանիչ. արտոնագրային լիցենզիա չկա, վերալիցենզավորում չկա։

Եթե ​​կրկնակի լիցենզավորումը կամ ապագա լիցենզիայի վերափոխումը հավանական է, օգտագործեք CLA (Կատարողականի համաձայնագիր). եթե նախագիծը իրական ընդհանուր սեփականություն է, DCO-ն սովորաբար բավարար է: Ամեն դեպքում, համոզվեք, որ ձեր աշխատանքային և կապալառուական պայմանագրերը հեղինակային իրավունք են շնորհում ձեր մարդկանց գրած կոդին:

Գործնական քաղաքականության ստուգաթերթիկ

• Ստեղծեք բաղադրիչների ցանկ յուրաքանչյուր ապրանքի համար և թողարկեք այն կառուցման ընթացքում, այլ ոչ թե ձեռքով։
• Հրապարակեք ներքին քաղաքականություն՝ թույլատրվածների ցանկ, արգելվածների ցանկ և մնացած ամեն ինչի հաստատման ուղի։
• Գրավոր սահմանեք, թե ինչն է համարվում բաշխում՝ տեղում տեղադրումներ, սարքավորումներ, կոնտեյներներ, SDK-ներ, բջջային հավելվածներ, ներկառուցված ծրագրային ապահովում։
• Յուրաքանչյուր ապրանքի հետ ուղարկեք ստեղծված վերագրման ֆայլ։
• Հաստատել լիցենզիայի ընտրությունները նախագծման պահին, երբ բաղադրիչն ընտրվում է, այլ ոչ թե թողարկման ժամանակ։
• Հաշվի առնելով ներգրավված արտոնագրային դրամաշնորհները, որոշեք, թե արդյոք արտաքին նախագծերին կատարվող ներդրումները կարիք ունեն հաստատման, և առաջին արտաքին ներդրումից առաջ ընտրեք CLA կամ DCO:
• Համապատասխանեցրեք մտավոր սեփականության երաշխիքները, փոխհատուցումները և էսքրոու պայմանները ապրանքում առկա բաց կոդի հետ։
• Անցկացրեք վերանայումը դրամահավաքից կամ վաճառքի գործընթացից առաջ, այլ ոչ թե դրա ընթացքում։

Law & More խորհրդատվություն է տրամադրում ծրագրային ապահովման ընկերություններին և նրանց ներդրողներին Eindhoven և Amsterdam բաց կոդով համապատասխանության, լիցենզիայի վերանայման, մասնակիցների հետ պայմանավորվածությունների և գործարքի շրջանակներում բաց կոդով աշխատանքային հոսքի վերաբերյալ։