From: Andrey Savchenko <bircoph@altlinux.org> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] automatic License Date: Sun, 30 Aug 2020 18:58:24 +0300 Message-ID: <20200830185824.45ddb82b656611bd9eeee2ce@altlinux.org> (raw) In-Reply-To: <20200830152134.zqpbglwztajblikj@comp-core-i7-2640m-0182e6> [-- Attachment #1: Type: text/plain, Size: 6095 bytes --] On Sun, 30 Aug 2020 17:21:34 +0200 Alexey Gladkov wrote: > On Sun, Aug 30, 2020 at 03:44:23PM +0300, Igor Vlasenko wrote: > > On Sun, Aug 30, 2020 at 12:09:17PM +0200, Alexey Gladkov wrote: > > > > Гм. действительно. Вылетело из головы, когда писал. > > > > Надо будет добавить поиск в исходниках соответствующих > > > > юридических оборотов в библиотеку SourceAnalyzer. > > > > > > Я не видел ни одного проекта, который бы проверял лицензию правильно. Даже > > > в гугле [1] считают расстояние левенштейна для текстов лицензий. > > > [1] https://github.com/google/licenseclassifier/ > > > > Спасибо, занес себе в закладки. > > Но расстояние левенштейна это для всяких патологических > > случаев, вроде MIT-подобных лицензий, и то, > > для их прореживания есть рабочие хаки. > > Расстояние левенштейна не подходит совсем для лицензий. Если я в лицензию > добавлю три символа ("permitted" -> "not permitted"), то лицензия > изменится на противоположную, а расстояние левенштейна будет утверждать, > что тексты на 99% одинаковые. Это легко решается весовым коэффициентом. Впрочем, Ваш пример не реалистичный, т.к. большинство лицензий типовые. По-моему, Ваша ошибка в том, что Вы предполагаете, что роботы будут всегда всё разбирать. Нет, это не так. Они будут разбирать типовые ситуации, где можно однозначно сказать (например, семейство GPL где автор не может вставить "not" где-либо, да и вообще менять текст лицензий). Если типовая проверка не сработает, то всё останется на ручную работу, как и было раньше. И, насколько я знаю, у viy все роботы примерно так сейчас и работают: тот же logoved разбирает типовые ситуации где есть шаблонный и однозначный алгоритм действий, а все сложные случаи вываливаются в отдельную корзиночку. > > В отличие от гугла, мне нужен не полный охват, > > а охват типичных случаев. Нетипичные слусаи можно обработать и вручную. > > В этом плане 'diff -wB ...' будет вести себя правильнее при условии > дополнительной обработки адресов и синонимов. > > А вот если лицензий больше одной, то будет очень сложно понять это "и" или > "или". > > Вот и получается, что тривиальные случаи мантейнер и сам без труда > выставит, а сложные только мантейнер (и то не всегда) сможет разобрать. > Если за роботом всё равно нужно будет перепроверять (а это нужно будет > делать в любом случае), то в таком роботе я не вижу смысла. У больших пакетов могут быть десятки лицензий, их сложно все найти, нужно перечитывать все заголовки всех файлов, т.к. общие файлы вида LICENSES/COPYING обычно содержат не всё. Здесь роботы очень полезны будут. По поводу корректности указания лицензий: для *большинства* srpm пакетов они у нас сейчас указаны некорректно, если учитывать случаи, когда перечислены не все лицензии. Потому что у нас by design предполагается, что у name.rpm и name.srpm одна и та же лицензия, что в большинстве неверно, поскольку: а) бинарники являются результатом объединения лицензий путём неявного перелицензирования; б) есть лицензии на код, который используется при сборке или просто есть в исходниках, но в бинарник не попадает: например, сборочные скрипты или m4, которые часто отличаются от лицензии пакета и в srpm должны быть указаны, строго говоря. Мало того, для многих подпакетов у нас некорректно указаны лицензии, потому что подпакет часто является малым подмножеством общего кода и к нему применимы лишь некоторые из лицензией основного пакета. Разгребать это всё руками не реалистично. Да и не разребает у нас никто. Так что разумная автоматизация улучшит процесс. Best regards, Andrew Savchenko [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-08-30 15:58 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 [this message] 2020-08-30 16:40 ` Alexey Gladkov 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=20200830185824.45ddb82b656611bd9eeee2ce@altlinux.org \ --to=bircoph@altlinux.org \ --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