Mga lisensya ng open source software sa ilalim ng batas ng Dutch at EU

Halos bawat komersyal na produkto ng software ay naglalaman ng mga open source na bahagi, kadalasan ay daan-daan, na pinipili ng mga developer kaysa sa mga abogado. Nagiging problema ito kapag walang makapagsasabi kung aling mga lisensya ang naaangkop, kung ano ang mga kinakailangan ng mga ito, at kung sumusunod ang produkto. Ipinapaliwanag ng artikulong ito kung paano gumagana ang mga open source na lisensya sa ilalim ng batas ng Dutch at EU, kung saan nakasalalay ang panganib, at kung ano ang dapat ipatupad.

Ano ang isang open source license, sa legal na termino

Ang isang open source na lisensya ay isang lisensya sa karapatang-ari na ipinagkakaloob na napapailalim sa mga kundisyon. Hindi ito isang pagtalikod, hindi isang pag-aalay sa pampublikong dominyo, hindi isang pag-abandona sa mga karapatan, at sa bagay na iyon, gumagana ito tulad ng anumang iba pang lisensya sa software sa ilalim ng batas ng Dutch . Ang may-akda ay nagpapanatili ng karapatang-ari sa ilalim ng art. 1 Aw at art. 10 Aw, na nagpoprotekta sa mga programa sa computer bilang mga gawa, at pinahihintulutan ng lisensya ang mga kilos na kung hindi man ay lalabag sa mga eksklusibong karapatan sa ilalim ng art. 12 Aw at art. 13 Aw.

Mas mahalaga ang kahihinatnan kaysa sa kahulugan. Sumunod, at ang iyong pagkopya at pamamahagi ay naaayon sa batas. Kung hindi ka susunod, hindi sakop ng pahintulot ang iyong ginawa: ang iyong paggamit ay paglabag sa copyright, hindi paglabag sa kontrata. Karamihan sa mga lisensya ng copyleft ay nagpapatibay dito sa pamamagitan ng awtomatikong pagtatapos sa paglabag — GPLv2 nang walang anumang panahon ng paggaling, habang ang GPLv3 at AGPLv3 ay nagpapanumbalik ng mga karapatan kung ang paglabag ay naayos sa loob ng isang tinukoy na panahon pagkatapos ng abiso.

Inilapat ng mga korteng Dutch ang pangangatwirang ito. Sa Rb. Amsterdam Noong ika-22 ng Setyembre 2020, ECLI:NL:RBAMS:2020:4717, isang distributor na nag-alis ng teksto ng lisensya at abiso ng karapatang-ari mula sa isang forked codebase ay pinasiyahan na nawalan ng pahintulot at lumalabag. Ang pagdaragdag ng malaking dami ng bagong code ay hindi lumikha ng isang independiyenteng akda: ang orihinal ay nanatiling nakikilalang naroroon, kaya ang mga obligasyon ay kasama nito.

Ang dalawang pamilya: mapagpahintulot at copyleft

Ang mga lisensyang permisive — MIT, ang mga lisensya ng BSD, Apache 2.0 — ay nagpapahintulot sa paggamit, pagbabago at muling pamamahagi, kabilang ang mga produktong nasa loob ng closed-source, basta't pinapanatili mo ang mga abiso sa copyright at teksto ng lisensya.

Kinakailangan ng mga lisensya ng Copyleft na kapag ipinamahagi mo ang software, o isang bagay na binuo dito, gawin mo ito sa ilalim ng parehong lisensya at gawing magagamit ang kaukulang mapagkukunan. Magkakaiba sila sa abot.

Ang trigger ng copyleft at ang tanong sa pag-link

Ang mga obligasyon ng copyleft ay nangunguna sa pamamahagi, hindi sa paggamit. Ang isang kumpanyang nagpapatakbo ng GPL software sa loob ng kumpanya, gaano man kalaki ang pagbabago, ay walang ipinamamahagi at walang utang. "Naipamahagi na ba natin?" ang palaging unang tanong, at ito ang dahilan kung bakit mas mahalaga ang mga container, appliances, firmware at SDK kaysa sa internal tooling.

Mas mahirap ang pangalawang tanong. Binanggit ng GPL ang isang "akda batay sa Programa", na hiniram ang konsepto ng Amerika ng isang hinangong akda. Walang ganitong termino ang batas ng Olandes: ang pagsusuri ay sumasaklaw sa mga karapatan sa reproduksyon at adaptasyon, na nagtatanong kung ang protektadong ekspresyon mula sa orihinal ay narekober na.

