Linux Forum Казахстан

[size="3"]Попытка унификации соглашений с разработчиками открытого ПО вскрыла много проблем [/size]

Созданный (http://www.opennet.ru/opennews/art.shtml?num=30171) главным юридическим консультантом компании Canonical проект Harmony (http://harmonyagreements.org/) выпустил первую версию набора шаблонов (http://harmonyagreements.org/agreements.html) для создания соглашений CLA (Contributor License Agreement), определяющих типовые условия передачи разработчиком открытого проекта имущественных прав в руки компании или организации. Дополнительно подготовлена интерактивная форма (http://selector.harmonyagreements.org/), позволяющая выбрать оптимальное соглашение с учетом используемой в проекте лицензии.

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

По мнению (http://blogs.gnome.org/bolsh/2011/07/06/harmony-agreements-reach-1-0/) Дейва Нири (Dave Neary), опасность может таиться в том, что само существование шаблонов соглашений с разработчиками открытого ПО может использоваться как популяризация использования CLA и преподноситься как "передовая практика" ("best practice"), которой надо следовать.

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

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

Основным слабым местом проекта Harmony является отсутствие патентного обещания стороне, передающей право, со стороны, это право принимающей. Это на самом деле похоже на отвлекающий манёвр, считает Дейв Нири, потому что такое обещание должно быть в действительности явно прописано в лицензии, под которой контрибьютор лицензирует свою программу, и наличие такого обещания непосредственно в тексте соглашения CLA не выглядит обязательным или практическим. "В целом,"- говорит дальше Нири -"я считаю, что соглашения, разрабатываемые проектом Harmony, могут оказаться полезными для некоторых разработчиков, поскольку соглашения определённо сэкономят время на налаживании коммуникаций между проектами, предоставляющими CLA, и разработчиками, а также уменьшат расходы на юристов для компаний. Тем не менее, в первую очередь я ставлю под вопрос предпосылки и предположения, ведущие разработчиков к решению принять соглашение CLA, без тщательного анализа всех возможных последствий. И общей нашей целью должно быть не написание лучшего соглашения CLA, а рассмотрение путей, когда можно будет обойтись вообще без соглашений."

 Брэдли Кун (Bradley M. Kuhn), известный активист движения за свободное программное обеспечение, директор организации Software Freedom Conservancy и член управляющего совета GNOME, также опубликовал (http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html) в своём блоге гораздо более негативный анализ соглашений, предоставляемых проектом Harmony, с точки зрения индивидуального разработчика. Проект Harmony позиционирует себя как решение проблем в той области, где в сущности никаких особых проблем сообщество не видит, говорит Кун, и даже само название типично маркетинговое - название без определенного смысла, зато создает приятное впечатление. Ниже даётся краткий пересказ мнения Бредли Куна.

• Предоставление имущественных прав (Copyright Assignment, ©AA) не предоставляет действительных гарантий. Некоторый смысл в этих соглашениях есть, в частности если разработчики хотят быть уверенными в том, что условия GPL или другие условия копилефта будут обязательно исполняться, и у них нет времени самим за этим следить. Кроме того, всегда есть возможность назначить судебного агента, следящего за их выполнением, так что и тут необходимость в ©AA довольно ограничена. Кун уверен, что подписывать эти соглашения желательно только с фондом Free Software Foundation, поскольку его моральные принципы широко известны и подкрепляются практикой. Кроме того, фонд FSF в своих ©AA также берёт (http://www.groklaw.net/articlebasic.php?story=20110524120303815) на себя договорные обязанности, имеющие юридическую силу, относительно разработчиков, подписывающих эти соглашения. А в соглашениях, предлагаемых проектом Harmony, объявление таких обязанностей не считается обязательным. Относительно ©AA также стоит заметить, что FSF не требует его подписания для всех пакетов GNU, в отличие от распространённого заблуждения.
• Проект Harmony, тем не менее, заявляет, что основной акцент делается не на предоставление имущественных прав, а на лицензионном договоре контрибьютора (Contributor License Agreement, CLA). Первым таким соглашением в истории открытого и свободного ПО стало Apache CLA (http://www.apache.org/licenses/icla.txt). Фонд Apache Software всегда находился под сильным влиянием IBM и других компаний, которые как правило ищут "тёплые и пушистые" способы получить от каждого контрибьютора подпись под сложными юридическими соглашениями, дающими различные гарантии на код, и передающими определённые права компаниям. Основной и в чём-то справедливой, по мнению Куна, целью CLA является гарантия права разработчика предоставлять свой код под определённой copyright-лицензией. Подписывая соглашение Apache или соглашение, составленное проектом Harmony, разработчик заключает официальный договор с юридическим лицом (как правило, коммерческой компанией), заверяющий тот факт, что разработчик точно знает, что его вклад лицензируется под указанной лицензией. Ответственность за все возможные неточности или спорные вопросы касающиеся этой лицензии, после этого ложится на разработчика.
  
  Конечно, перекладывать ответственность за происхождение кода - это "тёплый и пушистый" выход для юристов компании. Эти юристы знают, что теперь легко могут подать в суд на разработчика-одиночку за нарушение контракта, если разработчик ошибался. Если, например, компания распространит код разработчика и компании в результате этого будет подан иск о нарушении с угрозой выплаты миллионов долларов, то она легко может повернуться к разработчику и подать за это в суд на него. В суде компания будет говорить, что разработчик нарушил условия CLA.
• В отличие от Apache CLA, во все шаблоны договоров, составленные юристами проекта Harmony, включена так называемая "оговорка о применимом праве" (http://www.roche-duffay.ru/faq/pmwiki.php/FAQ/%D0%9E%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%BA%D0%B0_%D0%BE_%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D0%B8%D0%BC%D0%BE%D0%BC_%D0%BF%D1%80%D0%B0%D0%B2%D0%B5), и в этом случае компания сама решает, к чему будет "привязана" эта "переменная", и прочти всегда это решение будет не тем, которые предпочёл бы индивидуальный разработчик. Можно представить следующий сценарий: компания, пообещав разработчику, что программа будет всегда AGPL, затем выпускает проприетарные версии. Разработчик, подписавший соглашение CLA без оговорки о "применимом праве", всё ещё остаётся держателем авторских прав, и имеет возможность применить принудительные меры для исполнения закона об авторском праве, что само по себе позволяет это сделать в рамках законов той юрисдикции, которая больше ему подходит (при условии, что нарушение происходит на территории данной юрисдикции). Соглашение же с данной оговоркой заставляет разработчика согласиться на любую юрисдикцию, указанную в соглашении, и в этом случае возможный процесс о нарушении авторского права превращается в спор по выполнению условий контракта между разработчиком и компанией, в рамках законов, действующих на указанной территории согласно оговорке "о применимом праве". Более того, если разработчик будет действовать на своей территории, то в этом случае будут насильно применяться законы той территории, которая указана в CLA, что может привести к крайне разбросанным и неясным результатам.

Приводя ещё множество деталей, касающихся юридических нюансов разработок проекта Harmony, Кун, заключает, что, хотя он и не является профессиональным юристом, но он - эксперт в политике движения за свободное программное обеспечение, и в этом ключе его мнение - работу проекта Harmony нужно прекратить. На практике различие между политикой и юридической экспертизой как раз показывает корень проблемы проекта Harmony. Это система документов, разработанных комиссией, в основном состоящей из корпоративных поверенных, а преподносится она как результат консенсуса разработчиков FLOSS.

Процесс первоначальной разработки шаблонов проводился секретно на закрытых совещаниях, на которых в основном присутствовали всё те же корпоративные поверенные. Ныне вышедшая версия 1.0 этих шаблонов документов мало отличается от первоначальных шаблонов, анонсированных в апреле этого года, и таким образом остаётся прежде всего документами, тайно разработанными корпоративными юристами, лишь понаслышке знакомыми с культурой свободного ПО. Проект Harmony был инициирован не по просьбе разработчиков, а компаниями, которым бы хотелось убедить разработчиков пассивно принять все эти CLA и ©AA.

Необходимость этого проекта не была чётко обрисована для разработчиков. Что же всё-таки здесь не так? Индустрия последовательно и повсеместно принимает GNU и Linux уже на протяжении многих лет. У движения GNU есть соглашения, разработанные FSF для большого количества их ранних проектов, но более поздние проекты (в частности, GNOME (http://live.gnome.org/CopyrightAssignment/Guidelines)), были либо полностью против ©AA и CLA, либо полностью индифферентны к ним. Linux, со своей стороны, использует соглашение DCO (http://www.opennet.ru/opennews/art.shtml?num=3896) (Developer's Certificate of Origin), которое разрешает самые срочные и важные вопросы CLA, не становясь на пути у разработчиков и не загружая их дополнительными юридическими нагромождениями. Дефекты проекта Harmony заключаются уже в самом его замысле, заключает Кун.