From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Date: Sun, 30 Aug 2020 18:40:50 +0200 From: Alexey Gladkov To: ALT Linux Team development discussions Message-ID: <20200830164050.vxkkmn7exrbojnua@comp-core-i7-2640m-0182e6> References: <20200827022952.GA8129@dad.imath.kiev.ua> <20200828175532.GA21836@altlinux.org> <20200830081407.GA7392@dad.imath.kiev.ua> <20200830100917.l4lqaoqreemfxzoc@comp-core-i7-2640m-0182e6> <20200830124422.GA14871@dad.imath.kiev.ua> <20200830152134.zqpbglwztajblikj@comp-core-i7-2640m-0182e6> <20200830185824.45ddb82b656611bd9eeee2ce@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200830185824.45ddb82b656611bd9eeee2ce@altlinux.org> Subject: Re: [devel] automatic License X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 16:40:58 -0000 Archived-At: List-Archive: List-Post: 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