Ang praktikal na kaso ay ang pag-uugnay. Kung ang pag-uugnay ng isang proprietary module sa isang GPL library ay lumilikha ng isang gawang napapailalim sa copyleft ay hindi pa napagpasyahan ng korte ng Netherlands, at walang umiiral na awtoridad ng EU. Ang pananaw ng Free Software Foundation na ang pag-uugnay ay lumilikha ng isang pinagsamang gawa ay interpretasyon ng license steward, hindi batas, at ang kabaligtaran na pananaw ay hindi pa nasusubukan. Ang paboritong sagot sa internet — ligtas ang dynamic linking, hindi ang static linking — ay walang batayan sa batas ng copyright ng Dutch, na hindi nagtatanong kung paano kumikilos ang isang compiler. Ang isang mas maipagtatanggol na pagsusuri ay nagtatanong kung gaano kalapit ang pagsasama ng mga bahagi: nagbabahagi ba sila ng isang address space at mga istruktura ng data, ang kombinasyon ba ay ipinapadala bilang isang produkto, maaaring gumana nang mag-isa, ang proprietary side ba ay nagre-reproduce ng mga header, macro o inline code mula sa copyleft side? Ang mga tanong na iyon ay karaniwang lumulutas sa panganib. Kung hindi, ihihiwalay ang bahagi sa likod ng isang hangganan ng proseso, papalitan ito, o kukuha ng komersyal na lisensya.

AGPL at paggamit ng network

Umiiral ang AGPL dahil ang copyleft ay nati-trigger ng distribution at ang mga SaaS provider ay hindi namamahagi. Ayon sa network clause nito, kung babaguhin mo ang software at gagawin itong available sa mga user na nakikipag-ugnayan dito nang malayuan, ialok mo sa kanila ang kaukulang source ng iyong binagong bersyon.

Tatlong punto ang karaniwang nakakaligtaan. Ang obligasyon ay para sa mga gumagamit ng serbisyo, na sa isang open-signup na produkto ay hindi gaanong nakakagaan ng loob. Ito ay nati-trigger ng pagbabago, kaya ang isang hindi nabagong bahagi ay hindi ito kinakabit ngunit maaaring kinakabit ng isang patched build. At nagtataas ito ng parehong tanong tungkol sa pinagsamang trabaho gaya ng GPL para sa iba pang bahagi ng iyong stack — kaya naman maraming kumpanya ang nagbabawal sa AGPL sa production code.

Pagkakatugma ng lisensya

Ang compatibility ay ang problema ng pagsasama-sama ng mga bahagi na ang mga lisensya ay nagpapataw ng mga obligasyon na hindi maaaring matugunan sa parehong distribusyon: ang mga permissive license ay tugma sa halos lahat ng bagay, ang mga copyleft license ay tugma lamang sa kung ano ang pinahihintulutan ng kanilang sariling mga tuntunin. Ang karaniwang kaso ay ang Apache 2.0 at GPLv2. Sumasang-ayon ang Apache Software Foundation at ang Free Software Foundation na ang kombinasyon ay hindi pinahihintulutan, dahil ang mga probisyon sa pagtatapos ng patente at pagbabayad-pinsala ng Apache 2.0 ay mga karagdagang paghihigpit na hindi pinahihintulutan ng GPLv2. Ang GPLv3 ay binuo upang tanggapin ang mga ito. Ang compatibility ay direksiyonal din: Ang Apache code ay maaaring maisama sa isang proyekto ng GPLv3, ngunit hindi ang kabaligtaran. Ang isang bahagi ng GPL sa maling lugar ay maaaring pumili sa pagitan ng muling paglilisensya, muling pag-engineer o pag-alis — mas mura bago ang paglabas kaysa pagkatapos.

Mga obligasyon sa pagpapakilala at paunawa

Ang mga obligasyong pinakamadalas na nilalabag ay ang hindi gaanong kapansin-pansin: ang pagkopya ng mga abiso sa copyright, mga teksto ng lisensya, mga disclaimer at, sa ilalim ng Apache 2.0, mga nilalaman ng NOTICE sa mga materyales na kasama ng distribusyon. Ipinapataw ang mga ito ng bawat pamilya, kasama ang MIT at BSD. Nilalabag ang mga ito dahil walang nagmamay-ari ng mga ito, at pinakamadaling ayusin — kadalasan ay isang nabuong attribution file na ipinadala kasama ng produkto. Ang kaso ng mga Dutch sa itaas ang siyang eksaktong nagbigay-daan sa pagkabigong ito.

