Инициатива GitHub по привлечению ЕС к финансированию открытого ПО

выделяли бабло на эти развития замены slave на secondary и разработки CoC’ов

и переписывание на rust, конечно же

Технически это реализовать абсолютно не сложно.

Ну ты же понимаешь, проблема не техническая. :)

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

Я не согласен что это основная проблема СПО :) Это просто современная тенденция в разработке ПО вообще. Едва ли с этим можно что-то сделать.

А проблема качества ПО не усугубится даже «вертолётным» финансированием. Едва ли можно вывести однозначную связь между изменением качества ПО и финансированием вообще. При увеличении финансирования общее количество СПО вырастет, как качественного, так и некачественного, но пропорции скорее всего сохранятся.

Но о чём речь? О каких-то смешных 350 миллионов? Это не приведёт к существенному росту. Речь идёт о точечной поддержке небольшого количества важных, критических проектов. Их не так уж много.

Такие целевые точечные вливания, могут принести много пользы. Но если говорить вообще, то даже и слепая «вертолётная» поддержка проектов СПО тоже в целом будет весьма полезна.

Вспоминается недавний срач о том, что разработчик Organic Maps потратил донаты на отпуск (кажется, внимательно не вчитывался), до этого были такие же претензии к другим проектам, вплоть до того, что автора одного OS проекта потратил донаты на личный ноутбук (наверное, он должен был разрабатывать на бумажке).

Я не согласен что это основная проблема СПО :) Это просто современная тенденция в разработке ПО вообще.

Ну, эта тенденция связана с распространением СПО. И из-за этой тенденции растут общие риски в ИТ, которые гос. финансирование типа должно снизить. А для свободного софта в этом меньше проблема, чем для коммерческих решений.

О каких-то смешных 350 миллионов? Это не приведёт к существенному росту.

Такие целевые точечные вливания, могут принести много пользы.

Потраченные ресурсы на что-то одно всегда идут в ущерб чему-то другому, а там размытые заявления о поддержке «критических» проектов. Основная беда же не в недофинансировании известного софта, а в проектах невидимках в составе важных для экономики решений. И донатами эта проблема нерешается.

Едва ли с этим можно что-то сделать.

Вернуть время вспять нельзя, но сгладить последствия можно. Скорее всего нас ждет болезненное и не самое эффективное регулирование. Типа выпиливания анонимности под корень, жестких требований к способам аутентификации пользователей на ресурсах с софтом/пакетами, сбор статистики с них, требований и гарантий от поставщиков коммерческих решений и т.п.

там размытые заявления о поддержке «критических» проектов

Что размыто? Мне всё понятно, собираем экспертов, те составляют список критических проектов, мониторим, поддерживаем при необходимости.

Основная беда же не в недофинансировании известного софта, а в проектах невидимках в составе важных для экономики решений.

Ну так, «проекты-невидимки в составе важных для экономики решений» это же и есть «критически важные» проекты? Разве нет?

донатами эта проблема нерешается.

Не понял тебя. Ну так для этого же фонд и создаётся, чтобы не донаты собирать по миру, а финансировать системно через фонд.

Вернуть время вспять нельзя, но сгладить последствия можно. Скорее всего нас ждет болезненное и не самое эффективное регулирование.

Не поможет

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

запуск в продакшене прототипов с гитхаба.

!! Вот! Наблюдаю регулярно. Причём именно прототипов, законченные работы разработчики не открывают и наработками не делятся. Плюс сюда огромное количество неработающих проектов «для CV», которые создаются автором только для поиска работы и умирают сразу, как это происходит.

Я не совсем понимаю, в чём проблема проектов-однодневок и проектов-прототипов?

Ну да, есть такие проекты и всегда были. Ну и что? Не используй их в своём надёжном прекрасном проекте и всё. Делов-то.

