ใบอนุญาตซอฟต์แวร์โอเพนซอร์สภายใต้กฎหมายของเนเธอร์แลนด์และสหภาพยุโรป

ซอฟต์แวร์เชิงพาณิชย์เกือบทุกตัวมีส่วนประกอบโอเพนซอร์สอยู่เป็นจำนวนมาก โดยปกติแล้วจะเป็นหลายร้อยชิ้น ซึ่งนักพัฒนาเป็นผู้เลือกส่วนประกอบเหล่านั้น ไม่ใช่นักกฎหมาย นี่จึงกลายเป็นปัญหาเมื่อไม่มีใครสามารถระบุได้ว่าใบอนุญาตใดบ้างที่ใช้บังคับ ข้อกำหนดเป็นอย่างไร และผลิตภัณฑ์นั้นเป็นไปตามข้อกำหนดหรือไม่ บทความนี้จะอธิบายว่าใบอนุญาตโอเพนซอร์สทำงานอย่างไรภายใต้กฎหมายของเนเธอร์แลนด์และสหภาพยุโรป ความเสี่ยงอยู่ที่ใด และควรมีมาตรการอะไรบ้าง

ในทางกฎหมายแล้ว ใบอนุญาตโอเพนซอร์สคืออะไร

ใบอนุญาตโอเพนซอร์สเป็นใบอนุญาตลิขสิทธิ์ที่มอบให้ภายใต้เงื่อนไข ไม่ใช่การสละสิทธิ์ ไม่ใช่การอุทิศให้แก่สาธารณสมบัติ ไม่ใช่การละทิ้งสิทธิ์ และในแง่นั้นจึงทำงานเหมือนกับใบอนุญาตซอฟต์แวร์อื่นๆ ภายใต้กฎหมายของเนเธอร์แลนด์ผู้แต่งยังคงรักษาสิทธิ์ในลิขสิทธิ์ภายใต้มาตรา 1 และมาตรา 10 ของกฎหมายว่าด้วยลิขสิทธิ์ของเนเธอร์แลนด์ ซึ่งคุ้มครองโปรแกรมคอมพิวเตอร์ในฐานะงาน และใบอนุญาตนี้อนุญาตให้กระทำการใดๆ ที่อาจละเมิดสิทธิ์แต่เพียงผู้เดียวภายใต้มาตรา 12 และมาตรา 13 ของกฎหมายว่าด้วยลิขสิทธิ์ของเนเธอร์แลนด์ได้

ผลที่ตามมาสำคัญกว่าคำจำกัดความ หากปฏิบัติตาม การคัดลอกและการเผยแพร่ของคุณก็ถูกต้องตามกฎหมาย หากไม่ปฏิบัติตาม การอนุญาตจะไม่ครอบคลุมสิ่งที่คุณทำ การใช้งานของคุณถือเป็นการละเมิดลิขสิทธิ์ ไม่ใช่การผิดสัญญา สัญญาอนุญาตแบบ Copyleft ส่วนใหญ่เน้นย้ำเรื่องนี้โดยการยุติสัญญาโดยอัตโนมัติเมื่อมีการละเมิด — GPLv2 โดยไม่มีระยะเวลาแก้ไข ในขณะที่ GPLv3 และ AGPLv3 จะคืนสิทธิ์หากแก้ไขการละเมิดภายในระยะเวลาที่กำหนดหลังจากได้รับแจ้ง

ศาลดัตช์ใช้เหตุผลนี้ ในคดี Rb. Amsterdam เมื่อวันที่ 22 กันยายน 2020 คดี ECLI:NL:RBAMS:2020:4717 ผู้จัดจำหน่ายที่ลบข้อความอนุญาตและประกาศลิขสิทธิ์ออกจากโค้ดเบสที่แยกออกมา ถูกตัดสินว่าสูญเสียสิทธิ์และละเมิดลิขสิทธิ์ การเพิ่มโค้ดใหม่จำนวนมากไม่ได้สร้างงานอิสระ: งานต้นฉบับยังคงอยู่และสามารถจดจำได้ ดังนั้นภาระผูกพันจึงยังคงอยู่กับงานต้นฉบับด้วย

สองครอบครัว: ครอบครัวที่อนุญาตให้ใช้ลิขสิทธิ์และครอบครัวที่อนุญาตให้ใช้ลิขสิทธิ์แบบเปิด

