Як уникнути того, щоб сильніший дописувач не був відкинутий у небуття?

Як нещодавно тут повідомлялося :

Xamarin розробив Cocos2D-XNA, 2D / 3D рамку розвитку ігор, створивши міжплатформенну бібліотеку, яку можна включити до PCL-проектів.

Однак засновник проекту, який був роздвоєний, говорить :

Мета ліцензії MIT - обмежити ваше добросовісне використання. Щоб не заохочувати вас брати програмне забезпечення, ребрендіруйте його як власне, а потім "приймайте його в новому напрямку", як ви говорите.

Хоча це не незаконно, але це неетично.

Схоже, що сторінка нового проекту GitHub навіть не вказує на те, що це роздріб типовим чином GitHub, замість цього вибираючи розділ Історія, який легко знімається (див. Низ).

Отже, мої запитання:

1. Чи діяла Xamarin і спосіб дії був етичним чи ні?
2. Чи можна уникнути такої ситуації, якщо ви є одним розробником або невеликою групою, що не фінансується?

Я сподіваюсь, що це може бути або питанням вікі, або знайдуться об'єктивні відповіді, засновані на сучасній етиці / філософії ОСЗ.

Чи діяла Xamarin і спосіб дії був етичним чи ні?

Що ж, давайте запитаємо експерта - перелік Ініціативи з відкритим кодом з переліком самої Ліцензії MIT , з цією ліцензією, що цитується повністю:

Ліцензія MIT (MIT)

Авторські права (c)

Дозвіл надається безкоштовно будь-якій особі, яка отримує копію цього програмного забезпечення та пов'язаних з ним файлів документації ("Програмне забезпечення"), здійснювати обробку в Програмному забезпеченні без обмежень, включаючи без обмеження права на використання, копіювання, модифікацію, об'єднання , публікувати, поширювати, надавати субліцензію та / або продавати копії Програмного забезпечення та дозволяти особам, яким надається Програмне забезпечення, робити це за умови дотримання наступних умов:

Вищезазначене повідомлення про авторські права та це повідомлення про дозвіл повинні міститись у всіх копіях або значній частині Програмного забезпечення.

ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ надається "ЯК Є Є", БЕЗ ГАРАНТІЇ БУДЬ-ЯКОГО РОЗУМУ, ЕКСПРЕССУ АБО НЕ ВПРАВЛЕНО, Включаючи НЕ ОБМЕЖЕНІ ГАРАНТІЯМИ ПРОДАЖНОСТІ, ФІТНІСНОСТІ ДЛЯ ЧАСНОГО МЕТА І НЕФІНФОРМУВАННЯ. НІ В ЯКІ НЕ БУДУТЬСЯ АВТОРИ АБО ВЛАСНИКИ ПРАВИЛЬНОГО ПРАВА НЕ БУТЬ ВІДПОВІДАЛЬНІ за будь-яку претензію, збитки чи іншу відповідальність, навіть якщо це відбувається в договорі, ТОРТІ АБО ІНШИМ, НЕ ВІДПОВІДАЮТЬСЯ, АБО ІЗ ЗВ'ЯЗКУ ПРО ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ІЛИ ВИКОРИСТОВУВАННЯ ТА ІНШИМ УПРАВЛІННЯМИ ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ.

Якщо хтось - фізична особа чи компанія - випускає програмне забезпечення / вихідний код з ліцензією MIT, це означає, що будь-хто інший - фізична особа чи компанія можуть "працювати з Програмним забезпеченням без обмежень". Поки повідомлення про авторські права залишається недоторканим, вони в значній мірі можуть робити як завгодно.

Це один із тих випадків, коли етика та законність майже однакові. Якщо людина чи група не розуміли ліцензію або це має наслідки, вони не виконали належну ретельність. Ініціатива з відкритим кодом надає безліч інших приємних ресурсів, які допоможуть нам зрозуміти ліцензії, такі як варіант MIT. Давайте розглянемо кілька положень їх визначення з відкритим кодом:

