Лидеры проектов GnuTLS, grep и sed выходят из проекта GNU в знак несогласия с политикой Фонда СПО

Никос Маврогианнопулос (Nikos Mavrogiannopoulos), создатель, ключевой разработчик и лидер проекта GnuTLS, объявил о выводе GnuTLS из-под контроля Фонда СПО и проекта GNU. Разработка GnuTLS перемещена из инфраструктуры GNU, при передаче кода проекту больше не требуется подписание соглашения о передаче имущественных прав Фонду СПО.

В качестве причины называется несогласие с системой принятия решений и действиями Фонда СПО, притом, что Никос по-прежнему остаётся сторонником идей, продвигаемых Фондом СПО. Указывается на то, что в проекте GNU отсутствует возможность влияния на принятие решений, все решения единолично исходят от Столлмана, а не принимаются в ходе дискуссий, учитывающих различные мнения. Поэтому Никос устал от того, что его участие в проекте ограничивается только написанием кода, без возможности выражения и обсуждения различных точек зрения.

В ответ на шаг Никоса Ричард Столлман заявил, что GnuTLS не личная разработка Никоса, а проект, развиваемый сообществом, поэтому так просто увести его из-под контроля Фонда СПО не получится. Несмотря на все свои заслуги, Никос добровольно согласился управлять разработкой и развивать GnuTLS под эгидой проекта GNU, на что проектом GNU ему были даны соответствующие полномочия. Никос волен основать форк под другим именем и продолжить его развитие, или прекратить своё участие в разработке, но отобрать проект GNU невозможно. Так как при передаче кода разработчики подписывают соглашение с Фондом СПО, Фонд является владельцем имущественных прав на код и использует эти права чтобы гарантировать, что проект всегда останется свободным. Если Никос передумает, Ричард выразил готовность обсудить возвращение к сотрудничеству с проектом GNU.

После этого Никос выразил сожаление о том, что передал свои имущественные права Фонду СПО и указал на готовность сменить имя проекта GnuTLS и продолжить развитие под новым именем, если того потребует Фонд СПО. Столлман ответил, что проект остаётся GNU и он не может его просто переименовать (но может создать отдельный форк, не трогая текущий проект GnuTLS). Несмотря на то, что Никос является автором большей части кода GnuTLS, имущественные права принадлежат FSF, поэтому даже при создании форка Никос не сможет изменить условия его распространения, т.е. невозможно поменять лицензию без согласия Фонда СПО.

После этого ряд разработчиков выразили несогласие с позицией Столлмана. Paolo Bonzini, мэйнтейнер проектов GNU sed и GNU grep, заявил об уходе со своего поста и прекращении участия в разработке (будет продолжено только участие в проектах GCC и GNU Smalltalk). Ниже представлен перевод объяснения причин такого решения:

Мне неприятно это объявлять, но я отказываюсь от ведения проектов GNU sed (чем я занимался 8 лет) и GNU grep (после трёх лет). Я также выхожу из участия в проектах Autoconf, Automake, Libtool, gnulib, libsigsegv и bison.

Для других участников проекта GNU и для некоторых внешних обозревателей связь между этим объявлением и заметкой Никоса Маврогианнопулоса не станет неожиданностью. Как и Никос, я так же сильно, как и всегда, всецело поддерживаю идеи движения FSF и я благодарен сотрудникам FSF за поддержку, оказанную мне с момента моего вступления в проект GNU в 1999 году. Однако так же, как и он, я не согласен с некоторыми решениями FSF и Ричарда Столлмана.

Всё сводится к следующим трём проблемам:

  • Если говорить прямо, то единственный способ для проекта GNU быть среди лидеров в своей области — это игнорирование любых рекомендаций со стороны FSF. Я не думаю, что Столлман был вовлечён в решение GCC перейти с C на C++ или тогда, когда GNOME выбрали JavaScript в качестве языка для расширения функциональности GNOME-shell.

    В некоторых ситуациях, принятие единоличных решений может оказаться полезным. Например, вероятно, разнородным группам разработчиков, таким, как группы мэйнтейнеров GNU, невозможно договориться об использовании единых стандартов кодирования на языке C++. Однако всё, что в этом случае мог предложить Ричард, — это: «Мы всё ещё предпочитаем C, а не C++ — ибо последний настолько уродлив». В результате этого, соглашения о кодировании в GNU не обновлялись много лет и стали полностью устаревшими.

    Эта проблема касается не только языков программирования. Так, например, проект libabc, который должен был быть разработан в рамках GNU, по факту был создан отдельно.

    В стандартах программирования GNU нет ни слова про написание безопасного кода.

  • 2) Проект GNU делает очень мало для организации FSF и наоборот. Из-за огромного успеха открытого ПО и с тех пор, как появился манифест GNU, распространение СПО более не является эксклюзивным правом GNU — и это хорошая весть. С другой стороны, FSF ничего не делает для того, чтобы подчеркнуть важность бренда GNU. Такие проекты, как Gnash, который по идее должен был получать непрерывное финансирование со стороны FSF, постоянно имеет с ним проблемы, несмотря на то, что он находится в списке высокоприоритетных проектов FSF. Другие проекты в этом списке просто отсутствуют, потому что они требуют несколько человеко-лет для разработки, но люди, которые готовы их реализовать, не будут делать это на свои собственные деньги.

    Этого абсолютно недостаточно, чтобы сохранить значимость в мире, где свободное ПО путают с "open source" (ПО с открытым исходным кодом) и большинство людей на самом деле не заботится о свободе пользователей.

  • 3) Прикрепление метки GNU к приложению уже абсолютно не является показателем привлекательности. Люди ожидают, что GNU проект будет медленным как черепаха, вместо того, чтобы быть быстрым как лань, и, возможно, они правы. Такие проекты, как LLVM, достигли большой значимости из-за медлительности в принятии решений со стороны GNU, а такие компании, как Apple, получают похвалу, даже если они принимают участие в этих проектах, чтобы избежать проблем с лицензией GPLv3.

    Быть частью GNU — это уже не эмблема технического превосходства. «Если это плохо реализовано в Unix, не стесняйтесь заменить это на что-то совершенно иное и более совершенное» . Является ли это истиной в текущей ситуации с GNU?

©  OpenNet