На коротком поводке

Новым в Gated Source является только название. На самом деле, на сходной сумме условий распространялось и распространяется значительная часть проприетарного программного обеспечения за исключением, возможно, специфического софта, адресованного пользователям персональных компьютеров, где утаивание исходных текстов проприетарного ПО стало нормой.

Новым в Gated Source является только название. На самом деле, на сходной сумме условий распространялось и распространяется значительная часть проприетарного программного обеспечения за исключением, возможно, специфического софта, адресованного пользователям персональных компьютеров, где утаивание исходных текстов проприетарного ПО стало нормой.

Пример UNIX

Самый масштабный и изученный пример - это тридцатилетняя судьба UNIX, и, увы, большого оптимизма она не внушает.

Напомню, что ОС UNIX, разработанная в 1970-х гг. по контракту с AT&T для внутреннего использования в структурах последней, долгое время была доступна независимым разработчикам и внешним пользователям по цене копирования - не потому, что у AT&T была какая-то рациональная политика в этом плане, а потому, что компании-монополисту на рынке услуг связи было запрещено вторгаться на смежные рынки.

После разукрупнения «мамы Белл» (1984-86 гг.) ее наследники стремительно вступили на рынок программного обеспечения, причем сделали это с изяществом слона, выходящего на рынок хрусталя и фарфора: цены на право доступа к базе кода UNIX были установлены на уровне десятков тысяч долларов, и пользователи почувствовали, что их откровенно надувают - вкладывались-то в освоение и развитие системы они совсем в других предположениях.

Дальнейшее общеизвестно: рынок Открытых систем стал в конце концов конкурентным, и соперники UNIX - системы BSD, а позднее - и Linux - были предложены на условиях, которые сделали владение исключительными правами на базу UNIX чуть ли не чистым пассивом, и эти права долго гуляли по рукам, как чемодан без ручки, который бросить жалко, а нести неудобно.

Однако коррекция рынка потребовала времени, а конфликт 1992-94 гг. между Berkeley Software Design, Inc. и Unix System Laboratories по поводу прав на тексты вверг пользователей и разработчиков в сомнения и уныние, нетто-результатом которых стало критическое уменьшение доли Открытых систем на рынке - если бы не совпавшее по времени бурное развитие сетей Интернет, оно, видимо, было бы еще большим ¹.

Однако ничего специфичного именно для Gated Source в этом нет, это типичный случай «отрицательной спирали» (неправильное позиционирование - падение спроса - нехватка средств на развитие - падение качества - еще более «кривое» позиционирование и т. д.), в которую попадает продукт ² и от падения в которую не застрахована, вообще говоря, и свободная разработка, правда, с менее катастрофическими последствиями. То, что отдельно от полноценного (с исходными текстами) софта по совсем другим ценам позиционировалась и усеченная (только исполняемые модули) версия UNIX, скорее затемняет, чем проясняет всю историю.

Эксцессы проприетарности и проприетарность без эксцессов

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

Итак, резюмирую: нет никакого основания говорить о Gated Source как о «компромиссе» между проприетарным и свободным программным обеспечением. Gated Source предполагает проприетарность и ею живет, его специфика в том, что он смягчает некоторые отрицательные последствия закрытости. Тем не менее, распространение и разработка софта на условиях Gated Source позволяет «сэмулировать» некоторые свойства свободных проектов. Иными словами, GS - это альтернатива, но лишь внутри домена проприетарного.

Вряд ли обоснованно и рассматривать Gated Source как средство «рубить хвост по частям» - осуществить поэтапный переход от «жестко проприетарной» модели разработки к свободной.

Практика ³ показывает, что основные сложности в «освобождении» проприетарного софта связаны:

• во-первых, с тем, чтобы отделить «свой» код (код, исключительными правами на который обладает изначальный разработчик/владелец) от «чужого» (исключительные права на который принадлежат третьим лицам),

• и во-вторых, с тем, чтобы преодолеть психологическое сопротивление и ложную рационализацию части инвесторов и, возможно, менеджеров.

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

Дополнительная сложность Gated Source в том, что если для «жестко проприетарного» софта есть справочники и пособия по лицензированию, а сфера свободного софта также достаточно подробно описана в этом отношении (см. материалы на www.gnu.org и www.opensource.org), то здесь приходится анализировать образцы и думать над ними.

Возможно, нижеприведенные соображения кому-то помогут.

Алгебра лицензирования

Многих разработчиков модель Gated Source вполне устраивает, как и их клиентов. Из известных примеров приведу среду Solaris от Sun Microsystems, ОС plan9 и Inferno, разработанные Lucent Technologies, Inc. и распространяемые VitaNuova, Inc. и QNX, бесплатную с недавних пор для некоммерческого использования и предоставляющую значительную часть исходных текстов членам своего сообщества. Вокруг QNX, достаточно популярной в нашей стране, кстати, сложилось внешне весьма успешное русскоязычное пользовательское сообщество.

Появляются и российские проекты, разворачиваемые на сходных условиях - перед «РИФом» о переводе движка Communiware под Gated Source-лицензии объявила «ТехИнвестЛаб» ⁴.

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

Стоимость «входа» и основания для ценовой дискриминации. Известны две модели «пропуска»: 1) недискриминационный и 2) дискриминирующий по «коммерческому/некоммерческому» способу использования. В последнем случае следует аккуратно провести границу между ними, поскольку общепринятого толкования «некоммерческого» использования нет.

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

Наличие внутреннего рынка. Один из основных вопросов - могут ли пользователи обмениваться производными от вашего кода произведениями и могут ли брать за это деньги, и если да, то квалифицируется ли такое использование кода как «коммерческое».

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

Рамки различных юрисдикций. Экспортируете ли вы всем пользователям свою национальную юрисдикцию или пытаетесь создать общезначимую лицензию? В последнем случае следует прописывать толкования большинства используемых в тексте лицензии терминов, так как разные законодательные системы могут вводить для них разные умолчания.

И еще - last but not least - существенным недостатком всех изученных лицензий являлась чрезмерная свобода, оставляемая за собой на будущее «хозяином» в части изменения их условий. Можно заметить, что «хозяин» немногим поступается, лицензировав код на установленных условиях бессрочно либо обязавшись возобновить лицензию на не худших для пользователя условиях, а последнему это может изрядно придать уверенности.

[i39350]