[Перевод] Как захватить/защитить open-source проект28.12.2017 18:33

На «Ars Technica» есть интересная статья о том, как Google понемногу закрывает Android. Это классическая игра Capture the Flag, которая ведется против open-source сообщества. Я собираюсь объяснить, как этот захват работает, и как его предотвратить.

Почему Capture the Flag?

Как говорит «Ars Technica»: «Легко отдать что-нибудь, когда ты на последнем месте с нулевой долей рынка, как это было с Android в начале. Когда же ты на первом месте, немного сложнее быть таким открытым и доброжелательным».

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

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

Вопрос о захвате, о том, как это происходит и как это предотвратить, особенно важен, если вы не Google, т.е. если вы пользователь или участник open-source-проекта. В Android много патчей других фирм, таких как LG, Samsung и прочие. По мере того как Google превращает операционную систему в свой личный огород, эти патчи начинают использоваться против тех самых людей, которые их сделали.

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

Отмечу две вещи:

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

Сценарий использования

Я постараюсь выразиться недвусмысленно о сценарии использования. Речь идет об Android: одна компания начинает open-source-проект, используя его как «товар-приманку», намереваясь проникнуть на рынок, и просит поддержки у других. Это классическая стратегия, которая может быть очень успешной. Однако это точно не то же, что студенческий проект-исследование или мусор вроде «давайте сделаем систему расчетов по заработной плате open-source» или «пятеро из нас собрались в гараже и решили сделать новый фреймворк».

Здесь есть частичное совпадение, и я думаю, полученные выводы можно применять более широко (и я точно применяю их систематически), опять же, мой сценарий использования — «open-source для прорыва на рынок».

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

Большинство open-source проектов провальные (серьезно, идите, почитайте о каком-нибудь случайном проекте на GitHub и увидите, сколько из них адекватных), и даже успешные в очень скромном значении этого слова, незначительны сами по себе. Пока нет серьезного изменения власти, проект может оставаться потенциальным прорывом на рынке очень долгое время. Он может выглядеть очень стабильным и счастливым. Что ж, легко быть дружелюбным, когда на кону не стоят деньги.

Если и когда проект становится успешным, правила игры меняются, умные парни, которые запустили прорывной проект, стараются сорвать спелый фрукт и забрать его себе. И вот только тогда становится интересно.

Поле с равными условиями игры не под «запретом»

Есть несколько способов захватить open-source проект, включая торговые марки и патенты. Я рассмотрю только авторские права, потому что это наиболее частый случай. Ключевыми соглашениями, которыми регулируются авторские права на open-source проект, являются а) лицензия и б) политика участия.

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

«закрытая» лицензия, которая не позволяет повторно обрабатывать материал, классическое авторское право плюс некоторые ограничительные лицензии;
лицензия «free to take», которая позволяет одностороннюю обработку материала, например Apache/BSD/MIT;
лицензия «share-alike», которая позволяет двустороннюю обработку материала, например GPL, LGPL и cc-by-sa.

Представьте себе ди-джея, который выпускает популярный бит по модели «free to take». Ведущий музыкальный лейбл делает из бита ремикс и выпускает его. Тот становится хитом. И теперь эта новая версия закрыта. Ди-джей не может ремиксить эту новую работу, и, возможно, не может даже проигрывать ремикс. Конечно, он может взять свою старую версию и улучшить ее, однако деньги будет приносить коммерческая версия.

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

Когда люди называют эту гарантию ограничением, остается только вздыхать по этому поводу. Это как называть замок в моей машине «ограничением», потому что он останавливает остальных от присвоения моей машины. Назвать защиту от воров «ограничением» это…. ну, по меньшей мере, неумение анализировать. Когда правила работают для обеих сторон, это не ограничение, ОК?!

Как происходит захват?

Давайте еще раз определимся с целью. Необходимо предотвратить захват open-source проекта кем-то с большими деньгами и властью, кто нацелился собрать урожай с проекта для своей личной выгоды, за счет сообщества, которое помогало развивать или создало проект. Мне все равно, насколько «правомерен» будет этот захват, я просто объясняю, как его предотвратить.
Лицензия и политика участия являются двумя половинками одной головоломки.