ใบอนุญาตแบบเปิดกว้างเช่น ใบอนุญาต MIT, ใบอนุญาต BSD, Apache 2.0 อนุญาตให้ใช้งาน ดัดแปลง และแจกจ่ายต่อได้ รวมถึงภายในผลิตภัณฑ์โอเพนซอร์ส โดยมีเงื่อนไขว่าต้องคงไว้ซึ่งประกาศลิขสิทธิ์และข้อความใบอนุญาต

สัญญาอนุญาตแบบ Copyleftกำหนดว่า เมื่อคุณเผยแพร่ซอฟต์แวร์ หรือสิ่งใดก็ตามที่สร้างขึ้นจากซอฟต์แวร์นั้น คุณต้องทำภายใต้สัญญาอนุญาตเดียวกัน และต้องเปิดเผยซอร์สโค้ดที่เกี่ยวข้องด้วย สัญญาอนุญาตทั้งสองแบบแตกต่างกันในขอบเขตการใช้งาน

กลไกการทำงานของลิขสิทธิ์แบบ Copyleft และคำถามเกี่ยวกับการเชื่อมโยง

ข้อผูกพันตามลิขสิทธิ์แบบ Copyleft มีผลเฉพาะกับการเผยแพร่ ไม่ใช่การใช้งาน บริษัทที่ใช้ซอฟต์แวร์ GPL ภายในองค์กร แม้จะมีการดัดแปลงอย่างมาก ก็ไม่ได้เผยแพร่สิ่งใดและไม่มีภาระผูกพันใดๆ คำถามแรกเสมอคือ “เราได้เผยแพร่ไปแล้วหรือยัง?” และนี่คือเหตุผลว่าทำไมคอนเทนเนอร์ อุปกรณ์ เฟิร์มแวร์ และ SDK จึงมีความสำคัญมากกว่าเครื่องมือภายในองค์กร

คำถามข้อที่สองยากกว่า GPL กล่าวถึง “งานที่อิงจากโปรแกรม” โดยยืมแนวคิดเรื่องงานดัดแปลงจากอเมริกา กฎหมายดัตช์ไม่มีคำดังกล่าว การวิเคราะห์จึงต้องพิจารณาจากสิทธิ์ในการทำซ้ำและการดัดแปลง โดยถามว่ามีการทำซ้ำการแสดงออกที่ได้รับการคุ้มครองจากต้นฉบับหรือไม่

กรณีในทางปฏิบัติคือการเชื่อมโยง ศาลดัตช์ยังไม่เคยตัดสินว่าการเชื่อมโยงโมดูลที่เป็นกรรมสิทธิ์กับไลบรารี GPL จะสร้างงานชิ้นเดียวที่อยู่ภายใต้ copyleft หรือไม่ และไม่มีหน่วยงานของสหภาพยุโรปที่มีผลผูกพัน มุมมองของมูลนิธิซอฟต์แวร์เสรีที่ว่าการเชื่อมโยงสร้างงานรวมกันนั้นเป็นเพียงการตีความของผู้ดูแลลิขสิทธิ์ ไม่ใช่กฎหมาย และมุมมองที่ตรงกันข้ามก็ยังไม่ได้รับการทดสอบเช่นกัน คำตอบที่ได้รับความนิยมบนอินเทอร์เน็ต — การเชื่อมโยงแบบไดนามิกปลอดภัย การเชื่อมโยงแบบคงที่ไม่ปลอดภัย — ไม่มีพื้นฐานในกฎหมายลิขสิทธิ์ของเนเธอร์แลนด์ ซึ่งไม่ได้ถามว่าคอมไพเลอร์ทำงานอย่างไร การวิเคราะห์ที่สมเหตุสมผลกว่านั้นถามว่าส่วนประกอบต่างๆ รวมกันอย่างใกล้ชิดเพียงใด: พวกมันใช้พื้นที่แอดเดรสและโครงสร้างข้อมูลร่วมกันหรือไม่ การรวมกันนั้นถูกส่งเป็นผลิตภัณฑ์เดียวหรือไม่ แต่ละส่วนสามารถทำงานได้โดยลำพังหรือไม่ ฝั่งที่เป็นกรรมสิทธิ์สร้างส่วนหัว มาโคร หรือโค้ดแบบอินไลน์จากฝั่ง copyleft หรือไม่ คำถามเหล่านั้นมักจะช่วยคลี่คลายความเสี่ยง หากไม่ได้ผล ให้แยกส่วนประกอบนั้นไว้หลังขอบเขตกระบวนการ เปลี่ยนส่วนประกอบนั้น หรือขอใบอนุญาตเชิงพาณิชย์

AGPL และการใช้งานเครือข่าย