Когда-то давно был создан FSF, именно для решения этой проблемы. Права на софт передаются в фонд, а фонд занимается его дальнейшей разработкой и поддержкой при необходимости. Не нравится лично конкретный FSF, можно сделать ещё один свой национальный фонд…

Других путей, кроме как через подобные государственные и негосударственные фонды я не вижу.

Ну так, «проекты-невидимки в составе важных для экономики решений» это же и есть «критически важные» проекты? Разве нет?

Это уязвимость, важность для экономики от которой в образовавшихся от неё рисках. А сложность с проектами-невидимками в том, что их замечают уже тогда, когда петух клюнет.

Мне всё понятно, собираем экспертов, те составляют список критических проектов, мониторим, поддерживаем при необходимости.

Например, выложил Васян проект с названием «моя схема бп» с описанием того, что он сделал его для моргания светодиодами с ардуино. А через пять лет бытовая техника начала гореть, так как для экономии на инженерах все начали использовать её в своих девайсах. Вот это то, что сегодня происходит в ИТ.

И эта проблема никак не решается донатами Васянам. Даже если он допилит в меру своих возможностей и за гроши схему под бытовые устройства, то через год девайсы начнут гореть на заводах. Раздавать надо не донаты Васянам, а другие нецензурные вещи недобросовестным поставщикам коммерческих решений.

Неплохой разбор подобной абсурдной ситуации: https://www.youtube.com/watch?v=H_O5JtBqODA

Я не совсем понимаю, в чём проблема проектов-однодневок и проектов-прототипов?

В высоком риске, связанном с их использованием. Дешевле и надёжнее создать свою однодневку-прототип. Как следствие - быстрое размножение недоделок несопроводилок.

В высоком риске, связанном с их использованием. Дешевле и надёжнее создать свою однодневку-прототип. Как следствие - быстрое размножение недоделок несопроводилок.

Я работал с такими внутренними проектами-однодневками. Качество часто не лучше, чем у поделок на GitHub.

Когда человек вываливает что-то на публику, то он обычно старается всё причесать хотя бы минимально, написать хоть какую-нибудь доку.

Во внутренних корпоративных велосипедах часто доки нет. «Надо будет - спросишь у Кости, он написал эту либу.» Через год Костя увольняется, компетенций по либе не остаётся ни у кого, а документация так и не была написана.

Внутренние либы часто костыльные и ещё менее законченые. «Хватит полировать, твоя либа уже достаточно хороша. Бизнес пришёл с новыми задачами, срочно переключайся на них. Либу свою допилишь в следующем спринте (никогда)»

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

Например, выложил Васян проект с названием «моя схема бп» с описанием того, что он сделал его для моргания светодиодами с ардуино. А через пять лет бытовая техника начала гореть, так как для экономии на инженерах все начали использовать её в своих девайсах. Вот это то, что сегодня происходит в ИТ.

Спонсирование критических важных проектов решает другую проблему: Василий не хочет больше сопровождать проект, потому что ему нужно заработать на еду или он умер и нужен другой Василий.

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

Вот чтобы это произошло быстрее и нужен такой фонд.

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

И таких Васянов тонна. Например, компилировал проект аналог спидтеста. Вытянул три сотни зависимостей. Сколько из них подтянуто в других проектах и сколько будет заброшено через год одному богу известно.

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

Как ты себе представляешь процесс перекладывания ответственности? В GPL есть два важных пункта

1. Отказ от предоставления гарантий
2. Отказ от ответственности

Если ты хочешь какие-то гарантии, типа тебе будут фиксить баги в течении года, то надо заключить какой-то договор. Так что не переживай, никакой ответственности ни на кого переложить не удастся.

Если ты хочешь какие-то гарантии, типа тебе будут фиксить баги в течении года, то надо заключить какой-то договор.

1. Это нормализует ситуацию для разработчиков коммерческих решений брать всё подряд бесплатно без регулирования и оглядки на последствия с подходом, что государство как-нибудь профинансирует эти бесплатные проекты, а Васяны как-нибудь да починят.

