Причины НЕ открывать некоммерческий код с открытым исходным кодом? [закрыто]

34

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

Прежде чем я выйду и начну прозелитизм, я хочу знать: есть ли веские аргументы для того, чтобы не публиковать некоммерческий код публично и с OSI-совместимой лицензией?

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

Пояснение: под «некоммерческой» я подразумеваю побочные мотивы прибыли, такие как узнаваемость бренда материнской компании и ожидания прибыли инвестора. Другими словами, вопрос касается только программного обеспечения, для которого НИКАКОЙ мотив прибыли не связан с программным обеспечением.

naught101
источник
+1, как я считаю, что интересный вопрос сам. Но мне интересно, если это правильное место, чтобы спросить это. Может быть, вы получите другие перспективы от других сайтов SE, таких как сайт PM.SE. Просто предложение.
Хайлем
@haylem, я не видел PM.SE, но кажется, что это больше касается технических аспектов управления проектами?
naught101
Будете ли вы впоследствии активно поддерживать проект или это кладбище кода. Другими словами, каково будущее проекта.
@ ThorbjørnRavnAndersen: да, я предполагаю активное сопровождение, разработку и использование кода.
naught101

Ответы:

28

Вы должны принять во внимание, что открытый код вашего кода может потребовать дополнительных усилий.

В качестве примера, в этой записи блога инженер Sun / Oracle описывает усилия, которые они должны были предпринять, когда открыли исходный код своего кода: Open Source или Dirty Laundry?

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

Еще одним подготовительным действием является «очистка» кода служебной информации, упоминание конкретных клиентов, разработчиков, технологий и т. Д. Это немного менее очевидно, но рассмотрим следующий пример:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

Хотя все вышеперечисленное может быть правдой, мы, вероятно, имеем какие-то отношения с Intertrode Tech, и наличие подобных комментариев в коде может как-то навредить нашему бизнесу, и поэтому его следует удалить. Возможно, это не должно было быть там, во-первых, но сейчас самое время его убрать.

Другая часть «чистки» - удаление ненормативной лексики и других «нежелательных» слов ...

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

комар
источник
2
Что ж, это относится к крупным компаниям с существующей кодовой базой, а тем более к коду, который написан с открытым исходным кодом.
Конрад Рудольф
1
@KonradRudolph OP упомянул, что я должен работать с ... кодом, который не является открытым исходным кодом (либо закрытым, либо закрытым ), то есть его не было с нуля
gnat
Разве не случилось то же самое с DOOM 3? Патентный выпуск задерживает выпуск исходного кода Doom 3
user16764
11

Безопасность.

Например, скажем, вы строите веб-фреймворк и сами его используете.

Как некоммерческий проект, у вас не было времени посвятить проверке каждого фрагмента кода на предмет уязвимости к той или иной атаке:

  • CSRF
  • XSS
  • SQL-инъекция
  • Фиксация сессии
  • Использование глючных сторонних библиотек или даже языков

Теперь, имея проект с открытым исходным кодом, вы позволяете дружественным глазам вносить свой вклад, но вы также позволяете злонамеренным глазам получить полное представление о вашей работе, и, если они обнаружат сервер, на котором выполняется ваш код, вы лишите себя возможности скрывать свои недостатки в безвестности.

Конечно, это может не относиться к типу программного обеспечения, над которым вы работаете; и как всегда безвестность не оправдывает лени в безопасности.

Однако, как я обнаружил в паре уровней, которые я прошел в игре Stripe the flag , зная, что код - это один из самых простых способов найти уязвимости (и иногда это может быть единственным способом).

