Насколько открыт Open Source

Очень часто мы слышим вокруг, что использование Open Source кода — это хорошо и правильно, это развивает ИТ-индустрию, это позволяет накапливать знания, а не тратить время разработчиков, создавая очередной «велосипед». Но давайте разбираться, так ли дело обстоит на самом деле, какие трудности будут нас преследовать на пути распространения Open Source продуктов, и как их преодолеть.

Задачи лицензирования

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

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

Типы лицензий

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

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

Более свободным вариантом (также с необходимостью поставлять продукт вместе с исходными кодами) является семейство GPL-совместимых лицензий. Здесь авторы могут изменить лицензию исходного кода внутри группы без каких-либо нарушений.

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

Наиболее свободным является открытый код (размещенный в так называемом «публичном доступе», public domain). Но в этом случае код теряет авторское право (это противоречит российскому законодательству, поэтому в нашей стране такая практика не применима).

Случаи использования

Давайте рассмотрим несколько характерных случаев поведения при работы с Open Source лицензиями.

Выбор лицензии

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

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

Если мы хотим сделать наш код максимально доступным для использования (в том числе, в коммерческих продуктах), то лучше всего выбрать GPL- или даже OSI-совместимую лицензию. При этом можно выбрать и двойное лицензирование (например, BSD + Apache лицензии).

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

Множественное лицензирование

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

@licensed LGPL (LICENSE-LGPL.txt)
@licensed MIT license (LICENSE-MIT.txt)
@licensed YOUR license (LICENSE-YOURS.txt)

Желательно также приложить все тексты лицензий в сам продукт и дополнительно в readme-файле написать, какие модули под какой лицензией опубликованы.

Использование стороннего кода

Существенным при использовании какого-либо Open Source кода является понятие «производного произведения» (derivative work). Если ваш продукт не может работать без заимствованной части, например, заимствованная часть составляет основу (ядро) продукта, то в таком случае необходимо сохранить правила лицензирования первоначального кода.

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

Обход лицензии

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

• Можно переписать код заново, используя те же концепции или (что лучше) идеи, которые в него заложены. Чем больший уровень абстракции от первоначального кода будет взят, тем менее вероятны судебные пути развития. Особым шиком здесь является не только переписать исходный код заново, но и самостоятельно запатентовать его (или его идеи), поскольку то, что уже находится в Open Source, запатентовано быть не может. В этом случае можно почти со 100% уверенностью гарантировать, что никто не возьмется повторить ваш трюк. По-видимому, подобная ситуация и произошла в споре между Google и Oracle по поводу Java ME.
• Если лицензия исходного предполагает какие-либо вариации, то ее можно изменить под требуемую (в рамках текущей группы, OSI- / GPL-совместимых лицензий).
• Как было указано ранее, можно включить сторонний код как дополнительный модуль вашего продукта. Самое главное здесь — максимально абстрагировать использование стороннего функционала, свести его только к вызовам API. По этому пути пошли все Open Source системы управления сайтами: расширения могут иметь свою собственную лицензию, при этом сама система использует функционал расширений через заранее известное API.
• Вы также можете договориться с авторами кода, чтобы они выпустили его под необходимой вам лицензией. Например, лицензия на ExtJS является коммерческой, но подразумевает возможность лицензирования производных продуктов на некоммерческой основе. А Qt лицензирует весь код под тремя лицензиями, поэтому вы вольны выбирать ту, которая походит лучше всего.

Закрытие кода

Как быть в том случае, если вы хотите соблюсти исходную лицензию, но при этом совсем не хотите, чтобы ваши работы стали публичным достоянием?

Во-первых, можно использовать минимизацию и обфускацию кода. Грамотная обфускация почти на 100% гарантирует, что прочесть ваши исходники смогут только в самом крайней случае (а в нем исходники все равно смогут тем или иным образом достать). При этом стоит учесть ограничение текущей лицензии, и не выпускать скомпилированный код без исходных текстов (т.е., например, Zend тут не поможет).

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

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

Спасибо за внимание. Вопросы?

Все комментарии (habrahabr.ru)