Волшебный котел - Рэймонд Эрик С. (читать книги полностью без сокращений txt) 📗
7.2. Случай с Cisco: разделение риска
Несколько лет назад двум программистам в Cisco (изготовитель сетевого оборудования) была поручена работа по написанию распределенной системы управления печатью для использования в корпоративной сети Cisco. Это было настоящим вызовом. Помимо поддержки возможности произвольному пользователю A печатать на произвольном принтере B (который мог быть в соседней комнате или на расстоянии в тысячу миль), система должна была удостовериться, что в случае окончания бумаги или чернил задание было направлено по другому адресу на принтер, расположенный недалеко от нужного. Система также должна была сообщать о таких проблемах администратору принтера.
Дуэт придумал интеллектуальный набор модификаций к стандартному программному обеспечению печати Unix, плюс несколько скриптов для оболочки, которые выполняли работу. И в этот момент они поняли, что и у них, и у Cisco проблема.
Проблемой было то, что ни один из них, вероятно, не остался бы в Cisco навсегда. В конечном счете, оба программиста ушли бы, программное обеспечение осталось бы без поддержки и начало «загнивать» (то есть постепенно переставать удовлетворять условиям совместимости, необходимым для работы). Никакой разработчик не желает видеть, как это происходит с его творением, и бесстрашный дуэт чувствовал, что Cisco заплатила за решение проблемы, не так уж неблагоразумно ожидая, что программа переживет их собственные рабочие места.
Исходя из этого, они пошли к своему менеджеру и убедили его разрешить выпуск программы управления печатью с открытыми текстами. Их аргументы заключались в том, что у Cisco нет возможности получить никакой прибыли от продажи программы, которые можно потерять, но при этом она может извлечь пользу. Поощряя рост сообщества пользователей и со-разработчиков, распространенных во многих корпорациях, Cisco могла эффективно застраховаться в случае ухода первоначальных разработчиков программы.
История Cisco иллюстрирует модель, в которой функция открытых исходных текстов не столько в том, чтобы понизить затраты, сколько в том, чтобы распределить риск. Все стороны находят, что открытость исходников, и присутствие совместного сообщества, финансируемого из множества независимых источников, обеспечивает предохранительные меры, которые представляют самостоятельную экономическую ценность — являются достаточно ценными для того, чтобы вести финансирование.
8. Почему получение продажной стоимости проблематично
Открытые исходные тексты делают довольно трудным получение продажной цены напрямую за программное обеспечение. Трудность не является технической; исходный код — не более и ни менее подвержен копированию чем исполняемые файлы, поэтому распространение авторского права, и законодательства о лицензировании, разрешающих получать деньги за продажу программы, при необходимости не было бы более трудным для программ с открытыми текстами, нежели для программ с закрытым кодом.
Трудность находится скорее с характером общественного договора, который поддерживает развитие открытых текстов. По трем взаимно усиливающим друг друга причинам, главные лицензии на открытые программы запрещают большинство ограничений на использование, распространение и модификацию, которая облегчила бы получение дохода от продажи напрямую. Для понимания этих причин мы должны исследовать социальное окружение, в котором эти лицензии развились: хакерскую культуру Интернета.
Несмотря на мифы о культуре хакеров, в которые все еще (в 1999 году) широко верят посторонние, ни одна из этих причин не имеет отношения к враждебности к рынку. В то время как меньшинство хакеров действительно остается враждебным к получению прибыли, общая готовность сообщества сотрудничать с коммерческими производителями дистрибутивов Linux, подобными Red Hat, SUSE, и Caldera, демонстрирует, что большинство хакеров будет счастливо работать с корпоративным миром, когда это способствует достижению их целей. Реальные причины настороженного отношения хакеров к лицензиям, позволяющим напрямую получать доход, менее очевидны и более интересны.
Одна причина имеет отношение к соразмерности прав. В то время как большинство разработчиков программ с открытым кодом, в сущности, не возражает против других, получающих прибыль от их даров, большинство при этом требует, чтобы никто (с возможным исключением создателя части кода) не находился в привилегированном положении, для извлечения прибыли. Вася Пупкин позволяет Fubarco получать прибыль, продавая написанное им программное обеспечение или патчи, но только пока сам он также может сделать так.
Другая причина связана с неявными последствиями. Хакеры заметили, что лицензии, которые включают в себя ограничения и разрешают плату за «коммерческое» использование или продажу (самая общая и на первый взгляд, благоразумная форма попытки получить продажную стоимость напрямую), имеют очень опасные последствия. Один из специфических — бросание тени на действия наподобие распространения программы на недорогих антологиях CD-ROM, которые, в идеале, нужно было бы поощрять. В более широком аспекте ограничения на использование/ продажу/ модификацию/ распределение (и другие осложнения в использовании) ограничивают расходы на прослеживание соответствия и (в той степени, в какой повышается число программных пакетов, с которыми люди имеют дело) комбинаторный взрыв неуверенности в и потенциального юридического риска. Этот результат считается вредным, поэтому существует сильное общественное давление, направленное на то, чтобы держать лицензии простыми и свободными от ограничений.
Заключительная и самая критичная причина относится к сохранению возможности экспертизы со стороны членов сообщества и культуре даров, развитие которой описано в [2]. Ограничения лицензий, разработанные для того, чтобы защитить интеллектуальную собственность или получение напрямую цены продажи часто делают невозможным с юридической точки зрения ветвление проекта (так обстоит дело, например, с «лицензиями» «Community Source» Sun для Jini и Java). В то время как к ветвлению относятся отрицательно и оно рассматривается как крайняя мера (по причинам, обсужденным подробно в [2]), считается, тем не менее, важным, чтобы присутствовала возможность пойти на эту крайнюю меру в случае некомпетентности сопровождающего или его отступничества (например, перехода к более закрытой лицензии).
Сообщество хакеров имеет некоторую уступчивость к требованиям симметрии; таким образом оно допускает лицензии, подобные NPL Netscape, дающие немного привилегий создателям кода (определенное в NPL исключительное право использовать открытые тексты Mozilla в производных изделиях, включая программы с закрытыми исходниками). Это дает меньше поводов для причинения незапланированных последствий, и предохраняет от ветвления (чт о является причиной того, почему «схемы» «Sun Community License» для Java и Jini были признаны сообществом в значительной степени неудовлетворительными).
Это объясняет пункты «Определения открытых исходников» (Open Source Definition), которое было написано для того, чтобы выразить позицию сообщества хакеров по отношению к критическим особенностям стандартных лицензий (GPL, лицензия BSD, Лицензия MIT, и «Художественная лицензия» (Artistic License)). Эти пункты имеют следствием (хотя и не предназначены для этого) затруднение получение дохода от продажи напрямую.
