07 พ.ย. 2568·3 นาที
Richard Stallman และซอฟต์แวร์เสรี: แนวคิดที่เปลี่ยนโค้ด
สำรวจปรัชญาซอฟต์แวร์เสรีของ Richard Stallman, โครงการ GNU และ GPL—และวิธีที่แนวคิดเหล่านี้เปลี่ยนการอนุญาตสิทธิ์ สิทธิของนักพัฒนา และระบบนิเวศโอเพนซอร์ส
สำรวจปรัชญาซอฟต์แวร์เสรีของ Richard Stallman, โครงการ GNU และ GPL—และวิธีที่แนวคิดเหล่านี้เปลี่ยนการอนุญาตสิทธิ์ สิทธิของนักพัฒนา และระบบนิเวศโอเพนซอร์ส
ซอฟต์แวร์ไม่ใช่แค่ผลิตภัณฑ์เชิงเทคนิค—มันยังเป็นชุดของสิทธิ์: ใครรันมันได้ ใครคัดลอก แบ่งปันกับเพื่อน แก้บั๊ก หรือสร้างสิ่งใหม่อยู่บนมันได้ คำถามเหล่านี้ถูกตอบโดยไม่ใช่แค่โค้ด แต่โดยการอนุญาต (licensing). เมื่อซอฟต์แวร์กลายเป็นหัวใจของงาน การสื่อสาร และการวิจัย กฎเกี่ยวกับ “สิ่งที่คุณได้รับอนุญาตให้ทำ” เริ่มมีอิทธิพลต่อการสร้างนวัตกรรมไม่แพ้กับฟีเจอร์
Richard Stallman (มักเรียกสั้น ๆ ว่า “RMS”) สำคัญเพราะเขาทำให้กฎเหล่านั้นไม่สามารถมองข้ามได้ ในต้นทศวรรษ 1980 เขาเห็นการเปลี่ยนแปลง: โปรแกรมจำนวนมากถูกแจกจ่ายโดยไม่มีซอร์สโค้ด และผู้ใช้ถูกบอกว่าพวกเขาใช้ซอฟต์แวร์ได้เพียงตามเงื่อนไขของคนอื่น Stallman มองเรื่องนี้ไม่ใช่แค่ความไม่สะดวก แต่เป็นการสูญเสียเสรีภาพของผู้ใช้และนักพัฒนา—และเขาตอบโต้ด้วยการเสนอชุดหลักการและเครื่องมือทางกฎหมายเพื่อปกป้องเสรีภาพเหล่านั้น
บทความนี้มุ่งเน้นที่แนวคิดของ Stallman และผลลัพธ์เชิงปฏิบัติ: คำจำกัดความของซอฟต์แวร์เสรี โครงการ GNU copyleft และ GNU General Public License (GPL)—และวิธีที่สิ่งเหล่านี้หล่อหลอมระบบนิเวศโอเพนซอร์สยุคใหม่และบรรทัดฐานการอนุญาตซอฟต์แวร์
นี่ไม่ใช่ชีวประวัติ และไม่ใช่เจาะลึกด้านเทคนิคเกี่ยวกับการคอมไพล์เคอร์เนลหรือการจัดการรีโพ คุณไม่จำเป็นต้องมีพื้นฐานการเขียนโปรแกรมเพื่ออ่านต่อ
Stallman มีอิทธิพลและยังเป็นบุคคลที่มีความขัดแย้ง เป้าหมายที่นี่คือการยืนอยู่บนพื้นฐานข้อเท็จจริงและอ่านง่าย: สิ่งที่เขาโต้แย้ง เครื่องมือทางกฎหมายที่ปรากฏ ธุรกิจและนักพัฒนาปรับตัวอย่างไร และที่ไหนที่ยังมีการถกเถียงต่อเนื่อง—เพื่อให้คุณเห็นว่าทำไมผลงานของเขาจึงยังมีผลต่อการเลือกซอฟต์แวร์ในชีวิตประจำวัน
“ซอฟต์แวร์เสรี” มักเข้าใจผิดเพราะคำว่า ฟรี ฟังเหมือนราคาหรือของฟรี Richard Stallman ใช้คำว่า ฟรี ในความหมายของ เสรีภาพ—ความสามารถของผู้ใช้ในการควบคุมซอฟต์แวร์ที่พวกเขาพึ่งพา
ถ้าโปรแกรมมีราคา $0 แต่คุณไม่ได้รับอนุญาตให้ตรวจสอบ แก้ไข หรือแบ่งปัน มันอาจจะเป็น “ฟรีแบบเบียร์ฟรี” ในทางราคา แต่ยังคง ไม่เสรี ในความหมายที่ Stallman ให้ความสำคัญ
ซอฟต์แวร์เสรีถูกกำหนดด้วยสิทธิพื้นฐานสี่ประการ:
สิทธิ์เหล่านี้เกี่ยวกับอำนาจในการกระทำ: คุณไม่ได้เป็นแค่ผู้บริโภคเครื่องมือ แต่สามารถเป็นผู้มีส่วนร่วม ตรวจสอบ ปรับแต่ง และปรับปรุงได้
สิทธิ 1 และ 3 เป็นไปไม่ได้ถ้าไม่มีการเข้าถึง ซอร์สโค้ด—คำสั่งที่มนุษย์อ่านได้ หากไม่มีซอร์สโค้ด ซอฟต์แวร์จะเหมือนเครื่องใช้ไฟฟ้าที่ปิดผนึก: คุณใช้ได้ แต่ไม่เข้าใจว่ามันทำอะไร แก้เมื่อเสียไม่ได้ หรือปรับให้เข้ากับความต้องการใหม่
การเข้าถึงซอร์สโค้ดยังสำคัญต่อความไว้วางใจ มันเปิดทางให้การตรวจสอบอิสระ (ด้านความเป็นส่วนตัว ความปลอดภัย และความยุติธรรม) และทำให้สามารถดูแลรักษาซอฟต์แวร์ต่อได้แม้ผู้พัฒนารายเดิมจะหยุดสนับสนุน
คิดถึงมื้ออาหารร้านอาหาร
นั่นคือไอเดียหลัก: ซอฟต์แวร์เสรีคือเรื่องของเสรีภาพที่ผู้ใช้ต้องการเพื่อควบคุมการคำนวณของตน
ก่อนที่ “ไลเซนส์ซอฟต์แวร์” จะเป็นเรื่องที่คนส่วนใหญ่โต้แย้ง วัฒนธรรมการเขียนโปรแกรม—โดยเฉพาะในมหาวิทยาลัยและห้องแล็บวิจัย—มักทำงานภายใต้สมมติฐานว่า หากคุณปรับปรุงเครื่องมือ คุณจะแบ่งปันการปรับปรุงนั้น ซอร์สโค้ดเดินทางพร้อมซอฟต์แวร์ ผู้คนเรียนรู้โดยอ่านงานของกันและกัน และการแก้ปัญหาแพร่ผ่านการร่วมมืออย่างไม่เป็นทางการ
วัฒนธรรมนี้เริ่มเปลี่ยนเมื่อซอฟต์แวร์กลายเป็นผลิตภัณฑ์ บริษัท (และสถาบันบางแห่ง) เริ่มถือซอร์สโค้ดเป็นข้อได้เปรียบทางการแข่งขัน การแจกจ่ายมาพร้อมข้อกำหนด “ห้ามแบ่งปัน” โค้ดหยุดมาพร้อมโปรแกรม และข้อตกลงไม่เปิดเผยข้อมูล (NDA) กลายเป็นเรื่องปกติ สำหรับนักพัฒนาที่คุ้นเคยกับการแก้ปัญหาแบบร่วมกัน การเปลี่ยนแปลงนี้ไม่ได้เป็นแค่ความไม่สะดวก แต่เป็นการเปลี่ยนกฎที่ทำให้การแก้ปัญหาโดยชุมชนกลายเป็นความเสี่ยงทางกฎหมาย
หนึ่งในเรื่องเล่าที่ถูกยกซ้ำคือเครื่องพิมพ์ที่มาถึงห้องปัญญาประดิษฐ์ของ MIT Stallman เล่าว่าเครื่องพิมพ์เครื่องใหม่มาพร้อมซอฟต์แวร์ที่แจกจ่ายเป็นไบนารีอย่างเดียว ไม่มีซอร์ส ทีมต้องการปรับโปรแกรมเพื่อจัดการแจ้งเตือนกระดาษติดหรือจัดการคิวการพิมพ์ ภายใต้บรรทัดฐาน “แฮ็กเกอร์” เดิม ใครสักคนจะแก้โค้ดและแชร์การแก้ นี่ทำไม่ได้เพราะพวกเขาไม่สามารถดูหรือแก้ซอร์สได้
ควรให้สัดส่วน: ไม่ใช่เครื่องพิมพ์เครื่องเดียวที่สร้างขบวนการทั่วโลก แต่มันเป็นตัวอย่างชัดเจนของแนวโน้มที่กว้างกว่า—เครื่องมือที่คนพึ่งพาถูกทำให้ไม่สามารถแก้ไขได้โดยผู้ใช้
สำหรับ Stallman ประเด็นหลักไม่ใช่แค่การเข้าถึงทางเทคนิค แต่เป็นการสูญเสียเสรีภาพในการร่วมมือ หากคุณศึกษาซอฟต์แวร์ไม่ได้ คุณไม่สามารถควบคุมมันได้จริง ๆ หากคุณแบ่งปันการปรับปรุงไม่ได้ ชุมชนจะกระจัดกระจายและทุกคนต้องคิดค้นการแก้ปัญหาโดยลำพัง
แรงจูงใจนี้หล่อหลอมการคิดค้นไลเซนส์ใหม่ ๆ Stallman ไม่ต้องการพึ่งความมีน้ำใจหรือบรรทัดฐานที่ไม่เป็นทางการ แต่ต้องการกฎที่รักษาความสามารถในการใช้ ศึกษา แก้ไข และแบ่งปันซอฟต์แวร์—เพื่อให้ความร่วมมือไม่สามารถถูกถอนกลับเมื่อซอฟต์แวร์กลายเป็นสินค้ามีมูลค่า
ก้าวสำคัญของ Stallman ไม่ได้เป็นแค่การเขียนแถลงการณ์—แต่เป็นการเริ่มงานวิศวกรรมที่เป็นรูปธรรม ในปี 1983 เขาประกาศ โครงการ GNU โดยมีเป้าหมายทะเยอทะยาน: สร้าง ระบบปฏิบัติการครบถ้วนที่ใครก็ใช้ ศึกษา แก้ไข และแบ่งปันได้ โดยยังคง เข้ากันได้กับ Unix เพื่อให้ผู้คนรันโปรแกรมและเวิร์กโฟลว์เดิมได้
ระบบปฏิบัติการไม่ใช่โปรแกรมเดียว—มันคือสแตกทั้งชุด GNU ตั้งใจสร้างชิ้นส่วนที่จำเป็นทุกอย่างเพื่อให้คอมพิวเตอร์ใช้ได้จริง รวมถึง:
พูดตรง ๆ: GNU สร้างงานระบบพื้นฐานทั้งหมด ไม่ใช่อุปกรณ์เดียว
ต้นทศวรรษ 1990 GNU ผลิตส่วน “userland” จำนวนมาก แต่ชิ้นสำคัญหนึ่งยังขาดคือ เคอร์เนล เมื่อ Linux ปรากฏในปี 1991 มันเติมช่องว่างนั้นได้
ดังนั้นระบบยอดนิยมหลายตัวในวันนี้จึงรวม ส่วนประกอบ GNU กับ เคอร์เนล Linux—มักเรียกกันว่า “GNU/Linux”
GNU ทำให้แนวคิดซอฟต์แวร์เสรีเป็นจริงโดยสร้างฐานการทำงานที่คนอื่นสามารถต่อยอดได้ ปรัชญาอธิบาย ทำไม เสรีภาพสำคัญ; GNU ให้เครื่องมือที่ทำให้เสรีภาพใช้งานได้จริง ทำซ้ำได้ และขยายได้
Copyleft เป็นยุทธศาสตร์ไลเซนส์ที่ออกแบบมาเพื่อรักษาซอฟต์แวร์ให้เสรี (ในความหมายของเสรีภาพ) ไม่ใช่แค่ในการปล่อยครั้งแรก แต่รวมถึงเวอร์ชันในอนาคตด้วย ถ้าคุณได้รับโค้ดที่มี copyleft คุณได้รับอนุญาตให้ใช้ ศึกษา แก้ไข และแบ่งปัน—แต่เมื่อคุณแจกจ่ายเวอร์ชันที่ดัดแปลง คุณต้องส่งต่อเสรีภาพเดียวกันนั้นให้คนอื่น
Copyleft ฟังดูเหมือน “ต่อต้านลิขสิทธิ์” แต่มันอาศัยกฎหมายลิขสิทธิ์ ผู้เขียนใช้สิทธิ์ลิขสิทธิ์ของตนเพื่อตั้งเงื่อนไขในไลเซนส์: “คุณอาจคัดลอกและแก้ไขนี้ แต่ถ้าคุณแจกจ่าย คุณต้องเก็บมันไว้ภายใต้ไลเซนส์นี้” หากไม่มีลิขสิทธิ์ จะไม่มีกลไกทางกฎหมายเพื่อบังคับเงื่อนไขเหล่านี้
คิดมันเป็นกฎที่ติดตามโค้ด:
เป้าหมายคือป้องกันรูปแบบที่ Stallman กังวล: ใครสักคนเอางานชุมชน ปรับปรุง แล้วล็อกการปรับปรุงไว้
ไลเซนส์แบบ permissive (เช่น MIT หรือ BSD) อนุญาตให้ทำแทบทุกอย่างกับโค้ด รวมถึงแจกจ่ายเวอร์ชันดัดแปลงภายใต้ไลเซนส์ปิดได้ Copyleft (เช่น GNU GPL) ยังคงอนุญาตใช้งานและแก้ไขอย่างกว้าง แต่บังคับให้อนุญาตซ้ำเมื่อแจกจ่าย—เพื่อรักษาเสรีภาพลงไปยังผู้ใช้ด้านล่าง
GNU General Public License (GPL) เปลี่ยนการอนุญาตซอฟต์แวร์โดยทำให้ “การแบ่งปัน” เป็นกฎที่บังคับใช้ได้ ไม่ใช่แค่ท่าทีดี ๆ ก่อน GPL คุณอาจรับซอร์ส ปรับปรุง แล้วส่งเวอร์ชันปิดออกมาโดยผู้ใช้ไม่สามารถศึกษาได้ GPL พลิกสถานการณ์: มันปกป้องเสรีภาพผู้ใช้โดยแนบท้ายเงื่อนไขเมื่อมีการแจกจ่าย
ในทางปฏิบัติ GPL ให้สิทธิ์ในการรันโปรแกรมเพื่อวัตถุประสงค์ใดก็ได้ อ่านและแก้ซอร์ส และแบ่งปันต้นฉบับหรือเวอร์ชันที่แก้ไข
ถ้าคุณ แจกจ่าย ซอฟต์แวร์ GPL (โดยเฉพาะในผลิตภัณฑ์) คุณต้องส่งต่อเสรีภาพเดียวกัน ซึ่งโดยทั่วไปหมายถึง:
ข้อผูกพันของ GPL กระตุ้นเมื่อคุณแจกจ่ายซอฟต์แวร์ให้ผู้อื่น—เช่น ส่งไบนารี ขายอุปกรณ์ที่มีซอฟต์แวร์ หรือติดตั้งสำเนาให้ลูกค้า หากคุณแก้โค้ด GPL เพื่อใช้ภายในและไม่แจกจ่าย มักจะไม่ต้องเผยแพร่ซอร์ส
ไม่ต้องใช้ทฤษฎีกฎหมายมากนัก: ถ้าโปรแกรมของคุณรวมโค้ด GPL ในลักษณะที่สร้างงานรวม (เช่น ลิงก์เข้าเป็นส่วนหนึ่งของแอป) ผลลัพธ์มักถูกมองเป็นงานดัดแปลงและต้องแจกจ่ายภายใต้ GPL การรันโปรแกรม GPL หรือติดต่อมันเป็นกระบวนการแยกผ่านอินเทอร์เฟซปกติ มักถูกมองต่างกัน
GPLv2 เป็นเวอร์ชันคลาสสิกที่ใช้แพร่หลาย GPLv3 เพิ่มการคุ้มครองเรื่องสิทธิบัตรและการป้องกันการ “tivoization” (อุปกรณ์ที่บล็อกซอฟต์แวร์ที่แก้ไข) LGPL ออกแบบมาสำหรับไลบรารี: อนุญาตการลิงก์จากโปรแกรมเชิงพาณิชย์ภายใต้เงื่อนไขบางอย่าง แต่ยังคงทำให้ไลบรารีเสรี
ไลเซนส์เสรี (โดยเฉพาะ GNU GPL) ไม่ใช่แค่ “อนุญาต” การแบ่งปัน—แต่ปกป้องสิทธิในการศึกษา แก้ไข และแจกจ่ายซอฟต์แวร์ในลักษณะที่ยากจะย้อนกลับ สำหรับนักพัฒนา นั่นหมายความว่าการปรับปรุงของคุณสามารถคงอยู่ให้ผู้อื่นใช้ได้ภายใต้เงื่อนไขเดียวกัน แทนที่จะถูกผนวกเข้าไปในผลิตภัณฑ์ปิดที่ชุมชนเข้าถึงไม่ได้
ภายใต้ GPL คุณสามารถ:
นี่คือเหตุผลที่ GPL มักถูกอธิบายว่าเป็น “การตอบแทนที่บังคับใช้ได้” ถ้ามีคนแจกโปรแกรมที่ครอบคลุมด้วย GPL (หรืองานดัดแปลง) พวกเขาไม่สามารถเพิ่มข้อจำกัดที่ปิดกั้นผู้ใช้ด้านล่างจากการแก้ไขและแบ่งปันเหมือนกันได้
สิทธิ์เหล่านั้นมาพร้อมภาระเมื่อคุณ แจกจ่าย ซอฟต์แวร์:
ความรับผิดชอบเหล่านี้ไม่ใช่กับดัก—มันคือกลไกที่ทำให้ความร่วมมือไม่กลายเป็นการสกัดทรัพยากรทางเดียว
ทีมควรปฏิบัติตามไลเซนส์เหมือนการดูแลการปล่อยซอฟต์แวร์: ติดตามว่า:
SBOM (Software Bill of Materials) ง่าย ๆ และเช็คลิสต์การปล่อยซ้ำ ๆ สามารถป้องกันปัญหาส่วนใหญ่ได้ก่อนที่ทนายจะเข้ามาเกี่ยวข้อง
ระดับโค้ด “ซอฟต์แวร์เสรี” และ “โอเพนซอร์ส” มักอธิบายโปรเจกต์เดียวกันหลายอย่าง แต่การแยกเกิดขึ้นที่ ทำไม การแบ่งปันมีความสำคัญ
ขบวนการ Free Software (เกี่ยวข้องกับ Richard Stallman และ Free Software Foundation) มองเสรีภาพซอฟต์แวร์เป็นเรื่องจริยธรรม: ผู้ใช้ควรมีสิทธิ์รัน ศึกษา แก้ไข และแบ่งปันซอฟต์แวร์ จุดมุ่งหมายไม่ใช่แค่วิศวกรรมที่ดีกว่า แต่เพื่อปกป้องเอกราชของผู้ใช้
วิธีการ Open Source เน้นผลลัพธ์เชิงปฏิบัติ: การร่วมมือที่ดีขึ้น การวนซ้ำเร็วขึ้น บั๊กน้อยลง และความปลอดภัยที่ดีขึ้นผ่านความโปร่งใส มันสามารถเสนอแนวทางที่เป็นมิตรกับธุรกิจได้โดยไม่ต้องมีท่าทีเชิงศีลธรรม
ในปี 1998 Open Source Initiative (OSI) ทำให้คำว่า “open source” เป็นที่รู้จักเพื่อทำให้แนวคิดน่าสนับสนุนทางธุรกิจ คำว่า “free software” มักถูกเข้าใจผิดว่าแปลว่า “ไม่มีค่าใช้จ่าย” และบริษัทบางแห่งหวั่นเกรงข้อความที่เน้นสิทธิและจริยธรรม “Open source” ให้วิถีทางสำหรับองค์กรที่จะพูดว่า “เราทำงานแบบนี้ได้” โดยไม่ดูเป็นอุดมการณ์
โปรเจกต์หลายแห่งที่เรียกตัวเองว่า open source ใช้ GNU GPL หรือลิขสิทธิ์ copyleft อื่น ๆ ขณะที่อีกหลายโปรเจกต์เลือกไลเซนส์ permissive เช่น MIT หรือ Apache ข้อความทางกฎหมายอาจเหมือนกัน แต่นิทานที่เล่าให้ผู้ร่วมงาน ผู้ใช้ และลูกค้าฟังต่างกัน ข้อความหนึ่งคือ “นี่ปกป้องเสรีภาพของคุณ” อีกข้อความคือ “นี่ลด friction และปรับปรุงคุณภาพ”
ซอฟต์แวร์เสรีไม่ได้หมายความว่า “ไม่มีใครได้เงิน” มันหมายความว่าผู้ใช้มีเสรีภาพในการรัน ศึกษา แก้ไข และแจกจ่ายโค้ด หลายบริษัทสร้างรายได้รอบ ๆ เสรีภาพนั้น—มักเรียกเก็บเงินสำหรับสิ่งที่องค์กรขาดแคลนจริง ๆ: ความน่าเชื่อถือ ความรับผิดชอบ และเวลา
รูปแบบที่ใช้ได้จริงรวมถึง:
มุมร่วมสมัยของโมเดล “managed offering” คือแพลตฟอร์มที่สร้างและรันแอปได้เร็ว เช่น Koder.ai ซึ่งช่วยทีมสร้างเว็บ แบ็กเอนด์ และแอปมือถือผ่านแชท—พร้อมรองรับการส่งออกซอร์ส การรวมกันนี้ (การวนซ้ำเร็ว + การเป็นเจ้าของโค้ด) สอดคล้องกับค่านิยมเบื้องหลังเสรีภาพซอฟต์แวร์: ความสามารถในการตรวจสอบ แก้ไข และย้ายซอฟต์แวร์เมื่อจำเป็น
การเลือกไลเซนส์ช่วยกำหนดว่าใครจับมูลค่าได้:
“เชิงพาณิชย์” บอกว่า ขายอย่างไร; “ซอฟต์แวร์เสรี” บอกว่า สิทธิของผู้ใช้คืออะไร บริษัทสามารถขายซอฟต์แวร์เสรี เก็บเงินค่าการสนับสนุน และยังเคารพเสรีภาพซอฟต์แวร์ได้
ก่อนนำหรือพึ่งพาผลิตภัณฑ์จากโปรเจกต์ FOSS ถามตัวเอง:
GPL และ “FOSS” ถูกพูดถึงมาก แต่มีตำนานซ้ำ ๆ ที่ทำให้ความเข้าใจคลุมเครือ—โดยเฉพาะสำหรับทีมที่แค่อยากออกผลิตภัณฑ์โดยไม่ทำผิดไลเซนส์
ไม่ได้เป็นเช่นนั้น สาธารณสมบัติ หมายถึงไม่มีเจ้าของลิขสิทธิ์บังคับเงื่อนไข—ใครก็ใช้ได้โดยไม่มีพันธะ
GNU GPL เป็นสิ่งตรงกันข้ามกับ “ไม่มีเงื่อนไข” ผู้เขียนยังคงถือครองลิขสิทธิ์และให้สิทธิ์กว้างในการใช้ แก้ไข และแบ่งปัน—แต่มีเงื่อนไขที่ต้องปฏิบัติตาม (ที่เด่นคือ การแชร์ซอร์สเมื่อแจกจ่ายไบนารี)
การเปิดโค้ดช่วยด้านความปลอดภัยได้ แต่ไม่รับประกัน โครงการเปิดซอร์สก็ยังอาจ:
ความปลอดภัยมาจากการบำรุงรักษาเชิงรุก การตรวจสอบและกระบวนการเผยช่องโหว่อย่างรับผิดชอบ ไม่ใช่แค่ป้ายไลเซนส์
ผู้คนมักเรียก GPL ว่า “viral” เพื่อสื่อว่ามันแพร่ไปในทุกสิ่งที่สัมผัส นั่นเป็นการเปรียบเทียบที่หนักไป
สิ่งที่มักหมายถึงคือ copyleft: ถ้าคุณแจกจ่ายงานดัดแปลงของโค้ด GPL คุณต้องให้ซอร์สที่สอดคล้องภายใต้ GPL ข้อกำหนดนี้มีเจตนา: เพื่อรักษาเสรีภาพของผู้ใช้ด้านล่าง มันไม่ใช่ “การติดเชื้อ” แต่เป็นเงื่อนไขที่คุณเลือกจะยอมรับหรือหลีกเลี่ยงด้วยการใช้โค้ดประเภทอื่น
กฎโดยทั่วไป: ข้อผูกพันกระตุ้นเมื่อมีการแจกจ่าย
เมื่อมันสำคัญ ให้ขอคำอ่านที่แม่นยำตามรูปแบบการรวมและการแจกจ่าย ไม่ใช่แค่สมมติฐาน
Richard Stallman เป็นบุคคลที่มีความขัดแย้งได้ การยอมรับเรื่องนั้นและยังพูดถึงอิทธิพลที่ยืนยาวของแนวคิดและไลเซนส์ที่เกี่ยวข้องกับเขาเป็นสิ่งเป็นไปได้
จุดเริ่มต้นที่มีประโยชน์คือแยกสองการสนทนา: (1) การถกเถียงเกี่ยวกับ Stallman ในฐานะบุคคลและสมาชิกชุมชน และ (2) ผลกระทบที่วัดได้ของหลักการซอฟต์แวร์เสรี โครงการ GNU และ GNU GPL ต่อการอนุญาตซอฟต์แวร์และสิทธิของนักพัฒนา ฝ่ายหลังสามารถถกด้วยแหล่งข้อมูลต้นทาง (ข้อความไลเซนส์ ประวัติโปรเจกต์ แบบแผนการนำไปใช้) แม้ผู้คนจะแตกต่างกันเรื่องความคิดเห็นเกี่ยวกับด้านแรก
ข้อวิจารณ์ประจำหนึ่งไม่ได้เกี่ยวกับไลเซนส์เลย แต่เกี่ยวกับการกำกับดูแล: โปรเจกต์ตัดสินใจอย่างไร ใครมีอำนาจ และจะเกิดอะไรขึ้นเมื่อผู้ก่อตั้ง ผู้ดูแล และผู้ใช้ต้องการสิ่งต่างกัน ชุมชนซอฟต์แวร์เสรีต่อสู้กับคำถามเช่น:
คำถามเหล่านี้สำคัญเพราะไลเซนส์ตั้งเงื่อนไขทางกฎหมาย แต่ไม่สร้างกระบวนการตัดสินใจที่ดีโดยตัวมันเอง
การถกเถียงอีกด้านมุ่งไปที่ความครอบคลุมและบรรทัดฐานชุมชน: โปรเจกต์ตั้งความคาดหวังในการประพฤติอย่างเคารพอย่างไร แก้ความขัดแย้งอย่างไร และเปิดต้อนรับผู้เริ่มต้นแค่ไหน ชุมชนบางแห่งเน้นโค้ดการปฏิบัติที่ชัดเจน บางแห่งชอบกฎขั้นต่ำและการดูแลแบบไม่เป็นทางการ ไม่มีวิธีใดถูกต้องอัตโนมัติ แต่ผลกระทบและการเลือกแนวทางมีผลจริง
ถ้าคุณประเมินมรดกของ Stallman จะเป็นประโยชน์ถ้าแยกคำกล่าวอ้างให้ตรวจสอบได้: GPL กำหนดอะไร Copyleft เปลี่ยนแนวปฏิบัติการปฏิบัติตามอย่างไร และแนวคิดเหล่านี้มีอิทธิพลต่อไลเซนส์และสถาบันอย่างไร คุณสามารถวิจารณ์ สนับสนุน หรือยังไม่ตัดสิน—แต่ควรมุ่งสู่ความแม่นยำ เคารพ และความชัดเจนในสิ่งที่ถูกวิพากษ์วิจารณ์
ของขวัญเชิงปฏิบัติที่ Stallman ให้ทีมทั่วไปคือคำถามชัดเจน: คุณต้องการให้เสรีภาพอะไรคงอยู่ต่อไปสู่ผู้ใช้ด้านล่าง? การตอบคำถามนั้นเปลี่ยนการเลือกไลเซนส์จากความรู้สึกเป็นการตัดสินใจ
ถ้าไม่แน่ใจ เลือกตามเป้าหมาย: การยอมรับ (permissive) vs การตอบแทน (copyleft) vs ความเป็นมิตรต่อไลบรารี (weak copyleft)
LICENSE ในรากรีโพ (คัดลอกข้อความไลเซนส์ทั้งหมด)ถ้าคุณสร้างผลิตภัณฑ์ด้วยการพัฒนาด้วย AI (รวมถึงแพลตฟอร์มแชทอย่าง Koder.ai) เช็คลิสต์นี้ยิ่งสำคัญ: คุณยังส่งมอบการพึ่งพาจริง ชิ้นงานจริง และภาระผูกพันด้านไลเซนส์ ความเร็วไม่ลบล้างความรับผิดชอบ—แต่ทำให้กระบวนการปฏิบัติตามแบบทำซ้ำได้มีคุณค่ามากขึ้น
ทำให้มันน่าเบื่อและทำซ้ำได้:
สำหรับการเปรียบเทียบเชิงลึกเพิ่มเติม ให้ดูบทความเกี่ยวกับการเลือกไลเซนส์โอเพนซอร์ส และการเปรียบเทียบ GPL vs MIT vs Apache.
“ซอฟต์แวร์เสรี” หมายถึง เสรีภาพ ไม่ใช่ราคา
โปรแกรมหนึ่งอาจมีราคา $0 แต่ยังคงเป็น ไม่เสรี หากคุณไม่สามารถตรวจสอบ แก้ไข หรือแบ่งปันมันได้ ซอฟต์แวร์เสรีให้ความสำคัญกับสิทธิในการรัน ศึกษา เปลี่ยนแปลง และแจกจ่ายซอฟต์แวร์ที่คุณพึ่งพา
คำจำกัดความขึ้นอยู่กับสี่สิทธิพื้นฐาน:
หากสิทธิใดหายไป ผู้ใช้จะสูญเสียการควบคุมและความร่วมมือจะยากขึ้น
เพราะคุณไม่สามารถ ศึกษาหรือแก้ไข ซอฟต์แวร์ได้อย่างแท้จริงหากไม่มีซอร์สโค้ด
การเข้าถึงซอร์สโค้ดช่วยให้สามารถ:
Copyleft ใช้กฎหมายลิขสิทธิ์เพื่อบังคับให้เมื่อคุณแจกจ่าย ต้องแจกจ่ายในลักษณะ “แชร์เหมือนกัน”
คุณใช้และแก้ไขได้ รวมถึงขายได้ แต่ถ้าคุณ แจกจ่าย เวอร์ชันที่ดัดแปลง คุณต้องให้ผู้รับมีเสรีภาพเดียวกัน (โดยปกติคือปล่อยซอร์สที่สอดคล้องภายใต้ไลเซนส์เดิม)
GPL มอบสิทธิ์กว้าง (รัน ศึกษา แก้ไข แจกจ่าย) และขอการตอบแทนเมื่อมีการแจกจ่าย
ถ้าคุณ แจกจ่าย ไบนารีที่ครอบคลุมด้วย GPL ปกติคุณต้อง:
โดยทั่วไปแล้ว ไม่เสมอไป
ข้อผูกพันของ GPL มักจะเกิดขึ้นเมื่อคุณ แจกจ่าย หากคุณแก้ไขโค้ด GPL เพื่อใช้ภายในองค์กรและไม่แจกสำเนาให้คนนอก มักจะไม่ต้องเผยแพร่ซอร์ส
(มีกรณีย่อย—ให้ถือเป็นแนวทางทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย)
ขึ้นกับวิธีรวมโค้ด
โดยทั่วไป:
เมื่อสำคัญ ให้แมปรูปแบบการรวมก่อนส่งมอบ
พวกเขาต่างเน้นประเด็นต่างกัน:
เลือกตามว่าต้องการการตอบแทนแบบเข้มข้น (GPL) หรือต้องการความเป็นมิตรต่อไลบรารี (LGPL)
โดยปกติไม่ภายใต้ GPL
ถ้าคุณรันซอฟต์แวร์ GPL บนเซิร์ฟเวอร์ของคุณและผู้ใช้โต้ตอบผ่านเครือข่าย ปกติไม่ถือว่าเป็นการ “แจกจ่าย” ดังนั้นข้อผูกพันการเปิดซอร์สของ GPL มักไม่ถูกกระตุ้น
ถ้าคุณต้องการให้การใช้งานทางเครือข่ายบังคับให้เปิดซอร์ส ให้พิจารณา AGPL และประเมินโมเดลการปรับใช้ของคุณอย่างรอบคอบ
ใช่—หลายบริษัทสร้างรายได้จากซอฟต์แวร์เสรีผ่านบริการและการส่งมอบ แทนการจำกัดสิทธิ์ผู้ใช้
รูปแบบทั่วไปได้แก่:
การเลือกไลเซนส์มีผลต่อกลยุทธ์: แบบ permissive ช่วยเพิ่มการยอมรับ ส่วน copyleft ช่วยปกป้องการตอบแทนแบบร่วมกัน