2. В любом ИТ проекте у тебя отказ от гарантий и ответственности, с учетом уровня и скорости роста текущих проблем это скоро поменяется.

3. СПО может и не избежать этого регулирования, как бы абсурдно это не выглядело. А если общество примет идею «да, проблемы в СПО, его просто не финансируют», то следующим шагом жди и ответственность.

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

Это я обрисовал лайтовый вариант и куда ветер дует. Есть высокая вероятность, что в результате регулирования на СПО лягут обязанности на том же уровне, что и на коммерческие проекты.

Авторов этих пакетов обяжут реагировать на уязвимости в течении определенного времени после последнего дня доступности пакета.

На что автор скажет «идите на хутор бабочек ловить» и удалит пакет.

Есть высокая вероятность, что в результате регулирования на СПО лягут обязанности на том же уровне, что и на коммерческие проекты.

Тем временем любая EULA: «мы снимаем с себя всю ответственность в пределах, допустимых местным законодательством»

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

Инициатива GitHub по привлечению ЕС к финансированию открытого ПО

то есть америкосовский Некрософт, у которого денег хоть жопой жуй, такой: "эй, Гейропа, дайте нам денях на поддержку открытого ПО и прочие хорошие дела, а то у нас не хватат!" прекрасно, просто прекрасно!

с первоначальным бюджетом €350 млн. для поддержки критически

млн, млрд - без точки! Розенталем по башке до просветления!

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

Вообще не вижу проблемы, а наоборот, по-моему это прекрасно.

В любом ИТ проекте у тебя отказ от гарантий и ответственности, с учетом уровня и скорости роста текущих проблем это скоро поменяется.

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

Авторов этих пакетов обяжут реагировать на уязвимости в течении определенного времени после последнего дня доступности пакета.

Почему бы авторам не пойти навстречу страждущим, если страждущие готовы платить за подобные услуги?

Почему бы авторам не пойти навстречу страждущим, если страждущие готовы платить за подобные услуги?

Заинтересованные фонды и корпорации могут предложить опытным разработчикам выгодные контракты за то что они будут вовремя закрывать дыры, разве это не прекрасно?

Они и сейчас предложить могут по своему желанию, а авторы могут пойти или нет на встречу. А тут задвигают идею «из-за недофинансирования опенсорса создаётся угроза для экономики, надо это дело пофиксить с налогов», то появляется проблема. Люди должны будут это оплачивать, государство распределять ресурсы и контролировать результат, что приближает к гос. регулированию в опенсорсе.

Вообще не вижу проблемы, а наоборот, по-моему это прекрасно.

Когда коммерческие компании берут бездумно бесплатные поделки ради экономии средств на инженерах, так как с доступным в ИТ полным отказом от ответственности на неё просто забить можно, а это единственный способ в таких условиях конкурировать на рынке? Финансирование этих поделок ничего не исправит, инженеры на зарплате этих компаний должны работать над общими опенсорс проектами для взаимной экономии ресурсов.

Люди должны будут это оплачивать, государство распределять ресурсы и контролировать результат, что приближает к гос. регулированию в опенсорсе.

А что же в этом плохого? Это прекрасно. Так и должно быть. Если государство сочтёт необходимым финансировать некие критические важные проекты, вполне логично, что оно будет и следить за результатами. Такое регулирование нам нужно! Действительно, если в sudo или libcrypt не пофиксят дыры из-за недостатка времени из-за недофинансирования, то будет плохо всем.

Вообще не вижу проблемы, а наоборот, по-моему это прекрасно.

Когда коммерческие компании берут бездумно …

Те что действуют через чур уж бездумно, однажды потерпят убытки и прогорят или проиграют конкурентам. В этом же идея капитализма, разве нет?

Финансирование этих поделок ничего не исправит

