Theppitak's blog

My personal blog.

25 พฤศจิกายน 2557

FOSS Behind my Wedding

blog นี้เป็น blog แรกที่ผมเขียนภายใต้สถานภาพ สมรส หลังจากที่ได้เข้าพิธีแต่งงานไปเมื่อวันที่ 26 ต.ค. ที่ผ่านมา (นับถึงวันที่ 25 พ.ย. ที่เขียน blog นี้ ก็ครบ 30 วันพอดี)

ชีวิตผมซึ่งอยู่กับ ซอฟต์แวร์เสรี และ โอเพนซอร์ส อยู่แล้ว ก็เป็นธรรมดาที่จะมีสิ่งนี้เข้ามาพัวพันกับงานครั้งนี้

วีดิทัศน์

เริ่มจากการเตรียมวีดิทัศน์แนะนำตัวบ่าว-สาว ผมกับเจ้าสาวช่วยกันคัดรูปถ่ายของพวกเราตั้งแต่วัยเด็กจนโต แล้วนำมาสร้างเป็นวีดิทัศน์เล่นภาพสไลด์พร้อมเพลงประกอบ

เครื่องมือแรกที่ใช้คือ dvd-slideshow ซึ่งเป็นชุด command-line สำหรับสร้างวีดิทัศน์จากแฟ้ม spec ซึ่งเป็น text file แต่ติดปัญหาว่ามันมี error message และ gen video ไม่สำเร็จ จึงได้ file Debian #750626 พร้อมเสนอแพตช์แก้ ซึ่งเริ่มมีผลในรุ่น 0.8.4.2-3 ของ Debian

นั่นเป็นการทดลองเครื่องมือก่อน แต่เมื่อเริ่มได้รูปภาพจำนวนหนึ่งมา การจะนั่งจัดเรียงภาพด้วยการ edit text file พร้อมกับเจ้าสาวซึ่งไม่ใช่นักคอมพิวเตอร์ มันก็ลำบากอยู่ จึงได้ไปหาเครื่องมือตัวอื่น จนกระทั่งพบ imagination ซึ่งเป็น GUI โดยใช้ GTK+ 2.0 ซึ่งทำให้สามารถลากจัดลำดับรูปภาพได้ พร้อมกับมี transition ที่หลากหลายกว่า

ปัญหาเกิดขึ้นเมื่อจะ gen video กลับ gen ไม่ได้ เพราะหา FFmpeg ไม่เจอ เนื่องจาก FFmpeg ได้ถูกตัดออกจาก Debian ไปแล้ว จึงได้ไปค้นบั๊กของ Debian พบ Debian #722293 ซึ่งมีผู้รายงานไว้ และได้ forward bug ไปที่ต้นน้ำ (Imagination #78) จึงตามไปคุยและเสนอแพตช์ที่ต้นน้ำ พร้อมกลับมาแปะแพตช์ไว้ที่ Debian ด้วย

ผู้พัฒนาต้นน้ำดูจะไม่กระตือรือร้นสักเท่าไรกับแพตช์ที่เสนอ หลังจากตรวจสอบไปก็พบว่า FFmpeg ยังไม่ตาย ไม่ได้เปลี่ยนชื่อเป็น libav อย่างที่ผู้ดูแลแพกเกจใน Debian และ Ubuntu พยายามจะสื่อถึงผู้ใช้ แต่ libav เป็น fork หนึ่งของ FFmpeg ซึ่งทีม Debian เลือกมาใช้แทน แต่ในดิสโทรอื่นยังคงใช้กันอยู่ และผู้ใช้ Debian/Ubuntu บางส่วนก็ต้องการกลับไปใช้ FFmpeg เหมือนเดิม (อ่าน ตัวอย่างเรื่องเล่าสถานการณ์) และมีนักพัฒนา Debian เสนอกลับเข้ามาใหม่ จนกระทั่ง ได้เข้า experimental และ sid ในที่สุด (แต่ไม่ทัน Jessie freeze จึงไม่มีใน Jessie)

อย่างไรก็ดี ในขณะที่ผมทำวีดิทัศน์ของผมอยู่นั้น Debian ไม่มี FFmpeg ทั้งใน testing และ unstable จึงได้ผลักดันแพตช์ให้ imagination กลับมาทำงานได้ โดยเพิ่มระดับความรุนแรงของ Debian #722293 จาก important เป็น grave เพื่อให้มันกลายเป็น RC bug เพราะถึงอย่างไร FFmpeg ก็จะไม่มีใน Jessie ถ้า Debian จะออก Jessie พร้อมกับ imagination ที่ต้องการ FFmpeg มันก็จะไม่สามารถ gen video ได้เลย จนในที่สุด แพตช์ก็เริ่มมีผลในรุ่น 3.0-5 ของ Debian ส่วนที่ต้นน้ำนั้น ผมเข้าใจแล้วว่าบั๊กนี้ไม่ถือว่ารุนแรงนอก Debian/Ubuntu

เป็นอันว่า กว่าผมจะเริ่มทำวีดิทัศน์ได้ ก็ได้แก้ RC bug ใน Debian ไปแล้ว 2 bug และสามารถสร้างวีดิทัศน์ได้ตามที่ต้องการ

พิมพ์ซอง

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

ผมเริ่มจากเขียน shell script เอง โดยอ่านรายชื่อจาก text file มาสร้างแฟ้ม LaTeX ก่อนคอมไพล์เป็น PDF ทีละราย แต่นั่นทำให้จำนวนไฟล์เยอะมาก PDF 1 แฟ้มต่อแขก 1 คน

ผมจึงมองหาวิธีทำ mail merge ใน LaTeX ดู ก็พบแพกเกจ mailmerge แต่ปรากฏว่าต้องใส่รายชื่อใน LaTeX source เลย แทนที่จะแยกออกมาข้างนอกต่างหาก กลายเป็นว่า PDF ไฟล์เดียวมีซองของแขกทุกคน ทำให้เพิ่มแขกที่จะเชิญทีละกลุ่มได้ลำบาก (คุณนึกออกไหม? เวลาที่นึกได้ว่าควรเชิญญาติคนนั้นเพิ่ม เพื่อนคนนู้นทวงการ์ดเชิญ เพื่อนที่ได้การ์ดแนะนำว่าควรเชิญคนนั้นคนนี้เพิ่มอีก ฯลฯ ผมจึงต้องเตรียมพร้อมที่จะพิมพ์ซองเพิ่มได้ตลอดเวลา)

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

สำหรับ LaTeX ไม่พบบั๊กอะไรครับ ใช้งานได้ราบรื่นดี รายละเอียดการใช้งานสามารถศึกษาจากเอกสารของแพกเกจได้ไม่ยาก (บน Debian ก็แค่สั่ง texdoc ชื่อแพกเกจ บนเทอร์มินัล) หรือถ้ามีเวลา ผมอาจจะเขียนวิธีการในภายหลัง

นั่นคือการใช้ FOSS ในการเตรียมงานแต่งงานของผมครับ ผ่านมาได้ด้วยดี ก็บันทึกไว้เป็นกรณีศึกษาเสียหน่อย :-)

ป้ายกำกับ: , , ,

12 ตุลาคม 2554

Sarabun to be Freed

ข่าวดีข่าวหนึ่งที่ผมได้รับมาตั้งแต่ตอนที่ยังอยู่ที่ DebConf ที่บอสเนียก็คือ ฟอนต์ชุด DIP/SIPA ได้รับอนุมัติให้เปลี่ยน license เป็น GPL แล้ว โดยครั้งนี้ได้รับอนุมัติจากทั้งผู้อำนวยการ (รักษาการ) SIPA และอธิบดีกรมทรัพย์สินทางปัญญาเลย จึงถือได้ว่ามีผลทางกฎหมายแน่นอน

ว่าจะเขียนถึงเรื่องนี้แต่ก็ติดงานโน่นนี่จนไม่ได้เขียนเสียที นี่ก็ล่วงเลยมา 3 เดือนครึ่งแล้ว ถึงจะช้าแต่ก็ยังอยากเขียนถึง

นับว่าเป็นความคืบหน้าอย่างมากสำหรับการผลักดันฟอนต์ชุดนี้เข้าในดิสโทรลินุกซ์ต่าง ๆ ที่เหลือก็คือ รอให้ทีมงานของ SIPA ปรับแก้ข้อมูล license ของฟอนต์ตามที่ได้รับอนุมัติแล้วประกาศออกฟอนต์ชุดใหม่อย่างเป็นทางการ เพื่อที่เราจะได้มีวัตถุดิบที่สามารถใช้เป็นฐานในการพัฒนากันต่อไป

อีกเรื่องหนึ่งที่อยากเสนอแนะก็คือ ควรมี upstream maintainer ที่จะคอยดูแลและรับแพตช์จากที่ต่าง ๆ เพราะถ้าประกาศออกไปด้วย GPL เฉย ๆ ก็ยากที่จะควบคุมมาตรฐานของฟอนต์ คนที่เอาไปดัดแปลงแก้ไขก็ไม่รู้ว่าจะส่งแพตช์ปรับปรุงไปที่ไหน ก็เป็นไปได้ที่จะมีการ fork ออกไปมากมาย

แน่นอนว่าทางเลือกที่ดีที่สุดคือ SIPA เป็นผู้ดูแลเอง หรือมิฉะนั้น ก็อาจจะให้คนภายนอกตั้งโครงการขึ้นมา เหมือนที่ TLWG คอยดูแลฟอนต์แห่งชาติของเนคเทคผ่านโครงการ thaifonts-scalable อยู่ ซึ่งอันที่จริง ก็ได้มีโครงการ thaifonts-siampradesh ที่ดัดแปลงไปจากฟอนต์ชุด DIP/SIPA อยู่ก่อนแล้ว ถ้าจะให้ดูแลต่อก็ย่อมเป็นไปได้ เพียงแต่เราอาจจะขาดทรัพยากรสำหรับ OS อื่นที่ไม่ใช่ลินุกซ์ไปเท่านั้น

แต่ไม่ว่าอย่างไร ตอนนี้ผู้ครองบอลคือ SIPA ที่จะต้องออกฟอนต์ชุดใหม่อย่างเป็นทางการเสียก่อน ฝ่ายอื่น ๆ จึงจะสามารถรับลูกไปทำต่อได้

หัวข้อนี้ เมื่อรวมกับหัวข้อ localization ของเนคเทค ก็สามารถบรรจุเป็นวาระใน workshop ของ Thailand Mini-DebConf 2011 ได้เหมือนกันนะนี่

ป้ายกำกับ: ,

15 มิถุนายน 2554

The Case of Sarabun IT9

เป็นเรื่อง.. เมื่อมติ ครม. สองอย่าง คือให้ใช้ฟอนต์สารบรรณและเลขไทยในเอกสารราชการ ได้ผสมกันทำให้เกิดกรณี ฟอนต์ Sarabun IT9 ที่ดัดแปลงฟอนต์สารบรรณในชุด 13 ฟอนต์โพสต์การ์ดแวร์ของ DIP-SIPA ให้ป้อนเลขไทยด้วยแป้นตัวเลข (numpad) ได้ แต่เป็นวิธีที่ไม่ถูกหลักการ คือไปเปลี่ยนรูปร่างของตัวเลขอารบิกให้เป็นเลขไทย ทำให้ข้อมูลที่เก็บลงในแฟ้มแตกต่างจากสิ่งที่แสดงบนหน้าจอ

เรื่องนี้ต้องแยกพูดเป็นสองประเด็น คือประเด็นเรื่องกฎหมาย กับประเด็นเรื่องเทคนิค

ประเด็นเรื่องกฎหมายนั้น ข้อมูลที่ผมได้รับจากการพูดคุยกับเพื่อนใน Facebook ก็คือ ผู้ดัดแปลงฟอนต์ Sarabun IT9 ได้แจ้งเป็นลายลักษณ์อักษร แต่ไม่ได้รับอนุญาตให้ดัดแปลง (กรมทรัพย์สินทางปัญญาอนุญาต แต่ SIPA ไม่อนุญาต) จึงได้ลบฟอนต์ออกจากเว็บดาวน์โหลด แต่นั่นก็สายไปแล้ว เพราะฟอนต์ได้เผยแพร่ออกไปในเน็ตเรียบร้อยแล้ว

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

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

ผมพอเข้าใจแนวคิดของ SIPA ได้ ที่ไม่ยอมอนุญาตให้ดัดแปลงแบบนี้ น่าจะเป็นเหตุผลทางเทคนิคเป็นหลัก แต่ในทางกฎหมายแล้ว นี่กลับเป็นการแสดงให้เห็นจริงว่าฟอนต์ชุดนี้ไม่ได้ "ส่งเสริมการร่วมมือในการสร้างสรรค์ฟอนต์ในวงกว้าง" อย่างที่โปรยไว้ที่ต้นสัญญาอนุญาต

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

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

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

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

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

ป้ายกำกับ: ,

10 มิถุนายน 2554

FOSS Why and How

เมื่อวันที่ 7 มิ.ย. ได้รับเกียรติจากศูนย์คอมพิวเตอร์ มข. ให้ไปบรรยายเรื่องโอเพนซอร์สเนื่องในโอกาสครบรอบ 25 ปีของศูนย์ฯ ก็เลยถือโอกาสรวบรวมเกร็ดความคิดต่าง ๆ เกี่ยวกับซอฟต์แวร์เสรีและโอเพนซอร์สที่เคยคิดหรือพูดไว้ในโอกาสต่าง ๆ ของตัวเอง มาเรียบเรียงเป็นเรื่องราว

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

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

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

ป้ายกำกับ:

18 มกราคม 2554

th.gnome.org Closed

เว็บ th.gnome.org ล่มมาสามเดือนกว่าแล้ว โดยที่ไม่มีใครเดือดร้อนหรือทักท้วงอะไร อีกทั้ง hit stat ในช่วงที่เปิดทำงานอยู่ก็ไม่ได้สูงอะไร ก็คงเป็นสัญญาณว่ามันไม่มีประโยชน์ใด ๆ กับใครนัก ในขณะที่การดูแลเว็บนั้นกินเวลาใช่เล่น สแปมเป็นเสมือนปลวกที่กัดกินบ้านที่ไม่มีใครดูแลเพื่อย่อยสลายวัสดุให้กลับคืนสู่ธรรมชาติ การต้องคอยกำจัดปลวกในบ้านร้างก็เป็นเรื่องที่เสียเวลาโดยใช่เหตุ ในเมื่อยังมีงานด้านอื่น ๆ ให้ทำอีกมากมาย ฉะนั้น ผมจึงถือโอกาสปิดเว็บ GNOME ไทย โดยไม่พยายามกู้คืน

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

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

ด้วยเหตุผลต่าง ๆ ข้างต้น จึงนำมาสู่ข้อสรุปของผมที่จะไม่พยายามกู้เว็บ GNOME ไทย กลับคืน (แม้จะกู้ไม่ยากเท่าไร) ขอขอบคุณ MrChoke สำหรับการสนับสนุน hosting ตลอดเวลาที่ผ่านมาครับ

ป้ายกำกับ: , ,

06 ตุลาคม 2553

OSSFest 2010

เพิ่งกลับมาถึงบ้านครับ จากงาน OSSFest 2010 ที่สถาบันปัญญาภิวัฒน์ งานเขามีสองวัน 30 ก.ย. - 1 ต.ค. (พฤหัส-ศุกร์) จบงานแล้วผมก็อยู่ทำธุระต่อ จนกระทั่งเพิ่งกลับขอนแก่นเมื่อวานนี้

ในงานก็ได้พบปะกับหลาย ๆ คน ได้ฟังความรู้ความคิดเห็นจากหลาย ๆ ท่าน

คุณ James Clark: FOSS ในยุค cloud และ mobile

วันแรกหลังพิธีเปิด คุณ James Clark บรรยายเกี่ยวกับความสำคัญของ FOSS ในยุค cloud และ mobile โดยได้ให้ทัศนะว่าความสำคัญจะย้ายไปอยู่ที่ผู้ให้บริการและองค์กรมากขึ้น ซึ่งก็น่าจะเป็นอย่างนั้น ตามแนวโน้มของการเกิดและใช้งาน web application มากขึ้นเรื่อย ๆ แต่ก็แอบคิดแย้งในประเด็นที่บอกว่า FOSS นั้น ไม่สำคัญเลยกับผู้ใช้ mobile

