?

Log in

No account? Create an account

Июнь, 30, 2007

Начало обсуждения темы см. в моих предыдущих заметках:
RB18. Как зарождалась свобода открытых исходных текстов
RB19. Разные взгляды на дух свободы программного обеспечения


Как мы смогли заметить, движения Free Software и Open Source связывают понятия свободы и открытости:
  • свобода использования;
  • свобода изучения;
  • свобода модификации;
  • свобода распространения;
  • открытость изучения;
  • открытость распространения.

При этом в Open Source Definition подразумевают, что “там, где некоторые формы продукта не распространяются с исходными текстами, должны быть обнародованы средства получения за цену, не превышающую обоснованную стоимость воспроизведения — предпочтительно, бесплатное скачивание из Интернета”. Причём “промежуточные формы, такие как вывод препроцессора или транслятора, не допускаются”.

Занятные требования, не правда ли? Т.е. если кто-то использует некоторые собственные средства высокоуровневого программирования (например, специальный математический аппарат — конечные автоматы, сети Петри, нейронные сети и т.п.), с которого автоматически происходит отображение на исходный текст, представленный на том или ином языке реализации, ему сразу указывают на дверь — вон из нашего Open Source. Да если и не автоматически, а вручную – кто и как может определить, работал специальный транслятор при отображении или сам человек? Если кто-то посчитал возможным воспользоваться какими-то внеязыковыми средствами, требующими препроцессорной обработки (например, своими шаблонами) — он вне закона в Open Source.

Не менее занимательно и следующее требование: “Преднамеренное изменение исходного текста таким образом, чтобы он вводил в заблуждение, не допускается”. Простите, а кто и как определяет: (1) введение в заблуждение, (2) преднамеренность введения?

В требованиях к Open Source есть и такое требование: “Производные работы должны поставляться на тех же условиях, как и исходные”. Т.е. они наследуют всю ту “свободу” и “открытость”. Не будем сейчас касаться совершенно понятных вещей. Например того, что свобода одних есть всегда ущемление свободы других. Поэтому мы, как правило, имеем дело с “несвободной свободой”. Здесь же налицо выламывание рук в чистом виде. Если автор что-то создал и отдал в Open Source, если это получено (бесплатно или за деньги) кем-то, кто захотел использовать данный продукт, то у него должно быть право применять правомерно полученный продукт по своему усмотрению. Иначе это весьма своеобразная свобода. В том смысле, что “я тебе формулу дал – будь любезен, всё, что с ней наработал, – верни”. Справедливости ради надо сказать, что ряд лицензий Open Source на этом не настаивает. Но сам принцип декларируется, причём самими основателями движения.

С другой стороны, кто мешает послать далеко всю эту пышно декларируемую “свободу” и “открытость” и делать действительно открытые и доступные вещи на уровне общественного достояния? Т.е. переводить свои работы в известный правовой режим авторского права, когда подобные продукты могут свободно использоваться любым лицом без выплаты авторского вознаграждения. Другими словами, задаром и без ограничений.

Уходят в прошлое те времена, когда в силу развития UNIX-культуры под словами “исходные тексты” (source) понимался исключительно текст на языке Си. Исходники делаются на разных языках, причём проблемно-ориентированных, малоизвестных. Если будет несколько языковых слоёв, да ещё новых языков, не знакомых потребителям продуктов, это не сильно упростит задачу посторонним понять, что там происходит, как они получены, из каких (абстрактных) моделей. Примитивизм Linux и подобных ему OpenSource-вещей в этом смысле уйдёт в прошлое.

С точки зрения науки, создавать гигантские верификаторы того, что наплодили программисты исходя из общих соображений и общеизвестных (разбалансированных) языков программирования — куда менее разумно, нежели позволять там, где это возможно, использовать научный, математический аппарат, анализировать абстракции научными средствами, после чего генерировать исходные тексты на том или ином языке (что зависит от требований проекта, включая целевую платформу). Однако Open Source по сути это отвергает. Не потому ли, что программирование с подачи американцев давно превратилось в ремесло, где слово “наука” вызывает, по меньшей мере, недоумение.

Почему возникло требование обязательного наличия исходных текстов? Идеологи движений за свободу исходили из того, что это — гарантия контроля технологий. Да неужели? Нет такой гарантии. Нет и полной уверенности (при наличии всех исходных текстов), что продукт не содержит умышленных “закладок”, потайных лазеек.

