Лиценци за софтвер со отворен код според холандското и европското право

Речиси секој комерцијален софтверски производ содржи компоненти со отворен код, обично стотици, избрани од програмери, а не од адвокати. Тоа станува проблем кога никој не може да каже кои лиценци се однесуваат, што бараат и дали производот е во согласност со прописите. Оваа статија објаснува како функционираат лиценците со отворен код според холандското и европското право, каде лежи ризикот и што треба да се има предвид.

Што е лиценца за отворен код, во правна смисла

Лиценца за отворен код е лиценца за авторски права доделена под услови. Таа не е откажување, не е посветеност на јавниот домен, не е откажување од правата и во тој поглед функционира како и секоја друга софтверска лиценца според холандскиот закон . Авторот ги задржува авторските права според чл. 1 од Законот и чл. 10 од Законот, кои ги штитат компјутерските програми како дела, а лиценцата дозволува дејствија што инаку би ги прекршиле ексклузивните права според чл. 12 од Законот и чл. 13 од Законот.

Последицата е поважна од дефиницијата. Доколку се почитува, вашето копирање и дистрибуција се законски. Доколку не се почитува, дозволата не го опфаќа она што сте го направиле: вашата употреба е повреда на авторски права, а не прекршување на договор. Повеќето лиценци за авторско право го зајакнуваат ова со автоматско прекинување при прекршување - GPLv2 без никаков период на корекција, додека GPLv3 и AGPLv3 ги враќаат правата ако прекршувањето се поправи во рамките на дефиниран рок по известувањето.

Холандските судови го применуваат ова образложение. Во случајот Rb. Amsterdam На 22 септември 2020 година, ECLI:NL:RBAMS:2020:4717, дистрибутер кој го отстранил текстот на лиценцата и известувањето за авторски права од разгранета база на кодови беше прогласен за лице кое ја изгубило дозволата и дека прекршува. Додавањето голем обем на нов код не создаде независно дело: оригиналот остана препознатливо присутен, па затоа обврските патуваа со него.

Двете семејства: пермисивни и копилефт

Дозволените лиценци — MIT, BSD лиценците, Apache 2.0 — дозволуваат употреба, модификација и редистрибуција, вклучително и во производи со затворен код, под услов да ги зачувате известувањата за авторски права и текстот на лиценцата.

Лиценците за авторски права бараат кога го дистрибуирате софтверот или нешто изградено врз него, да го правите тоа под истата лиценца и да го ставите на располагање соодветниот изворен код. Тие се разликуваат по досег.

Активатор за copyleft и прашање за поврзување

Обврските за авторско право влијаат врз дистрибуцијата, а не врз употребата. Компанија што интерно користи GPL софтвер, колку и да е силно модифициран, не дистрибуира ништо и не должи ништо. „Дали сме дистрибуирале?“ е секогаш првото прашање и затоа контејнерите, апаратите, фирмверот и SDK-ата се поважни од интерните алатки.

Второто прашање е потешко. GPL зборува за „дело засновано на Програмата“, позајмувајќи го американскиот концепт на изведено дело. Холандскиот закон нема таков термин: анализата се протега низ правата за репродукција и адаптација, прашувајќи дали е репродуциран заштитен израз од оригиналот.

Практичниот случај е поврзувањето. Дали поврзувањето на сопственички модул со GPL библиотека создава едно дело кое е предмет на copyleft никогаш не е одлучено од холандски суд и не постои обврзувачки орган на ЕУ. Ставот на Фондацијата за слободен софтвер дека поврзувањето создава комбинирано дело е толкување на управителот на лиценцата, а не закон, а спротивниот став е подеднакво нетестиран. Омилен одговор на интернетот - динамичко поврзување безбедно, статичко поврзување не - нема основа во холандскиот закон за авторски права, кој не прашува како се однесува компајлерот. Поодбранлива анализа прашува колку интимно се комбинирани компонентите: дали тие делат адресен простор и структури на податоци, дали комбинацијата се испорачува како еден производ, дали може да функционира самостојно, дали сопственичката страна репродуцира заглавија, макроа или вграден код од страната copyleft? Овие прашања обично го решаваат ризикот. Онаму каде што не го прават тоа, изолирајте ја компонентата зад границата на процесот, заменете ја или земете комерцијална лиценца.