คุณเจมส์บอกว่า ผู้ใช้ mobile ไม่สนใจหรอก ว่าซอฟต์แวร์ที่ใช้ในโทรศัพท์นั้นเป็น FOSS หรือไม่ ผมคิดว่าไม่จริง เอาง่าย ๆ ถ้าพูดกันแค่เรื่องราคา ผู้ใช้ก็มีแนวโน้มเลือกโปรแกรมฟรีก่อนโปรแกรมซื้อถ้ามันใช้งานได้ดีพอ และสำหรับคนที่คุ้นเคยกับเสรีภาพที่จะแก้บั๊กต่าง ๆ ด้วยตัวเอง การต้องกลับไปใช้ซอฟต์แวร์ที่มัดมือมัดเท้าไม่ให้ทำอะไรได้ก็จะรู้สึกอึดอัด ก็มันเคย apt-get ได้แทบทุกอย่าง มีบั๊กก็ apt-get source มาแก้แล้ว file bug หรืออยากจะดัดแปลงอะไรก็ทำได้ตามถนัด พอมาใช้มือถือก็ยังอยากได้ความสะดวกสบายแบบนั้น ที่ยังใช้ Android ที่ยังไม่สามารถ root ได้อยู่ ก็ยังหวังว่าสักวันหนึ่งเราจะได้เป็นเจ้าของแบบเต็ม ๆ คือจะทำอะไรกับมันก็ได้เหมือนอย่าง Debian on FreeRunner อยู่นะครับ

อ.กิตติ์ เสริมเรื่องความโปร่งใสของซอฟต์แวร์ อีกประเด็นหนึ่ง

คุณ roofimon กับคอร์สวิศวกรรมซอฟต์แวร์แบบสบาย ๆ

จากบรรยายของคุณเจมส์ ก็มาต่อที่ community edition ซึ่งเริ่มงานช้ากว่าปกติ เพราะต้องรอพักทานกาแฟกันก่อน การพูดตอนเช้า 3 รายการก็เลยถูกหดเวลาลงจากคนละ 50 นาทีเหลือคนละ 30 นาที ผมเริ่มคนแรก กับหัวข้อ "How to Contribute to Debian" เลยต้องพยายามรักษาเวลาเต็มที่ พูดแบบติดเทอร์โบชนิดไม่เคยทำมาก่อนในชีวิต ตามมาด้วยการแนะนำสิ่งใหม่ใน Ubuntu 10.10 โดยคุณมะระ ปิดท้ายก่อนพักเที่ยงโดยคุณ roofimon ว่าด้วยเรื่องวิศวกรรมซอฟต์แวร์กับภาษา Java

เครื่องมือสุดยอด ภาษาสุดยอด อะไรก็ตามแต่ที่คุณ roofimon เล่ามา รู้สึกว่าสิ่งที่สำคัญกว่านั้นในเนื้อหาคือเรื่องวินัยการพัฒนาโปรแกรม หัวอกโปรแกรมเมอร์จะเข้าใจได้ดี เวลาที่ต้องไป maintain โค้ดของคนที่เขียนโปรแกรมราวกับอยู่ท่ามกลางมรสุมชีวิต กลายเป็นโค้ดที่ "แม่สะดุ้ง" บ่อย ๆ :-P

How to Build Community

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

ผมนั่งฟังทั้งสองท่านแล้วก็เลยนึกเปรียบเทียบกับแนวทางที่ debianclub ทำอยู่ ก็เลยเปรียบเทียบให้ฟัง คือ debianclub นั้นใช้แนวทางคล้ายกับ อ.วิภัทร ตรงที่ไม่พยายามหว่านแห แต่มุ่งไปที่ผู้ใช้ที่ใช้ debian มาพอสมควรแล้ว ซึ่งก็ได้รับความช่วยเหลือจากหลายท่านในการเขียนบทความมาเผยแพร่ แต่ก็พยายามไม่ให้เนื้อหาหนักเกินไปสำหรับมือใหม่ โดยจะมีเนื้อหาเบา ๆ หรือข่าวสารมาสลับบ้าง มี forum ให้ถามคำถาม ส่วนค่าใช้จ่ายก็อาศัย donation เป็นส่วนใหญ่ คือมีทั้งคนบริจาคเครื่องเซิร์ฟเวอร์ แบนด์วิดท์ ฮาร์ดดิสก์ ฯลฯ เหลือค่าใช้จ่ายเพียงอย่างเดียวที่ยังต้องออกกันเองกับนิวตรอนอยู่คือค่า domain

PSU-12 Boot Server

ต่อจากนั้น แยกห้องทำ workshop ก็เข้าไปดู workshop ของ อ.วิภัทร เรื่องการทำ boot server สำหรับ diskless PC ที่ไม่ใช่แค่สำหรับ thin client แต่ดัดแปลงให้บูตได้หลายแบบ เป็น rescue, live CD, kiosk หรืออะไรก็ตามแต่ โดยควบคุมเป็นเครื่อง ๆ ได้ มีระบบเมนูให้เลือกบูต นับเป็น deployment ที่น่าสนใจมาก ๆ

OpenStreetMap

โดยคุณ Willi มาบรรยายเกี่ยวกับที่มาและหลักการของ OSM วิธีการนำไปใช้ วิธีการ contribute พร้อมกับปูพื้นเพื่อทำ workshop ตอนบ่ายด้วย

Translating OSS in Launchpad

โดยคุณจรูญ (Jeroen T. Vermeulen) ผู้พัฒนา Launchpad ของ Ubuntu มาเอง อธิบายว่า LP ทำอะไรได้บ้าง จะทำงานแปลจะมีวงรอบการประมวลผลยังไงบ้าง แต่สุดท้าย คำถามที่สงสัยคือ จะทำงานกับต้นน้ำยังไงดี ก็ได้รับคำตอบว่า ทีมคุณต้องไปตกลงกันเอง จบข่าว

ประวัติศาสตร์แฮกเกอร์และโอเพนซอร์สไทย

เสวนาเล่าความหลัง โดย bact' เป็นผู้ดำเนินรายการ ผู้ร่วมเสวนาก็มี Ott, มะระ แล้วก็ผม ความจริงคงมีบางคนนอนสะดุ้งอยู่ที่ชลบุรี เนื่องจากถูกพาดพิงถึงบ่อย ๆ :-)

You can eat Open Source

bact' มาดำเนินรายการต่อ สัมภาษณ์สองบริษัทที่ทำธุรกิจกับ FOSS คือ Marvelic Engine (โดยคุณ อัครวุฒิ) และ Metamedia Technology (โดย Ott)

OSM Workshop

คุณ Willi พาทุกคนออกเก็บ GPS track ในบริเวณศูนย์ประชุม แล้วกลับมาวาดแผนที่ใน JOSM ให้ดู พร้อมกับบอกเทคนิคต่าง ๆ ได้เกร็ดเล็กเกร็ดน้อยมาเยอะเหมือนกัน

อ.ปราสาท: ว่าด้วยเรื่อง 13 ฟอนต์ DIP-SIPA

มีโอกาสได้พบ อ.ปราสาท วีรกุล หนึ่งในคณะทำงานฟอนต์ DIP-SIPA ได้ทราบว่า เดิมนั้นเสนอให้ใช้ OFL กับฟอนต์ชุดนี้ แต่ฝ่ายกฎหมายของ DIP และ SIPA ได้ดัดแปลงสัญญาอนุญาตจนกลายเป็น postcardware ดังที่ปรากฏ และอาจารย์ยังได้ให้ข้อมูลอีกว่า ฟอนต์ชุดนี้รองรับผู้ใช้ Mac โดยใช้ AAT เนื่องจากการรองรับ OpenType บน Mac ยังไม่สมบูรณ์พอ ซึ่งก็คงเป็นแนวทางนำไปปรับแก้ ThaiFonts-Scalable ของ TLWG ได้

หลังงาน ก็อยู่ต่อเพื่อพบกับคุณ Martin Hosken เพื่อหารือเรื่องการแก้ไข Unicode UAX #29 เพื่อแก้ปัญหาเรื่องการเลื่อนเคอร์เซอร์ข้ามสระหน้าและสระหลังของภาษาไทย ลาว และไทดำ พร้อมกันนั้นก็ได้คุยเรื่องการรองรับภาษาของชนกลุ่มน้อยที่ใช้อักษรไทย เช่น กุย/ส่วย, เขมรตอนเหนือ ฯลฯ รวมทั้งภาษาบาลี-สันสกฤต ซึ่งต้องร่างเป็นข้อกำหนด วทท 3 ต่อไป โดยคุณ Martin ได้สาธิตการใช้ฟีเจอร์ของ Graphite ใน OO.o เพื่อเขียนภาษาบาลี-สันสกฤตด้วย แต่ยังมีปัญหาบางอย่างที่ต้องแก้ไขอยู่ จึงยังไม่เผยแพร่ในตอนนี้ ถ้าทำเสร็จแล้วก็อาจจะเป็นคำตอบสำหรับ OO.o ต่อไป รวมทั้งการเพิ่มการรองรับแบบเดียวกันกับฟอนต์ OpenType ด้วย

ก่อนกลับบ้าน มีเวลาเหลือเล็กน้อย ก็ไปเก็บ GPS track แถวแยกประชานุกูล เอากลับมาทำแผนที่ OSM ต่อที่บ้านหลังจากกลับถึงขอนแก่นแล้ว

ป้ายกำกับ: , , , ,

25 กันยายน 2553

Double-Array Trie Has Got Java Implementation

ไม่ใช่ผมทำเองหรอกครับ แต่ได้รับแจ้งจากคุณ Chris Gioran นักพัฒนาชาวกรีก ว่าได้พัฒนา double-array trie ในฉบับ Java แล้ว โดยโฮสต์ไว้ที่ github โดยอาศัยหลักการจากหน้าเว็บที่ผมเขียนไว้ สัญญาอนุญาตที่ใช้ เป็น LGPL เหมือน libdatrie ครับ

รายละเอียด มีบันทึกไว้ใน blog ของเขา

ภูมิใจจังที่ได้เขียนเอกสารฉบับนี้ไว้ และได้รู้ว่ามันมีประโยชน์ในที่ต่าง ๆ ตามที่ได้เคยบอกกล่าวมาบ้างแล้ว ว่าผู้ใช้ประโยชน์ต่อยอดส่วนใหญ่เป็นชาวต่างประเทศ มีบางครั้งได้พบชาวต่างประเทศแล้วเขาบอกว่าจำชื่อผมได้จากเว็บ double-array trie ก็รู้สึกอิ่มอกอิ่มใจ ว่างานเล็ก ๆ จากประเทศเล็ก ๆ ชิ้นนี้ก็มีประโยชน์กับเขาบ้างเหมือนกัน

ป้ายกำกับ: ,

13 กันยายน 2553

The DIP-SIPA 13 Postscardware Fonts

ถึงจะช้าไปหน่อย (ทราบข่าวหลายวันแล้ว แต่เพิ่งมีเวลาเขียน) แต่ก็ขอเขียนถึง ฟอนต์สารบรรณและ ๑๓ ฟอนต์ "แห่งชาติ" ของ SIPA และกรมทรัพย์สินทางปัญญา ที่ ครม. ได้มีมติเห็นชอบให้หน่วยงานภาครัฐติดตั้งเพื่อใช้เป็นฟอนต์มาตรฐาน

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

ข้อแรก คือการทำแบนเนอร์ "๑๓ ฟอนท์แห่งชาติ" นั้น ทำให้เกิดความสับสนกับโครงการเดิมที่มีอยู่ คือ โครงการฟอนต์แห่งชาติ ของเนคเทค ซึ่งปัจจุบัน TLWG กำลังดูแลอยู่ในฐานะส่วนหนึ่งของโครงการ ThaiFonts-Scalable ผมคิดว่าถ้าโครงการใหม่นี้ไม่ใช่การสานต่อโครงการเก่า ก็ไม่ควรจะใช้ชื่อซ้ำกันให้เป็นที่สับสน น่าจะใช้ชื่ออื่น เช่น ชื่อที่จั่วหัวในเว็บ f0nt.com ว่า ฟอนต์มาตรฐาน ก็เป็นชื่อที่ดีครับ

ข้อสอง คือปัญหาเรื่อง license ของฟอนต์ชุดนี้ ซึ่งผมเคยเขียนถึงไปหลายครั้งแล้ว (เช่น DIP-SIPA Fonts License, Thai Fonts Siampradesh (non-free), Postcardware) จะทำให้ฟอนต์ชุดนี้ไม่สามารถผลักดันให้เข้าสู่ distro กระแสหลักได้ กล่าวคือ มันจะเป็นได้อย่างดีที่สุดก็ national ไม่มีทางไปสู่ international หรือ "worldwide development" ตามเจตน์จำนงของ license ได้ และมันก็จะต้องติดแหง็กอยู่ที่ ThaiOS ของ SIPA ไปตราบชั่วฟ้า SIPA สลาย คือโครงการปิดเมื่อไรก็จบกัน ไม่มีใครสามารถจะแก้ไขปรับปรุงฟอนต์ชุดนี้ต่อไปได้อีก

ขอทบทวนปัญหาของ license อีกครั้ง เพื่อเตือนความจำว่าทำไมมันถึงจะเป็นเช่นนั้น

ปัญหาที่หนักที่สุดอยู่ที่เงื่อนไขข้อ 2 ของ license ของฟอนต์:

2. If you wish to adapt this Font Computer Program, you must notify copyright owners (DIP & SIPA) in writing.

ปัญหาคือ:

  • ใน license บอกให้เขียนแจ้งเป็นลายลักษณ์อักษร แต่ไม่ได้ระบุที่อยู่ที่จะให้แจ้งเลย ว่าจะให้ติดต่อไปที่ไหน บอกเพียงชื่อ "DIP & SIPA" เท่านั้น อย่าลืมว่าเมื่อฟอนต์นี้ go worldwide แล้ว การติดต่อหน่วยงานราชการไทยจากต่างประเทศไม่ใช่เรื่องง่าย จะไปทึกทักว่านักพัฒนาฟอนต์อิสระที่แอฟริกาจะสามารถค้นหาที่อยู่ทางไปรษณีย์ของหน่วยงานรัฐของไทยได้เองแล้วส่งมาอย่างถูกต้องนั้นไม่ได้
  • แม้กระนั้น การต้องแจ้งเป็นลายลักษณ์อักษรนั้น วัฒนธรรมเสรี (free culture) เขาถือว่าเป็นอุปสรรคที่ทำให้เลิกล้มความตั้งใจแล้วไปหาตัวเลือกอื่นได้ง่าย ๆ เพราะในทางปฏิบัติแล้ว การแจ้งเป็นลายลักษณ์อักษรจะต้องการคำตอบรับจากเจ้าของ เพื่อให้มีหลักฐานยืนยันในภายหลังว่าได้แจ้งเป็นลายลักษณ์อักษรตามเงื่อนไขของ license แล้ว และหากเจ้าของไม่ตอบรับ ก็จะไม่มีอะไรรับประกันได้เลยว่าจะสามารถเริ่มแก้ไขได้ การตอบรับหรือไม่ตอบรับจึงไม่ต่างอะไรกับการอนุญาตหรือไม่อนุญาตให้แก้ไข ดังนั้น ไม่ว่า license จะให้เสรีในการแก้ไขอย่างไรก็ตาม ถ้ามันเป็นเสรีภาพที่ต้องได้รับการอนุญาต มันก็ไม่ต่างกับการเจรจาขอใช้ license ของซอฟต์แวร์ proprietary ทั่วไปเลย
  • license นี้ขาดความยั่งยืน จะเกิดอะไรขึ้นถ้าโครงการนี้ถูกปิดไปจากแผนงานของ DIP และ SIPA คนที่เขียนเข้ามาจะได้รับการตอบสนองหรือไม่? ฟอนต์ชุดนี้คงจะตายไปพร้อมกับการปิดโครงการในหน่วยงานทั้งสองโดยไม่มีใครปรับปรุงแก้ไขต่อได้

ปัญหาของ license ข้อนี้ มีคนทำผิดพลาดบ่อยจนเขามีศัพท์เฉพาะสำหรับเรียก ว่า Postcardware และไม่ถือเป็นซอฟต์แวร์เสรีหรือโอเพนซอร์สครับ ถ้าเป็นไปได้ก็ขอเสนอให้ตัดข้อนี้ออก

ปัญหาอีกข้อหนึ่งของ license นี้คือเงื่อนไขที่ไม่ตรงกันระหว่างฉบับภาษาอังกฤษกับภาษาไทยในเงื่อนไขข้อ 3:

No adapted version of Font Computer Program may use the Reserved Font Name(s), ...

ซึ่งฉบับไทยได้แปลไว้ว่า:

เมื่อดัดแปลงโปรแกรมคอมพิวเตอร์ฟอนต์นี้แล้ว ห้ามผู้ดัดแปลงใช้ชื่อฟอนต์เดิม ...