Николь
источник
7
Эта дискуссия продолжается уже целую вечность, и у меня сложилось впечатление, что открытый исходный код лучше для безопасности, но только если проект довольно популярен (по крайней мере, среди разработчиков). Странно, что в сети нет хороших аргументов в любом месте (во всяком случае, я могу найти).
naught101
1
В сочетании с комментариями naught101s это имеет большой смысл. Если меньше людей заботятся о вашем источнике, и вы используете его в производстве, очень
велики
1
Безопасность через неизвестность?
Дунайский моряк
3
@lechlukasz Ты вообще прочитал весь пост?
Николь
1
@Oleksi Спасибо, но я это знаю. Я сказал: «Мрак не оправдывает лени в безопасности». Этот вопрос не об открытых и закрытых, а об открытии ранее закрытой системы. Я полностью согласен с той ссылкой, которую вы опубликовали, но разработчики не совершенны, и когда вы открываете систему, есть шанс, что первые глаза, которые найдут ошибку, воспользуются ею, а не исправят ее для вас.
Николь
10

Хорошей причиной не открывать исходный код является то, что часть вашего источника может быть защищена авторским правом. Как часто вы не ищете в Интернете быстрое решение проблемы, а просто берете фрагмент кода, который найдете?

Ну, это может быть защищено авторским правом, и я не знаю, хотел бы автор найти лицензию своего кода под другой лицензией.

Питер Б
источник
1
+1 за авторские права. Просто хотел добавить патенты. Вы можете просто узнать, что ваш проект с открытым исходным кодом нарушает некоторые из тысяч и тысяч патентов на программное обеспечение, на которых проживает «корпус». Потоковое видео? Запатентованный. Объявления с платой за клик? Запатентованный. Просто несколько примеров. Однако шансы на то, что «корпусу» все равно - если вы не конкурент.
Амадей Хейн
1
Хехе. Это на самом деле не аргумент против открытого источника, но против пиратства. Но вы правы, держу пари, что это проблема во многих больших частных кодах.
naught101
1
@ naught101 Согласен. Открытый источник только разоблачает проблему. Закрытое право собственности в этом случае является вопросом не быть пойманным;)
Андрес Ф.
То есть, вы говорите, что одна из причин, по которой источник остается закрытым, - это возможность скрывать случайные нарушения авторских прав? Не кажется ли вам, что это довольно неэтичная причина для использования?
Марк Бут
1
Неэтично .... может быть, очень и очень веская причина не открывать исходный код, конечно.
Питер Б
6

Вы должны быть осторожны с тем, как вы выбираете свою лицензию, чтобы избежать потенциальных проблем ответственности.

С юристом лучше поговорить об этом, но общая идея заключается в том, что произойдет, если кто-то использует (или злоупотребляет) приложение, и это причиняет некоторый вред? Вы ответственны? Очевидно, это будет зависеть от того, какой тип программного обеспечения вы пишете, но вы всегда должны быть осторожны с тем, что ваша лицензия говорит о вашей ответственности. Это может быть сложно сделать правильно, так что может быть проще просто не выпускать исходный код.

Oleksi
источник
1
Да, это хороший момент, и большинство лицензий на ОС обычно где-то содержат какой-то задорный текст. Я предполагаю, что я принимаю лицензию типа «без обязательств».
naught101
4

Предупреждение: я не юрист .

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

Некоторые другие причины, которые, вероятно, глубоко укоренились в первой, на самом деле, состоят в том, что в вашем случае большая часть исследований высокого уровня происходит с частным финансированием, и обычно инвесторы хотят видеть ROI. И до сих пор не все участники индустрии программного обеспечения (или новички) были полностью убеждены в жизнеспособности модели с открытым исходным кодом (скорее всего, из-за недостатка знаний и понимания лицензирования или из-за простого страха, что лицензирование не предотвратит злонамеренное использование). использует и копирует).

Кроме того, эти компании не хотят получать иск от тех, кто пытался получить прибыль за их спиной, и лицензирование рассматривается как гарантия в этом отношении, по уважительной причине или нет.

