David Chisnall бросает критический взгляд на GNU GPL и спрашивает, приносят ли она больше вреда, чем пользы для движения Free Software.

В 1985, была сформирована организация Free Software Foundation (FSF) с целью продвижения программной свободы, как определено этими четырьмя свободами:

0. Свобода выполнить программу, с любой целью.

1. Свобода изучения того, как программа работает, и адаптации к своим нуждам.

2. Свобода распространения копий, чтобы помочь своему соседу.

3. Свобода улучшить программу, и выпустить свои усовершенствования (и модифицированные версии в целом) для всех, так, чтобы принести пользу всему сообществу.

Одним из инструментов, используемых для достижения этой цели, является лицензия GPL. Оглядываясь назад, был ли GPL помощью или помехой? И продолжит ли быть помощью или помехой в будущем?

История успеха GPL

Вебсайт FSF указывает на определенный экземпляр GPL, чтобы вынудить компанию открыть ее исходные коды. Компания в этом примере — NeXT (нынче Apple), и исходный код — фронт-энд Objective-C для GCC. Но что произошло в действительности?

Когда NeXT купила права на Objective-C, она унаследовала две части технологии. Одна была препроцессором — довольно простой программой, которая превращала Objective-C в чистый C. Другой была runtime библиотека, которая обрабатывала все динамические запросы, загрузку модуля, и другие элементы, требуемые для полноценной среды Objective-C. У препроцессорного подхода были некоторые ограничения, не последним из которых была трудность в отладке, таким образом NeXT решила переместить препроцессор в компилятор.

В то же время, используемым компилятором C был GCC, который был выпущен под GPL. Чтобы избежать ограничений этого кода, NeXT предоставила свой фронт-энд как библиотеку, которую конечные пользователи слинкуют с GCC, таким образом избегая GPL (которая применима только к распространению программного обеспечения, не касаясь того, как вы используете его). Этот небольшой юридический маневр не работал, однако, NeXT была вынужден выпустить код.

Заметка

Фактически, эта уловка, возможно, сработала бы, если NeXT могла бы показать, что ее фронт-энд не использовал результаты работы GCC (проблемно, потому что он использовал), или если бы NeXT не распространяла GCC (который она распространяла).

Помните, что реализация Objective-C состоит из двух частей: компилятор и библиотека. NeXT была обязана выпустить код своего компилятора, исключая runtime-библиотеку. Как тот, кто работал над компилятором Objective-C и двумя runtime-библиотеками Objective-C, я могу сказать с некоторой уверенностью, что NeXT не могла рассчитывать на лучший исход в этой ситуации: для диалектов Objective-C той эпохи библиотека намного более сложна чем компилятор.

Вместо того, чтобы признать, что у это был ничего не стоящий кусочек кода, Проект GNU написал свою собственную библиотеку для Objective-C — и это — то, когда начались самые интересные вещи. Библиотека от GNU не был настоящей заменой для библиотеки от NeXT, и GNU необходимо было изменить компилятор для поддержки новой библиотеки. Модификация задействовала множество операторов #ifdef файле поддержки Objective-C. Конечно, NeXT не имела никакого интереса в поддержке библиотеки от GNU, и поэтому не потрудилась импортировать эти изменения.

Периодически, NeXT выпускала бы новую версию своего форка GCC, и основные разработчики пытались бы бэкпортить свои изменения в основную ветку. Когда Apple поглотила NeXT, разработчики Apple продолжали работать над GCC, добавляя усовершенствования, такие как улучшенная поддержка SIMD, чтобы воспользоваться преимуществами модулей AltiVec на процессорах PowerPC, которые поставляла Apple. Разработчики также продолжили добавлять фичи к Objective-C. Поскольку ветка Apple поддерживала единственную runtime-библиотеку, не было никакого четкого разделения между runtime-специфичными и runtime-независимыми частями, и таким образом ветвь GNU быстро отстала.

Тем не менее, история на этом не заканчивается. Позже, Apple захотела более тесно интегрировать компилятор со своей IDE. Одна из хороших вещей в Visual Studio — то, что она использует тот же самый синтаксический анализатор и семантический анализатор для подсветки синтаксиса и сообщений об ошибках, что и для генерации кода, позволяя получить намного лучшую обратную связь, чем от полностью отдельных двух редакторов. К несчастью для Apple, GPL требовала или открыть исходный код XCode или переписать GCC. Apple выбрала последнее.