Mga pagbibigay ng patente at paghihiganti ng patente

Walang sinasabi ang MIT at BSD tungkol sa mga patente, at hindi pa napag-uusapan kung ang isang lisensya ng patente ay maaaring ipahiwatig. Nagdagdag ang Apache 2.0 ng isang hayagang, royalty-free na lisensya ng patente mula sa bawat kontribyutor, na may kasamang isang sugnay na paghihiganti: magsampa ng litigasyon sa patente na nagsasabing lumalabag ang gawa at nagtatapos ang iyong lisensya ng patente. Naglalaman ang GPLv3 ng isang maihahambing na grant at sarili nitong mga probisyon sa patente.

Dalawang implikasyon para sa mga kumpanyang may mga portfolio ng patent. Kung ang iyong mga inhinyero ay nag-aambag sa mga proyektong may lisensyang Apache o GPLv3, nagbibigay ka ng mga lisensya sa ilalim ng iyong sariling mga patente. At kung sakaling mag-angkin ka ng mga patente laban sa isang kumpanya depende sa parehong mga bahaging may lisensyang Apache na iyong ginagamit, ang paghihiganti ay maaaring magdulot sa iyo ng pagkawala ng lisensyang iyong inaasahan.

Ang EUPL at ang pampublikong sektor ng Netherlands

Ang bersyon 1.2 ng Lisensyang Pampubliko ng Unyong Europeo, na inaprubahan ng Komisyon sa Europa sa pamamagitan ng desisyon sa pagpapatupad noong Mayo 2017, ay isang lisensyang copyleft na inaprubahan ng OSI na may tatlong natatanging katangian.

• Wika. Ito ay umiiral sa mga opisyal na wika ng EU, lahat ng aprubadong bersyon ay may magkaparehong halaga, kaya ang isang awtoridad ng Olandes ay maaaring makipagkontrata sa wikang Olandes.
• Kakayahan. Isang apendiks ang naglilista ng mga katugmang lisensya — kasama na ang GPLv2 at v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL at CeCILL — at nagpapahintulot sa isang hinangong akda na pinagsasama ang EUPL code at code sa ilalim ng isang nakalistang lisensya na ipamahagi sa ilalim ng lisensyang iyon.
• Abutin Saklaw ng kahulugan nito ng pamamahagi ang paggawa ng mga akda na makukuha online o offline o pagbibigay ng access sa mga mahahalagang functionality nito, at art. 5 Dinadala ng EUPL ang obligasyon ng copyleft hanggang sa malayuang pakikipag-ugnayan kung saan inaalok ang parehong functionality. Samakatuwid, naaabot nito ang software na inihahatid bilang isang serbisyo, sa paraang hindi naaabot ng GPL.

Maaaring kailanganin ng isang kostumer ng pampublikong sektor na Dutch ang EUPL bilang isang patakaran sa halip na batas. Ang Interoperable Europe Act, Regulation (EU) 2024/903, ay nag-uutos sa mga katawan ng pampublikong sektor na unahin ang mga solusyon sa interoperability nang walang mahigpit na mga tuntunin sa paglilisensya, tulad ng open source, kung saan katumbas nito; sa buong bansa, ang prinsipyo ng open source, tenzij, ay nakasalalay sa mga desisyon ng gabinete at mga linya ng patakaran, hindi sa batas: ang Wet digitale overheid ay nagpapadali sa imprastraktura ng digital identity ngunit hindi nagpapataw ng anumang maipapatupad na obligasyon na i-publish ang lahat ng source code. Basahin ang mga dokumento ng tender: ang isang kinakailangan sa EUPL ay nagbibigkis sa iyong deliverable at maaaring hindi tugma sa proprietary code na balak mong gamitin muli.

Pagpapatupad sa pagsasagawa

