Просмотр исходного текста страницы Лицензионный иммунитет СПО. Освобождение проекта на примере Kallithea (Андрей Шадура, LVEE-2014)

== Аннотация ==
;Докладчик: {{Speaker|Андрей Шадура}}
<blockquote>
Free software business models are difficult to design and not as lucrative as proprietary ones.

Sometimes, companies make a difficult choice to proprietarise the work of a Free Software community in an effort to produce more revenue.

While proprietary models do often produce more revenue, they bear a cost on the community.

Fortunately enough, the very idea behind free software, coupled with specifics of some of the free licenses, makes it possible to liberate the project when it's at danger of becoming non-free.
</blockquote>

== Видео ==

{{vimeoembed|106435828|800|450}}

{{youtubelink|Twl9q5GpP6o}}{{letscomment}}


<!-- pollholder -->

== Слайды ==
[[File:Лицензионный иммунитет СПО. Освобождение проекта на примере Kallithea (Андрей Шадура, LVEE-2014).pdf|left|page=-|256px]]

{{----}}

== Тезисы ==

Зачастую авторы успешных свободных программных проектов задумываются над тем, как превратить хобби в способ зарабатывания денег на жизнь. Самым действенным способом зарабатывания денег на свободном коде, оставляя его свободным, является платная поддержка его или продуктов на его основе, либо продажа сервисов, в которых этот продукт используется. Помимо крупных компаний, таких как RedHat и Ubuntu, подобным образом зарабатывают авторы меньших проектов. Одним из известных примеров таких продуктов является веб-сервер nginx: основанная автором компания осуществляет платную поддержку и обновления безопасности, а также предоставляет услуги по настройке специальных конфигураций и внедрению дополнительных возможностей. Менее известный белорусский проект — Ajenti, инструмент веб-администрирования наподобие Webmin, но основанный на современных технологиях. Проект распространяется под лицензией AGPLv3, но предлагает и схему коммерческого лицензирования для компаний, предоставляющих услуги хостинга, или производителей серверного оборудования.



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



В феврале 2010 года польский программист Марцин Кузьминьски начал проект под названием RhodeCode, цель которого была в создании платформы для совместной работы над кодом с использованием системы контроля версий Mercurial, подобной GitHub. На тот момент для Mercurial не было сравнимой по возможностям системы, кроме «облачного» и закрытого Bitbucket. Код RhodeCode, с другой стороны, распространялся на условиях GPLv3, и его можно было поставить на свой собственный сервер, в отличие от «облачных» решений. Проект начал быстро развиваться, к разработке подключилось много разработчиков, в том числе, например, из Unity Technologies. Появилась поддержка pull requests, комментирования коммитов, поддержка Git, авторизации через LDAP и другие возможности.



В июле 2013 года после продолжительной закрытой разработки компания, которую основал Марцин, RhodeCode GmbH, выпустила новую версию, 2.0, на новых условиях — Business Source License. Первоначально лицензия покрывала весь код, требуя покупки лицензий для коммерческих пользователей, но при этом обещалось, что лицензия автоматически превращается в GPLv3. Помимо того, что такая лицензия делает код несвободным (хоть и доступным), подобная смена лицензии без согласия всех, кто вносил свой вклад в кодовую базу, попросту нелегальна. После существенного недовольства пользователей решение было изменено: отныне код на Python и HTML снова под лицензией GPLv3, а всё остальное — под Business Source License.

=== Что же такое опенсорс? ===

Небольшое отступление насчёт критериев «опенсорсности» лицензий. Первоначально, Ричард Столлман определил свободу ПО как «право пользователя свободно запускать, копировать, распространять, изучать, изменять и улучшать его». В июле 1997 проект Debian опубликовал Debian Free Software Guidelines (DFSG) — набор критериев для определения свободного ПО:
* Свободное распространение: лицензия не ограничивает распространение каким бы то ни было лицам или организациям, не требует денежной компенсации
* Исходные тексты: они должны присутствовать, и лицензия не должна ограничивать их распространение
* Производные работы: лицензия должна разрешать создание и распространение производных работ от данного ПО на тех же условиях, как и оригинал
* Целостность авторских исходных текстов: лицензия может запрещать распространение производных работ от исходных текстов, но в этом случае она должна разрешать свободное распространение патчей для исходного текста
* Запрещается дискриминация людей или групп людей
* Запрещается дискриминации по областям деятельности
* Распространение лицензии: лицензия распространяется на любого, кто получил копию ПО
* Лицензия не должна относиться исключительно к Debian
* Лицензия не должна ограничивать другое ПО
* Примеры лицензий: GNU GPL, BSD, Artistic License — свободные лицензии