AGPL มีอยู่เพราะลิขสิทธิ์แบบ copyleft จะทำงานเมื่อมีการเผยแพร่ และผู้ให้บริการ SaaS ไม่ได้เผยแพร่ซอฟต์แวร์ ข้อกำหนดด้านเครือข่ายของ AGPL ระบุว่า หากคุณแก้ไขซอฟต์แวร์และทำให้ผู้ใช้ที่ใช้งานจากระยะไกลสามารถเข้าถึงได้ คุณต้องเสนอซอร์สโค้ดของเวอร์ชันที่แก้ไขแล้วให้แก่พวกเขาด้วย

มีสามประเด็นที่มักถูกมองข้ามไป ข้อผูกพันนี้ตกอยู่กับผู้ใช้บริการ ซึ่งในผลิตภัณฑ์ที่เปิดให้ลงทะเบียนใช้งานทั่วไปนั้นแทบจะไม่มีประโยชน์อะไรเลย ข้อผูกพันนี้จะเกิดขึ้นเมื่อมีการแก้ไข ดังนั้นส่วนประกอบที่ไม่ได้รับการแก้ไขจะไม่ทำให้เกิดข้อผูกพันนี้ แต่เวอร์ชันที่ได้รับการแก้ไขแล้วอาจทำให้เกิดข้อผูกพันนี้ได้ และมันยังก่อให้เกิดคำถามเกี่ยวกับการทำงานร่วมกันเช่นเดียวกับ GPL สำหรับส่วนอื่นๆ ของระบบของคุณ ซึ่งเป็นเหตุผลว่าทำไมหลายบริษัทจึงห้ามใช้ AGPL ในโค้ดที่ใช้งานจริง

ความเข้ากันได้ของใบอนุญาต

ความเข้ากันได้เป็นปัญหาของการรวมส่วนประกอบต่างๆ ที่มีข้อกำหนดในใบอนุญาตซึ่งไม่สามารถปฏิบัติตามได้พร้อมกันในเวอร์ชันเดียว: ใบอนุญาตแบบอนุญาต (permissive licences) เข้ากันได้กับเกือบทุกอย่าง ในขณะที่ใบอนุญาตแบบ copyleft เข้ากันได้กับสิ่งที่ข้อกำหนดของตนเองอนุญาตเท่านั้น กรณีมาตรฐานคือ 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 เดียวกันกับคุณ การตอบโต้ดังกล่าวอาจทำให้คุณสูญเสียสิทธิ์การใช้งานที่คุณพึ่งพาอยู่

สหภาพยุโรปและภาครัฐของเนเธอร์แลนด์

ใบอนุญาตสาธารณะของสหภาพยุโรปเวอร์ชัน 1.2 ซึ่งได้รับการอนุมัติจากคณะกรรมาธิการยุโรปโดยมติการดำเนินการในเดือนพฤษภาคม 2017 เป็นใบอนุญาตแบบ copyleft ที่ได้รับการอนุมัติจาก OSI ซึ่งมีคุณลักษณะเด่นสามประการ

• ภาษา. เอกสารนี้มีให้บริการในภาษาทางการของสหภาพยุโรป โดยทุกฉบับที่ได้รับการอนุมัติมีคุณค่าเท่าเทียมกัน ดังนั้นหน่วยงานของเนเธอร์แลนด์จึงสามารถทำสัญญาเป็นภาษาดัตช์ได้
• ความเข้ากันได้ ภาคผนวกแสดงรายการใบอนุญาตที่เข้ากันได้ ได้แก่ GPLv2 และ v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL และ CeCILL และอนุญาตให้เผยแพร่ผลงานดัดแปลงที่รวมโค้ด EUPL กับโค้ดภายใต้ใบอนุญาตที่ระบุไว้ภายใต้ใบอนุญาตดังกล่าว ภายใต้ใบอนุญาตนั้นแทน
• เข้าถึง. นิยามของการเผยแพร่ครอบคลุมถึงการทำให้ผลงานสามารถเข้าถึงได้ทางออนไลน์หรือออฟไลน์ หรือการให้สิทธิ์เข้าถึงฟังก์ชันการทำงานที่จำเป็นและมาตรา 5 ของ EUPL บังคับใช้ข้อผูกพัน copyleft กับการโต้ตอบระยะไกลซึ่งมีฟังก์ชันการทำงานเดียวกันนั้น ดังนั้นจึงครอบคลุมถึงซอฟต์แวร์ที่ให้บริการในรูปแบบบริการ ซึ่งเป็นสิ่งที่ GPL ทำไม่ได้

