[devel] automatic License

[Andrey Savchenko]

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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20200830/ba60e95d/attachment-0001.bin>