AGPL и употреба на мрежа

AGPL постои бидејќи авторското право се активира со дистрибуција, а SaaS провајдерите не го дистрибуираат. Неговата мрежна клаузула бара, ако го модифицирате софтверот и го направите достапен за корисниците кои комуницираат со него од далечина, да им го понудите соодветниот изворен код на вашата изменета верзија.

Најчесто се пропуштаат три точки. Обврската важи за корисниците на услугата, што кај производ со отворена регистрација не е голема удобност. Се активира со модификација, така што немодифицирана компонента не ја активира, но поправената верзија може. И го поставува истото прашање за комбинирана работа како и GPL за остатокот од вашиот стек - поради што многу компании ја забрануваат AGPL во продукцискиот код.

Компатибилност со лиценци

Компатибилноста е проблем со комбинирање на компоненти чии лиценци наметнуваат обврски кои не можат да се исполнат во една дистрибуција: дозволивите лиценци се компатибилни со скоро сè, лиценците со авторско право само со она што нивните услови го дозволуваат. Стандарден случај се Apache 2.0 и GPLv2. Фондацијата за софтвер Apache и Фондацијата за слободен софтвер се согласуваат дека комбинацијата не е дозволена, бидејќи одредбите за престанок на патентот и обештетување на 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 код со код според наведена лиценца да се дистрибуира според таа лиценца.
• Достигнување. Неговата дефиниција за дистрибуција опфаќа достапност на делото онлајн или офлајн. или обезбедување пристап до неговите основни функционалности, и чл. 5 од EUPL ја пренесува обврската за авторско право до далечинска интеракција во која се нуди истата таа функционалност. Затоа, таа достигнува до софтверот испорачан како услуга, на начин на кој GPL не го прави тоа.

Холандски клиент од јавниот сектор може да бара EUPL како прашање на политика, а не како прашање на закон. Законот за интероперабилна Европа, Регулатива (ЕУ) 2024/903, им наложува на органите од јавниот сектор да дадат приоритет на интероперабилните решенија без рестриктивни услови за лиценцирање, како што е отворениот код, каде што е еквивалентно; на национално ниво, принципот на отворен код, tenzij , се потпира на одлуките на кабинетот и политичките линии, а не на закон: Wet digitale overheid ја олеснува инфраструктурата за дигитален идентитет, но не наметнува никаква извршна обврска за објавување на целиот изворен код. Прочитајте ја тендерската документација: барањето за EUPL го обврзува вашиот производ и може да биде некомпатибилно со сопственичкиот код што сте имале намера да го користите повторно.

Спроведување во пракса

