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

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

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

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

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

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

В качестве примера, в этой записи блога инженер 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, и наличие подобных комментариев в коде может как-то навредить нашему бизнесу, и поэтому его следует удалить. Возможно, это не должно было быть там, во-первых, но сейчас самое время его убрать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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