Кто владеет авторскими правами? Они «сконцентрированы» у основателей проекта или они разделены между всеми участниками? Это жизненно важный вопрос. Если они сконцентрированы, то это тривиальная задача по покупке авторских прав, разветвлению проекта, изменению лицензии в одностороннем порядке, — и можно двигаться в закрытом направлении. Однако если права распределены, т.е. многие люди владеют работой, совместно владеют, то вам нужно одобрение всех (не большинства, а 100% единодушие) для изменения лицензии. А это логистически невозможно.

Кстати, если бы вы только знали, сколько людей мне предлагали деньги за коммерческую лицензию на ZeroMQ, вы были бы поражены (очень много). Предложение простое: я продаю им лицензию «non-LGPL», они платят мне хорошие деньги и делают свои версии ZeroMQ. Если бы я специально не позаботился о невозможности этого варианта давным-давно, то я бы был очень богатым. И теперь мириться с бедностью мне помогает осознание того, что ZeroMQ переживет меня.

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

Никто не будет платить за коммерческую лицензию проекта «free to take», потому что они могут просто взять код и использовать его. В некоем смысле я считаю, что это уже неправильно, т.к. нарушает равенство правил игры для всех. Ведь очевидно, что крупная компания выиграет от этого больше, чем маленькие команды. Опять же представьте себе независимого ди-джея, противостоящего звукозаписывающим лейблам со всеми их маркетинговыми и медийными связями и доходами от концертов.

Теперь перейдем к шагу по захвату номер два: найм разработчиков.

«Но код все еще свободен!», — говорят люди. Конечно. Возвращаемся к лейбл vs ди-джей. Пусть лейбл нанимает только одного ди-джея, ключевого сотрудника и использует его, чтобы протолкнуть коммерческий микс альбома. Куда публика тогда пойдет?

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

Предотвращая захват

Я знаю только одну модель, которая предотвращает захват open-source проекта в области ПО:

Лицензия семейства «GPL» (или MPLv2, которая работает схожим образом).
Распределенные авторские права.

Именно так я строю open-source проекты с самого начала, и это требование к любому сообществу, к которому я присоединяюсь. Ваше право делать деньги не включает мое право использовать мою работу как конкурентное преимущество, если только это не взаимовыгодно.

Продолжение следует…

Об авторе

«К сожалению, мы не выбираем себе смерть, но мы можем встретить ее достойно, чтобы нас запомнили, как мужчин.»
— к/ф «Гладиатор»

Питер Хинченс (Pieter Hintjens) — бельгийский разработчик, писатель. Занимал должность CEO и chief software designer в iMatix, компании, производящей free software, такие как библиотека ZeroMQ (библиотека берет на себя часть забот о буферизации данных, обслуживанию очередей, установлению и восстановлению соединений и прочие), OpenAMQ, Libero, GSL code generator, и веб-сервиса Xitami.

Автор более 30 протоколов и распределенных систем.
Основатель проекта Edgenet по созданию полностью безопасной, анонимной глобальной P2P-сети.
Президент ассоциации Foundation for a Free Information Infrastructure (FFII), которая воевала с патентным правом.
CEO сервиса по созданию собственных вики-проектов Wikidot.
Он был активистом open standards и основателем Digital Standards Organization.
Питер в 2007-м был назван одним из 50 самых влиятельных людей в области «Интеллектуальная собственность».

Подробнее тут: Тридцать пять лет я, как некромант, вдыхал жизнь в мертвое железо при помощи кода

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

Сайт Питера Хинченса
Статья в Википедии

О проекте

Я, при поддержке Филтех-акселератора, планирую опубликовать на Хабре (и, может быть, в бумаге) перевод книги «Social Architecture». Имхо, это лучшее (если не единственное адекватное) пособие по управлению/построению/улучшению сообществ, ориентированных на создание продукта (а не на взаимный груминг или «поклонение» лидеру, спортклубу и пр).

Мысли и идеи Питера Хинченса на Хабре:

Протокол ухода из жизни
Optimistic Merging: Сначала люди, потом код. Соберите правильное сообщество, и оно напишет нужный код
Социальная архитектура: стратагемы для успеха open source проектов
Как построить сообщество. Перевод книги «Социальная архитектура»: Глава 1. Инструментарий

Call to action

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

Если вы пришлете ссылки на статьи, видео, курсы на Coursera по управлению/построению/улучшению сообществ, ориентированных на создание продукта, с меня шоколадка.