จะหลีกเลี่ยงการถูกแยกจากกันโดยการมีส่วนร่วมที่ทรงพลังมากขึ้นได้อย่างไร?

ตามที่รายงานเมื่อเร็ว ๆ นี้ที่นี่ :

Xamarin ได้แยก Cocos2D-XNA ซึ่งเป็นกรอบการพัฒนาเกม 2D / 3D สร้างห้องสมุดข้ามแพลตฟอร์มที่สามารถรวมไว้ในโครงการ PCL

อย่างไรก็ตามผู้ก่อตั้งโครงการที่ถูกแยกออกพูดว่า :

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

ในขณะที่ไม่ผิดกฎหมายก็ผิดจรรยาบรรณ

ดูเหมือนว่าหน้า GitHub ของโครงการใหม่ไม่ได้ระบุว่ามันเป็นทางแยกในลักษณะ GitHub ทั่วไปการเลือกสำหรับส่วนประวัติที่ถอดออกได้อย่างง่ายดายแทน (ดูด้านล่าง)

ดังนั้นคำถามของฉันคือ:

1. การกระทำของ Xamarin และวิธีการกระทำนั้นถูกต้องตามหลักจริยธรรมหรือไม่?
2. เป็นไปได้หรือไม่ที่จะหลีกเลี่ยงสถานการณ์เช่นนี้หากคุณเป็นผู้พัฒนาเดี่ยวหรือกลุ่มนักพัฒนาขนาดเล็กที่ไม่มีเงินทุน?

ฉันหวังว่านี่อาจเป็นคำถามแบบ wiki หรือจะมีคำตอบที่ตรงตามวัตถุประสงค์บนพื้นฐานจริยธรรม / ปรัชญา OSS ที่ทันสมัย

การกระทำของ Xamarin และวิธีการกระทำนั้นถูกต้องตามหลักจริยธรรมหรือไม่?

ทีนี้มาถามผู้เชี่ยวชาญ - รายการโอเพ่นซอร์ส Initiative ของ MIT Licenseนั้นมีใบอนุญาตที่อ้างถึงทั้งหมด:

ใบอนุญาต MIT (MIT)

ลิขสิทธิ์ (c)

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

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

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

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

นี่เป็นหนึ่งในกรณีที่จริยธรรมและความชอบด้วยกฎหมายมีความเหมือนกัน หากบุคคลหรือกลุ่มไม่เข้าใจใบอนุญาตหรือมีความหมายแล้วพวกเขาก็ล้มเหลวในการตรวจสอบสถานะ The Open Source Initiative ให้แหล่งข้อมูลที่น่าสนใจอื่น ๆ อีกมากมายที่จะช่วยให้เราเข้าใจใบอนุญาตเช่นตัวแปร MIT ลองดูข้อสองสามข้อของนิยามโอเพนซอร์ซของพวกเขา:

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

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

5) ไม่เลือกปฏิบัติต่อบุคคลหรือกลุ่ม - ใบอนุญาตต้องไม่เลือกปฏิบัติต่อบุคคลหรือกลุ่มบุคคลใด ๆ

6) ไม่มีการเลือกปฏิบัติกับสาขาการมานะ - ใบอนุญาตจะต้องไม่ จำกัด ใครจากการใช้งานโปรแกรมในสาขาเฉพาะของความพยายาม ตัวอย่างเช่นมันอาจไม่ จำกัด โปรแกรมที่ถูกใช้ในธุรกิจหรือจากการใช้สำหรับการวิจัยทางพันธุกรรม

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

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

แนวคิดก็คือคุณมีส่วนร่วมในสิ่งที่ดีกว่าโดยการยกเลิกสิทธิ์ตามกฎหมายใด ๆ ที่คุณต้องควบคุมและ จำกัด การใช้งานและการเปลี่ยนแปลงสิ่งที่คุณทำอย่างชัดเจน หาก Microsoft ต้องการแยกโครงการ FluffBall ของคุณและขายในราคา $ 2k ต่อที่นั่งในฐานะ WindowsSpongeCake พวกเขาสามารถทำได้ ไม่ปล่อยให้คนทำในสิ่งที่พวกเขาต้องการตั้งแต่จุดแรกของโครงการ

เป็นไปได้หรือไม่ที่จะหลีกเลี่ยงสถานการณ์เช่นนี้หากคุณเป็นผู้พัฒนาเดี่ยวหรือกลุ่มนักพัฒนาขนาดเล็กที่ไม่มีเงินทุน?

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

ปัญหาของ Xamarin และ Coco kerfuffle ไม่ได้เป็นเรื่องของจริยธรรมหรือความถูกต้องตามกฎหมาย - มันเป็นเรื่องของการต่อสู้ทางอินเทอร์เน็ตระหว่างคนไม่กี่คนที่มีเนื้ออยู่ด้วยกัน พวกเราทุกคนมันเกิดขึ้น ดูเหมือนว่าเป็นผลมาจากการไม่สามารถทำงานร่วมกัน / ร่วมมือเนื่องจากความขัดแย้งทางบุคลิกภาพหรือวิสัยทัศน์ที่เข้ากันไม่ได้สำหรับวิธีการจัดการโครงการ

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

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

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

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

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

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

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