กล่าวคือ ฉบับภาษาอังกฤษบอกว่า เมื่อดัดแปลงฟอนต์แล้ว "ห้ามใช้ชื่อที่สงวนไว้" แต่ฉบับไทยแปลว่า "ห้ามใช้ชื่อฟอนต์เดิม" ซึ่งความหมายต่างกัน และมีนัยสำคัญในทางปฏิบัติ เช่น ฟอนต์เริ่มแรกชื่อ A นายสมชายดัดแปลงแล้วเปลี่ยนชื่อเป็น B ต่อมานายสมศักดิ์เอาฟอนต์ B ของนายสมชายไปดัดแปลงต่อ ถ้า "ห้ามใช้ชื่อที่สงวนไว้" นายสมศักดิ์จะยังสามารถใช้ชื่อฟอนต์ B ต่อไปได้ เพราะไม่ใช่ชื่อที่สงวนไว้ แต่ถ้า "ห้ามใช้ชื่อฟอนต์เดิม" นายสมศักดิ์จะใช้ชื่อฟอนต์ B อีกไม่ได้ เพราะเป็นชื่อฟอนต์เดิมที่มีการคุ้มครองไว้โดย license และถ้าใครดัดแปลงต่อจากนายสมศักดิ์อีก (เช่น อาจจะเป็นโครงการ Fedora ที่จำเป็นต้องสามารถแก้บั๊กให้ผู้ใช้ได้) ก็จะต้องใช้ชื่อที่ต่างจากนายสมศักดิ์อีก เป็นอย่างนี้ทุกครั้งไป

การแก้ไข: ควรแก้คำแปลภาษาไทยให้เป็น "ห้ามผู้ดัดแปลงใช้ชื่อที่สงวนไว้" ให้เหมือนฉบับภาษาอังกฤษ

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

ป้ายกำกับ: ,

11 กรกฎาคม 2553

Software Freedom

ขอเขียนถึงเสียหน่อยน่ะ เกี่ยวกับเรื่องเสรีภาพในซอฟต์แวร์ หลังจากเจอประเด็นสะสมมาเรื่อย ๆ

ผมเคยเขียนไปหลายครั้งว่าผมพยายามรักษาสมดุลระหว่างแนวทางของซอฟต์แวร์เสรี (free software) และโอเพนซอร์ส (open source software) โดยถือว่าซอฟต์แวร์เสรีคือหลักการ และโอเพนซอร์สคือแนวทางปฏิบัติ แต่ในชุมชนในไทยปัจจุบันเราจะเริ่มเห็นการแบ่งแยกสองสิ่งนี้ออกเป็นคนละสำนักขึ้นเรื่อย ๆ จนถึงขั้นที่ว่า ถ้าเข้าไปในวงโอเพนซอร์สแล้วพูดถึงเสรีภาพซอฟต์แวร์จะกลายเป็นคนสุดโต่งไปเลย

แต่เราต้องไม่ลืมว่า ซอฟต์แวร์เสรีนั้นคือหลักการพื้นฐานที่ทำให้เราสร้างกฎเกณฑ์ของการแบ่งปันซอฟต์แวร์ภายใต้กรอบของกฎหมายลิขสิทธิ์ได้ ทบทวนสักเล็กน้อยสำหรับคนที่มาใหม่ หลักการของซอฟต์แวร์เสรีนั้นคือเสรีภาพ 3 ประการ และมีการเพิ่มเสรีภาพข้อที่ 0 เข้าไปในภายหลังกลายเป็นเสรีภาพ 4 ประการ คือ

  1. เสรีภาพในการใช้ซอฟต์แวร์
  2. เสรีภาพในการศึกษาการทำงานและแก้ไขซอฟต์แวร์ให้ทำงานตามต้องการ
  3. เสรีภาพในการแจกจ่ายซอฟต์แวร์ต่อ
  4. เสรีภาพในการเผยแพร่ซอฟต์แวร์ที่แก้ไขแล้ว

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

เมื่อเราละทิ้งเสรีภาพเหล่านี้ แล้วยอมรับเงื่อนไขของซอฟต์แวร์ซอร์สปิดมากขึ้นเรื่อย ๆ แล้วเราได้เจออะไรบ้าง?

  • Postcardware เต็มบ้านเต็มเมือง คือซอฟต์แวร์ที่เขียนสัญญาอนุญาตที่ให้เสรีภาพครบทุกประการ แต่ต้องแจ้งเป็นลายลักษณ์อักษรก่อนลงมือแก้ไข ซึ่งเงื่อนไขตรง "แต่" นี้เอง ที่ทำให้ซอฟต์แวร์นั้นกลายเป็นซอฟต์แวร์ปิดโดยปริยาย เพราะไม่ต่างอะไรกับการต้องขออนุญาตก่อนทำ (ในทางปฏิบัติ ถ้าไม่มีหนังสือตอบกลับว่าได้รับแจ้งแล้ว คุณก็ไม่มีหลักฐานไปยืนยันการแจ้งเป็นลายลักษณ์อักษรของคุณในกรณีที่เกิดการฟ้องร้อง การจะตอบกลับหรือไม่จึงมีผลเสมือนการอนุญาตหรือไม่นั่นเอง) หรือรูปแบบที่พยายามควบคุมการแจกจ่ายทางอื่นด้วยการให้ลงทะเบียนก่อนดาวน์โหลดก็เข้าข่ายขัดขวางการแจกจ่ายอย่างเสรีและลดแรงจูงในในการพัฒนาต่อยอดแบบโอเพนซอร์สเช่นกัน
  • แนวทางการต่อสู้ที่เพียงแค่ใช้ FOSS เป็นเครื่องมือต่อรองราคากับซอฟต์แวร์ปิดเท่านั้น เราไม่ได้ใส่ใจเรื่องเสรีภาพอะไรเลย แค่สนใจเรื่องราคาอย่างเดียว ได้ของถูกมาใช้ก็จบ หรือใช้แค่เป็นยันต์กันผีเวลาที่มีการตรวจจับการละเมิดลิขสิทธิ์ซอฟต์แวร์ เราไม่เคยมองในระยะยาวเลยว่าเราจะได้ประโยชน์จากมาตรฐานเปิด ความอิสระ สามารถกำหนดทิศทางของตัวเอง โดยเฉพาะอย่างยิ่งการถ่ายทอดเทคโนโลยีผ่านการทำงานกับซอร์สโค้ดที่เปิดและกับโครงการสากล
  • ร่างแผนแม่บท ICT ที่เน้น การจดสิทธิบัตรซอฟต์แวร์ พร้อม ๆ กับการส่งเสริมซอฟต์แวร์โอเพนซอร์ส โดยบางท่านถึงกับส่งเสริมให้ใช้ซอฟต์แวร์โอเพนซอร์สในการสร้างซอฟต์แวร์ไปจดสิทธิบัตรกลับไปขายเมืองนอกเลยทีเดียว ซึ่งสิทธิบัตรซอฟต์แวร์เป็นสิ่งที่ขัดขวางโอเพนซอร์สโดยตรง เพราะการแจกจ่ายซอฟต์แวร์โอเพนซอร์สแบบตามเก็บค่าสิทธิบัตรกับผู้ใช้นั้น เป็นการขัดขวางการแจกจ่ายอย่างเสรีตามหลักซอฟต์แวร์เสรี และส่งผลกระทบถึงกระบวนการใด ๆ ที่โอเพนซอร์สจะใช้ในการสร้างความเติบโตของซอฟต์แวร์ ดังนั้น ไม่ว่าจะโดยมุมมองของซอฟต์แวร์เสรีหรือโอเพนซอร์ส สิทธิบัตรซอฟต์แวร์ก็เป็นสิ่งไม่พึงประสงค์ทั้งนั้น การมองข้ามข้อนี้แล้วเปิดรับแบบรู้เท่าไม่ถึงการณ์จะกลายเป็นการสะดุดขาตัวเอง

เกี่ยวกับเรื่องสิทธิบัตรซอฟต์แวร์นี้ แม้จะมองในมุมมองของซอฟต์แวร์ปิด การส่งเสริมก็ยังถือว่าเสี่ยงสำหรับอุตสาหกรรมซอฟต์แวร์ไทย เพราะการยอมรับสิทธิบัตรซอฟต์แวร์ จะกลายเป็นการคุ้มครองสิทธิบัตรซอฟต์แวร์ต่าง ๆ จำนวนมหาศาลที่บริษัทยักษ์ใหญ่ได้จดเอาไว้ และเราได้เห็นว่าเขาใช้ถล่มกันเละแค่ไหน เพราะสิทธิบัตรจะคุ้มครอง วิธีการ ไม่ใช่คุ้มครองแค่ตัวโค้ดโปรแกรม ทำให้เขียนโปรแกรมเลี่ยงได้ยาก บริษัทในอเมริกาจึงสะสมสิทธิบัตรไว้เป็นคลังแสงจำนวนมาก ในขณะที่ประเทศเรายังเตาะแตะ การเปิดรับสิทธิบัตรซอฟต์แวร์จะมีแต่เสียเปรียบ ซึ่งเรื่องนี้แม้สหภาพยุโรปเองก็กำลังต่อต้านไม่ให้มีการคุ้มครองสิทธิบัตรซอฟต์แวร์ เพราะถือเป็นการผูกขาดการแข่งขันเกินไป (เช่น ffii.org, nosoftwarepatent.com, stopsoftwarepatent.eu)

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

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

ป้ายกำกับ:

11 กุมภาพันธ์ 2553

A Linux Migration Case

บันทึกปัญหาที่ได้รับรายงานจากโรงเรียนแห่งหนึ่งที่เปลี่ยนมาใช้ลินุกซ์ (Ubuntu) ทั้งโรงเรียน โดยครูฝ่ายคอมพิวเตอร์ร่วมผลักดัน หลังได้รับอนุมัติจากผู้อำนวยการโรงเรียน ซึ่งปัญหาส่วนใหญ่ยังเป็นเรื่องแรงเฉื่อยจากสิ่งแวดล้อมเดิม

  • เล่นวีซีดีไม่ได้ อันนี้ต้องถือว่าลินุกซ์ตายน้ำตื้น พอใส่ VCD ที่เป็นสื่อการสอนเข้าไป GNOME จะขึ้นกล่องโต้ตอบมาถามหาโปรแกรมที่จะเปิด โดยค่าปกติจะเป็น Totem (GStreamer) ซึ่งเล่น VCD ไม่ได้ และครูส่วนใหญ่ก็จะเข้าใจไปว่าลินุกซ์เล่นวีซีดีไม่ได้ ก็ต้องควักโน้ตบุ๊กที่มีวินโดวส์มาเล่นแทน ทิ้งเครื่องลินุกซ์ปิดไว้
  • ระบบส่งเกรดใช้ฟอร์แมตปิด เพิ่งทราบมาว่า สำนักงานเขตการศึกษา บังคับให้ส่งเกรดของนักเรียนในรูปแบบเฉพาะของโปรแกรมซึ่งพัฒนาขึ้นเองบนวินโดวส์ ทำให้โรงเรียนยังต้องซื้อไลเซนส์วินโดวส์เพื่อใช้ส่งเกรด
  • ปัญหาการทำการบ้านของนักเรียน ที่โรงเรียนสอนใช้โปรแกรมบนลินุกซ์ แต่เครื่องที่บ้านของนักเรียนหลายคนยังเป็นวินโดวส์อยู่ และไม่สะดวกจะติดตั้งลินุกซ์ หรือแม้แต่โปรแกรมโอเพนซอร์สบนวินโดวส์ เนื่องจากเป็นเครื่องของผู้ปกครองที่ต้องใช้ทำงานอยู่ ดังนั้น นักเรียนจะคอยถามครู ว่าถ้าจะทำงานแต่ละอย่างที่ครูสั่งโดยใช้วินโดวส์ จะต้องใช้โปรแกรมอะไร (กลับกันกับคำถามของคนที่เพิ่งเปลี่ยนมาใช้ลินุกซ์)

ปัญหาเรื่องวีซีดี แก้ได้ด้วยการแนะนำให้รู้จักกับ VLC, MPlayer หรือ Xine แต่ถ้า GStreamer รองรับ VCD เสียที ปัญหานี้ก็จะง่ายลงเยอะ

ปัญหาเรื่องการทำการบ้านของนักเรียน อาจใช้วิธีแจก Live CD ให้ไปบูตใช้ที่บ้าน จะได้ไม่รบกวนผู้ปกครอง (และอาจชวนผู้ปกครองให้ลองใช้ด้วย)

แต่ปัญหาเรื่องระบบส่งเกรดนี่สิ.. ปัญหาระดับชาติเชียวแหละ ต้องอาศัยการต่อสู้เพื่อเปลี่ยนไปใช้ระบบอื่น เช่น ผ่านเว็บ หรือใช้สเปรดชีตแทนก็ยังดี แต่คงทำโดยโรงเรียนใดโรงเรียนหนึ่งโดยลำพังไม่ไหว

ป้ายกำกับ: , , , ,

16 มกราคม 2553

LibThai Security Update

ผ่านไปเรียบร้อย กับ LibThai 0.1.13 ซึ่งเป็น security update โดยแก้ปัญหา integer/heap overflow vulnerability (CVE-2009-4012, DSA-1971)

ปัญหานี้ Tim Starling ได้รายงานทางเมลส่วนตัวมาที่ผมตั้งแต่ช่วงปีใหม่ แต่กว่าจะได้เริ่มลงมือแก้ก็ผ่านไปเกือบอาทิตย์ เนื่องจากต้องไปเฝ้าไข้พ่อที่ รพ. อยู่ หลังจากที่ได้แพตช์แล้ว ก็ส่งแพตช์กลับไปให้เขาช่วยตรวจทานอีกรอบเพื่อความแน่ใจ เสร็จแล้วก็เริ่มติดต่อทีม Debian Security เพื่อขอ update ใน stable และ oldstable

ทีม security ก็ได้กำหนดหมายเลข CVE สำหรับใช้อ้างอิง พร้อมกับนัดหมาย embargo date มาให้ ในระหว่างนั้น ผมจะแพร่งพรายปัญหานี้ออกไปไม่ได้ แม้แต่ commit public VCS ก็ห้าม (แต่ผมก็พลาด โดยได้ commit SVN ไปตั้งแต่ก่อนติดต่อเขาแล้ว ซึ่งเป็นสิ่งไม่สมควร) เพื่อให้เวลาในการแก้ปัญหานี้ร่วมกับ distro ต่าง ๆ ที่ ship libthai ก่อนที่จะประกาศ release พร้อมกัน ทั้งนี้เพื่อความป้องกันการ exploit ที่จะเกิดขึ้นก่อนที่ผู้ใช้จะมีโอกาสได้ update นั่นเอง

เดิมทีนั้น ผมขอ update แค่ stable (lenny) เพราะแพกเกจใน oldstable (etch) นั้น เป็นโค้ดเก่าตั้งแต่ก่อนรื้อเขียนใหม่มาใช้ libdatrie แต่ทีม security บอกว่าต้อง update oldstable ด้วย เนื่องจาก Debian มีภาระผูกพันที่จะ maintain oldstable เป็นเวลาหนึ่งปีนับจาก stable ออก ก็เป็นอันว่าผมต้องทำงานทั้งหมด 3 ครั้ง ครั้งแรกแก้ที่ upstream trunk, ครั้งที่สอง backport มา lenny และครั้งที่สาม แก้โค้ดเก่าใน etch (ซึ่งครั้งหลังสุดนี้ใช้เวลานานหน่อย เนื่องจากเป็นโค้ดที่โละทิ้งไปแล้ว แถมไม่ใช่โค้ดของผมเองด้วย) แล้วก็ยังมีครั้งท้ายสุดจริง ๆ คือปล่อย upstream release และ upload ขึ้น unstable

ครั้งนี้ ทำให้ได้ประสบการณ์ใหม่:

  • ได้เรียนรู้ระบบการจัดการ security bug ในโครงการซอฟต์แวร์ มีคน blog สรุปเอาไว้ดีพอสมควรครับ กล่าวคือ:
    • ถ้าคุณพบบั๊กที่เกี่ยวกับ security ที่ยังไม่เป็นที่ทราบกันในสาธารณะ คุณควรรายงานผ่านช่องทางพิเศษที่ไม่เปิดเผย (ขึ้นอยู่กับแต่ละโครงการจะกำหนด หรืออาจจะเป็นเมลส่วนตัว) เพื่อให้โอกาสผู้ดูแลได้แก้ปัญหาก่อนที่จะเกิด exploit กับผู้ใช้ เรียกว่าเป็น responsible disclosure (การเปิดเผยข้อมูลอย่างรับผิดชอบ)
    • การปิดบังปัญหานี้ เป็นแค่การปิดบัง ชั่วคราว ในระหว่างแก้ปัญหา เพื่อปกป้องผู้ใช้เท่านั้น ไม่ได้เข้าข่าย security through obscurity แต่อย่างใด หลังจากแก้ปัญหาเรียบร้อย ทุกอย่างก็จะเปิดเผยผ่าน security alert ซึ่งผู้ใช้จะอุดรูรั่วได้ทันท่วงทีก่อนที่จะมี exploit
    • ถ้าบั๊กนั้นเป็นที่ทราบกันในสาธารณะแล้ว ก็ควรมุ่งหาวิธีแก้ทันทีแทน
    • ถ้าบั๊กนั้นมีผลร้ายแรง ก็จะมีการกำหนด embargo date สำหรับปล่อย fix สู่สาธารณะพร้อม ๆ กัน โดยก่อนหน้านั้น ไม่ควรแพร่งพรายปัญหาสู่สาธารณะ
  • social network ต่าง ๆ เช่น twitter, facebook, identi.ca กลายเป็นสิ่งยั่วยวนอย่างมากก่อน embargo date โดยเฉพาะถ้าคุณติดนิสัย tweet ทุกอย่างที่ทำ ควรมีสติเสมอ ถ้าคันปากนักก็หันไปหาสิ่งอื่นที่น่าสนใจ tweet แทน
  • เห็นประโยชน์ของ distributed VCS (เช่น git, bzr, hg) ขึ้นมาทันที เพราะก่อน embargo date นั้น คุณไม่ควร commit โค้ดสู่ public VCS อันจะเป็นการแพร่งพรายปัญหาได้ ถ้าใช้ centralized VCS ก็อาจลำบากหน่อย คือต้อง maintain security patch ต่าง ๆ เอาไว้ในระหว่างที่ commit เรื่องอื่น แต่ถ้าใช้ distributed VCS ล่ะก็ แตก branch หรือ commit แบบ local แล้วไปทำงานส่วนอื่นต่อได้ตามสบาย ขอแค่อย่า push security commit เป็นพอ

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