Кој може да тужи. Носителот на правата — индивидуални соработници или фондацијата или компанијата што ги поседува доделените авторски права. Фрагментираното авторство е практичната сопирачка: подносителот на барањето мора да докаже сопственост врз спорниот код. Со тоа беше поништен најпознатиот европски случај со GPL, каде што тужбата на развивач на јадро против продавач на виртуелизација не успеа поради недостаток на доказ за авторство (LG Hamburg 8 јули 2016, 310 O 89/15; потврдена OLG Hamburg 28 февруари 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 може да ја спроведе GPL како корисник од трета страна. Тоа е централното прашање во Software Freedom Conservancy v Vizio пред Вишиот суд на Калифорнија: дали потрошувачите, како корисници од трета страна, можат да бараат објавување на изворниот код според GPLv2. На 23 декември 2025 година, судот одлучи за едно прашање во врска со резимираната пресуда, утврдувајќи дека GPLv2 и LGPLv2.1 бараат извор што може да се добие и преработи за употреба на друго место, а не извор што може повторно да се инсталира на уредот со недопрена функционалност. Самото прашање за корисник од трета страна беше оставено за судењето пред судот, кое беше одложено повеќе од еднаш. Во секој случај, тоа е прашање од калифорниското договорно право, па затоа не обврзува ништо во Холандија; она што би го променило е бројот на луѓе што можат да поднесат жалба.

Како би пристапил холандскиот суд кон тоа. Како повреда на авторски права според Законот за авторски права: тужителот докажува сопственост и репродукција или соопштување; тужениот ја покренува лиценцата; тужителот одговара дека нејзините услови не биле исполнети, па затоа одбраната не успева. Договорните правни лекови според чл. 6:265 BW течат паралелно, но авторските права се посилниот пат.

Правни лекови. Забрана согласно чл. 3:296 BW, обично со парична казна и достапна во скратена постапка; штети согласно чл. 27 Aw и сметка за профитот согласно чл. 27a Aw; повлекување, предавање или уништување согласно чл. 28 Aw; и целосно враќање на разумни и пропорционални судски трошоци согласно чл. 1019h Rv. Кога софтверот се дистрибуирал бесплатно, загубата е тешко да се квантифицира, а германскиот апелационен суд одби да досуди отштета, а ја потврди забраната (OLG Hamm 13 јуни 2017 година, 4 U 72/16). Она што ретко се налутува е отштета: тоа е забраната, повлекувањето, одлуката за трошоци и обврската да се објави извор што никогаш не сте имале намера да го објавите.

Кога ќе откриете проблем со усогласеност

Откритието обично доаѓа од прашалник за безбедност на клиентот, скенирање за време на длабинска анализа или писмо од носителот на права. Потоа, санацијата се одвива на следниов начин. Запрете ја дистрибуцијата на засегнатата верзија ако изложеноста е сериозна. Утврдете која компонента, која верзија, која лиценца, кои производи и изданија, во кој период. Утврдете што всушност бара лиценцата - честопати датотека за атрибуција, а не издание на извор. Подгответе ги артефактите: известувања, текстови на лиценци, комплетен соодветен извор, вклучувајќи скрипти за градење и писмена понуда каде што е користено. Испратете издание кое е во согласност со прописите, а потоа кажете му на носителот на права што сте направиле, наместо да се расправате дали сте морале.

Според GPLv3 и AGPLv3, прозорецот за лекување дава правна вредност на брзината; според GPLv2 нема право на лекување, поради што поголемиот дел од спроведувањето завршува со договорена обврска за усогласеност. Забележете исто така дека привилегијата се однесува на совет од вашиот адвокат, а не на внатрешен инженерски извештај.

Отворен код во спојувања и преземања и длабинска анализа

При аквизиција на софтвер, отворениот код е стандарден работен тек на анализа, а неоткриената компонента за авторско право во основниот производ е едно од ретките откритија што навистина го поместуваат договорот: ако производот не може да се дистрибуира без да се објави неговиот изворен код, купувачот стекнува различен имот од оној со цената.

Очекувајте скенирање на базата на код, инвентар на компоненти со лиценци и прашања во врска со аранжманите со придонесувачите и изведувачите. Типични исходи се специфична обештетување, задржување во исчекување на санација, условен преседан што бара отстранување или гаранција за отворен код по мерка. Продавачите треба прво да скенираат: наодите што ги откривате се преговори, наодите што ги прави советникот на купувачот се влијание. Купувачите не треба да бараат „компанијата ја поседува својата интелектуална сопственост“, туку изјава дека ниеден производ не вклучува отворен код што бара откривање на сопственички изворен код.

Список на материјали, скенирање и Законот за кибер отпорност

Списокот на материјали за софтвер е инвентар на компонентите на производот, со верзии и лиценци. До неодамна беше чисто договорен, а сега е и регулаторен.

Законот за сајбер отпорност, Регулатива (ЕУ) 2024/2847, стапи на сила на 10 декември 2024 година и постепено стапува во сила. Тој е дел од холандскиот Закон за сајбер безбедност , кој се однесува на организацијата, а не на производот. Обврските за известување за активно искористени ранливости и сериозни инциденти во член 14 од CRA важат од 11 септември 2026 година; одредбите за известување на телата за оцена на сообразност од 11 јуни 2026 година; Регулативата во целост од 11 декември 2027 година (член 71 од CRA). Анекс I од CRA бара од производителите да ги идентификуваат и документираат компонентите во производот, вклучително и со изготвување список на материјали за софтвер во најчесто користен и машински читлив формат, кој ги опфаќа барем зависностите од највисоко ниво. Не мора да се објавува; органите за надзор на пазарот можат да го побараат.

Слободниот софтвер со отворен код испорачан надвор од комерцијална активност спаѓа надвор од надлежноста на CRA. Регулативата го воведува управителот за софтвер со отворен код - правно лице кое дава постојана поддршка на развојот на софтвер со отворен код наменет за комерцијални активности - со полесни обврски во член 24. CRA: документирана политика за сајбер безбедност, соработка со органите за надзор на пазарот и известување. Ако комерцијализирате отворен код или финансирате проект што другите го комерцијализираат, утврдете ја вашата улога. Комисијата го усвои своето прво упатство на 27 јули 2026 година: упатството на Комисијата за примена на Законот за сајбер отпорност (CRA), приложено кон комуникацијата C(2026) 5252, кое, меѓу другото, се однесува кога слободниот софтвер со отворен код спаѓа во опфатот. Не е усвоен никаков акт за спроведување што пропишува формат за списокот на материјали на софтверот, па затоа сопствениот стандард на Регулативата - најчесто користен, машински читлив формат - засега останува мерка.

Анализата на составот на софтверот извршена во CI генерира инвентар кој истовремено обезбедува усогласеност, преглед на лиценцата и проверка на квалитетот. Ваквите алатки го промашуваат кодот на добавувачот, погрешно идентификуваат проекти со двојна лиценца и не можат да ги прочитаат условите на лиценцата: третирајте го резултатот како почеток на прегледот, а не како преглед.

Ако го објавите сопствениот код: CLAs и DCO

Компанијата што објавува код и прифаќа надворешни придонеси мора да знае дека ги има правата врз она што го спојува. Договорот за лиценца за придонесувач е договор помеѓу проектот и придонесувачот, со кој обично се доделува широка лиценца за авторски права и експлицитна лиценца за патент, со гаранции за оригиналност и авторитет. Тоа е она што ѝ овозможува на компанијата подоцна да го релиценцира својот проект или да понуди комерцијални лиценци заедно со лиценци со отворен код. Неговата цена е триење.

Сертификатот за потекло на развивачот , кој го користат Linux јадрото и многу други проекти, не е доделување лиценца, туку лесна потврда, додадена како потписна линија на секое извршување, дека придонесувачот може да го поднесе кодот според лиценцата на проектот. Помалку оптоварувачки и помалку заштитнички: нема патентна лиценца, нема релиценцирање.

Доколку е можно двојно лиценцирање или идно релиценцирање, користете CLA; ако проектот е вистински заеднички имот, DCO е обично доволен. Во секој случај, осигурајте се дека вашите договори за вработување и договори за изведувачи доделуваат авторски права за кодот што го пишуваат вашите луѓе.

Контролна листа за практична политика

• Генерирајте инвентар на компоненти по производ и објавете го во процесот на градење, а не рачно.
• Објавете интерна политика: список на дозволени, список на забранети и пат за одобрување за сè друго.
• Дефинирајте во писмена форма што се смета за дистрибуција — инсталации на лице место, апарати за домаќинство, контејнери, SDK-а, мобилни апликации, фирмвер.
• Испратете генерирана датотека за атрибуција со секој производ.
• Одобрувајте ги изборите за лиценци во времето на дизајнирање, кога е избрана компонента, а не при објавување.
• Одлучете дали е потребно одобрување за придонеси за надворешни проекти, со оглед на вклучените грантови за патенти, и изберете CLA или DCO пред првиот надворешен придонес.
• Усогласете ги гаранциите, обештетувањата и условите за депонирање за интелектуална сопственост со отворениот код што всушност е во производот.
• Направете го прегледот пред процесот на собирање средства или продажба, а не за време на тој процес.

Law & More советува софтверски компании и нивните инвеститори од Eindhoven Amsterdam за усогласеност со отворениот код, преглед на лиценците, аранжманите за придонесувачи и работниот тек со отворен код во трансакцијата.