НОВОСТИ: Второй пошел?

Автор: Виктор Шепелев

24 мая, с горем пополам, стартовал главный этап второго конкурса для студентов-программистов Google Summer of Code (см. «КТ» #637) — собственно реализация проектов.

А «горя» было немало. Начать с того, что «старт» (то есть публикацию списка проектов, выбранных для «Кодового лета») назначили на 23 мая. Целый день 6400 студентов и 101 опенсорсная организация ждали решения «Поисковика №1» — и ничего. Утром 24-го на веб-страничке code.google.com/soc все еще висела старая заставка, однако письма участникам все же были отправлены. Здесь, правда, организаторы поспешили — 1800 студентов получили ошибочные уведомления о том, что их проект выбран. Весь день 24 мая ньюс-группа Summer Of Code пестрела извинениями и инструкциями на тему «если вам пришло одно письмо с сообщением, что вы избраны, — а потом второе, что нет, то верить надо второму»; а равно и упреками «обманутых вкладчиков».

Тем не менее начали. В этом году для получения 4500 долларов за интересное времяпровождение было отобрано 630 проектов против прошлогодних 410. Немного, если учесть, что количество «отметившихся» организаций выросло в 2,5 раза (101 против 40). Солидный прирост желающих заполучить «студентов на халяву» неудивителен после победных реляций SoC 2005: более 84% проектов было завершено успешно и в срок, организации-менторы получили полезный код, а студенты-участники — полезные деньги. Менее афишируется, что по прошествии полугода с первого «кодового лета» ситуация выглядит не так радужно: всего около 30% студентов продолжили развитие своих проектов, а большинство предпочло «свалить с деньгами». В общем, это понятно (на голом энтузиазме, не подкрепленном гугловскими деньгами, не каждый продержится), однако достойно сожаления — ведь код, оставшийся без «хозяина», во многих случаях становится «мертвым грузом»: даже если его не выкидывают из проекта, то развивать задел все равно некому.

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

По спискам идей, принятых для различных вариантов *nix, можно неплохо представить ориентацию этих операционных систем: BSD-клоны, традиционно «серьезно-серверно-сетевые», сосредотачивают усилия на воплощении сетевых функций и улучшении файловых систем, а также расширении количества железяк, на которых FreeBSD/NetBSD портированы[К слову сказать, на страничке FreeBSD очень странно смотрится задача «исправить уязвимости IPv6», отданная на откуп студенту-энтузиасту]. У Gentoo-дистрибутива Linux с репутацией «максимально настраиваемого» бо’льшая часть задач — менеджеры, настройщики и конфигураторы; у «самого человечного» Ubuntu — задачи интерфейсные, вроде «экранной лупы» или «экранной клавиатуры специально для TabletPC». Такое же «разделение обязанностей по предназначению» и у оконных менеджеров: KDE развивает множество своих «финтифлюшек» — PIM, фотоальбом, KOffice, редактор формул; более «стройный и системный» Gnome сосредотачивается на сетевой функциональности и внутренних библиотеках (хотя и здесь упомянуты различные дополнительные приложения).

Впрочем, отдельные программы по масштабам участия догоняют операционные системы: монструозный OpenOffice.org 2.0 намерен за «гугловское лето» радикально улучшить интеграцию с Mac OS X; Gaim, который «всего-навсего интернет-пейджер», заграбастал аж девять студентов (больше, чем некоторые из линуксов)[У Gaim’а наиболее положительный прошлогодний опыт — из десяти студентов, выбранных прошлым летом, все десять до сих пор работают в команде]; еще тринадцать взяли «на двоих» графические редакторы GIMP и Inkscape.

Шумиха последнего года вокруг различных версий Web не прошла даром: одна только Apache Foundation «подняла» 27 проектов. Справедливости ради заметим, что они относятся не только к одноименному веб-серверу, но все же бо’льшая часть — это реализация фич, связанных с новомодным AJAX и сходными технологиями. Wikimedia Foundation, «хозяин» Wikipedia, из сотни предложенных проектов выбрал всего два; правда, один из них скромно называется Video for Wikipedia и подразумевает «отображение видео со страниц Википедии в браузере, не требующее установки плагинов» (!). Отметились и другие вики-движки, CMS и библиотеки для создания AJAX-эффектов; в списке организаций-участников фигурирует даже LiveJournal; правда, он почему-то не выбрал ни одного проекта.

Сюда же, в категорию «скоростного веборазвития», стоит записать и четыре основных языка веб-разработки (Perl, PHP, Python и Ruby, обязанный своей резко возросшей популярности библиотеке RubyOnRails). Из них Perl’овцы активно занялись подготовкой Perl6, который чуть ли не пять лет пребывал в состоянии «скоро будет спецификация», а за последний год практически завершен благодаря усилиям удивительного человека Одри (Атриус) Танг[Долго рассказывать, чем он(а) удивителен(льна). Интересующихся отсылаю к Google]. PHP и Ruby ничего интересного не обещают; зато Python, с его выигрышной комбинацией высокой выразительности и относительно неплохой скорости, похоже, развивается во всех направлениях сразу: среди его 25 (!) проектов — и веб с AJAX’ом, и развитие популярных игровых библиотек, и 3D-графика, и сложные научные вычисления, и радикальные улучшения самого языка[Python Foundation, видимо, удовлетворился результатами прошлого года — несмотря на то что в полном объеме была реализована лишь треть идей, а часть студентов и вовсе исчезла еще до конца лета]. Энтузиастам Ruby, который пока выигрывает в выразительности языка, но радикально проигрывает в скорости и количестве библиотек, сейчас должно быть не слишком весело; тем более что Django, прямой конкурент RubyOnRails, но написанный на Python, тоже участвует в SoC (в отличие от самих «Рельсов»).

Кроме четырех упомянутых «столпов», в рамках Summer of Code ведутся работы над языками Haskell и Lisp, а также десятками других утилит для разработчиков (библиотеки, компиляторы, среды разработки, средства контроля версий). Эти проекты не вызывают никаких опасений за свою судьбу: большинство студентов, взявшихся за развитие утилит для разработчиков, делают это в первую очередь «для себя».

Из оставшихся проектов выделим несколько динамично развивающихся 3D-движков (OGRE, Project Looking Glass); ряд задач под эгидой NASA (Free Earth, Mars Space Flight Facility); Internet Archive с его «машиной времени», стремящийся еще улучшить свой и без того ни с чем не сравнимый сервис; а также постепенно «выползающий из тумана» мегапроект Internet 2. Google не забыл и о себе: в его активе удивительная задумка «Игры для счастья» («веб-игра, в которой широкая аудитория учится быть счастливой»), задача с зубодробительным названием, касающаяся машинного перевода, и пара чисто технических проектов.

В общем, поезд пошел. Следующая остановка — 26 июня, «Оценка середины работы».

АНАЛИЗЫ: Краткий путеводитель по зоопарку публичных лицензий

Автор: Федор Зуев

Успех проекта GNU и широкое распространение генеральной публичной лицензии (GPL) GNU, ставшей его символом, породил множество подражаний. Движение свободного софта стало предметом пристального интереса широкой публики и государства, бизнеса и академических исследователей.

Идея дозированной передачи авторских (а в последнее время — и патентных) прав как орудия социальных преобразований сверхпритягательна для многих социально-ориентированных компьютерщиков и компьютерно-ориентированных юристов. Поэтому с середины-конца 1990-х различные типовые публичные лицензии стали расти как грибы после дождя. Может даже показаться, что их число скоро превысит число самих лицензируемых программ. В то же время стороннему наблюдателю лицензионная механика зачастую непонятна. Что такое публичные лицензии? Почему их так много? Почему программисты придают различиям в лицензиях такое большое значение?

Позвольте предложить вам краткую экскурсию по зоопарку публичных лицензий.

Часто спрашивают, да еще с эдакой ехидцей, в чем разница между публичными лицензиями и так называемыми «Лицензионными соглашениями конечного пользователя» (по-английски сокращенно EULA — текстами, выводимыми при инсталляции проприетарных программ и снабженными внизу кнопочкой «Я тебя уважаю!», которую нужно нажать, чтобы продолжить инсталляцию)? Следует честно ответить: кроме сходства в названиях между ними нет ничего общего.

Публичные софтверные лицензии появились в 1980-х годах, после введения в США копирайта на программы. Они формулируют общие условия, на которых автор передает публике право на распространение кода. Без публичных лицензий мы должны были бы, по букве закона о копирайте, каждый раз испрашивать особое разрешение у автора на копирование файла на другой носитель, на продажу диска с программой, на перевод сообщений и даже на исправление ошибки. Запуск программы не требует особого разрешения (как и, скажем, чтение книги), и публичные лицензии обычно тоже его не касаются. Впрочем, с распространением в некоторых странах софтверных патентов, претендующих на контроль именно работы программ, новейшие публичные лицензии стали затрагивать и этот вопрос.

EULA исторически происходят от договоров о сохранении коммерческой тайны, которые в 1960—70-е годы заставляли подписывать своих клиентов продавцы программ. В те времена это имело определенный смысл, поскольку компьютеров было мало и каждая продажа была Действом, совершавшимся с глазу на глаз. В наше время, когда программами торгуют в розницу, говорить о какой-то тайне уже не приходится. Сейчас основным содержанием EULA являются разного рода дисклаймеры — заявления об отказе от ответственности за результаты работы программы, предупреждения о возможных ошибках и т. д. Смысл их не в передаче пользователю прав, а, напротив, в ограждении разработчика от претензий пользователя. Для того и требуется нажатие на кнопочку — как доказательство того, что пользователь EULA читал. Зачастую в EULA также включают несколько внушительно звучащих фраз про авторские права (как правило, неточных или даже вовсе ошибочных).

Самая простая и исторически первая из ныне используемых свободных лицензий — лицензия операционной системы BSD — появилась в начале 1980-х. Она коротка и проста. Лицензия предоставляет полную свободу распространения кода, на любых условиях, с исходными текстами или без них, и заботится только об охране честного имени организации-автора (Калифорнийский университет). Конкретно: требуется, чтобы 1) при распространении исходных текстов сохранялся текст лицензии вместе с именем автора, 2) при распространении двоичных кодов лицензия и имя помещались в документацию и 3) имя автора не должно упоминаться всуе, то есть в рекламе продуктов, основанных (derived) на данном исходном коде. Был еще четвертый пункт — о демонстрации рекламной фразы со ссылкой на первоначальных разработчиков при любом упоминании продукта, использующего программу, но в 1999 году по многочисленным просьбам публики он был убран — сложным системам, использующим код многих программ, приходилось прокручивать порой до десятка страниц рекламы.