แต่นี่ไม่ได้อ้างว่าซอฟต์แวร์โอเพนซอร์สจะปลอดภัยกว่า 100% นะครับ เพียงแต่ชี้ว่า การพบจุดโหว่ทำให้ซอฟต์แวร์ปลอดภัยได้อย่างไร

ป้ายกำกับ: , , ,

28 พฤศจิกายน 2552

Opensource Mindset

ไปเจอวารสาร OpenSource2Day ฉบับที่ 13 บนแผงหนังสือ ลงปกสัมภาษณ์ ดร.ทวีศักดิ์ เกี่ยวกับโอเพนซอร์ส เลยซื้อมาเพื่ออ่านแนวคิดของท่านโดยเฉพาะ อ่านจบแล้วก็อ่านข่าวคราวทั่วไปในวงการโอเพนซอร์สเมืองไทยต่อไป จนกระทั่งไปสะดุดที่บทความเรื่อง การคิดแบบโอเพนซอร์ส (Open Source Thinking) ของ อ.ธวัชชัย เอี่ยมไพโรจน์ แห่ง ม.บูรพา

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

  • ผู้ที่มีความเชื่อในโอเพนซอร์ส จะใช้ซอฟต์แวร์โอเพนซอร์ส แม้จะมีซอฟต์แวร์ที่ดีกว่าให้ใช้ เพราะเขาต้องการซอร์สโค้ด (อันที่จริง อาจจะพูดได้อีกอย่างว่า ต้องการเสรีภาพ สำหรับผม ผมใช้คำว่า "ใช้แล้วสบายใจ" เพราะการมีซอร์สโค้ดก็หมายความว่า ผมจะสามารถดัดแปลงซ่อมแซมอะไรเองได้ ซอฟต์แวร์เป็นของผมอย่างเต็มที่)
  • ผู้ที่มีความเชื่อในโอเพนซอร์ส จะมีปฏิกิริยาเชิงรุกเมื่อพบปัญหา โดยจะพยายามค้นหาวิธีแก้จากอินเทอร์เน็ต อ่านเอกสาร ทดลองทำ หรือกระทั่งนั่งดีบั๊ก แต่ก็ไม่ได้ทำอย่างนี้กับทุกเรื่อง จะทำเฉพาะในโปรแกรมที่สนใจ
  • คนโอเพนซอร์สจะเข้าร่วมวงสนทนา เช่น mailing list เพื่อแลกเปลี่ยนข้อมูลกับคนอื่น และทุ่มเทเวลาให้กับการสร้างทักษะการแก้ปัญหา
  • คนโอเพนซอร์ส จะทั้ง contribute และ donate ให้กับโครงการที่ชอบ แบ่งปันวิธีแก้ปัญหา รับฟังผู้ review ด้วยความขอบคุณ แล้วพยายามปรับแพตช์ซ้ำแล้วซ้ำอีกจนสำเร็จ
  • ผู้ที่มีความเชื่อในโอเพนซอร์ส จะมีความอยากรู้อยากเห็น (curiosity) ยืนหยัด (tenacity) พยายาม (perseverance) พากเพียร (diligence) ปรารถนาอันแรงกล้า (passion) และความเห็นอกเห็นใจผู้อื่น (compassion) โดยจะใช้สิ่งเหล่านี้พัฒนาศักยภาพของตนเองจนมีทักษะในตัว จนสามารถช่วยงาน ช่วยเหลือผู้อื่นได้
  • ผู้ที่มีความเชื่อในโอเพนซอร์ส จะกระหายที่จะช่วยเหลือกลับคืนสู่ชุมชนโอเพนซอร์สในทุก ๆ จังหวะเวลาที่มีโอกาส โดยมีพื้นฐานจากจริยธรรม ไม่ใช่ความมั่งคั่ง ซึ่งสวนทางกับความคิดของนักธุรกิจ ในขณะที่ซอฟต์แวร์โอเพนซอร์สก็ถูกนักธุรกิจจำนวนมากใช้เพื่อความมั่งคั่งของตัว
  • สังคมนักพัฒนาโอเพนซอร์ส เป็นสังคม meritocracy ใครจะมีฐานะอย่างไร ก็อยู่ที่ผลงานที่ทำ ไม่เกี่ยวกับความร่ำรวย หรืออายุ หรือสิ่งอื่น ๆ
  • คนโอเพนซอร์สจำเป็นต้องเรียนรู้ภาษาอังกฤษไว้บ้าง เพราะเป็นภาษาที่ใช้สื่อสารกันในวงการโอเพนซอร์สสากล
  • คนโอเพนซอร์สมีการเคารพเครดิตซึ่งกันและกันเมื่อมีการ copy งานกัน ไม่มีการขโมยผลงานผู้อื่น (plagiarism)

นี่สรุปมาคร่าว ๆ เท่านั้น รายละเอียดอ่านได้ในวารสารครับ อันที่จริง บทความนี้ อาจารย์จะเกริ่นถึงงานวิจัยชิ้นหนึ่ง ซึ่งจะเปรียบเทียบ mindset นี้ซึ่งเกิดในบริบทสังคมตะวันตก กับ mindset พื้นฐานของสังคมไทย

เพิ่มเติม (2009-11-29): เกี่ยวกับการเปรียบเทียบกับวัฒนธรรมไทยนั้น blog หนึ่งที่ผมเคยเขียนไว้ อาจมีส่วนเกี่ยวข้อง

ป้ายกำกับ:

24 ตุลาคม 2552

Romance of the Three (Software) Kingdoms

ตามที่มีประกาศโครงการป้องปรามการละเมิดลิขสิทธิ์ ปีที่ 2 ที่ stop.in.th พร้อม จดหมายแจ้ง ถึงหน่วยงานต่าง ๆ ก็คิดว่าใกล้เวลาที่จะได้เห็นการ debate เรื่องลิขสิทธิ์ซอฟต์แวร์ตามที่ต่าง ๆ อีกครั้ง ทั้งในและนอกอินเทอร์เน็ต แล้วก็คงเลี่ยงไม่ได้ที่จะพาดพิงถึง ซอฟต์แวร์เสรี และ โอเพนซอร์ส ด้วย

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

ผู้ใช้ซอฟต์แวร์อาจแบ่งแบบหยาบ ๆ ได้เป็น 3 กลุ่ม:

  1. ผู้ใช้ซอฟต์แวร์สงวนสิทธิ์แบบมีใบอนุญาต (Proprietary Licensed)
  2. ผู้ใช้ซอฟต์แวร์แบบไม่มีใบอนุญาต (Unlicensed)
  3. ผู้ใช้ซอฟต์แวร์เสรี/โอเพนซอร์ส (Free/Open Source Licensed)

Three Software Kingdoms

แต่ละกลุ่มมีทัศนคติเกี่ยวกับซอฟต์แวร์เกาะเกี่ยวกันอยู่:

  • สิ่งที่ทุกกลุ่มสนใจร่วมกัน คือการใช้ซอฟต์แวร์คอมพิวเตอร์เพื่อทำงานให้ลุล่วง
  • สิ่งที่กลุ่ม Proprietary Licensed กับ Unlicensed สนใจร่วมกัน มักเป็นเรื่องการใช้ซอฟต์แวร์ยอดนิยมที่ "ใคร ๆ ก็ใช้กัน" ซึ่งโดยมากไม่ใช่ซอฟต์แวร์เสรี/โอเพนซอร์ส
  • สิ่งที่กลุ่ม Proprietary Licensed กับกลุ่ม Free/Open Source Licensed สนใจร่วมกัน คือเรื่องทรัพย์สินทางปัญญา เพราะทั้งสองกลุ่มนี้ อาศัยกฎหมายลิขสิทธิ์ในการควบคุมการใช้งานซอฟต์แวร์ในลักษณะต่าง ๆ
  • สิ่งที่กลุ่ม Unlicensed กับ Free/Open Source Licensed สนใจร่วมกัน คือเรื่องความประหยัด เนื่องจากซอฟต์แวร์เถื่อนมีราคาถูก แม้จะผิดกฎหมาย ในขณะที่ซอฟต์แวร์เสรี/โอเพนซอร์สโดยทั่วไปก็ราคาถูกเช่นกัน แต่ถูกกฎหมายด้วย

ในขณะเดียวกัน แต่ละกลุ่มก็มีความสนใจในส่วนที่ไม่ร่วมกับกลุ่มอื่นด้วย:

  • กลุ่ม Proprietary Licensed จะสนใจในการปกป้องทรัพย์สินทางปัญญาอย่างเต็มที่ ซอร์สโค้ดของซอฟต์แวร์ยังคงเป็นความลับสุดยอดที่ต้องเก็บรักษาไม่ให้รั่วไหล สิทธิ์ในการใช้งานของผู้ใช้ต้องถูกตีกรอบชัดเจนเพื่อไม่ให้ล่วงละเมิดผู้ผลิต ผู้ใช้จะต้องซื้อสิทธิ์ที่จะได้ใช้ซอฟต์แวร์อย่างถูกต้อง
  • กลุ่ม Unlicensed จะสนใจในความสะดวกสบายในการจัดหาซอฟต์แวร์มาใช้ ความสบายกระเป๋า โดยไม่สนใจในเรื่องทรัพย์สินทางปัญญานัก แม้ในที่สุดจะต้องอยู่อย่างพลเมืองชั้นสองบ้าง เช่น ไม่สามารถ update ซอฟต์แวร์ได้ หรือต้องคอยหลบเลี่ยงการตรวจจับของเจ้าหน้าที่ แต่ทุกอย่างยังถือว่าอยู่ในจุดคุ้มเสี่ยง
  • กลุ่ม Free/Open Source Licensed จะสนใจในเสรีภาพและความเปิดกว้างของซอฟต์แวร์ ซอฟต์แวร์ที่จัดหามานั้น ผู้ใช้ควรมีสิทธิ์ที่จะใช้ แก้ไข แจกจ่ายต่อได้อย่างเสรี ผู้ผลิตควรเปิดรับการแก้ไขปรับปรุงต่าง ๆ ทำให้ซอฟต์แวร์กลายเป็นของชุมชน ไม่ใช่ของเอกชนรายใดรายหนึ่ง แต่เรื่องเสรีภาพนี้ คงไม่ได้อยู่ในความสนใจของทั้งกลุ่ม Proprietary Licensed และ Unlicensed

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

แต่แน่นอนว่าทุกครั้งที่มีการถกกันในเรื่องนี้ ก็จะมีประเด็นเรื่องความคุ้นเคยกับซอฟต์แวร์ยอดนิยมที่เป็น Proprietary เสมอ ๆ โดยทั้งกลุ่ม Proprietary Licensed และ Unlicensed จะร่วมมือกันถล่มกลุ่ม FOSS ในประเด็นนี้

ในขณะเดียวกัน ถ้าพูดถึงเรื่องทรัพย์สินทางปัญญาเมื่อไร กลุ่ม Unlicensed ก็มักโดนถล่มจากทั้งกลุ่ม Proprietary Licensed และ FOSS เช่นกัน พร้อม ๆ กับมีความร่วมมือระหว่างกลุ่ม Unlicensed และกลุ่ม FOSS บ้างในการต่อสู้เรื่องราคากับกลุ่ม Proprietary Licensed

ความสัมพันธ์ระหว่างกลุ่มผู้ใช้ซอฟต์แวร์จึงเป็นสามก๊กสามเส้า ฉะนี้

ต่อไปเป็นความเห็นของผมสำหรับการป้องปรามครั้งนี้:

  • กลุ่ม FOSS คงไม่ร่วมสังฆกรรมกับกลุ่ม Proprietary ในการซ้ำเติมกลุ่ม Unlicensed ในครั้งนี้ (ความจริง ไม่ว่าครั้งไหน ๆ ก็ไม่ควรเข้าร่วม) แต่ควรเข้าช่วยเหลือเสนอทางเลือกที่คุ้มทุน
  • กลุ่ม FOSS คงไม่หลงใหลได้ปลื้มกับการย้ายมาใช้ FOSS ของกลุ่ม Unlicensed บางส่วนนัก ด้วยสาเหตุ:
    • ต้องเหนื่อยออกแรงซัพพอร์ต รวมทั้งรับมือกับเสียงต่อต้านจากผู้ใช้ในองค์กรที่อาจถูกบังคับให้เปลี่ยน โดยอาจถูกเหมารวมว่าเป็นพวกเดียวกับกลุ่ม Proprietary หรืออย่างน้อยก็ถูกมองว่ารอเสียบมานาน
    • การปราบปรามอาจไม่ยั่งยืนอะไร การเปลี่ยนอาจเป็นแค่การเปลี่ยนเพื่อบังหน้าเท่านั้น พอเรื่องซาลงก็อาจกลับไปใช้ของเถื่อนกันใหม่
    ประเด็นคือ มันเป็นการเปลี่ยนเพราะถูกบังคับ ไม่ใช่การเปลี่ยนจากข้างในนั่นเอง
  • แต่ไม่ว่าอย่างไร กลุ่ม FOSS ก็ควรทำงานให้เต็มที่ตามปกติ

ป้ายกำกับ:

16 กันยายน 2552

Academic Document Format

ตรวจคำแปลแบบมาราธอน 2 อาทิตย์เพิ่งเสร็จครับ เลยเขียนเรื่องนี้ช้าไปหน่อย

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

อย่างที่ว่ากันแหละครับ เรื่องเก่าเล่าใหม่ แต่มันก็เป็นปัญหาคาใจกันมานานในหมู่ผู้ใช้ที่ไม่ได้ใช้วินโดวส์ ผมคิดว่าเจ้าของกระทู้จุดประเด็นแรงไปหน่อย ทำให้เกิดแรงต้าน เกิดความเข้าใจผิดในประเด็น แต่ตัวประเด็นมันก็มีอยู่ ไม่ใช่เรื่องทฤษฎีสมคบคิดหรือเรื่องฝ่าฝืนกฎอะไร แต่เป็นเรื่องในทางปฏิบัติหลาย ๆ อย่าง ที่หนักที่สุดคงเป็นเรื่องความไม่สะดวกของผู้ใช้ที่ไม่ได้ใช้วินโดวส์

ความเปิดกว้าง

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

ในฐานะที่เคยอยู่ในทีม secretariat ของการประชุมวิชาการมาบ้าง ก็จะพบว่าในการประชุมที่รับเอกสารแบบ camera-ready เช่น Postscript หรือ PDF นั้น จะพบสัดส่วนของเอกสารที่เตรียมด้วย LaTeX สูงพอ ๆ กับที่ใช้ MS Word โดยอาจมีเครื่องมืออื่นแซมมาบ้างนิดหน่อย เช่น Pagemaker แต่ก็ไม่มาก

กรณีของ proceedings ที่รับ camera-ready นั้น อาจจะไม่ได้เคร่งครัดถึงขนาดนั่งลงทาบไม้บรรทัดวัด ขอเพียงใช้ฟอนต์ในตระกูลทั่วไปที่กำหนด (เช่น Times หรือ serif font ที่เทียบเคียง) ในขนาดที่กำหนด ความยาวไม่เกินที่กำหนด ก็น่าจะโอเคแล้ว แต่ถ้าเป็นกรณีของบัณฑิตวิทยาลัยที่ต้องการให้วิทยานิพนธ์ออกมาในรูปแบบเดียวกันหมด หรือต้องการนำไปประมวลผลอย่างอื่น ก็อาจต้องขอแฟ้มต้นฉบับเพิ่มเติมจาก camera-ready มาด้วย แต่การจำกัดอยู่เพียง MS Word อย่างเดียวนั้น น่าจะสุดโต่งเกินไป อย่างน้อยก็ควรเตรียมรองรับฟอร์แมตหลัก ๆ อย่าง LaTeX หรือ ODF ด้วย

