แพตช์เคอร์เนล Linux ที่ทำให้โมดูลแบบ proprietary ใช้งานลำบากยิ่งขึ้น

 (lwn.net)
3 คะแนน โดย GN⁺ 2023-08-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ชุมชนเคอร์เนล Linux ไม่ค่อยต้อนรับ โมดูลเคอร์เนลแบบ proprietary มานานแล้ว และแพตช์ของ Christoph Hellwig ก็เป็นความพยายามที่จะปิดช่องทางเลี่ยงข้อจำกัดนั้นให้แคบลงอีกครั้ง
  • แทนที่จะห้ามการโหลดโมดูล proprietary โดยตรง เคอร์เนลใช้ GPL-only exports เพื่ออนุญาตให้เข้าถึงสัญลักษณ์บางส่วนของเคอร์เนลได้เฉพาะโมดูลที่เข้ากันได้กับ GPL เท่านั้น
  • ในปี 2020 มีการเปิดเผยวิธีแบบ GPL condom ที่ให้โมดูล GPL ทำหน้าที่เป็นตัวกลางเชื่อมระหว่างโมดูล proprietary กับเคอร์เนล และหลังจากนั้นก็มีการปรับให้โมดูลที่ใช้สัญลักษณ์ของโมดูล proprietary ถูกมองว่าเป็น proprietary เช่นกัน
  • ช่องทางเลี่ยงใหม่คือการใช้ symbol_get() เพื่อดึงที่อยู่ของสัญลักษณ์ภายในโมดูล proprietary โดยไม่ผ่านขั้นตอน import ตามปกติ ซึ่ง Hellwig เห็นว่า NVIDIA ได้ปรับโค้ดให้ใช้วิธีนี้
  • แพตช์ที่เสนอจะทำให้ symbol_get() ล้มเหลวเมื่อค้นหาสัญลักษณ์ที่ ไม่ใช่ GPL-only เพื่อปิดช่องทางดังกล่าว แต่ตราบใดที่โมดูลยังรันอยู่ในพื้นที่แอดเดรสของเคอร์เนล การควบคุมการเข้าถึงก็ยังยากจะทำให้ปลอดภัยได้อย่างสมบูรณ์

ความตึงเครียดที่ยืดเยื้อมานานรอบโมดูลเคอร์เนลแบบ proprietary

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

ความพยายามแบนการโหลดในปี 2006 และ GPL-only exports

  • ในปี 2006 เคยมีความพยายามช่วงสั้น ๆ ที่จะห้ามการโหลดโมดูลเคอร์เนล proprietary ทั้งหมด
  • Linus Torvalds ขัดขวางความพยายามนั้นด้วยเหตุผลหลายข้อ
    • การโหลดโมดูล proprietary เข้าไปในเคอร์เนล Linux เพียงอย่างเดียว ไม่ได้ถือเป็นการละเมิดลิขสิทธิ์
    • ผู้ใช้ Linux สามารถทำเช่นนั้นได้
    • Torvalds มองว่าการแบนลักษณะนี้อาจเป็นสัญญาณว่าฝ่ายที่ผลักดันสนใจข้อถกเถียงเรื่องไลเซนส์มากกว่าการปรับปรุงด้านเทคนิค
  • อย่างไรก็ตาม การ แจกจ่าย โมดูล proprietary อาจเป็นการละเมิดลิขสิทธิ์ได้ หากโมดูลนั้นถือเป็นงานดัดแปลงของโค้ดเคอร์เนล
  • แต่การตัดสินว่าเป็นงานดัดแปลงหรือไม่นั้นยังคลุมเครือ และตัวเคอร์เนลเองก็แทบตัดสินเรื่องนี้จริง ๆ ไม่ได้
  • ในเคอร์เนลมีมาตรการเก่าแก่ที่ใช้ขัดขวางโมดูลที่อาจเข้าข่ายละเมิด คือ GPL-only exports
    • โมดูลเคอร์เนลต้องเข้าถึงฟังก์ชันและสัญลักษณ์ของโครงสร้างข้อมูลที่เคอร์เนล export ออกมา จึงจะทำงานที่มีประโยชน์ได้
    • สัญลักษณ์จำนวนมากอนุญาตเฉพาะโมดูลที่ประกาศไลเซนส์เข้ากันได้กับ GPL เท่านั้น
    • วิธีนี้ทำให้โมดูล proprietary ถูกกันออกจากความสามารถของเคอร์เนลส่วนสำคัญจำนวนมาก

เจตนาของการติดป้าย GPL-only กับความเป็นจริง

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