Может показаться, что это не так, но, возможно, некоммерческие организации приносят прибыль своим учредителям или инвесторам. Преимущества просто не являются прямыми. Таким образом, они проявляют большой интерес к тому, что NFP станут сильными и не будут побеждены конкурентами (даже если вы не часто будете думать о «конкурентах» на некоммерческом рынке), и они хотят сохранить свои IP, даже если это стоит того, чтобы не получить больше бесплатных глазных яблок, чтобы пересмотреть свой код, чтобы найти проблемы и улучшить его на ранней стадии.

Также обратите внимание, что законы об авторском праве отличаются от страны к стране. Например, многие европейские страны считают законы США об авторском праве и патентную систему США довольно ошеломляющими, поэтому существует культурный фон и вес, с которым трудно избавиться.

Вытолкни мои 2 цента на эту тему.

(Я много работал с университетами, и в последнее время в биоинформатике и здравоохранении ... Это постоянный вопрос для меня и моих коллег :))

haylem
источник
Хм ... Я как бы рассматривал код и IP вместе в своем вопросе. Может быть, я должен был сделать это яснее. Я бы думал о рентабельности инвестиций и брендинге как о мотивах получения прибыли ... (я понимаю, что "наука" была немного расплывчатой, и что многие науки
приносят
Уточнил вопрос. Извините за неприятности.
naught101
Я бы посчитал ваше поле прибыльным. У него может не быть широкого рынка, но это не значит, что это не выгодно. В fqct я считаю, что это связано с довольно большими деньгами. Почему ты чувствуешь иначе?
Хайлем
Я занимаюсь моделированием климата. Никто не платит за модели климата. Никто не платит за использование климатических моделей. Там нет никакой прибыли, которую можно получить от использования программного обеспечения. Людям платят за проведение исследований с использованием этих моделей (и это часто включает в себя написание моделей), и иногда приходится платить за вычислительное время, но оба эти значения означают, что совместное использование кода сделает вещи более дешевыми (больше времени тратится на исследования вместо написания кода на оборудование HPC тратится меньше времени). Я действительно не понимаю, как программное обеспечение связано с прибыльностью.
naught101
1
@psr: Я думаю, в этом суть naught101: результаты использования модели приносят выгодные результаты, но не обязательно много денег делается на продаже программного обеспечения, реализующего модель. Меня тоже удивляет, но вполне может быть.
Хайлем
1

Существует как минимум два разных типа открытого кода.

Если ваша позиция такова: «вот что-то полезное, я с этим покончил» (и это оказывается точным), то есть небольшой недостаток.

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

ddyer
источник
3
Я действительно не понимаю, как выпуск кода обязывает кого-либо оказывать поддержку? И в науке, по крайней мере, большинство пользователей довольно хорошо осведомлены, по крайней мере, о процессе, если не о самом коде.
naught101
1
@ naught101: Обязательства нет, но если кто-то использует ваш код, вы будете получать электронные письма, вопросы, предложения ... с которыми вам придется потрудиться, если вы просто не захотите их игнорировать. Вне науки многие пользователи не слишком осведомлены, так что вы можете помочь людям с элементарными проблемами настройки и т. Д. Просто потому, что вы случайно выпустили некоторый код. Я испытал это, по крайней мере. Даже отказ от ответственности в стиле BSD «предоставляется как есть» и т. Д. Не мешает и не должен мешать людям обращаться за помощью.
Joonas Pulakka
1
Проголосовал, потому что этот ответ на самом деле не менее применим, чем многие другие. @JoonasPulakka: конечно, это не должно мешать людям обращаться за помощью. Но это должно остановить их в ожидании ответа. Кроме того, если у вас есть настоящее программное обеспечение в открытом доступе, то, вероятно, вы несете одинаковую ответственность перед пользователями независимо от того, является ли ваш код общедоступным (возможно, в зависимости от лицензионного соглашения). Возможно, вам придется ожидать большего количества запросов от разработчиков, если вы выпустите код, но было бы неплохо подумать, что большинство из них будут иметь некоторую подсказку и могут погасить некоторые советы патчем или двумя ..
naught101