Open Source — это просто исходники; обладание ими не есть обладание технологиями. Чем больше объём подобных исходников, тем большей фикцией становится владение контролем над системой. Если они, разумеется, делались не вами и не вашей группой. Это наглядно показал автор UNIX Кен Томпсон в своей лекции при вручении премии Тьюринга в 1983 г. "Закладки" ("трояны") можно встраивать в компиляторы, которые могут генерировать с одного и того же исходника разный код. Лекция так и называется "Размышления о том, можно ли полагаться на доверие". Какова мораль? Томпсон выразил её просто: "Нельзя доверять программе, которую вы не написали полностью сами... Сколько бы вы не исследовали и не верифицировали исходный текст — это не защитит вас от троянской программы". Кто не читал эту лекцию, см. "Лекции лауреатов премии Тьюринга за первые двадцать лет (1966-1985)" http://www.europrog.ru/book/trng1993r.pdf (69 Мбайт)

Дело не только в закладках. Надо обладать контролем над архитектурно-технологическими аспектами, которые в случае необходимости (патентные претензии, особенности целевого компьютера) могут быть переделаны. Заниматься восстановлением "рабочих чертежей" с исходников (где всегда есть ошибки и где идёт борьба конкретного программиста с ограничениями конкретного языка реализации) — неблагодарное занятие.

Открытость исходного текста даёт возможность иметь представление о том, что внутри происходит (хотя бы примерно). Это лишняя подсказка при отсутствии документации или её ущербности. Это одна из возможностей создания производного программного обеспечения. Хотя производное можно создавать и без наличия исходных текстов, путём расширяющего программирования (extensible programming) или объектно-ориентированного программирования. Наличие же всех исходных текстов облегчает задачу взлома и несанкционированного доступа, а также лишает возможности разработчиков хотя бы на время закрыть от любопытных глаз недоделанные вещи (которые — предмет перспективных исследований или коммерческих контрактов).

Если вы что-то разрабатываете, то должны отдавать себе отчёт в том, что ваше творчество на языках программирования никак не защищено. Авторское право — охрана формы. Оно не распространяется по определению на идеи. Переписать чью-то часть — не самая большая проблема. И это ахиллесова пята Open Source.

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

Но если не Free Software и не Open Source, то какой может быть альтернатива? Давайте попробуем порассуждать. Разработка программ может быть как результатом исследований, так и результатом производства (кустарного или промышленного). В первом случае, как правило, технологическая новизна выходит на первый план. Во втором требуется решить задачу по накатанной колее (опытное и серийное производство). Как отмечает Эрик Реймонд, распределённое сообщество в Open Source востребовано, когда что-то уже создано и надо его просто развивать и совершенствовать. Следовательно, даже сами идеологи этого направления признают, что технологические новинки создавать всем “скопом” в рамках Open Source — неразумно. С другой стороны, исследования в области программного обеспечения по своему характеру не сильно отличаются от научных исследований, имеющих славную историю и богатые традиции. В научном мире открытый обмен достижениями — обязательное условие развития. В последние годы, правда, коммерциализация науки сделала свое пагубное дело и привела к излишнему перекосу в сторону прикладной науки, причём работающей на потреб бизнеса. Что же, тем важнее предлагать модели, которые позволят преодолевать косность и стимулировать дальнейшее развитие как науки, так и индустрии.

Параллели с наукой были замечены и ранее. Линус Торвальдс писал: “Понять феномен открытых исходников помогает аналогия с тем, как наука воспринималась религией столетия назад (а иными и сейчас воспринимается так же). Изначально наука представлялась чем-то вредным, опасным и антиобщественным — именно так многие софтверные компании рассматривают открытые исходники”. Гораздо более обстоятельно эти аналогии раскрыты в более ранней работе проф. Н.Н.Безрукова “Open Source Software Development as a Special Type of Academic Research (Critique of Vulgar Raymondism)” (First Monday, October 1999).