ลูกค้าภาครัฐของเนเธอร์แลนด์อาจต้องการ EUPL (ใบอนุญาตใช้งานซอฟต์แวร์ของสหภาพยุโรป) ตามนโยบายมากกว่ากฎหมาย พระราชบัญญัติการทำงานร่วมกันของยุโรป (Interoperable Europe Act) ระเบียบ (EU) 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 ไม่มีสิทธิ์ในการแก้ไขข้อผิดพลาด ซึ่งเป็นเหตุผลว่าทำไมการบังคับใช้ส่วนใหญ่จึงจบลงด้วยการเจรจาตกลงปฏิบัติตาม นอกจากนี้ โปรดทราบด้วยว่าสิทธิพิเศษนั้นครอบคลุมถึงคำแนะนำจากทนายความของคุณ ไม่ใช่รายงานทางวิศวกรรมภายใน

โอเพนซอร์สในด้านการควบรวมกิจการและการตรวจสอบสถานะทางธุรกิจ

ในการเข้าซื้อกิจการซอฟต์แวร์ โอเพนซอร์สเป็นขั้นตอนการตรวจสอบวิเคราะห์สถานะมาตรฐาน และส่วนประกอบแบบ copyleft ที่ไม่เปิดเผยในผลิตภัณฑ์หลักเป็นหนึ่งในไม่กี่สิ่งที่สามารถผลักดันให้เกิดการซื้อขายได้จริง ๆ กล่าวคือ หากผลิตภัณฑ์ไม่สามารถเผยแพร่ได้โดยไม่เปิดเผยซอร์สโค้ด ผู้ซื้อจะได้รับสินทรัพย์ที่แตกต่างจากที่ตกลงกันไว้

คาดว่าจะมีการตรวจสอบโค้ดเบส การตรวจสอบส่วนประกอบพร้อมใบอนุญาต และคำถามเกี่ยวกับข้อตกลงกับผู้มีส่วนร่วมและผู้รับเหมา ผลลัพธ์โดยทั่วไปคือการชดเชยเฉพาะเจาะจง การหักเงินประกันไว้จนกว่าจะแก้ไขเสร็จ เงื่อนไขเบื้องต้นที่กำหนดให้ต้องลบออก หรือการรับประกันโอเพนซอร์สที่กำหนดเอง ผู้ขายควรตรวจสอบก่อน: สิ่งที่คุณเปิดเผยคือการเจรจาต่อรอง สิ่งที่ที่ปรึกษาของผู้ซื้อค้นพบคืออำนาจต่อรอง ผู้ซื้อไม่ควรต้องการเพียงแค่ "บริษัทเป็นเจ้าของทรัพย์สินทางปัญญา" แต่ควรต้องการคำรับรองว่าไม่มีผลิตภัณฑ์ใดที่ใช้โอเพนซอร์สซึ่งต้องเปิดเผยซอร์สโค้ดที่เป็นกรรมสิทธิ์

รายการวัสดุ การสแกน และพระราชบัญญัติความยืดหยุ่นทางไซเบอร์

รายการส่วนประกอบซอฟต์แวร์ (Software Bill of Materials หรือ SWITCH) คือรายการส่วนประกอบของผลิตภัณฑ์ พร้อมด้วยเวอร์ชันและใบอนุญาต ก่อนหน้านี้เป็นเพียงข้อกำหนดตามสัญญา แต่ปัจจุบันนี้ได้กลายเป็นข้อกำหนดทางกฎหมายด้วย

พระราชบัญญัติความยืดหยุ่นทางไซเบอร์ (Cyber ​​Resilience Act) ระเบียบ (EU) 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 จะสร้างรายการสินค้าคงคลังที่ตอบสนองความต้องการด้านการปฏิบัติตามกฎระเบียบ การตรวจสอบใบอนุญาต และการตรวจสอบอย่างรอบคอบไปพร้อมกัน เครื่องมือเหล่านี้อาจพลาดโค้ดจากผู้จำหน่ายรายอื่น ระบุโครงการที่มีใบอนุญาตซ้ำซ้อนผิดพลาด และไม่สามารถอ่านเงื่อนไขของใบอนุญาตได้ ดังนั้น ให้ถือว่าผลลัพธ์เป็นจุดเริ่มต้นของการตรวจสอบ ไม่ใช่การตรวจสอบทั้งหมด

หากคุณเผยแพร่โค้ดของคุณเอง: CLA และ DCO