К счастью, Apple не нужно было начинать на пустом месте, а вместо этого она смогла нанять ведущего разработчика LLVM Compiler Infrastructure Project, инфраструктуры компилятора с BSD-лицензией, и усадить его за работу. Результатом было создание нового проекта, clang, чтобы создать новый фронт-энд для LLVM, который поддерживал C, Objective-C, и C++. Этот фронт-энд в настоящее время поддерживает библиотеку GNU и две библиотекиApple, и поддерживает несколько особенностей — таких как быстрое перечисление и частичная поддержка объявленных свойств — что GCC не делает, даже используя библиотеку GNU.

Clang не единственный фронт-энд Objective-C для LLVM, хотя единственный, основанный на GCC. К сожалению для людей, использующих не-Apple платформы, он основан на эппловской ветке GCC, и поэтому поддерживает только Objective-C на Darwin. Этот фронт-энд покрывается GPL, тогда как тот, который имеет лучшую поддержку библиотеки GNU, идет под BSD-лицензией.

Какой урок мы должны извлечь из этой истории?

Во-первых, мы узнаем, что вы не обязательно получаете хорошие результаты вследствие того, что вы принуждаете людей делать что-то. Код Objective-C от NeXT был внесен в GCC скрепя сердце, и никогда толком не поддерживался. Напротив, код Apple, внесенный в clang, был написан с понятным уровнем абстракции и позволяет легко поддерживать новые runtime-библиотеки. Это не требовалось Apple, которая запустила проект и поэтому она могла делать с ним все, что пожелает. Так как Apple охотно привлекала сообщество, то результат оказался наилучшим для всех.

Вторая вещь, которую нужно помнить — то, что иногда наличие чьего-либо кода фактически не является хорошей вещью. Код Objective-C в GCC — жуткое, нечитабельное месиво. Objective-C — маленький язык, и команда GCC, возможно, могла бы объединить его со своим собственным фронт-эндом самое большое через несколько недель. Если бы команда сделала это, то они вероятно спроектировали бы это так, чтобы поддерживать множественные библиотеки с самого начала, и закончили бы в итоге кое с чем намного более удобным в сопровождении.

Google для linux

В течение некоторого времени, Google был образцовым представителем сообщества свободного программного обеспечения. Вся инфраструктура Google встроена вокруг свободного ПО, и многое Google возвращает в linux. Это можно считать успехом для GPL.

Слон в этой посудной лавочке — файловая система Google, высокомасштабируемая распределенная файловая система, используемая в linux. Google опубликовало ее? Нет. Но ведь GPL требует этого? В конце концов, разве не это было целью — заставить людей, которые извлекают выгоду из свободного ПО и улучшают его, поделиться своми усовершенствованиями с сообществом?

Фактически, нет. Как я упоминал ранее, GPL — дистрибутивная лицензия, не лицензия использования. Она приходит в действие тогда, когда вы распространяете код. Если вы используете это только для себя, вы не должны распространять свои изменения ни для кого.

Однако, Google внесла справедливый вклад кода в linux. Почему? Поскольку это более дешево для парней из Google — иметь этот код поддерживаемым в актуальном состоянии, чем хранить постоянно растущий локальный набор патчей для вещей, которые не являются ключевыми в их бизнесе. Каждая компания, которая использует свободное ПО, должна сделать этот рассчет. Содержание изменений в секрете влечет за собой увеличение затрат (таких как дополнительная работа по обслуживанию, когда кто-то вносит некоторые изменения, которые ломают ваши патчи) и выгоду (коммерческое преимущество, которое вы получаете от того, что будете единственным с такой ключевой особенностью). Если расходы перевесят выгоду, то тогда любая грамотно управляемая компания выпустит свой код, независимо от того, требует лицензия этого или нет.

Это объясняет, почему Yahoo! нанимала людей на полный рабочий день для работы над FreeBSD и внесла большую часть изменений. Yahoo! использовала FreeBSD внутри компании, и нуждалась в добавлении определенных особенностей и исправлении ошибок. Как и GPL, лицензия BSD применяется только при распространении, но даже если бы люди из Yahoo! распространяли код, то они не должны были бы выпускать свои изменения. Только они сделали это, потому что у них было хорошее деловое чутье.

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

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

Кто не с нами, тот против нас

FSF делает два набора лицензий для свободного ПО — один, это GPL-совместимые, и другой — GPL-несовместимые. Это — интересная позиция, потому что большинство «GPL-несовместимых» лицензий — пофайловые, позволяют вам объединить их с кодом под любой другой лицензией. GPL устанавливает дополнительные ограничения для кода, и поэтому несовместима. Вы можете легко объединить код под лицензиями APSL, MPL, CDDL, Apache, и BSD в одном проекте, но вы можете объединить только одну из них с кодом GPLv2.