ฟอนต์และการจัดหน้า

ประเด็นหนึ่งที่กระทู้พูดถึง คือการบังคับใช้ฟอนต์ Angsana เท่านั้น ซึ่งผมก็ยังสับสนอยู่ เพราะบางความเห็นก็บอกว่าให้ใช้ฟอนต์อื่นอย่าง Browallia, Eucrosia ฯลฯ ได้ แต่อย่างไรก็ดี รายชื่อที่แสดงมาทั้งหมดนั้น จัดจำหน่ายโดยผู้ผลิตเพียงเจ้าเดียว คือไมโครซอฟท์ และมีอยู่บนระบบปฏิบัติการเดียว คือวินโดวส์ ผมไม่แน่ใจว่า ในทางปฏิบัติแล้ว ถ้ามีใครใช้ฟอนต์อย่าง DB Narai หรือ Kinnari จะถูกตีกลับมาหรือเปล่า

เรื่องการบังคับฟอนต์แบบเจาะจงชื่อ รวมทั้งการบังคับกั้นหน้าซ้ายขวาอย่างละเอียดนี้ ความจริงเป็นประเด็นที่น่าจะเกิดมาพร้อมกับคำว่า WYSIWYG (What You See Is What You Get) เพราะในระบบอย่าง LaTeX นั้น จะแยก stylesheet ออกจากเนื้อหาอย่างเด็ดขาด ผู้เตรียมเอกสารมีหน้าที่แค่ป้อนเนื้อหาและใส่ markup ต่าง ๆ ไว้เท่านั้น ไม่จำเป็นต้องกังวลถึงฟอนต์และกั้นหน้าที่ใช้เลย และ stylesheet สามารถเปลี่ยนแปลงได้อย่างยืดหยุ่น เช่น สมมุติว่าผู้จัดพิมพ์ต้องการเปลี่ยนฟอนต์จาก serif เป็น sans serif และแปะตรามหาวิทยาลัยไว้ที่หัวกระดาษ ก็แค่เปลี่ยน stylesheet แล้วสั่ง typeset ใหม่โดยไม่จำเป็นต้องไปนั่งจัดหน้าเนื้อหาเอกสารต้นฉบับเลย

แนวคิดเรื่อง stylesheet นี้ ความจริงใน MS Word หรือ OO.o ก็มี โดยการกำหนด template มาล่วงหน้า จากนั้น ผู้ใช้ก็เพียงแต่เตรียมเอกสารโดยใช้ style ต่าง ๆ จาก template ถ้าผู้จัดพิมพ์ต้องการเปลี่ยนรูปเล่ม ก็เพียงแต่มาเปลี่ยน style ต่าง ๆ ใน template เท่านั้น เพียงแต่อาจต้องไล่ทำทีละเอกสาร เนื่องจากข้อมูล stylesheet จะฝังมาในทุกเอกสาร ไม่ใช่แยกต่างหากให้แก้เพียงที่เดียวได้เหมือน LaTeX

แต่ stylesheet ในเวิร์ดโพรเซสเซอร์แบบ WYSIWYG นั้น มีปัญหาในทางปฏิบัติ คือมันกลายเป็นแค่ออปชันหนึ่งที่ผู้ใช้ส่วนน้อยเท่านั้นที่จะใช้ จากการสังเกตพฤติกรรมการใช้เวิร์ดของผู้คนที่ผมพบ ส่วนใหญ่จะใช้เวิร์ดในฐานะของ กระดาษวาดรูป ไม่ใช่ เครื่องมือเตรียมเอกสาร เช่น ขึ้นหัวข้อใหม่ด้วยการป้ายกำหนดฟอนต์ตัวหนาขยายใหญ่ แทนที่จะกำหนด style เป็น Heading, ร่นย่อหน้าด้วยการเคาะ space bar แทนการกำหนด margin ที่ style ของย่อหน้า, เวลาลงท้ายจดหมายก็เคาะ space bar ดันข้อความไปด้านขวา เล็งให้บรรทัด "ขอแสดงความนับถือ" กับบรรทัดลงชื่อ เรียงกันกึ่งกลางพอดี แทนที่จะใช้วิธีกำหนด margin และ alignment ใน style ของย่อหน้า ฯลฯ เอกสารจึงขาดโครงสร้าง เวลาเปลี่ยนขนาดฟอนต์หรือขนาดกระดาษที ก็ต้องมานั่งจัดหน้าใหม่หมด จาก What You See Is What You Get ก็เลยกลายเป็น What You See Is All You Get แทน คือไม่ได้อะไรมากไปกว่าที่เห็นหรอก

นอกจากนี้ ยังมีรายละเอียดปลีกย่อยอย่างอื่นอีกที่อาจจะเฉพาะเจาะจงกับเอกสารวิชาการ เช่น การใช้ cross reference ในการอ้างถึงหัวข้ออื่นและบรรณานุกรม, การทำสารบัญและดัชนีในกรณีที่เป็นหนังสือ ฯลฯ

คนที่พูดว่าเวิร์ดใช้ง่ายนั้น ยังต้องแยกประเภทอีกครับ ว่าใช้เวิร์ดในฐานะเวิร์ดจริง ๆ หรือเปล่า

แม้แต่คนที่ใช้เวิร์ดเป็นจริง ๆ เอง ก็พลาดบ่อยครับ เช่น การตัดแปะเอกสารมาจากหน้าเว็บ มันจะติด style จาก HTML มาด้วย แล้ว WYSIWYG ก็จะ "อำนวยความสะดวก" ด้วยการเพิ่ม style ให้โดยอัตโนมัติ ทำให้เอกสารเกิด customized style ที่แปลกแยกจากส่วนอื่นของเอกสารขึ้นมาโดยไม่รู้ตัว ซึ่งตอนที่ผมโดนแบบนี้ ผมไม่ถือว่ามัน "อำนวยความสะดวก" ให้ผม แต่เรียกว่ามัน "สู่รู้" ครับ และวิธีที่ปลอดภัยที่สุดก็คือ ตัดแปะผ่าน plain text editor อีกที

เพราะ WYSIWYG มีปัญหาที่เอื้อให้ผู้ใช้ทำผิดพลาดต่าง ๆ ได้ง่ายนี่เอง ก็เลยเป็นที่มาของสงครามระหว่างนิสิตกับผู้ตรวจวิทยานิพนธ์ ฟอนต์ผิด ไม่ได้ขนาด ก็แก้ กั้นหน้าไม่ถูก ก็แก้ ร่นย่อหน้าไม่ได้ระยะ ก็แก้ และอื่น ๆ จุกจิกสารพัดจะแก้ ซึ่งถ้าใช้รูปแบบที่เป็น markup อย่าง LaTeX, HTML หรือ DocBook แล้ว ปัญหาจะไม่เยอะขนาดนี้ และบัณฑิตวิทยาลัยก็ไม่จำเป็นต้องบังคับฟอนต์ด้วย อยากได้ฟอนต์อะไร รูปหน้าแบบไหน ก็เปลี่ยนตอนจัดพิมพ์ได้เลย หรือถ้าให้นิสิตจัดพิมพ์เอง ก็เชื่อได้ว่าการจัดหน้าจะได้ตาม template เกือบทั้งหมด เพราะการที่จะเปลี่ยน style อะไรในเอกสาร markup นั้น จะยากและอาศัยความรู้ระดับลึก ผิดกับ WYSIWYG ที่วางกับดักล่อผู้ใช้ไว้แทบทุกส่วนของ UI

ดังนั้น ถ้ามี LaTeX เป็นอีกทางเลือกหนึ่งสำหรับคนที่ไม่ได้ใช้เวิร์ด (ไม่ว่า OS จะเป็นวินโดวส์หรือลินุกซ์) และสนใจจะใช้เครื่องมือหนึ่งที่แวดวงวิชาการก็ยอมรับ ก็น่าพิจารณาไม่ใช่หรือ?

ไม่เอาละ LaTeX ใช้ยาก.. ไม่มี GUI.. มี LyX พอช่วยได้ครับ แล้วก็เครื่องมืออื่น ๆ อีกหลายอย่าง โดยเฉพาะบนวินโดวส์ มีเยอะเลย (ลองดู LaTeX for Fun and Profit ของคุณ Beamer User ด้วย) แต่เตือนไว้ก่อนว่าถ้าคุณยังคาดหวังว่ามันจะ WYSIWYG เหมือนตอนใช้เวิร์ดอยู่ คุณผิดหวังแน่นอน อย่าง LyX นั้น เขาเป็น WYSIWYM (What You See Is What You Mean) ครับ

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

ฟอร์แมตของแฟ้ม

พูดถึงฟอร์แมตของแฟ้ม เราจะมองง่าย ๆ เพียงว่าฟอร์แมตไหนมีโปรแกรมเปิดได้มากที่สุดเท่านั้นไม่ได้ แต่ต้องดูด้วยว่า ฟอร์แมตนั้นเปิดหรือไม่ เป็นมาตรฐานแค่ไหน

Word DOC

เป็นฟอร์แมตปิด ใช้เฉพาะสำหรับไมโครซอฟท์ออฟฟิศเป็นการภายในเท่านั้น เปรียบเทียบกับรูปภาพก็เหมือนไฟล์ .psd ของ Photoshop ยังไม่ใช่รูปแบบสำหรับเผยแพร่ทันทีอย่าง .jpg หรือ .png เพียงแต่บังเอิญว่ามีผู้ใช้ MS Office กันเยอะ จึงแลกเปลี่ยนกันจนกลายเป็นธรรมเนียมปฏิบัติ แล้วก็เลยบีบให้โปรแกรมค่ายอื่นจำเป็นต้องรองรับด้วยวิธี reverse engineering ซึ่งอาจได้รายละเอียดไม่ครบตามที่ MS Office เปิดเอง และแม้แต่ MS Office เอง แต่ละรุ่นก็ไม่ได้มีฟอร์แมตที่เหมือนกัน เมื่อรุ่นใหม่มีการเพิ่มความสามารถ ก็จะมีข้อมูลแบบใหม่ที่จะเปิดด้วยรุ่นเก่าไม่ได้

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

ฟอร์แมตที่ MS Office ออกแบบไว้สำหรับแลกเปลี่ยนจริง ๆ น่าจะเป็น RTF (Rich Text Format) ซึ่งจะมีฟีเจอร์ที่จำกัด (เช่น ไม่มีแมโคร—ซึ่งหมายถึงปลอดไวรัส) สามารถแลกเปลี่ยนข้ามรุ่นกันได้ หรือแม้แต่ข้ามแพลตฟอร์ม เพราะเนื้อหาจะเป็น markup text ที่รูปแบบคล้าย TeX ไม่ใช่ไบนารี แต่ปัญหาคือมีการใช้งานกันจริง ๆ แค่ในวงจำกัดเท่านั้น และเนื่องจากเอกสารที่ได้จะมีความแตกต่างอยู่บ้างระหว่าง .doc ต้นฉบับในบางกรณี ทำให้ไม่เป็นที่นิยม

ด้วยเหตุที่กล่าวมานี้ Word DOC จึงไม่ใช่ฟอร์แมตมาตรฐานแต่อย่างใด แม้แต่ใน MS Office ด้วยกันเอง ในแง่การแลกเปลี่ยนข้อมูลแล้ว RTF ยังเป็นตัวเลือกที่ปลอดภัยกว่า ถาวรกว่า อ่านได้กว้างขวางกว่า

แต่ทั้งนี้ทั้งนั้น ถ้า RTF หรือ Word DOC ที่เปิดข้ามรุ่นหรือข้ามโปรแกรมจะมีความเพี้ยนกันบ้าง ก็อย่าลืมว่า สาเหตุใหญ่ข้อหนึ่งของความเพี้ยน ก็มาจากพฤติกรรมการใช้เวิร์ดของผู้ใช้เองด้วย ถ้าใช้เวิร์ดแบบกระดาษวาดรูป โอกาสเพี้ยนก็ย่อมสูงมาก ไม่มีอะไรรับประกันได้เลย และอีกสาเหตุหนึ่งคือการขาดฟอนต์ตามที่เอกสารระบุ โดยเฉพาะเมื่อเปิดข้ามระบบ

LaTeX

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

LaTeX ไม่ได้เป็นมาตรฐาน ISO อะไร แต่อาศัยความเปิดของเครื่องมือและเอกสาร ทำให้มีปัญหาการข้ามแพลตฟอร์มน้อยกว่า Word DOC และความเป็นมาตรฐานของ LaTeX จะไปอยู่ที่รูปแบบของเอกสารที่เป็นผลลัพธ์มากกว่า โดยจะให้สมการคณิตศาสตร์ที่สวยงามถูกต้อง เป็นที่ยอมรับของสมาคมคณิตศาสตร์ต่าง ๆ รวมทั้งในสาขาอื่น ๆ ก็จะได้เอกสารที่ดูเป็นมืออาชีพ ด้วย stylesheet ที่จัดเตรียมโดยมืออาชีพ

แต่ข้อเสียของ LaTeX ก็คือ ผู้ใช้จำเป็นต้องเรียนรู้คำสั่งต่าง ๆ ซึ่งเท่าที่ผมใช้ก็ไม่ได้ยากไปกว่า HTML มากนัก หลายคำสั่งที่ใช้บ่อยสามารถ map กันได้แบบหนึ่งต่อหนึ่ง และข้อเสียอีกอย่างหนึ่งคือ ผู้ใช้จะไม่เห็นรูปร่างหน้าตาของเอกสารทันที จนกว่าจะสั่ง typeset ซึ่งตรงนี้ส่วนหนึ่งผมมองว่าเป็นข้อดี เพราะทำให้สามารถทุ่มสมาธิให้กับเนื้อหาได้เต็มที่ ไม่ต้องวอกแวกไปจัดหน้าตามากนัก

OpenDocument (ODF)

เป็นฟอร์แมตเปิดที่พัฒนาโดยองค์กรกลางชื่อ OASIS โดยอิง XML และได้รับการรับรองเป็นมาตรฐาน ISO/IEC 26300:2006 โดยมี OO.o เป็นซอฟต์แวร์ตัวแรกที่รองรับ และมีแนวโน้มที่ซอฟต์แวร์ต่าง ๆ จะรองรับมากขึ้น

ในแง่ความเป็นมาตรฐานแล้ว จึงไม่มีข้อกังขา แต่ก็เช่นเดียวกับ Word DOC ในแง่ที่เป็น WYSIWYG ความถูกต้องการจัดหน้าตามที่กำหนดจึงขึ้นอยู่กับพฤติกรรมผู้ใช้อย่างมาก แต่เมื่อเทียบกับ LaTeX แล้ว ผู้ใช้ที่คุ้นเคยกับ MS Office มีแนวโน้มที่จะยอมรับได้ง่ายกว่ามาก

ปัญหาอีกเรื่องหนึ่งคือ ซอฟต์แวร์หลักที่รองรับในปัจจุบัน คือ OO.o นั้น มีขนาดใหญ่ และใช้ทรัพยากรของเครื่องสูงมาก แต่ก็เริ่มจะมีซอฟต์แวร์อื่น ๆ ที่เล็กกว่ามารองรับ ODF มากขึ้นเรื่อย ๆ หรือแม้กระทั่ง MS Office 2007 SP2 เอง ในแง่นี้ก็มองเห็นทางออกในทางเทคนิคได้

Office Open XML (OOXML)

เป็นการผลักดันจากไมโครซอฟท์เองที่จะให้เป็นฟอร์แมตเปิด และได้รับการรับรองให้เป็นมาตรฐาน ECMA-367 และ ISO/IEC 29500:2008 ในที่สุด ท่ามกลางข้อกังขาของหลาย ๆ ฝ่าย ในเรื่องการซุกซ่อนข้อกำหนดที่อ้างอิง implementation ภายในของ MS Office ไว้ เช่น กำหนดแอตทริบิวต์ว่า autoSpaceLikeWord95, footnoteLayoutLikeWW8, lineWrapLikeWord6, useWord97LineBreakRules ฯลฯ ซึ่งไม่มีมาตรฐานกลางที่ไหนเขาทำกัน เพราะมันเอื้อผู้ผลิตรายใดรายหนึ่งอย่างเห็นได้ชัด แต่ในที่สุด MS ก็เดินเกมล็อบบี้จนผ่าน

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

Portable Document Format (PDF)

เป็นฟอร์แมตเปิดที่สร้างโดย Adobe ที่เป็นมาตรฐานแบบ de facto มานาน ก่อนที่จะกลายเป็น ISO/IEC 32000-1:2008 ในที่สุด