Sino ang maaaring magsampa ng kaso. Ang may-ari ng karapatan — mga indibidwal na kontribyutor, o ang pundasyon o kumpanyang may hawak ng itinalagang karapatang-ari. Ang pira-pirasong pag-akda ang praktikal na preno: dapat patunayan ng isang naghahabol ang pagmamay-ari ng pinag-uusapang code. Natalo nito ang pinakakilalang kaso ng European GPL, kung saan nabigo ang paghahabol ng isang kernel developer laban sa isang virtualisation vendor dahil sa kakulangan ng patunay ng pag-akda (LG Hamburg 8 Hulyo 2016, 310 O 89/15; pinagtibay OLG Hamburg 28 Pebrero 2019, 5 U 146/16).

Ang itinatatag ng batas. Paulit-ulit na tinatanggap ng mga korte ng Alemanya na ang mga lisensyang open source ay balido at ang paglabag ay ginagawang labag sa batas ang pamamahagi, simula sa unang utos ng GPL (LG München I noong Mayo 19, 2004, 21 O 6123/04). Naabot ng US Federal Circuit ang parehong konklusyon sa Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008): ang mga termino ng lisensya ay mga kondisyon sa saklaw ng grant, hindi lamang mga tipan, kaya sinusuportahan ng paglabag ang isang paghahabol sa copyright at injunctive relief. Sinusuri ng litigasyon ng Estados Unidos kung maaaring ipatupad ng isang tatanggap sa ibaba ang GPL bilang third-party beneficiary. Iyan ang pangunahing tanong sa Software Freedom Conservancy v Vizio sa harap ng Superior Court ng California: kung ang mga mamimili, bilang mga third-party beneficiary, ay maaaring humiling ng pagpapalabas ng source code sa ilalim ng GPLv2. Noong ika-23 ng Disyembre 2025, nagpasya ang korte ng isang punto sa summary adjudication, na nagsasabing ang GPLv2 at LGPLv2.1 ay nangangailangan ng source na maaaring makuha at baguhin para magamit sa ibang lugar sa halip na source na maaaring muling i-install sa device nang buo ang functionality nito. Ang mismong tanong tungkol sa third-party beneficiary ay naiwan para sa bench trial, na ipinagpaliban nang higit sa isang beses. Ito ay isang tanong tungkol sa batas ng kontrata sa California sa anumang pagkakataon, kaya wala itong kinalaman sa Netherlands; ang mababago nito ay ang bilang ng mga taong maaaring magreklamo.

Paano ito lalapitan ng isang korte ng Netherlands. Bilang paglabag sa karapatang-ari sa ilalim ng Auteurswet: pinatutunayan ng nagsasakdal ang pagmamay-ari at pagpaparami o komunikasyon; itinaas ng nasasakdal ang lisensya; sinagot ng nagsasakdal na hindi natugunan ang mga kundisyon nito, kaya nabigo ang depensa. Ang mga kontratwal na remedyo sa ilalim ng art. 6:265 BW ay tumatakbo nang magkasabay, ngunit ang karapatang-ari ang mas malakas na ruta.

Mga Remedyo. Isang utos na nagbabawal sa ilalim ng art. 3:296 BW, karaniwang may kasamang multa at makukuha sa mga buod na paglilitis; mga danyos sa ilalim ng art. 27 Aw at isang ulat ng mga kita sa ilalim ng art. 27a Aw; pagbawi, pagsuko o pagsira sa ilalim ng art. 28 Aw; at ganap na pagbawi ng makatwiran at proporsyonal na mga legal na gastos sa ilalim ng art. 1019h Rv. Kung saan ang software ay ipinamahagi nang libre, ang pagkawala ay mahirap sukatin, at ang isang korte ng apela sa Alemanya ay tumanggi na maggawad ng mga danyos habang pinapanatili ang utos na nagbabawal (OLG Hamm 13 Hunyo 2017, 4 U 72/16). Ang nakakagat ay bihirang mga danyos: ito ay ang utos na nagbabawal, ang pagbawi, ang utos ng mga gastos, at ang kinakailangang maglathala ng pinagmulan na hindi mo naman talaga nilalayong ilathala.

Kapag nakatuklas ka ng problema sa pagsunod

Karaniwang nagmumula ang pagtuklas sa security questionnaire ng customer, isang scan habang isinasagawa ang due diligence, o isang liham mula sa isang rightholder. Ang remediation ay isinasagawa ayon sa sumusunod. Itigil ang pamamahagi ng apektadong build kung malala ang exposure. Tukuyin kung aling component, aling bersyon, aling lisensya, aling mga produkto at release, at sa anong tagal ng panahon. Alamin kung ano talaga ang hinihingi ng lisensya — kadalasan ay isang attribution file sa halip na isang source release. Ihanda ang mga artifact: mga abiso, mga teksto ng lisensya, kumpletuhin ang kaukulang source kasama ang mga build script, at isang nakasulat na alok kung saan ginamit. Magpadala ng compliant release, pagkatapos ay sabihin sa rightholder kung ano ang iyong ginawa sa halip na makipagtalo kung kinailangan mo bang gawin iyon.

