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


11

คุณอาจรู้ว่ารายการใบอนุญาตโอเพนซอร์สได้รับการอนุมัติอย่างเป็นทางการจาก OSI ที่สำคัญที่สุดฉันคิดว่าจะเป็น GPL, MIT, [ใส่ใบอนุญาตโปรดของคุณที่นี่]

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

  • มันปล่อยแหล่งที่มา แต่ไม่ได้สัญญาว่าจะปล่อยแหล่งที่มาในอนาคต

  • อนุญาตให้ดัดแปลงคำแนะนำได้ แต่ไม่ได้สัญญาว่าจะยอมรับการแก้ไขและไม่อนุญาตการแจกจ่ายภายนอกของเวอร์ชั่นที่มีการแก้ไขภายนอก

  • อนุญาตให้ใช้ซอฟต์แวร์ในเชิงพาณิชย์หรือโครงการที่ต้องชำระเงิน แต่ไม่อนุญาตให้ขายซอฟต์แวร์เอง

ฉันคิดว่ามันอาจเรียกได้ว่า "แหล่งข้อมูลที่มีอยู่" ไม่ใช่แหล่งโอเพ่นซอร์สตามที่เราคิด

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

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

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

อยากรู้ว่าคนอื่นคิดอย่างไร


1
ฉันคิดว่าส่วนหนึ่งของจุดสำคัญของ OSS คือคุณไม่ได้พึ่งพาคนอื่นในการยอมรับและแจกจ่ายแพตช์คุณมีแหล่งที่มาเพื่อให้คุณสามารถทำสิ่งต่าง ๆ ได้ด้วยตัวคุณเอง ถ้าคุณต้องการ)
Jon Hopkins

สำเนาซ้ำที่เป็นไปได้: programmers.stackexchange.com/questions/26548/…
Dipan Mehta

ดูเหมือนว่าข้อกำหนดสิทธิการใช้งานนั้นค่อนข้างชัดเจนเกี่ยวกับซอฟต์แวร์นี้ ฟังดูควรเขียนรหัสของตัวเองแทนที่จะใช้รหัสที่ได้รับอนุญาตในวิธีที่ไม่อนุญาตให้ใช้รหัสในแบบที่ต้องการใช้
Ramhound

คำตอบ:


5

สำหรับโครงการที่จะต้องพัฒนาตั้งแต่เริ่มต้นการทำงานของซอฟต์แวร์นี้มันเป็นความสะดวกที่แน่นอนว่าจะไม่ทำเช่นนั้น

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

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

ไม่ตอบรับปัจจัยเหล่านี้บ่งชี้ว่า OSS เป็นตัวเลือกที่ดีกว่า

ส่วนใหญ่โค้ดนั้นไม่ใช่ปัจจัยกำหนด หนึ่งต้องตรวจสอบภาพใหญ่

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


2

คำถามนี้และห้องสมุดภายนอกอื่น ๆ คือการบำรุงรักษา

อายุการใช้งานของแอปพลิเคชันของคุณคืออะไรและอายุการใช้งานที่ชัดเจนของห้องสมุดนี้คือเท่าไหร่ หวังว่าคุณจะสั้นที่สุด

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

ความคิดนี้เพียงอย่างเดียวอาจทำให้ห้องสมุดมีราคาแพงเกินกว่าจะใช้

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

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

คุณมีอิสระที่จะพูดคุยเกี่ยวกับห้องสมุดที่เป็นปัญหาหรือไม่?


2

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

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

สถานการณ์เดียวที่ IMHO "โอเพ่นซอร์ส" ชนะสัญญาอนุญาต "แหล่งที่มา" ที่มีอยู่ในคำถามคือเมื่อใด

  • ใบอนุญาตของผลิตภัณฑ์ของเรายังต้องการการเปิดเผยแหล่งที่มาของห้องสมุดที่มีอยู่
  • เราอยู่ในธุรกิจการผลิตไลบรารี่รุ่นปรับปรุง / ขยาย

1

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

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

คำใดคำหนึ่งมีความสามารถที่จะกลายเป็นเรียกชื่อผิด ฉันจ่ายเงิน $ 50 สำหรับการคัดลอกแรกของ emacs (ในเทป QIC) แต่ emacs เป็นซอฟต์แวร์ฟรี ฉันมีซอร์สโค้ดสำหรับแอปพลิเคชั่นที่เป็นกรรมสิทธิ์ซึ่ง บริษัท ของฉันใช้ภายใน แต่ไม่ได้เป็นโอเพ่นซอร์ส

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

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

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


-1

เรื่องนี้ค่อนข้างสำคัญ ปัญหาหลักเกี่ยวกับวิธี "แหล่งที่มา" ที่คุณได้อธิบายไว้:

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

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


สิ่งที่ heck คือ "โอเพ่นซอร์สจริง" ใบอนุญาตอธิบายให้ฉันฟังดูสมจริงสำหรับฉัน
Ramhound
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.