1) Безкоштовний перерозподіл - Ліцензія не повинна обмежувати будь-яку сторону від продажу або передачі програмного забезпечення як складової сукупного розповсюдження програмного забезпечення, що містить програми з кількох різних джерел. Ліцензія не вимагає роялті чи іншої плати за такий продаж.

3) Отримані твори - Ліцензія повинна допускати модифікації та похідні твори, і повинна дозволяти поширювати їх за тими ж умовами, що і ліцензія оригінального програмного забезпечення.

5) Заборона дискримінації щодо осіб або груп - Ліцензія не повинна дискримінувати будь-яку особу чи групу осіб.

6) Заборона дискримінації щодо польових зусиль - Ліцензія не повинна обмежувати будь-кого у використанні програми у певній галузі. Наприклад, це може не обмежувати використання програми в бізнесі або використання генетичних досліджень.

На мій прочитання це здається абсолютно зрозумілим: випуск чогось як відкритого коду, особливо з ліцензією MIT, дозволяє комусь вільно взяти програмне забезпечення, змінити його, упакувати його та продати його майже всім, хто їм подобається, доки вони не хочуть ' т видалити повідомлення про авторські права і стверджують , що це їх власна єдина робота.

Як автор, ви явно відмовляєтесь від права бути прискіпливими та вибагливими. Ви не можете вирішити, хто чи що може отримати вигоду від вашого програмного забезпечення або використовувати його, і ви не можете вирішити, чому вони використовують його. Ви прямо відмовляєтесь від цього права.

Ідея полягає в тому, що ви сприяєте досягненню більшого блага, явно відмовляючись від будь-яких законних прав, які ви маєте контролювати та обмежувати використання та зміну того, що ви зробили. Якщо Microsoft хоче роздрібнити ваш проект FluffBall і продати його за 2 тис. Доларів за місце як WindowsSpongeCake, вони можуть. Хіба ви не дозволяли людям робити все, що вони хочуть, в першу чергу всю точку вашого проекту?

Чи можна уникнути такої ситуації, якщо ви є одним розробником або невеликою групою, що не фінансується?

Типу! По-перше, використовуйте ліцензію, відповідну вам та вашим цілям та бажанням організації. Якщо ви не хочете, щоб хтось використовував його у спосіб, який ви не схвалюєте, ви, ймовірно, не повинні випускати його як Open Source - і, чесно кажучи, ви, можливо, не повинні його випускати зовсім! Якщо ви не хочете, щоб хтось використовував похідні роботи (наприклад, виделка) для комерційного проекту, вам, ймовірно, слід скористатися версією GPL для copyleft . Якщо ви хочете отримати некомерційну ліцензію, вам, мабуть, слід порадити юриста щодо авторських прав / ліцензій, оскільки це часто взагалі не вважається програмним забезпеченням з відкритим кодом, і немає жодної великої попередньої письмової ліцензії для підтримки цієї справи.

Проблема з коріфуфлею Xamarin та Coco - не питання етики чи законності - це боротьба в Інтернеті між кількома людьми, які мають яловичину між собою. Ми всі люди, буває. Схоже, це результат неможливості співпрацювати / співпрацювати, ймовірно, через конфлікт особистості або несумісні бачення того, як проект повинен працювати.

Отже, інший спосіб захисту - це відкриття для співпраці та змін, але розумійте, що якщо це не виходить, а бачення розходяться ... ну, це причина для варіанту розкрутити і мати свій окремий проект.

Дуже власною і зрозумілою для почуття власності та популярності робити програмні проекти дуже і дуже складно. Але мета відкритого коду полягає в тому, щоб спробувати переступити це і дозволити найкращому програмному забезпеченню бути доступним для всіх вільно.

Підсумок, будьте зрозумілі щодо своїх цілей, коли ви приймаєте рішення про ліцензію, і розумійте, що це має наслідки для вашого майбутнього контролю та спрямування проекту. Якщо ви просто хочете пожертвувати на краще благо, відкритим кодом є шлях. Якщо ви хочете більш жорстко контролювати свій проект та мати право власності та хоча б юридичний випадок, якщо хтось намагається продати ваш проект або поглинути його власним (частково або повністю), вам знадобиться інша ліцензія, і, ймовірно, потрібно буде розібратися з юристом.