Ну так и речь не о поделках, а о критически важных компонентах.

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

Да, хорошо бы, чтобы они это делали. Но это иногда плохо работает, по разным причинам. Так почему бы не создать фонд, которые оплатит работу инженеров над этими общими проектами? Вполне логичный шаг, выгодный всем нам.

Логическая ошибка здесь в том, что авторам зачастую деньги не нужны. Точнее сказать, излишние деньги. Многие «Васяны» быстро начинают понимать, по мере накопления жизненного опыта, что берёшь деньги — приходится брать и ответственность, обязанности. «Получая корову получаешь и рога».

Особенно это касается взрослых, состоятельных «Васянов». Их и так всё устраивает, и им не нужен лишний геморрой, приятнее кодить в своё удовольствие когда хочешь и что хочешь.

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

Логическая ошибка здесь в том, что авторам зачастую деньги не нужны.

Ну так и не будут брать, в чём проблема. Или за ними будут бегать и заставлять взять деньги насильно? :)

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

Что-то ты перемудрил по-моему. Использование СПО экономически оправдано и приносит пользу обществу, государству, коммерсантам, помогая снижать издержки и избегать дублирования работы. Да, многие проекты СПО не блещут качеством, но и собственническое ПО тоже не часто блещет своим качеством. Это нормально. Для огромной части прикладного ПО качество, безопасность не являются первостепенными требованиями, очень часто нужно хоть какое-то решение уже вчера. Поэтому даже вертолётная поддержка принесёт свои полезные плоды. А здесь речь о точечной, целенаправленной поддержке небольшого списка критически важного СПО. Что тут может пойти не так???

Действительно, если в sudo или libcrypt не пофиксят дыры из-за недостатка времени из-за недофинансирования, то будет плохо всем.

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

Те что действуют через чур уж бездумно, однажды потерпят убытки и прогорят или проиграют конкурентам.

Возможно потерпят, возможно проиграют конкуренту. А у него тоже самое, так как в текущих условиях это самая выгодная стратегия оставаться на плаву и другой подход не оправдан.

то надо заключить какой-то договор. Так что не переживай, никакой ответственности ни на кого переложить не удастся.

Ты не поверишь, но в заключаемом договоре будет и «Отказ от предоставления гарантий» и " Отказ от ответственности". 😄 Софтовые компании милостиво позволяют надеяться, что на твои вопли «всё плохо и не работает» кто то что то ответит по факту и всё. У меня таких примеров от ораклов и микрософтов, до васян и компания софт.

Вот и пример первой сложности, их нет смысла финансировать, особенно судо. Для libcrypt инженеры сразу найдутся

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

Реальные проблемы создают ситуации типа нашумевшего log4j

Если заметный процент серверов его использует, то вполне может быть ещё один кандидат. Вот и будут там с этим разбираться.

в текущих условиях это самая выгодная стратегия

Ну вот ты же сам всё прекрасно понимаешь. СПО позволяет сильно экономить, но есть проблема с заброшенными проектами или проектами которыми занимаются три калеки в свободное время. Для начала их нужно пересчитать и оценить масштаб проблемы.

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

Договор на гарантийное обслуживание, в который может входить исправление найденных дефектов и прочих дыр в безопасности вполне реален.

Если заметный процент серверов его использует, то вполне может быть ещё один кандидат. Вот и будут там с этим разбираться.

И тут сразу две проблемы:

1. Как они должны разбираться? Разработчики сами зачастую не знают, что они у себя в проекте используют. Там может быть по сторонней библиотеке на 10 строчек кода. Тут явно требуется регулирование по распространению кода и требования к отчетности его использования.

2. Проблема образуется не из-за отсутствия финансирования и оно её не решает. Беда в том, что проекты в своем составе имеют сотни сторонних зависимостей, а ошибка в одном из распространённых пакетов представляет угрозу для экономики в целом. Критичность проекта при этом не имеет значения, это может быть хоть библиотека для проверки числа на четность. Когда обнаруживается баг уже поздно, а основная сложность не пофиксить его в коде, а оперативно распространить фикс в использующие его проекты:

• Кто-то пофиксил баг и куда теперь фикс выложить? Скорее всего самым быстрым и разумным способом будет форк. Вместе с фиксом туда еще можно и закладочку подложить, вдруг кто утянуть успеет.

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

• Повезло, разработчики выпустили фикс и даже оповестили пользователя. Фикс они добавили в свою последнюю версию, теперь организациям осталось выделить бюджет на приобретение последний версии и выполнить миграцию.

В реальности это приводит к тому, что ничего оперативно не исправляется и значительный кусок «прода» от которого зависит экономика продолжает и дальше работает с известными (часто не пользователям этого кода) дырами.

В разрезе дистрибутивов линукса же как раз всё более-менее не плохо. Тут забавная ситуация, что работающие на энтузиазме люди не мотивированы выполнять задачи в духе «после меня хоть потоп» и их как раз в первую очередь волнует простота поддержки системы. В рамках линукса основная угроза распространение подхода «curl | sh», васяновских ppa и в тоннах плагинов для едиторов.

И тут сразу две проблемы:

Сначала надо список составить, определить критерии важности и т.п. Это даже посложнее будет.

Как они должны разбираться? Разработчики сами зачастую не знают, что они у себя в проекте используют.

Не знаю что как там с Джавой, но в дистрибутивах, например в Дебиане, почти все зависимости прописаны и их можно отследить. В вебе как-то тоже отслеживают.

ошибка в одном из распространённых пакетов

ну вот тебе один из критериев сразу - распространённость

Кто-то пофиксил баг и куда теперь фикс выложить?

Этот механизм давно отработан. Можно CVE посмотреть, например. Работает же.

В реальности это приводит к тому, что ничего оперативно не исправляется…

В Линукс-дистрах вроде Дебиана исправляется.

Речь идёт о том, чтобы критично важные пакеты (из списка) обновлялись ещё оперативней и не возникало ситуации, когда ими заняться некому.

Что касается собственнического ПО, то с ним проблема как была, так и остаётся на плечах их собственников. Захотят выпустить обновление - выпустят, не захотят - не выпустят. И тут чаще второе, к сожалению. И если с СПО более-менее понятно, хоть сложно, но возможно сделать фиксы третьей стороне, то с собственническим всё очень очень плохо, чаще всего такой возможности нет.

Если регуляцию и вводить, то для крупных известных закрытых проектов. Если они становятся достаточно важными и популярными, то они должны обеспечивать фиксы на протяжении длительных сроков. Например, для телефонов обновления должны выпускаться в течении 8 лет, либо код должен быть полностью открыт.

Сначала надо список составить, определить критерии важности и т.п. Это даже посложнее будет.

ну вот тебе один из критериев сразу - распространённость

И вот решая эту задачу мы идем к регулированию.

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

Ява тут не причем. Это общий тренд современного ИТ. Даже сами компании часто не в курсе, чего там у них в код разработчики тянут и от чего зависят их решения.

Этот механизм давно отработан. Можно CVE посмотреть, например. Работает же.

В том то и дело, не работает. Даже разработчики не всегда в курсе, что у них там в проекте используется.

В Линукс-дистрах вроде Дебиана исправляется.

Так я и написал, что в разрезе дистрибутивов линукса то проблемы и нет, да и система распространения обновлений в них встроена. И фонд предлагают создать не для поддержки дистров, а для включаемого в коммерческие решения OSS кода.

– повысить жалованье Королевскому астроному! (Директору обсерватории)

– Ни в коем случае, Ваше величество! Иначе в астрономию полезут проходимцы. (Эдмунд Галлей, директор обсерватории в Гринвиче, которую за свой счёт заново оборудовал инструментами) 300 лет прошло…