บริษัทที่เผยแพร่โค้ดและรับการมีส่วนร่วมจากภายนอกต้องมั่นใจว่าตนเองมีสิทธิ์ในสิ่งที่นำมาผสานรวมข้อตกลงใบอนุญาตสำหรับผู้มีส่วนร่วมเป็นสัญญาที่ทำขึ้นระหว่างโครงการและผู้มีส่วนร่วม โดยทั่วไปจะให้สิทธิ์ใช้งานลิขสิทธิ์ในวงกว้างและสิทธิ์ใช้งานสิทธิบัตรโดยชัดแจ้ง พร้อมการรับประกันเกี่ยวกับความคิดริเริ่มและความถูกต้อง นี่คือสิ่งที่ทำให้บริษัทสามารถให้ใบอนุญาตโครงการของตนใหม่ได้ในภายหลัง หรือเสนอใบอนุญาตเชิงพาณิชย์ควบคู่ไปกับใบอนุญาตโอเพนซอร์ส ต้นทุนของมันคือความยุ่งยาก

ใบรับรองแหล่งกำเนิดนักพัฒนา (Developer Certificate of Origin)ที่ใช้โดยเคอร์เนลลินุกซ์และโครงการอื่นๆ อีกมากมาย ไม่ใช่การอนุญาตให้ใช้สิทธิ์ แต่เป็นการรับรองอย่างง่ายๆ ที่เพิ่มเข้ามาเป็นบรรทัดลงนามในแต่ละการคอมมิต เพื่อยืนยันว่าผู้มีส่วนร่วมสามารถส่งโค้ดภายใต้ใบอนุญาตของโครงการได้ มีภาระน้อยกว่า และให้การคุ้มครองน้อยกว่า: ไม่มีใบอนุญาตสิทธิบัตร ไม่มีการต่ออายุใบอนุญาต

หากการอนุญาตใช้งานแบบคู่ขนานหรือการอนุญาตใช้งานใหม่ในอนาคตเป็นไปได้ ให้ใช้ CLA; หากโครงการเป็นสาธารณสมบัติอย่างแท้จริง DCO มักจะเพียงพอแล้ว ไม่ว่าในกรณีใด โปรดตรวจสอบให้แน่ใจว่าข้อตกลงการจ้างงานและข้อตกลงผู้รับเหมาของคุณกำหนดลิขสิทธิ์ในโค้ดที่พนักงานของคุณเขียนขึ้น

รายการตรวจสอบนโยบายที่นำไปใช้ได้จริง

• สร้างรายการส่วนประกอบสำหรับแต่ละผลิตภัณฑ์และแต่ละรุ่นในขั้นตอนการสร้าง ไม่ใช่สร้างด้วยตนเอง
• เผยแพร่นโยบายภายในองค์กร: รายการที่อนุญาต รายการสิ่งที่ห้าม และขั้นตอนการอนุมัติสำหรับรายการอื่นๆ ทั้งหมด
• ระบุเป็นลายลักษณ์อักษรว่าอะไรบ้างที่นับเป็นการแจกจ่าย — การติดตั้งบนระบบภายในองค์กร, อุปกรณ์สำเร็จรูป, คอนเทนเนอร์, SDK, แอปพลิเคชันบนมือถือ, เฟิร์มแวร์
• จัดส่งไฟล์ระบุแหล่งที่มาที่สร้างขึ้นโดยอัตโนมัติไปพร้อมกับสินค้าทุกชิ้น
• อนุมัติตัวเลือกใบอนุญาตในขั้นตอนการออกแบบ เมื่อเลือกส่วนประกอบแล้ว ไม่ใช่ในขั้นตอนการเผยแพร่
• พิจารณาว่าการสนับสนุนโครงการภายนอกจำเป็นต้องได้รับการอนุมัติหรือไม่ โดยคำนึงถึงสิทธิบัตรที่เกี่ยวข้อง และเลือกใช้ CLA หรือ DCO ก่อนการสนับสนุนจากภายนอกครั้งแรก
• ปรับเงื่อนไขการรับประกันทรัพย์สินทางปัญญา การชดเชย และเงื่อนไขการฝากเงินให้สอดคล้องกับซอฟต์แวร์โอเพนซอร์สที่มีอยู่ในผลิตภัณฑ์จริง
• ควรทำการตรวจสอบก่อนเริ่มกระบวนการระดมทุนหรือการขาย ไม่ใช่ระหว่างกระบวนการดังกล่าว

Law & More ให้คำแนะนำแก่บริษัทซอฟต์แวร์และนักลงทุนจาก Eindhoven และ Amsterdam เกี่ยวกับการปฏิบัติตามข้อกำหนดโอเพนซอร์ส การตรวจสอบใบอนุญาต ข้อตกลงของผู้มีส่วนร่วม และกระบวนการทำงานโอเพนซอร์สในธุรกรรม