สัญญาอนุญาตสาธารณะของสหภาพยุโรป (European Union Public Licence, EUPL)

 (eupl.eu)
1 คะแนน โดย GN⁺ 2025-10-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สัญญาอนุญาตสาธารณะของสหภาพยุโรป (EUPL) เป็นสัญญาอนุญาตโอเพนซอร์สที่มีเป้าหมายเพื่อส่งเสริมการแบ่งปันและการนำกลับมาใช้ใหม่ของซอฟต์แวร์ภายในสหภาพยุโรป
  • EUPL มีผลทางกฎหมายเท่าเทียมกันในทุกภาษาทางการของสหภาพยุโรป และระบุคำศัพท์ด้านทรัพย์สินทางปัญญาและข้อจำกัดความรับผิดให้ชัดเจนตามมาตรฐานกฎหมายยุโรป
  • เป้าหมายหลักคือการเผยแพร่และใช้งานซอฟต์แวร์ที่เป็นของสหภาพยุโรปและหน่วยงานในสังกัดภายใต้สัญญาอนุญาตซอฟต์แวร์เสรี/โอเพนซอร์ส
  • EUPL ใครก็ใช้ได้ ไม่ใช่เฉพาะหน่วยงานรัฐเท่านั้น แต่ผู้ถือลิขสิทธิ์ก็สามารถนำไปใช้กับซอฟต์แวร์ของตนได้
  • EUPL มีข้อกำหนดด้านความเข้ากันได้กับสัญญาอนุญาตโอเพนซอร์สอื่น เช่น GPL เพื่อรองรับการผสมผสานซอฟต์แวร์และการทำงานร่วมกัน

EUPL (สัญญาอนุญาตสาธารณะของสหภาพยุโรป) คืออะไร

  • EUPL ย่อมาจาก "European Union Public Licence" และเป็นสัญญาอนุญาตซอฟต์แวร์โอเพนซอร์สที่สหภาพยุโรปจัดทำขึ้นอย่างเป็นทางการ
  • ร่างแรก (v.0.1) เผยแพร่ในเดือนมิถุนายน 2005 และต่อมาได้มีการแก้ไข 10 มาตราโดยสะท้อนความคิดเห็นจากชุมชนนักพัฒนาและผู้ใช้
  • เวอร์ชันสุดท้าย (v.1.0) ได้รับการอนุมัติอย่างเป็นทางการเมื่อวันที่ 9 มกราคม 2007 ใน 3 ภาษา จากนั้นขยายเป็นทุกภาษาทางการของสหภาพยุโรปในปี 2008 มีการทำให้บางส่วนชัดเจนขึ้นใน v.1.1 เมื่อปี 2009 และในปี 2017 ได้ออกv.1.2 เพื่อขยายความเข้ากันได้และส่งเสริมการแบ่งปันกับการนำกลับมาใช้ใหม่ให้มากยิ่งขึ้น

ทำไมต้องเป็น EUPL?

  • มีการสร้างสัญญาอนุญาตนี้ขึ้นเพื่อใช้ในการเผยแพร่ซอฟต์แวร์ที่คณะกรรมาธิการยุโรป (EC) เป็นเจ้าของ โดยในช่วงแรกนำไปใช้กับผลงานจากโครงการ IDABC (เช่น Circabc, Eusurvey)
  • แม้จะมีสัญญาอนุญาตโอเพนซอร์สอยู่ราว 100 แบบ (GPL, BSD, OSL ฯลฯ) แต่ก็ไม่มีสัญญาอนุญาตใดที่ตอบข้อกำหนดทางกฎหมายของสหภาพยุโรปได้ครบถ้วน (เช่น มีผลเท่ากันในทุกภาษา ใช้คำศัพท์ทรัพย์สินทางปัญญาตามมาตรฐานยุโรป และกำหนดข้อจำกัดความรับผิดอย่างชัดเจน) จึงได้พัฒนาขึ้นใหม่

วัตถุประสงค์

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

ใครก็ใช้ได้

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