Випуск проекту за ліцензією MIT дає людям дозвіл на розкручування проекту. Частина філософії вільного програмного забезпечення полягає у наданні користувачам та розробникам права використовувати, змінювати та випускати програмне забезпечення способами, які зазвичай не дозволяють. Якщо ви не хочете, щоб люди це робили, тоді не використовуйте ліцензію MIT. Ви не можете поскаржитися, коли люди використовують код згідно з умовами ліцензії, яку ви їм дали.

Вилки - це досить нормальна річ, що трапляється у спільноті вільного програмного забезпечення. Схоже, розробники fork намагалися внести свій внесок у оригінальний проект, але не погодились, тому вони зробили внесок у власний проект. Вільне програмне забезпечення заохочує це, щоб розробникам не заважати змінювати програмне забезпечення, оскільки власникам не подобаються їх зміни.

Крім того, випускаючи щось під ліцензією безкоштовного програмного забезпечення, ви отримуєте вигоду від внеску інших людей, внесок, який ви, можливо, не отримали, якби це було за іншою ліцензією. Якщо ви приймаєте внески за ліцензією, ви самі повинні дотримуватися умов ліцензії.

Один із способів зберегти контроль над офіційною версією - покладатися на такі речі, як торгові марки. Наприклад, корпорація Mozilla має торгову марку на Firefox, яка дозволяє їм диктувати, що люди можуть робити з Firefox, навіть якщо це відкритий код (див. Iceweasel для виду цього).

Інші ліцензії, такі як LGPL, все ще дозволяють вилки, але код залишається відкритим. Таким чином, ви можете принаймні включити будь-які зміни від вилки до свого оригінального проекту та отримати вигоду від розробки на вилці. Код LGPL може використовувати будь-який ліцензований код MIT, тому, якщо ви хочете більше контролювати проект, ви можете використовувати LGPL замість цього.

Я б не назвав це неетичним. Я б назвав це неспортивним. Існує неписане сподівання, що ви докладете зусиль, щоб покращити оригінальну версію, перш ніж зважитися на вилку, і, здається, оригінальний автор відчуває, що добросовісні зусилля не були зроблені.

Незважаючи на це, найкращий спосіб уникнути розгортання програмного забезпечення - реагувати на запити клієнтів таким чином, щоб ваше програмне забезпечення було якомога ширшим. Ніхто не збирається надавати підтримку вилці, якщо вони знають, що оригінал вищий. Крім цього, ваш єдиний захист - це зміна умов ліцензування.

• Чи діяла Xamarin і спосіб дії був етичним чи ні?

Дуже багато людей плутають правову та етичну ситуацію. Ліцензія X11 дозволяє будь-якому «використовувати, копіювати, змінювати, об'єднувати, публікувати, поширювати, субліцензувати і / або продавати копії програмного забезпечення, а також дозволяти особам, яким Програмне Забезпечення , щоб зробити це», так що це, безумовно , правова .

Етично, проте, це складніше. У спільнотах з відкритим кодом вважається переважно вдосконалювати оригінальне програмне забезпечення, а не створювати вилку. У посиланні, яке ви надали , Мігель де Іказа говорить:

Як відомо, ми зробили великий внесок у Cocos2D-XNA, і ми просто не могли продовжувати працювати разом.

Як тільки ми дійшли до того, що ми не змогли співпрацювати разом, я вирішив взяти проект у тому напрямку, який я хотів, за рахунок зворотної сумісності.

Незрозуміло, чому вони "не могли співпрацювати разом", але, здається, Xamarin доклала розумних зусиль для роботи над оригінальним проектом, перш ніж вирішити роздрібнити його.

• Чи можна уникнути такої ситуації, якщо ви є одним розробником або невеликою групою, що не фінансується?

