Сравнение лицензий с открытым исходным кодом

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

Любое программное обеспечение должно принадлежать к какому-либо типу лицензии. У всех них, за исключением общественного достояния, есть правообладатель. Поэтому, когда вы используете в своей инфраструктуре или коде приложений чужое ПО, вы должны соблюдать условия и ограничения, которые предусмотрены лицензией. Это касается библиотек, фреймворков, готовых модулей и даже кода, скопированного со Stack Overflow.

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

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

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

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

Существует более 80 вариантов опенсорс-лицензий, которые в большинстве своем относятся к одной из двух основных категорий: авторское лево или разрешающие.

Авторское лево (копилефт): форма правил, при котором исходник, полученный от open source, наследует тип лицензии.

Разрешающие правила использования: больше свободы для повторного использования, модификации и распространения.

Наиболее популярными являются AGPL, GPL, LGPL, EPL и Mozilla.

Стандартная общественная лицензия GNU (GPL) имеет простой принцип: если вы использовали бесплатный open source для разработки своего приложения, то и ваш модифицированный код должен быть в открытом доступе под такой же лицензией.

Основателем GPL является Ричард Столлман. В середине 1980-х он хотел внести незначительные улучшения в проприетарную систему Массачусетского технологического института, но не смог этого сделать по закону. В результате разногласий Столлман разработал альтернативу коммерческим правилам и назвал ее GPL, или Стандартная общественная лицензия. Он также основал некоммерческий фонд Free Software Foundation (FSF), который поддерживает свободное распространение программного обеспечения.

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

Примером такой лицензии является Linux. Так как он находится под GPL-правилами, то любой код, статически связанный с ядром Linux, должен распространяться под этой же лицензией.

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

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

Affero GPL (AGPL) —усиленная версия GPL, которая отличается от прародителя только одним пунктом. Поскольку права GPL срабатывает только при распространении ПО, то существует лазейка для программного обеспечения, доступного только по сети, так как фактически оно не является распространяемым. AGPL закрывает эту лазейку, включая в свои условия положение об удаленном сетевом взаимодействии, которое активирует лицензию GPL для любого программного продукта, используемого в сети.

Lesser General Public Licence (LGPL) предоставляет менее строгие условия по сравнению с AGPL или GPL. Основное отличие заключается в том, что LGPL не обязана наследовать лицензию на все приложение, а только на те компоненты, которые были под LGPL.

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

Публичная лицензия Eclipse (EPL) обычно используется для программного обеспечения для бизнеса. С помощью EPL его можно комбинировать и сублицензировать, но при условии, что любые не-EPL-элементы находятся обособленно в виде отдельных модулей или объектов. Модификации могут быть сделаны под правами EPL, но они должны быть выпущены на тех же условиях.

Общественная лицензия Mozilla (MPL) является наименее ограничительной с авторским левом. Код, лицензированный в соответствии с MPL, может быть объединен в одном приложении с проприетарными файлами. При этом достаточно только условия, чтобы MPL-код хранился в отдельных файлах. MPL также включает выдачу патентов и обеспечивает сохранение уведомлений об авторских правах.

Наиболее популярными являются: Apache, MIT, BSD и Unlicense.

Лицензия Apache дает право использовать ПО для любых целей, модифицировать его и распространять. При этом производные работы могут иметь другие условия лицензирования и не обязаны предоставлять исходный код.

Условие, которое накладывает Apache, одно — вы обязаны проинформировать пользователей о факте использования исходного кода. Для этого в корневую папку приложения нужно поместить 2 файла: Licence с копией текста на правообладание и Notice с перечислением всех библиотек, лицензированных под Apache. При внесении изменений в код файлы должны актуализироваться.

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

Berkeley Source Distribution (BSD) — это еще один разрешительный вид с открытым исходным кодом, который сохраняет уведомления о лицензии и авторские права, но также позволяет распространять более крупные работы на других условиях.

Текст лицензии может содержать разное количество пунктов. BSD с 2 пунктами (также известна как FreeBSD) очень похожа на MIT, только отличается текстом уведомления. BSD из 3 и 4 пунктов добавляют дополнительные требования или ограничения, связанные с повторным использованием и другими условиями

BSD изначально предназначалась для модификации и распространения кода Berkeley Unix. Текст лицензии требовал, чтобы в источнике указывали Калифорнийский университет в Беркли как правообладателя, таким образом производные продукты рекламировали учебное заведение.

В 1999 году университет выпустил новую версию с удаленным пунктом о рекламе. С тех пор BSD позволяет пользователю фактически делать что угодно с программой или ее исходником, но без гарантий, то есть правообладатель не несет ответственности за продукты, разработанные с помощью его кода.

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

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

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

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

• Следует соблюдать осторожность при выборе лицензии с авторским левом. Если исходная версия очень либеральна, измененный код также не имеет ограничений, что может быть не в пользу автора.
• Лицензии с авторским левом обычно предусматривают больше ограничений, чем разрешающие.
• Когда цель состоит в том, чтобы сделать код максимально пригодным для повторного и совместного использования, разрешающие будут лучшим выбором.
• AGPL может быть очень выгодным выбором, если вы разрабатываете ПО, распространяемое по сети. Типичным примером этого являются базы данных с открытым исходным кодом: не лицензируя по AGPL, любая компания (например, крупный поставщик облачных услуг) может улучшить ваш продукт и монетизировать его без необходимости распространять свои модификации.
• Существуют две основные версии GPL: GPLv2 и GPLv3. Отличия заключаются в том, что в GPLv3 есть пункты, касающиеся патентов. GPLv3 также улучшает совместимость с другими лицензиями с открытым исходным кодом, такими как Apache. Однако обратите внимание, что две версии GPL несовместимы друг с другом.
• Поскольку лицензии MIT широко используются, их преимущество заключается в том, что они хорошо известны и понятны всем. Когда дело доходит до использования программного обеспечения, лицензированного по MIT, нет никаких ограничений относительно распространения или монетизации, что делает их очень привлекательными для любого вида использования. MIT может также использоваться в проектах с другими лицензиями.

В отличие от GPL, которые предназначены для предотвращения коммерческой коммерциализации кода, разрешающие лицензии, например, MIT или BSD, накладывают минимальные ограничения на поведение в будущем. Это позволяет ему оставаться открытым или интегрироваться в коммерческие решения по мере изменения проекта.

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