ความเข้ากันได้กับ GPL และสัญญาอนุญาตโอเพนซอร์สอื่น

  • EUPL มีข้อกำหนดด้านความเข้ากันได้ที่เป็นเอกลักษณ์ และรองรับความเข้ากันได้กับสัญญาอนุญาตแบบ copyleft หลายแบบ (รวมถึง GPL)
  • ตัวอย่างเช่น ซอฟต์แวร์ที่เผยแพร่ภายใต้ EUPL (เช่น CIRCA) สามารถนำไปรวมกับคอมโพเนนต์ GPL แล้วเผยแพร่งานดัดแปลงใหม่ภายใต้ GPL ได้
  • อย่างไรก็ตาม ไม่อนุญาตให้เพียงแค่นำซอฟต์แวร์ทั้งหมดที่เผยแพร่ภายใต้ EUPL เดิมไป relicense เป็น GPL
  • หากผนวกรวมซอฟต์แวร์ EUPL เข้ากับโครงการ GPL เดิม ก็สามารถเผยแพร่งานทั้งหมดที่ได้รับการปรับปรุงแล้วภายใต้ GPL เดิมได้

อ้างอิง

  • เว็บไซต์นี้ไม่ได้รับการสนับสนุนหรือการรับรองอย่างเป็นทางการจากคณะกรรมาธิการยุโรปหรือหน่วยงานของสหภาพยุโรป

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

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

 
GN⁺ 2025-10-01
ความคิดเห็นจาก Hacker News

  • แม้ EUPL จะมีข้อกำหนดที่พยายามปิดช่องโหว่ของ SaaS (Software as a Service) แต่ก็ยังอนุญาตให้ใครก็ตามนำโค้ดของฉันไปรีไลเซนส์เป็น GPL-2.0-only หรือ GPL-3.0-only ได้อยู่ดี และทั้งสองไลเซนส์นี้ก็ไม่มีข้อกำหนดเกี่ยวกับ SaaS เลย ทำให้ความพยายามปิดช่องโหว่นี้ดูเหมือนไม่มีความหมาย FSF ก็พูดถึงประเด็นนี้เช่นกัน ในมุมของนักพัฒนา ดูเหมือนจะคาดหวังผลแบบ copyleft ที่เข้มแข็งได้ยาก ดังนั้นจึงคิดว่าใช้ AGPL จะดีกว่า
    ความเห็น/ข้อมูลที่เกี่ยวข้องจาก FSF อ้างอิง

    • ข้อกำหนดเรื่องความเข้ากันได้ของไลเซนส์ใน EUPL หมายถึงเพียงว่า “สามารถนำโค้ดมาใช้ร่วมกันได้” เท่านั้น โค้ดต้นฉบับยังคงอยู่ภายใต้ EUPL และจะใช้ไลเซนส์ที่เข้ากันได้กับงานผสมเฉพาะเมื่อจำเป็นเท่านั้น หากเป็นการรวมกันในระดับลิงก์ ซอร์สแต่ละส่วนก็ยังคงไลเซนส์เดิมของตนเอง นี่เป็นผลตามกฎหมายยุโรป โดยข้อยกเว้นด้านลิขสิทธิ์ทำให้อินเทอร์เฟซ (API, โครงสร้างข้อมูล ฯลฯ) สามารถนำไปใช้ในผลงานได้อย่างอิสระ แต่ถ้าใช้เพียงเพื่อจะรีไลเซนส์งานต้นฉบับอย่างเดียว ก็เข้าข่ายละเมิดลิขสิทธิ์
      ลิงก์ FAQ อย่างเป็นทางการ

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

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

  • ความเข้ากันได้ของไลเซนส์หมายถึง “ใช้ร่วมกันได้” หากไลเซนส์สองตัวไม่ขัดกันก็สามารถใช้ร่วมกันได้ โดยทั่วไปต้องปฏิบัติตามข้อกำหนดของฝั่งที่เข้มงวดกว่า ตัวอย่างเช่น GPLv2 กับ Apache ใช้ร่วมกันไม่ได้ แต่หลังจาก GPLv3 ออกมาก็แก้ได้ด้วยการอัปเกรด การรีไลเซนส์จาก EUPL ไปเป็น GPLv2 ทำไม่ได้ในตอนนี้ แต่ยังสามารถใช้โค้ด GPLv2 ได้ และข้อกำหนดเรื่องการแจกจ่ายซ้ำแบบนี้มีความสำคัญ

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

    • ไลเซนส์ส่วนใหญ่ตั้งอยู่บนสมมติฐานของกฎหมายแบบแองโกล-อเมริกันเท่านั้น แต่กฎหมาย EU มีความแตกต่างแบบละเอียดอ่อนอยู่มาก

    • กลับรู้สึกว่าข้อกำหนดเรื่องความเข้ากันได้นี่เองที่ทำให้ EUPL ดูไม่มีความหมาย เพราะถ้าใครเอาโค้ด EUPL ของฉันไปเปลี่ยนเป็น GPL สุดท้ายโครงการ EUPL ก็หายไป เหลือแต่ GPL

    • อยากรู้ว่ามีจุดไหนบ้างที่ GPL ยังไม่ครอบคลุมแต่ EUPL อธิบายไว้ชัดเจนกว่าโดยเฉพาะ และการบังคับใช้เขตอำนาจของกฎหมาย EU ก็อาจยิ่งทำให้ผู้ใช้นอก EU ไม่อยากใช้ แม้การรองรับหลายภาษาจะดี แต่ก็ดูเหมือนไลเซนส์ที่สร้างมาเพื่อหน่วยงานของ EU มากกว่า สำหรับ reciprocation (การเปิดเผยตอบแทนซึ่งกันและกัน) ฉันคิดว่าข้อกำหนดฝั่ง EUPL อาจทำให้ผู้ที่ไม่ใช่หน่วยงาน EU ลังเล โดยเฉพาะเงื่อนไขเรื่องการคลิกยอมรับ เป็นต้น ซึ่งอาจไม่ดึงดูดองค์กรภายนอกนัก

  • เคยมีประสบการณ์ทำงานกับ EUPL อยู่บ้าง เลยขอสรุปบางอย่าง

    • EUPL อ้างอิง GPL ค่อนข้างใกล้ชิด ถ้าดูละเอียด ๆ แล้วโดยพื้นฐานก็คือ GPL
    • มันคล้าย GPLv3 มากกว่า และมีข้อกำหนดเรื่องสิทธิบัตรที่ชัดเจน
    • แต่ไม่มีข้อกำหนดเรื่อง Tivoization (ทีโวอิเซชัน) และ DRM (การจัดการสิทธิ์ดิจิทัล)
    • ต่างจาก GPL ตรงที่ EUPL แยกความชัดเจนระหว่างความเข้ากันได้ของไลเซนส์ขาเข้า (inbound) กับขาออก (outbound)
    • ไลเซนส์ copyleft อื่น ๆ (เช่น GPL) ไม่สามารถเข้ามาเป็น EUPL ได้
    • แต่สามารถออกไปเป็น GPL (v2, v3) ได้
    • และเมื่อออกไปเป็น GPL ข้อกำหนดที่เข้มงวดกว่าซึ่งมีเฉพาะใน EUPL ก็จะหายไปโดยอัตโนมัติ
      ดังนั้นแม้จะดูเป็นรายละเอียดเล็กน้อย แต่ก็มีความแปลกอยู่
      EDIT: พออ่านความเห็นอื่นแล้วก็เห็นว่าบางคนรู้สึกว่า EUPL คล้าย AGPL มากกว่า แต่สิ่งที่ฉันสนใจคือการที่ EUPL เปลี่ยนเป็น GPL ได้ง่าย ทำให้เงื่อนไข SaaS ที่เข้มแข็งของ AGPL ถูกทำให้หมดแรงไปในทางปฏิบัติ
      EDIT2: สำหรับ AGPL ก็ยอมรับว่ามุมมองของฉันอาจจะเรียบง่ายเกินไป โปรดดูความเห็นอื่นประกอบ

    • ถ้ามีเหตุผลหรือสถานการณ์ที่ควรเลือก EUPL อยากฟังแบบเจาะจง ว่าทำไมถึงเลือก EUPL แทน GPLv3

    • รู้สึกว่า EUPL ถูกออกแบบโดยคำนึงถึงการนำกลับมาใช้ซ้ำระหว่างหน่วยงานและความชัดเจนทางกฎหมาย มากกว่าความบริสุทธิ์ของ copyleft อย่างแท้จริง

  • มีบทความที่ Martin Tournoi ผู้พัฒนา GoatCounter อธิบายว่าทำไมจึงเลือก EUPL ให้กับ GoatCounter เป็นเอกสารเปรียบเทียบ/วิเคราะห์ที่มีประโยชน์สำหรับคนที่กำลังคิดเรื่องการเลือกไลเซนส์
    ลิงก์บทความที่เกี่ยวข้อง

    • ผู้เขียนนำ EUPL ไปดัดแปลงใช้เอง ซึ่งไม่ใช่ความคิดที่ดีนัก กลับทำให้ข้อดีเรื่องดึงดูดแม้แต่บริษัทที่ไม่ชอบ AGPL หายไป จากมุมของบริษัทนอก EU นั้น EUPL เองก็บังคับเขตอำนาจศาลอยู่แล้วจึงยิ่งไม่น่าสนใจ อีกทั้งยังเข้าใจผิดว่ามีข้อกำหนดบังคับต้องส่งการเปลี่ยนแปลงกลับให้ผู้เขียนต้นฉบับใน AGPL ทั้งที่จริงเพียงแค่ต้องเปิดเผยต่อผู้ใช้เท่านั้น การดัดแปลง EUPL แบบนี้ยังทำให้รายชื่อไลเซนส์ที่เข้ากันได้แคบลงมาก จนแทบเหลือเพียง AGPL กับ OSL และสุดท้ายก็กลับไม่เข้ากันแม้แต่กับ EUPL ทางการเองด้วย

    • สำหรับข้อมูลอ้างอิง GoatCounter เป็นแพลตฟอร์มเว็บแอนะลิติกส์โอเพนซอร์ส เป็นทางเลือกที่คำนึงถึงความเป็นส่วนตัวแทน Google Analytics หรือ Matomo

  • ดูเหมือนว่าข้อกำหนดเรื่องความเข้ากันได้จะทำให้หลายความเห็นสับสน เอกสารทางการอธิบายเรื่องความเข้ากันได้ไว้ดีมาก จึงแนะนำให้อ่าน
    ภาพอธิบายความเข้ากันได้
    เมทริกซ์ไลเซนส์ที่เข้ากันได้

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

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

    • มีความเห็นว่าการใช้ไอคอนธง EU อย่างเป็นทางการทั้งที่ไม่ใช่เว็บไซต์ทางการ และยังมีตัวติดตามจำนวนมากในเว็บ เป็นเรื่องมีปัญหาและชวนให้ไม่สบายใจ

  • ลองค้นดูเพราะสงสัยความต่างระหว่าง EUPL กับ AGPL ก็พบว่ามีการประเมินว่า EUPL คล้าย AGPLv3 (affero-like) และใช้กับโมเดล SaaS ได้ด้วย
    เอกสารเปรียบเทียบอย่างเป็นทางการ

    • มีคนถามว่าสามารถหาคำอธิบายละเอียด ๆ ได้จากที่ไหน และเกี่ยวข้องกับข้อกำหนด anti-Tivoization ที่เพิ่มเข้ามาใน GPLv3 หรือไม่ อีกทั้งแม้จะเข้าใจเหตุผลที่ Linus Torvalds ยืนกรานใช้ GPLv2-only ต่างจาก Richard Stallman แต่ก็คิดว่าเป็นไปไม่ได้เลยที่จะไม่มีข้อกำหนดเรื่องการคืนประโยชน์จากการดัดแปลงแบบ SaaS อยู่ด้วย อยากให้มีเวอร์ชันแบบ AGPLv2 ที่มีเพียงการคืนผลงานสำหรับ SaaS แต่สุดท้ายก็เพิ่งตระหนักว่า EUPL เองก็มีช่องโหว่แปลก ๆ เรื่องการรีไลเซนส์อยู่ดี
      คำอธิบายจาก GNU

    • ดูเหมือนจะมีปัญหาความขัดแย้งระหว่างข้อกำหนดซอฟต์แวร์เครือข่าย (SaaS) ของ EUPL กับข้อกำหนดเรื่องความเข้ากันได้ของไลเซนส์ เพราะใครก็สามารถฟอร์กโครงการ EUPL ไปเป็น GPL แล้วทำให้ข้อกำหนดเพิ่มเติมของ EUPL หมดผลได้ จึงมองว่านี่เป็นความผิดพลาดและช่องโหว่ของ EUPL เอง แต่ตนไม่ใช่นักกฎหมายจึงไม่มั่นใจ และคิดว่าควรฟังความเห็นจากผู้เชี่ยวชาญทางกฎหมาย

    • จากประสบการณ์ส่วนตัว ต้องบอกว่ายังหาไม่เจออย่างชัดเจนในข้อความไลเซนส์ว่า มีข้อกำหนดครอบคลุม SaaS อยู่ตรงไหน ถ้าชี้เฉพาะส่วนได้จะดีมาก

    • นี่ไม่ใช่เป้าหมายหลักของ AGPL เองหรอกหรือ?

  • มีการแนะนำว่าสามารถหาเอกสารทางการที่ละเอียดมากเกี่ยวกับการตีความและวิธีใช้ไลเซนส์ EUPL ได้จาก Interoperable Europe Portal
    พอร์ทัลทางการ

    • สงสัยว่ามีการผลักดันอย่างเป็นทางการสำหรับเวอร์ชันใหม่ที่ทำให้เรื่องเหล่านี้ชัดเจนขึ้นหรือไม่

  • คิดว่าบทความต้นทางทำให้สับสนเพราะไม่ได้ระบุแหล่งที่มาของข้อความเต็มที่กล่าวถึงไว้อย่างชัดเจน
    ต้นฉบับทางการของ EUPL

    • มีความเห็นถามว่าต้องไปตรงไหนจึงจะเห็นตัวบท และมีคำอธิบายว่าเหนือส่วน "What is the EUPL" จะมีลิงก์ไปยังตัวบทไลเซนส์ในแต่ละภาษา

    • หากเลือกภาษาที่ต้องการ ก็จะไปยังข้อความเต็มของ EUPL ในภาษานั้นทันที
      ตัวอย่าง: ต้นฉบับภาษาอังกฤษ

  • มีความเห็นว่าในช่วงต้นของบทนำ EUPL ควรระบุให้ชัดเจนว่านี่คือไลเซนส์ซอฟต์แวร์ ไม่เช่นนั้นจะทำให้สับสน เพราะในบริบทด้านกฎระเบียบอย่าง EU คำว่า “ไลเซนส์” เป็นคำทั่วไปมากจนเดายากว่าเป็นไลเซนส์ประเภทไหน และอาจเป็นผลจากชื่อที่ชวนให้นึกถึง LGPL และการตลาด ดังนั้นหากเขียนให้ชัดในย่อหน้าแรกว่าเป็น “ไลเซนส์สำหรับการแจกจ่ายซอฟต์แวร์” ก็น่าจะช่วยลดความสับสนได้

    • แน่นอนว่า EUPL ไม่ได้จำกัดอยู่แค่ซอฟต์แวร์เท่านั้น จริง ๆ แล้วยังมีไลเซนส์ที่เข้ากันได้สำหรับงานที่ไม่ใช่ซอฟต์แวร์ด้วย (เช่น CC BY-SA 3.0)

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