Аналогичные условия содержит лицензия другого классического проекта — X Window, называемая обычно MIT/X-лицензией. Лицензии такого типа называют пермиссивными, всеразрешающими. Их главной особенностью является то, что они позволяют как лицензировать исходные тексты под любой другой лицензией, так и вовсе их придержать.

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

Философия эта, впрочем, носит характер больше теоретический, нежели практический. Львиная доля BSD-лицензированных программ возникла в результате исследований, проводимых по государственным грантам американскими университетами. BSD-лицензия в них не являлась выбором разработчика, а была условием получения денег. И тут пермиссивная лицензия выглядит не только уместной, но и единственно возможной. Вряд ли вообще законно ставить обществу условия при распространении кода, созданного на его же, общества, деньги. Другой источник BSD-лицензированного кода — крупные корпорации, пропагандирующие новую технологию путем публикации ее «образцовой» реализации. Пример тому — X Consortium, созданный крупнейшими компьютерными фирмами для разработки стандартной графической системы юниксов X Window.

История с TEX и LATEX показывает, до каких крайностей можно дойти в защите своей репутации.

Издательская система TEX, детище известного математика Дональда Кнута (Donald Knuth), была одной из первых свободных программ. Но лицензии на распространение TEX, в современном смысле, не существует. Вместо этого Кнут опубликовал статью в научном журнале, повествующую о том, каковой он желает видеть дальнейшую судьбу TEX.

