Имеет ли для вас значение, что программное обеспечение является «доступным источником», а не «открытым исходным кодом»

Вам, вероятно, известен список лицензий с открытым исходным кодом, официально утвержденных OSI. В частности, я думаю, что это будет GPL, MIT, [вставьте вашу любимую лицензию здесь].

Недавно я столкнулся с проектом, который, хотя и был открытым исходным кодом (создатель сделал весь исходный код доступным), не был официально открытым исходным кодом под одной из этих официальных лицензий.

• Он выпустил источник, но не обещал выпустить источник в будущем.

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

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

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

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

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

Итак, мы знаем, что компания, которая хочет основать свой бизнес на этом «доступном исходном» программном обеспечении, не может этого сделать, но как кто-то из команды разработчиков программного обеспечения, будут ли эти различия иметь значение для вас или они кажутся менее значимыми?

Любопытно, что другие думают об этом.

Для проектов, которые должны были бы разработать с нуля функциональность, предоставляемую этим программным обеспечением, это определенное удобство - не делать этого.

Но будет ли сопоставимый пакет с открытым исходным кодом лучше, зависит от других факторов:

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

Ответ « нет» на любой из этих факторов указывает на то, что OSS - лучший выбор.

В большинстве случаев сам код не является определяющим фактором. Нужно изучить большую картину.

Проекты SIDEBAR OSS не могут по закону обещать, что они сохранят будущие версии открытыми или что будущие версии будут. Это одна из причин, почему наличие открытой лицензии так выгодно. Кроме того, проекты OSS не обязаны принимать исправления от участников (особенно без передачи прав собственности или прав).

Вопрос для этой и любой другой внешней библиотеки - обслуживание .

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

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

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

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

Лично я подумал бы очень осторожно, приму ли я этот или любой другой внешний код, поскольку вся причина использования кода других людей заключается в том, что вам не нужно иметь дело с ним самостоятельно . Также подумайте о будущих сопровождающих - вы должны выполнить пожарные учения, изменяя код в библиотеке, чтобы посмотреть, можно ли это сделать вообще. Здесь могут быть ОЧЕНЬ неприятные сюрпризы.

Вы можете обсуждать эту библиотеку?

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

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

Единственные ситуации, когда, IMHO, «открытый исходный код» превосходит лицензию «доступный исходный», изложенную в вопросе, это когда

• лицензия нашего продукта также требует раскрытия источников содержащихся в них библиотек
• мы находимся в производстве расширенной / расширенной версии библиотеки

Вот почему Free Software Foundation использует термины «бесплатный» или «несвободный» для описания программного обеспечения. Они не относятся к цене, но ограничивают использование или распространение программного обеспечения.

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

Любой термин может стать неправильным. Я заплатил 50 долларов за свою первую копию emacs (на ленте QIC), но emacs - свободное программное обеспечение . У меня есть исходный код для некоторых проприетарных приложений, которые моя компания использует внутри компании, но они не являются открытыми.

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

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

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

Это имеет значение совсем немного. Основные проблемы с подходом «доступный источник», который вы описали:

• Вы не контролируете свою технологическую судьбу, если у вас нет свободы изменять источник. Часто взлом источника может быть предпочтительнее грязного обходного пути.
• У вас нет гарантии, что программное обеспечение будет продолжать поддерживаться, и у вас нет альтернативной возможности сделать это самостоятельно, которую вы получаете с настоящим открытым исходным кодом.
• Поскольку это похоже на пользовательскую лицензию, вы, вероятно, имеете больший юридический риск по сравнению с использованием чего-то известного и проверенного, например, лицензий GPL или BSD.
• Если это не настоящий открытый исходный код, вы не получите такого же уровня полезного сообщества вокруг него, что является основным преимуществом для многих проектов с открытым исходным кодом.

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