Adobe นั้น เดินเกมต่างจากไมโครซอฟท์ โดยหลังจากที่เปิดสเปคของ Postscript มาแล้ว ก็พัฒนาต่อเป็น PDF แล้วก็เปิดสเปคต่ออย่างเต็มที่ ทำให้ทุกคนสามารถพัฒนาซอฟต์แวร์ขึ้นมาอ่าน เขียน และจัดการกับ PDF ได้ ทุกคนจึงเปิดประตูต้อนรับ PDF กันเต็มที่ โดย Adobe เปิด Acrobat Reader (ที่ต่อมาเปลี่ยนชื่อเป็น Adobe Reader) ให้ดาวน์โหลดฟรี แต่ก็ยังสามารถขาย Adobe Acrobat ที่สามารถแก้ไขหรือเติมแบบฟอร์มอะไรกับ PDF ได้ Adobe ไม่ต้องผลักดันอะไรมากมาย เพราะท่าทีของ Adobe ทำให้มีกองเชียร์ที่อยากเห็น PDF กลายเป็นมาตรฐานอย่างเป็นทางการอยู่แล้ว

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

สรุปแนวทาง

จากที่กล่าวมาทั้งหมด ก็พอสรุปแนวทางว่าอย่างนี้:

แนวทางที่ 1: camera-ready เท่านั้น

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

ประเด็นในทางปฏิบัติ:

  • การตรวจทาน เข้าใจว่าส่วนใหญ่ใช้วิธีตรวจทานผ่านกระดาษ แต่ถ้าจะใช้การ highlight และ annotation ก็มีเครื่องมือที่ทำได้สำหรับ PDF (สำหรับลินุกซ์ก็มี Xournal ส่วนบนวินโดวส์ก็มี Foxit Reader)
  • การสืบค้น มีเครื่องมือสำหรับแปลง PDF เป็น text อยู่บ้าง เช่น Xpdf หรือ Foxit แต่ก็ต้องยอมรับว่า PDF เป็นฟอร์แมตสำหรับจัดพิมพ์ ไม่ใช่สำหรับสืบค้น อาจได้ผลไม่เต็มร้อยสำหรับ PDF บางประเภท
  • การปรับเปลี่ยนแก้ไข ไม่สามารถทำได้โดยสะดวก โดยปกติวิทยานิพนธ์ก็จะพิมพ์ออกมาใหม่ได้ในรูปแบบเดิมนั่นเอง
แนวทางที่ 2: รับฟอร์แมตอื่นเพิ่ม

การรับฟอร์แมตอื่นเพิ่มนี้ ใช้สำหรับกรณีที่มหาวิทยาลัยต้องการที่จะสามารถปรับเปลี่ยนการจัดพิมพ์ หรือต้องการทำ full text search แบบเต็มร้อยกว่าใช้ PDF แต่ก็ไม่ใช่ว่าการเปิดรับจะต้องเปิดรับฟอร์แมตใดก็ได้ เพราะในทางปฏิบัติก็ต้องขึ้นอยู่กับความพร้อมของทางมหาวิทยาลัยเองด้วย ฟอร์แมตที่น่าพิจารณาเพิ่มเติมก็คือ:

  • OOXML น่าจะเป็น migration ที่ต้องทำอยู่แล้ว ถ้าจะรองรับผู้ใช้ MS Office 2007
  • ODF โดยผู้ใช้ MS Office 2007 ก็อาจส่งในรูปแบบนี้ได้ ผู้ใช้ OpenOffice.org บนวินโดวส์หรือลินุกซ์ก็จะสามารถเตรียมเอกสารได้ด้วยเครื่องมือที่โอเพนซอร์ส
  • LaTeX สำหรับแวดวงวิชาการส่วนหนึ่งที่นิยมรูปแบบเอกสารที่เป็นมืออาชีพ อาจารย์ที่ปรึกษาส่วนหนึ่งที่เคยทำวิทยานิพนธ์ด้วย LaTeX น่าจะสามารถให้คำปรึกษาได้ รองรับทั้งผู้ใช้วินโดวส์และลินุกซ์

เมื่อตัดสินใจเลือกแล้ว ก็อาจจะเตรียม template สำหรับแต่ละรูปแบบเอาไว้ เพื่อให้วิทยานิพนธ์ออกมาเป็นรูปแบบเดียวกัน

ประเด็นในทางปฏิบัติ:

  • การตรวจทาน สำหรับ DOC, OOXML, ODF สามารถใช้ annotation ในตัวโปรแกรมได้ ส่วน LaTeX ก็สามารถ highlight และ annotate บน PDF ได้ หรือจะ annotate บน PDF ทั้งหมดให้เหมือนกันก็ได้ หรือจะใช้กระดาษก็ไม่ผิดกติกา
  • การสืบค้น รูปแบบ OOXML, ODF, LaTeX เนื้อหาล้วนเป็นแฟ้มข้อความอยู่แล้ว (แม้ของ OOXML และ ODF จะต้องแตก zip ออกมาก่อน) สามารถทำ index ได้ไม่ยาก
  • การปรับเปลี่ยนแก้ไข ไม่มีปัญหา โดยเฉพาะ LaTeX ปัญหาอาจจะน้อยกว่า

ป้ายกำกับ: , , ,

29 เมษายน 2552

Free Culture

bact' คิดได้น่าสนใจ เกี่ยวกับวัฒนธรรมเสรี (free culture) โดยต่อเนื่องกับ blog เรื่อง Postcardware ของผม

ประเด็นของ bact' นั้นโดนใจ แต่ผมค่อนข้างจะมองในแง่ปฏิบัติ ก็เลยไม่ได้คิดไปไกลขนาดนั้นในบางเรื่อง

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

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

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

ลองมาดูทีละข้อ

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

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

ในทางกลับกัน หลักของ action-reaction ก็ยังใช้ได้ วัฒนธรรมเสรีเป็นวัฒนธรรมของการแบ่งปัน ยิ่งคุณให้ออกไปมากเท่าไร คุณก็ยิ่งมีโอกาสได้รับ contribution มากเท่านั้นด้วย ใครจะอยากไปช่วยรายงานบั๊กหรือส่งแพตช์ปรับปรุงให้กับซอฟต์แวร์ที่มีแนวโน้มจะกั๊กไว้หาผลประโยชน์เชิงพาณิชย์เล่า?

ถึงตรงนี้ ผมอยากสรุปว่า

ความคิดแบบ proprietary ละลายได้ด้วยวัฒนธรรมการมีส่วนร่วม

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

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

พอจะสรุปแบบนี้ได้ไหม?

แนวคิดการวัดผล ต้องคำนึงถึงผลกระทบต่อระบบ

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

ผมมีข้อสังเกตเกี่ยวกับเรื่อง "ความเท่าเทียม" ที่ bact' พูดถึงในตอนท้าย ถ้าใครได้อ่านบทความ Homesteading the Noosphere (ฉบับแปล: ลงหลักปัญญาภูมิ) ก็จะพบข้อสังเกตที่น่าสนใจบางอย่าง คือในขณะที่วัฒนธรรมเสรีพูดถึง "ความเท่าเทียม" ระหว่างฝ่ายต่าง ๆ นั้น ก็ปรากฏว่ากลับมีการจัดระเบียบกันเองด้วยความเคารพซึ่งกันและกัน เอาเข้าจริงแล้ว วัฒนธรรมที่เสรีที่ดูเหมือนจะไร้ขอบเขตกลับมีเขตแดนที่เกิดแบบเป็นไปเอง เป็นความไม่เท่าเทียมที่เกิดจากความเท่าเทียม ในทางกลับกัน วัฒนธรรมของวงการซอฟต์แวร์ไทยยังไปไม่ถึงไหน ในยุคสงครามทะเล-ปลาดาวนั้น ถึงกับมีฝรั่งให้ความเห็นว่า "Forking is a norm in Thai culture." เป็นเพราะเรายังสลัดความคิดแบบ proprietary ออกไปไม่หมด ยิ่งเมื่อการ fork กลายเป็นเรื่องปกติ (เสรีแบบไทย ๆ) ก็เลยอาจจะส่งผลถึง license ที่คนคิดคอยจะลดเสรีภาพผู้ใช้ลงไปด้วย เพราะความระแวง

ในสังคมที่ mature นั้น ความเท่าเทียมได้สร้างความไม่เท่าเทียมที่สมเหตุสมผลตามหน้าที่ความรับผิดชอบ แต่สังคมที่ไม่ mature จะเรียกร้องความเท่าเทียมจนได้ความไม่เท่าเทียมแบบบังคับกลับมา

เอาเป็นว่า เรามาเริ่มสร้างความเท่าเทียมแบบ mature จากการสลัดความคิดแบบ proprietary ขณะเข้าร่วมวัฒนธรรมเสรีกันดีกว่า โดยไม่ลืมว่า เสรีภาพกับความรับผิดชอบเป็นของคู่กัน

ป้ายกำกับ:

27 เมษายน 2552

Postcardware

จาก TODO list ที่บันทึกไว้ น่าจะถือได้ว่าเรื่อง libdatrie/libthai/swath เกือบเสร็จแล้ว เหลือออก libdatrie ตัวใหม่ที่ build บนระบบต่าง ๆ ได้ และอีกเรื่องที่เสร็จแล้วคือการ update Debian package ภาษาไทย ช่วงหลายวันที่ผ่านมาเลยมาทำเรื่องผลักดัน Thai Fonts Siampradesh (non-free) เข้า Debian

เริ่มจาก file ITP bug โดยระบุรายละเอียดของแพกเกจที่จะทำไว้ ซึ่งก็ปรากฏว่ามีความเห็นตอบมาอย่างรวดเร็วดังคาด ว่า license ของ ฟอนต์ประกวดของกรมทรัพย์สินทางปัญญาร่วมกับ SIPA นั้น ไม่ผ่านเกณฑ์ของ Debian Free Software Guidelines (DFSG) และไม่สามารถอยู่ในส่วน main ของ Debian ได้

รายละเอียดต่าง ๆ ผมเคย blog ไว้แล้ว โดยประเด็นที่ผมคิดว่าหนักหนาสาหัสที่สุดก็คือเงื่อนไขข้อ 2:

2. If you wish to adapt this Font Computer Program, you must notify copyright owners (DIP & SIPA) in writing.

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

license แบบนี้ เขาเรียกกันว่าเป็น Postcardware

บังเอิญจริง ๆ ที่ bact' เพิ่งพูดถึงเรื่องนี้เหมือนกันใน blog ของเขา:

สิ่งที่ผมคิดว่าน่าสนใจ และเป็นคุณสมบัติสำคัญของ open licenses ทั้งหลาย ไม่ว่าจะเป็น copyleft, GNU หรือ Creative Commons ก็คือ การไม่ต้องขออนุญาต ผมคิดว่าการไม่ต้องขออนุญาตนี้ทำให้ ข้อมูล โค้ด ไอเดีย ต่าง ๆ มันไหลเวียนได้อย่างอิสระ-ทันที ใครอยากจะเล่นอะไรก็เอา เต็มที่ ตามเงื่อนไขที่ประกาศไว้ชัดเจนล่วงหน้า ไม่ต้องรอไปรอมา ไม่ต้องตกอยู่ในภาวะไม่แน่ใจ

นี่ยังเป็นการพูดแบบนุ่มนวลมาก แต่ถ้าลองคิดถึงผลในทางปฏิบัติจริง ๆ มันอาจร้ายแรงกว่านั้น สำหรับกรณีของฟอนต์ DIP/SIPA นี้ การตั้งเงื่อนไขให้แจ้งเป็นลายลักษณ์อักษรมีปัญหาคือ:

  • ในทางปฏิบัติ การแจ้งเป็นลายลักษณ์อักษรนั้น หากไม่มีคำตอบจากเจ้าของว่าได้รับแล้ว จะเกิดความไม่แน่นอนว่าจะสามารถเริ่มแก้ไขได้หรือไม่ เพราะถ้ามีการฟ้องร้องการละเมิด license ในภายหลัง จะเอาหลักฐานที่ไหนไปอ้างว่าได้แจ้งเป็นลายลักษณ์อักษรแล้ว ดังนั้น การต้องแจ้งเป็นลายลักษณ์อักษรจึงไม่ต่างอะไรกับการต้องขออนุญาตก่อนแก้ไข จึงไม่ถือว่าเป็น license ที่ free (เสรี) อย่างแท้จริง ไม่ว่าเงื่อนไขอื่น ๆ จะพร่ำบอกถึงเสรีภาพที่เปิดให้อย่างไรก็ตาม มันก็ยังเป็นเสรีภาพที่ต้องผ่านการขออนุมัติอยู่ดี
  • license แบบนี้ ขาดความยั่งยืน จะเกิดอะไรขึ้นถ้าโครงการนี้ถูกปิดไปแล้วในแผนงานของหน่วยงานนั้น ๆ จดหมายที่แจ้งเป็นลายลักษณ์อักษรถึงหน่วยงานนั้น จำเป็นต้องผ่านการเซ็นรับรองของผู้บริหารหลายขั้นตอน แล้วถ้าคนที่รู้รายละเอียดของโครงการนี้ไม่อยู่แล้ว ไม่มีใครดูแลโครงการต่อ จดหมายนี้จะไปถูกดองเค็มไว้ที่ขั้นตอนไหนก็ไม่มีใครรู้ได้ การเปิดเสรีจึงเสมือนถูกปิดลงทันทีที่จบโครงการ แล้วถ้าวันดีคืนดี เกิดมีหน่วยงานใหม่มารับช่วงต่อ แล้วเกิดเปลี่ยนนโยบายไปเที่ยวฟ้องร้องคนที่แก้ไขไปแล้ว โดยไม่มีหลักฐานการตอบรับทราบมายืนยัน ก็ซวยสิ
  • ใน รายการการทดสอบ license ของทีม debian-legal (มี สำเนาที่ Wikipedia) มีหลายกรณีที่แม้เป็นกรณีสมมุติ ก็มีนัยเชื่อมโยงกับโลกแห่งความเป็นจริง อย่างเช่น Desert Island test สมมุติว่ามีคนหิ้วซีดี Debian เข้าไปทำงานในชนบทห่างไกลที่ไม่มีอินเทอร์เน็ต แต่เขาต้องการพัฒนาซอฟต์แวร์ต่อเพื่อใช้ในชุมชนห่างไกลนั้น เขาไม่สามารถออกมาส่งอีเมล หรือแม้แต่ส่งจดหมายทางไปรษณีย์ได้ เขาไม่สามารถแจ้งเป็นลายลักษณ์อักษรได้ เขาก็หมดสิทธิ์แก้ไขซอฟต์แวร์เพื่อแบ่งปันผู้อื่นในชุมชนนั้นไปเลย

เมืองไทย ยังต้องทำความเข้าใจกับ free culture อีกมาก ไม่งั้น ก็จะมี license ที่ทำตาม ๆ กันมาแบบนี้อีกเป็นขบวน (เช่น ฟอนต์ของสหพันธ์อุตสาหกรรมการพิมพ์)

สำหรับ thaifonts-siampradesh นี้ แก้ไขโดยการขออนุญาตของ บริษัทเมตามีเดียเทคโนโลยี ครับ โดยผม subsidize งานส่วนนี้มาอีกที ใครที่จะแก้ไขต่อ ยังไม่มีความชัดเจนว่ายังต้องแจ้งให้กับ DIP-SIPA ทราบก่อนหรือไม่ เพราะแม้เจตนาของเงื่อนไขการแจ้งไม่น่าจะครอบคลุมถึงฟอนต์ที่ได้ดัดแปลงแล้วอย่าง thaifonts-siampradesh แต่เงื่อนไขข้อ 4 นั้นทำให้น่าเป็นห่วง:

4. The adapted version of Font Computer Program must be released under the term and condition of this license.

ซึ่งหมายความว่า ข้อ 2. จะยังคงบังคับใช้กับ thaifonts-siampradesh ไปด้วย ใครจะแก้ไขต่อ อย่าลืมแจ้ง DIP และ SIPA เป็นลายลักษณ์อักษรก่อนด้วย เพื่อความปลอดภัยของตัวท่านเอง

และทั้งหมดนี้ เป็นเหตุผลที่ thaifonts-siampradesh จำเป็นต้องเข้าไปอยู่ในหมวด non-free ของ Debian ไม่ใช่ main

ป้ายกำกับ: , ,

02 มีนาคม 2552

Some Thoughts on Translation

blog ที่แล้ว ผมเขียนถึงการตัดสินใจลดบทบาทงานแปลของตัวเองลง โดยเว้นที่จะลงรายละเอียดเรื่องเนื้องาน เพราะไม่อยากพูดหลายเรื่องในเวลาเดียวกัน ซึ่งจะทำให้ประเด็นสับสน ก็ขอมาพูดเพิ่มเติมใน blog นี้

