Материал из Linuxformat.

LXFИнтервью Брэдли Кун

Блюститель

Корреспондент Linux Format встретился с Брэдли Куном, одним из разработчиков GPLv3. Брэдли считает, что плодить лишние лицензии ни к чему...

Бывший директор FSF, известный защитник GPL, автор пункта про Affero, Perl-программист и акула покера... мы знаем Брэдли Куна [Bradley Kuhn] в основном по его работе над лицензиями свободного ПО. Приняв участие в доводке текста GPLv3, Кун продолжает пресекать всяческие нарушения GPl. Не так давно он помог нескольким крупным проектам свободного ПО сформировать некоммерческие организации, миновав многочисленные бюрократические рогатки. Мы встретились с ним, чтобы обсудить процесс внедрения GPLv3, лицензионные исключения и важность взаимного соответствия лицензий...

• Linux Format: Новейшая статистика Google показывает, что внедрение GPLv3 ускоряется, а вот у LGPLv3 наблюдается спад. Что вы думаете по этому поводу?

Брэдли Кун (БК): Меня это не очень беспокоит. Одни люди пользуются LGPL, другие – лицензией Apache. Причина в том, что «приватизировать» код Apache меньше желающих. Даже если лицензия позволяет такое сделать, не каждому этого хочется. Я думаю, что с кодом Apache произошло вот что: люди понимают ценность коллективной работы на условиях этой лицензии, поэтому не хотят отгораживаться от мира. Для программистов LGPL имеет меньшую ценность: они не видят проблем, которые она призвана устранить. Есть много методов реализации принципа copyleft, и мы, те, кто работает в сфере «копилефта», не считаем, что наш путь единственно верный. Мы выбираем «копилефт» потому, что нам нравится юридическая защита свободного ПО. Но есть ведь и другие методы: сообщества BSD и Apache оказывают социальное давление по освобождению кода – и это работает! Я хорошо понимаю людей, избравших такую стратегию.

• LXF: Нам кажется, некоторые проекты вообще никогда не перейдут на GPLv3 — например, ядро Linux.

БК: Вполне возможно. Но суждение по Linux еще не вынесено. Полагаю, сообщество и сам Линус [Торвальдс] все еще обдумывают этот вопрос. Да, некоторые проекты вряд ли переключатся. Но происходит любопытная вещь: ведь было время, когда GPLv2 считалась проблемной, и люди не хотели переходить на нее. Сам Линус говорил, что, если бы вернуть время вспять, он ни за что не стал бы трогать GPL. Работая над GPLv3, мы предчувствовали, что ее выпуск приведет к проявлению так называемого синдрома идеализации GPLv2. То есть те же самые люди, которым раньше не нравилась GPLv2, вдруг решат, что лучшей лицензии никогда и не было – а вот у GPLv3 сплошные проблемы. Я понимаю, что людям, не варившимся в гуще работы над GPLv3, нужно время на обдумывание. Не хочу, чтобы решения о смене лицензии принимались поспешно, без тщательной оценки последствий и подробного обсуждения в сообществе.

• LXF: Вы считаете, что люди должны хорошенько поразмыслить над выбором лицензии — это понятно. Но согласитесь, что процесс выработки GPLv3 проходил весьма гладко.

БК: Не совсем. Многое приходилось увязывать с законодательством, а это всегда нелегко. Я недоволен тем, что пункт Affero пришлось выделить в отдельную лицензию. Бенджамин Мако Хилл [Benjamin Mako Hill] и я, вероятно, дольше всех пытались удержать поправку в GPL – как и было задумано с самого начала.

Начиная разработку GPLv3 в 2002 году, Эбен Моглен [Eben Moglen], Ричард Столлмен [Richard Stallman] и я держали совет. Основным вопросом был именно ввод пункта Affero. И мне кажется – а я занимался этим пунктом с первого дня – что он вошел бы в лицензию, так было задумано. Но из-за мощного противодействия многих людей, таких как Крис ДиБона [Chris DiBona] из Google, было решено составить отдельную лицензию и предоставить программистам самим выбирать, нужна ли она им. Элегантное решение. Я-то хотел сделать иначе, но и такой вариант меня устраивает: хакеры сами решили судьбу пункта Affero.

• LXF: Добавление и удаление пунктов немного сбивает с толку, особенно если учесть, что в рамках GPLv3 программисты могут добавлять и удалять их сами.

БК: Типы поправок, которые можно добавлять – это исключения, а не добавочные ограничения. Структура исключений в GPLv3 полезна – они были всегда, их добавляли и в GPLv2, даже в кодовую базу GNU от FSF. Представление о том, что существует только четыре способа лицензирования – GPL, LGPL, Apache и BSD – не соответствует практике. Можно взять зазор между лицензиями (например, между GPL и LGPL) и несколько сократить его. Вы можете сказать: «Я хочу разрешить вещи, допустимые в рамках LGPL, но не все. Но мне не надо и “чистой” GPL: пусть будет нечто посредине». Применение исключений позволяет задать формат лицензирования с хирургической точностью.

• LXF: Но, принявшись работать скальпелем, не угодим ли мы в итоге в стан лицензий Creative Commons?

БК: Не думаю, что это приведет к такому виду размножения лицензий, поскольку исключениями ведь можно и не пользоваться. Если вы смешиваете один продукт с исключениями, а другой – без них, исключения не действуют. Поэтому всегда есть общая база, к которой можно стремиться. При другом способе размножения лицензий возникает серия несовместимых документов, и можно зайти в тупик. В данном случае все лицензии сводятся к GPl. Я хотел бы подчеркнуть ее отличие от Creative Commons: это ортогональное пространство, поскольку они имеют дело не только с ПО. Они превосходно ориентируются в своем пространстве, и я рад, что они переняли принципы свободного ПО и распространяют их в других сферах.

• LXF: Как вы считаете, хорошо ли, что GPLv3 теперь совместима с лицензией Apache 2.0?

БК: Теперь можно взять код Apache 2.0, скомбинировать его с кодом GPLv3 – и все будет нормально. Я думаю, это большой успех. Ирония заключается в том, что было время, когда многие предпочитали множить лицензии. Инициатива Open Source Initiative с момента зарождения старалась привлечь как можно больше людей под знамена открытого ПО и под открытые/свободные лицензии. Хорошо, что теперь они выступают против размножения лицензий. В значительной мере этот процесс заключается в расчистке сделанного ранее. Я возражал против размножения лицензий еще в 2001 году. Для пользы дела достаточно иметь минимальный комплект.