Эти самые критерии легли в основу определения open source. Вопреки распространённому мнению, любое программное обеспечение, которое является open source, всегда является и free software. Иначе говоря, разница в определениях free software и open source исключительно идеологическая: FSF и Столлман исходят из этической стороны вопроса, а OSI и Debian — из практической. Кроме того, Столлман не распространяет своё видение этих свобод в полной мере на документацию: лицензия GNU FDL с неизменяемыми секциями признаётся Debian несвободной, а именно под такой лицензией распространяется документация к многим проектам GNU.

=== Проблемы с лицензией RhodeCode ===

Легко видеть, что ограничения на количество пользователей, род деятельности (коммерческий, военный и т.д.) переводят лицензию в род несвободных. Именно такой является новая лицензия Business Source RhodeCode.

Следующая проблема с лицензией RhodeCode — раздельное применение GPLv3 и Business Source к разным частям проекта. Как известно, GPL требует, чтобы производные работы распространялись также под GPL, так что по сути GPLv3 применима ко всему проекту, но на часть файлов накладываются ограничения в соответствии с Business Source. А здесь уже вступает в силу раздел §7 GPLv3, в котором говорится, что дополнительные условия могут только давать права пользователям, но не могут их отбирать. Подобные дополнительные ограничения, утверждает этот пункт, не имеют силы, могут игнорироваться и могут быть вовсе устранены.

По мнению Брэдли Куна, президента фонда Software Freedom Conservancy, подобная схема лицензирования, возможно, представляет собой нарушение GPL, и вносит неясность насчёт того, какими же правами обладает пользователь (leaves the redistributor feeling unclear about their rights).

К сожалению, проблемы с RhodeCode неясностью лицензии не ограничились. Американский разработчик, Тревис Бертрам, опубликовал на GitHub четырёхстрочный патч, устраняющий ограничение по количеству пользователей в RhodeCode… после чего с ним связался CEO упомянутого GmbH с угрозами судебного преследования за нарушение условий использования торговой марки. Подобные угрозы получил Джейсм Родс, который месяцами ранее поднял вопрос о легальности смены лицензии. Несмотря на это, RhodeCode продолжал рекламироваться как opensource-решение, таковым по сути являясь весьма условно.

=== Форк ===

Как легко догадаться, такая ситуация расстроила немалое количество людей, потому в январе 2014 началась работа по подготовке форка RhodeCode. Очевидным и самым простым способом было бы взять за основу код последней полностью свободной версии, 1.7.2. Таким путём удалось бы избежать борьбы с неясностями лицензии, но кодовая база проекта была бы устаревшей как минимум на год, и в ней отсутствовала бы некоторая весьма востребованная функциональность. Кроме того, версия 2.0 состояла из объединённых двух веток: развивавшейся в закрытых условиях ветки с графическим интерфейсом, и открытой до определённого момента ветки с бэкендом, которая не писалась единолично автором. Весь этот код было бы очень неприятно потерять, поэтому было решено рискнуть и взять максимум того, что получится, из самого свежего кода, выпущенного GmbH.

Форк производился под эгидой вышеупомянутой организации Software Freedom Conservancy, что позволило гарантировать дальнейший свободный характер разработки и снять с разработчиков решение юридических и финансовых вопросов. Группа энтузиастов с помощью юридического отдела SFC провела ревизию всех опубликованных изменений в RhodeCode начиная с последней полностью свободной версии и заканчивая наиболее актуальной на данный момент версией 2.2.5. Был тщательно рассмотрен лицензионный статус каждого из них, и те, которые были признаны полностью свободными, были перенесены в новый проект. Кроме того, был наведён порядок с лицензиями на JavaScript-библиотеки, использованные в проекте (jQuery, Bootstrap, YUI и другие).

Таким образом, Kallithea получила большую часть кода RhodeCode на Python, но оказалась лишена нового графического интерфейса, который в версии 2.0 был переписан практически с нуля. Адаптация старого интерфейса на новую кодовую базу, ребрендинг, включение в поставку полных исходных кодов JavaScript-зависимостей — всё это потребовало ещё немало времени, но в конце концов проект был выпущен в свет 4 июля 2014 года, в день независимости США. Код Kallithea гарантированно 100% GPLv3, и таковым и останется: поддержание данного статуса является одной из задач Software Freedom Conservancy. Поддержку проекту выразил и автор и главный разработчик Mercurial — Matt Mackall.

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

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

== Примечания и отзывы ==
<!-- <blockquote>[©]</blockquote> -->
* [http://lvee.org/en/abstracts/145 Страница доклада на сайте конференции]

<references/>

[[Category:LVEE-2014]]
[[Категория:Open-source и законы]]
[[Category:Linux]]
[[Category:Python]]

<!-- topub -->
{{stats|disqus_comments=0|refresh_time=2020-01-28T14:47:45.859074|vimeo_comments=0|vimeo_plays=79|youtube_comments=0|youtube_plays=13}}