Я большой поклонник открытого исходного кода. Я думаю, что понимаю большинство преимуществ открытого исходного кода. Я научный сотрудник, и мне приходится работать с удивительным количеством программного обеспечения и кода, которые не являются открытым исходным кодом (либо проприетарными, либо непубличными). На самом деле я не вижу веской причины для этого, и я вижу, что код и люди, его использующие, определенно выиграют от того, что станут более публичными (если не более того, в науке жизненно важно, чтобы ваши результаты могли быть воспроизведены при необходимости, и это намного сложнее, если другие не имеют доступа к вашему коду).
Прежде чем я выйду и начну прозелитизм, я хочу знать: есть ли веские аргументы для того, чтобы не публиковать некоммерческий код публично и с OSI-совместимой лицензией?
(Я понимаю, что есть несколько похожих вопросов , но большинство сосредоточено на ситуациях, когда код в первую очередь используется для зарабатывания денег, и я не мог иметь большого значения в ответах.)
Пояснение: под «некоммерческой» я подразумеваю побочные мотивы прибыли, такие как узнаваемость бренда материнской компании и ожидания прибыли инвестора. Другими словами, вопрос касается только программного обеспечения, для которого НИКАКОЙ мотив прибыли не связан с программным обеспечением.
источник
Ответы:
Вы должны принять во внимание, что открытый код вашего кода может потребовать дополнительных усилий.
В качестве примера, в этой записи блога инженер Sun / Oracle описывает усилия, которые они должны были предпринять, когда открыли исходный код своего кода: Open Source или Dirty Laundry?
Обратите внимание, что все вышеперечисленные изменения должны были быть внесены в код, который считался совершенно нормальным как закрытый исходный код, что делает его, так сказать, просто дополнительным усилием .
источник
Безопасность.
Например, скажем, вы строите веб-фреймворк и сами его используете.
Как некоммерческий проект, у вас не было времени посвятить проверке каждого фрагмента кода на предмет уязвимости к той или иной атаке:
Теперь, имея проект с открытым исходным кодом, вы позволяете дружественным глазам вносить свой вклад, но вы также позволяете злонамеренным глазам получить полное представление о вашей работе, и, если они обнаружат сервер, на котором выполняется ваш код, вы лишите себя возможности скрывать свои недостатки в безвестности.
Конечно, это может не относиться к типу программного обеспечения, над которым вы работаете; и как всегда безвестность не оправдывает лени в безопасности.
Однако, как я обнаружил в паре уровней, которые я прошел в игре Stripe the flag , зная, что код - это один из самых простых способов найти уязвимости (и иногда это может быть единственным способом).
источник
Хорошей причиной не открывать исходный код является то, что часть вашего источника может быть защищена авторским правом. Как часто вы не ищете в Интернете быстрое решение проблемы, а просто берете фрагмент кода, который найдете?
Ну, это может быть защищено авторским правом, и я не знаю, хотел бы автор найти лицензию своего кода под другой лицензией.
источник
Вы должны быть осторожны с тем, как вы выбираете свою лицензию, чтобы избежать потенциальных проблем ответственности.
С юристом лучше поговорить об этом, но общая идея заключается в том, что произойдет, если кто-то использует (или злоупотребляет) приложение, и это причиняет некоторый вред? Вы ответственны? Очевидно, это будет зависеть от того, какой тип программного обеспечения вы пишете, но вы всегда должны быть осторожны с тем, что ваша лицензия говорит о вашей ответственности. Это может быть сложно сделать правильно, так что может быть проще просто не выпускать исходный код.
источник
Предупреждение: я не юрист .
Что ж, если это некоммерческая организация и ее интеллектуальная собственность тесно связана с кодом программного обеспечения, то некоторые могут захотеть защитить его от коммерческого использования или даже от неправомерного использования для создания копий вашего программного обеспечения.
Некоторые другие причины, которые, вероятно, глубоко укоренились в первой, на самом деле, состоят в том, что в вашем случае большая часть исследований высокого уровня происходит с частным финансированием, и обычно инвесторы хотят видеть ROI. И до сих пор не все участники индустрии программного обеспечения (или новички) были полностью убеждены в жизнеспособности модели с открытым исходным кодом (скорее всего, из-за недостатка знаний и понимания лицензирования или из-за простого страха, что лицензирование не предотвратит злонамеренное использование). использует и копирует).
Кроме того, эти компании не хотят получать иск от тех, кто пытался получить прибыль за их спиной, и лицензирование рассматривается как гарантия в этом отношении, по уважительной причине или нет.
Может показаться, что это не так, но, возможно, некоммерческие организации приносят прибыль своим учредителям или инвесторам. Преимущества просто не являются прямыми. Таким образом, они проявляют большой интерес к тому, что NFP станут сильными и не будут побеждены конкурентами (даже если вы не часто будете думать о «конкурентах» на некоммерческом рынке), и они хотят сохранить свои IP, даже если это стоит того, чтобы не получить больше бесплатных глазных яблок, чтобы пересмотреть свой код, чтобы найти проблемы и улучшить его на ранней стадии.
Также обратите внимание, что законы об авторском праве отличаются от страны к стране. Например, многие европейские страны считают законы США об авторском праве и патентную систему США довольно ошеломляющими, поэтому существует культурный фон и вес, с которым трудно избавиться.
Вытолкни мои 2 цента на эту тему.
(Я много работал с университетами, и в последнее время в биоинформатике и здравоохранении ... Это постоянный вопрос для меня и моих коллег :))
источник
Существует как минимум два разных типа открытого кода.
Если ваша позиция такова: «вот что-то полезное, я с этим покончил» (и это оказывается точным), то есть небольшой недостаток.
С другой стороны, если вы настроены так: «Я действительно взволнован и хочу, чтобы некоторые настоящие пользователи помогли вести дальнейшее развитие», подумайте очень внимательно. Вам придется тратить время на поддержку пользователей, многие из которых не имеют понятия. Вам придется учитывать конфликтующие запросы на функции и улучшения. Вам будет все труднее вносить изменения, чтобы сохранить обратную совместимость.
источник