Даже FSF не удатется разрулить все это правильно. Версия 3 LGPL, например, несовместима с версией 2 GPL. Это недавно вызвало проблему для нескольких проектов библиотеки GNU, которые хотели перейти на LGPLv3, но использовались другими проектами, которые были GPLv2-only.

Официальная позиция — то, что проекты не должны быть v2-only, они должны всегда быть v2-or-later. Я позволю вам попытаться убедить linux переключиться. О, и удачи, также, с читателями PDF; единственные читалки формата PDF с открытыми исходниками в настоящее время основаны на xpdf, который является GPLv2-only. FSF отчаянно пытается написать новую библиотеку PDF, чтобы обойти это ограничение, и лицензирует ее как GPLv3-or-later.

Это отношение понятно. Ричард Столлман полагает, что написание проприетарного программного обеспечения является антиобщественным. К сожалению, такой образ мышления приводит к потере возможностей. GPL не дает вам выбора в написании некоторого проприетарного программного обеспечения и содействия его свободному программному обеспечению. Если Вы хотите использовать некоторый код под GPL, у вас должен быть под GPL весь ваш проект (что иногда невозможно из-за сторонних требований).

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

Я чувствую себя нарушенным!

GPL представляет собой несколько страниц юридического жаргона. Я читал ее несколько раз, и все еще должен уточнять определенные вещи, и у меня вероятно есть лучшее знание закона об авторском праве чем у среднего разработчика. Один из главных доводов в пользу свободного ПО — то, что нет никакой стоимости сопровождения лицензий. Любая часть свободного ПО идет со свободами FSF 0 и 2, означая, что Вы можете использовать это и копировать это столько, сколько хотите. Такой порядок резко упрощает аудит, и является огромным выигрышем для крупных компаний.

Поскольку GPL — лицензия свободного программного обеспечения, здесь применяется тот же самый принцип, верно? Да, пока вы распространяете с исходниками. Есть простой способ нарушить версию 2 GPL, в выполениии которого, как я полагаю, виновна по крайней мере половина читателей этой статьи. Возьмите исходный текст своего любимого проекта GPLv2, скомпилируйте его, и дайте другу бинарный файл. Упс — вы только что совершили нарушение авторского права. GPLv2 требует, чтобы вы предоставили или исходники или предложение в письменной форме (действующее в течение трех лет) по их предоставлению (см. пункт 3).

Это вообще полезным принимать во внимание, при компиляции программного обеспечения для ваших друзей, которые не особенно разбираются в компьютерах. У них нет никакого интереса к исходникам, но GPL требует, чтобы вы дали им исходники (они поблагодарят вас за них, когда загрузят объединенный пакет по мобильному подключению с оплатой по трафику), или дали им письменное предложение относительно исходников. Если вы выбираете второй вариант, вы должны иметь в наличии копию источника в течение трех лет — и не забываете, что это должна быть именно та версия, использовавшаяся для сборки бинарника.

Это — только индивидуальная проблема, так? Ну, не совсем. Вообразите этот разговор, происходящий между двумя служащими различных компаний:

«Я не могу открыть тот файл, который вы послали мне.»

«Ох, извините. Я вышлю вам программу, которой я пользовался для создания файла — она бесплатная.»

«Отлично, спасибо.»

Звучит разумно? Вариации этого же разговора широко распространены, когда рассматриваемое программное обеспечение является проприетарным, и его копирование незаконно, а для свободного ПО подобный разговор, вероятно, будет свойственнен еще больше.

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

Конечно, никакой разумный разработчик не предъявил бы иск за этот вид нарушения GPL. К сожалению, нет никакого простого способа проверить, разумны ли разработчики конкретной программы.

Связи, Каналы, Уловки

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

Если вы достаточно изобретательны, то весьма просто обходить ограничения, вводимые GPL. С веб-службами и веб-приложениями, получающими все большее распространение, вы даже не должны сильно напрягаться. Вы можете внедрить так много GPL кода, как вы захотите в свое проприетарное веб-приложение или службу, и никто не сможет получить код, потому что вы не распространяете бинарник — вы просто позволяете людям использовать его.

Affero GPL пытается обратиться к этой проблеме, требуя, чтобы вы оставляли на месте любые существующие ссылки «загрузить исходники». Конечно, это требование сделало Affero GPL несовместимым с GPLv2 (v3, имеет специальное исключение). Поскольку это требование ограничивает модификации, которые вы можете сделать в коде, оно нарушает четыре свободы (хотя это не мешает FSF рекомендовать его).

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

источник