Система обрастала расширениями и дополнениями, из которых наиболее известен макропакет LATEX, ставший «лицом» TEX для современных пользователей. Условия распространения формулировались среди пользователей TEX неформально. Фактически их превращение в общепринятую форму публичной лицензии произошло только в 1999 году в виде LPPL — LATEX Project Public License.

LPPL примечательна тем, что она вообще запрещает вносить какие-либо изменения в существующие файлы. Содержащийся в этих файлах код может свободно использоваться, но лишь во вновь созданных файлах с другими именами. Все однажды опубликованное должно оставаться неизменным. Последнее не относится к первоначальным авторам — они могут исправлять ошибки по своему усмотрению. Такое требование кажется диким обычному программисту, но «TEXники» ценят стабильность результата выше, чем его безошибочность. По поводу LPPL были большие споры: можно ли вообще относить ее к свободным лицензиям? Кончилось тем, что в последующих версиях формулировки были сильно смягчены.

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

Про GPL, детище Ричарда Столлмена (Richard Stallman) и Free Software Foundation (FSF), можно сказать много, но я ограничусь кратким упоминанием о лицензии — ибо не упомянуть о ней все-таки нельзя. Именно с публикации GPL отсчитывается существование свободного софта как единого значимого социального и экономического явления, а не просто совокупности замкнутых на себя кружков, каким сообщество было до Столлмена.