วิธีเลี่ยงแบบตัวกลางที่ถูกเปิดเผยในปี 2020

  • ผู้พัฒนาโมดูล proprietary พยายามหาวิธีเลี่ยงข้อจำกัดของ GPL-only exports มานานแล้ว
  • วิธีหนึ่งคือประกาศไลเซนส์ GPL-compatible แบบไม่ตรงความจริง แต่สิ่งนี้ดูเหมือนเป็นการยอมรับผิดอย่างชัดเจน จึงเป็นสิ่งที่บริษัทต่าง ๆ มักหลีกเลี่ยงโดยสัญชาตญาณ
  • อีกวิธีที่แนบเนียนกว่าถูกเปิดเผยระหว่างชุดแพตช์เกี่ยวกับ peer-to-peer DMA ในปี 2020
  • โครงสร้างนี้ใช้โมดูลที่ประกาศไลเซนส์เข้ากันได้กับ GPL เป็นตัวกลาง
    • โมดูลนั้นสามารถเข้าถึงสัญลักษณ์ทั้งหมดที่เคอร์เนล export ได้
    • จากนั้นเมื่อ import สัญลักษณ์ของโมดูล proprietary อีกต่อหนึ่ง โค้ด proprietary ก็จะเข้าถึงความสามารถของเคอร์เนลที่ต้องการได้
  • นี่คือรูปแบบดัดแปลงของวิธีที่มักถูกเรียกว่า GPL condom

แพตช์ตอบโต้ในปี 2020

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

ช่องทางเลี่ยงใหม่ผ่าน symbol_get()

  • เคอร์เนลมีแมโคร symbol_get() โดยงานจริงทำใน __symbol_get()
  • ฟังก์ชันนี้ใช้ค้นหาที่อยู่ที่ผูกอยู่กับสัญลักษณ์ของเคอร์เนล
  • symbol_get() อยู่ในเคอร์เนลมาตั้งแต่รีลีส 2.5.48 เมื่อเดือนกุมภาพันธ์ 2002 และถูกเพิ่มเข้ามาระหว่างการเปลี่ยนระบบตัวโหลดโมดูลครั้งใหญ่
  • มันมีข้อจำกัดสำคัญอยู่ด้วย
    • จะค้นหาเฉพาะสัญลักษณ์ที่มาจากโมดูลที่สามารถโหลดได้เท่านั้น
    • จุดประสงค์คือใช้ในกรณีที่โมดูลซึ่งเชื่อมโยงกันแน่นแฟ้นต้องหลีกเลี่ยงวงอ้างอิง และต้องรับมือกับความเป็นไปได้ที่อีกฝั่งอาจยังไม่ถูกโหลด
  • เมื่อดูผิวเผิน มันเหมือนจะช่วยผู้พัฒนาโมดูล proprietary ที่ต้องการเลี่ยงกติกาไม่ได้มากนัก เพราะไม่สามารถใช้ค้นหาตำแหน่งของสัญลักษณ์เคอร์เนลแบบ GPL-only ได้

วิธีที่ symbol_get() เลี่ยงการป้องกันของปี 2020

  • symbol_get() สามารถถูกใช้เพื่อรับ ที่อยู่ของโมดูล proprietary ได้โดยไม่ต้องผ่านกลไก import ปกติและข้อจำกัดของมัน
  • ด้วยเหตุนี้ การแก้ไขในปี 2020 จึงถูกเลี่ยงได้อีกครั้ง
    • โมดูลที่อ้างว่าใช้ไลเซนส์ GPL สามารถเรียกโมดูล proprietary ได้
    • และโมดูล proprietary นั้นก็เข้าถึงความสามารถของเคอร์เนลที่ต้องการได้
  • Hellwig มองว่า NVIDIA ได้แก้โค้ดให้ใช้ช่องทางเลี่ยงนี้

การเปลี่ยนพฤติกรรมในชุดแพตช์ใหม่

  • Hellwig ได้ส่ง ชุดแพตช์ เพื่ออุดช่องโหว่นี้อีกครั้ง และต่อมาก็ส่ง ฉบับแก้ไข เพิ่มเติม
  • การเปลี่ยนแปลงหลักคือการปรับพฤติกรรมของ symbol_get()
    • ถ้าสัญลักษณ์ที่ต้องการค้นหา ไม่ได้ถูกทำเครื่องหมายเป็น GPL-only ก็จะล้มเหลว
    • นี่เป็นการตรวจสอบในทิศทางตรงข้ามกับวิธีปกติที่มักปฏิเสธการเข้าถึงสัญลักษณ์ GPL-only
  • เหตุผลคือ symbol_get() เดิมถูกออกแบบมาเพื่อความร่วมมือระดับต่ำในส่วนลึกของเคอร์เนล และในบริเวณนั้นก็คาดว่าสิ่งต่าง ๆ ควรเป็น GPL-only อยู่แล้ว
  • จุดใช้งานเดิมบางแห่งในเคอร์เนลอ้างถึงสัญลักษณ์ที่ไม่ได้ถูกทำเครื่องหมายเป็น GPL-only
    • ชุดแพตช์นี้จึงรวมการเปลี่ยนสัญลักษณ์กรณีเหล่านั้นให้เป็น GPL-only ด้วย