ใบอนุญาตอื่น ๆ เช่น LGPL ยังอนุญาตให้ส้อม แต่เปิดรหัสไว้ ด้วยวิธีนี้อย่างน้อยที่สุดคุณสามารถรวมการเปลี่ยนแปลงใด ๆ จาก fork ลงในโครงการดั้งเดิมของคุณและได้รับประโยชน์จากการพัฒนาบน fork รหัส LGPL สามารถใช้รหัสลิขสิทธิ์ MIT ใดก็ได้ดังนั้นหากคุณต้องการควบคุมโครงการมากกว่านี้คุณสามารถใช้ LGPL แทน

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

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

• การกระทำของ Xamarin และวิธีการกระทำนั้นถูกต้องตามหลักจริยธรรมหรือไม่?

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

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

อย่างที่คุณทราบเรามีส่วนร่วมอย่างกว้างขวางใน Cocos2D-XNA และเราก็ไม่สามารถทำงานร่วมกันได้ต่อไป

เมื่อเรามาถึงจุดที่เราไม่สามารถทำงานร่วมกันได้ฉันตัดสินใจที่จะทำโครงการในทิศทางที่ฉันต้องการด้วยค่าใช้จ่ายในการใช้งานร่วมกันได้

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

• เป็นไปได้หรือไม่ที่จะหลีกเลี่ยงสถานการณ์เช่นนี้หากคุณเป็นผู้พัฒนาเดี่ยวหรือกลุ่มนักพัฒนาขนาดเล็กที่ไม่มีเงินทุน?

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

ในสังคมคุณสามารถป้องกันการหลอกลวงโดย:

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

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

นอกจากนี้การใช้สิทธิ์ใช้งานที่เข้มงวดยิ่งขึ้นจะทำให้บางคนมีโอกาสน้อยที่จะมีส่วนร่วม Xamarin เห็นได้ชัดว่า "สนับสนุน Cocos2D-XNA" อย่างกว้างขวางและฉันสงสัยว่าพวกเขาจะทำเช่นนั้นหากใบอนุญาตไม่อนุญาตให้แจกจ่ายซ้ำ

สิ่งที่ซามารินทำคือถูกกฎหมายและมีจริยธรรม ... เกือบ

ลองมาดูการคอมมิทการแก้ไขของไลเซนส์และการแก้ไขตัวพิมพ์ผิดใน readme :

LicenseAndCredit.txt (ต่าง)

-Copyright (c) 2010-2012 cocos2d-x.org
-
-Copyright (c) 2008-2010 Ricardo Quesada
-Copyright (c) 2011      Zynga Inc.
-Copyright (c) 2011-2012 openxlive.com
-Copyright (c) 2012      Totally Evil Entertainment, LLC
-Copyright (c) 2012      Gena Minchuk
-Copyright 2012 Xamarin Inc
+Copyright (c) The Cocos2D-XNA Team

มีข้อกำหนดเพียงข้อเดียวในใบอนุญาต MIT ทั้งหมด:

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

และซามารินทำสิ่งต้องห้ามอย่างแน่นอน Xamarin อาจคิดว่ามันทำให้ใบอนุญาต "สวยกว่า" มีประกาศด้านลิขสิทธิ์น้อยลงที่ด้านบน แต่พวกเขาไม่ได้รับอนุญาต (ตามกฎหมายหรือจริยธรรม) เพื่อลบ "ความซ้ำซ้อน"

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

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

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

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

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

การขยายหัวข้อเครื่องหมายการค้า:

ที่ Apache Software Foundation รหัสทั้งหมดคือ AL และเช่นเดียวกับใบอนุญาต BSD ภายใต้การสนทนาที่นี่เป็นที่ชัดเจนอย่างสมบูรณ์ว่าอัลอนุญาตให้ส้อม ระยะเวลา จบการสนทนา ในความเป็นจริงตามที่กล่าวไว้ในคำตอบอื่น ๆ ใบอนุญาตโอเพนซอร์สจริงทั้งหมดอนุญาตให้ส้อม สิ่งที่พวกเขาควบคุมคือใบอนุญาต / การใช้งานของรหัสแยก

มูลนิธิ Apache ได้เลือกที่จะลงทะเบียนและปกป้องเครื่องหมายการค้า หากเอนทิตีอื่นที่ไม่ใช่โครงการรากฐานใช้งานได้โอ้ 'Apache Tomcat' ก็ดี ... แต่พวกเขาไม่สามารถเรียกมันว่า Apache Tomcatและเมื่อเราสามารถปกป้องเครื่องหมายพวกเขาไม่สามารถเรียกมันว่าTomcatได้

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

ในท้ายที่สุดสิ่งแบบนี้เป็นหนึ่งในเหตุผลที่รากฐานต่างๆ

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

Github เป็นเต็มรูปแบบของงา บางครั้งผู้คนเปลี่ยนชื่อหรือแพคเกจ Java หรืออะไรก็ตาม - โดยเฉพาะอย่างยิ่งหากพวกเขาต้องการเผยแพร่ไปยังศูนย์กลาง Maven บ่อยครั้งที่พวกเขาทำไม่ได้และผู้ใช้จะออกจากการนำทางเขาวงกตแห่งความสับสน มันไม่เหมาะ แต่นั่นคือการหยุดพักกับอนาธิปไตย