В софте? Ну, наверно, у каких нить вояк, возможно, есть такие договора с соответствующим ценником. Но у простых смертных такое чудо не доступно. Везде прописывается одно - время реакции на запрос и на самом деле всё.

И вот решая эту задачу мы идем к регулированию.

Почему тебя пугает слово регулирование? Я не вижу ничего плохого в регулировании в принципе. Бывают, конечно, разные крайности, но регулирование вообще не означает автоматически что-то плохое. А тем более регулирование, заключающееся в финансовой поддержке критически важных проектов! Это нам нужно и полезно. Побольше бы такого регулирования.

Ява тут не причем. Это общий тренд современного ИТ. Даже сами компании часто не в курсе, чего там у них в код разработчики тянут и от чего зависят их решения.

Я уже написал про Дебиан, там все зависимости есть. В большинстве свободных c/c++ проектов зависимости чётко прописаны и известны. Может быть я что-то пропустил, за Явой не слежу.

Так я и написал, что в разрезе дистрибутивов линукса то проблемы и нет

С чего ты взял, что проблемы нет? Ещё как есть. Вот, например

Уязвимости выявлены в ходе аудита кодовой базы GNU screen, проведённого командой, отвечающей за безопасность дистрибутива SUSE Linux. Разработчикам screen сведения об уязвимости были отправлены 7 февраля, но за отведённые 90 дней они так и не смогли подготовить исправления для всех уязвимостей и сотрудникам SUSE пришлось подготовить некоторые патчи самостоятельно. По мнению проводивших аудит исследователей, нынешние сопровождающие GNU screen недостаточно хорошо ориентируются в кодовой базе проекта и не способны полностью разобраться в выявленных проблемах безопасности.

https://www.opennet.ru/opennews/art.shtml?num=63226

В софте? Ну, наверно, у каких нить вояк, возможно, есть такие договора с соответствующим ценником. Но у простых смертных такое чудо не доступно. Везде прописывается одно - время реакции на запрос и на самом деле всё.

Ты удивишься, но в ЕС есть обязательная гарантия на цифровые продукты, включая ПО

Можно здесь почитать https://base.garant.ru/73960691/

По закону ЕС 2019/770 гарантия (Mängelhaftung) на цифровой продукт составляет 2 года.

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

Покупатель имеет право на:

• Бесплатное устранение дефекта (обновление, исправление).
• Снижение цены.
• Расторжение договора, если исправление невозможно или отказано.

В софте? Ну, наверно, у каких нить вояк, возможно, есть такие договора с соответствующим ценником. Но у простых смертных такое чудо не доступно. Везде прописывается одно - время реакции на запрос и на самом деле всё.

Ну и в принципе, повторюсь - вопрос договорённостей и цены. Вот как раз такой фонд позволит это делать централизовано и по приемлемой цене.

А тем более регулирование, заключающееся в финансовой поддержке критически важных проектов!

Я уже написал, что для этого первым шагом потребуется полный отказ от анонимности и контроль распространения кода/пакетов. Регулирование - доп. нагрузка и ограничения для касающихся его людей.

Я уже написал про Дебиан, там все зависимости есть.

Дистрибутив линукса - капля в море опенсорса, не о них речь. Так же речь касается не самого опенсорса, а решений на его основе (как открытых, так и закрытых).

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

Ещё как есть. Вот, например

Пример не проблемы, которую спокойно можно проигнорировать. Патчи подготовили и доставили до пользователя. Дистрибутивы линукс как раз редкий пример здорового распространения ПО. Первый же громкий звоночек о ситуации с софтом был с log4j (это не особенность явы, так сейчас в ит всё делается), и эту ситуацию пытаются выставить как проблему с финансированием опенсорса.

Сама же суть проблемы в комбинации двух факторов:

1. Из-за популярности свободного ПО для сокращения времени и затрат на разработку все тянут готовые бесплатные решения. Эти решения не всегда плохие и могут быть даже и с меньшим числом багов/уязвимостей, чем получилось бы при реализации их с нуля. Но число их в проектах бесконтрольно растёт, их становится сложнее контролировать, а системы дистрибьюции становится вкусной целью для разного рода вредителей.

2. Когда какое-то решение расползается по проектам, то растет и угроза от ошибки в нём. Даже если оно прям замечательное и его применение сократило кратно число дыр и багов в целом, но эти дыры теперь стали вкусными для эксплуатации, а последствия от багов не размазаны по разным проектам и во времени, а бьют сразу по всем.

И получается концентрация угроз ИТ в библиотеках/утилитах, которых еще и много и их использование нормально даже не проследить. Хоть миллионы сюда вбрасывай, хоть миллиарды, финансированием опенсорса проблема не решается.

и их использование нормально даже не проследить

Так и не надо: не за чем...

финансированием опенсорса проблема не решается

Разумеется, не решается. Никакая проблема одним финансированием не решается. Нужны ещё постановка задач(и), управление реализацией и прочие «глупости». Ну а уже на это всё нужно финансирование, да. :)

Но тоже контролируемое... ;)

Я уже написал, что для этого первым шагом потребуется полный отказ от анонимности и контроль распространения кода/пакетов. Регулирование - доп. нагрузка и ограничения для касающихся его людей.

Про анонимость вообще непонятно, в чём ты видишь проблему и при чём тут анонимность. Обычно авторы не скрывают свои личности и подписывают свои творения.

Про контроль распространения кода/пакетов - это ещё зачем? Почему недостаточно того что есть сейчас?

Дистрибутив линукса - капля в море опенсорса, не о них речь.

Едва ли много важных и критических пакетов существуют вне известных дистрибутивов. Тот же log4j есть в Дебиане.

Пример не проблемы, которую спокойно можно проигнорировать. Патчи подготовили и доставили до пользователя. Дистрибутивы линукс как раз редкий пример здорового распространения ПО. Первый же громкий звоночек о ситуации с софтом был с log4j

Нет, это как раз та проблема, которую и собираются решать, в отличие от log4j. В том и дело, что в установленные сроки с патчами авторы screen не справились и пришлось привлекать кого-то со стороны. А как раз с log4j всё было отлично - фикс был выпущен через 9 дней после обнаружения.

Сама же суть проблемы в комбинации двух факторов: …

Это другая проблема, непонятно почему ты вообще о ней заговорил. С этой проблемой создаваемый фонд бороться не собирается, речь идёт о совершенно другой проблеме: проблеме заброшенных и полузаброшеных пакетых из-за недофинансирования. Где ты там увидел что они собираются что-то делать с количеством зависимостей?

Почему недостаточно того что есть сейчас?

Так как не известно, кто, что и где использует.

Едва ли много важных и критических пакетов существуют вне известных дистрибутивов. Тот же log4j есть в Дебиане.

Дистрибутивы линукса - один из способов распространения свободного софта. Есть он там или нет в дебиане значения не имеет.

А как раз с log4j всё было отлично - фикс был выпущен через 9 дней после обнаружения.

В случае со скрином, в самой запущенной ситуации, его можно было просто удалить из системы. А после обновления тупо сделать apt update && apt upgrade. В случае со всякими библиотеками изменения должны выкатить все, кто их у себя использовал. И, часто, этот софт еще и пользователю потом не так просто обновить. А отказаться от него он не может, так как на нём завязаны бизнес процессы.

Где ты там увидел что они собираются что-то делать с количеством зависимостей?

Я описал реальную проблему, из-за которой начинают шевелиться. А в предложении от микрософта предлагают просто спустить деньги в унитаз.

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

Так как не известно, кто, что и где использует.

