On Monday, 16 December 2019 10:01:45 MSK Andrey Cherepanov wrote: > /.out/qt-creator-4.11.0-alt1.src.rpm: license not found in > '/usr/share/license' directory: > GPL-3.0-with-Qt-Company-Qt-exception-1.1 В qtbase-5, например: LGPL-2.1 with Qt-LGPL-exception-1.1 or LGPL-3.0-only > hsh-rebuild: pkg.tar: sisyphus_check failed. > > Как в таком случае поступать, что решили? > > Почему нет принятой политики закручивания гаек на > https://www.altlinux.org/License_Tag_Policy ? -- Regards, Sergey.
16.12.2019 10:21, Sergey V Turchin пишет: > On Monday, 16 December 2019 10:01:45 MSK Andrey Cherepanov wrote: >> /.out/qt-creator-4.11.0-alt1.src.rpm: license not found in >> '/usr/share/license' directory: >> GPL-3.0-with-Qt-Company-Qt-exception-1.1 > В qtbase-5, например: > LGPL-2.1 with Qt-LGPL-exception-1.1 or LGPL-3.0-only Хорошо. GPL-3.0 with Qt-GPL-exception-1.0 and MIT and LGPL-2.0 and LGPL-2.1 and LGPL-3.0 and BSD-3-Clause Где мне в common-licenses найти: * Boost Software License, Version 1.0 (для пары расширений Boost) * Public Domain (для забандленного sqlite) ? >> hsh-rebuild: pkg.tar: sisyphus_check failed. >> >> Как в таком случае поступать, что решили? >> >> Почему нет принятой политики закручивания гаек на >> https://www.altlinux.org/License_Tag_Policy ? Этот вопрос также актуален. -- Andrey Cherepanov cas@altlinux.org
On Monday, 16 December 2019 10:50:03 MSK Andrey Cherepanov wrote: > 16.12.2019 10:21, Sergey V Turchin пишет: > > On Monday, 16 December 2019 10:01:45 MSK Andrey Cherepanov wrote: > >> /.out/qt-creator-4.11.0-alt1.src.rpm: license not found in > >> '/usr/share/license' directory: > >> GPL-3.0-with-Qt-Company-Qt-exception-1.1 > > > > В qtbase-5, например: > > LGPL-2.1 with Qt-LGPL-exception-1.1 or LGPL-3.0-only > > Хорошо. GPL-3.0 with Qt-GPL-exception-1.0 and MIT and LGPL-2.0 and > LGPL-2.1 and LGPL-3.0 and BSD-3-Clause > > Где мне в common-licenses найти: > > * Boost Software License, Version 1.0 (для пары расширений Boost) > > * Public Domain (для забандленного sqlite) > > ? License: GPL-3.0-with-Qt-Company-Qt-exception-1.1 AND (LGPL-2.1-with- Qt-Company-Qt-exception-1.1 OR LGPL-3.0-only) AND (LGPL-2.1-only OR LGPL-3.0- only) AND GPL-3.0-only AND LGPL-3.0-only AND MIT AND BSD-3-Clause https://build.opensuse.org/package/view_file/openSUSE:Factory/libqt5-creator/ libqt5-creator.spec?expand=1 Наверняка поправить придётся. > >> hsh-rebuild: pkg.tar: sisyphus_check failed. > >> > >> Как в таком случае поступать, что решили? > >> > >> Почему нет принятой политики закручивания гаек на > >> https://www.altlinux.org/License_Tag_Policy ? > > Этот вопрос также актуален. -- Regards, Sergey.
16.12.2019 11:01, Sergey V Turchin пишет: > On Monday, 16 December 2019 10:50:03 MSK Andrey Cherepanov wrote: >> 16.12.2019 10:21, Sergey V Turchin пишет: >>> On Monday, 16 December 2019 10:01:45 MSK Andrey Cherepanov wrote: >>>> /.out/qt-creator-4.11.0-alt1.src.rpm: license not found in >>>> '/usr/share/license' directory: >>>> GPL-3.0-with-Qt-Company-Qt-exception-1.1 >>> В qtbase-5, например: >>> LGPL-2.1 with Qt-LGPL-exception-1.1 or LGPL-3.0-only >> Хорошо. GPL-3.0 with Qt-GPL-exception-1.0 and MIT and LGPL-2.0 and >> LGPL-2.1 and LGPL-3.0 and BSD-3-Clause >> >> Где мне в common-licenses найти: >> >> * Boost Software License, Version 1.0 (для пары расширений Boost) >> >> * Public Domain (для забандленного sqlite) >> >> ? > License: GPL-3.0-with-Qt-Company-Qt-exception-1.1 AND (LGPL-2.1-with- > Qt-Company-Qt-exception-1.1 OR LGPL-3.0-only) AND (LGPL-2.1-only OR LGPL-3.0- > only) AND GPL-3.0-only AND LGPL-3.0-only AND MIT AND BSD-3-Clause > https://build.opensuse.org/package/view_file/openSUSE:Factory/libqt5-creator/ > libqt5-creator.spec?expand=1 > Наверняка поправить придётся. Они не учли, что exception 1.0 и стыдливо закрыли глаза на Boost Software License, Version 1.0 и Public Domain. И смысл в простыне при явном их передёргивании? > >>>> hsh-rebuild: pkg.tar: sisyphus_check failed. >>>> >>>> Как в таком случае поступать, что решили? >>>> >>>> Почему нет принятой политики закручивания гаек на >>>> https://www.altlinux.org/License_Tag_Policy ? >> Этот вопрос также актуален. > -- Andrey Cherepanov cas@altlinux.org
On Mon, Dec 16, 2019 at 10:50:03AM +0300, Andrey Cherepanov wrote: > 16.12.2019 10:21, Sergey V Turchin пишет: > > On Monday, 16 December 2019 10:01:45 MSK Andrey Cherepanov wrote: > >> /.out/qt-creator-4.11.0-alt1.src.rpm: license not found in > >> '/usr/share/license' directory: > >> GPL-3.0-with-Qt-Company-Qt-exception-1.1 > > В qtbase-5, например: > > LGPL-2.1 with Qt-LGPL-exception-1.1 or LGPL-3.0-only > > Хорошо. GPL-3.0 with Qt-GPL-exception-1.0 and MIT and LGPL-2.0 and > LGPL-2.1 and LGPL-3.0 and BSD-3-Clause > > Где мне в common-licenses найти: > > * Boost Software License, Version 1.0 (для пары расширений Boost) BSL-1.0 > * Public Domain (для забандленного sqlite) ALT-Public-Domain -- Rgrds, legion
Добрый день!
> > * Public Domain (для забандленного sqlite)
> ALT-Public-Domain
Если написано вот так:
-------
PLATON is free of charge for Academics (as all Academic scientific
software should ideally be .....).
For-profit organisations should contact (E-mail address below) or
forward a filled out application form (docx) before copying the
programs.
-------
то что писать в качестве License tag?
--
Всего доброго,
Денис.
On Mon, Dec 16, 2019 at 05:39:46PM +0700, Denis G. Samsonenko wrote:
> Добрый день!
>
> > > * Public Domain (для забандленного sqlite)
> > ALT-Public-Domain
>
> Если написано вот так:
>
> -------
> PLATON is free of charge for Academics (as all Academic scientific
> software should ideally be .....).
> For-profit organisations should contact (E-mail address below) or
> forward a filled out application form (docx) before copying the
> programs.
> -------
>
> то что писать в качестве License tag?
Напишите: ALT-Proprietary-PLATON
--
Rgrds, legion
On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
> Это, в частности, означает, что если в пакете перемешан код под
> GPLv2+, GPLv2-only и какой-нибудь MIT, то у пакета лицензия
> GPLv2-only, и точка. Потому что весь остальной код "автоматически"
> перелицензируется под самую жесткую из лицензий, если может, а
> если не может, то такой пакет нельзя собирать в Сизиф.
Давайте ещё один пример разберём. Пакет nfdump. Основная лицензия
BSD-3-Clause. Но вот libnfdump содержит LZ4 с BSD-2-Clause и miniLZO с
GPL-2.0-or-later. Всё это попадает в один бинарник libnfdump-%version.so.
С libnfdump, согласно вышеотквоченному, понятно - GPL-2.0-or-later.
Вопрос, что с libnfdump-devel? Этого подпакета у nfdump нет по случаю, но
если бы он был, там должны бы были быть lz4.h c BSD-2-Clause и minilzo.h
с GPL-2.0-or-later. И что писать надо было бы в этом случае? Всё же все
три через and?
--
С уважением, Сергей Афонин.
On 2020-03-25 13:55:09 +0400, Sergey Afonin wrote: >> Это, в частности, означает, что если в пакете перемешан код под >> GPLv2+, GPLv2-only и какой-нибудь MIT, то у пакета лицензия >> GPLv2-only, и точка. Потому что весь остальной код "автоматически" >> перелицензируется под самую жесткую из лицензий, если может, а >> если не может, то такой пакет нельзя собирать в Сизиф. > Давайте ещё один пример разберём. Пакет nfdump. Основная лицензия > BSD-3-Clause. Но вот libnfdump содержит LZ4 с BSD-2-Clause и > miniLZO с GPL-2.0-or-later. Всё это попадает в один бинарник > libnfdump-%version.so. С libnfdump, согласно вышеотквоченному, > понятно - GPL-2.0-or-later. > Вопрос, что с libnfdump-devel? Этого подпакета у nfdump нет по > случаю, но если бы он был, там должны бы были быть lz4.h c > BSD-2-Clause и minilzo.h с GPL-2.0-or-later. И что писать надо > было бы в этом случае? Всё же все три через and? Если чистоплюйствовать, то: %package devel-lz4 License: BSD-2-Clause # ... %package devel-minilzo License: GPL-2.0-or-later # ... %package devel Requires: %name-devel-lz4 %name-devel-minilzo # сам пакет может быть вообще пустым Но, по счастью, всем глубоко начхать.. -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
On Wednesday 25 March 2020, Alexey V. Vissarionov wrote: > > Вопрос, что с libnfdump-devel? Этого подпакета у nfdump нет по > > случаю, но если бы он был, там должны бы были быть lz4.h c > > BSD-2-Clause и minilzo.h с GPL-2.0-or-later. И что писать надо > > было бы в этом случае? Всё же все три через and? > > Если чистоплюйствовать, то: > > %package devel-lz4 > License: BSD-2-Clause > # ... > %package devel-minilzo > License: GPL-2.0-or-later > # ... > %package devel > Requires: %name-devel-lz4 %name-devel-minilzo > # сам пакет может быть вообще пустым Да, логично. Но это пока не стал делать. > Но, по счастью, всем глубоко начхать.. Я тут слегка заморочился. :-) Принимаю замечания по спеку в http://git.altlinux.org/tasks/248510 Кстати можно английский там подрихтовать, явно есть, где... -- С уважением, Сергей Афонин.
On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
> Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
> где это что-то такое сказано для Сизифа, но например у коллег из Федоры
> написано чётко:
>
> The License: field refers to the licenses of the contents of the binary
> rpm.
В итоге кто шашкой махнёт? Смотрю сейчас на пакет ntp, в OpenSUSE написано
License: (MIT and BSD-3-Clause and BSD-4-Clause) and GPL-2.0
Явно не вариант RH. И попутно, а код под GPL-3.0 можно под 2.0 перелицензировать ?
А то в ntp/sntp/libopts лежат COPYING.gplv3 и COPYING.lgplv3. И ещё непонятно,
где BSD-2-Clause, в ntp/COPYRIGHT вроде она.
Хотя, похоже, можно писать GPL-3.0-or-later: 2.0, вроде, везде с "or later".
Только есть ещё LGPL 2/2.1 or later. В случае общей лицензии для бинарника
GPL получается, или LGPL?
--
С уважением, Сергей Афонин.
[-- Attachment #1: Type: text/plain, Size: 2035 bytes --] On Fri, 3 Apr 2020 15:07:11 +0400 Sergey Afonin wrote: > On Tuesday 17 March 2020, Ivan A. Melnikov wrote: > И попутно, а код под GPL-3.0 можно под 2.0 перелицензировать ? Нет, нельзя. > Хотя, похоже, можно писать GPL-3.0-or-later: 2.0, вроде, везде с "or later". > Только есть ещё LGPL 2/2.1 or later. В случае общей лицензии для бинарника > GPL получается, или LGPL? Общая лицензия как получается: фактом сборки в один бинарник код перелицензируется под одну из лицензий (за исключением редких случаев двойного лицензирования, которого тут нет) в соответствии с правилами всех этих лицензий. На практике это приводит к перелицензированию под наиболее строгую из лицензий. LGPL разрешает перелицензирование под GPL (при условии соответствия версий), т.е. LGPLv2 only можно перелицензировать в GPLv2 only, но нельзя в GPLv3. GPL перелицензирования под LGPL не разрешает. Поэтому при совмещении LGPL и GPL лицензия бинарника будет GPL соответствующей версии. Если версии кода — смесь LGPL и GPL при этом не совместимы (например, LGPLv2.1 и GPLv3+), то такой бинарник распространять нельзя. Однако, если LGPL код в отдельной библиотеке (а обычно так и делают), то линоваться с ним можно кому угодно, в т.ч. и GPLv3+. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
On Friday 03 April 2020, Andrey Savchenko wrote: > > On Tuesday 17 March 2020, Ivan A. Melnikov wrote: > > И попутно, а код под GPL-3.0 можно под 2.0 перелицензировать ? > > Нет, нельзя. То есть, в OpenSUSE ошибка в любом случае с "and GPL-2.0", раз присутствует GPL 3? Как минимум должно быть "and GPL-3.0-or-later", если всё перечислять? > > Хотя, похоже, можно писать GPL-3.0-or-later: 2.0, вроде, везде с "or later". > > Только есть ещё LGPL 2/2.1 or later. В случае общей лицензии для бинарника > > GPL получается, или LGPL? > > Общая лицензия как получается: фактом сборки в один бинарник код > перелицензируется под одну из лицензий (за исключением редких > случаев двойного лицензирования, которого тут нет) в соответствии > с правилами всех этих лицензий. На практике это приводит к > перелицензированию под наиболее строгую из лицензий. > > LGPL разрешает перелицензирование под GPL (при условии > соответствия версий), т.е. LGPLv2 only можно перелицензировать > в GPLv2 only, но нельзя в GPLv3. GPL перелицензирования под LGPL не > разрешает. Поэтому при совмещении LGPL и GPL лицензия бинарника > будет GPL соответствующей версии. > > Если версии кода — смесь LGPL и GPL при этом не совместимы > (например, LGPLv2.1 и GPLv3+), то такой бинарник распространять > нельзя. Однако, если LGPL код в отдельной библиотеке (а обычно так > и делают), то линоваться с ним можно кому угодно, в т.ч. и GPLv3+. Разделяемых библиотек я в пакете ntp сейчас нет. Но LGPLv2.1 и LGPLv2 присутствуют с пометкой, допускающей следующую версию. Получается, что LGPLv3+ дозволена, а тогда можно писать GPLv3+. Так? -- С уважением, Сергей Афонин
On Fri, Apr 03, 2020 at 06:15:32PM +0400, Sergey Y. Afonin wrote:
> On Friday 03 April 2020, Andrey Savchenko wrote:
>
> > > On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
> > > И попутно, а код под GPL-3.0 можно под 2.0 перелицензировать ?
> >
> > Нет, нельзя.
>
> То есть, в OpenSUSE ошибка в любом случае с "and GPL-2.0", раз присутствует
> GPL 3? Как минимум должно быть "and GPL-3.0-or-later", если всё перечислять?
>
> > > Хотя, похоже, можно писать GPL-3.0-or-later: 2.0, вроде, везде с "or later".
> > > Только есть ещё LGPL 2/2.1 or later. В случае общей лицензии для бинарника
> > > GPL получается, или LGPL?
> >
> > Общая лицензия как получается: фактом сборки в один бинарник код
> > перелицензируется под одну из лицензий (за исключением редких
> > случаев двойного лицензирования, которого тут нет) в соответствии
> > с правилами всех этих лицензий. На практике это приводит к
> > перелицензированию под наиболее строгую из лицензий.
> >
> > LGPL разрешает перелицензирование под GPL (при условии
> > соответствия версий), т.е. LGPLv2 only можно перелицензировать
> > в GPLv2 only, но нельзя в GPLv3. GPL перелицензирования под LGPL не
> > разрешает. Поэтому при совмещении LGPL и GPL лицензия бинарника
> > будет GPL соответствующей версии.
> >
> > Если версии кода — смесь LGPL и GPL при этом не совместимы
> > (например, LGPLv2.1 и GPLv3+), то такой бинарник распространять
> > нельзя. Однако, если LGPL код в отдельной библиотеке (а обычно так
> > и делают), то линоваться с ним можно кому угодно, в т.ч. и GPLv3+.
>
> Разделяемых библиотек я в пакете ntp сейчас нет. Но LGPLv2.1 и LGPLv2
> присутствуют с пометкой, допускающей следующую версию. Получается, что
> LGPLv3+ дозволена, а тогда можно писать GPLv3+. Так?
У нас с лицензиями возникла путаница. Ухудшает картину то, что до сих
пор нет документации и рекомендаций по оформлению тега.
Уже в обсуждении проскальзывало, что лицензии распространяются на
исходный код, поэтому нужно перечислять все лицензии, под которыми этот
исходный код распространяется. А производных бинарников работают другие
правила: их возможно распространять, если все условия лицензий
соблюдены, в частности, нет связывания программного обеспечения с
несовместимыми лицензиями.
--
WBR,
Vladimir D. Seleznev
On Friday 03 April 2020, Vladimir D. Seleznev wrote: > > Разделяемых библиотек я в пакете ntp сейчас нет. Но LGPLv2.1 и LGPLv2 > > присутствуют с пометкой, допускающей следующую версию. Получается, что > > LGPLv3+ дозволена, а тогда можно писать GPLv3+. Так? > > У нас с лицензиями возникла путаница. Ухудшает картину то, что до сих > пор нет документации и рекомендаций по оформлению тега. Это да. Нужно, чтобы кто-то разбирающийся написал. Я хоть и думаю, что что-то понял, но именно, что что-то. А надо точно и с примерами. > Уже в обсуждении проскальзывало, что лицензии распространяются на > исходный код, поэтому нужно перечислять все лицензии, под которыми этот > исходный код распространяется. Это для devel-пакетов, RPM допускает там отдельный тэг. -- С уважением, Сергей Афонин
[-- Attachment #1: Type: text/plain, Size: 1454 bytes --] Доброго времени суток! Предлагаю перевести тег Group в разряд необязательных, устаревших и рекомендовать его к удалению в новых или обновляемых пакетах. Причины: 1) Перечень групп сильно устарел (например, там есть и System/Xfree86, и System/X11). 2) Перечень сильно неполный и не соответсвует современным реалиям (см. /usr/lib/rpm/GROUS). 3) Нередко тег выставляется спорный или к пакету применимы несколько категорий. По-моему, это лишь запутывает пользователей неполной, некорректной и бесполезной информацией. Поэтому предлагаю постепенно от него уйти. Особых проблем с rpm/rpmbuild быть не должно: там всё просто, могут быть завязаны внешние сервисы вроде packages.altlinux.org, но вряд ли там что-то критичное. На всякий посмотрел как в Федоре, там уже давно deprecated: https://fedoraproject.org/wiki/RPMGroups Что думаете? Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
Да, идея напрашивается, но требуется переработка всего софта, в котором
используются группы.
Из сложного там скорее всего synaptic.
Я бы начал с актуализации списка групп.
On 14.07.2022 00:04, Andrey Savchenko wrote:
> Доброго времени суток!
>
> Предлагаю перевести тег Group в разряд необязательных, устаревших
> и рекомендовать его к удалению в новых или обновляемых пакетах.
>
> Причины:
> 1) Перечень групп сильно устарел (например, там есть
> и System/Xfree86, и System/X11).
> 2) Перечень сильно неполный и не соответсвует современным реалиям
> (см. /usr/lib/rpm/GROUS).
> 3) Нередко тег выставляется спорный или к пакету применимы
> несколько категорий.
>
> По-моему, это лишь запутывает пользователей неполной, некорректной
> и бесполезной информацией. Поэтому предлагаю постепенно от него
> уйти. Особых проблем с rpm/rpmbuild быть не должно: там всё просто,
> могут быть завязаны внешние сервисы вроде packages.altlinux.org, но
> вряд ли там что-то критичное.
>
> На всякий посмотрел как в Федоре, там уже давно deprecated:
> https://fedoraproject.org/wiki/RPMGroups
>
> Что думаете?
>
> Best regards,
> Andrew Savchenko
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
On Thursday, 14 July 2022 08:35:29 MSK Anton Farygin wrote:
> Да, идея напрашивается, но требуется переработка всего софта, в котором
> используются группы.
> Из сложного там скорее всего synaptic.
>
> Я бы начал с актуализации списка групп.
Только если это не приведёт к тому, как сейчас с License, т.е. никогда не
будет стремитсья стать обязательным.
Я бы:
1. Оставил поддержку групп.
2. Отключил все проверки на обязательность наличия тега.
3. При сборке переименовывал всякие System/X11 в System/Display, например.
4. Слегка пропатчил бы затронутый софт, чтоб при отсутствии ПКЩГЗ придумыал
его себе сам. Например, "Misc".
[...]
--
Regards, Sergey.
On 14.07.2022 10:24, Sergey V Turchin wrote: > On Thursday, 14 July 2022 08:35:29 MSK Anton Farygin wrote: >> Да, идея напрашивается, но требуется переработка всего софта, в котором >> используются группы. >> Из сложного там скорее всего synaptic. >> >> Я бы начал с актуализации списка групп. > Только если это не приведёт к тому, как сейчас с License, т.е. никогда не > будет стремитсья стать обязательным. Группы уже обязательные (как и соответствие группам) > > Я бы: > 1. Оставил поддержку групп. > 2. Отключил все проверки на обязательность наличия тега. Для начала проверить весь софт, как он переживёт осутствие группы. > 3. При сборке переименовывал всякие System/X11 в System/Display, например. > 4. Слегка пропатчил бы затронутый софт, чтоб при отсутствии ПКЩГЗ придумыал > его себе сам. Например, "Misc". > > [...] >
On Thursday, 14 July 2022 11:16:12 MSK Anton Farygin wrote: > On 14.07.2022 10:24, Sergey V Turchin wrote: > > On Thursday, 14 July 2022 08:35:29 MSK Anton Farygin wrote: > >> Да, идея напрашивается, но требуется переработка всего софта, в котором > >> используются группы. > >> Из сложного там скорее всего synaptic. > >> > >> Я бы начал с актуализации списка групп. > > > > Только если это не приведёт к тому, как сейчас с License, т.е. никогда не > > будет стремитсья стать обязательным. > Группы уже обязательные (как и соответствие группам) Ещё. И не только необязательны, но и запрещены. Речь про пока несуществующие группы, которые возникнут после актуализации. А SPDX в License ещё не обязателен, но когда-то будет, иначе он нафиг не нужон. > > Я бы: > > 1. Оставил поддержку групп. > > 2. Отключил все проверки на обязательность наличия тега. > Для начала проверить весь софт, как он переживёт осутствие группы. Ну да. Сперва п.4 . > > 3. При сборке переименовывал всякие System/X11 в System/Display, например. > > 4. Слегка пропатчил бы затронутый софт, чтоб при отсутствии ПКЩГЗ > > придумыал > > его себе сам. Например, "Misc". > > > > [...] > > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel -- Regards, Sergey.
On Thu, Jul 14, 2022 at 12:04:40AM +0300, Andrey Savchenko wrote:
> Доброго времени суток!
>
> Предлагаю перевести тег Group в разряд необязательных, устаревших
> и рекомендовать его к удалению в новых или обновляемых пакетах.
>
> Причины:
> 1) Перечень групп сильно устарел (например, там есть
> и System/Xfree86, и System/X11).
> 2) Перечень сильно неполный и не соответсвует современным реалиям
> (см. /usr/lib/rpm/GROUS).
> 3) Нередко тег выставляется спорный или к пакету применимы
> несколько категорий.
>
> По-моему, это лишь запутывает пользователей неполной, некорректной
> и бесполезной информацией. Поэтому предлагаю постепенно от него
> уйти. Особых проблем с rpm/rpmbuild быть не должно: там всё просто,
> могут быть завязаны внешние сервисы вроде packages.altlinux.org, но
> вряд ли там что-то критичное.
>
> На всякий посмотрел как в Федоре, там уже давно deprecated:
> https://fedoraproject.org/wiki/RPMGroups
>
> Что думаете?
Я очень не люблю изменений ради изменений.
Не могу сказать, что тег Group мне дорог, но мне бы не хотелось, чтобы
1. сломались какие-то приложения вроде synaptic, наткнувшись на пакет без
этого тэга;
2. кто-то потом пришёл с патчами по удалению тэга Group из спеков.
Если решить первый вопрос, то можно будет сперва сделать тег Group
необязательным, а потом и вовсе его игнорировать в спеке.
--
ldv
14.07.2022 11:33, Sergey V Turchin пишет:
> On Thursday, 14 July 2022 11:16:12 MSK Anton Farygin wrote:
>> On 14.07.2022 10:24, Sergey V Turchin wrote:
>>> On Thursday, 14 July 2022 08:35:29 MSK Anton Farygin wrote:
>>>> Да, идея напрашивается, но требуется переработка всего софта, в котором
>>>> используются группы.
>>>> Из сложного там скорее всего synaptic.
>>>>
>>>> Я бы начал с актуализации списка групп.
>>>
>>> Только если это не приведёт к тому, как сейчас с License, т.е. никогда не
>>> будет стремитсья стать обязательным.
>> Группы уже обязательные (как и соответствие группам)
> Ещё. И не только необязательны, но и запрещены. Речь про пока несуществующие
> группы, которые возникнут после актуализации.
> А SPDX в License ещё не обязателен, но когда-то будет, иначе он нафиг не
> нужон.
Не вижу особого смысла в удалении групп. Как я понимаю, смысл групп
всегда был в поиске пользователя подходящего пакета и изучении из каких
пакетов состоит система и для чего тот или иной пакетв приложениях типа
aptitude synaptic и т.п. Этот смыл как был, так и остался. Я бы только
актуализировал название групп, если их название сильно устарело.
В новых названиих групп, я-бы ориентировался на стандарт меню
приложений, что-бы название группы коррелировало с группами меню.
Даже если пакет не имеет десктоп файлов, всё равно можно ориентироваться
на этот стандарт, как-бы его расширяя, ведь любая библиотека служит для
определённых приложений.
А вот для консольных приложений можно подумать о том, в какую-бы группу
оно вошло, будь у неё десктоп файл.
Или возможно какая-то большая группа типа no-menu с подгруппами, как в
остальных группах.
При таком принципе пользователю легче понимать где в меню может
оказаться то или иное приложение, или для каких приложений нужна та, или
иная библиотека.
И я бы оставил обязательность групп, это дисциплинирует мантейнера.
[-- Attachment #1: Type: text/plain, Size: 2967 bytes --] On Sat, 16 Jul 2022 06:11:37 +0300 P X wrote: > 14.07.2022 11:33, Sergey V Turchin пишет: > > On Thursday, 14 July 2022 11:16:12 MSK Anton Farygin wrote: > >> On 14.07.2022 10:24, Sergey V Turchin wrote: > >>> On Thursday, 14 July 2022 08:35:29 MSK Anton Farygin wrote: > >>>> Да, идея напрашивается, но требуется переработка всего софта, в котором > >>>> используются группы. > >>>> Из сложного там скорее всего synaptic. > >>>> > >>>> Я бы начал с актуализации списка групп. Смысл актуализировать то, что будет удаляться? > >>> Только если это не приведёт к тому, как сейчас с License, т.е. никогда не > >>> будет стремитсья стать обязательным. > >> Группы уже обязательные (как и соответствие группам) > > Ещё. И не только необязательны, но и запрещены. Речь про пока несуществующие > > группы, которые возникнут после актуализации. > > А SPDX в License ещё не обязателен, но когда-то будет, иначе он нафиг не > > нужон. SPDX опасен: one ring to rule them all. Удобный повод блокировать неугодные лицензии. Не стоит его навязывать, особенно когда нет всецелого доверия к управляющей организации, управляемой корпорациями, а не сообществом. > Не вижу особого смысла в удалении групп. Как я понимаю, смысл групп > всегда был в поиске пользователя подходящего пакета и изучении из каких > пакетов состоит система и для чего тот или иной пакетв приложениях типа > aptitude synaptic и т.п. Этот смыл как был, так и остался. Однозначная классификация принципиально невозможна, текущая система лишь запутывает пользователей и создаёт лишнии проблемы мейнтенерам. Лучше тогда облако тегов добавить (массив ключевых слов), но под это придётся переделывать софт. > И я бы оставил обязательность групп, это дисциплинирует мантейнера. Чем дисциплинирует? Создаёт лишнюю волокиту? Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2758 bytes --] On Fri, 15 Jul 2022 20:18:41 +0300 Dmitry V. Levin wrote: > On Thu, Jul 14, 2022 at 12:04:40AM +0300, Andrey Savchenko wrote: > > Доброго времени суток! > > > > Предлагаю перевести тег Group в разряд необязательных, устаревших > > и рекомендовать его к удалению в новых или обновляемых пакетах. > > > > Причины: > > 1) Перечень групп сильно устарел (например, там есть > > и System/Xfree86, и System/X11). > > 2) Перечень сильно неполный и не соответсвует современным реалиям > > (см. /usr/lib/rpm/GROUS). > > 3) Нередко тег выставляется спорный или к пакету применимы > > несколько категорий. > > > > По-моему, это лишь запутывает пользователей неполной, некорректной > > и бесполезной информацией. Поэтому предлагаю постепенно от него > > уйти. Особых проблем с rpm/rpmbuild быть не должно: там всё просто, > > могут быть завязаны внешние сервисы вроде packages.altlinux.org, но > > вряд ли там что-то критичное. > > > > На всякий посмотрел как в Федоре, там уже давно deprecated: > > https://fedoraproject.org/wiki/RPMGroups > > > > Что думаете? > > Я очень не люблю изменений ради изменений. > > Не могу сказать, что тег Group мне дорог, но мне бы не хотелось, чтобы > 1. сломались какие-то приложения вроде synaptic, наткнувшись на пакет без > этого тэга; > 2. кто-то потом пришёл с патчами по удалению тэга Group из спеков. > > Если решить первый вопрос, то можно будет сперва сделать тег Group > необязательным, а потом и вовсе его игнорировать в спеке. Я думаю, что достаточно в Synaptic вставить заглушку Unclassified, если нет тега. Удалять Group из спеков только ради этой операции действительно не стоит, но при внесении иных изменений вполне можно совмещать. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
On Sat, Jul 16, 2022 at 01:05:41PM +0300, Andrey Savchenko wrote:
[...]
> SPDX опасен: one ring to rule them all. Удобный повод блокировать
> неугодные лицензии. Не стоит его навязывать, особенно когда нет
> всецелого доверия к управляющей организации, управляемой
> корпорациями, а не сообществом.
Мне кажется, что это проблема надуманная: спецификация SPDX
предусматривает расширения, и у нас уже есть /usr/share/license/ALT-*.
--
ldv
On 16.07.2022 13:53, Dmitry V. Levin wrote: > On Sat, Jul 16, 2022 at 01:05:41PM +0300, Andrey Savchenko wrote: > [...] >> SPDX опасен: one ring to rule them all. Удобный повод блокировать >> неугодные лицензии. Не стоит его навязывать, особенно когда нет >> всецелого доверия к управляющей организации, управляемой >> корпорациями, а не сообществом. > Мне кажется, что это проблема надуманная: спецификация SPDX > предусматривает расширения, и у нас уже есть /usr/share/license/ALT-*. SPDX никак не связан с возможностью блокировать неугодные лизенции, т.к. есть и другие способы вычисления лицензий в проектах. SPDX скорее удобен чем неудобен, т.к. по сути является стандартом описания лицензии. Например, благодаря ему мы сделали кликабельным лицензии и добавили в базу тексты: https://beta.packages.altlinux.org/ru/sisyphus/srpms/dbeaver/2826003590463999447
On 16.07.2022 13:05, Andrey Savchenko wrote:
> On Sat, 16 Jul 2022 06:11:37 +0300 P X wrote:
>> 14.07.2022 11:33, Sergey V Turchin пишет:
>>> On Thursday, 14 July 2022 11:16:12 MSK Anton Farygin wrote:
>>>> On 14.07.2022 10:24, Sergey V Turchin wrote:
>>>>> On Thursday, 14 July 2022 08:35:29 MSK Anton Farygin wrote:
>>>>>> Да, идея напрашивается, но требуется переработка всего софта, в котором
>>>>>> используются группы.
>>>>>> Из сложного там скорее всего synaptic.
>>>>>>
>>>>>> Я бы начал с актуализации списка групп.
> Смысл актуализировать то, что будет удаляться?
>
Для того, что бы понять, что группу можно не удалять, если начать ей
пользоваться.
На самом деле группировку можно в значительной степени, если не
полностью, автоматизировать.
On Sat, Jul 16, 2022 at 07:28:25PM +0300, Anton Farygin wrote:
> On 16.07.2022 13:53, Dmitry V. Levin wrote:
> > On Sat, Jul 16, 2022 at 01:05:41PM +0300, Andrey Savchenko wrote:
> > [...]
> >> SPDX опасен: one ring to rule them all. Удобный повод блокировать
> >> неугодные лицензии. Не стоит его навязывать, особенно когда нет
> >> всецелого доверия к управляющей организации, управляемой
> >> корпорациями, а не сообществом.
> > Мне кажется, что это проблема надуманная: спецификация SPDX
> > предусматривает расширения, и у нас уже есть /usr/share/license/ALT-*.
>
> SPDX никак не связан с возможностью блокировать неугодные лизенции, т.к.
> есть и другие способы вычисления лицензий в проектах.
>
> SPDX скорее удобен чем неудобен, т.к. по сути является стандартом
> описания лицензии.
>
> Например, благодаря ему мы сделали кликабельным лицензии и добавили в
> базу тексты:
>
> https://beta.packages.altlinux.org/ru/sisyphus/srpms/dbeaver/2826003590463999447
А можно посчитать сколько пакетов имеют не common-licenses совместимую
лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ?
--
Rgrds, legion
[-- Attachment #1: Type: text/plain, Size: 2947 bytes --] On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote: > On Sat, Jul 16, 2022 at 07:28:25PM +0300, Anton Farygin wrote: > > On 16.07.2022 13:53, Dmitry V. Levin wrote: > > > On Sat, Jul 16, 2022 at 01:05:41PM +0300, Andrey Savchenko wrote: > > > [...] > > >> SPDX опасен: one ring to rule them all. Удобный повод блокировать > > >> неугодные лицензии. Не стоит его навязывать, особенно когда нет > > >> всецелого доверия к управляющей организации, управляемой > > >> корпорациями, а не сообществом. > > > Мне кажется, что это проблема надуманная: спецификация SPDX > > > предусматривает расширения, и у нас уже есть /usr/share/license/ALT-*. > > > > SPDX никак не связан с возможностью блокировать неугодные лизенции, т.к. > > есть и другие способы вычисления лицензий в проектах. > > > > SPDX скорее удобен чем неудобен, т.к. по сути является стандартом > > описания лицензии. > > > > Например, благодаря ему мы сделали кликабельным лицензии и добавили в > > базу тексты: > > > > https://beta.packages.altlinux.org/ru/sisyphus/srpms/dbeaver/2826003590463999447 > > А можно посчитать сколько пакетов имеют не common-licenses совместимую > лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ? А можно сперва обеспечить доступный каждому мейнтенеру механизм добавления лицензий? И да, в самом common-licenses полно ошибок, особенно в механизме исключений. Да и лицензии большинства подпакетов указаны некорректно, т.к. наследуют лицензии родительского пакета, а могут содержать лишь какую-то часть под одной лицензией. Даже для составляющих gcc они указаны некорректно. Более того, лицензии на srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL в исходниках и только GPL в результирующем бинарнике), но у нас нет даже механизма для обеспечения такого отличия. Но это борьба с ветряными мельницами. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
On 2022-07-16 19:25:18 +0200, Alexey Gladkov wrote: >> SPDX скорее удобен чем неудобен, т.к. по сути является >> стандартом описания лицензии. > А можно посчитать сколько пакетов имеют не common-licenses > совместимую лицензию ? Может пора сделать в sisyphus_check > варнинг ошибкой ? И тем самым перекрыть себе возможность собирать софт со свободной, но своей собственной лицензией? Не самое мудрое решение... -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote: > On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote: [...] > > А можно посчитать сколько пакетов имеют не common-licenses совместимую > > лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ? > > А можно сперва обеспечить доступный каждому мейнтенеру механизм > добавления лицензий? > > И да, в самом common-licenses полно ошибок, особенно в механизме > исключений. Например? -- ldv
On Sun, Jul 17, 2022 at 01:55:54PM +0300, Alexey V. Vissarionov wrote:
> On 2022-07-16 19:25:18 +0200, Alexey Gladkov wrote:
>
> >> SPDX скорее удобен чем неудобен, т.к. по сути является
> >> стандартом описания лицензии.
> > А можно посчитать сколько пакетов имеют не common-licenses
> > совместимую лицензию ? Может пора сделать в sisyphus_check
> > варнинг ошибкой ?
>
> И тем самым перекрыть себе возможность собирать софт со
> свободной, но своей собственной лицензией?
>
> Не самое мудрое решение...
Не самое мудрое решение изобретать свою лицензию, но если есть настолько
амбициозный разработчик, то его лицензию просто необходимо проверить на
соответствие свободности.
Как и раньше у нас есть механизм для добавления лицензий в
common-licenses. Мантейнер пакета с такой уникальной лицензией может
обратиться в багзиллу и добавить лицензию.
В общем-то я не вижу какой-то уникальности в этом случае.
--
Rgrds, legion
On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote: > On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote: > > On Sat, Jul 16, 2022 at 07:28:25PM +0300, Anton Farygin wrote: > > > On 16.07.2022 13:53, Dmitry V. Levin wrote: > > > > On Sat, Jul 16, 2022 at 01:05:41PM +0300, Andrey Savchenko wrote: > > > > [...] > > > >> SPDX опасен: one ring to rule them all. Удобный повод блокировать > > > >> неугодные лицензии. Не стоит его навязывать, особенно когда нет > > > >> всецелого доверия к управляющей организации, управляемой > > > >> корпорациями, а не сообществом. > > > > Мне кажется, что это проблема надуманная: спецификация SPDX > > > > предусматривает расширения, и у нас уже есть /usr/share/license/ALT-*. > > > > > > SPDX никак не связан с возможностью блокировать неугодные лизенции, т.к. > > > есть и другие способы вычисления лицензий в проектах. > > > > > > SPDX скорее удобен чем неудобен, т.к. по сути является стандартом > > > описания лицензии. > > > > > > Например, благодаря ему мы сделали кликабельным лицензии и добавили в > > > базу тексты: > > > > > > https://beta.packages.altlinux.org/ru/sisyphus/srpms/dbeaver/2826003590463999447 > > > > А можно посчитать сколько пакетов имеют не common-licenses совместимую > > лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ? > > А можно сперва обеспечить доступный каждому мейнтенеру механизм > добавления лицензий? Механизм есть. Бага в багзилле на пакет common-licenses. Этот механизм уже использовался не раз. > И да, в самом common-licenses полно ошибок, особенно в механизме > исключений. Да и лицензии большинства подпакетов указаны > некорректно, т.к. наследуют лицензии родительского пакета, а могут > содержать лишь какую-то часть под одной лицензией. Даже для > составляющих gcc они указаны некорректно. Более того, лицензии на > srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL > в исходниках и только GPL в результирующем бинарнике), но у нас нет > даже механизма для обеспечения такого отличия. Тэг License может быть указан в подпакетах. Это позволяет указать разные лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем. Либо я не понял вас. -- Rgrds, legion
On Sun, Jul 17, 2022 at 02:15:06PM +0200, Alexey Gladkov wrote: > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote: [...] > > Более того, лицензии на > > srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL > > в исходниках и только GPL в результирующем бинарнике), но у нас нет > > даже механизма для обеспечения такого отличия. > > Тэг License может быть указан в подпакетах. Это позволяет указать разные > лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем. > Либо я не понял вас. Наверное, речь идёт о том, что нет возможности указать разные лицензии для исходного пакета и для собранного из него одноимённого бинарного. -- ldv
On Sun, Jul 17, 2022 at 04:03:04PM +0300, Dmitry V. Levin wrote:
> On Sun, Jul 17, 2022 at 02:15:06PM +0200, Alexey Gladkov wrote:
> > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> [...]
> > > Более того, лицензии на
> > > srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL
> > > в исходниках и только GPL в результирующем бинарнике), но у нас нет
> > > даже механизма для обеспечения такого отличия.
> >
> > Тэг License может быть указан в подпакетах. Это позволяет указать разные
> > лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем.
> > Либо я не понял вас.
>
> Наверное, речь идёт о том, что нет возможности указать разные лицензии
> для исходного пакета и для собранного из него одноимённого бинарного.
Обычно лицензии совпадают. Но если это не так, то нужно переименовывать
либо исходный, либо бинарный пакет.
Возможно такой подход не очевиден или не удобен, но нельзя говорить, что
у нас нет механизма для обеспечения такого отличия.
--
Rgrds, legion
On Sun, Jul 17, 2022 at 03:11:39PM +0200, Alexey Gladkov wrote:
> On Sun, Jul 17, 2022 at 04:03:04PM +0300, Dmitry V. Levin wrote:
> > On Sun, Jul 17, 2022 at 02:15:06PM +0200, Alexey Gladkov wrote:
> > > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> > [...]
> > > > Более того, лицензии на
> > > > srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL
> > > > в исходниках и только GPL в результирующем бинарнике), но у нас нет
> > > > даже механизма для обеспечения такого отличия.
> > >
> > > Тэг License может быть указан в подпакетах. Это позволяет указать разные
> > > лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем.
> > > Либо я не понял вас.
> >
> > Наверное, речь идёт о том, что нет возможности указать разные лицензии
> > для исходного пакета и для собранного из него одноимённого бинарного.
>
> Обычно лицензии совпадают. Но если это не так, то нужно переименовывать
> либо исходный, либо бинарный пакет.
Часто бывает, что из исходного пакета собирается несколько бинарных,
в том числе один одноимённый, причём лицензии бинарных пакетов являются
подмножеством исходного, например, из исходного пакета собирается library
под лицензией LGPL-3.0-or-later и executable под лицензией
GPL-3.0-or-later. В такой ситуации бывает, что и переименовывать
не во что.
--
ldv
On Sun, Jul 17, 2022 at 04:25:01PM +0300, Dmitry V. Levin wrote:
> On Sun, Jul 17, 2022 at 03:11:39PM +0200, Alexey Gladkov wrote:
> > On Sun, Jul 17, 2022 at 04:03:04PM +0300, Dmitry V. Levin wrote:
> > > On Sun, Jul 17, 2022 at 02:15:06PM +0200, Alexey Gladkov wrote:
> > > > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> > > [...]
> > > > > Более того, лицензии на
> > > > > srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL
> > > > > в исходниках и только GPL в результирующем бинарнике), но у нас нет
> > > > > даже механизма для обеспечения такого отличия.
> > > >
> > > > Тэг License может быть указан в подпакетах. Это позволяет указать разные
> > > > лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем.
> > > > Либо я не понял вас.
> > >
> > > Наверное, речь идёт о том, что нет возможности указать разные лицензии
> > > для исходного пакета и для собранного из него одноимённого бинарного.
> >
> > Обычно лицензии совпадают. Но если это не так, то нужно переименовывать
> > либо исходный, либо бинарный пакет.
>
> Часто бывает, что из исходного пакета собирается несколько бинарных,
> в том числе один одноимённый, причём лицензии бинарных пакетов являются
> подмножеством исходного, например, из исходного пакета собирается library
> под лицензией LGPL-3.0-or-later и executable под лицензией
> GPL-3.0-or-later. В такой ситуации бывает, что и переименовывать
> не во что.
Придумать можно, но повторюсь, что я согласен, что не очень удобно это.
Может быть ввести тэг License-src какой-нибудь ?
--
Rgrds, legion
On Sun, Jul 17, 2022 at 03:38:37PM +0200, Alexey Gladkov wrote:
> > > > Наверное, речь идёт о том, что нет возможности указать разные лицензии
> > > > для исходного пакета и для собранного из него одноимённого бинарного.
> > >
> > > Обычно лицензии совпадают. Но если это не так, то нужно переименовывать
> > > либо исходный, либо бинарный пакет.
> >
> > Часто бывает, что из исходного пакета собирается несколько бинарных,
> > в том числе один одноимённый, причём лицензии бинарных пакетов являются
> > подмножеством исходного, например, из исходного пакета собирается library
> > под лицензией LGPL-3.0-or-later и executable под лицензией
> > GPL-3.0-or-later. В такой ситуации бывает, что и переименовывать
> > не во что.
>
> Придумать можно, но повторюсь, что я согласен, что не очень удобно это.
>
> Может быть ввести тэг License-src какой-нибудь ?
Ну или забить вообще на эти лицензии. Потому что складывается ощущение,
что это всё нафиг никому не нужно.
--
Rgrds, legion
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --] On Sun, 17 Jul 2022 14:19:19 +0300 Dmitry V. Levin wrote: > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote: > > On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote: > [...] > > > А можно посчитать сколько пакетов имеют не common-licenses совместимую > > > лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ? > > > > А можно сперва обеспечить доступный каждому мейнтенеру механизм > > добавления лицензий? > > > > И да, в самом common-licenses полно ошибок, особенно в механизме > > исключений. > > Например? У gcc больше исключений, чем есть в common-licenses. Я когда-то на это напоролся и оставил в стороне, т.к. лицензии на подпакеты, в частности библиотеки некорретны (избыточны). С openssl тоже: там куда больше исключений, чем openvpn и все они типовые. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3660 bytes --] On Sun, 17 Jul 2022 15:38:37 +0200 Alexey Gladkov wrote: > On Sun, Jul 17, 2022 at 04:25:01PM +0300, Dmitry V. Levin wrote: > > On Sun, Jul 17, 2022 at 03:11:39PM +0200, Alexey Gladkov wrote: > > > On Sun, Jul 17, 2022 at 04:03:04PM +0300, Dmitry V. Levin wrote: > > > > On Sun, Jul 17, 2022 at 02:15:06PM +0200, Alexey Gladkov wrote: > > > > > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote: > > > > [...] > > > > > > Более того, лицензии на > > > > > > srpm и rpm в большинстве сучаев отличаются (например, BSD+MIT+GPL > > > > > > в исходниках и только GPL в результирующем бинарнике), но у нас нет > > > > > > даже механизма для обеспечения такого отличия. > > > > > > > > > > Тэг License может быть указан в подпакетах. Это позволяет указать разные > > > > > лицензии на srpm и rpm'ы. Я только что попробовал и не увидел проблем. > > > > > Либо я не понял вас. > > > > > > > > Наверное, речь идёт о том, что нет возможности указать разные лицензии > > > > для исходного пакета и для собранного из него одноимённого бинарного. > > > > > > Обычно лицензии совпадают. Но если это не так, то нужно переименовывать > > > либо исходный, либо бинарный пакет. > > > > Часто бывает, что из исходного пакета собирается несколько бинарных, > > в том числе один одноимённый, причём лицензии бинарных пакетов являются > > подмножеством исходного, например, из исходного пакета собирается library > > под лицензией LGPL-3.0-or-later и executable под лицензией > > GPL-3.0-or-later. В такой ситуации бывает, что и переименовывать > > не во что. > > Придумать можно, но повторюсь, что я согласен, что не очень удобно это. > > Может быть ввести тэг License-src какой-нибудь ? Это хорошая идея, но можно пойти дальше и упростить мейнтенерам жизнь. Лицензия на src.rpm будет включать в себя все лицензии подпакетов, но может и иметь дополнительные (например, софт GPL, а инструменты для сборки (configure, am) BSD). Думаю, что ситуация, когда в бинарном пакете или подпакете есть лицензия, которая не попадает распространяется на пакет с исходном нереалистична. Поэтому можно автоформировать License у srpm как объединение множеств всех лицензий (под)пакетов и добавить тег вида License-src-extra для указания дополнительных лицензий, которые есть только в исходниках, но не попадают в бинарные пакеты. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
On 2022-07-17 15:40:55 +0200, Alexey Gladkov wrote: >>> Часто бывает, что из исходного пакета собирается несколько >>> бинарных, в том числе один одноимённый, причём лицензии >>> бинарных пакетов являются подмножеством исходного, например, >>> из исходного пакета собирается library под лицензией >>> LGPL-3.0-or-later и executable под лицензией >>> GPL-3.0-or-later. В такой ситуации бывает, что и >>> переименовывать не во что. >> Придумать можно, но повторюсь, что я согласен, что не очень >> удобно это. >> Может быть ввести тэг License-src какой-нибудь ? > Ну или забить вообще на эти лицензии. Потому что складывается > ощущение, что это всё нафиг никому не нужно. По большому счету - да: лично я не знаю ни одного случая, чтобы типовой пользователь отказался от установки софта из-за того, что ему не нравится определенная свободная лицензия. Нетиповые могут, но их пренебрежимо мало. Так что вполне можно оставить решение этого вопроса на усмотрение мейнтейнеров. А нынешние предупреждения... да в общем-то пусть будут: вреда от них никакого, а польза бывает. -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
On 2022-07-17 17:39:47 +0300, Andrey Savchenko wrote: >> Придумать можно, но повторюсь, что я согласен, что не очень >> удобно это. >> Может быть ввести тэг License-src какой-нибудь ? > Это хорошая идея, Я все больше склоняюсь к мысли, что это был сарказм. > но можно пойти дальше и упростить мейнтенерам жизнь. Прочитал, общую идею уловил. Сколько часов в месяц это сэкономит типовому мейнтейнеру? И каким образом? -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
On 2022-07-17 13:58:32 +0200, Alexey Gladkov wrote: >>>> SPDX скорее удобен чем неудобен, т.к. по сути является >>>> стандартом описания лицензии. >>> А можно посчитать сколько пакетов имеют не common-licenses >>> совместимую лицензию ? Может пора сделать в sisyphus_check >>> варнинг ошибкой ? >> И тем самым перекрыть себе возможность собирать софт со >> свободной, но своей собственной лицензией? >> Не самое мудрое решение... > Не самое мудрое решение изобретать свою лицензию, но если > есть настолько амбициозный разработчик, то его лицензию > просто необходимо проверить на соответствие свободности. Случаи бывают всякие. Помнится, году этак в 2004...2005 мне нужно было передать своему тогдашнему работодателю кое-какой код, и если бы я не нашел (ныне мою любимую) WTFPL, которая появилась буквально за полгода до описываемых событий, я бы ее просто придумал сам. И да: лицензия - свободнее не бывает. > Как и раньше у нас есть механизм для добавления лицензий > в common-licenses. Мантейнер пакета с такой уникальной > лицензией может обратиться в багзиллу и добавить лицензию. > В общем-то я не вижу какой-то уникальности в этом случае. Трата времени. Пусть однократная, но все же. -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
On Sun, Jul 17, 2022 at 11:46:15PM +0300, Alexey V. Vissarionov wrote: > On 2022-07-17 15:40:55 +0200, Alexey Gladkov wrote: > > >>> Часто бывает, что из исходного пакета собирается несколько > >>> бинарных, в том числе один одноимённый, причём лицензии > >>> бинарных пакетов являются подмножеством исходного, например, > >>> из исходного пакета собирается library под лицензией > >>> LGPL-3.0-or-later и executable под лицензией > >>> GPL-3.0-or-later. В такой ситуации бывает, что и > >>> переименовывать не во что. > >> Придумать можно, но повторюсь, что я согласен, что не очень > >> удобно это. > >> Может быть ввести тэг License-src какой-нибудь ? > > Ну или забить вообще на эти лицензии. Потому что складывается > > ощущение, что это всё нафиг никому не нужно. > > По большому счету - да: лично я не знаю ни одного случая, чтобы > типовой пользователь отказался от установки софта из-за того, > что ему не нравится определенная свободная лицензия. Нетиповые > могут, но их пренебрежимо мало. Вы вероятно не знаете, но в common-licenses у нас не только свободные лицензии, а в репозиториях не только свободные пакеты. Некоторые пакеты можно использовать только на определённых условиях. > Так что вполне можно оставить решение этого вопроса на усмотрение > мейнтейнеров. А нынешние предупреждения... да в общем-то пусть > будут: вреда от них никакого, а польза бывает. > > > -- > Alexey V. Vissarionov > gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii > GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel -- Rgrds, legion
[-- Attachment #1: Type: text/plain, Size: 1553 bytes --] On Sun, 17 Jul 2022 23:55:02 +0300 Alexey V. Vissarionov wrote: > On 2022-07-17 17:39:47 +0300, Andrey Savchenko wrote: > > > но можно пойти дальше и упростить мейнтенерам жизнь. > > Прочитал, общую идею уловил. Сколько часов в месяц это сэкономит > типовому мейнтейнеру? Зависит от активности мейнтенера: сколько событий при которых необходим анализ лицензии происходит. Это как минимум добавления новых пакетов или серьёзные изменения имеющихся. Трудозатраты на одно такое событие зависят от размера и качества пакета, но в целом в нулевом порядке приближения я бы оценил экономию в 20 минут на событие. Если проверка на наличие лицензии в common-licenses будет обязательной, то такие события наступят разово для всех пакетов. > И каким образом? Экономия достигается за счёт того, что не нужно вручную указывать лицензию для srpm в типовых случаях, а в нетиповых работы будет меньше. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1534 bytes --] On Sun, 17 Jul 2022 14:15:06 +0200 Alexey Gladkov wrote: > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote: > > On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote: > > > А можно посчитать сколько пакетов имеют не common-licenses совместимую > > > лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ? > > > > А можно сперва обеспечить доступный каждому мейнтенеру механизм > > добавления лицензий? > > Механизм есть. Бага в багзилле на пакет common-licenses. Этот механизм уже > использовался не раз. Если это штатный механизм, то нужно SLA по нему, чтоб люди не ждали годами[1] добавления лицензии. [1] https://bugzilla.altlinux.org/38953 Я думаю, что неделя - разумный срок, т.к. невозможность добавления лицензии блокирует работы по пакету (это может быть как добавление пакета, так и обновление, при котором сменилась лицензия или просто исправление ранее не вполне корректно указанной информации о лицензии). Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
On 2022-07-18 00:35:11 +0200, Alexey Gladkov wrote: >>>> Может быть ввести тэг License-src какой-нибудь ? >>> Ну или забить вообще на эти лицензии. Потому что складывается >>> ощущение, что это всё нафиг никому не нужно. >> По большому счету - да: лично я не знаю ни одного случая, чтобы >> типовой пользователь отказался от установки софта из-за того, >> что ему не нравится определенная свободная лицензия. Нетиповые >> могут, но их пренебрежимо мало. > Вы вероятно не знаете, но в common-licenses у нас не только > свободные лицензии, а в репозиториях не только свободные пакеты. Ну ладно: s/свободная/distributable/ Что-то принципиально меняется? На мой взгляд - ничего, причем в точности по той же причине: идейных пренебрежимо мало. > Некоторые пакеты можно использовать только на определённых > условиях. Много вы знаете пользователей, которые внимательно изучают эти условия? Большинству из них вообще нет дела до каких-то там лицензий, а почти всем остальным хватает "distributable - ну и хорошо". >> Так что вполне можно оставить решение этого вопроса на >> усмотрение мейнтейнеров. А нынешние предупреждения... >> да в общем-то пусть будут: вреда от них никакого, а польза >> бывает. Здесь, насколько я понимаю, возражений нет? -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
On Mon, Jul 18, 2022 at 10:03:19AM +0300, Andrey Savchenko wrote:
> On Sun, 17 Jul 2022 14:15:06 +0200 Alexey Gladkov wrote:
> > On Sun, Jul 17, 2022 at 11:09:18AM +0300, Andrey Savchenko wrote:
> > > On Sat, 16 Jul 2022 19:25:18 +0200 Alexey Gladkov wrote:
> > > > А можно посчитать сколько пакетов имеют не common-licenses совместимую
> > > > лицензию ? Может пора сделать в sisyphus_check варнинг ошибкой ?
> > >
> > > А можно сперва обеспечить доступный каждому мейнтенеру механизм
> > > добавления лицензий?
> >
> > Механизм есть. Бага в багзилле на пакет common-licenses. Этот механизм уже
> > использовался не раз.
>
> Если это штатный механизм, то нужно SLA по нему, чтоб люди не ждали
> годами[1] добавления лицензии.
>
> [1] https://bugzilla.altlinux.org/38953
>
> Я думаю, что неделя - разумный срок, т.к. невозможность добавления
> лицензии блокирует работы по пакету (это может быть как добавление
> пакета, так и обновление, при котором сменилась лицензия или просто
> исправление ранее не вполне корректно указанной информации о
> лицензии).
Судя по истории изменений я просто не заметил этой баги. Да, если за
неделю не произошло реакции я думаю можно поднимать приоритет и пинать.
--
Rgrds, legion
On Mon, Jul 18, 2022 at 11:18:06AM +0300, Alexey V. Vissarionov wrote:
> On 2022-07-18 00:35:11 +0200, Alexey Gladkov wrote:
>
> >>>> Может быть ввести тэг License-src какой-нибудь ?
> >>> Ну или забить вообще на эти лицензии. Потому что складывается
> >>> ощущение, что это всё нафиг никому не нужно.
> >> По большому счету - да: лично я не знаю ни одного случая, чтобы
> >> типовой пользователь отказался от установки софта из-за того,
> >> что ему не нравится определенная свободная лицензия. Нетиповые
> >> могут, но их пренебрежимо мало.
> > Вы вероятно не знаете, но в common-licenses у нас не только
> > свободные лицензии, а в репозиториях не только свободные пакеты.
>
> Ну ладно: s/свободная/distributable/
> Что-то принципиально меняется? На мой взгляд - ничего, причем в
> точности по той же причине: идейных пренебрежимо мало.
>
> > Некоторые пакеты можно использовать только на определённых
> > условиях.
>
> Много вы знаете пользователей, которые внимательно изучают эти
> условия? Большинству из них вообще нет дела до каких-то там
> лицензий, а почти всем остальным хватает "distributable - ну и
> хорошо".
>
> >> Так что вполне можно оставить решение этого вопроса на
> >> усмотрение мейнтейнеров. А нынешние предупреждения...
> >> да в общем-то пусть будут: вреда от них никакого, а польза
> >> бывает.
>
> Здесь, насколько я понимаю, возражений нет?
Есть, но я просто хочу свернуть эту дискуссию. Мне не хочется поддерживать
пустой спор. Раз вы не видите в этом толка - ок. Я не планирую вас
убеждать.
--
Rgrds, legion