|
Brave GNU World -- Выпуск #28
Copyright © 2001
Georg C. F. Greve
<[email protected]> Расположение оригинала: http://www.gnu.org/brave-gnu-world/issue-27.en.html Перевод на русский язык: Павел В. Ступин (Кобальт) [email protected] Добро пожаловать в очередной выпуск Georg's Brave GNU World. В этот раз центральной темой выпуска будет философское измерение феномена Free Software с акцентом на коммерческом Свободном программном обеспечении. Но сначала мне бы хотелось представить вам несколько проектов. TuxFamily.orgJulien Ducros начал работать над проектом "TuxFamily.org" [5] вместе с группой добровольцев. Источником вдохновения послужил американский проект SourceForge [6], который предоставляет программистам всю необходимую инфраструктуру для разработки ПО и его презентации пользователям (это, например, web-сервер, ftp-сервер, cvs-сервер и др.). Julien Docrus глубоко убежден в том, что европейское и африканское сообщества разработчиков также нуждаются в подобных услугах на территории их континентов. Именно этого и пытается добиться французский проект TuxFamiliy. Акцент TuxFamily на Свободном ПО является очевидным. Программа, используемая для хостинга (vhffs), сама выпущена под лицензией GNU GPL. К тому же, услуги предоставляются исключительно тем проектам, которые могут рассматриваться как Свободные. Так что всем проектам, которые ищут пристанища, рекомендуется обратить внимание на TuxFamily. HOWTO: Работа CVS-сервера через SSH в сhroot-средеОчень часто сравнительно небольшие компании вносят важный вклад в развитие Свободного ПО, при этом оставаясь практически неизвестными за пределами своих стран. Французская компания Idealx - одна из них. На сайте Idealx (Community home page of Idealx) [7] посетители могут обнаружить ряд интересных модулей и документацию по Свободному ПО. Они позволяют эффективно решать набор стандартных задач, и, разумеется, все это выпущено под лицензиями GNU GPL и GNU FDL (Free Documentation License). Среди уже упомянутых пакетов есть модуль, написанный на Python, который позволяет создавать календари с использованием CGI-скриптов. Помимо него также есть настраиваемый на уровне XML скрипт для CVS-уведомлений, который автоматизирует действия при проверке появления новых версия, и еще там есть связка, позволяющая интегрировать Erlang с Python. Одной из главных "достопримечательностей" проекта является Howto [8], написанный Olivier Berger и Olivier Tharan. Предметом данного документа является настройка очень хорошо защищенного и изолированного от вторжений CVS-сервера. Программистам обычно не нужно рассказывать о достоинствах CVS (Система конкурирующих версий) [9], но в то же время почему-то именно CVS является тем инструментом, который обычно недооценивается. Поэтому я постараюсь кратко описать, что такое CVS. Я думаю, что ни для кого не является секретом то, что программное обеспечение обычно создается в виде программного кода. Этот код постоянно редактируется автором или группой разработчиков на протяжении всего процесса разработки. Здесь возникает проблема координирования работы нескольких разработчиков, потому что работа программистов, как правило, автономна - каждый работает за своей машиной. Это, в свою очередь, означает, что программный код изменяется одновременно в нескольких местах сразу. Для решения это проблемы CVS (равно как и другие системы контроля за версиями) обеспечивает существование центральной точки, куда стекается весь код. Эта точка часто называется репозиторием. Каждый разработчик участвует в написании программного продукта, напрямую взаимодействуя с репозиторием, то есть получая обновления от других участников или внося свои собственные изменения. Разумеется, может случиться такое, что два автора изменили одну и ту же часть программы, однако различные способы для разрешения или предотвращения подобных конфликтов не являются важными в контексте моего обзора. На что следует обратить пристальное внимание, так это на то, что репозиторий CVS содержит не только текущую версию, но и реестр всех внесенных изменений. Благодаря этому можно пошагово контролировать разработку в дальнейшем. Также существует возможность вернуться к более ранним версиям, чтобы разбить проект на несколько веток и тем самым получить несколько одновременно протекающих процессов разработки с возможностью их дальнейшего объединения. Все это представляет интерес не только для разработчиков. Учитывая, что в большинстве случаев программный код представляет собой простые ASCII файлы, становится очевидным, что CVS может использоваться для различных типов данных, особенно если данные представлены в виде текста. Web-сайты, документы, архивы электронной почты и многие другие сферы просто идеально подходят для использования с CVS. Главной головной болью при работе CVS-сервера являются права доступа к нему. Существует ряд возможностей для настройки сервера с различными уровнями безопасности. В большинстве случаев учетная запись для CVS означает пользователя в системе, а некоторые средства идентификации пользователей передают пароли в виде простого текста, тем самым давая посторонним возможность прочитать эту информацию. Даже когда эта проблема устраняется за счет использования SSH, тем не менее остается нежелательным давать каждому CVS-пользователю полноценный доступ к системе. Howto [8], который я уже упомянул, очень профессионально описывает то, как настроить один сервер для того, чтобы на нем параллельно работали несколько CVS-серверов, при этом давая пользователям только те права, которые необходимы для работы с тем или иным репозиторием. Документ позволит большинству пользователей среднего уровня установить безопасный CVS-сервер на их машинах, чтобы воспользоваться всеми преимуществами CVS, которые были описаны ранее. AutoGenДля меня всегда является удовольствием представить читателям новый GNU-проект. В этом месяце я решил остановиться на AutoGen [1], проекте Bruce Korb. AutoGen - это инструмент, созданный для удобной разработки и поддержки программ, где высок процент повторяемого кода. Классической иллюстрацией являются циклы для обработки данных, поступаемых с командной строки. В худшем случае эффект повторения текста осуществляется посредством манипуляций с буфером обмена (скопировать - и - вставить) для каждой опции программы, чтобы поместить куда-нибудь все значения, где их могут использовать другие функции, которым эти значения понадобятся. Так как эта проблема является стандартной, в AutoGen есть шаблон "AutoOpts", который решает данную задачу. У AutoGen есть ряд явных сходств с m4 [11], классическим макропроцессором для Unix. Однако Autogen превосходит свой аналог по ряду показателей, в том числе по более прозрачному способу добавления новых параметров в функции. Также Autogen поддерживает вложенные (nested) коллекции значений. Из-за этого Garry V. Vaugnam, второй по активности среди разработчиков проекта (после Bruce Korb), считает, что было бы здорово, заменить в autoconf'е m4 на AutoGen. Если верить Брюсу (Bruce), одним из ключевых достоинств AutoGen является четкое разделение между шаблонами (templates) и определениями (definitions), потому что это добавляет существенную гибкость шаблонам. Также все обращения к данным осуществляются с помощью имен, а не их местоположения, что позволяет изменять структуру файлов и пересортировывать их. Используя такой фундамент, можно позволить старым определениям устаревать без необходимости вносить изменения в старые файлы. Такой подход увеличивает совместимость. Ну и, разумеется, все определения могут становиться вложенными. С помощью переменных, которые отмечают те места, куда будут внесены изменения, становится возможным определять за счет ключевых слов, какие части кода вырезать или повторить. AutoGen также обладает более качественными способами контроля за выводом программы, нежели те, которые предлагаются C-препроцессором. Говоря о недостатках Autogen, Bruce Korb отмечает, что проект практически неизвестен в широких кругах, и что слишком легко превратить шаблоны в загадочные иероглифы. Статическая обработка определений является на сегодняшний день основным ограничением AutoGen, но в планах разработчиков сделать обработку динамической в будущих версиях. Помимо всего этого, AutoGen является достаточно зрелым и стабильным программным продуктом. На сегодняшний день известно, что он работает на GNU/Linux, BSD, SVR4-5, HP-UX, SCO OpenServer и Solaris, а также на Windows NT с установленным CygWin.
Хотя сам AutoGen выпущен под лицензией GNU GPL, некоторые модули выпущены либо под LGPL и FreeBSD license, либо предоставлены во всеобщее пользование (public domain). Свободное программное обеспечение и бизнесКо мне приходят письма, связанные с заглавной темой. В частности, было письмо от Tommy Scheunemann, который интересовался темой "Индустрия ПО и GPL", а также весьма противоречивая дискуссия в рассылке FSF Europe, где обсуждалось, является ли это законным делать деньги на Свободном ПО. Это дало мне понять, что в данной сфере еще существует целый ряд вопросов, открытых для обсуждения. Перед тем, как переходить к вопросу о коммерциализации и взаимоотношениях с индустрией ПО, просто необходимо обратиться к определению Свободного ПО. В первую очередь, всегда нужно четко понимать, что под "free" в словосочетании Free Software подразумевается не бесплатность, а свобода. Но что именно подразумевается под свободой в этом контексте? Самым точным определением свободы для Free Software являются четыре свободы Free Software Foundation (Фонд Свободного Программного Обеспечения) [12]. "Принципы Свободного ПО Debian" берут свои корни именно отсюда, эти свободы являются базой и для "Open Source Definition" (Определение Open Source). По сути все эти три определения были написаны, чтобы описать одни и те же лицензии. Из-за того, что в четырех свободах определение представлено в самой лаконичной форме, я ограничусь только их обсуждением. Первая свобода - это возможность использования программы для любых целей. Наложение ограничений на характер использования будет ясно означать, что программа не может считаться Свободной. Вторая свобода позволяет изучать программу для того, чтобы понять, каким образом она работает, и чтобы внести в нее изменения при необходимости. Доступ к исходному коду программы является обязательным условием для этого. Свобода #3 разрешает копирование и распространение программы, а Свобода #4 суммирует содержание #2 и #3. Она гласит, что пользователь должен обладать свободой делиться усовершенствованиями программы, которые он(а) внес(ла), с другими пользователями. Как и вторая свобода, для выполнения #4 необходим доступ к исходному коду программы. Очень важно понимать то, что обладание свободой делать что-то также включает в себя свободу не делать этого - что применимо к свободам #2, #3 и #4. Это не является обязательным копировать и изменять программу, а также делиться ей с другими пользователями. Фактически, именно требование публикации внесенных изменений сделало невозможным рассмотрение лицензии "Apple Public Source License" как Свободной лицензии. Вопрос о том, считать ли программу Свободной или нет, определяется ее лицензией. Изо всех Свободных лицензий [15], GNU General Public License является наиболее распространенной. Помимо лицензии Lesser General Public License, которая является вариантом GPL, наибольшее значение и применение в реальности имеет лицензия Free BSD License. Так как на счет коммерческого использования? Свободное ПО преднамеренно не различает коммерческое и некоммерческое использования программ. Ведь ограничение на использование в комерческих целях нарушало бы Первую Свободу - таким образом Свободное ПО также всегда является потенциально коммерческим. Вместе со знанием того, что нет необходимости распространять его, становится очевидным то, что Свободное ПО может даже продаваться. Это должно быть ясным, что Свободное ПО может быть коммерческим, хотя это и не является требованием. На сегодняшний день доминирующей моделью на рынке программного обеспечения является модель патентованного (proprietary) ПО, где цена искусственно завышается за счет ущемления описанных свобод. Ситуация такова, что у компаний велик соблазн отбросить все свободы, чтобы увеличить прибыльность уже в краткосрочной перспективе. Существует два способа достичь этого. Лицензии типа FreeBSD license основаны на предположении, что никто не решится поставить свои личные интересы выше интересов общественности. Они преднамеренно допускают ре-лицензирование с возможностью приобретения программным продуктом статуса патентованного. GNU-лицензии обладают защитой против подобных метаморфоз. Если ваш успех напрямую основан на работе других, то у вас просто нет прав выпускать программу как патентованную. В этом случае единственным способом вернуться к схеме с применением патентов является написание модулей, которые технически изолированы от первоначального кода, что требует дополнительного труда и не всегда возможно. В обоих случаях патентованный продукт, как правило, продается как программное обеспечение с добавленной стоимостью с целью убедить пользователя отказаться от его (ее) свобод. Это может произойти как в коммерческом, так и некоммерческом вариантах. Поэтому, несмотря на защиту, предлагаемую GPL, в конечном итоге, исключительно осведомленность пользователей может предотвратить возврат к патентованности ПО. Резюме: нет никаких сомнений в том, что существует как коммерческое, так и некоммерческое Свободное ПО. Это дело выбора. Вместо того, чтобы увлекаться этой дилеммой, нам, однако, следует убедиться в том, что мы еще не забыли о свободе, которая лежит в основе всего движения. достаточно на этот разХорошо, это все на сегодня. Я надеюсь, что понятие коммерческого Свободного ПО стало более ясным для вас, и что я выразил свои мысли в доступной форме. Как обычно я жду от вас комментариев, вопросов, идей, вдохновения и обзоров проектов. Пишите на обычный адрес [1].
|