Популярные проекты известны не только из дистров. Но статистика вне дистрибутивов не сильно отличается от статистики внутри дистрибутивов (с чего бы она радикально отличалась), всё самое популярное и критически важное в основном включено в дистры.

Дистрибутивы линукса - один из способов распространения свободного софта.

Это всё же основной способ для СПО на сегодняшний день.

Я описал реальную проблему, из-за которой начинают шевелиться. А в предложении от микрософта предлагают просто спустить деньги в унитаз.

Описанная тобой «проблема» это просто обратная сторона популярности СПО из-за колоссальных преимуществ и выгод, которые оно даёт. Естественно, никто не будет отказываться от преимуществ и выгод из-за якобы повышенных рисков, которые ещё и непонятно как измерять.

Популярные проекты известны не только из дистров. Но статистика вне дистрибутивов не сильно отличается от статистики внутри дистрибутивов (с чего бы она радикально отличалась), всё самое популярное и критически важное в основном включено в дистры.

Это не так.

Это всё же основной способ для СПО на сегодняшний день.

Нет. Основной - pip, npm, cargo и т.п. Сегодня все используют СПО и даже не задумываются об этом.

Естественно, никто не будет отказываться от преимуществ и выгод из-за якобы повышенных рисков, которые ещё и непонятно как измерять.

Поэтому регулирование неизбежно, так как риски уже серьезные и только растут. И хотелось бы, чтобы регулировали зарабатывающий за счет СПО бизнес, а не СПО.

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

У нас переход на «отечественное» ПО и нормы по защите от ФСТЭКа. Направление верное и есть местами разумные моменты, но все выродилось в создание индустрии по бумажной отчетности.

Основной - pip, npm, cargo и т.п.

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

Поэтому регулирование неизбежно

Регулирование в области ПО давно существует. Если ты имеешь в виду что-то новое необычное, то так и пиши. Наверное ты ожидаешь что ужесточатся требования на государственные тендерах или законы о защите потребителях? Что ж, вполне может быть. Уже сейчас есть страны которые требуют использование СПО при возможности в государственном секторе. Такое регулирование нам надо!

Он не может быть основным хотя бы потому что разработчиков гораздо меньше, чем пользователей.

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

Если ты имеешь в виду что-то новое необычное, то так и пиши.

Я и написал, что первым делом придется отказаться от анонимности и можно ждать требования об отчетности. В рамках текущей анархии просто невозможно определить проблемные места и что-то с этим сделать. Вполне возможно, что через несколько лет и пул реквесты можно будет делать только по паспорту из списка одобренных стран.

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

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

Я и написал, что первым делом придется отказаться от анонимности и можно ждать требования об отчетности.

Какой ещё анонимности? Где ты видел анонимность? Авторы важных СПО проектов вполне известны. Отчётность о чём, кого и перед кем?

Вполне возможно, что через несколько лет и пул реквесты можно будет делать только по паспорту из списка одобренных стран.

Это может быть, конечно, политики сходят с ума, по политическим причинам - вполне. Но только не из-за зависимостей. Хотя как повод могут использовать :)

Ты разберись с терминологией. Пользователи сначала должны получить эти продукты от разработчика, это и есть распространение. На сегодняшний день основной путь распространения СПО - через дистрибутивы.

Из инициативы: «GitHub’s research says 96% of all codebases contain open source code…». СПО внутри по всюду, даже если ты линуксом не пользуешься. Типичные дистрибутивы линукса - маленький кусочек от свободного софта и, очевидно, что речь в инициативе не про них.

Какой ещё анонимности?

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

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

Да, пожалуй ты прав. Но всё равно, вычислить популярные проекты можно и без линукс-дистрибутивов. Например используя тот же гитхаб и т.п.

Кто угодно может постить код на тот же гитхаб

Ну и при чём тут анонимость? Авторы проекта всё равно утверждают или отвергают запросы на изменения и свои имена они обычно не скрывают. Может быть ты имел в виду открытость, а не анонимность?