К GPL восходит добрая половина всех концепций и технических решений, используемых свободными лицензиями: копилефт (см. врезку), апгрейд лицензии, реализация передаваемых прав как способ заключения договора, понятие исходного кода и т. д.

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

Больше двух третей всех свободных программ распространяются сейчас под лицензией GPL и под ее «ослабленным» вариантом — LGPL (вариант лицензии, специально созданный на тот случай, если автор библиотеки решит, что определенная степень совместимости с проприетарным софтом отвечает его интересам).

Не все начинания FSF были столь успешными. GNU Free Documentation License (GFDL) — это неряшливая реализация ненужной функциональности. В общих чертах, GFDL — лицензия, созданная с расчетом на ее применение к толстым «Руководствам пользователя» классического «мэйнфреймного» стиля — исчерпывающей документации на сложные программные системы. К книгам, которые чаще будут издаваться и читаться в бумажном виде, чем в машиночитаемом. Соответственно, основные усилия были потрачены на выстраивание предельно допустимого компромисса с интересами книгоиздателей, с одной стороны, и на защиту от их возможных недобросовестных уловок — с другой. Отсюда — причудливое разделение на прозрачные (transparent) и непрозрачные (opaque) форматы, мелочный подсчет максимального числа допустимых бумажных копий для разных форм распространения, детально прописанные требования к содержанию обложек документов и прочие обременительные условия.

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

Впрочем, следует отметить, что из-за всеобщей нелюбви к GFDL ее критика является популярной стартовой площадкой для атаки на копилефт как таковой. Разговоры о «недостаточной свободе» GPL сейчас, через два десятилетия после ее появления, мало кем воспринимаются всерьез. А вот те же самые претензии к тем же самым словам, но — взятым из текста GFDL вместо GPL, порой встречают активную народную поддержку.

Копилефт — условие, требующее, чтобы всякое дальнейшее распространение кода свободной программы, а также дополнений к ней шло на тех же условиях, на которых она была получена, в частности — чтобы исходный код программы оставался доступен. Классический пример — GNU GPL. Но существуют и другие формулировки копилефта.

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

Если копилефтная и пермиссивная лицензия совместимы (например, GPL и BSD), то объединенный код распространяется на условиях копилефтной лицензии.

Другим примером «экстремальной» свободной лицензии является QPL (Q Public License).

QPL была придумана в 1998 году фирмой TrollTech, когда та решила привести условия распространения своей библиотеки виджетов Qt в соответствие с критериями свободного софта. Для проприетарного использования библиотека продается за большие деньги, и TrollTech хотела поставить такие условия распространения, которые были бы наиболее благоприятны для ее бизнеса.

Для самой TrollTech усилия оказались потраченными напрасно — после двух лет горячих споров, в 2000 году, свободная версия Qt была лицензирована под GPL. Ожидаемые преимущества QPL для коммерции, как оказалось, не перевешивали неудобств и плохой репутации от GPL-несовместимой лицензии. Сейчас под QPL распространяются лишь несколько незначительных программ. Однако QPL оказала большое влияние на развитие идеологии свободного софта, на представления о том, какие нормы может содержать свободная лицензия.

QPL — асимметричная лицензия. Права Первоначального Разработчика и права разработчика вторичного, лицензиата, различны. Первый может пользоваться кодом — в том числе и кодом второго разработчика — как угодно, в том числе и выпуская проприетарные версии программы. Второй ограничен лицензией. Первый может потребовать копию софта, который разрабатывает второй, — и второй обязан его предоставить. Из-за асимметричности QPL нельзя отнести ни к пермиссивным, ни к копилефтным: Первоначальному Разработчику она предоставляет неограниченные права, остальным — только голодный минимум.

