Вы, наверное, никогда не слышали о недавно умершем Джиме Вайрихе [Jim Weirich] или его программах. Но вы почти наверняка пользовались приложениями, построенными на основе его работы.
Вайрих помог создать несколько ключевых инструментов для Ruby, популярного языка программирования, код на котором написан для таких сайтов, как Hulu, Kickstarter, Twitter, и огромного числа других. Исходники его кода были открытыми, что означает, что использовать и изменять их могли все желающие. «Он был плодовитым членом западного сообщества Ruby», — говорит Джастин Сёрлс [Justin Searls], разработчик Ruby и сооснователь компании, разрабатывающей ПО, Test Double.
Когда Вайрих умер в 2014-м, Сёрлс заметил, что уже никто не поддерживает один из инструментов Вайриха для проверки софта. Это означало, что никто не будет одобрять изменения, если другие разработчики пришлют в проект исправления багов, патчи для безопасности или другие улучшения. Любые тесты, основывающиеся на этом инструменте, в итоге будут проваливаться, поскольку код устареет и станет несовместимым с новыми технологиями.
Этот случай отражает растущее беспокойство в сообществе ПО с открытым кодом. Что случается с кодом после смерти программиста? Уже написано много статей по поводу того, что случится в соцсетях с социальными учётными записями после смерти пользователя. Но для программистов эта проблема была не такой острой. Частично потому, что большая часть компаний и правительств полагается на коммерческое ПО, которое поддерживают команды людей. Но сегодня больше программ полагается на такое малоизвестное, но критически важное ПО, какое делал Вайрих.
Некоторые проекты с открытым кодом хорошо известны — ОС Linux или платформа искусственного интеллекта от Google TensorFlow. Но каждый такой проект зависит от более мелких библиотек с открытым кодом. А эти библиотеки зависят от других. В результате появляется сложная, по большей части скрытая сеть программных зависимостей.
Это может привести к большим проблемам, как случилось в 2014 году с уязвимостью в безопасности, получившей название Heartbleed, обнаруженной в OpenSSL — программе с исходным кодом, используемой практически всеми веб-сайтами, обрабатывающими платежи с банковских карт. Это ПО поставляется с большинством версий Linux, но его поддерживала небольшая команда добровольцев, у которых не было времени или ресурсов для всестороннего аудита безопасности. Вскоре после такого фиаско проблема с безопасностью была обнаружена в другой часто используемой программе с открытым кодом, Bash, из-за чего бесчисленное количество веб-серверов и других устройств оказались уязвимыми для атак.
Наверняка существует ещё больше нераскрытых уязвимостей. Группа людей, анализирующих связи между проектами ПО, Libraries.io, обнаружила более 2400 библиотек с открытым кодом, используемых по меньшей мере в 1000 других программ, и не получавших должного внимания со стороны open-source сообщества.
И недостатки в безопасности — лишь часть проблемы. Если библиотеки ПО не обновлять, они могут перестать работать с новыми программами. Это значит, что приложение, зависящее от устаревшей библиотеки, может перестать работать после обновления другого ПО. Когда разработчик умирает или бросает проект, могут пострадать все, кто зависят от этого ПО. В прошлом году, когда программист Азер Кочулу [Azer Koculu] удалил крохотную библиотеку Leftpad из интернета [только не Leftpad, а left-pad, и не из интернета, а из системы хранения пакетов npm / прим. перев.], что привело к расходящемуся эффекту, добавившему головной боли поддержке Facebook, Netflix и других проектов.
Фактор автобуса
Чем меньшее число людей владеет частью кода, тем больше риск, что он останется без владельца. У разработчиков есть даже мрачный термин для таких случаев — фактор автобуса, означающий количество людей, которых должен сбить автобус перед тем, как проект некому будет поддерживать. Libraries.io определили порядка 3000 библиотек с открытым кодом, используемых во многих других программах, у которых число поддерживающих их программистов очень мало.
Осиротевшие проекты — это риск использования ПО с открытым кодом, хотя и коммерческие производители ПО могут оставить пользователя в таком же положении, перестав поддерживать или обновлять старые программы. В некоторых случаях ответственные программисты усыновляют осиротевшие проекты с открытым кодом.
Это сделал Сёрлс с одним из проектов Вайриха. Самые популярные его проекты на момент его смерти управлялись им совместно с кем-то ещё. Но Сёрлс нашёл один проект, инструмент для тестирования Rspec-Given, который никому не достался, и захотел взять на себя ответственность за его обновление. Но он столкнулся с некоторыми трудностями.
Rspec-Given обитал на популярном сайте для совместной работы и размещения кода GitHub, где расположено порядка 67 млн проектов. Страница Вайриха для Rspec-Given на GitHub была основным местом для того, чтобы другие люди могли сообщать об ошибках или предлагать помощь по улучшению кода. Но GitHub не хотел давать Сёрсу управление страницей, поскольку Вайрих не передал ему таких прав перед смертью. Поэтому Сёрлсу пришлось создать новую копию кода и разместить его в другом месте. Также ему пришлось уговорить операторов Ruby Gems, системы управления пакетами, распространяющей код, использовать его версию Rspec-Given вместо версии Вайнриха, чтобы у всех пользователей был доступ к изменениям, проделанным Сёрлсом. GitHub отказался комментировать свои правила по передаче управления проектами.
Это решило возможные проблемы, связанные с Rspec-Given, но открыло Сёрлсу глаза на то, как много всего может пойти не так. «Легко относиться к проектам с открытым кодом как к чисто техническому явлению, — говорит Сёрлс. — Но как только что-то взлетает, если от него зависит работа сотен других людей, оно становится ещё и социальным явлением».
У групп поддержки большинства систем управления пакетами есть по крайней мере один процесс передачи управления над библиотекой, но он обычно зависит от того, чтобы кто-нибудь заметил, что проект осиротел, и затем вызвался его поддерживать. «У нас нет официальных правил на этот счёт, поскольку такие проблемы не часто возникают», — говорит Иван Финикс из проекта Ruby Gems. «У нас есть экспертный совет, который решает подобные вопросы индивидуально».
Некоторые системы управления пакетами отслеживают библиотеки и отмечают широко используемые проекты, которые давно не обновлялись. Нил Бауэрс, помогающий поддерживать систему пакетов для языка программирования Perl, говорит, что иногда он ищет добровольцев для поддержки осиротевших проектов.
Триггер мертвеца
Получение контроля над Rspec-Given вдохновило Сёрлса, которому на тот момент было всего 30 лет, на написание завещания и плана передачи его проектов с открытым кодом. Разработчики могут предпринять и другие действия для обеспечения будущего своих проектов. Например, передать права какому-нибудь фонду, вроде Apache Foundation. Но многие проекты с открытым кодом часто начинаются как хобби, поэтому программисты могут не задумываться над передачей прав до тех пор, пока уже не будет поздно.
Сёрлс предлагает, чтобы GitHub и такие системы управления пакетами, как Gems, добавили себе «триггер мертвеца», позволяющий программистам автоматически передавать управление проектом или учётной записью кому-то ещё, если этот создатель не залогинивался или не вносил изменений в проект в течение определённого периода времени.
Но план передачи — это не просто открытие доступа к коду другим людям. Майкл Дротбом, взявший на себя разработку популярной математической библиотеки Matplotlib после смерти её создателя Джона Хантера в 2012-м, указывает на то, что преемникам нужно ещё и понять код. «Иногда в коде встречаются части, понятные только одному человеку, — говорит он. — Знание существует только в голове одного человека».
Это значит, что людей нужно привлекать в проект на ранней стадии, в идеале, сразу после того, как его начинают использовать другие люди, кроме разработчика. Сёрлс говорит, что у такого подхода есть ещё одно преимущество — распределение работы по поддержке проекта, помогающее избежать «выгорания» разработчика.
Комментарии (57)
artskep
04.12.2017 16:47Смешались вместе люди, кони…
КМК, если разобрать по частям:
1. Если мы говорим о возможности сопровождать код, то это зависит от лицензии. «университетские» лицензии, GPL, Apache2 — вполне позволяют сопровождать код тем, кому это надо (для GPL это вообще одна из основ на которых она построена). Если лицензия позволяет делать форк — кто-то, да сделает форк, если это надо (см. п.2)
2. Если мы говорим о том, что кто-то захочет сопровождать код — тут не opensource ни проприетарщина не даст гарантии. Сколько серьезных продуктов серьезные конторы сняли с поддержки — не перечесть. Сколько контор тупо ушли с рынка забрав с собой хорошие продукты — еще больше. Во всяком случае с opensource есть шанс, что форк возможен и кто-то захочет его поддерживать(хотя бы и контора, которой надо «для себя»), хотя, конечно есть проблема (см. п.3)
3. Контроль за репозиторием. Тут да, есть проблема, что (скажем честно) мало кто читает лицензии, смотрит на обновления и прочая и прочая. Народ доверяет репозиторию (и, как результат) человеку, которые его контролирует. И тогда малоизвестный форк может «не взлететь». Точно так же как сам репозиторий, кстати, может быть подменен/взломан/чего-там еще. Это все проблемы вечные как жизнь…
Но, прочитав еще раз заголовок, я не понимаю чем подобная проблема смерти автора для опенсорс кода отличается от смерти автора чего-нибудь еще (будь это хоть проприетарный код, хоть книга хоть картина)?
Да, со смертью Пискассо, Дали или Шишкина мы потеряли новые картины от них, а репродукции это уже «не то». Но картины никуда не делись, репродукции печатают, новые художники вдохновляются.
vesper-bot
04.12.2017 17:14+1Ну, в картинах же не ищут уязвимости, и дыра в картине не приведет к общемировому коллапсу вроде heartbleed'a. Проблема как раз в глобализации, здесь — схемы зависимостей ПО с открытым кодом от вот таких «мелочей» и багов в них.
artskep
04.12.2017 18:13Heartbleed появился, замечу, на популярном продукте. И узнали о нем ровно по этой же причине.
Пока кому-то продукт интересен — его будут поддерживать (хоть кто-то) и мониторить. Я об этом писал в п.2. Хотя единой конторы, которая бы openssl синхронизировала ЕМНИП не существует. Поэтому и пришлось делать «модный сайт», который привлек бы всех, чтобы обновиться можно было бы разом.
Глобальная зависимость — это факт. Будь это опенсорс, проприетарщина или что-то еще. С опенсорсом единственная разница — можно подсмотреть и (возможно) сделать форк и/или поправить.
Больше разницы нет и быть не может.
vassabi
04.12.2017 17:20рисование новых картин тем же человеком — это такое.
вот умение и приемы рисования, если не было у мастера учеников, — то они умирают вместе с ним.
недавно в теме про падения ракет (не помню правда в которой, их тут развелось уже больше пяти) — выяснилось, что старые профессионалы в атомной промышленности давно уже перестали обновлять документацию и вписывать все подробности. Чтобы их на пенсию не турнули и молодыми спецами не заменили.
А потом фигак — вопрос «а как это железо\процесс поддерживать?» встает в полный рост. (Не говоря уже — о модернизации, хотя бы безопасно модифицировать «по месту» становится трудновыполнимым)artskep
04.12.2017 18:31вот умение и приемы рисования, если не было у мастера учеников, — то они умирают вместе с ним
Да, это печально. Техника сфумато (которой была написана Мона Лиза), скорее всего, умерла с Леонардо да Винчи.
Но, стоит заметить, это как-то не остановило развитие живописи. Не говоря уже об изобразительном искусстве вообще.
Не стоит преувеличивать роль личности в истории.vassabi
04.12.2017 21:36ну как, ракеты тоже не перестанут летать, просто грусть-тоска, что это будет как умение строить пирамиды у египтян…
SirEdvin
04.12.2017 21:29Проблема, как уже написано, связана с тем, что большое количество проектов хостятся в собственных репозиториях, которые нельзя так просто взять и продолжить.
А также есть пакетные менеджеры, в которые проект вам тоже не так то и просто будет загрузить, если вообще возможно.
Как следствие, подхватить проект получается некому. Разве что на его обломках построить проект с новым именем, но это менее эффективно и таких проектов сразу будет по 5-6 штук, вместо одного.
Ну и странно сравнивать программный код с картинами, которые как бы не развиваются.
artskep
04.12.2017 21:34Заголовок спойлераПочему все прочитали про картины, но не читают все остальное.SirEdvin
04.12.2017 21:50Проблема пропритераного софта лежит в другой плоскости. За него вы платите, а значит, у вас есть какие-то гарантии. В случае opensource это не так, и абсолютно никаких гарантий того, что автор внезапно не забьет на пакет и что больше никто не сможет исправлять в нем проблемы у вас нет. И это проблема, которая обсуждается в статье.
Касательно доверия пакетными менеджерам, а в чем проблема? Вы доверяете пакетным репозиториям дистрибутива Linux, который вы используете? Вы доверяете исходному коду ядра, на котором он запущен? Или, если у вас винда, вы доверяете системе, которая может отправить с вашего компа что угодно и куда угодно. В современном IT безумное количество вещей строится чисто на доверии и я не вижу проблемы в конкретном пакетном менеджере. На мой взгляд, зашитые пароли в IoT куда большая проблема.
vassabi
04.12.2017 21:53Проблема пропритераного софта лежит в другой плоскости. За него вы платите, а значит, у вас есть какие-то гарантии.
Это если его делали для вас. А у массового софта (типа ворда) стоит EULA, что вы его используете на свой страх и риск и AS IS.
Во-вторых — разоряется контора, и привет всем гарантиям.
kafeman
04.12.2017 21:57За него вы платите, а значит, у вас есть какие-то гарантии.
Можете попытаться через суд вернуть стоимость лицензии. Если какая-то компания и согласится на такие риски, то это обойдется вам в over9000 денег. И это уж точно не про массовый софт.artskep
04.12.2017 22:05Отнюдь — многие могут и SLA подписать. Правда, как правило, со своим железом и, возможно, своим обслуживанием. Но да, это не для ноутбука для просмотра порнухи и котиков… Хотя, если будет спрос найдется, наверное, и предложение (может быть даже уже есть).
artskep
04.12.2017 22:00В случае opensource это не так, и абсолютно никаких гарантий того, что автор внезапно не забьет на пакет и что больше никто не сможет исправлять в нем проблемы у вас нет.
Полная чушь! Подавляющее большинство опенсорса сейчас делается крупными конторами. И за деньги они дают поддержку и гарантии.
Распространенный пример — RedHat, хотя почти на любой приличный opensource продукт найдется контора, которая за скромную сумму будет обеспечивать поддержку.SirEdvin
04.12.2017 22:01Вы плохо читали статью, там основная указанная проблема, согласно которой на самом деле все не так радужно и эти продукты строятся на мелких проектах, у которого такой радости нет.
kafeman
04.12.2017 22:10Не берусь комментировать заявление о том, что Red Hat якобы готова взять на себя ваши риски, но они точно участвуют в «мелочах», из которых состоят их продукты. Довольно часто натыкаюсь на их копирайт в исходниках совершенно разных проектов.
artskep
04.12.2017 22:21Ну, «взять» или «не взять» — тут вопрос тонкий, но обеспечить тех. поддержку по определенным SLA — это факт. Починят или нет — дело отдельное, но бизнес вполне считает подобное уменьшением рисков.
Конечно, они работают с большим количеством GPL лицензированного кода и обязаны публиковать изменения (и те, кто их использует, должны копирайты за собой тоже тащить). Ну, и под другими лицензиями, вроде, тоже много чего пишут.
Учитывая, что ребята много чего делают это вполне прогнозируемо, что их копирайты расползлись по разным проектам. В этом идея опенсорса как есть.
artskep
04.12.2017 22:12Я хорошо читал статью. Там нет НИ ОДНОГО упоминания того, чтобы какой-то коммерческий продукт пострадал из-за того, что нельзя было сделать форк или с этим были сложности.
Единственный пример известной проблемы, который привели это heartbleed, который к проблеме не имеет никакого отношения, т.к. на тот момент openssl был живым и поддерживаемым (как и сейчас, собственно говоря). Тупо нашли багу. Бывает…
perfect_genius
04.12.2017 21:49Есть ли сервис, показывающий-раскрывающий информацию (пароли), если не заходить и не отсрочить таймер каждый раз?
Areso
05.12.2017 19:18Можно такое поведение настроить в gmail. Если не заходить N времени, он пошлет письмо с инструкциями на случай смерти владельца по указанному адресу. Получателем вполне может быть список рассылки.
NtsDK
04.12.2017 23:39В связи с неизбежностью смерти автора и по мере нарастания связанных с этим проблем, я думаю, что сообщество открытого ПО дорастет до создания типовых завещаний по аналогии с лицензиями. Неудивительно, что код будет жить дольше, чем его создатели.
tangro
05.12.2017 11:44Какая-то надуманная проблема. При просмотре репозитория на GitHub сразу видно как давно в него вносились правки. Если очень давно — можно посмотреть форки этого репозитория и найти более активный. Если более активного нет — ну, поздравляю, проект умер.
Sly_tom_cat
05.12.2017 12:07Триггер мертвеца — плохая идея.
Поясню: допустим можно определить период отсутствия логина, который надо считать триггером (как установить этот предел — это еще отдельный вопрос). Но что происходит после срабатывания триггера?
В теории: находится хороший, добропорядочный программист, который берет такой проект под свой контроль.
На практике: обязательно появится хоть один хороший, недобропорядочный программист который внедрит в код проекта какую-нибудь сложно выявляему бяку (бекдор, майнерб да что угодно — выбор сейчас хороший). И да — такой «выкрутас» довольно скоро обнаружат (на то он и опенсорс), но получится что:
1. оригинальный репозиторий — в руках злоумышленника (и с этим нужно что-то делать).
2. зависимые от этого проекта проекты вынуждены будут откатывать обновления и переходить на форк созданный хорошего, добропорядочного программиста (если он найдется)
3. А весь тот вред от внедренного недобропорядочный кода, который он нанесет от момента внедрения до реализации корректирующих мероприятий уже будет не откатить.
В итоге имеем репутационные издержки и реальные потери реальных клиентов.
Можно возразить, что вариант внедрения «недобропорядочного кода» возможен и при живом авторе. Однако репы на том же гитхабе становятся популярными и активно используемыми в других проектах не внезапно, а по мере нарастания «положительной» истории. И вероятность того, что человек много лет делал качественный продукт, а потом вдруг начал внедрять зловред — гораздо ниже чем шанс получить такой зловред после перехода собственности репы по триггеру мертвеца.
VovanZ
05.12.2017 15:46+1Но GitHub не хотел давать Сёрсу управление страницей, поскольку Вайрих не передал ему таких прав перед смертью.
А с чего им хотеть?
Также ему пришлось уговорить операторов Ruby Gems, системы управления пакетами, распространяющей код, использовать его версию Rspec-Given вместо версии Вайнриха, чтобы у всех пользователей был доступ к изменениям, проделанным Сёрлсом.
И они согласились? Очень плохо, если так.
Изначально пользователи "подписывались" на rspec, который пишет и поддерживает конкретный человек. То что их переключили на другую версию без их ведома — это очень плохо.
Я считаю, что такие вещи не должны происходить неявно. Мне бы не хотелось, чтобы после моей смерти кто-то получил доступ к моим публичным репозиториям и мог бы публиковать там изменения как будто бы от моего имени.
Продумать заранее, кому и как передать такие права — это хорошая идея. Но передавать их уже после смерти человека, если он при жизни не дал на это разрешение — очень плохая идея.
x86d0cent
05.12.2017 16:19Изначально пользователи «подписывались» на rspec, который пишет и поддерживает конкретный человек. То что их переключили на другую версию без их ведома — это очень плохо.
Если пользователь указывал в Gemfile конкретную версию пакета, написанную конкретным человеком (например rspec-given 3.4.0), то никто его на другую версию, написанную другим человеком, не переключит. И даже на другую версию, написанную тем же самым человеком не переключит. Если же конкретную версию не указывал — ну так это и подразумевает, что его может со временем переключить на другую версию, и кем она будет написана — в общем случае не известно (хотя бы потому, что предыдущий автор может передать управление пакетом кому угодно).VovanZ
05.12.2017 20:35хотя бы потому, что предыдущий автор может передать управление пакетом кому угодно
Есть разница между случаем, когда предыдущий автор передаёт управление кому-то; и случаем, когда управление передают без ведома предыдущего автора (потому что он мёртв).
x86d0cent
05.12.2017 21:36Разница-то, конечно есть, но в обоих случаях вас без вашего ведома «переключат» на другую версию, написанную другим человеком.
Обезопасить себя от такого, как я писал выше, очень просто — указать конкретную версию.VovanZ
05.12.2017 21:39Это понятно, но тем не менее. Забирать у автора проект только потому, что автор умер и не может возразить — очень плохая практика, ИМХО.
указать конкретную версию
Я не знаю, как там в этих ваших рубях принято, но у нас в пейтоне все делают
pip freeze > requirements.txt, и все зависимости фризятся с указанием точной версии, так что ситуация с неявным обновлением невозможна.x86d0cent
05.12.2017 21:55Забирать у автора проект
Конкретно в этом случае у автора никто ничего не забрал — автор остался в Owners.
ситуация с неявным обновлением невозможна
Ну а в чем тогда проблема-то? :)
telhin
Вроде как можно сделать форк проекта на гитхабе и продолжить его разработку. Триггеры так-то и не нужны. Проблема в том, что сложно найти разработчика, который бы взялся поддерживать проект.
Anarions
Все ссылки будут на оригинальный проект, гугл будет вести на оригинальный проект, пакет-мэнеджеры будут скачивать оригинальную необновлённую библиотеку. В общем не всё так просто.
artskep
Если билд процедура берет тупо последнюю версию без вашего ведома, да еще с неконтролируемого репозитория — у меня для вас очень плохие новости. Если вы так делаете, то я рекомендую перестать это делать — уже были случаи, когда автор тупо решал немножко «пошалить».
А если вы хотите последних обновлений и видите, что проект не обновляется — это звоночек о том, что надо искать альтернативу. Вот тут надо и думать о том, чтобы найти форк/создать форк/перейти на что-то другое.
zone19
Предположим в проекте 30 подключенных внешних либ, следить за каждой?
kafeman
Не знаю, что вас удивляет, но описанное artskep вполне обычная практика в нормальных ИТ-компаниях, а не бред параноика.
artskep
Э… Смотря чего вы хотите от продукта.
Если при его падении/утечке данных/чего-то-еще-придумайте-сами вы теряете деньги, то да — следите за всеми. Клиенту (а, если дело пойдет серьезнее, то суду) пофигу сколько у вас депендюков — надо выполнять условия контракта и законодательства
Если вы это не можете отслеживать — надо найти кого-то кто это будет отслеживать и нести ответственность (естественно, придется заплатить).
Энтерпрайз любит RedHat не потому, что у них все лучше, чем у других бесплатных дистрибутивов Линукса, а потому, что они могут подписать контракт и взять на себя часть рисков.
Если это студенческий курсовик, то, конечно, пофигу. Но в статье речь не о них.
tangro
Да, следить за каждой. Как минимум за секьюрити-обновлениями.
amarao
Конечно не следить. Это же сложно. Тащи всё автоматом в продакшен. У меня же работает!
kutensky
Конечно да. Каждую библиотеку нужно обновлять отдельно, проверив что в ней изменилось и нет ли там breaking changes. У нас в компании, например, библиотеки обновляются только при наличии тикета, и на это выделяется время, что бы всё аккуратно сделать, ничего не сломать и протестировать affected areas.
mayorovp
Нормальные пакетные менеджеры скачивают пакет не с гитхаба, а из репозитория пакетов…
Anarions
Да, только у пакета на репозитории пакетов обычно тот же владелец что и у репозитория на гитхабе, так что от описанной проблемы это не избавит.
mayorovp
У репозитория есть организация-владелец, в которой могут принять решение передать владение пакетом кому-то другому (и так уже делалось, пусть и по другим причинам). Процесс этот точно будет небыстрым, но он возможен.
А еще бывают локальные репозитории.
alltiptop
Или наобарот, слишком много, когда количество форков после прекращения поддержки превышает разумные пределы. В принципе преемственность полезная штука, в идеале как описанно выше крупные проекты лучше держать под крылом организаций (GNU/Apache/Mozilla и тд), которые будут способны позаботится о судьбе программы/библиотеки — например официально заявить о проблемах чтобы привлечь внимание, если не найдётся разработчиков.
artskep
Вы смеетесь?
GNU это лицензия, а не организация. FSF, которая эту лицензию придумала формально не занимается разработкой от слова «совсем».
GNU Linux (как самый, наверное, известный продукт под GNU) имеет херову тучу репозиториев не связанных друг с другом, которые поддерживают разные организации с разными целями и разной историей. И еще больше организаций, которые туда коммитят.
GNU Linux жив не потому, что его поддерживает некоторая мифическая организация, а потому что он всем полезен. Во времена моей юности slackware было круто, а ubuntu еще не родилась. Ну даже если оба эти дистрибутива со своими репозиториями сдохнут — что изменится? Да ничего.
x86d0cent
Ну вообще лицензия называется GPL.
А GNU (расшифровывается как «GNU's Not Unix!») — операционная система, построенная с использованием ПО, созданного в рамках GNU Project (такие как GNU/Linux, GNU/Hurd и т.д.).
Но организация называется FSF, тут вы правы.
artskep
Блин, да, тупо попутал аббревиатуры. Обидно.
Но суть остается той же. GNU — продукт под GPL. Это не организация. Организация, которая формально продукт «основала» это FSF, которая сама по себе цель разработки не ставит (а уж тем более не пытается монополизировать ее, т.к. это противоречит самому духу FSF и созданной ей GPL).
Фу, надеюсь сейчас ничего не перепутал
x86d0cent
kafeman
FSF занимается популяризацией СПО и защитой его разработчиков / пользователей.
Я не понимаю, почему вас так волнует взаимоотношение FSF и GNU. Вы можете являться частью GNU и не являться частью FSF, ровно как и наоборот.
artskep
Я про то, что GNU — не организация, которая следит за тем, чтобы все было хорошо.
Я просто стараюсь аккуратнее прокомментировать комментарий выше: geektimes.ru/post/296131/#comment_10481011 где пытались сказать, что держать «под крылом организации» полезно для opensource. В случае GNU это очевидно не так. Я бы даже сказал, что наоборот — организация отстраняется от разработки ради многообразия (и, по факту, занимается только тем, чтобы демонополизировать разработку).
Это вопрос не взаимоотношений, а идеологий, скорее всего.
kafeman
В «тусовке» GNU множество профессиональных разработчиков, переводчиков, дизайнеров, юристов и куча других специалистов. Зачем вы все время пытаетесь объединить ее с FSF в одно целое и неделимое? FSF была создана уже позже.
Комментируя оригинальный комментарий, я, по правде сказать, даже не знаю, каким образом можно добиться включения своего проекта в GNU. Но если вам как-то удастся это сделать, то можно точно не беспокоиться о смерти своего проекта.
artskep
В «тусовке» GNU полно серьезных контор, делающих деньги. И они даже друг другу конкуренты.
gnu.org — это не весь GNU. Здесь, наверное, у нас взаимонепонимание. По факту уже найти где GNU а где нет уже почти невозможно — код расползся. Согласно GPL каждый форк по своему GNU. И авторство кода тоже расползлось, так что приватизировать GNU уже физически нереально.
Расползание кода и демонополизация этого всего — результат лицензии GPL. Которая изначально была сделана «вирусной», чтобы никак нельзя было монополизировать хотя бы частичку кода. Поэтому ее энтерпрайз недолюбливает, но частенько вынужден использовать.
FSF — это такое же детище Столлмана, как и GPL (и как результат, GNU). Можно спорить кто появился раньше, но это не принципиально.
kafeman
Большинство авторов отдают свои права в пользу FSF. Но приватизировать код нельзя по другой причине, потому что автор (не важно, FSF, или конкретный человек) в свое время опубликовали его под лицензией GPL. С этих пор программа становится «свободной» (в понимании RMS) и может продолжать жить независимо от хотелок корпораций или той же FSF.
В любом случае, я не понимаю, как из всего этого следует вывод:
artskep
Во-первых, вспомните что означает буква G в GPL
Во-вторых: пункт 2a (я читаю под GPLv2 www.gnu.org/licenses/old-licenses/gpl-2.0.en.html)
Т.е. если это был GNU проект он как бы им и остается — позволяется только делать изменения в нем (и об этом явно указывать)
Там, конечно, есть секция про то, что можно выдирать куски. Но все-таки большинство форков GNU, очевидно, не такие.
GNU не организация. FSF не контролирует GNU. Большинство коммиттеров в GNU вообще левые конторы (подчас конкурирующие).
Вывод — GNU не контролируется какой-то организацией.
Л — логика.
kafeman
Если я форкну GNU Emacs и назову его Kafemacs, последний не станет автоматически частью проекта GNU.
Логика должна показывать, как из A следует B. Сейчас я не вижу следствия между умозаключениями «держать „под крылом организации“ полезно для opensource. В случае GNU это очевидно не так.» и «GNU не контролируется какой-то организацией, но при этом успешный opensource проект».
Позвольте поинтересоваться, какой опыт работы с проектами в GNU/Mozilla/Apache/etc. у вас имеется? У меня есть знакомый в Mozilla Foundation на fulltime, я сам являюсь одновременно участником одного из проектов GNU и ассоциативным членом FSF. И, конечно, я не утверждаю, что в GNU вашему проекту будет лучше, чем в тех же Apache или Mozilla, но ваше утверждение «это очевидно не так» относительно наречия «полезно» без возможности доказать свою позицию, мягко скажем, вызывает вопросы в вашей компетентности по данному вопросу. И за сем я не вижу смысла продолжать этот спор.
kafeman
GNU-кун в треде.
GNU — это проект по разработке свободного программного обеспечения, а также одноименная операционная система. В рамках этого проекта в т. ч. разработано несколько свободных лицензий, таких как GPL.
Проекта «GNU Linux», на сколько я знаю, не существует, и никогда не существовало. Однако, есть масса дистрибутивов (вроде тех же Slackware или Ubuntu), которые используют код ОС GNU, а ядро заменяют на Linux. Такие дистрибутивы называются «основанные на GNU/Linux», чтобы отличить их от полностью основанных на Linux систем вроде Android, а также систем, основанных на GNU, но с другим ядром (например, GNU Hurd).