ผลกระทบที่คาดและข้อจำกัด

  • การเปลี่ยน symbol_get() ครั้งนี้จะทำให้โมดูลเคอร์เนลที่ใช้ไลเซนส์ GPL ไม่สามารถใช้ symbol_get() เพื่อ resolve สัญลักษณ์ภายในของโมดูล proprietary ได้อีก
  • หากการเปลี่ยนแปลงนี้เข้าสู่ mainline release และถูกส่งต่อไปยังดิสทริบิวชันต่าง ๆ ผู้พัฒนาโมดูล proprietary ก็จะต้องหาวิธีอื่นเพื่อเข้าถึงส่วนภายในของเคอร์เนลที่ต้องการ
  • เนื่องจากผู้ดูแลโมดูล Luis Chamberlain ได้ นำการเปลี่ยนแปลงนี้ไปใช้ แล้ว โอกาสที่มันจะเข้า mainline ในท้ายที่สุดจึงดูค่อนข้างดี
  • ความขัดแย้งนี้ดำเนินมานาน และก็มีความเป็นไปได้ไม่น้อยที่ผู้เขียนโมดูล proprietary จะหาวิธีอื่นมาเลี่ยงเจตนาของชุมชนเคอร์เนลอีก
  • ไม่ว่าจะเป็น proprietary หรือไม่ โมดูลต่างก็ทำงานอยู่ใน พื้นที่แอดเดรสของเคอร์เนล
    • พื้นที่โจมตีที่โมดูลซึ่งต้องการหลบเลี่ยงนโยบายการเข้าถึงสัญลักษณ์ของเคอร์เนลจะใช้ประโยชน์ยังมีขนาดใหญ่
    • จึงยากที่จะปกป้องพื้นที่นี้ได้อย่างสมบูรณ์
  • ในทางปฏิบัติ สิ่งที่ดีที่สุดที่ทำได้คือทำให้ผู้แจกจ่ายโมดูลเคอร์เนลแบบไบนารีล้วนยังคงรู้สึกไม่สะดวกต่อไป เพื่อผลักดันให้สร้างทางออกที่ใช้ไลเซนส์เสรีแทน
  • วิธีนี้ไม่สมบูรณ์แบบ แต่ตลอดหลายปีที่ผ่านมาก็มักได้ผลอยู่บ่อยครั้ง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-08-31
