Лиценце за софтвер отвореног кода према холандском и ЕУ праву

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

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

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

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

Холандски судови примењују ово образложење. У случају Rb. Amsterdam 22. септембра 2020, 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. Крше се јер их нико не поседује и најлакше их је поправити — обично се генерише датотека са атрибуцијом која се испоручује са производом. Горе наведени холандски случај је управо показао овај неуспех.

Доделе патената и одмазде због патената

МИТ и БСД не говоре ништа о патентима, а питање да ли се лиценца за патент може подразумевати је нерешено. Апачи 2.0 је додао изричиту, бесплатну лиценцу за патент од сваког сарадника, упарену са клаузулом о одмазди: покрените патентни спор тврдећи да рад крши патент и ваша лиценца за патент престаје да важи. ГПЛв3 садржи упоредиву лиценцу за доделу и сопствене одредбе о патентима.

Две импликације за компаније са портфолијима патената. Ако ваши инжењери доприносе пројектима лиценцираним под 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 као корисник треће стране. То је централно питање у предмету Software Freedom Conservancy v Vizio пред Вишим судом Калифорније: да ли потрошачи, као корисници треће стране, могу захтевати објављивање изворног кода под GPLv2. Дана 23. децембра 2025. године, суд је одлучио о једној тачки о скраћеном поступку, утврдивши да GPLv2 и LGPLv2.1 захтевају изворни код који се може добити и прерадити за употребу на другом месту, а не изворни код који се може поново инсталирати на уређај са нетакнутом функционалношћу. Само питање корисника треће стране остављено је за суђење пред већим судом, које је више пута одлагано. У сваком случају, то је питање калифорнијског уговорног права, тако да не обавезује ништа у Холандији; оно што би променило је број људи који могу да се жале.

Како би холандски суд приступио томе. Као повреда ауторских права према Auteurswet-у: тужилац доказује власништво и репродукцију или саопштавање; тужени покреће питање лиценце; тужилац одговара да његови услови нису били испуњени, тако да одбрана не успева. Уговорни правни лекови према члану 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 Закона о сајбер безбедности примењују се од 11. септембра 2026. године; одредбе о нотификацији тела за оцењивање усаглашености од 11. јуна 2026. године; Уредба у целости од 11. децембра 2027. године (члан 71 Закона о сајбер безбедности). Анекс I Закона о сајбер безбедности захтева од произвођача да идентификују и документују компоненте у производу, укључујући и израду софтверског списка материјала у уобичајено коришћеном и машински читљивом формату који покрива барем зависности највишег нивоа. Није потребно објављивање; органи за надзор тржишта могу то захтевати.

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

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

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

Компанија која објављује код и прихвата спољне доприносе мора знати да има права на оно што спаја. Уговор о лиценци сарадника је уговор између пројекта и сарадника, којим се обично даје широка лиценца за ауторска права и изричита лиценца за патент, са гаранцијама у погледу оригиналности и ауторитета. То је оно што омогућава компанији да касније поново лиценцира свој пројекат или да понуди комерцијалне лиценце поред лиценце отвореног кода. Његова цена је трење.

Сертификат о пореклу програмера , који користи Линуксово језгро и многи други пројекти, није лиценца, већ једноставна потврда, додата као линија потписивања сваком комиту, да сарадник може да пошаље код под лиценцом пројекта. Мање оптерећујуће и мање заштитно: нема патентне лиценце, нема поновног лиценцирања.

Ако је двоструко лиценцирање или будуће ослањање на лиценцу могуће, користите CLA; ако је пројекат стварно заједничко добро, DCO је обично довољан. У сваком случају, уверите се да ваши уговори о раду и извођачи радова додељују ауторска права на код који ваши људи пишу.

Практична контролна листа политика

• Генеришите инвентар компоненти по производу и објавите га у процесу израде, а не ручно.
• Објавите интерну политику: листу дозвољеног, листу забрањеног и поступак одобравања за све остало.
• Писано дефинишите шта се рачуна као дистрибуција — локалне инсталације, уређаји, контејнери, SDK-ови, мобилне апликације, фирмвер.
• Пошаљите генерисану датотеку атрибуције уз сваки производ.
• Одобравајте избор лиценци у време дизајнирања, када је компонента одабрана, а не приликом објављивања.
• Одлучите да ли је за доприносе екстерним пројектима потребно одобрење, с обзиром на укључене патентне доделе, и изаберите CLA или DCO пре првог екстерног доприноса.
• Ускладите гаранције за интелектуалну својину, обештећења и услове депозита са отвореним кодом који се заправо налази у производу.
• Прегледајте пре процеса прикупљања средстава или продаје, а не током њега.

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