Другой характерной чертой QPL является patch clause — требование распространять все модификации исходного кода отдельно от первоначальной программы, исключительно в виде патчей. В принципе, это было не ново — уже TEX распространялся на похожих условиях. Но многие программисты впервые встретили такую конструкцию именно в QPL.

Особняком стоит проект Creative Commons, созданный профессором права Лоуренсом Лессигом со товарищи (Lawrence Lessig). С точки зрения практики свободного софта, да и софта вообще, проект этот — жутчайший бардак. Creative Commons уже сочинили в общей сложности несколько десятков разных публичных лицензий, по большей части несовместимых друг с другом, причем многие из них заведомо не удовлетворяют требованиям свободного софта. Мало того, каждой из этих лицензий предполагается делать еще «национальную адаптацию» для десятков стран, и эти варианты тоже несовместимы.

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

Лицензии Сreative Commons (СС) организованы в виде этакого детского конструктора, в котором автор может подобрать подходящие ему условия распространения из стандартных деталей. Каждая деталька обозначена суффиксом в имени лицензии. Так, -NC (NonCommercial) означает, что допускается только некоммерческое распространение, -SA (ShareAlike) — что в лицензии присутствует копилефт, -BY — что должна сохраняться указанная автором манера attribution, а -ND (NoDerivatives) запрещает создание новых произведений на основе данного.

Очень симпатичным изобретением Creative Commons является система пиктограмм, позволяющая лаконично и наглядно отметить произведение как распространяемое под той или иной CC-лицензией. На первый взгляд это выглядит детской игрой по сравнению с тяжеловесным «легалезе» софтверных лицензий, но, как выяснилось недавно[creativecommons.org/weblog/entry/5823], суды, по крайне мере европейские, вполне способны понять и принять условия этой игры. (Многие иллюстрации к этой статье выпущены именно под лицензиями CC. — И.Щ.)

Другим любопытным, но малоизвестным проектом, поддерживаемым Creative Commons, является Founders’ Copyright — копирайт отцов-основателей. Суть его в том, что автор добровольно отказывается от полагающегося ему по современному закону огромного срока копирайта, оставляя себе только тот срок, который существовал в США в начале XIX века, — четырнадцать лет.

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

Впрочем, стоит отметить, что концепцию Founders’ Copyright поддержал и взял на вооружение издатель-гуманист Тим О’Рейли.

Понятие свободного софта ввел в 1980-х годах Ричард Столлмен. Перефразируя Рузвельта, он заявил, что каждый пользователь программы должен иметь четыре свободы: право свободно запускать, распространять, изучать и улучшать программу. Мало-помалу эти права конкретизировались, и наконец в 1996-м было сформулировано довольно подробное определение свободного софта, сокращенно FSD (Free Software Definition).

Примерно в то же время свое определение свободного софта формулирует Проект Дебиан. Создатель Debian Free Software Guidelines (DFSG) Брюс Перенс (Bruce Perens) рассматривал DFSG как другое определение того же самого явления, о котором говорил Столлмен. В отличие от FSD, это определение оперировало не социальными и этическими, а формально-юридическими понятиями, что облегчало классификацию запутанных софтверных лицензий — задачу, практически стоявшую перед Дебианом. Однако этот же подход создает простор для схоластических построений, в которых легко заблудиться. В последние годы разработчики, выступавшие от имени Проекта Дебиан, порой высказывали довольно странные суждения по поводу свободы-несвободы конкретных лицензий, и доверие к ним, по крайне мере мое, сильно упало. Однако сами DFSG остаются общепризнанными критериями для оценки лицензий.

Позднее, при участии того же Брюса Перенса, было сформулировано Open Source Definition[www.opensource.org/docs/definition.php] (OSD) — определение софта с открытыми исходными текстами. Первая версия OSD представляла собой DFSG, в которых были удалены упоминания о Проекте Дебиан. Но их дальнейшие уточнения и толкования пошли в совершенно разные стороны, так что теперь эти определения отличаются и текстуально, и идеологически. В отличие от FSF, сформулировавшего критерии, но не спешащего предлагать себя на роль судьи, и от Дебиана, оценивающего свободу не вообще лицензии, а каждой конкретной программы в отдельности, OSI (Open Source Initiative) ведет тщательный учет лицензий, которые она официально признала «достаточно Open Source». Такие лицензии называются OSI-approved [Список таких лицензий].

Terralab.ru: Железный поток