ความคิดเห็นจาก Hacker News

  • โค้ด linker ของเคอร์เนล Linux ถูกออกแบบมาเพื่อบังคับใช้การตีความของ Linus Torvalds ว่า GPL และข้อยกเว้นสำหรับ system call ควรทำงานอย่างไร ดังนั้นดูเหมือนจะมีช่องทางทางกฎหมายให้ Nvidia อ้างว่ามีการหลีกเลี่ยงมาตรการคุ้มครองลิขสิทธิ์ (DMCA 1201) ได้
    Linus คงไม่ทำแบบนั้นจริง ๆ และถ้าทำก็คงค่อนข้างเลวร้ายต่อทั้งระบบนิเวศ FOSS ด้วย แต่พอคิดถึงสิ่งที่ Nvidia ทำมาจนถึงตอนนี้ ก็อดอยากเห็นสักครั้งไม่ได้

    • ถ้า โปรเจกต์ GPL ที่โด่งดังที่สุดอย่าง Linux ไม่บังคับใช้เงื่อนไขไลเซนส์และลิขสิทธิ์ แม้จะมีเหตุผลอันสมควร ก็อาจเลวร้ายต่อระบบนิเวศ FOSS มากกว่าการเข้มงวดกับบริษัทใหญ่บางรายเสียอีก
      ถ้าแม้แต่ Linux ซึ่งเป็นกอริลลา 800 ปอนด์ในห้อง ยังไม่เต็มใจจะขึ้นศาล อนาคตของโปรเจกต์อื่น ๆ ก็ดูไม่สดใสนัก
      ถ้า Linux จะใช้แค่แรงกดดันทางเทคนิคแบบ “นุ่มนวล” ต่อการละเมิดไลเซนส์และลิขสิทธิ์อย่างโจ่งแจ้งของบริษัทใหญ่ ๆ ก็ชวนให้คิดว่า GPL อาจจบแล้ว และย้ายไปใช้ทางเลือกอย่าง BSD3 หรือ MIT+Apache น่าจะดีกว่า
      LLVM ไม่ใช้ copyleft แบบเข้มงวด แต่ใช้วิธีทางเทคนิคล้วน ๆ เช่น API ที่เปลี่ยนแปลงบ่อยและความเร็วในการพัฒนาที่สูงมาก เพื่อกระตุ้นให้ร่วมมือกับ upstream ซึ่งก็ทำงานได้ค่อนข้างดีโดยไม่ทำให้ไลเซนส์ที่เลือกไว้เจือจางลง
    • ถ้าเตรียมไว้เผื่อวันที่ Nvidia อาจพยายามดำเนินคดีกับ Linux Foundation ก็ไม่ใช่ไพ่ที่แย่
      การฟ้องกลับ ที่สามารถสร้างผลกระทบจริงต่อโอกาสทางธุรกิจของ Nvidia อาจทำหน้าที่ยับยั้งปัญหาในอนาคตได้ดี
    • ถ้อยคำของ Hellwig ที่ถูกอ้างในบทความน่าประทับใจ
      ทำนองว่า “symbol_get เดิมมีไว้เฉพาะสำหรับโมดูลที่ร่วมมือกันอย่างใกล้ชิดและใช้สัญลักษณ์ที่เป็นภายในมาก ๆ ดังนั้นจึงสมเหตุสมผลที่จะจำกัดให้ใช้ได้เฉพาะกับ EXPORY_SYMBOL_GPL และช่วยให้ Nvidia เลี่ยงคดีราคาแพงเรื่องการหลีกเลี่ยงการควบคุมการเข้าถึงตาม DMCA” เป็นถ้อยคำประชดที่ยอดเยี่ยมมากต่อการที่ Nvidia เมินเจตนาและน้ำใจอย่างโจ่งแจ้งแล้วทำตามใจตัวเอง
    • ถ้า Linus ถึงขั้นชูนิ้วกลางใส่ NVIDIA จริง ๆ ได้ [1] ก็คิดว่า Linus หรือ Linux Foundation อาจเล่นงาน NVIDIA ทางกฎหมายสักหมัดได้เหมือนกันไหม
      ฝันได้แหละ :)
      [1]: https://www.youtube.com/watch?v=tQIdxbWhHSM
    • เคอร์เนล Linux มีผู้ร่วมพัฒนาหลายพันคน ดังนั้นใครในนั้นก็สามารถยกข้ออ้างนี้ได้
      Linus ไม่ได้มีอำนาจพิเศษอะไร

  • คอมเมนต์ที่ผู้เขียนแพตช์นี้ทิ้งไว้นั้นแปลกมากจริง ๆ
    https://lore.kernel.org/lkml/20230731083806.453036-6-hch@lst...
    เขียนไว้ว่า “symbol_get เดิมมีไว้เฉพาะสำหรับโมดูลที่ร่วมมือกันอย่างใกล้ชิดและใช้สัญลักษณ์ที่เป็นภายในมาก ๆ ดังนั้นจึงสมเหตุสมผลที่จะจำกัดให้ใช้ได้เฉพาะกับ EXPORY_SYMBOL_GPL และช่วยให้ nvidia เลี่ยงคดีราคาแพงเรื่องการหลีกเลี่ยงการควบคุมการเข้าถึงตาม DMCA”
    นี่คือความพยายามที่จะอ้างการคุ้มครองตาม ข้อห้ามการหลีกเลี่ยงของ DMCA ซึ่งทำให้การหลีกเลี่ยง DRM เป็นสิ่งผิดกฎหมาย ต่อเคอร์เนล Linux ซึ่งเป็นโปรเจกต์โอเพนซอร์สอย่างตรงตัว
    ขณะเดียวกันก็เท่ากับยอมรับโดยนัยว่า EXPORT_SYMBOL_GPL เป็นระบบ DRM อย่างชัดเจน
    โดยส่วนตัวผมไม่ชอบ NVIDIA และไม่ได้คิดจะปกป้องพฤติกรรมของพวกเขาเป็นพิเศษ แต่ก็น่าประหลาดใจที่โปรเจกต์ Linux อ้างว่ากฎหมายห้ามหลีกเลี่ยง DRM ใช้กับโปรเจกต์โอเพนซอร์สได้ด้วย
    มันเป็นหนึ่งในกฎหมายที่ชุมชนโอเพนซอร์สแทบจะคัดค้านกันโดยทั่วไป และไม่ว่าจะเป็นระบบ DRM แบบใด ก็ดูค่อนข้างขัดกับคุณค่าของ FOSS

    • ไม่มีอะไรแปลก
      เป้าหมายหลักของ GPL เองก็คือการใช้กฎหมายลิขสิทธิ์ต่อสู้กับกฎหมายลิขสิทธิ์ หรือก็คือ copyleft
      ยิ่งกฎหมายลิขสิทธิ์แข็งแรงขึ้น การคุ้มครองของ GPL ก็ยิ่งแข็งแรงขึ้น ดังนั้นการใช้กฎหมายลิขสิทธิ์เพิ่มเติมเพื่อปกป้องซอฟต์แวร์โอเพนซอร์สจึงค่อนข้างสอดคล้องกับจิตวิญญาณของ GPL
    • เครื่องหมาย kernel taint เป็น ระบบ DRM อย่างชัดเจน และก็ไม่ได้เป็นความลับอะไร
      GPL ไม่ใช่ไลเซนส์แบบ permissive แต่เป็นไลเซนส์ copyleft ที่เข้มงวด และมีพลังบังคับใช้จริง
      กลไก taint ไม่ใช่ความหน้าไหว้หลังหลอก แต่เป็นโอเพนซอร์ส และถ้าโค้ดเป็น GPL คุณก็ทำอะไรก็ได้ตามต้องการ
      มันคือกลไกที่บังคับใช้ข้อกำหนดเรื่องการลิงก์ของไลเซนส์ GPL อย่างตรงตัว
    • ต่อให้ไม่ชอบกฎหมายบางฉบับ กฎหมายก็คือกฎหมาย และเราก็อยู่ในความเป็นจริงที่กฎหมายนั้นมีผลบังคับใช้
      เมื่อจำเป็นก็ต้องใช้กฎหมายนั้น ดังนั้นจึงไม่รู้สึกว่าแปลกเลย
    • คุณค่าของชุมชน FOSS คือการสนับสนุนฝ่ายที่ดี
      ถ้าทำเรื่องน่าสงสัยมาแล้ว ยังได้รับการไว้หน้าแบบนุ่มนวลขนาดนี้ ก็ถือว่าโชคดีแล้ว
    • การรักษาโอเพนซอร์สไว้ด้วย GPL2 ก็เป็น สิทธิดิจิทัล ไม่ใช่หรือ?
      DRM เพื่อป้องกันการฉวยใช้ GPL ดูเหมือนเป็นขั้นต่อไปที่สมเหตุสมผล

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

    • ไลเซนส์ของ Linux คือ GPLv2 พร้อมข้อยกเว้นสำหรับ system call
      ถ้ามีแค่ GPLv2 อย่างเดียว โมดูลแบบปิดก็น่าจะเป็นการละเมิด
      แต่เพราะ Linus ระบุชัดว่า system call ไม่ทำให้ copyleft ของ GPL ทำงาน ดังนั้นสัญลักษณ์ของเคอร์เนลที่เข้าข่าย system call ก็ไม่ทำให้ copyleft ของ GPL ทำงานเช่นกัน
      ดังนั้นเพื่อหลีกเลี่ยงการละเมิดไลเซนส์ตามการตีความข้อยกเว้น GPL ของ Linus จึงต้องมี loader ที่ตรวจข้อมูลไลเซนส์ว่า symbol ใดลิงก์ได้หรือไม่ได้
      นี่ใช่ DRM ระดับเคอร์เนลจริง ๆ[0] และ Linus อาจมีช่องให้โต้แย้งทางกฎหมายเรื่องที่ Nvidia หลีกเลี่ยงการป้องกันการคัดลอกได้
      GPLv3 ปฏิเสธอย่างชัดเจนต่อการป้องกันการคัดลอกใด ๆ ในโค้ดที่อยู่ภายใต้ไลเซนส์ ดังนั้นในทางทฤษฎีอาจกันคดีแบบนี้ได้ แต่ข้อกำหนดนั้นยังไม่เคยถูกทดสอบในศาล และ Linus ก็ไม่ชอบ GPLv3 เป็นพิเศษเพราะมีการเพิ่มข้อกำหนด TiVo[1]
      ฟีเจอร์นี้ถูกทำไว้ตั้งแต่หลายสิบปีก่อน และเป้าหมายเดิมคือไม่อยากรับบั๊กรายงานว่าเคอร์เนล Linux แครชเพราะโมดูลปิดที่แก้ไขไม่ได้
      การบังคับใช้ GPL เป็นผลข้างเคียง
      [0] อย่าสับสนกับ DRM อีกตัวในเคอร์เนลคือ Direct Rendering Manager
      [1] ไม่ใช่ว่าไม่ชอบข้อกำหนด TiVo เองเท่าไร แต่ไม่ชอบการเพิ่มเงื่อนไขย้อนหลังให้ซอฟต์แวร์ v2 และเปลี่ยนเงื่อนไขการแลกเปลี่ยน เพราะมันให้ความรู้สึกเหมือน Linux ถูก FSF เข้าควบคุม
    • ไดรเวอร์แบบปิดก็โต้ตอบกับเคอร์เนล Linux ได้
      เพียงแต่ต้องใช้เฉพาะความสามารถของระบบปฏิบัติการที่ค่อนข้างทั่วไป ซึ่งพบได้ในเคอร์เนลที่คล้ายกันหลายตัว
      ไดรเวอร์แบบนั้นที่ไม่พึ่งพาฟีเจอร์เฉพาะของ Linux ไม่อาจถือเป็น “งานดัดแปลง” ของเคอร์เนล Linux ได้ จึงเลือกไลเซนส์อะไรก็ได้ตามต้องการ
      ในทางกลับกัน ไดรเวอร์ที่ใช้อินเทอร์เฟซเฉพาะของเคอร์เนล Linux ซึ่งไม่มีในระบบปฏิบัติการอื่น แม้แต่ในเคอร์เนลตระกูล Unix อื่น ๆ ตามนิยามแล้วก็ใกล้เคียงกับ “งานที่อิงจากโปรแกรม” ของเคอร์เนล ดังนั้นจึงควรถูกไลเซนส์ในลักษณะใกล้เคียงกัน
      ดูถ้อยคำของ GPL-2 ที่เคอร์เนลใช้อยู่ได้
      https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
      LGPL มีอยู่แยกต่างหากเพื่ออนุญาตให้ซอฟต์แวร์เสรีกับซอฟต์แวร์ปิดลิงก์แยกกันได้ ซึ่ง GPL ห้ามไว้
      แต่ Linux เป็น GPL-2 ดังนั้นการอนุญาตเพิ่มเติมแบบนั้นจึงไม่ใช้กับกรณีนี้
      ถ้าไดรเวอร์ Nvidia ใช้แค่ kernel API ทั่วไปก็คงไม่เป็นไร แต่ในความเป็นจริงไม่ใช่อย่างนั้น
      เพราะพยายามใช้ API เฉพาะ Linux ที่ทำเครื่องหมายไว้ให้ไดรเวอร์ที่มีไลเซนส์เข้ากันได้กับ GPL ใช้ ในสถานะที่ไม่ใช่ GPL จึงเป็นการละเมิด ไลเซนส์ซอฟต์แวร์เสรี ที่ Linux แจกจ่ายอยู่โดยชัดเจน
    • การที่ซอฟต์แวร์เสรีบังคับใช้หลักการของตัวเองไม่ได้ขัดแย้งกับซอฟต์แวร์เสรี
      ทำไมซอฟต์แวร์ปิดถึงควรได้รับผลประโยชน์ทั้งหมดของซอฟต์แวร์เสรีโดยไม่ต้องทำตามกฎใด ๆ แล้วซอฟต์แวร์เสรีต้องได้แต่อดทน?
      แม้แต่สังคมประชาธิปไตยก็ยังมีกลไกที่จำกัดการแสดงออกในระดับหนึ่งเพื่อปกป้องตัวเอง
      ระบบปฏิบัติการแบบปิดมีอยู่มากมายอยู่แล้ว และไม่ได้สนใจเรื่องแบบนั้นเลย
      จะมีระบบปฏิบัติการที่ใส่ใจหลักการแบบนั้นบ้างไม่ได้หรือ? ทุกอย่างจำเป็นต้องเป็นเพียงเครื่องมือที่เย็นชา เป็นมิตรต่ออุตสาหกรรม และไร้ความคำนึงถึงมนุษย์เท่านั้นหรือ?
    • เพราะเคอร์เนลถูกไลเซนส์ภายใต้ GPL และนั่นคือแก่นของ Linux
      เจตนาของไลเซนส์คือทุกอย่างที่ลิงก์และโหลดเข้ากับเคอร์เนลต้องถูกแจกจ่ายภายใต้ไลเซนส์ copyleft ที่เข้ากันได้
    • นี่ไม่ใช่ DRM แต่เป็น ไลเซนส์ซอฟต์แวร์ ธรรมดา
      ข้อกำหนดที่ว่าโค้ดปิดไม่ควร “รวม” โค้ด GPL ก็คือตัว GPL เอง และเป็นเป้าหมายหลักของ GPL
      อย่างไรก็ตาม ยังมีประเด็นให้ถกเถียงได้ว่าการลิงก์กับ API เพียงอย่างเดียวถือเป็นการละเมิดถึงระดับใด
      ดูเหมือนว่าศาลอาจตัดสินได้ทั้งสองทาง และการตัดสินแบบนั้นจะส่งผลอย่างมากต่อ GPL

  • โค้ดของ Nvidia ทำงานใน ring0 ดังนั้นจากประสบการณ์แล้ว Nvidia ยังมีกลเม็ดที่น่าสนใจกว่านี้ให้ใช้ได้อีกมาก แต่ตอนนี้คงกำลังยั้งมืออยู่
    ฝั่งนักพัฒนา Linux ก็เช่นกัน
    สงคราม DRM โง่ ๆ แบบนี้ไม่ช่วยใครเลย และมีแต่จะยิ่งกระตุ้นเกมแมวจับหนูที่เสียเวลาของทุกฝ่าย
    “พวกนาย อยู่ร่วมกันดี ๆ เถอะ”

  • ผมไม่เข้าใจว่าทำไม Nvidia ถึงทุ่มแรงมากขนาดนั้นเพื่อคงไดรเวอร์ไว้เป็น ก้อน binary แบบปิด
    ซอฟต์แวร์ก็ไม่ใช่แกนหลักของการป้องกันตัวของพวกเขา และ Nvidia ก็เป็นบริษัทฮาร์ดแวร์
    การเปิดเผยโมดูลเคอร์เนลไม่เพียงไม่กระทบยอดขายฮาร์ดแวร์ แต่ยังช่วยให้เสถียรขึ้น และยังได้คะแนนนิยมจากนักพัฒนาที่ตั้งใจหันไปซื้อ AMD GPU อีกด้วย

    • Nvidia อยากเป็นมากกว่าบริษัทฮาร์ดแวร์ธรรมดา
      เพราะการกลายเป็นสินค้าโภคภัณฑ์อยู่ตรงข้ามกับอัตรากำไรหนา ๆ
      เมื่อครองตลาด GPU ราว 80% แล้ว หากอยากเพิ่มอัตรากำไรให้สูงขึ้น ก็ทำได้ง่ายกว่าด้วยการตั้งราคาให้แรงขึ้น หรือควบคุมชั้นที่สูงกว่าของสแต็กทั้งหมด
      เช่น ถ้า ภาษา GPU แบบใช้งานทั่วไป หลัก ๆ ถูกสร้างโดยมีสถาปัตยกรรม GPU ของตนเป็นศูนย์กลาง ก็ย่อมได้เปรียบ
      ไม่อย่างนั้นก็ต้องขยายไปสู่领域ที่ต่างไปโดยสิ้นเชิง และที่ Nvidia กระโดดเข้าสู่ AI อย่างหนักก็เพราะสามารถใช้ความเหนือกว่าด้าน GPU เพื่อคว้าความได้เปรียบช่วงต้นใน领域นั้นได้
    • เดาว่าน่าจะเป็นเพราะอาจทำให้ปลดล็อกช่วงประสิทธิภาพที่สูงขึ้นจากการ์ดรุ่นล่างได้
      แต่ไม่มีหลักฐานนะ
    • ซอฟต์แวร์ของ Nvidia เป็น ส่วนมหาศาล ของแนวป้องกันของพวกเขา

  • คำว่า “ผิดกฎหมาย” เป็นเพียงทฤษฎีเท่านั้นจนกว่าจะได้รับการพิสูจน์ในศาล
    สิ่งที่พูดถึงในที่นี้โดยพื้นฐานแล้วคือ DRM ภายในโค้ดเคอร์เนล ซึ่งพยายามป้องกันไม่ให้โมดูลเคอร์เนลที่โหลดได้เดาว่าโครงสร้างข้อมูลของเคอร์เนลอยู่ตรงไหนในหน่วยความจำ
    เพราะรู้ว่าผู้คนมีแนวโน้มจะพยายามดันขอบเขตให้สุด จึงพยายามทำให้มันยากที่สุดเท่าที่ทำได้ในฐานะมาตรการยับยั้ง
    แต่ก็อาจโต้แย้งได้ว่าโมดูลเคอร์เนลแบบโหลดได้ที่เป็นซอร์สปิดทั้งหมดละเมิด GPL เหมือนกัน ไม่ว่าจะมี “shim” หรือไม่ และที่จริงก็เคยมีข้อโต้แย้งแบบนั้น แต่คนส่วนใหญ่ลืมไปแล้ว แล้วใช้เรื่องแต่งเรื่อง DRM นี้ราวกับเป็นสิ่งทดแทนเรื่องแต่งทางกฎหมาย
    หรือถ้าฟังก์ชันที่ติดแท็ก GPL ในเคอร์เนลเข้าข่ายเป็น API ตามความหมายในคดี Google กับ Oracle การถกเถียงทั้งหมดนี้ก็อาจไม่มีความหมายมากนัก

    • ไม่ควรพูดในทำนองว่า “โมดูลเคอร์เนลที่โหลดได้ส่วนใหญ่ละเมิด GPL”
      โมดูลเคอร์เนลที่โหลดได้ส่วนใหญ่อยู่ในซอร์สทรีของเคอร์เนลและเผยแพร่ภายใต้ GPL

  • ขั้นถัดไปก็แค่สร้างโมดูลโหลดได้แบบโอเพนซอร์สที่มีเครื่องเสมือนขนาดเล็กซึ่งโหลดก้อนข้อมูลไบนารีใน user mode
    ให้รันเฉพาะก้อนไบนารีที่เซ็นด้วยคีย์ส่วนตัวของ NVIDIA และใส่คีย์สาธารณะไว้ในโมดูลโอเพนซอร์ส
    หรือไม่ก็สร้างไฮเปอร์ไวเซอร์ที่ทำ virtualization ให้ Linux เพื่อเลี่ยงเคอร์เนลส่วนใหญ่ไปเลย…
    ยังไงก็มีทางเสมอ
    นี่แค่ทำให้น่ารำคาญและเพิ่มต้นทุนในการได้ไดรเวอร์ดี ๆ สำหรับ Linux ดังนั้นความพยายามที่ทุ่มไปทางนั้นก็จะลดลง

    • ไม่ใช่การเพิ่มต้นทุนของไดรเวอร์ดี ๆ สำหรับ Linux แต่เป็นการเพิ่มต้นทุนของ ไดรเวอร์กรรมสิทธิ์ สำหรับ Linux
      ยังไม่ชัดเจนว่านั่นเป็นการสูญเสียครั้งใหญ่หรือไม่

  • หวังว่าการต่อสู้นี้จะไม่ลงเอยด้วยการที่ไดรเวอร์ Nvidia สำหรับ Linux หายไปหรือแย่ลง
    ถ้าไม่มีไดรเวอร์นั้น ระบบปฏิบัติการที่ผมชอบจะมีประโยชน์น้อยลงทันทีเพราะเกมและ AI

    • ในปี 2023 NVIDIA จำเป็นต้องพึ่ง Linux มากกว่า Linux จำเป็นต้องพึ่ง NVIDIA มาก
      เมื่อ 10 ปีก่อนต่างออกไป
      ตอนนั้นส่วนใหญ่มีแค่กี๊ก Linux ส่วนน้อยที่อยากเล่นเกมบน Linux เท่านั้นที่สนใจ และพวกเขาเป็นสัดส่วนเล็กน้อยของยอดขาย
      ตอนนี้มูลค่ากิจการเกือบทั้งหมดของ NVIDIA ตั้งอยู่บน AI และผู้เล่นรายใหญ่แทบทั้งหมดที่ซื้อฮาร์ดแวร์นั้นในปริมาณมากก็ใช้มันบน Linux
      การตัดขาดจาก Linux ไม่ใช่ตัวเลือกสำหรับ NVIDIA
    • การสูญเสียสถานะผู้นำบน Linux จะเป็นหายนะสำหรับ Nvidia
      มีแนวโน้มสูงว่าจะทำทุกอย่างเพื่อไม่ให้เรื่องนั้นเกิดขึ้น
    • ถ้ากังวลว่าเกมจะลดลง การ์ด AMD ทำงานบน Linux ได้ดีมาก
    • ผมคิดว่า Linux ก็ควรทำเหมือน OpenBSD
      คือถอดการสนับสนุนทั้งหมดออกจนกว่า nVidia จะเปิดเผยซอร์ส
      แต่ทุกวันนี้บริษัทเชิงพาณิชย์มีสิทธิ์มีเสียงมากกว่าเราในเรื่องว่าจะใช้และสนับสนุนฮาร์ดแวร์บน Linux อย่างไร

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

  • ในระดับเคอร์เนล นี่กลายเป็นเรื่อง “บิตของคุณเป็นสีอะไร”[1] แล้วสินะ… ก็ดีนะ?
    [1] https://ansuz.sooke.bc.ca/entry/23

    • กรณีนี้ต่างตรงที่ NVIDIA สามารถใส่ไลเซนส์ให้ไดรเวอร์เพื่อทำให้บิตนั้นเป็น สี GPL ได้