Юридично ви можете скористатися ліцензією, яка не дозволяє розблокувати, заборонивши перерозподіл вихідного коду (на даний момент це не було б "вільним програмним забезпеченням"). Інший варіант - залишити код без прокрутки, але не допускати перерозподілу статичних активів, таких як зображення або текст без коду (деякі ігри мають такі ліцензії).

Соціально ви можете запобігти розвантажуванню:

• Полегшення для людей внесення змін до вашого проекту.
• Швидкий огляд патчів.
• Дозволення змін, які безпосередньо вам не приносять користі.
• Бути чемним. Дивовижна кількість вилок пояснюється тим, що вкладники більше не бажають працювати один з одним.

Розігрування програмного забезпечення - це велика робота, і більшість розумних людей цього не робитимуть, якщо у них є простіший варіант. Якщо у них немає іншого вибору, то запобігання розгортанню вашого коду просто змусить їх розщедрити чужий код або переписати програмне забезпечення з нуля. Це може сповільнити їх, але це не дуже допоможе вам.

Крім того, використання більш обмеженої ліцензії змусить деяких людей зробити менший внесок. 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 немає наміру запобігати вил, тому це не є неетично саме по собі. Якщо "ребрендинг як власний" є кодом для "оприлюднення публічних кредитних вимог, яких ви не заслуговуєте", то впевнені, що це було б неетично, якщо це правда.

Щодо того, щоб не допустити того, щоб це сталося з вами: якщо ви хочете уникнути того, щоб хтось інший накинув на те, що ваш код є їхнім, то вам потрібно голосно голосувати, коли вимагаєте кредиту. Якщо ви хочете уникнути ситуації, коли хтось створить вилку вашого коду, яка в кінцевому підсумку може виявитись більш популярною, ніж ваш оригінал (або завдяки більшим ресурсам, або просто зосередженості на "правильних" потреби користувача), тоді я думаю, що ви не в змозі удачі в ОСС. Ви не можете просто вирішити, що маєте рацію, якщо інша група хоче відрізнятись від функцій програмного забезпечення від того, що ви хочете, і якщо (на думку користувачів) ви помиляєтесь, ви повинні втратити, незважаючи на те, що ви там спочатку. Це наслідок первинного принципу відкритого коду (або належним чином, принципу вільного програмного забезпечення), що автор не контролює програмне забезпечення, так це роблять люди, які ним керують.

Розширення теми торговельної марки:

У програмному фонді Apache увесь код - AL. І, як і з ліцензією BSD, про яку йдеться тут, абсолютно зрозуміло, що AL дозволяє вилки. Період. Кінець дискусії. Насправді, як обговорюється в інших відповідях, усі справжні ліцензії з відкритим кодом дозволяють отримати вилки. Все, що вони контролюють, - це ліцензія / використання роздвоєного коду.

Фонд Apache вирішив зареєструвати та захистити торгові марки. Якщо якась організація, окрім фундаментального проекту, роздвоєна, о, "Apache Tomcat", вони добре ... але вони не можуть назвати це Apache Tomcat , і, коли ми можемо захистити марку, вони не можуть назвати це Tomcat .

Проблема тут полягає в тому, що торговельні марки не для слабкого серця. Якщо ви невелика група людей, яка не має юридичної структури і не має фінансування, ви практично не можете використовувати закон про торговельну марку для захисту свого імені.

Зрештою, така річ є однією з причин різних фондів там.

З етичної точки зору, ну якщо є внутрішній поділ між учасниками, хто повинен сказати, хто «заслуговує», щоб зберегти ім’я? Якщо, з іншого боку, сторонні вилки, це, мабуть, не найетичніше у світі, щоб залишити ім’я без змін. Це теж не грізний вчинок.

Github повна виделок . Іноді люди змінюють ім’я, або пакет Java, або що завгодно - особливо якщо вони хочуть опублікувати в Maven central. Часто вони цього не роблять, і користувачі відвідують лабіринт плутанини. Це не ідеально, але це розриви з анархією.