Несколько лет назад двум программистам в Cisco (изготовитель сетевого оборудования) была поручена работа по написанию распределенной системы управления печатью для использования в корпоративной сети Cisco. Это было настоящим вызовом. Помимо поддержки возможности произвольному пользователю A печатать на произвольном принтере B (который мог быть в соседней комнате или на расстоянии в тысячу миль), система должна была удостовериться, что в случае окончания бумаги или чернил задание было направлено по другому адресу на принтер, расположенный недалеко от нужного. Система также должна была сообщать о таких проблемах администратору принтера.

Дуэт придумал интеллектуальный набор модификаций к стандартному программному обеспечению печати Unix, плюс несколько скриптов для оболочки, которые выполняли работу. И в этот момент они поняли, что и у них, и у Cisco проблема.

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

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

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

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

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

Несмотря на мифы о культуре хакеров, в которые все еще (в 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)). Эти пункты имеют следствием (хотя и не предназначены для этого) затруднение получение дохода от продажи напрямую.