Приведём некоторые важные цитаты. “Убеждён,— пишет Безруков, — что существуют серьёзные проблемы, которые присущи модели разработки на основе открытых исходных текстов. Их нужно обсуждать и осознавать, а лучший способ понять их — использовать аналогию между сообществом открытых исходных текстов и научным сообществом (по сути они пересекаются)”. Далее он продолжает: “Модель открытых исходных текстов очень близка модели научных работ, где исходные тексты трактуются как результаты исследований и публикуются для рецензирования и во благо человечества”. В чём же аналогии? Безруков отмечает следующие моменты: взаимодействие в рамках распределённого сообщества, схожая модель финансирования, единая база (многие проекты создаются в научных подразделениях), одинаковые условия для взаимодействия через Интернет.

“Программное обеспечение, — пишет Безруков, — будет создаваться не отдельной личностью или группой людей, а глубоко взаимосвязанной сетью исполнителей. Хотелось бы сделать акцент на то, что виртуальные команды вероятно напоминают некогда действовавшие неформальные сообщества учёных, которые использовали традиционную почту с рукописными заметками для обмена достижениями, идеями и критическими взглядами”. О финансировании и единой базе: “Финансирование проектов на основе исходных текстов очень схоже с финансированием прикладной науки. Иногда научные исследования финансируются косвенно, поскольку люди, работающие в том или ином институте, становятся заинтересованы в конкретном явлении и ведут исследования за счёт имеющегося финансирования. Значительное число разработчиков в области ПО с открытыми исходными текстами находятся в академических институтах или больших корпорациях. Последние обычно предоставляют очень благоприятные условия для ведения проектов с открытыми исходными текстами, поскольку частенько дают пристанище талантливым разработчикам, которые прямым служебным вопросам уделяют лишь часть своего рабочего времени. Разработка UNIX в Bell Labs — хороший пример таких возможностей”.

Что касается роли глобальных коммуникаций, Безруков отмечает: “Благодаря Интернету теперь можно создавать виртуальную команду для разработки ПО, подобную научной среде, где несколько исследователей, заинтересованных в конкретной проблематике, создают виртуальное научное сообщество для решения тех или иных задач. Малые проекты не нуждаются в явных координирующих структурах. Координация обычно автоматически осуществляется лидером проекта или группой лидеров. Этот подход плохо масштабируется. Для больших проектов авторитарная модель — единственный выбор, если ключевым фактором является скорость разработки. Если скорость рассматривается как важная цель проекта, то сообщество разработчиков осознанно или неосознанно будет идти по пути авторитарных тенденций в отношении своего лидера. Со временем это может приводить к проблемам”.

Рассуждения о демократии и равенстве в рамках Open Source — это сознательная наивность: “Открытые исходные тексты воспринимаются как нечто демократическое, но это не так. Лидеры хорошо известных проектов в области открытых исходных текстов часто явно утверждают, что они диктаторы. Если Линусу Торвальдсу не нравится ваша правка, неважно сколь технически она совершенна”.

В то же время, критика со стороны проф. Безрукова не идёт дальше — к формулировке альтернативной модели. Такой шаг предпринял проф. Анатолий Абрамович Шалыто (СПбГУ ИТМО). В 2003 г. он вышел с инициативой "Движения за открытую проектную документацию" (Open Project Documentation), которую изложил в работе “Новая инициатива в программировании. Движение за открытую проектную документацию”.

Отправной точкой послужила уже приведённая ранее работа проф. Безрукова “Повторный взгляд на Собор и Базар”. Шалыто приводит цитату из этой работы: “Центральный вопрос в практике программирования — вопрос о понимании программных текстов. Всегда хорошо иметь исходники, но проблема состоит в том, что зачастую их недостаточно. Чтобы понять некоторую нетривиальную программу, обычно требуется дополнительная документация. Эта потребность растёт экспоненциально с ростом объема кода. Анализ текстов программ, направленный на восстановление первоначальных проектных решений, принятых разработчиками, и понимание программ являются двумя важными ветвями технологии программирования, существование которых неразрывно связано с недостаточностью исходных текстов для понимания программ. В качестве примера попробуйте понять структуру нетривиального компилятора при условии, что вы не располагаете определением того языка, который им компилируется”.

Проф. Шалыто предлагает такой выход: “Итак, без исходных текстов плохо, но и с ними также нехорошо. Чего же не хватает для полного счастья? Ответ прост: проектной документации, выполненной весьма подробно и аккуратно, в которую программная документация входит как одна из составляющих”.