Sa ilalim ng GPLv3 at AGPLv3, ang cure window ay nagbibigay ng legal na halaga para sa bilis; sa ilalim ng GPLv2, walang karapatan sa cure, kaya naman ang karamihan sa pagpapatupad ay nagtatapos sa isang napagkasunduang pagsasagawa ng pagsunod. Tandaan din na ang pribilehiyo ay kalakip ng payo mula sa iyong abogado, hindi sa isang internal engineering report.

Open source sa M&A at due diligence

Sa isang pagkuha ng software, ang open source ay isang karaniwang workstream ng diligence, at ang isang hindi isiniwalat na bahagi ng copyleft sa pangunahing produkto ay isa sa ilang mga natuklasan na tunay na nagpapabago sa isang kasunduan: kung ang produkto ay hindi maaaring ipamahagi nang hindi inilalabas ang pinagmulan nito, ang mamimili ay nakakakuha ng ibang asset mula sa isang naka-presyo.

Asahan ang isang codebase scan, isang imbentaryo ng mga bahagi na may mga lisensya, at mga tanong tungkol sa mga kaayusan ng kontribyutor at kontratista. Ang karaniwang mga resulta ay isang partikular na bayad-pinsala, isang pagpapanatili habang nakabinbin ang remediation, isang kundisyong nauna nang nangangailangan ng pag-alis, o isang bespoke open source warranty. Dapat munang i-scan ng mga nagbebenta: ang mga natuklasang isiniwalat mo ay isang negosasyon, ang mga natuklasang ginawa ng tagapayo ng mamimili ay isang leverage. Hindi dapat hanapin ng mga mamimili ang "pagmamay-ari ng kumpanya ang IP nito" kundi isang representasyon na walang produktong nagsasama ng open source na nangangailangan ng pagsisiwalat ng proprietary source code.

Ang bill of materials, scanning at ang Cyber ​​Resilience Act

Ang isang software bill of materials ay isang imbentaryo ng mga bahagi ng isang produkto, kasama ang mga bersyon at lisensya. Hanggang kamakailan lamang ay purong kontrata lamang, ngayon ay isa na rin itong regulatory.

Ang Cyber ​​Resilience Act, Regulation (EU) 2024/2847, ay nagkabisa noong ika-10 ng Disyembre 2024 at unti-unting isinasabatas. Kasabay ito ng Dutch Cybersecurity Act , na tumutugon sa organisasyon sa halip na sa produkto. Ang mga obligasyon sa pag-uulat para sa mga aktibong sinasamantalang kahinaan at malalang insidente sa art. 14 CRA ay nalalapat mula ika-11 ng Setyembre 2026; ang mga probisyon sa abiso ng mga conformity assessment bodies mula ika-11 ng Hunyo 2026; ang buong Regulasyon mula ika-11 ng Disyembre 2027 (art. 71 CRA). Hinihiling ng Annex I CRA sa mga tagagawa na tukuyin at idokumento ang mga bahagi sa produkto, kabilang ang paggawa ng isang software bill of materials sa isang karaniwang ginagamit at machine-readable na format na sumasaklaw kahit man lang sa mga top-level dependencies. Hindi na ito kailangang i-publish; maaaring hilingin ito ng mga awtoridad sa market surveillance.

Ang libre at open source na software na ibinibigay sa labas ng isang komersyal na aktibidad ay nasa labas ng CRA. Ipinakikilala ng Regulasyon ang open-source software steward — isang legal na tao na nagbibigay ng patuloy na suporta sa pagbuo ng open source software na inilaan para sa mga komersyal na aktibidad — na may mas magaan na obligasyon sa art. 24 CRA: isang dokumentadong patakaran sa cybersecurity, kooperasyon sa mga awtoridad sa pagsubaybay sa merkado, at pag-uulat. Kung ikaw ay nagkokomersyalisa ng open source, o nagpopondo sa isang proyektong kinokomersyalisa ng iba, itakda kung aling tungkulin ang iyong gagampanan. Pinagtibay ng Komisyon ang unang gabay nito noong Hulyo 27, 2026: ang gabay ng Komisyon sa aplikasyon ng Cyber ​​Resilience Act (CRA), na nakalakip sa komunikasyon C(2026) 5252, na tumutugon sa iba pang mga bagay kapag ang libre at open source na software ay nasa loob ng saklaw. Walang batas sa pagpapatupad na nagtatakda ng isang format para sa software bill of materials ang pinagtibay, kaya ang sariling pamantayan ng Regulasyon — isang karaniwang ginagamit, machine-readable na format — ay nananatiling sukatan sa ngayon.

