From: Alexey Gladkov <legion@altlinux.ru> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] automatic License Date: Sun, 30 Aug 2020 18:40:50 +0200 Message-ID: <20200830164050.vxkkmn7exrbojnua@comp-core-i7-2640m-0182e6> (raw) In-Reply-To: <20200830185824.45ddb82b656611bd9eeee2ce@altlinux.org> On Sun, Aug 30, 2020 at 06:58:24PM +0300, Andrey Savchenko wrote: > > Расстояние левенштейна не подходит совсем для лицензий. Если я в лицензию > > добавлю три символа ("permitted" -> "not permitted"), то лицензия > > изменится на противоположную, а расстояние левенштейна будет утверждать, > > что тексты на 99% одинаковые. > > Это легко решается весовым коэффициентом. Впрочем, Ваш пример не > реалистичный, т.к. большинство лицензий типовые. Я же не истина в последней инстанции. Попробуйте подобрать этот коэффициент и поугадывать лицензии. > По-моему, Ваша ошибка в том, что Вы предполагаете, что роботы будут > всегда всё разбирать. Нет, это не так. Они будут разбирать типовые > ситуации, где можно однозначно сказать (например, семейство GPL > где автор не может вставить "not" где-либо, да и вообще менять > текст лицензий). Если типовая проверка не сработает, то всё > останется на ручную работу, как и было раньше. Для типовой ситуации есть diff -wB. Если эта проверка не прошла, то это уже не типовой случай. Лично мне кажется, что типовой случай мантейнер и сам в состоянии обработать без труда. > И, насколько я знаю, у viy все роботы примерно так сейчас > и работают: тот же logoved разбирает типовые ситуации где есть > шаблонный и однозначный алгоритм действий, а все сложные случаи > вываливаются в отдельную корзиночку. Если робот не на 100% выполняет какую-то задачу, то за ним нужно перепроверять. Раз я сажусь перепроверять, то по сути делаю эту работу сам. И да, за всё время существования этих репокопов я его патчами никогда не воспользовался потому что я открываю патч, смотрю в него, вижу ложное срабатывание и закрываю. > > > В отличие от гугла, мне нужен не полный охват, > > > а охват типичных случаев. Нетипичные слусаи можно обработать и вручную. > > > > В этом плане 'diff -wB ...' будет вести себя правильнее при условии > > дополнительной обработки адресов и синонимов. > > > > А вот если лицензий больше одной, то будет очень сложно понять это "и" или > > "или". > > > > Вот и получается, что тривиальные случаи мантейнер и сам без труда > > выставит, а сложные только мантейнер (и то не всегда) сможет разобрать. > > Если за роботом всё равно нужно будет перепроверять (а это нужно будет > > делать в любом случае), то в таком роботе я не вижу смысла. > > У больших пакетов могут быть десятки лицензий, их сложно все найти, > нужно перечитывать все заголовки всех файлов, т.к. общие файлы вида > LICENSES/COPYING обычно содержат не всё. Здесь роботы очень полезны > будут. Я уже писал, что если будет инструмент, который скажет для каких файлов какая лицензия, то это будет успех, но я уверен, что такой инструмент невозможно написать. Всегда нужно будет перепроверять. > По поводу корректности указания лицензий: для *большинства* srpm > пакетов они у нас сейчас указаны некорректно, если учитывать > случаи, когда перечислены не все лицензии. Потому что у нас by > design предполагается, что у name.rpm и name.srpm одна и та же > лицензия, что в большинстве неверно, поскольку: > > а) бинарники являются результатом объединения лицензий путём > неявного перелицензирования; > > б) есть лицензии на код, который используется при сборке или просто > есть в исходниках, но в бинарник не попадает: например, сборочные > скрипты или m4, которые часто отличаются от лицензии пакета и в > srpm должны быть указаны, строго говоря. Я с вами полностью согласен. Это очень сложная тема и универсального подхода в разных дистрибутивах я не нашёл. Правильнее всего сделано у debian, но автоматизировать то как у них сделано я вообще не представляю. > Мало того, для многих подпакетов у нас некорректно указаны > лицензии, потому что подпакет часто является малым подмножеством > общего кода и к нему применимы лишь некоторые из лицензией > основного пакета. > > Разгребать это всё руками не реалистично. Да и не разребает у нас > никто. Так что разумная автоматизация улучшит процесс. К сожалению, у нас не до конца сформировано то самое пресловутое полиси на лицензии и то как их обозначать. Если есть желание двинуть эту тему вперёд, то давайте откроем новый тред. Если интересно, я могу рассказать из-за чего я вообще полез в эти авгиевы конюшни. -- Rgrds, legion
next prev parent reply other threads:[~2020-08-30 16:40 UTC|newest] Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-27 2:29 [devel] incoming/girar: проблема производительности Igor Vlasenko 2020-08-27 7:27 ` Anton Farygin 2020-08-27 11:54 ` Andrey Savchenko 2020-08-27 11:59 ` Anton Farygin 2020-08-27 12:09 ` [devel] архивирование репозиториев Dmitry V. Levin 2020-08-27 12:14 ` Anton Farygin 2020-08-27 12:20 ` Dmitry V. Levin 2020-08-27 12:32 ` Anton Farygin 2020-08-27 15:59 ` Dmitry V. Levin 2020-08-27 18:26 ` Anton Farygin 2020-08-27 20:29 ` Dmitry V. Levin 2020-08-28 7:06 ` Alexey V. Vissarionov 2020-08-28 7:09 ` Anton Farygin 2020-08-27 17:31 ` Michael Shigorin 2020-08-27 17:51 ` Andrey Savchenko 2020-08-27 20:33 ` Dmitry V. Levin 2020-08-28 1:28 ` Dmitry V. Levin 2020-08-28 6:29 ` Andrey Savchenko 2020-08-29 2:04 ` Leonid Krivoshein 2020-08-28 0:58 ` Leonid Krivoshein 2020-08-28 1:11 ` Dmitry V. Levin 2020-08-29 2:16 ` Leonid Krivoshein 2020-08-28 5:03 ` Anton Farygin 2020-08-29 2:22 ` Leonid Krivoshein 2020-08-29 4:58 ` Anton Farygin 2020-08-29 14:18 ` Leonid Krivoshein 2020-08-29 16:23 ` Anton Farygin 2020-08-29 19:28 ` [devel] zfs " Vitaly Chikunov 2020-08-29 20:11 ` Anton Farygin 2020-08-29 20:38 ` Vitaly Chikunov 2020-08-29 21:12 ` Anton Farygin 2020-08-30 4:28 ` Alexey V. Vissarionov 2020-08-27 12:05 ` [devel] incoming/girar: проблема производительности Alexey V. Vissarionov 2020-08-28 9:25 ` Igor Vlasenko 2020-08-28 9:28 ` Anton V. Boyarshinov 2020-08-28 9:31 ` Igor Vlasenko 2020-08-28 9:34 ` Anton Farygin 2020-08-28 9:47 ` Igor Vlasenko 2020-08-27 9:17 ` Michael Shigorin 2020-08-28 0:23 ` [devel] mass rebuilds Dmitry V. Levin 2020-08-28 5:09 ` Anton Farygin 2020-08-28 6:25 ` Andrey Savchenko 2020-08-28 6:58 ` Anton Farygin 2020-08-28 16:46 ` Dmitry V. Levin 2020-08-28 20:23 ` Anton Farygin 2020-08-28 21:47 ` Dmitry V. Levin 2020-08-29 5:08 ` Anton Farygin 2020-08-27 9:57 ` [devel] incoming/girar: проблема производительности Dmitry V. Levin 2020-08-28 18:47 ` Dmitry V. Levin 2020-08-27 11:35 ` [devel] License Tag Policy (Re: incoming/girar: проблема =?utf-8?b?INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM0L3QvtGB0YLQuC4=?=) Sergey Afonin 2020-08-27 23:01 ` [devel] unmaintained packages shall not belong to Sisyphus Dmitry V. Levin 2020-08-28 0:04 ` Dmitry V. Levin 2020-08-28 0:35 ` Dmitry V. Levin 2020-08-28 5:22 ` Anton Farygin 2020-08-28 16:02 ` Dmitry V. Levin 2020-08-28 16:30 ` Michael Shigorin 2020-08-28 16:33 ` Michael Shigorin 2020-08-28 16:43 ` Dmitry V. Levin 2020-08-28 19:52 ` Michael Shigorin 2020-08-28 20:04 ` Dmitry V. Levin 2020-08-28 20:34 ` Michael Shigorin 2020-08-28 20:19 ` Alexey Gladkov 2020-08-28 20:46 ` Michael Shigorin 2020-08-28 23:52 ` Alexey Gladkov 2020-08-31 10:14 ` Konstantin Lepikhov 2020-08-31 18:09 ` [devel] [JT] баланс/динамика: пакеты/майнтейнеры (was: unmaintained packages shall not belong to Sisyphus) Michael Shigorin 2020-08-31 7:53 ` [devel] suggested tags order Aleksei Nikiforov 2020-08-31 11:46 ` Sergey V Turchin 2020-08-31 12:25 ` Paul Wolneykien 2020-08-28 16:40 ` [devel] hasher ALT#36531 Dmitry V. Levin 2020-08-30 0:15 ` Igor Vlasenko 2020-08-28 17:55 ` [devel] automatic License Dmitry V. Levin 2020-08-30 8:14 ` Igor Vlasenko 2020-08-30 10:09 ` Alexey Gladkov 2020-08-30 12:44 ` Igor Vlasenko 2020-08-30 15:21 ` Alexey Gladkov 2020-08-30 15:36 ` Michael Shigorin 2020-08-30 15:44 ` Alexey Gladkov 2020-08-30 15:58 ` Andrey Savchenko 2020-08-30 16:40 ` Alexey Gladkov [this message] 2020-08-30 17:27 ` Andrey Savchenko 2020-08-30 18:15 ` Alexey Gladkov 2020-08-30 18:47 ` Michael Shigorin 2020-08-30 17:56 ` Igor Vlasenko 2020-08-28 18:26 ` [devel] will be fatal in Perl 5.30 Dmitry V. Levin 2020-08-28 19:46 ` Michael Shigorin 2020-08-28 19:58 ` Dmitry V. Levin 2020-08-28 20:19 ` Michael Shigorin 2020-08-28 22:11 ` Dmitry V. Levin 2020-08-28 22:13 ` Dmitry V. Levin 2020-08-30 0:58 ` Igor Vlasenko 2020-08-30 0:41 ` Igor Vlasenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200830164050.vxkkmn7exrbojnua@comp-core-i7-2640m-0182e6 \ --to=legion@altlinux.ru \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git