งานแปลนั้น ที่ผ่านมาก็ได้เจอแนวคิดจากหลายคนเรื่องจะแปลหรือไม่แปลดี ซึ่งเรื่องนี้ก็ไม่ได้เจอเฉพาะภาษาไทย ภาษาอื่น ๆ เขาก็เจอ จึงถือได้ว่าเป็นเรื่องธรรมดา ลองประมวลแนวคิดต่าง ๆ ก็เช่น

pros

  • ลด digital divide ยังมีผู้ใช้อยู่มากที่ไม่สามารถใช้ภาษาอังกฤษได้ สำหรับเด็กประถมที่เพิ่งหัดอ่าน ก ข ก กา นี่ยังถือว่าก้ำกึ่ง เพราะแม้เด็กจะรู้ศัพท์ภาษาอังกฤษน้อย แต่ความเป็นเด็กก็ยังพอลองผิดลองถูกในแนวทางของเด็กได้ อีกทั้งงานที่เด็กใช้ก็ยังไม่วิกฤตมาก แต่อีกกลุ่มหนึ่งที่ลืมไม่ได้ คือผู้อาวุโสที่ในรุ่นของท่านยังไม่ได้เน้นเรียนภาษาอังกฤษมาก โดยเฉพาะในต่างจังหวัด หรือแม้แต่เด็กรุ่นใหม่ก็ตาม มีบางสาขาวิชาที่ไม่เคยต้องอ่านตำราภาษาอังกฤษเลย แต่ต้องมาทำงานรูทีนที่ต้องแข่งกับเวลา การมีภาษาไทยเป็นทางเลือก จึงเป็นการอำนวยความสะดวกแก่คนกลุ่มนี้
  • กระแสโลกาภิวัตน์ (globalization) ในส่วนเจาะกลุ่มท้องถิ่น พร้อม ๆ กับกระแสที่ทำให้ทั้งโลกเริ่มทำอะไรเหมือน ๆ กันหมด แต่โลกาภิวัตน์ก็มีแนวคิดเรื่องการปรับให้เข้ากับท้องถิ่นด้วย เช่น แมคโดนัลด์ก็มีสูตรกะเพราไก่ หรือจะเป็นเรื่องบังคับอย่างรถยนต์ที่ทำสำหรับประเทศที่วิ่งถนนเลนซ้าย-เลนขวา ซอฟต์แวร์ก็เช่นกัน แนวคิดโลกาภิวัตน์นี้เองที่ทำให้ซอฟต์แวร์เกิดแนวคิด internationalization (I18N) วินโดวส์เลิกทำ Thai Edition, Chinese Edition แล้วเริ่มใช้ I18N มาตั้งแต่ Windows 95 ก็เพื่อเตรียมพร้อมสำหรับการเจาะกลุ่มท้องถิ่นอย่างมีประสิทธิภาพ แนวคิดที่อยู่เบื้องหลังทั้งหมดนี้ ก็คือการปรับตัวในทิศทางย้อนกลับ จากเดิมที่ผู้บริโภคต้องคอยปรับตัวให้เข้ากับส่วนกลาง โลกาภิวัตน์ก็กลับทิศเสียใหม่ ด้วยการให้ส่วนกลางปรับตัวเข้าหาท้องถิ่นด้วย เพื่อความครอบคลุมให้กว้างที่สุด กระแสนี้ทำให้ภาษาท้องถิ่นเริ่มได้รับความสำคัญมากขึ้น คนในยุคโลกาภิวัตน์จึงรู้สึกเท่าเทียมกันมากขึ้นในแง่ภาษา การแปลภาษาจึงเป็นการสะท้อนการตระหนักในความสำคัญของภาษาตนเองอย่างหนึ่ง ท่ามกลางโลกที่ทุกประเทศต่างพร้อมแสดงท่าทีนี้
  • เพิ่มความเป็นที่รู้จักของภาษาไทย การที่ภาษาไทยมีการแปลจนขึ้นทำเนียบ supported language นั้น ทำให้ระดับความใส่ใจในการรองรับภาษาไทยของนักพัฒนาส่วนกลางดีขึ้น อันที่จริงแล้ว ในช่วงเริ่มแรกนั้น เราจำเป็นต้องพยายามต่อสู้เอาเองเพื่อให้ได้มาซึ่งการรองรับในระดับโครงสร้างพื้นฐาน เช่น ใน rendering engine และ input method แล้วจึงเริ่มแปลได้ แต่เมื่อแปลแล้ว และ GNOME ได้ประกาศใน release notes ว่าภาษาไทยเป็น supported language แล้ว การร้องขอในเรื่องอื่น ๆ ที่สูงขึ้นไป เช่น การตัดคำ หรือการแก้ปัญหาทั่วไป ก็ย่อมได้รับการตอบรับที่ดีขึ้น หรือแม้แต่ทาง Mozilla ก็เช่นกัน กว่าที่เขาจะรับคำแปลของเราได้ เขาก็ต้องแน่ใจว่าภาษาไทยมีการรองรับโดยพื้นฐานดีพอสมควร แต่การแปลก็ทำให้เกิดความคุ้นเคยบางอย่าง ที่ทำให้เราไม่ต้องรอ check-in แพตช์เป็นปี ๆ เหมือนเมื่อก่อน การแปลเป็นการส่งสัญญาณที่มีประสิทธิภาพอย่างหนึ่ง ว่ามีความต้องการใช้ภาษาไทยเพียงใดในซอฟต์แวร์ของเขา

cons

  • ทำให้เด็กไม่กระตือรือร้นเรียนภาษาอังกฤษ แม้ภาษาท้องถิ่นจะมีความสำคัญเพิ่มขึ้นในยุคโลกาภิวัตน์ แต่เวลาที่ติดต่อกับชาวต่างประเทศ ภาษาอังกฤษก็ยังเป็นภาษาที่สะดวกที่สุดอยู่ดี ดังนั้น การแปลข้อความจึงมีผลด้านลบต่อการพัฒนาประเทศ ในแง่ที่ทำให้ประชากรขาดแรงจูงใจ หรือเครื่องมือช่วย ในการเรียนภาษาอังกฤษไปเรื่องหนึ่ง ประเด็นนี้มีนัยสำคัญพอสมควร ดังจะเห็นได้จากการที่เด็กจบใหม่จำนวนมากอ่อนภาษาอังกฤษ หลังจากมีตำราแปลออกมามากมาย การตอบถามปัญหาตามเว็บบอร์ดต่าง ๆ จะเริ่มยุ่งยาก เมื่อผู้ถามต่างเรียกร้องแต่คำตอบภาษาไทย แนะนำลิงก์คำอธิบายภาษาอังกฤษก็โอดครวญ
  • แปล doc ดีกว่า อันนี้เป็นบทเสริมของข้อที่แล้ว คือมีบางความเห็น เห็นว่าไม่ควรแปลโปรแกรม แต่แปลเอกสารกับ help ดีกว่า เพื่อช่วยให้คนไทยได้เข้าถึงเทคโนโลยีง่ายเข้า
  • ทำให้ผู้ใช้ไทยไม่ใช้โลแคลไทย อันนี้เป็นประเด็นตรงกันข้าม คือเกิดจากผู้ใช้ที่นิยมใช้ UI ภาษาอังกฤษมากกว่าฉบับแปล ..ชอบดูหนังซาวนด์แทร็ก ว่างั้น.. ทำให้เวลาติดตั้งและเข้าระบบ ก็จะเลือกโลแคล en_US ไว้ก่อน ซึ่งผลก็คือ ทำให้ไม่ได้ใช้ส่วนรองรับภาษาไทยที่ขึ้นกับโลแคล เช่น input method และเรื่องอื่น ๆ ที่อาศัยโลแคลเป็นพื้นฐานในการตัดสินใจของโปรแกรม ทำให้การพัฒนาต่าง ๆ เรื่องภาษาไทย แทบจะสูญเปล่า เรื่องนี้ผมก็เคย blog ไว้

ความเห็นของผมเป็นดังนี้:

  • ใน blog เรื่องผมเข้าร่วมทีมแปลได้ยังไง ผมได้เล่าไว้ว่า ก่อนที่จะร่วมทีมแปลนั้น ผมไม่เคยเปิดใช้ภาษาไทยเลยเหมือนกัน แต่หลังจากไปเจอกรณีลูกค้าที่ยอมใช้ลินุกซ์ แต่ต้องใช้เมนูภาษาไทย เพราะเขาไม่คล่องภาษาอังกฤษ และต้องการความรวดเร็วในการทำงาน ทำให้ผมต้องเปิดใช้คำแปลภาษาไทยเป็นครั้งแรก และได้รับคำติมามากมายเกี่ยวกับคำแปลที่ขาด ๆ โบ๋ ๆ และใช้ภาษาตลก ๆ ในหลายที่ในตอนนั้น จนนำมาสู่การรายงานปัญหากับทีมแปล และร่วมแปลในแพกเกจที่เจอปัญหา นั่นก็เป็นหลักฐานหนึ่งที่ผมปฏิเสธไม่ได้ ว่า ความต้องการโปรแกรมที่แปลไทยนั้น มีอยู่จริง
  • ก่อนที่จะพบกรณีนั้น ผมไม่เคยคิดจะแตะต้องงานแปลเลย เพราะต้องการเน้นงานพัฒนามากกว่า แต่เมื่อได้เปิดใช้เมนูไทยแล้ว ก็พบว่า โปรแกรมที่แปลไม่สมบูรณ์นั้น ให้ความรู้สึกแย่ยิ่งกว่าไม่แปลเลยเสียอีก เพราะจะรู้สึกได้ถึงความไม่เนี้ยบเป็นเนื้อเดียวของเมนูและกล่องโต้ตอบต่าง ๆ ดังนั้น แม้จะไม่พูดถึงว่าควรแปลหรือไม่ แต่ถ้าได้เริ่มแปลแล้ว ควรแปลให้สมบูรณ์
  • ประเด็นเรื่องไม่แปลโปรแกรมแต่แปลเฉพาะ help นั้น จะขัดแย้งกันเองในทางปฏิบัติ เพราะโดยทั่วไป วิธีทำงานที่ดีคือ แปลโปรแกรมให้เสร็จ แล้วจึงแปล help เพราะ help จะอ้างถึงเมนู กล่องโต้ตอบต่าง ๆ รวมทั้งภาพหน้าจอตัวอย่าง ถ้าในภายหลังมีการแปลโปรแกรม คุณก็จะต้องไล่แก้ help ทั้งหมดให้ใช้ข้อความตามโปรแกรมด้วยอยู่ดี การที่จะลดความซ้ำซ้อนของงาน จึงควรทำในลำดับกลับกันมากกว่า
  • เรื่องการไม่ส่งเสริมการเรียนรู้ภาษาอังกฤษนั้น ผมเห็นด้วยพอสมควร แต่ผมเชื่อว่า การให้ทางเลือกน่าจะดีกว่าอยู่ดี เพราะในบางกรณีเราก็บังคับใช้แต่ภาษาอังกฤษไม่ได้จริง ๆ และเมื่อรวมกับเรื่องผู้ชอบใช้โปรแกรมฉบับไม่แปล ผมก็เห็นว่ายังมีผู้ใช้ที่พยายามจะใช้ภาษาอังกฤษอยู่ดี เพียงแต่จุดบอดของเรื่องนี้ก็คือ ยังขาด UI ที่ดี ในการเลือกภาษาโปรแกรมโดยไม่กระทบกับโลแคลหมวดอื่น ๆ ซึ่งเรื่องนี้ ออกจะ convince นักพัฒนายากสักหน่อย เพราะประเทศพัฒนาแล้ว เขานิยมใช้โปรแกรมฉบับแปลกันเป็นหลัก และเขาก็ถูกทำให้เชื่อในเรื่อง digital divide อย่างฝังลึก เราต้องทำให้เขาเชื่อ ว่าประเทศกำลังพัฒนายังคงต้องการใช้โปรแกรมภาษาอังกฤษอยู่ ก่อนที่จะอภิปรายถึงทางออกต่าง ๆ ต่อไป จุดนี้ ผมคิดว่าจะพยายามหาทางแก้ดู

ในฐานะที่ผมไม่ได้เป็นผู้ริเริ่มการแปล GNOME ผมจึงไม่สามารถพูดแทนกลุ่มผู้ริเริ่มได้ ผมพูดได้เพียงว่า งานแปลนั้นต้อง all-or-none ถ้าได้เริ่มแล้ว ต้องทำให้จบ ไม่งั้นก็ไม่ต้องทำเลย แต่ถ้าถามว่าผมเห็นด้วยไหมที่เขาเริ่ม ผมชั่งน้ำหนักข้อดีข้อเสียและทางออกต่าง ๆ ก็คิดว่าเห็นด้วย

สุดท้าย ก็ขอสรุปลักษณะต่าง ๆ เกี่ยวกับงานแปลในทัศนะของผม:

  • งานแปลที่ดี ถ้าได้เริ่มแล้ว ต้องทำให้สมบูรณ์
  • งานแปล เป็นงานที่ไม่มีวันเสร็จ ตราบใดที่ซอฟต์แวร์ยังมีการพัฒนาอยู่ งานแปลก็ยังต้องทำควบคู่ต่อไป
  • งานแปล เป็นงานที่มีแรงจูงใจเชิงพาณิชย์ต่ำมาก ดังนั้น สมมุติฐานในทฤษฎีโอเพนซอร์สที่อ้างถึง selfish agent ในระบบทุนนิยม ที่เป็นแรงกระตุ้นให้นักพัฒนาสร้างงานออกเผยแพร่แบบโอเพนซอร์สนั้น แทบจะใช้ไม่ได้กับงานแปลเลย งานแปลสามารถขาย service ได้ไหม? ยากครับ แค่จะมีใครยอมใช้โปรแกรมฉบับแปลยังสงสัยกันอยู่ มีใครยอมควักกระเป๋าจ่ายเพื่อให้ได้ฉบับแปลก่อนคนอื่น หรือให้ได้คำแปลในแบบฉบับที่ต้องการไหม? ยากครับ อย่างมาก งานแปลก็เป็นแค่ส่วนเล็ก ๆ ส่วนหนึ่งในโครงการที่ใหญ่กว่าเท่านั้น ชื่อเสียงในวัฒนธรรมแฮกเกอร์เหรอ? เมินซะเถอะ แค่แปลโปรแกรมนี่นะ? งานแปลจึงเป็นงานที่นอกจากจะหนักแบบมาราธอนแล้ว ยังต้องอาศัยใจอย่างมากด้วย

งานแปลที่เป็นทีมเล็ก ๆ แปลกันไม่กี่คน จึงเป็นทีมที่ขาดความยั่งยืนครับ มันจะตายในไม่ช้า จนกว่าจะมีผู้เสียสละเข้ามาช่วยอุ้มมันต่อ

ป้ายกำกับ: ,

03 ตุลาคม 2551

A Corollary to Linus's Law

ESR เขียนถึง Linus's Law ไว้ใน บทที่ 4 ของบทความ The Cathedral and the Bazaar (มี ฉบับแปลไทย) ว่า

Given enough eyeballs, all bugs are shallow.

แต่สำหรับประเทศกำลังพัฒนาอย่างเรา ผมอยากจะเพิ่มว่า

Given enough mouths, most bugs catch interests.

ผมได้ file bug พร้อมเสนอแพตช์สำหรับ libx11 ไป 3 bug ที่ Freedesktop.org (สรุปไว้ใน blog เก่า) ซึ่งสองในสามบั๊กนี้ เป็นบั๊กค่อนข้างร้ายแรงสำหรับผู้ใช้ภาษาไทยที่ได้พบ คือถึงกับทำให้ป้อนภาษาไทยไม่ได้ หรือป้อนได้แต่อักขระบนเส้นบรรทัด ป้อนสระบน-ล่างและวรรณยุกต์ไม่ได้เลย แต่สำหรับนักพัฒนาที่ Freedesktop แล้ว เรื่องนี้ไม่ได้สำคัญอะไรมาก หรืออาจจะสำคัญ แต่ไม่รู้จะทดสอบยังไง

ผมห่างเหินจากการทำงานในชั้น Xlib มานาน นับตั้งแต่ X.Org fork ออกมาจาก XFree86 ผมก็ไม่ได้ไปแตะต้องอะไรกับ X อีกเลย จนกระทั่งได้พบปัญหาเหล่านี้ ถึงได้กลับไป ผมจึงเป็นหน้าใหม่โดยสิ้นเชิงสำหรับชุมชนใหม่นี้ ทั้ง ๆ ที่ถ้าเป็นสมัย XFree86 แล้ว แพตช์ต่าง ๆ เกี่ยวกับ I18N จะได้รับความสนใจมากกว่านี้มาก