Ang pagsusuri ng komposisyon ng software na isinasagawa sa CI ay bumubuo ng imbentaryo na nagsisilbi sa pagsunod, pagsusuri ng lisensya, at kasipagan nang sabay-sabay. Hindi napapansin ng mga naturang tool ang vendored code, mali ang pagtukoy sa mga proyektong may dalawang lisensya, at hindi nababasa ang mga kondisyon ng lisensya: ituring ang output bilang simula ng pagsusuri, hindi ang pagsusuri.

Kung ilalathala mo ang sarili mong code: Mga CLA at ang DCO

Dapat malaman ng isang kumpanyang naglalabas ng code at tumatanggap ng mga kontribusyon mula sa labas na mayroon itong mga karapatan sa kung ano ang pinagsasama nito. Ang kasunduan sa lisensya ng kontribyutor ay isang kontrata sa pagitan ng proyekto at kontribyutor, na karaniwang nagbibigay ng malawak na lisensya sa copyright at isang express patent license, na may mga garantiya tungkol sa orihinalidad at awtoridad. Ito ang nagpapahintulot sa isang kumpanya na muling maglisensya sa proyekto nito sa ibang pagkakataon, o mag-alok ng mga komersyal na lisensya kasama ng isang open source. Ang gastos nito ay alitan.

Ang Developer Certificate of Origin , na ginagamit ng Linux kernel at marami pang ibang proyekto, ay hindi isang pagbibigay ng lisensya kundi isang magaan na pagpapatunay, na idinaragdag bilang isang linya ng pagpirma sa bawat commit, na maaaring isumite ng kontribyutor ang code sa ilalim ng lisensya ng proyekto. Hindi gaanong mabigat, at hindi gaanong proteksiyon: walang lisensya ng patente, walang muling paglilisensya.

Kung posible ang dual licensing o ang relicence sa hinaharap, gumamit ng CLA; kung ang proyekto ay isang genuine commons, karaniwang sapat na ang DCO. Alinman sa dalawa, siguraduhing ang iyong mga kasunduan sa trabaho at kontratista ay nagtatalaga ng copyright sa code na isinusulat ng iyong mga tao.

Isang praktikal na checklist ng patakaran

• Gumawa ng imbentaryo ng mga bahagi para sa bawat produkto at ilabas ito sa pipeline ng pagbuo, hindi sa pamamagitan ng kamay.
• Maglathala ng panloob na patakaran: isang pinahihintulutang listahan, isang ipinagbabawal na listahan at isang ruta ng pag-apruba para sa lahat ng iba pa.
• Tukuyin nang nakasulat kung ano ang maituturing na distribusyon — mga on-premise na pag-install, appliances, container, SDK, mobile app, firmware.
• Magpadala ng nabuong attribution file kasama ng bawat produkto.
• Aprubahan ang mga pagpipilian sa lisensya sa oras ng disenyo, kapag napili na ang isang bahagi, hindi sa paglabas.
• Magpasya kung ang mga kontribusyon sa mga panlabas na proyekto ay nangangailangan ng pag-apruba, batay sa mga kasangkot na grant para sa patent, at pumili ng CLA o DCO bago ang unang kontribusyon mula sa labas.
• Iayon ang mga IP warranty, indemnities, at mga tuntunin ng escrow sa open source na aktwal na nasa produkto.
• Patakbuhin ang pagsusuri bago ang isang proseso ng pangangalap ng pondo o pagbebenta, hindi habang isinasagawa ang proseso.

Law & More nagpapayo sa mga kompanya ng software at sa kanilang mga mamumuhunan mula sa Eindhoven at Amsterdam sa pagsunod sa mga patakaran ng open source, pagsusuri ng lisensya, mga kaayusan ng kontribyutor at ang open source workstream sa isang transaksyon.