Как захватить/защитить open-source проект

https://hintjens.gitbooks.io/social-architecture/content/chapter2.html
  • Перевод
image

На «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 проект не может быть захвачен. Это совершенно не верно. Грубо говоря, есть три типа соглашений об авторских правах:

  1. «закрытая» лицензия, которая не позволяет повторно обрабатывать материал, классическое авторское право плюс некоторые ограничительные лицензии;
  2. лицензия «free to take», которая позволяет одностороннюю обработку материала, например Apache/BSD/MIT;
  3. лицензия «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 проекта в области ПО:

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

Именно так я строю 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. :)
Протокол ухода из жизни

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

О проекте


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

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


Call to action


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

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

Philtech Initiative

87,00

Общественное благо через цифровые технологии

Поделиться публикацией
Комментарии 29
    +7

    Свобода — хрупкая вещь. Она не дана нам от рождения, её нужно выстрадать.

      +1
      Если вами было обнаружено нарушение GPL, необходимо сообщить об этом правообладателю(-ям) как можно скорее. Если вы сами являетесь правообладателем, ФСПО может посодействовать вам в защите ваших прав. Свяжитесь с ними.
        +1
        Там вроде все уже одумались и всё откатили. Похоже, что конфликт исчерпан.
          +1
          Я так и подумал. В любом случае, информация может пригодиться тем, кто решил зайти в комментарии к этой статье.
          +1

          Спасибо. Правда, я всегда полагал, что нужно обращаться в Software Freedom Conservancy. Или из-за их тяжбы с SFLC они сейчас не у дел?

            +1
            Про них, честно сказать, никогда не слышал. Знаю, что есть еще gpl-violations.org. Но FSF, все-таки, первой приходит на ум как основной создатель GPL. Тем более, что я и еще куча человек со всего мира платим им на это ежемесячные взносы. Пускай отрабатывают! :-)

            Главное, как можно скорее связаться с правообладателем. Никакая организация не сможет остановить нарушение GPL, пока владелец авторских прав не обратится к ним за помощью.
          0
          Свобода вполне конкретная вещь и имеет четкое определение (читать Энгельса) и уж точно не имеет ничего общего со страданиями, моралью и прочей абстрактной хней, окей?
            +1
            По годам жизни могу предположить, что Фридрих Энгельс при всем своем желании не смог бы дать определение свободы современного ПО.
          +1
          Когда люди называют эту гарантию ограничением, остается только вздыхать по этому поводу. Это как называть замок в моей машине «ограничением», потому что он останавливает остальных от присвоения моей машины.

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

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


            Но ведь именно для этого она и создавалась! Так что аналогия с замком мне очень понравилась. Возможно, замок на моей двери очень сильно ограничивает вас (придется пользоваться моей квартирой на моих условиях), но ведь в этом его задача и состоит.

              +2
              Да, она ограничивает вашу возможность взять чужую работу без спроса на ваших условиях.
              Практически любая лицензия ограничивает взятие продукта на чужих условиях, в том числе и свободные MIT или Apache.
              Из исключений вспомню лишь WTFPL.
                +1

                MIT как ограничивает? Вы же можете взять код под MIT и перелицензировать его, ни у кого не спрашивая?


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

                  +1
                  Мне очень нравится вот такая лицензия
                  Она позволяет почти всё что угодно, но вот поменять лицензию нельзя, а контрибутить изменения надо.
              +1

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

              +1
              IT рейдерство )))
                +2

                Что общего между копирайт лобби и поклонниками GPL? И те, и те считают, что создание точной копии информации без потери оригинала — воровство. Хотя существует достаточно количество людей, которые используют BSD-like не только осознавая полную потерю контроля, но и ставя это своей непосредственной целью.

                  0
                  Я считаю, что автор сам вправе выбирать лицензию.
                  Хоть я и предпочитаю свободные лицензии типа BSD/MIT, но все равно согласен с тем, что нарушение прав автора противозаконно.
                    +1

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

                    +2
                    И те, и те считают, что создание точной копии информации без потери оригинала — воровство.

                    Nope. Наоборот, поклонники GPL хотят, чтобы пользователь мог собрать программу из исходников. Копировать никто не запрещает. Если кто-то скопирует программу для личного использования, но не будет её распространять, то он не нарушит GPL. Если скопирует и будет распространять вместе с исходниками — опять же ничего не нарушит.


                    С их точки зрения воровство — когда пользователя лишают возможности собирать и менять программу.

                      0

                      И это правильно

                      +3
                      Насколько я помню, GPL — это борьба «копилефта» с «копирайтом» оружием последнего.

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

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

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


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


                        У GPL благородные намерения и я готов им симпатизировать, но давайте всё же называть вещи своими словами: политический идеал GPL — это коммунизм. Возможности общества в целом являются приоритетными, даже если это подразумевает ограничения для отдельного индивидуума. Вне зависимости от того, разделяете ли вы эти идеалы, подавать их под брендом свободы — лицемерно. Может быть множество уважительным причин ограничивать использование опубликованных исходников, но они всё равно останутся искусственными ограничениями.

                          +1
                          > политический идеал GPL — это коммунизм

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

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

                          А вот свобода продавать одно и тоже знание в чёрном ящике (бинарный код) раз за разом тут как раз ущемляется.

                          Так что никакого лицемерия, главное в терминах и определения договориться.
                            +1
                            Вспоминается эта новость на Geektimes: Самостоятельный ремонт трактора John Deere — нарушение закона DMCA.

                            Почему-то когда дело заходит о самостоятельном ремонте техники, то большинство возмущает запрет производителя что-либо делать с устройством. Ведь вы же его купили, значит, оно принадлежит вам. Но когда производитель запрещает вам, например, самостоятельно исправить баг в купленной вами программе, который ему некогда пофиксить самому, то это вроде как «нормально».
                      +1

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


                      Apache-like лицензия позволяет фактически украсть всю работу в три простых шага:


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

                      В итоге пользователи перетекут в форк, а оригинал будет заброшен.

                        0

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


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

                          0

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


                          Если компания решила использовать OpenSource для своих продуктов, GPL не особенно является проблемой, т.к. покупателей волнует функционал, а не публичность доработок.

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

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


                            Ключевой для бизнеса код выкладывается очень редко, вне зависимости от лицензии.

                          +3
                          «Статегия Microsoft»… Где-то была статья про то, а что будет с Linux, когда в Windows будут все его фичи плюс свои собственные плюшки. Там ещё писалось как убивали Netscape и убили кучу других продуктов.

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

                        Самое читаемое