Казалось бы, это снимает недостатки Open Source. Но так ли это? Каковы стимулы для создания проектной документации при условии, что лицензирование ведётся по-прежнему через схему Open Source со всеми вытекающими проблемами? Если речь идёт о проектной документации, то автоматически подразумевается производство. Но кто сказал, что программирование есть всегда производство? Технологические новинки ближе к научным вещам, к математическим абстракциям. Учёные-математики обмениваются проектной документацией? Вроде бы нет. Проектная документация подразумевает определённую унификацию (стандартизацию). Как это предполагается регулировать в сфере открытых исходных текстов? Получается, что особой мотивации нет и работа в рамках открытой проектной документации – это бремя, которое по доброй воле возлагают на себя её последователи.

Так не разумнее ли разграничить производство и исследования? И для исследований (точнее говоря, научно-исследовательских и опытно-конструкторских работ, НИОКР) предложить особую схему, учитывающую достоинства и недостатки ранее обсуждавшихся? Условно назовём её “открытое исследовательское программирование” (Open Research Programming).

Что туда должно войти:

  1. Результаты труда должны быть общедоступны. Самая оптимальная форма — общественное достояние.
  2. Проект должен быть открыт (публичен) ровно в той мере, как это принято в научном мире. Т.е. раскрывать сырые, промежуточные результаты нет никакого смысла.
  3. Информация о проекте должна быть представлена в разных жанрах, по большей части, неформальных заметках, где раскрываются: постановка проблемы, подходы к её решению, выбор оптимального варианта, конкретные абстракции и алгоритмы, инвариантные относительно языка реализации, описания ключевых спецификаций.
  4. Исходные тексты должны рассматриваться как иллюстрация изложенных идей и подходов, а не как основная самодовлеющая часть.
  5. Целесообразность представления той или иной части в открытом (исходном) тексте определяется разработчиками-исследователями. Другими словами, не должно быть ограничений на использование других форм представления программ, включая картриджи данных, в которых содержатся представления математических моделей.
  6. В силу статуса общественного достояния нельзя налагать никаких ограничений на использование того, что в эту область авторами осознанно переведено.

Скептики возразят: “Понятно, хотите всё засекретить, прикрывшись мнимой открытостью”. Ну зачем же всё секретить? Открытость (публичность) проекта в рамках Open Research Programming не подразумевает обсуждение перед публикой всех без исключения вопросов и установку веб-камер на рабочие места всех участников. Это не шоу.

А как же защита интеллектуальной собственности? Неужели всё на голом энтузиазме и чистом альтруизме? Зачем же? Общественное достояние сохраняет авторские права. Если есть необходимость “столбить” идеи и нет возможности (желания) воспользоваться патентной защитой — можно делать это традиционным образом: публикацией в различных изданиях (включая печатные и электронные). Какие-то вещи закрываются от прямого реинжиниринга специальными абстракциями. Это позволяет в определённой мере сохранять ноу-хау без потери доступности и открытости.

В остальном идеи свободы и открытости (если к ним прибегают) обретают более разумные черты. Здесь нет выкручивания рук. Нет наживы. Дело сугубо добровольное. Open Research Programming создаёт все необходимые предпосылки для формирования виртуальных команд, получения внешнего финансирования (грантов и др.), создаёт основу для перехода к производству и внедрению. Да и для этих этапов данный подход вполне применим.

На самом деле, это практически та же схема (за вычетом статуса общественного достояния), по которой работала группа проф. Н.Вирта в ETH Zurich, начиная с 1970-х годов. Диссертации с идеями и подходами — в открытом доступе. Исходные тексты также доступны, в том числе для модификации. Более того, книги по таким проектам, ставшие мировыми бестселлерами, спустя годы переведены авторами в свободный (бесплатный) доступ.

Движение Open Research Programming в состоянии стать вполне достойной альтернативой Free Software и Open Source. Проект создания новой перспективной отечественной операционной системы планируется проводить в рамках именно такой схемы.

(окончание следует)

Latest Month

Март 2009
Вс Пн Вт Ср Чт Пт Сб
1234567
891011121314
15161718192021
22232425262728
293031    
Разработано LiveJournal.com
Designed by Paulina Bozek