กับ Debian X Strike Force ก็เช่นกัน ผม file Debian #443800 สำหรับหนึ่งในสามบั๊กนั้นไป ก็ไม่มีเสียงตอบรับใด ๆ นอกจากการ forward bug ไปที่ upstream ซึ่งการ forward bug ของ Debian นี้ เป็นความพยายามที่จะลดความแตกต่างระหว่าง Debian กับ upstream ให้มากที่สุด คืออะไรที่พบโดยผู้ใช้ Debian แต่เป็นปัญหาที่ต้องแก้ที่ upstream ก็จะ forward รายงานให้ แต่ในกรณีของผมนี้ ผมได้ถอยลงมาจาก upstream เพื่อหวังว่า distro จะช่วยผลักดันแพตช์ให้ เหมือนกับที่ผมเคยได้รับจากกรณีแพตช์ตัดคำไทยใน Gecko ซึ่งในขณะนั้น นักพัฒนาของ Debian ได้ forward bug กลับไปที่ Mozilla พร้อมกับย้ายไปคุยเกี่ยวกับแพตช์ที่นั่นให้ด้วย แต่ในกรณีของ libx11 กลับไม่ใช่ คือ forward แล้วเงียบ อาจเป็นเพราะเขาไม่มีข้อมูลเพียงพอเรื่องภาษาไทย หรือไม่เห็นมีคนไทยอื่น ๆ บ่น หรือยังมีงานอื่นที่สำคัญกว่าต้องทำก็ได้ นั่นทำให้ผมเลิกล้มที่จะ file อีกสองบั๊กที่เหลือ แล้วไปพยายามผลักดันที่ upstream ด้วยตัวเอง

แต่สำหรับ Ubuntu แล้ว เรื่องมันต่างกัน เพราะเรื่องไม่ได้เริ่มจากมุมมองของนักพัฒนา แต่มาจากมุมมองของผู้ใช้ ใน LP #273856 โดยคุณ DArKer ได้รายงานว่า "Thai language input not work correctly" พร้อมกับมีความเห็นของผู้ใช้อื่น ๆ ตามมาอีกเป็นพรวน ทุกคนช่วยกันสาธยายอาการต่าง ๆ พร้อมวิธีแก้ขัดของตัวเอง การที่มีผู้ใช้หลายคนยืนยันจึงต่างจากการบุกเดี่ยวของผมในดินแดนแปลกหน้าราวฟ้ากับดิน และส่วนหนึ่งที่ต้องยอมรับคือ ท่าทีที่สนใจปัญหา I18N ของ Ubuntu เองด้วย หลังจากที่นักพัฒนามารับเรื่องและวิเคราะห์ปัญหาร่วมกับผู้ใช้ พอผมซึ่งมาสาย เข้าไปพูดถึงแพตช์ที่เคยทำไว้ เขาซึ่งพอรู้รายละเอียดของปัญหาระดับหนึ่งมาแล้ว ก็ทดสอบและรับแพตช์ได้อย่างรวดเร็ว

นี่คือสิ่งที่ ESR ได้กล่าวถึง The Importance of Having Users เสียงของผู้ใช้ มีส่วนช่วยแก้ปัญหาพอสมควร สำหรับสาขาของปัญหาที่อยู่นอกความสนใจของกระแสหลัก โดยเฉพาะเรื่องภาษาของประเทศกำลังพัฒนาอย่างเรา

จริงอยู่ ว่าการมีจำนวนผู้ใช้ปลายทาง (end-user) ที่มาก มีส่วนช่วยกดดันทางอ้อม ให้นักพัฒนาต้องสนใจ แต่ผลจะชัดเจนกว่ามาก ถ้าผู้ใช้ลงมือ "ส่งเสียง" ต่อปัญหาต่าง ๆ โดยตรง ตามแนวทางที่ซอฟต์แวร์เสรีและโอเพนซอร์สเปิดไว้ให้

ป้ายกำกับ: , , ,

13 กรกฎาคม 2551

DIP-SIPA Fonts License

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

สืบเนื่องมาจาก ฟอนต์ประกวดของ DIP-SIPA ซึ่ง (ตามที่ระบุใน license) “มีวัตถุประสงค์เพื่อก่อให้เกิดความร่วมมือในการสร้างสรรค์ฟอนต์ในวงกว้าง รวมทั้งเพื่อประโยชน์ทางด้านการศึกษาและการแบ่งปันความรู้และพัฒนาโปรแกรมคอมพิวเตอร์ฟอนต์นี้” ซึ่งโดยเจตนารมณ์แล้ว สมควรที่จะผลักดันเข้า distro ต่าง ๆ เพื่อเผยแพร่ในวงกว้างต่อไป แต่มาติดปัญหาที่ตัว license โดยขอคัดฉบับภาษาอังกฤษมาอ้างอิง ส่วนฉบับภาษาไทยนั้น มีความกำกวมในคำแปล ซึ่งจะพูดถึงต่อไป:

  1. Allow to use without any charges and allow to reproduce, study, adapt and distribute this Font Computer Program. Neither the original version nor adapted version of Font Computer Program may be sold by itself, except bundled and/or sold with any computer program.
  2. If you wish to adapt this Font Computer Program, you must notify copyright owners (DIP & SIPA) in writing.
  3. No adapted version of Font Computer Program may use the Reserved Font Name(s), the name(s) of the copyright owners and the author(s) of the Font Computer Program must not be used to promote or advertise any adapted version, except obtaining written permission from copyright owners and the author(s).
  4. The adapted version of Font Computer Program must be released under the term and condition of this license.

สาระก็คือ ห้ามขายตัวฟอนต์เดี่ยว ๆ นอกนั้นให้แจกจ่าย ดัดแปลงได้ โดย ต้องแจ้งเจ้าของเป็นลายลักษณ์อักษรก่อน และห้ามใช้ชื่อที่สงวนไว้ (ซึ่งในตอนต้นของ license มีการประกาศรายชื่อ “Reserved Font Name(s)” ไว้แล้ว) ปิดท้ายด้วยข้อบังคับว่า ฟอนต์ที่ดัดแปลงแล้วต้องเผยแพร่ด้วย license เดียวกันนี้

ทุก ๆ ข้อ ดูจะโอเค และมีสาระเหมือน Open Font License (OFL) รุ่นเก่าของ SIL ยกเว้นข้อ 2. ที่ระบุให้แจ้งเจ้าของเป็นลายลักษณ์อักษรก่อน ซึ่งไม่มีใน OFL

ข้อนี้ เป็นปัญหาในทางปฏิบัติสำหรับซอฟต์แวร์เสรีและโอเพนซอร์ส ถึงแม้ license จะอนุญาตให้แก้ไขได้ แต่การที่ต้องแจ้งเป็นลายลักษณ์อักษรก่อนแก้นั้น จะเป็นการเพิ่มขั้นตอนที่ยุ่งยาก โดยเฉพาะสำหรับคนที่ไม่สามารถติดต่อเจ้าของได้ ไม่ว่าจะด้วยอุปสรรคใด ๆ ก็ตามแต่ จะหมดสิทธิ์แก้ไขทันที และยังมีความกำกวมว่าต้องรอคำตอบรับจากเจ้าของว่ารับทราบแล้วก่อนแก้ไขหรือไม่ด้วย (ไม่งั้นจะมีหลักฐานอะไรบอกว่าได้แจ้งแล้ว) ซึ่งก็เท่ากับต้องขออนุญาตก่อนแก้กลาย ๆ คล้ายซอฟต์แวร์ปิดนั่นเอง

ซอฟต์แวร์เสรีทั่วไป จะอนุญาตให้ผู้ได้รับซอฟต์แวร์ใช้สิทธิ์ได้ทันที โดยไม่ต้อง “call home” และเขาจะ contribute กลับหรือแจ้งเจ้าของหรือไม่ ก็ให้เป็นสิทธิ์ของเขาเอง ซอฟต์แวร์ที่ต้องแจ้งก่อนแก้แบบนี้ จึงไม่ได้รับการยอมรับเข้าไปอยู่ในส่วนแกนหลักของ distro อย่าง Debian หรือ Ubuntu (หรือจะเป็น RedHat/Fedora ก็เคร่งครัดเรื่อง license ไม่แพ้กัน จากที่ผมเคยได้รับการติดต่อมา) อย่างดีก็อยู่ในหมวด non-free หรือ restricted ซึ่งไม่มีการ maintain เพราะจะมีอุปสรรคในการแจ้งเป็นลายลักษณ์อักษรก่อนแก้บั๊ก ทั้งการแยกออกไปจากส่วนหลักยังเป็นการป้องกันผู้ใช้จากปัญหาทางกฎหมายขณะใช้ซอฟต์แวร์ต่าง ๆ เยี่ยงซอฟต์แวร์เสรีทั่วไปอีกด้วย

ผมเองได้รับการว่าจ้างจาก SIPA (ผ่าน metamedia) ให้ทำ deb สำหรับฟอนต์ชุดนี้ พร้อมทั้ง “ผลักดันเข้าสู่ Debian/Ubuntu” ซึ่งผมทำได้เพียงส่วนแรก คือดัดแปลงฟอนต์ประกวดชุดนี้ โดยแจ้งเป็นลายลักษณ์อักษร พร้อมทั้งเปลี่ยนชื่อฟอนต์หลบชื่อสงวนก่อน build เป็น deb เผยแพร่ในซีดีชุดสุริยัน แต่ส่วนหลัง คือการผลักดันเข้า Debian/Ubuntu นั้น จำเป็นต้องทำความกระจ่างเกี่ยวกับเงื่อนไขข้อ 2. ของ license ก่อน ว่าจะผลักดันเข้า main หรือ non-free เนื่องจากสามารถตีความได้สองทางคือ:

  1. ผมได้แจ้งเป็นลายลักษณ์อักษรแทนผู้ที่จะดัดแปลงต่อจากชุดที่ผมดัดแปลงแล้ว ดังนั้น ใครจะดัดแปลงต่อจากผมก็ไม่ต้องติดเงื่อนไขข้อ 2. อีก ซึ่งถ้าตีความแบบนี้ ก็เท่ากับเข้าใน main ได้เลย
  2. เงื่อนไขข้อ 4. ที่บอกให้ฟอนต์ที่ดัดแปลงต้องอยู่ในเงื่อนไขของ license นี้ ก็หมายถึงครอบคลุมข้อ 2. เข้าไปด้วย ดังนั้น ใครจะดัดแปลงต่อจากผม ก็ไม่มีข้อยกเว้น ต้องแจ้งเจ้าของก่อนทั้งนั้น ซึ่งถ้าตีความแบบนี้ ก็ต้องเข้าหมวด non-free/restricted

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

แต่ปัญหาคือ เรื่องนี้หายเข้ากลีบเมฆ ตามธรรมเนียมราชการ

เพื่อความแน่ใจ ผมจึง โพสต์ถาม ทีมกฎหมายของ Debian อีกทางหนึ่ง เกี่ยวกับการตีความข้อกฎหมายในกรณีนี้ด้วย

ถ้าทุกอย่างไม่มีคำตอบ ก็คงจำเป็นต้องเสนอเข้าหมวด non-free แทน แม้จะขัดกับเจตนารมณ์เริ่มแรกของโครงการประกวดฟอนต์นี้ก็ตาม

ย้อนกลับมาที่ฉบับแปลไทยของ license นี้สักนิด ที่ผมพูดไว้ตอนต้นว่าแปลกำกวม คือเงื่อนไขข้อ 3. ซึ่งฉบับภาษาอังกฤษบอกว่า:

No adapted version of Font Computer Program may use the Reserved Font Name(s), ...

แต่ฉบับแปลไทยแปลไว้ว่า:

เมื่อดัดแปลงโปรแกรมคอมพิวเตอร์ฟอนต์นี้แล้ว ห้ามผู้ดัดแปลงใช้ชื่อฟอนต์เดิม ...

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

ความกำกวมของ license จึงอยู่ตรงนี้อีกจุดหนึ่ง แต่เมื่อเข้าไปอยู่ใน distro ผมคงต้องอ้างอิงฉบับภาษาอังกฤษเป็นหลัก

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

ป้ายกำกับ: , , ,

29 มิถุนายน 2551

A Bug a Day

ช่วงที่ผ่านมา ได้ทำตัวเป็นผู้ใช้ซอฟต์แวร์เสรีที่ดี คือได้ file bug เกือบทุกวัน..

17 มิ.ย.
Debian #486614 update คำแปลไทยสำหรับ debconf ของ samba4
ที่มาของบั๊ก: ได้รับแจ้งจาก maintainer
19 มิ.ย.
รายงานบั๊กที่พบใน fontforge เกี่ยวกับเรื่องค่าขยะใน strikeout และ sub/superscript (thread ใน thai-linux-foss-devel list) โดยแจ้งไปที่ fontforge-devel mailing list (แต่ไม่โดน archive) วันถัดมาเขาก็แก้ให้ใน CVS เรียบร้อย
ที่มาของบั๊ก: จาก ข่าวเรื่อง Plutoid ทักท้วงไปหลายที่ โดยที่ blognone แก้ด้วยการขีดฆ่าข้อความเดิมทิ้ง ซึ่งบังเอิญมันเละในเครื่องผม ซึ่ง gen ฟอนต์จากรุ่นพัฒนา
21 มิ.ย.
ไม่ได้รายงานบั๊ก แต่ follow up Debian #473508 เกี่ยวกับเรื่อง AbiWord 2.6
ที่มาของบั๊ก: บั๊กเก่า รอนานแล้ว
23 มิ.ย.
Freedesktop #16475 ว่าด้วยเรื่อง SCIM ไม่ทำงานบนโลแคลไทย เพราะปัญหาใน Xlib
ที่มาของบั๊ก: จาก รายงานเดิม จากนักพัฒนา Xandros
Debian #487664 คำผิดใน Debian Developer's Reference ใน 6.7.9 ว่าด้วยเรื่องของ debug package
ที่มาของบั๊ก: ระหว่างหาที่ผิดใน xlib โดยติดตั้ง libx11-6-dbg ซึ่งเป็น debug package ของ libx11-6 แล้วหาวิธีตั้งค่าก่อนดีบั๊ก ซึ่งสุดท้ายก็พบว่าไม่ต้องตั้งอะไรเลย แค่ติดตั้งก็ใช้ได้แล้ว รายละเอียดอ่านจาก reference ก็เข้าใจ เพียงแต่เจอที่ผิดในเนื้อหา โดยที่ยังไม่มีใครรายงาน เลยรายงานซะ
24 มิ.ย.
ไม่ได้ file bug อะไร แต่เป็นกิจกรรมการ upload deb คือแพกเกจที่ติดต่อ sponsor ไว้นานแล้ว (gtk-im-libthai, libdatrie, libthai) พอดี sponsor ว่างมา upload ให้แล้ว ก็เลยจัดการ update CVS ตามนั้นด้วย
ที่มาของบั๊ก: lintian
25 มิ.ย.
Debian #487912 ขอกำจัด conflict กับ xiterm+thai ใน xiterm (openi18n) deb
ที่มาของบั๊ก: xiterm+thai 1.07 เปลี่ยนชื่อ binary program หลบ xiterm ของ openi18n แล้ว และ xiterm+thai 1.07-1 ใน debian (โดย นิวตรอน) ก็ได้ตัด conflict ออกแล้ว เหลือแต่ที่ xiterm เท่านั้น
26 มิ.ย.
Debian #488090 update คำแปลของ dpkg พร้อมกันนั้นก็ update คำแปลของ debian-installer ด้วย
ที่มาของบั๊ก: ติดค้างงานแปลไว้นานแล้ว
28 มิ.ย.
รายงานบั๊ก GPeriodic ซึ่งไม่ได้ update ชื่อธาตุที่ 110, 111 ซึ่งได้ชื่ออย่างเป็นทางการแล้ว (Darmstadtium และ Roentgenium ตามลำดับ) พร้อมทั้ง mark ข้อความสำหรับแปลเพิ่มอีกหนึ่งข้อความด้วย (ส่งบั๊กทางเมลส่วนตัว ไม่มี archive)
ที่มาของบั๊ก: กระทู้หนึ่งใน KKL แนะนำโปรแกรมตารางธาตุของเด็กไทยเขียน เลยเกิดแรงบันดาลใจมาสำรวจ GPeriodic (เคย blog ถึง เมื่อสามปีก่อน) พร้อมทั้งแปลข้อความเป็นไทย (ยังไม่เสร็จ) เพราะเห็นว่า ถึงกับมีคนเขียน แสดงว่ามีคนต้องการใช้
29 มิ.ย.
Debian #488461 เกี่ยวกับบั๊ก GPeriodic นั่นแล แต่รายงานที่ Debian ด้วย

มีแต่บั๊กตอดเล็กตอดน้อย.. แต่ก็ด้วยการรายงานบั๊กไม่ใช่หรือ ซอฟต์แวร์เสรี/โอเพนซอร์สถึงมีการพัฒนา :-)

ป้ายกำกับ: , , , ,

hacker emblem