[devel] mysql-workbench-community, License tag

[devel] mysql-workbench-community, License tag

[Sergey Y. Afonin]

Приветствую.

Очередной пакет с ворохом лицензий: mysql-workbench-community.
В SuSe (для  8.0.15):  License: GPL-2.0-only AND GPL-2.0-or-later
Это, наверное, не очень правильно, так как в License.txt есть 
фраза "GPLv2 or any later version may be used". У нас же сейчас
"License: GPLv2, LGPLv2" с каких-то пор тянется. Если License.txt
дочитать до конца, то для разных компонент есть и LGPL, и варианты
BSD. Я сколонен написать GPL-2.0-or-later with with exeptions c
припиской в Description "Some parts of code have separate licenses",
как у ClamAV.

-- 
С уважением, Сергей Афонин

Re: [devel] mysql-workbench-community, License tag

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

On Sun, 15 Mar 2020 20:42:04 +0400 Sergey Y. Afonin wrote:
> Приветствую.
> 
> Очередной пакет с ворохом лицензий: mysql-workbench-community.
> В SuSe (для  8.0.15):  License: GPL-2.0-only AND GPL-2.0-or-later
> Это, наверное, не очень правильно, так как в License.txt есть 
> фраза "GPLv2 or any later version may be used".

Лицензии в хедерах файлов имеют приоритет над license.txt.

> У нас же сейчас
> "License: GPLv2, LGPLv2" с каких-то пор тянется. Если License.txt
> дочитать до конца, то для разных компонент есть и LGPL, и варианты
> BSD. Я сколонен написать GPL-2.0-or-later with with exeptions c
> припиской в Description "Some parts of code have separate licenses",
> как у ClamAV.

Следует перечислить все эти лицензии в теге "License:", начав
с самой главной.


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] mysql-workbench-community, License tag

[Sergey Y. Afonin]

On Sunday 15 March 2020, Andrey Savchenko wrote:

> > У нас же сейчас "License: GPLv2, LGPLv2" с каких-то пор тянется.
> > Если License.txt дочитать до конца, то для разных компонент есть
> > и LGPL, и варианты BSD. Я сколонен написать GPL-2.0-or-later with
> > exeptions c припиской в Description "Some parts of code have
> > separate licenses", как у ClamAV.
> 
> Следует перечислить все эти лицензии в теге "License:", начав
> с самой главной.

Что-то мне не кажется, что это будет читабельно во-первых и понятно
во-вторых. Вот как интерпретировать этот тэг тогда? Код распространяется
под любой из, или под всеми сразу? Откуда может быть понятно при таком
пересислении, что отдельные лицензии касаются не всего кода, а отдельных
компонент? И я не вижу примеров такого заполения License в других 
дистрибутивах. 

-- 
С уважением, Сергей Афонин

Re: [devel] mysql-workbench-community, License tag

[Alexey Gladkov]

On Sun, Mar 15, 2020 at 11:36:09PM +0400, Sergey Y. Afonin wrote:
> On Sunday 15 March 2020, Andrey Savchenko wrote:
> 
> > > У нас же сейчас "License: GPLv2, LGPLv2" с каких-то пор тянется.
> > > Если License.txt дочитать до конца, то для разных компонент есть
> > > и LGPL, и варианты BSD. Я сколонен написать GPL-2.0-or-later with
> > > exeptions c припиской в Description "Some parts of code have
> > > separate licenses", как у ClamAV.
> > 
> > Следует перечислить все эти лицензии в теге "License:", начав
> > с самой главной.

Да, это правильно.

> Что-то мне не кажется, что это будет читабельно во-первых и понятно
> во-вторых. Вот как интерпретировать этот тэг тогда?

Этот тег отражает список всех лицензий (в идеале), под которыми
распространяется код.

> Код распространяется под любой из, или под всеми сразу?

Это описывается в теге. Для этого теге допускается группировка и 'and',
'or'.

> Откуда может быть понятно при таком пересислении, что отдельные лицензии
> касаются не всего кода, а отдельных компонент?

Этот тег агрегирует правовую информацию. Если в пакете часть кода под GPL,
другой по BSD, то это GPL and BSD. Потому что при использовании всего
контента пакета вам необходимо принять обе лицензии.

Некоторый код подразумевает двойное лицензирование, тогда это, например,
GPL or MPL.

Бывают и более сложные ситуации, которые нужно обсуждать.

В некоторых случаях проще вынести в отдельный пакет код под лицензией,
отличной от основного проекта.

> И я не вижу примеров такого заполения License в других дистрибутивах. 

Suse занимается таким заполнением, но у них тоже это не автоматизировано и 
встречаются ошибки. Redhat занимается этим, но у них теряется часть
информации.

Это очень сложная задача, которая не автоматизируется и требует от
мантейнеров большой ответственности.

+Cc: aen@, ldv@

Поправьте меня, если я неправильно написал.

-- 
Rgrds, legion

Re: [devel] mysql-workbench-community, License tag

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]

On Sun, Mar 15, 2020 at 10:58:49PM +0100, Alexey Gladkov wrote:
> On Sun, Mar 15, 2020 at 11:36:09PM +0400, Sergey Y. Afonin wrote:
> > On Sunday 15 March 2020, Andrey Savchenko wrote:
> > 
> > > > У нас же сейчас "License: GPLv2, LGPLv2" с каких-то пор тянется.
> > > > Если License.txt дочитать до конца, то для разных компонент есть
> > > > и LGPL, и варианты BSD. Я сколонен написать GPL-2.0-or-later with
> > > > exeptions c припиской в Description "Some parts of code have
> > > > separate licenses", как у ClamAV.
> > > 
> > > Следует перечислить все эти лицензии в теге "License:", начав
> > > с самой главной.
> 
> Да, это правильно.
> 
> > Что-то мне не кажется, что это будет читабельно во-первых и понятно
> > во-вторых. Вот как интерпретировать этот тэг тогда?
> 
> Этот тег отражает список всех лицензий (в идеале), под которыми
> распространяется код.
> 
> > Код распространяется под любой из, или под всеми сразу?
> 
> Это описывается в теге. Для этого теге допускается группировка и 'and',
> 'or'.
> 
> > Откуда может быть понятно при таком пересислении, что отдельные лицензии
> > касаются не всего кода, а отдельных компонент?
> 
> Этот тег агрегирует правовую информацию. Если в пакете часть кода под GPL,
> другой по BSD, то это GPL and BSD. Потому что при использовании всего
> контента пакета вам необходимо принять обе лицензии.
> 
> Некоторый код подразумевает двойное лицензирование, тогда это, например,
> GPL or MPL.
> 
> Бывают и более сложные ситуации, которые нужно обсуждать.
> 
> В некоторых случаях проще вынести в отдельный пакет код под лицензией,
> отличной от основного проекта.
> 
> > И я не вижу примеров такого заполения License в других дистрибутивах. 
> 
> Suse занимается таким заполнением, но у них тоже это не автоматизировано и 
> встречаются ошибки. Redhat занимается этим, но у них теряется часть
> информации.
> 
> Это очень сложная задача, которая не автоматизируется и требует от
> мантейнеров большой ответственности.
> 
> +Cc: aen@, ldv@
> 
> Поправьте меня, если я неправильно написал.

Я бы не сказал, что это очень сложная задача.  В отдельных случаях
встречаются сложности, но обычно эта задача под силу любому мантейнеру.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] mysql-workbench-community, License tag

[Sergey Afonin]

On Monday 16 March 2020, Alexey Gladkov wrote:

> > И я не вижу примеров такого заполения License в других дистрибутивах. 
> 
> Suse занимается таким заполнением, но у них тоже это не автоматизировано
> и встречаются ошибки. Redhat занимается этим, но у них теряется часть
> информации.

Ни для ClamAV, ни для mysql-workbench в SuSe нет десятка лицензий
в License (а их там примерно по столько).

-- 
С уважением, Сергей Афонин.

Re: [devel] mysql-workbench-community, License tag

[Sergey Afonin]

On Monday 16 March 2020, Dmitry V. Levin wrote:

> Я бы не сказал, что это очень сложная задача.  В отдельных случаях
> встречаются сложности, но обычно эта задача под силу любому мантейнеру.

В License.txt в mysql-workbench, честно говоря, чёрт ногу сломит.
Лицензии натыканы одна за одной, в каких-то указано явно, а какие-то
надо по внешнему виду узнавать. В ClamAV они хоть в разных файлах,
которые сами по себе уже название.

-- 
С уважением, Сергей Афонин.

Re: [devel] mysql-workbench-community, License tag

[Dmitry V. Levin]

On Mon, Mar 16, 2020 at 09:46:29AM +0400, Sergey Afonin wrote:
> On Monday 16 March 2020, Dmitry V. Levin wrote:
> 
> > Я бы не сказал, что это очень сложная задача.  В отдельных случаях
> > встречаются сложности, но обычно эта задача под силу любому мантейнеру.
> 
> В License.txt в mysql-workbench, честно говоря, чёрт ногу сломит.
> Лицензии натыканы одна за одной, в каких-то указано явно, а какие-то
> надо по внешнему виду узнавать. В ClamAV они хоть в разных файлах,
> которые сами по себе уже название.

Посмотрите Debian:
https://metadata.ftp-master.debian.org/changelogs/main/m/mysql-workbench/mysql-workbench_8.0.19+dfsg-1_copyright


-- 
ldv

Re: [devel] mysql-workbench-community, License tag

[Sergey Afonin]

On Monday 16 March 2020, Dmitry V. Levin wrote:

> Посмотрите Debian:
> https://metadata.ftp-master.debian.org/changelogs/main/m/mysql-workbench/mysql-workbench_8.0.19+dfsg-1_copyright
> 

Да, тут список есть.  grep "License:" | sort | uniq даёт список

License: CC-BY-3.0
License: Expat
License: GPL-2
License: GPL-2+
License: GPL-3+
License: GPL-3+ or GPL-2
License: LGPL-2+
License: public-domain
License: Scintilla

Но тут отсутствуют, как минимум, Libzip, напоминающая BSD-3-clause,
OpenSSL License, Python, MIT (хотя есть Expat, но зачем-то в License.txt
и MIT отдельно есть). С чем-то workbench линкуется, и, видимо, это не 
надо упоминать. Компоненты на Python точно есть, хотя вроде, при беглом
просмотре, в коде везде GPL написано...

В итоге AND между всеми, что в Debian перечислены, написать?

Но странно будет смотреться "(GPL-3+ or GPL-2) and GPL-3+ and GPL-2"

-- 
С уважением, Сергей Афонин.

Re: [devel] mysql-workbench-community, License tag

[Alexey Gladkov]

On Mon, Mar 16, 2020 at 02:52:59PM +0400, Sergey Afonin wrote:
> On Monday 16 March 2020, Dmitry V. Levin wrote:
> 
> > Посмотрите Debian:
> > https://metadata.ftp-master.debian.org/changelogs/main/m/mysql-workbench/mysql-workbench_8.0.19+dfsg-1_copyright
> > 
> 
> Да, тут список есть.  grep "License:" | sort | uniq даёт список
> 
> License: CC-BY-3.0
> License: Expat
> License: GPL-2
> License: GPL-2+
> License: GPL-3+
> License: GPL-3+ or GPL-2
> License: LGPL-2+
> License: public-domain
> License: Scintilla
> 
> Но тут отсутствуют, как минимум, Libzip, напоминающая BSD-3-clause,
> OpenSSL License, Python, MIT (хотя есть Expat, но зачем-то в License.txt
> и MIT отдельно есть). С чем-то workbench линкуется, и, видимо, это не 
> надо упоминать. Компоненты на Python точно есть, хотя вроде, при беглом
> просмотре, в коде везде GPL написано...
> 
> В итоге AND между всеми, что в Debian перечислены, написать?
> 
> Но странно будет смотреться "(GPL-3+ or GPL-2) and GPL-3+ and GPL-2"

Стоит выкинуть очевидные повторы.

Если есть (GPL-3+ or GPL-2), что значит GPL-2 или GPL-3 или GPL-следующая,
то это на самом деле GPL-2+ поскольку между GPL-2 и GPL-3 не было других
лицензий.

В этом случае "and GPL-3+ and GPL-2" подпадают под группу.

Таким образом все GPL-* можно оставить GPL-2+.

-- 
Rgrds, legion

Re: [devel] mysql-workbench-community, License tag

[Sergey Afonin]

On Monday 16 March 2020, Alexey Gladkov wrote:

> Таким образом все GPL-* можно оставить GPL-2+.
 
Но у части исходников GPL-2-only и это не те исходники,
про которые написано (GPL-3+ or GPL-2). "GPL-3+ or GPL-2",
согласен, до GPL-2+ упрощается.

-- 
С уважением, Сергей Афонин.

Re: [devel] mysql-workbench-community, License tag

[Sergey Afonin]

On Monday 16 March 2020, Sergey Afonin wrote:

> > Таким образом все GPL-* можно оставить GPL-2+.
>  
> Но у части исходников GPL-2-only и это не те исходники,
> про которые написано (GPL-3+ or GPL-2). "GPL-3+ or GPL-2",
> согласен, до GPL-2+ упрощается.

В общем финальный вариант на основе списка из Debian сводится к 

License: GPL-2+ and LGPL-2+ and GPL-2 and Scintilla and public-domain

Так? Или, всё же, "and GPL-2" убирать?

-- 
С уважением, Сергей Афонин.

Re: [devel] mysql-workbench-community, License tag

[Sergey Afonin]

On Monday 16 March 2020, Sergey Afonin wrote:

> В общем финальный вариант на основе списка из Debian сводится к 
> 
> License: GPL-2+ and LGPL-2+ and GPL-2 and Scintilla and public-domain

> Так? Или, всё же, "and GPL-2" убирать?

"and CC-BY-3.0 end Expat" забыл. 

Хотя судя по [MIT "expat" license](http://opensource.org/licenses/MIT)
в License.txt, это MIT: SPDX short identifier: MIT. Зачем тогда MIT
отдельно в License.txt...

-- 
С уважением, Сергей Афонин.

Re: [devel] mysql-workbench-community, License tag

[Alexey Gladkov]

On Mon, Mar 16, 2020 at 04:16:02PM +0400, Sergey Afonin wrote:
> On Monday 16 March 2020, Sergey Afonin wrote:
> 
> > > Таким образом все GPL-* можно оставить GPL-2+.
> >  
> > Но у части исходников GPL-2-only и это не те исходники,
> > про которые написано (GPL-3+ or GPL-2). "GPL-3+ or GPL-2",
> > согласен, до GPL-2+ упрощается.
> 
> В общем финальный вариант на основе списка из Debian сводится к 
> 
> License: GPL-2+ and LGPL-2+ and GPL-2 and Scintilla and public-domain
> 
> Так? Или, всё же, "and GPL-2" убирать?

Да, его можно убрать.

-- 
Rgrds, legion

Re: [devel] mysql-workbench-community, License tag

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 6379 bytes --]

On Sun, 15 Mar 2020 22:58:49 +0100 Alexey Gladkov wrote:
> On Sun, Mar 15, 2020 at 11:36:09PM +0400, Sergey Y. Afonin wrote:
[...]
> > Откуда может быть понятно при таком пересислении, что отдельные лицензии
> > касаются не всего кода, а отдельных компонент?
> 
> Этот тег агрегирует правовую информацию. Если в пакете часть кода под GPL,
> другой по BSD, то это GPL and BSD. Потому что при использовании всего
> контента пакета вам необходимо принять обе лицензии.

Тут всё сложнее, даже если забыть про двойное лицензирование или
кодогенерацию. Лицензии на исходные файлы и на получившиеся
бинарники — это в общем случае разные вещи. Если говорить про
бинарные файлы, то в результате комбинирования BSD и GPL получается
строго GPL. С юридической точки зрения происходит
перелицензирование BSD кода под GPL, что разрешается, т.к. эти
лицензии совместимы в порядке наследования BSD -> GPL, но обратное
делать нельзя. А вот исходники как были под BSD и GPL, так и
остаются (если никто не менял явно лицензии исходников).

В 2018 в Калуге я делал доклад на тему того, как устроено это всё,
включая механизм совместимости лицензий:
http://0x1.tv/Уязвимости_в_лицензиях_СПО_(Андрей_Савченко,_OSSDEVCONF-2018)

В частности, там есть слайд с механизмом зависимостей между
основными лицензиями:
http://0x1.tv/img_auth.php/f/ff/Уязвимости_в_лицензиях_СПО_(Андрей_Савченко%2C_OSSDEVCONF-2018).pdf#page=11

Предположим, у нас есть пакет foo с бинарником foobin, подпакетом
libfoo с libfoo и libfoo-devel с хедерами и симлинками.
И предположим, что в этом пакете есть три лицензии на разные части
кода, такие что: libfoo собирается из LGPLv2.1 и BSD кода, при этом
BSD попадает в хедеры, а при сборке foobin также испольуется GPLv3
код. Тогда у разных (под)пакетов будут разные лицензии):

foo (rpm)    - GPLv3
libfoo       - LGPLv2.1
libfoo-devel - LGPLv2.1 + BSD
foo (srpm)   - GPLv3 + LGPLv2.1 + BSD

На данный момент единственный способ известный мне способ указать
разные лицензии для rpm и srpm — это паковать все файлы в подпакеты,
оставив основной rpm чисто виртуальным. Не лучшее решение, но наша
архитектура сборки пакетов лучшего не позволяет.

Ещё раз повторю главную мораль этого упражнения: за редкими
случаями двойного лицензирования у конкретного бинарника есть
только *одна* лицензия, даже если он собран из зоопарка совместимых
лицензий, которая определяется порядком совместимости. Если же
лицензии не совместимы, то распространять такой бинарник нельзя
и в репозитории ему не место. А вот исходники (в т.ч. и хедеры
библиотек) сохраняют все оригинальные лицензии.

В реальной жизни всё сложнее, т.к. помимо упомянутых двойных
лицензий и кодогенераторов есть ещё зависимость лицензии от
опций сборки пакета (привет ffmpeg).

> Некоторый код подразумевает двойное лицензирование, тогда это, например,
> GPL or MPL.
> 
> Бывают и более сложные ситуации, которые нужно обсуждать.
> 
> В некоторых случаях проще вынести в отдельный пакет код под лицензией,
> отличной от основного проекта.
> 
> > И я не вижу примеров такого заполения License в других дистрибутивах. 
> 
> Suse занимается таким заполнением, но у них тоже это не автоматизировано и 
> встречаются ошибки. Redhat занимается этим, но у них теряется часть
> информации.

Ещё Debian следит. В Gentoo проделана просто огромная работа, в т.ч.
и по условным зависимостях в лицензиях (т.е. лицензия пакета может
зависеть от того, как его собрали), например:

https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/ffmpeg/ffmpeg-4.2.2.ebuild

LICENSE="
	!gpl? ( LGPL-2.1 )
	gpl? ( GPL-2 )
	amr? (
		gpl? ( GPL-3 )
		!gpl? ( LGPL-3 )
	)
	gmp? (
		gpl? ( GPL-3 )
		!gpl? ( LGPL-3 )
	)
	libaribb24? (
		gpl? ( GPL-3 )
		!gpl? ( LGPL-3 )
	)
	encode? (
		amrenc? (
			gpl? ( GPL-3 )
			!gpl? ( LGPL-3 )
		)
	)
	samba? ( GPL-3 )
"

У нас тоже есть ручки (defined, enabled), так что такие вещи тоже
следует учитывать.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] mysql-workbench-community, License tag

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]

On Mon, 16 Mar 2020 15:40:21 +0100 Alexey Gladkov wrote:
> On Mon, Mar 16, 2020 at 04:16:02PM +0400, Sergey Afonin wrote:
> > On Monday 16 March 2020, Sergey Afonin wrote:
> > 
> > > > Таким образом все GPL-* можно оставить GPL-2+.
> > >  
> > > Но у части исходников GPL-2-only и это не те исходники,
> > > про которые написано (GPL-3+ or GPL-2). "GPL-3+ or GPL-2",
> > > согласен, до GPL-2+ упрощается.
> > 
> > В общем финальный вариант на основе списка из Debian сводится к 
> > 
> > License: GPL-2+ and LGPL-2+ and GPL-2 and Scintilla and public-domain
> > 
> > Так? Или, всё же, "and GPL-2" убирать?
> 
> Да, его можно убрать.

Нет, его нельзя убирать. Если есть код, который под GPLv2 only,
это значит, что его нельзя перелицензировать под любые другие
версии лицензий. Таким образом, GPLv2 only и GPLv2+ — это
фундаментально разные вещи.

Тег лицензии нужен не только, чтоб знать под какими лицензиями
идёт пакет, но и чтоб знать, под какими лицензиями его можно
использовать. Если написано GPLv2+, значит можно использовать под
GPLv3 и последующими (когда они появятся), если пользователь
захочет. Если написано GPLv2 (only), значит под GPLv3 и любыми
последующими использовать *нельзя*.

Это особенно важно для библиотек и их хедеров, т.к. они могут
использоваться в самых разных проектах и не нужно разработчиков
(и, в меньшей степени, мейнтенеров пакетов) таких проектов вводить
в заблуждение.


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] mysql-workbench-community, License tag

[Alexey Gladkov]

On Tue, Mar 17, 2020 at 01:14:42AM +0300, Andrey Savchenko wrote:
> On Mon, 16 Mar 2020 15:40:21 +0100 Alexey Gladkov wrote:
> > On Mon, Mar 16, 2020 at 04:16:02PM +0400, Sergey Afonin wrote:
> > > On Monday 16 March 2020, Sergey Afonin wrote:
> > > 
> > > > > Таким образом все GPL-* можно оставить GPL-2+.
> > > >  
> > > > Но у части исходников GPL-2-only и это не те исходники,
> > > > про которые написано (GPL-3+ or GPL-2). "GPL-3+ or GPL-2",
> > > > согласен, до GPL-2+ упрощается.
> > > 
> > > В общем финальный вариант на основе списка из Debian сводится к 
> > > 
> > > License: GPL-2+ and LGPL-2+ and GPL-2 and Scintilla and public-domain
> > > 
> > > Так? Или, всё же, "and GPL-2" убирать?
> > 
> > Да, его можно убрать.
> 
> Нет, его нельзя убирать. Если есть код, который под GPLv2 only,
> это значит, что его нельзя перелицензировать под любые другие
> версии лицензий. Таким образом, GPLv2 only и GPLv2+ — это
> фундаментально разные вещи.

Разумеется. Вы описываете более сложное и правильное описание правовой
информации, но тег License для этого совсем не годится. Для этого нужен
подход как у debian. В этом случае нужно описывать какие файлы под какой
лицензией поставляется.

Как я уже писал, я рассматриваю этот тег отражает список всех лицензий
(в идеале), под которыми распространяется код.

В этом смысле удалить GPL-2-only можно убрать.

> Тег лицензии нужен не только, чтоб знать под какими лицензиями
> идёт пакет, но и чтоб знать, под какими лицензиями его можно
> использовать.

Для этого этот тег не годится.

-- 
Rgrds, legion

Re: [devel] mysql-workbench-community, License tag

[Ivan A. Melnikov]

On Tue, Mar 17, 2020 at 12:03:07AM +0100, Alexey Gladkov wrote:
> On Tue, Mar 17, 2020 at 01:14:42AM +0300, Andrey Savchenko wrote:
> > Тег лицензии нужен не только, чтоб знать под какими лицензиями
> > идёт пакет, но и чтоб знать, под какими лицензиями его можно
> > использовать.
> 
> Для этого этот тег не годится.

Погодите.

Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
где это что-то такое сказано для Сизифа, но например у коллег из Федоры
написано чётко:

The License: field refers to the licenses of the contents of the binary
rpm.

https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/

Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
Потому что весь остальной код "автоматически" перелицензируется под
самую жесткую из лицензий, если может, а если не может, то такой
пакет нельзя собирать в Сизиф.

Разумеется, может быть несколько лицензий, если в пакете несколько
независимых бинарников под разными лицензиями, или разные лицензии
на код и данные, и т.п.

Однако в этом обсуждении, как мне показалось, в этот тег пытаются
собрать все лицезии, под которыми идут разные куски кода, независимо
от их применимости к итоговым бинарникам.

Так что же означает тег License у нас?

-- 
  wbr,
    iv m.

Re: [devel] mysql-workbench-community, License tag

[Alexey Gladkov]

On Tue, Mar 17, 2020 at 10:24:19AM +0400, Ivan A. Melnikov wrote:
> On Tue, Mar 17, 2020 at 12:03:07AM +0100, Alexey Gladkov wrote:
> > On Tue, Mar 17, 2020 at 01:14:42AM +0300, Andrey Savchenko wrote:
> > > Тег лицензии нужен не только, чтоб знать под какими лицензиями
> > > идёт пакет, но и чтоб знать, под какими лицензиями его можно
> > > использовать.
> > 
> > Для этого этот тег не годится.
> 
> Погодите.
> 
> Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
> где это что-то такое сказано для Сизифа, но например у коллег из Федоры
> написано чётко:
> 
> The License: field refers to the licenses of the contents of the binary
> rpm.
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
> 
> Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
> GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
> Потому что весь остальной код "автоматически" перелицензируется под
> самую жесткую из лицензий, если может, а если не может, то такой
> пакет нельзя собирать в Сизиф.
> 
> Разумеется, может быть несколько лицензий, если в пакете несколько
> независимых бинарников под разными лицензиями, или разные лицензии
> на код и данные, и т.п.
> 
> Однако в этом обсуждении, как мне показалось, в этот тег пытаются
> собрать все лицезии, под которыми идут разные куски кода, независимо
> от их применимости к итоговым бинарникам.
> 
> Так что же означает тег License у нас?

Вы правильно написали. Я сам запутался/ошибся/неправильно выразился и
начал вас путать. Прошу прощения.

-- 
Rgrds, legion

Re: [devel] mysql-workbench-community, License tag

[Sergey Afonin]

On Tuesday 17 March 2020, Ivan A. Melnikov wrote:

> Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
> где это что-то такое сказано для Сизифа, но например у коллег из Федоры
> написано чётко:
> 
> The License: field refers to the licenses of the contents of the binary
> rpm.
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
> 
> Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
> GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
> Потому что весь остальной код "автоматически" перелицензируется под
> самую жесткую из лицензий, если может, а если не может, то такой
> пакет нельзя собирать в Сизиф.
 
Хм. Рассматривать License c точки зрения бинарных пакетов я лично не
догадался что-то. С одной стороны это упрощает содержимое тэга, но, с
другой, а srpm тогда как? Туда же тот же тэг попадает. Или считается,
что он тоже бинарник, и как у бинарника, пока его на компоненты не 
разобрали, у него та же самая самая жёсткая лицензия?

-- 
С уважением, Сергей Афонин.

Re: [devel] License tag for source packages

[Dmitry V. Levin]

On Tue, Mar 17, 2020 at 05:31:20PM +0400, Sergey Afonin wrote:
> On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
> 
> > Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
> > где это что-то такое сказано для Сизифа, но например у коллег из Федоры
> > написано чётко:
> > 
> > The License: field refers to the licenses of the contents of the binary
> > rpm.
> > 
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
> > 
> > Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
> > GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
> > Потому что весь остальной код "автоматически" перелицензируется под
> > самую жесткую из лицензий, если может, а если не может, то такой
> > пакет нельзя собирать в Сизиф.
>  
> Хм. Рассматривать License c точки зрения бинарных пакетов я лично не
> догадался что-то. С одной стороны это упрощает содержимое тэга, но, с
> другой, а srpm тогда как? Туда же тот же тэг попадает. Или считается,
> что он тоже бинарник, и как у бинарника, пока его на компоненты не 
> разобрали, у него та же самая самая жёсткая лицензия?

Может быть, нам нужен синтаксис для описания лицензии исходных пакетов
для случаев, когда лицензии исходного и бинарных пакетов не совпадают?


-- 
ldv

Re: [devel] License tag for source packages

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

On Tue, 17 Mar 2020 19:40:32 +0300 Dmitry V. Levin wrote:
> On Tue, Mar 17, 2020 at 05:31:20PM +0400, Sergey Afonin wrote:
> > On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
> > 
> > > Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
> > > где это что-то такое сказано для Сизифа, но например у коллег из Федоры
> > > написано чётко:
> > > 
> > > The License: field refers to the licenses of the contents of the binary
> > > rpm.
> > > 
> > > https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
> > > 
> > > Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
> > > GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
> > > Потому что весь остальной код "автоматически" перелицензируется под
> > > самую жесткую из лицензий, если может, а если не может, то такой
> > > пакет нельзя собирать в Сизиф.
> >  
> > Хм. Рассматривать License c точки зрения бинарных пакетов я лично не
> > догадался что-то. С одной стороны это упрощает содержимое тэга, но, с
> > другой, а srpm тогда как? Туда же тот же тэг попадает. Или считается,
> > что он тоже бинарник, и как у бинарника, пока его на компоненты не 
> > разобрали, у него та же самая самая жёсткая лицензия?
> 
> Может быть, нам нужен синтаксис для описания лицензии исходных пакетов
> для случаев, когда лицензии исходного и бинарных пакетов не совпадают?

Я поддерживаю эту идею, например, тег SourceLicense.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] License tag for source packages

[Dmitry V. Levin]

On Tue, Mar 17, 2020 at 07:56:52PM +0300, Andrey Savchenko wrote:
> On Tue, 17 Mar 2020 19:40:32 +0300 Dmitry V. Levin wrote:
> > On Tue, Mar 17, 2020 at 05:31:20PM +0400, Sergey Afonin wrote:
> > > On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
> > > 
> > > > Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
> > > > где это что-то такое сказано для Сизифа, но например у коллег из Федоры
> > > > написано чётко:
> > > > 
> > > > The License: field refers to the licenses of the contents of the binary
> > > > rpm.
> > > > 
> > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
> > > > 
> > > > Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
> > > > GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
> > > > Потому что весь остальной код "автоматически" перелицензируется под
> > > > самую жесткую из лицензий, если может, а если не может, то такой
> > > > пакет нельзя собирать в Сизиф.
> > >  
> > > Хм. Рассматривать License c точки зрения бинарных пакетов я лично не
> > > догадался что-то. С одной стороны это упрощает содержимое тэга, но, с
> > > другой, а srpm тогда как? Туда же тот же тэг попадает. Или считается,
> > > что он тоже бинарник, и как у бинарника, пока его на компоненты не 
> > > разобрали, у него та же самая самая жёсткая лицензия?
> > 
> > Может быть, нам нужен синтаксис для описания лицензии исходных пакетов
> > для случаев, когда лицензии исходного и бинарных пакетов не совпадают?
> 
> Я поддерживаю эту идею, например, тег SourceLicense.

Видимо, новый rpm header tag нам не понадобится, поскольку можно будет
продолжать использовать RPMTAG_LICENSE для исходных пакетов.
А вот какой-нибудь новый rpm spec tag, хотя бы тот же SourceLicense, 
выглядит логично.


-- 
ldv

Re: [devel] License tag for source packages

[Leonid Krivoshein]

17.03.2020 23:06, Dmitry V. Levin пишет:
> On Tue, Mar 17, 2020 at 07:56:52PM +0300, Andrey Savchenko wrote:
>> On Tue, 17 Mar 2020 19:40:32 +0300 Dmitry V. Levin wrote:
>>> On Tue, Mar 17, 2020 at 05:31:20PM +0400, Sergey Afonin wrote:
>>>> On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
>>>>
>>>>> Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
>>>>> где это что-то такое сказано для Сизифа, но например у коллег из Федоры
>>>>> написано чётко:
>>>>>
>>>>> The License: field refers to the licenses of the contents of the binary
>>>>> rpm.
>>>>>
>>>>> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
>>>>>
>>>>> Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
>>>>> GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
>>>>> Потому что весь остальной код "автоматически" перелицензируется под
>>>>> самую жесткую из лицензий, если может, а если не может, то такой
>>>>> пакет нельзя собирать в Сизиф.
>>>>   
>>>> Хм. Рассматривать License c точки зрения бинарных пакетов я лично не
>>>> догадался что-то. С одной стороны это упрощает содержимое тэга, но, с
>>>> другой, а srpm тогда как? Туда же тот же тэг попадает. Или считается,
>>>> что он тоже бинарник, и как у бинарника, пока его на компоненты не
>>>> разобрали, у него та же самая самая жёсткая лицензия?
>>> Может быть, нам нужен синтаксис для описания лицензии исходных пакетов
>>> для случаев, когда лицензии исходного и бинарных пакетов не совпадают?
>> Я поддерживаю эту идею, например, тег SourceLicense.
> Видимо, новый rpm header tag нам не понадобится, поскольку можно будет
> продолжать использовать RPMTAG_LICENSE для исходных пакетов.
> А вот какой-нибудь новый rpm spec tag, хотя бы тот же SourceLicense,
> выглядит логично.

Ранее Андрей в этом обсуждении верно заметил: нужен чисто сборочный 
пакет, а всё остальное выносить в под-пакеты. Проблем-то нет, а 
SourceLicense позволит уйти от такой обязаловки.

Пользуясь случаем хочу спросить о лицензии на сами спеки. :-) Они ведь 
тоже исходники. И часто эти исходники перетекают между разными 
производителями дистрибутивов, пусть и не 1:1. Меня давно интересует 
вопрос, под какими лицензиями они идут? К ним применимы лицензии от 
пакета или лицензия от дистрибутива? В последнем случае, дистрибутив 
может быть не совсем свободным, а пакет быть часть бранча, а не частью 
дистрибутива. У бранча ведь нет единой лицензии? Вопрос "обострился" в 
связи с подготовкой нового Падавана.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] License tag for source packages

[Leonid Krivoshein]

17.03.2020 19:40, Dmitry V. Levin пишет:
> On Tue, Mar 17, 2020 at 05:31:20PM +0400, Sergey Afonin wrote:
>> On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
>>
>>> Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
>>> где это что-то такое сказано для Сизифа, но например у коллег из Федоры
>>> написано чётко:
>>>
>>> The License: field refers to the licenses of the contents of the binary
>>> rpm.
>>>
>>> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
>>>
>>> Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
>>> GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
>>> Потому что весь остальной код "автоматически" перелицензируется под
>>> самую жесткую из лицензий, если может, а если не может, то такой
>>> пакет нельзя собирать в Сизиф.
>>   
>> Хм. Рассматривать License c точки зрения бинарных пакетов я лично не
>> догадался что-то. С одной стороны это упрощает содержимое тэга, но, с
>> другой, а srpm тогда как? Туда же тот же тэг попадает. Или считается,
>> что он тоже бинарник, и как у бинарника, пока его на компоненты не
>> разобрали, у него та же самая самая жёсткая лицензия?
> Может быть, нам нужен синтаксис для описания лицензии исходных пакетов
> для случаев, когда лицензии исходного и бинарных пакетов не совпадают?

И ещё такой вопрос поступил (пока выкрутился, дав команду ls 
/usr/share/license): У нас где-то существует исчерпывающий список 
лицензий, под которыми допустима публикация кода в публичных бранчах? 
Что-то вроде этого из 
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines 
:

All software in Fedora must be under licenses in the *Fedora licensing 
list*. This list is based on the licenses approved by the Free Software 
Foundation, OSI and consultation with Red Hat Legal.

https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses



-- 
Best regards,
Leonid Krivoshein.

Re: [devel] License tag for source packages

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3336 bytes --]

On Wed, 18 Mar 2020 00:07:58 +0300 Leonid Krivoshein wrote:
> 
> 17.03.2020 19:40, Dmitry V. Levin пишет:
> > On Tue, Mar 17, 2020 at 05:31:20PM +0400, Sergey Afonin wrote:
> >> On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
> >>
> >>> Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
> >>> где это что-то такое сказано для Сизифа, но например у коллег из Федоры
> >>> написано чётко:
> >>>
> >>> The License: field refers to the licenses of the contents of the binary
> >>> rpm.
> >>>
> >>> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
> >>>
> >>> Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
> >>> GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
> >>> Потому что весь остальной код "автоматически" перелицензируется под
> >>> самую жесткую из лицензий, если может, а если не может, то такой
> >>> пакет нельзя собирать в Сизиф.
> >>   
> >> Хм. Рассматривать License c точки зрения бинарных пакетов я лично не
> >> догадался что-то. С одной стороны это упрощает содержимое тэга, но, с
> >> другой, а srpm тогда как? Туда же тот же тэг попадает. Или считается,
> >> что он тоже бинарник, и как у бинарника, пока его на компоненты не
> >> разобрали, у него та же самая самая жёсткая лицензия?
> > Может быть, нам нужен синтаксис для описания лицензии исходных пакетов
> > для случаев, когда лицензии исходного и бинарных пакетов не совпадают?
> 
> И ещё такой вопрос поступил (пока выкрутился, дав команду ls 
> /usr/share/license): У нас где-то существует исчерпывающий список 
> лицензий, под которыми допустима публикация кода в публичных бранчах? 
> Что-то вроде этого из 
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines 
> :
> 
> All software in Fedora must be under licenses in the *Fedora licensing 
> list*. This list is based on the licenses approved by the Free Software 
> Foundation, OSI and consultation with Red Hat Legal.
> 
> https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses

Я думаю, что под любой, которая не запрещает распространение
исходных кодов. Нет смысла ограничивать фиксированным списком
лицензий, т.к. всё время возникают новые.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] License tag for source packages

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 6387 bytes --]

On Tue, 17 Mar 2020 23:52:08 +0300 Leonid Krivoshein wrote:
> 
> 
> 17.03.2020 23:06, Dmitry V. Levin пишет:
> > On Tue, Mar 17, 2020 at 07:56:52PM +0300, Andrey Savchenko wrote:
> >> On Tue, 17 Mar 2020 19:40:32 +0300 Dmitry V. Levin wrote:
> >>> On Tue, Mar 17, 2020 at 05:31:20PM +0400, Sergey Afonin wrote:
> >>>> On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
> >>>>
> >>>>> Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
> >>>>> где это что-то такое сказано для Сизифа, но например у коллег из Федоры
> >>>>> написано чётко:
> >>>>>
> >>>>> The License: field refers to the licenses of the contents of the binary
> >>>>> rpm.
> >>>>>
> >>>>> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
> >>>>>
> >>>>> Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
> >>>>> GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
> >>>>> Потому что весь остальной код "автоматически" перелицензируется под
> >>>>> самую жесткую из лицензий, если может, а если не может, то такой
> >>>>> пакет нельзя собирать в Сизиф.
> >>>>   
> >>>> Хм. Рассматривать License c точки зрения бинарных пакетов я лично не
> >>>> догадался что-то. С одной стороны это упрощает содержимое тэга, но, с
> >>>> другой, а srpm тогда как? Туда же тот же тэг попадает. Или считается,
> >>>> что он тоже бинарник, и как у бинарника, пока его на компоненты не
> >>>> разобрали, у него та же самая самая жёсткая лицензия?
> >>> Может быть, нам нужен синтаксис для описания лицензии исходных пакетов
> >>> для случаев, когда лицензии исходного и бинарных пакетов не совпадают?
> >> Я поддерживаю эту идею, например, тег SourceLicense.
> > Видимо, новый rpm header tag нам не понадобится, поскольку можно будет
> > продолжать использовать RPMTAG_LICENSE для исходных пакетов.
> > А вот какой-нибудь новый rpm spec tag, хотя бы тот же SourceLicense,
> > выглядит логично.
> 
> Ранее Андрей в этом обсуждении верно заметил: нужен чисто сборочный 
> пакет, а всё остальное выносить в под-пакеты. Проблем-то нет, а 
> SourceLicense позволит уйти от такой обязаловки.

Я привёл этот способ как вынужденный обходной манёвр, а не как
рекомендуемый метод решения проблемы. Лишние подпакеты — это
неудобно и громоздко. Опциональный spec tag, который по-умолчанию
равен License и переопределяется лишь в особых ситуациях,— гораздо
более лаконичное и удобное решение.

> Пользуясь случаем хочу спросить о лицензии на сами спеки. :-) Они ведь 
> тоже исходники. И часто эти исходники перетекают между разными 
> производителями дистрибутивов, пусть и не 1:1. Меня давно интересует 
> вопрос, под какими лицензиями они идут? К ним применимы лицензии от 
> пакета или лицензия от дистрибутива? В последнем случае, дистрибутив 
> может быть не совсем свободным, а пакет быть часть бранча, а не частью 
> дистрибутива. У бранча ведь нет единой лицензии? Вопрос "обострился" в 
> связи с подготовкой нового Падавана.

Это хороший вопрос. В Альте, насколько я знаю, явно лицензия на код
самого spec нигде не задана; интересно, как на этот счёт в Fedora,
сходу я этого тоже не нашёл. В Gentoo с этим порядок: там на
каждый ebuild и eclass явно задана лицензия GPL-2.0 и другие не
разрешаются.

Думаю, что на spec при незаданной лицензии всеми участниками
подразумевается public domain, однако, обращу внимание, что
согласно российскому праву, если лицензия не указана, то код
считается проприетарным.

Возможно, нам нужно какое-то соглашение или policy на эту тему.
Я бы предпочёл GPLv3+ на наши собственные спеки. С заимствованными
непонятно что делать.

Нужно ещё понимать, что лицензированию подлежит только
нетривиальный код в спеках. Т.е. копирование текстовых полей
(description, summary и т.п.) не влечёт необходимости копировать
лицензию оригинала. То же самое касается тривиальных спеков с
типовыми действиями вида:

%prep
%patch0 -p1

%build
%configure
%make_build

%install
%makeinstall_std

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] License tag for source packages

[Dmitry V. Levin]

On Wed, Mar 18, 2020 at 01:16:01AM +0300, Andrey Savchenko wrote:
> On Tue, 17 Mar 2020 23:52:08 +0300 Leonid Krivoshein wrote:
[...]
> > Пользуясь случаем хочу спросить о лицензии на сами спеки. :-) Они ведь 
> > тоже исходники. И часто эти исходники перетекают между разными 
> > производителями дистрибутивов, пусть и не 1:1. Меня давно интересует 
> > вопрос, под какими лицензиями они идут? К ним применимы лицензии от 
> > пакета или лицензия от дистрибутива? В последнем случае, дистрибутив 
> > может быть не совсем свободным, а пакет быть часть бранча, а не частью 
> > дистрибутива. У бранча ведь нет единой лицензии? Вопрос "обострился" в 
> > связи с подготовкой нового Падавана.
> 
> Это хороший вопрос. В Альте, насколько я знаю, явно лицензия на код
> самого spec нигде не задана; интересно, как на этот счёт в Fedora,
> сходу я этого тоже не нашёл. В Gentoo с этим порядок: там на
> каждый ebuild и eclass явно задана лицензия GPL-2.0 и другие не
> разрешаются.
> 
> Думаю, что на spec при незаданной лицензии всеми участниками
> подразумевается public domain, однако, обращу внимание, что
> согласно российскому праву, если лицензия не указана, то код
> считается проприетарным.
> 
> Возможно, нам нужно какое-то соглашение или policy на эту тему.
> Я бы предпочёл GPLv3+ на наши собственные спеки. С заимствованными
> непонятно что делать.

Поскольку spec является частью исходного пакета, то по умолчанию
(если в спеке не написано иное) лицензия на спек - это лицензия на
исходный пакет.  В случае, когда лицензия на исходный пакет составная,
возникает неопределённость.


-- 
ldv

Re: [devel] License tag for source packages

[Leonid Krivoshein]

18.03.2020 1:31, Dmitry V. Levin пишет:
> On Wed, Mar 18, 2020 at 01:16:01AM +0300, Andrey Savchenko wrote:
>> On Tue, 17 Mar 2020 23:52:08 +0300 Leonid Krivoshein wrote:
> [...]
>>> Пользуясь случаем хочу спросить о лицензии на сами спеки. :-) Они ведь
>>> тоже исходники. И часто эти исходники перетекают между разными
>>> производителями дистрибутивов, пусть и не 1:1. Меня давно интересует
>>> вопрос, под какими лицензиями они идут? К ним применимы лицензии от
>>> пакета или лицензия от дистрибутива? В последнем случае, дистрибутив
>>> может быть не совсем свободным, а пакет быть часть бранча, а не частью
>>> дистрибутива. У бранча ведь нет единой лицензии? Вопрос "обострился" в
>>> связи с подготовкой нового Падавана.
>> Это хороший вопрос. В Альте, насколько я знаю, явно лицензия на код
>> самого spec нигде не задана; интересно, как на этот счёт в Fedora,
>> сходу я этого тоже не нашёл. В Gentoo с этим порядок: там на
>> каждый ebuild и eclass явно задана лицензия GPL-2.0 и другие не
>> разрешаются.
>>
>> Думаю, что на spec при незаданной лицензии всеми участниками
>> подразумевается public domain, однако, обращу внимание, что
>> согласно российскому праву, если лицензия не указана, то код
>> считается проприетарным.
>>
>> Возможно, нам нужно какое-то соглашение или policy на эту тему.
>> Я бы предпочёл GPLv3+ на наши собственные спеки. С заимствованными
>> непонятно что делать.
> Поскольку spec является частью исходного пакета, то по умолчанию
> (если в спеке не написано иное) лицензия на спек - это лицензия на
> исходный пакет.  В случае, когда лицензия на исходный пакет составная,
> возникает неопределённость.

Это было бы совсем логично, если бы спек шёл вместе с исходниками из 
апстрима, но такое случается далеко не всегда. Очевидно, что чаще этот 
спек пишется другим человеком, а не тем же коллективом, что работали над 
упакованными исходниками. В отсутствии ясного policy на эту тему, 
вариант считать спек лицензируемым под лицензией самого пакета, 
напрашивается, но только как один из вариантов. Поэтому и уточнил, на 
всякий случай.

К слову, у нас в policy хотя бы предлагается сохранять информацию об 
источниках патчей, чтобы не гадать потом насчёт их авторства. А ведь 
тоже встаёт вопрос лицензий, хотя с патчами проще -- уж они-то точно 
должны идти под лицензией исходника ПО. Но об этом явно опять же нигде 
не говорится.

Ух уж эти юристы...))


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] License tag for source packages

[Alexey Gladkov]

On Wed, Mar 18, 2020 at 01:31:40AM +0300, Dmitry V. Levin wrote:
> On Wed, Mar 18, 2020 at 01:16:01AM +0300, Andrey Savchenko wrote:
> > On Tue, 17 Mar 2020 23:52:08 +0300 Leonid Krivoshein wrote:
> [...]
> > > Пользуясь случаем хочу спросить о лицензии на сами спеки. :-) Они ведь 
> > > тоже исходники. И часто эти исходники перетекают между разными 
> > > производителями дистрибутивов, пусть и не 1:1. Меня давно интересует 
> > > вопрос, под какими лицензиями они идут? К ним применимы лицензии от 
> > > пакета или лицензия от дистрибутива? В последнем случае, дистрибутив 
> > > может быть не совсем свободным, а пакет быть часть бранча, а не частью 
> > > дистрибутива. У бранча ведь нет единой лицензии? Вопрос "обострился" в 
> > > связи с подготовкой нового Падавана.
> > 
> > Это хороший вопрос. В Альте, насколько я знаю, явно лицензия на код
> > самого spec нигде не задана; интересно, как на этот счёт в Fedora,
> > сходу я этого тоже не нашёл. В Gentoo с этим порядок: там на
> > каждый ebuild и eclass явно задана лицензия GPL-2.0 и другие не
> > разрешаются.
> > 
> > Думаю, что на spec при незаданной лицензии всеми участниками
> > подразумевается public domain, однако, обращу внимание, что
> > согласно российскому праву, если лицензия не указана, то код
> > считается проприетарным.
> > 
> > Возможно, нам нужно какое-то соглашение или policy на эту тему.
> > Я бы предпочёл GPLv3+ на наши собственные спеки. С заимствованными
> > непонятно что делать.
> 
> Поскольку spec является частью исходного пакета, то по умолчанию
> (если в спеке не написано иное) лицензия на спек - это лицензия на
> исходный пакет.  В случае, когда лицензия на исходный пакет составная,
> возникает неопределённость.

В suse делают хэдер, чтобы избавится от домыслов:

https://build.opensuse.org/package/view_file/openSUSE:Factory/libqt5-qtbase/libqt5-qtbase.spec?expand=1

Может у нас стоит сделать в начале спека что-нибудь типа:

# SPDX-License-Identifier: GPL-2.0-or-later

?

-- 
Rgrds, legion

Re: [devel] License tag for source packages

[Dmitry V. Levin]

On Tue, Mar 17, 2020 at 11:56:24PM +0100, Alexey Gladkov wrote:
> On Wed, Mar 18, 2020 at 01:31:40AM +0300, Dmitry V. Levin wrote:
> > On Wed, Mar 18, 2020 at 01:16:01AM +0300, Andrey Savchenko wrote:
> > > On Tue, 17 Mar 2020 23:52:08 +0300 Leonid Krivoshein wrote:
> > [...]
> > > > Пользуясь случаем хочу спросить о лицензии на сами спеки. :-) Они ведь 
> > > > тоже исходники. И часто эти исходники перетекают между разными 
> > > > производителями дистрибутивов, пусть и не 1:1. Меня давно интересует 
> > > > вопрос, под какими лицензиями они идут? К ним применимы лицензии от 
> > > > пакета или лицензия от дистрибутива? В последнем случае, дистрибутив 
> > > > может быть не совсем свободным, а пакет быть часть бранча, а не частью 
> > > > дистрибутива. У бранча ведь нет единой лицензии? Вопрос "обострился" в 
> > > > связи с подготовкой нового Падавана.
> > > 
> > > Это хороший вопрос. В Альте, насколько я знаю, явно лицензия на код
> > > самого spec нигде не задана; интересно, как на этот счёт в Fedora,
> > > сходу я этого тоже не нашёл. В Gentoo с этим порядок: там на
> > > каждый ebuild и eclass явно задана лицензия GPL-2.0 и другие не
> > > разрешаются.
> > > 
> > > Думаю, что на spec при незаданной лицензии всеми участниками
> > > подразумевается public domain, однако, обращу внимание, что
> > > согласно российскому праву, если лицензия не указана, то код
> > > считается проприетарным.
> > > 
> > > Возможно, нам нужно какое-то соглашение или policy на эту тему.
> > > Я бы предпочёл GPLv3+ на наши собственные спеки. С заимствованными
> > > непонятно что делать.
> > 
> > Поскольку spec является частью исходного пакета, то по умолчанию
> > (если в спеке не написано иное) лицензия на спек - это лицензия на
> > исходный пакет.  В случае, когда лицензия на исходный пакет составная,
> > возникает неопределённость.
> 
> В suse делают хэдер, чтобы избавится от домыслов:
> 
> https://build.opensuse.org/package/view_file/openSUSE:Factory/libqt5-qtbase/libqt5-qtbase.spec?expand=1
> 
> Может у нас стоит сделать в начале спека что-нибудь типа:
> 
> # SPDX-License-Identifier: GPL-2.0-or-later
> 
> ?

Можно, конечно, но тогда, по идее, ещё логично было бы и copyright holder
указать.


-- 
ldv

Re: [devel] License tag for source packages

[Alexey V. Vissarionov]

On 2020-03-18 00:50:50 +0300, Andrey Savchenko wrote:

 >> И ещё такой вопрос поступил (пока выкрутился, дав команду ls
 >> /usr/share/license): У нас где-то существует исчерпывающий список
 >> лицензий, под которыми допустима публикация кода в публичных
 >> бранчах? Что-то вроде этого из
 >> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines
 >> All software in Fedora must be under licenses in the *Fedora
 >> licensing list*. This list is based on the licenses approved by the
 >> Free Software Foundation, OSI and consultation with Red Hat Legal.
 >> https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses
 > Я думаю, что под любой, которая не запрещает распространение
 > исходных кодов. Нет смысла ограничивать фиксированным списком
 > лицензий, т.к. всё время возникают новые.

Увы, у ГК по данному вопросу может быть другое мнение... А вот что
действительно было бы полезно, так это опубликовать список заведомо
подходящих лицензий: это значительно упростит жизнь и мейнтейнерам
(если есть в списке, значит точно можно собирать), и разработчикам
(в условиях царящего в обществе правового нигилизма грамотно выбрать
лицензию для своих трудов не так уж просто).

Я предпочитаю WTFPL (ибо http://pics.rsh.ru/img/gafometer_u67qh.png),
но далеко не все могут себе это позволить, а выбор очень уж обширен.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] License tag for source packages

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3757 bytes --]

On Wed, 18 Mar 2020 02:10:19 +0300 Dmitry V. Levin wrote:
> On Tue, Mar 17, 2020 at 11:56:24PM +0100, Alexey Gladkov wrote:
> > On Wed, Mar 18, 2020 at 01:31:40AM +0300, Dmitry V. Levin wrote:
> > > On Wed, Mar 18, 2020 at 01:16:01AM +0300, Andrey Savchenko wrote:
> > > > On Tue, 17 Mar 2020 23:52:08 +0300 Leonid Krivoshein wrote:
> > > [...]
> > > > > Пользуясь случаем хочу спросить о лицензии на сами спеки. :-) Они ведь 
> > > > > тоже исходники. И часто эти исходники перетекают между разными 
> > > > > производителями дистрибутивов, пусть и не 1:1. Меня давно интересует 
> > > > > вопрос, под какими лицензиями они идут? К ним применимы лицензии от 
> > > > > пакета или лицензия от дистрибутива? В последнем случае, дистрибутив 
> > > > > может быть не совсем свободным, а пакет быть часть бранча, а не частью 
> > > > > дистрибутива. У бранча ведь нет единой лицензии? Вопрос "обострился" в 
> > > > > связи с подготовкой нового Падавана.
> > > > 
> > > > Это хороший вопрос. В Альте, насколько я знаю, явно лицензия на код
> > > > самого spec нигде не задана; интересно, как на этот счёт в Fedora,
> > > > сходу я этого тоже не нашёл. В Gentoo с этим порядок: там на
> > > > каждый ebuild и eclass явно задана лицензия GPL-2.0 и другие не
> > > > разрешаются.
> > > > 
> > > > Думаю, что на spec при незаданной лицензии всеми участниками
> > > > подразумевается public domain, однако, обращу внимание, что
> > > > согласно российскому праву, если лицензия не указана, то код
> > > > считается проприетарным.
> > > > 
> > > > Возможно, нам нужно какое-то соглашение или policy на эту тему.
> > > > Я бы предпочёл GPLv3+ на наши собственные спеки. С заимствованными
> > > > непонятно что делать.
> > > 
> > > Поскольку spec является частью исходного пакета, то по умолчанию
> > > (если в спеке не написано иное) лицензия на спек - это лицензия на
> > > исходный пакет.  В случае, когда лицензия на исходный пакет составная,
> > > возникает неопределённость.
> > 
> > В suse делают хэдер, чтобы избавится от домыслов:
> > 
> > https://build.opensuse.org/package/view_file/openSUSE:Factory/libqt5-qtbase/libqt5-qtbase.spec?expand=1
> > 
> > Может у нас стоит сделать в начале спека что-нибудь типа:
> > 
> > # SPDX-License-Identifier: GPL-2.0-or-later

Пожалуйста, не нужно тащить SPDX-помойку к нам в дистрибутив.

> Можно, конечно, но тогда, по идее, ещё логично было бы и copyright holder
> указать.

Да, это разумно.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] License tag for source packages

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3814 bytes --]

On Wed, 18 Mar 2020 01:48:17 +0300 Leonid Krivoshein wrote:
> 
> 18.03.2020 1:31, Dmitry V. Levin пишет:
> > On Wed, Mar 18, 2020 at 01:16:01AM +0300, Andrey Savchenko wrote:
> >> On Tue, 17 Mar 2020 23:52:08 +0300 Leonid Krivoshein wrote:
> > [...]
> >>> Пользуясь случаем хочу спросить о лицензии на сами спеки. :-) Они ведь
> >>> тоже исходники. И часто эти исходники перетекают между разными
> >>> производителями дистрибутивов, пусть и не 1:1. Меня давно интересует
> >>> вопрос, под какими лицензиями они идут? К ним применимы лицензии от
> >>> пакета или лицензия от дистрибутива? В последнем случае, дистрибутив
> >>> может быть не совсем свободным, а пакет быть часть бранча, а не частью
> >>> дистрибутива. У бранча ведь нет единой лицензии? Вопрос "обострился" в
> >>> связи с подготовкой нового Падавана.
> >> Это хороший вопрос. В Альте, насколько я знаю, явно лицензия на код
> >> самого spec нигде не задана; интересно, как на этот счёт в Fedora,
> >> сходу я этого тоже не нашёл. В Gentoo с этим порядок: там на
> >> каждый ebuild и eclass явно задана лицензия GPL-2.0 и другие не
> >> разрешаются.
> >>
> >> Думаю, что на spec при незаданной лицензии всеми участниками
> >> подразумевается public domain, однако, обращу внимание, что
> >> согласно российскому праву, если лицензия не указана, то код
> >> считается проприетарным.
> >>
> >> Возможно, нам нужно какое-то соглашение или policy на эту тему.
> >> Я бы предпочёл GPLv3+ на наши собственные спеки. С заимствованными
> >> непонятно что делать.
> > Поскольку spec является частью исходного пакета, то по умолчанию
> > (если в спеке не написано иное) лицензия на спек - это лицензия на
> > исходный пакет.  В случае, когда лицензия на исходный пакет составная,
> > возникает неопределённость.
> 
> Это было бы совсем логично, если бы спек шёл вместе с исходниками из 
> апстрима, но такое случается далеко не всегда. Очевидно, что чаще этот 
> спек пишется другим человеком, а не тем же коллективом, что работали над 
> упакованными исходниками.

Когда делаются изменения или дополнения кода апстрима, это обычно
осуществляется под лицензией апстрима. В определённой степени, но,
разумеется, не строго говоря, написание spec можно рассматривать
одним из таких изменений, поэтому логика ldv мне понятна.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] License tag for source packages

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3028 bytes --]

On Wed, 18 Mar 2020 11:16:53 +0300 Alexey V. Vissarionov wrote:
> On 2020-03-18 00:50:50 +0300, Andrey Savchenko wrote:
> 
>  >> И ещё такой вопрос поступил (пока выкрутился, дав команду ls
>  >> /usr/share/license): У нас где-то существует исчерпывающий список
>  >> лицензий, под которыми допустима публикация кода в публичных
>  >> бранчах? Что-то вроде этого из
>  >> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines
>  >> All software in Fedora must be under licenses in the *Fedora
>  >> licensing list*. This list is based on the licenses approved by the
>  >> Free Software Foundation, OSI and consultation with Red Hat Legal.
>  >> https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses
>  > Я думаю, что под любой, которая не запрещает распространение
>  > исходных кодов. Нет смысла ограничивать фиксированным списком
>  > лицензий, т.к. всё время возникают новые.
> 
> Увы, у ГК по данному вопросу может быть другое мнение...

Пример в студию, пожалуйста.

> А вот что
> действительно было бы полезно, так это опубликовать список заведомо
> подходящих лицензий: это значительно упростит жизнь и мейнтейнерам
> (если есть в списке, значит точно можно собирать), и разработчикам
> (в условиях царящего в обществе правового нигилизма грамотно выбрать
> лицензию для своих трудов не так уж просто).

Думаю, для нулевого приближения достаточно ориентироваться в данном
вопросе на другие дистрибутивы, которые уже проделали эту работу.
Зачем изобретать велосипед?

> Я предпочитаю WTFPL (ибо http://pics.rsh.ru/img/gafometer_u67qh.png),
> но далеко не все могут себе это позволить, а выбор очень уж обширен.

WTFPL (первая версия) как раз юридической значимости и не имеет, по
крайней мере в Европе и США из-за неправильно оформления, поэтому
сделали 2.0. 

Вторая версия таковую имеет, но настоятельно не рекомендуется FSF:
https://www.gnu.org/licenses/license-list.html#WTFPL

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] License tag for source packages

[Sergey Afonin]

On Wednesday 18 March 2020, Andrey Savchenko wrote:

> > > # SPDX-License-Identifier: GPL-2.0-or-later
> 
> Пожалуйста, не нужно тащить SPDX-помойку к нам в дистрибутив.
 
Нужно какое-то однообразие. На текущий момент получается, что
одним не нравится rpm-build-licenses, другим common-licenses.
Что делать мантейнерам, которым в принципе не важно, но которые
понимают нужность однообразия? Пока ждать и ничего больше не
делать?

-- 
С уважением, Сергей Афонин.

Re: [devel] License tag for source packages

[Dmitry V. Levin]

On Wed, Mar 18, 2020 at 11:45:14AM +0300, Andrey Savchenko wrote:
> On Wed, 18 Mar 2020 02:10:19 +0300 Dmitry V. Levin wrote:
> > On Tue, Mar 17, 2020 at 11:56:24PM +0100, Alexey Gladkov wrote:
> > > On Wed, Mar 18, 2020 at 01:31:40AM +0300, Dmitry V. Levin wrote:
> > > > On Wed, Mar 18, 2020 at 01:16:01AM +0300, Andrey Savchenko wrote:
> > > > > On Tue, 17 Mar 2020 23:52:08 +0300 Leonid Krivoshein wrote:
> > > > [...]
> > > > > > Пользуясь случаем хочу спросить о лицензии на сами спеки. :-) Они ведь 
> > > > > > тоже исходники. И часто эти исходники перетекают между разными 
> > > > > > производителями дистрибутивов, пусть и не 1:1. Меня давно интересует 
> > > > > > вопрос, под какими лицензиями они идут? К ним применимы лицензии от 
> > > > > > пакета или лицензия от дистрибутива? В последнем случае, дистрибутив 
> > > > > > может быть не совсем свободным, а пакет быть часть бранча, а не частью 
> > > > > > дистрибутива. У бранча ведь нет единой лицензии? Вопрос "обострился" в 
> > > > > > связи с подготовкой нового Падавана.
> > > > > 
> > > > > Это хороший вопрос. В Альте, насколько я знаю, явно лицензия на код
> > > > > самого spec нигде не задана; интересно, как на этот счёт в Fedora,
> > > > > сходу я этого тоже не нашёл. В Gentoo с этим порядок: там на
> > > > > каждый ebuild и eclass явно задана лицензия GPL-2.0 и другие не
> > > > > разрешаются.
> > > > > 
> > > > > Думаю, что на spec при незаданной лицензии всеми участниками
> > > > > подразумевается public domain, однако, обращу внимание, что
> > > > > согласно российскому праву, если лицензия не указана, то код
> > > > > считается проприетарным.
> > > > > 
> > > > > Возможно, нам нужно какое-то соглашение или policy на эту тему.
> > > > > Я бы предпочёл GPLv3+ на наши собственные спеки. С заимствованными
> > > > > непонятно что делать.
> > > > 
> > > > Поскольку spec является частью исходного пакета, то по умолчанию
> > > > (если в спеке не написано иное) лицензия на спек - это лицензия на
> > > > исходный пакет.  В случае, когда лицензия на исходный пакет составная,
> > > > возникает неопределённость.
> > > 
> > > В suse делают хэдер, чтобы избавится от домыслов:
> > > 
> > > https://build.opensuse.org/package/view_file/openSUSE:Factory/libqt5-qtbase/libqt5-qtbase.spec?expand=1
> > > 
> > > Может у нас стоит сделать в начале спека что-нибудь типа:
> > > 
> > > # SPDX-License-Identifier: GPL-2.0-or-later
> 
> Пожалуйста, не нужно тащить SPDX-помойку к нам в дистрибутив.

Это самая компактная из распространённых форм записи, насколько мне
известно.  Не вижу тут проблемы.


-- 
ldv

Re: [devel] License tag for source packages

[Alexey Gladkov]

On Wed, Mar 18, 2020 at 12:50:50AM +0300, Andrey Savchenko wrote:
> On Wed, 18 Mar 2020 00:07:58 +0300 Leonid Krivoshein wrote:
> > 
> > 17.03.2020 19:40, Dmitry V. Levin пишет:
> > > On Tue, Mar 17, 2020 at 05:31:20PM +0400, Sergey Afonin wrote:
> > >> On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
> > >>
> > >>> Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
> > >>> где это что-то такое сказано для Сизифа, но например у коллег из Федоры
> > >>> написано чётко:
> > >>>
> > >>> The License: field refers to the licenses of the contents of the binary
> > >>> rpm.
> > >>>
> > >>> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
> > >>>
> > >>> Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
> > >>> GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
> > >>> Потому что весь остальной код "автоматически" перелицензируется под
> > >>> самую жесткую из лицензий, если может, а если не может, то такой
> > >>> пакет нельзя собирать в Сизиф.
> > >>   
> > >> Хм. Рассматривать License c точки зрения бинарных пакетов я лично не
> > >> догадался что-то. С одной стороны это упрощает содержимое тэга, но, с
> > >> другой, а srpm тогда как? Туда же тот же тэг попадает. Или считается,
> > >> что он тоже бинарник, и как у бинарника, пока его на компоненты не
> > >> разобрали, у него та же самая самая жёсткая лицензия?
> > > Может быть, нам нужен синтаксис для описания лицензии исходных пакетов
> > > для случаев, когда лицензии исходного и бинарных пакетов не совпадают?
> > 
> > И ещё такой вопрос поступил (пока выкрутился, дав команду ls 
> > /usr/share/license): У нас где-то существует исчерпывающий список 
> > лицензий, под которыми допустима публикация кода в публичных бранчах? 
> > Что-то вроде этого из 
> > https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines 
> > :
> > 
> > All software in Fedora must be under licenses in the *Fedora licensing 
> > list*. This list is based on the licenses approved by the Free Software 
> > Foundation, OSI and consultation with Red Hat Legal.
> > 
> > https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses
> 
> Я думаю, что под любой, которая не запрещает распространение
> исходных кодов. Нет смысла ограничивать фиксированным списком
> лицензий, т.к. всё время возникают новые.

Когда мы обсуждали это с ldv@ мы думали, что разрешённые лицензии
должны содержатся в common-licenses. Для этого и была добавлена проверка в
sisyphus_check т.е. в идеале пакет с лицензиями не из этого списка не
сможет попасть в сизиф.

-- 
Rgrds, legion

Re: [devel] License tag for source packages

[Alexey Gladkov]

On Wed, Mar 18, 2020 at 11:45:14AM +0300, Andrey Savchenko wrote:
> Пожалуйста, не нужно тащить SPDX-помойку к нам в дистрибутив.

Почему ?

Это достаточно хорошая попытка стандартизовать зоопарк с лицензиями. Я
синхронизирую common-licenses из SPDX и именование из там сейчас из SPDX.

-- 
Rgrds, legion

Re: [devel] License tag for source packages

[Anton Farygin]

On 18.03.2020 15:23, Alexey Gladkov wrote:
> On Wed, Mar 18, 2020 at 12:50:50AM +0300, Andrey Savchenko wrote:
>> On Wed, 18 Mar 2020 00:07:58 +0300 Leonid Krivoshein wrote:
>>> 17.03.2020 19:40, Dmitry V. Levin пишет:
>>>> On Tue, Mar 17, 2020 at 05:31:20PM +0400, Sergey Afonin wrote:
>>>>> On Tuesday 17 March 2020, Ivan A. Melnikov wrote:
>>>>>
>>>>>> Мне всегда казалось, что именно для этого этот тег и нужен. Я не нашёл,
>>>>>> где это что-то такое сказано для Сизифа, но например у коллег из Федоры
>>>>>> написано чётко:
>>>>>>
>>>>>> The License: field refers to the licenses of the contents of the binary
>>>>>> rpm.
>>>>>>
>>>>>> https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
>>>>>>
>>>>>> Это, в частности, означает, что если в пакете перемешан код под GPLv2+,
>>>>>> GPLv2-only и какой-нибудь MIT, то у пакета лицензия GPLv2-only, и точка.
>>>>>> Потому что весь остальной код "автоматически" перелицензируется под
>>>>>> самую жесткую из лицензий, если может, а если не может, то такой
>>>>>> пакет нельзя собирать в Сизиф.
>>>>>    
>>>>> Хм. Рассматривать License c точки зрения бинарных пакетов я лично не
>>>>> догадался что-то. С одной стороны это упрощает содержимое тэга, но, с
>>>>> другой, а srpm тогда как? Туда же тот же тэг попадает. Или считается,
>>>>> что он тоже бинарник, и как у бинарника, пока его на компоненты не
>>>>> разобрали, у него та же самая самая жёсткая лицензия?
>>>> Может быть, нам нужен синтаксис для описания лицензии исходных пакетов
>>>> для случаев, когда лицензии исходного и бинарных пакетов не совпадают?
>>> И ещё такой вопрос поступил (пока выкрутился, дав команду ls
>>> /usr/share/license): У нас где-то существует исчерпывающий список
>>> лицензий, под которыми допустима публикация кода в публичных бранчах?
>>> Что-то вроде этого из
>>> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines
>>> :
>>>
>>> All software in Fedora must be under licenses in the *Fedora licensing
>>> list*. This list is based on the licenses approved by the Free Software
>>> Foundation, OSI and consultation with Red Hat Legal.
>>>
>>> https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses
>> Я думаю, что под любой, которая не запрещает распространение
>> исходных кодов. Нет смысла ограничивать фиксированным списком
>> лицензий, т.к. всё время возникают новые.
> Когда мы обсуждали это с ldv@ мы думали, что разрешённые лицензии
> должны содержатся в common-licenses. Для этого и была добавлена проверка в
> sisyphus_check т.е. в идеале пакет с лицензиями не из этого списка не
> сможет попасть в сизиф.
А как быть с исключениями, которых много в разных пакетах и они в них 
разные ?

Re: [devel] License tag for source packages

[Alexey Gladkov]

On Wed, Mar 18, 2020 at 07:21:00PM +0300, Anton Farygin wrote:
> > Когда мы обсуждали это с ldv@ мы думали, что разрешённые лицензии
> > должны содержатся в common-licenses. Для этого и была добавлена проверка в
> > sisyphus_check т.е. в идеале пакет с лицензиями не из этого списка не
> > сможет попасть в сизиф.
> А как быть с исключениями, которых много в разных пакетах и они в них разные ?

Не должно быть исключений. Все тексты лицензий, которые есть в репозитории
должны где-то перечислены, например, в common-licenses. Иначе ты не всегда
можешь сказать можешь ли ты использовать репозиторий для своих целей.

offtopic: Я бы ещё хотел бы иметь возможность сказать apt-get, что я не
хочу ставить пакеты с несвободными лицензиями... типа чёрный/белый список.

-- 
Rgrds, legion

Re: [devel] License tag for source packages

[Anton Farygin]

On 18.03.2020 19:35, Alexey Gladkov wrote:
> On Wed, Mar 18, 2020 at 07:21:00PM +0300, Anton Farygin wrote:
>>> Когда мы обсуждали это с ldv@ мы думали, что разрешённые лицензии
>>> должны содержатся в common-licenses. Для этого и была добавлена проверка в
>>> sisyphus_check т.е. в идеале пакет с лицензиями не из этого списка не
>>> сможет попасть в сизиф.
>> А как быть с исключениями, которых много в разных пакетах и они в них разные ?
> Не должно быть исключений. Все тексты лицензий, которые есть в репозитории
> должны где-то перечислены, например, в common-licenses. Иначе ты не всегда
> можешь сказать можешь ли ты использовать репозиторий для своих целей.
>
> offtopic: Я бы ещё хотел бы иметь возможность сказать apt-get, что я не
> хочу ставить пакеты с несвободными лицензиями... типа чёрный/белый список.
>
Забери пожалуйста тогда тексты лицензий из этих пакетов:

js_of_ocaml/.gear/js_of_ocaml.spec:License: LGPLv2 with exceptions
ocaml-camlidl/.gear/ocaml-camlidl.spec:License: QPL and LGPLv2 with 
exceptions
ocaml-cryptokit/.gear/ocaml-cryptokit.spec:License: LGPLv2 with exceptions
ocaml-dose3/.gear/ocaml-dose3.spec:License: LGPLv3+ with exceptions
ocaml-extlib/.gear/ocaml-extlib.spec:License: LGPLv2 with exceptions
ocaml/.gear/ocaml.spec:License: LGPLv2.1 with exceptions
ocaml-gettext/.gear/ocaml-gettext.spec:License: LGPLv2+ with exceptions
ocaml-graphics/.gear/ocaml-graphics.spec:License: LGPLv2.1 with exceptions
ocaml-lablgtk/.gear/ocaml-lablgtk.spec:License: LGPLv2 with exceptions
ocaml-labltk/.gear/ocaml-labltk.spec:License: LGPLv2+ with exceptions
ocaml-mccs/.gear/ocaml-mccs.spec:License: BSD and LGPLv3+ with exceptions
ocaml-migrate-parsetree/.gear/ocaml-migrate-parsetree.spec:License: 
LGPLv2+ with exceptions
ocaml-num/.gear/ocaml-num.spec:License: LGPLv2+ with exceptions
ocaml-ocamlgraph/.gear/ocaml-ocamlgraph.spec:License: LGPLv2 with exceptions
ocaml-omake/.gear/ocaml-omake.spec:License:        LGPLv2+ with 
exceptions and GPLv2+ and BSD
ocaml-opam-file-format/.gear/ocaml-opam-file-format.spec:License: LGPLv2 
with exceptions
ocaml-re/.gear/ocaml-re.spec:License: LGPLv2 with exceptions
ocaml-ssl/.gear/ocaml-ssl.spec:License: LGPLv2.1 with exemptions
ocaml-type-conv/.gear/ocaml-type-conv.spec:License: LGPLv2+ with 
exceptions and BSD
ocaml-tyxml/.gear/ocaml-tyxml.spec:License:        LGPL with exeptions
ocaml-zarith/.gear/ocaml-zarith.spec:License: LGPLv2 with exceptions
ocaml-zip/.gear/ocaml-zip.spec:License: LGPLv2.1+ with exceptions

И что мне при этом в спеках нужно будет указывать ?

Re: [devel] License tag for source packages

[Alexey Gladkov]

On Wed, Mar 18, 2020 at 07:48:09PM +0300, Anton Farygin wrote:
> Забери пожалуйста тогда тексты лицензий из этих пакетов:
> 
> js_of_ocaml/.gear/js_of_ocaml.spec:License: LGPLv2 with exceptions
> ocaml-camlidl/.gear/ocaml-camlidl.spec:License: QPL and LGPLv2 with
> exceptions
> ocaml-cryptokit/.gear/ocaml-cryptokit.spec:License: LGPLv2 with exceptions
> ocaml-dose3/.gear/ocaml-dose3.spec:License: LGPLv3+ with exceptions
> ocaml-extlib/.gear/ocaml-extlib.spec:License: LGPLv2 with exceptions
> ocaml/.gear/ocaml.spec:License: LGPLv2.1 with exceptions
> ocaml-gettext/.gear/ocaml-gettext.spec:License: LGPLv2+ with exceptions
> ocaml-graphics/.gear/ocaml-graphics.spec:License: LGPLv2.1 with exceptions
> ocaml-lablgtk/.gear/ocaml-lablgtk.spec:License: LGPLv2 with exceptions
> ocaml-labltk/.gear/ocaml-labltk.spec:License: LGPLv2+ with exceptions
> ocaml-mccs/.gear/ocaml-mccs.spec:License: BSD and LGPLv3+ with exceptions
> ocaml-migrate-parsetree/.gear/ocaml-migrate-parsetree.spec:License: LGPLv2+
> with exceptions
> ocaml-num/.gear/ocaml-num.spec:License: LGPLv2+ with exceptions
> ocaml-ocamlgraph/.gear/ocaml-ocamlgraph.spec:License: LGPLv2 with exceptions
> ocaml-omake/.gear/ocaml-omake.spec:License:        LGPLv2+ with exceptions
> and GPLv2+ and BSD
> ocaml-opam-file-format/.gear/ocaml-opam-file-format.spec:License: LGPLv2
> with exceptions
> ocaml-re/.gear/ocaml-re.spec:License: LGPLv2 with exceptions
> ocaml-ssl/.gear/ocaml-ssl.spec:License: LGPLv2.1 with exemptions
> ocaml-type-conv/.gear/ocaml-type-conv.spec:License: LGPLv2+ with exceptions
> and BSD
> ocaml-tyxml/.gear/ocaml-tyxml.spec:License:        LGPL with exeptions
> ocaml-zarith/.gear/ocaml-zarith.spec:License: LGPLv2 with exceptions
> ocaml-zip/.gear/ocaml-zip.spec:License: LGPLv2.1+ with exceptions
> 
> И что мне при этом в спеках нужно будет указывать ?

GPL/LGPL/QPL/BSD в ассортименте уже там есть. Не думаю, что у тебя
возникнят трудности уточнить версию BSD. Вопрос в exceptions. У нас уже
есть список exceptions. Нужно добавить недостающие.

Тебе нужно будет писать всё тоже самое, но вместо "exceptions" будет
написано конкретное исключение.

-- 
Rgrds, legion

Re: [devel] License tag for source packages

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]

On Wed, 18 Mar 2020 13:50:48 +0300 Dmitry V. Levin wrote:
> On Wed, Mar 18, 2020 at 11:45:14AM +0300, Andrey Savchenko wrote:
> > On Wed, 18 Mar 2020 02:10:19 +0300 Dmitry V. Levin wrote:
> > > On Tue, Mar 17, 2020 at 11:56:24PM +0100, Alexey Gladkov wrote:
> > > > On Wed, Mar 18, 2020 at 01:31:40AM +0300, Dmitry V. Levin wrote:
[...]
> > > > > Поскольку spec является частью исходного пакета, то по умолчанию
> > > > > (если в спеке не написано иное) лицензия на спек - это лицензия на
> > > > > исходный пакет.  В случае, когда лицензия на исходный пакет составная,
> > > > > возникает неопределённость.
> > > > 
> > > > В suse делают хэдер, чтобы избавится от домыслов:
> > > > 
> > > > https://build.opensuse.org/package/view_file/openSUSE:Factory/libqt5-qtbase/libqt5-qtbase.spec?expand=1
> > > > 
> > > > Может у нас стоит сделать в начале спека что-нибудь типа:
> > > > 
> > > > # SPDX-License-Identifier: GPL-2.0-or-later
> > 
> > Пожалуйста, не нужно тащить SPDX-помойку к нам в дистрибутив.
> 
> Это самая компактная из распространённых форм записи, насколько мне
> известно.  Не вижу тут проблемы.

Я не против формы записи, я против тега SPDX-License-Identifier
и вообще явных завязок на SPDX. Идеология "the one ring to rule
them all" — это зло. Потом будет деление лицензий на SPDX и не
SPDX, вернее, такие призывы уже звучат; затем будет "давайте
не рекомендовать всё, что не SPDX" и "вообще, зачем что-то кроме
SPDX". Плавали, знаем, ещё один systemd.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] License tag for source packages (и лишние сущности)

[Michael Shigorin]

On Wed, Mar 18, 2020 at 01:50:48PM +0300, Dmitry V. Levin wrote:
> > > > Может у нас стоит сделать в начале спека что-нибудь типа:
> > > > # SPDX-License-Identifier: GPL-2.0-or-later
> > Пожалуйста, не нужно тащить SPDX-помойку к нам в дистрибутив.
> Это самая компактная из распространённых форм записи, насколько
> мне известно.  Не вижу тут проблемы.

Да ладно, а симлинк GPLv2+ -> GPL-2.0-or-later тоже не видишь?

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] License tag for source packages (и лишние сущности)

[Dmitry V. Levin]

On Wed, Mar 18, 2020 at 11:08:14PM +0300, Michael Shigorin wrote:
> On Wed, Mar 18, 2020 at 01:50:48PM +0300, Dmitry V. Levin wrote:
> > > > > Может у нас стоит сделать в начале спека что-нибудь типа:
> > > > > # SPDX-License-Identifier: GPL-2.0-or-later
> > > Пожалуйста, не нужно тащить SPDX-помойку к нам в дистрибутив.
> > Это самая компактная из распространённых форм записи, насколько
> > мне известно.  Не вижу тут проблемы.
> 
> Да ладно, а симлинк GPLv2+ -> GPL-2.0-or-later тоже не видишь?

Симлинк вижу, проблемы не вижу.


-- 
ldv

Re: [devel] License tag for source packages (и лишние сущности)

[Michael Shigorin]

On Wed, Mar 18, 2020 at 11:11:37PM +0300, Dmitry V. Levin wrote:
> > > > > > # SPDX-License-Identifier: GPL-2.0-or-later
> > > > Пожалуйста, не нужно тащить SPDX-помойку к нам в дистрибутив.
> > > Это самая компактная из распространённых форм записи,
> > > насколько мне известно.  Не вижу тут проблемы.
> > Да ладно, а симлинк GPLv2+ -> GPL-2.0-or-later тоже не видишь?
> Симлинк вижу, проблемы не вижу.

Форма записи GPLv2+ менее компактная или нераспространённая? :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] License tag for source packages (и лишние сущности)

[Dmitry V. Levin]

On Wed, Mar 18, 2020 at 11:14:46PM +0300, Michael Shigorin wrote:
> On Wed, Mar 18, 2020 at 11:11:37PM +0300, Dmitry V. Levin wrote:
> > > > > > > # SPDX-License-Identifier: GPL-2.0-or-later
> > > > > Пожалуйста, не нужно тащить SPDX-помойку к нам в дистрибутив.
> > > > Это самая компактная из распространённых форм записи,
> > > > насколько мне известно.  Не вижу тут проблемы.
> > > Да ладно, а симлинк GPLv2+ -> GPL-2.0-or-later тоже не видишь?
> > Симлинк вижу, проблемы не вижу.
> 
> Форма записи GPLv2+ менее компактная или нераспространённая? :)

Эта форма практически не встречается в copyright headers, которые
до распространения SPDX-License-Identifier были длиннее двух строк.


-- 
ldv

Re: [devel] License tag for source packages (и лишние сущности)

[Andrey Cherepanov]

18.03.2020 23:14, Michael Shigorin пишет:
> On Wed, Mar 18, 2020 at 11:11:37PM +0300, Dmitry V. Levin wrote:
>>>>>>> # SPDX-License-Identifier: GPL-2.0-or-later
>>>>> Пожалуйста, не нужно тащить SPDX-помойку к нам в дистрибутив.
>>>> Это самая компактная из распространённых форм записи,
>>>> насколько мне известно.  Не вижу тут проблемы.
>>> Да ладно, а симлинк GPLv2+ -> GPL-2.0-or-later тоже не видишь?
>> Симлинк вижу, проблемы не вижу.
> Форма записи GPLv2+ менее компактная или нераспространённая? :)

Какая-то деревенская запись в эпоху вполне вменяемой стандартизации SPDX.

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] License tag for source packages

[Anton Farygin]

On 18.03.2020 20:04, Alexey Gladkov wrote:
> Тебе нужно будет писать всё тоже самое, но вместо "exceptions" будет
> написано конкретное исключение.

ok. Тебе прислать эти тексты ?

Re: [devel] License tag for source packages

[Alexey Gladkov]

On Thu, Mar 19, 2020 at 07:05:01AM +0300, Anton Farygin wrote:
> On 18.03.2020 20:04, Alexey Gladkov wrote:
> > Тебе нужно будет писать всё тоже самое, но вместо "exceptions" будет
> > написано конкретное исключение.
> 
> ok. Тебе прислать эти тексты ?

Присылай новые. Я добавлю.

-- 
Rgrds, legion

Re: [devel] License tag for source packages

[Sergey Afonin]

On Wednesday 18 March 2020, Sergey Afonin wrote:

> > > > # SPDX-License-Identifier: GPL-2.0-or-later
> > 
> > Пожалуйста, не нужно тащить SPDX-помойку к нам в дистрибутив.
>  
> Нужно какое-то однообразие. На текущий момент получается, что
> одним не нравится rpm-build-licenses, другим common-licenses.
> Что делать мантейнерам, которым в принципе не важно, но которые
> понимают нужность однообразия? Пока ждать и ничего больше не
> делать?

На wiki обнаружилась страница https://www.altlinux.org/License_Tag_Policy
Кто бы её поправил по мотивам обсуждений, которых уже хорошее количество
накопилось. Собственно говоря, исходя их этого обсуждения, надо вообще
всё с нуля переписать там.

-- 
С уважением, Сергей Афонин.

Re: [devel] License tag for source packages

[Dmitry V. Levin]

On Wed, Mar 18, 2020 at 05:35:09PM +0100, Alexey Gladkov wrote:
> On Wed, Mar 18, 2020 at 07:21:00PM +0300, Anton Farygin wrote:
> > > Когда мы обсуждали это с ldv@ мы думали, что разрешённые лицензии
> > > должны содержатся в common-licenses. Для этого и была добавлена проверка в
> > > sisyphus_check т.е. в идеале пакет с лицензиями не из этого списка не
> > > сможет попасть в сизиф.
> > А как быть с исключениями, которых много в разных пакетах и они в них разные ?
> 
> Не должно быть исключений. Все тексты лицензий, которые есть в репозитории
> должны где-то перечислены, например, в common-licenses. Иначе ты не всегда
> можешь сказать можешь ли ты использовать репозиторий для своих целей.
> 
> offtopic: Я бы ещё хотел бы иметь возможность сказать apt-get, что я не
> хочу ставить пакеты с несвободными лицензиями... типа чёрный/белый список.

Не пора ли уже завести в Сизифе компоненту non-free?


-- 
ldv

Re: [devel] License tag for source packages

[Vladimir D. Seleznev]

On Sun, Mar 22, 2020 at 12:21:31AM +0300, Dmitry V. Levin wrote:
> On Wed, Mar 18, 2020 at 05:35:09PM +0100, Alexey Gladkov wrote:
> > On Wed, Mar 18, 2020 at 07:21:00PM +0300, Anton Farygin wrote:
> > > > Когда мы обсуждали это с ldv@ мы думали, что разрешённые лицензии
> > > > должны содержатся в common-licenses. Для этого и была добавлена проверка в
> > > > sisyphus_check т.е. в идеале пакет с лицензиями не из этого списка не
> > > > сможет попасть в сизиф.
> > > А как быть с исключениями, которых много в разных пакетах и они в них разные ?
> > 
> > Не должно быть исключений. Все тексты лицензий, которые есть в репозитории
> > должны где-то перечислены, например, в common-licenses. Иначе ты не всегда
> > можешь сказать можешь ли ты использовать репозиторий для своих целей.
> > 
> > offtopic: Я бы ещё хотел бы иметь возможность сказать apt-get, что я не
> > хочу ставить пакеты с несвободными лицензиями... типа чёрный/белый список.
> 
> Не пора ли уже завести в Сизифе компоненту non-free?

Давно пора.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] License tag for source packages

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3380 bytes --]

On Sun, 22 Mar 2020 00:59:24 +0300 Vladimir D. Seleznev wrote:
> On Sun, Mar 22, 2020 at 12:21:31AM +0300, Dmitry V. Levin wrote:
> > On Wed, Mar 18, 2020 at 05:35:09PM +0100, Alexey Gladkov wrote:
> > > On Wed, Mar 18, 2020 at 07:21:00PM +0300, Anton Farygin wrote:
> > > > > Когда мы обсуждали это с ldv@ мы думали, что разрешённые лицензии
> > > > > должны содержатся в common-licenses. Для этого и была добавлена проверка в
> > > > > sisyphus_check т.е. в идеале пакет с лицензиями не из этого списка не
> > > > > сможет попасть в сизиф.
> > > > А как быть с исключениями, которых много в разных пакетах и они в них разные ?
> > > 
> > > Не должно быть исключений. Все тексты лицензий, которые есть в репозитории
> > > должны где-то перечислены, например, в common-licenses. Иначе ты не всегда
> > > можешь сказать можешь ли ты использовать репозиторий для своих целей.
> > > 
> > > offtopic: Я бы ещё хотел бы иметь возможность сказать apt-get, что я не
> > > хочу ставить пакеты с несвободными лицензиями... типа чёрный/белый список.
> > 
> > Не пора ли уже завести в Сизифе компоненту non-free?
> 
> Давно пора.

На мой взгляд, это слишком грубое решение. Что мы хотим? Чтоб
пользователи могли фильтровать устанавливаемые пакеты по
лицензионном признаку. С критерием free/non-free есть проблемы,
т.к. между ними нет строгой границы: если лицензии не одобрена FSF,
но одобрена OSI — это free? WTFPL или CPL — это free?
Индивидуальные лицензии пакетов, отличные от списков FSF/OSI
(libpng, netcat, PCRE… много их) — это free? 

Кроме того, есть ситуации, когда пользователи хотят не все free
лицензии, например, не хотят AGPL.

Поэтому правильным решением было бы добавить в apt возможность
фильтра лицензий, а-ля AcceptLicense. Для удобства пользователей
можно сделать группы лицензий (@FSF-approved, @OSI-approved, @FREE,
@EULA и т.п.). Так сделали в Gentoo и это хорошо работает. Все
довольны. Для задач тестирования зависимостей репозитория можно
полагать, что все лицензии разрешены. В то же время у мейнтенеров
дистрибутивов будет возможность фильтровать лицензии по своему
усмотрению.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] License tag for source packages

[Alexey Gladkov]

On Sun, Mar 22, 2020 at 12:21:31AM +0300, Dmitry V. Levin wrote:
> > Не должно быть исключений. Все тексты лицензий, которые есть в репозитории
> > должны где-то перечислены, например, в common-licenses. Иначе ты не всегда
> > можешь сказать можешь ли ты использовать репозиторий для своих целей.
> > 
> > offtopic: Я бы ещё хотел бы иметь возможность сказать apt-get, что я не
> > хочу ставить пакеты с несвободными лицензиями... типа чёрный/белый список.
> 
> Не пора ли уже завести в Сизифе компоненту non-free?

Это может решить конкретно мою проблему, но для других этот non-free будет
разный. Кому-то non-military будет критерием, кому-то non-commercial.

-- 
Rgrds, legion

Re: [devel] License tag for source packages

[Sergey V Turchin]

On Sunday, 22 March 2020 11:50:31 MSK Andrey Savchenko wrote:

[...]
> Поэтому правильным решением было бы добавить в apt возможность
> фильтра лицензий, а-ля AcceptLicense. Для удобства пользователей
> можно сделать группы лицензий (@FSF-approved, @OSI-approved, @FREE,
> @EULA и т.п.). Так сделали в Gentoo и это хорошо работает.
Им проще, а у нас на этапе сборки от библиотеки не отсечёшь какой-нибудь кусок 
кода или модуль с неугодной лицензией и потянется вся борода.

[...]

-- 
Regards, Sergey.

Re: [devel] License tag for source packages

[Pavel Isopenko]

22.03.2020 18:12, Alexey Gladkov пишет:
>> Не пора ли уже завести в Сизифе компоненту non-free?

> Это может решить конкретно мою проблему, но для других этот non-free будет
> разный. Кому-то non-military будет критерием, кому-то non-commercial.

Детали можно отложить на потом. Что если для начала предположить, что в 
компоненту non-free могут собираться пакеты, не проходящие 
sisyphus-check по критерию common-licenses?
Какую-то часть проблемы зоопарка лицензий это решит, а там будет видно.

-- 
*Pavel Isopenko*
mob. +79165329582

Re: [devel] License tag for source packages

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

On Wed, 25 Mar 2020 11:17:01 +0300 Pavel Isopenko wrote:
> 22.03.2020 18:12, Alexey Gladkov пишет:
> >> Не пора ли уже завести в Сизифе компоненту non-free?
> 
> > Это может решить конкретно мою проблему, но для других этот non-free будет
> > разный. Кому-то non-military будет критерием, кому-то non-commercial.
> 
> Детали можно отложить на потом. Что если для начала предположить, что в 
> компоненту non-free могут собираться пакеты, не проходящие 
> sisyphus-check по критерию common-licenses?

У многих пакетов собственные уникальные лицензии, что не отменяет
их свободности. Ряд мейнтенеров против их помещения в
common-licenses, потому что они ни разу не common.

Давайте сперва выработаем политику в отношении таких лицензий.

> Какую-то часть проблемы зоопарка лицензий это решит, а там будет видно.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] License tag for source packages

[Sergey Afonin]

On Wednesday 25 March 2020, Andrey Savchenko wrote:

> > Детали можно отложить на потом. Что если для начала предположить, что
> > в компоненту non-free могут собираться пакеты, не проходящие 
> > sisyphus-check по критерию common-licenses?
> 
> У многих пакетов собственные уникальные лицензии, что не отменяет
> их свободности. Ряд мейнтенеров против их помещения в
> common-licenses, потому что они ни разу не common.
 
Переименовать в used-licenses (или used-in-alt-licenses)? А там уже внутри
поделить на всякие разные.

-- 
С уважением, Сергей Афонин.

Re: [devel] License tag for source packages

[Sergey Afonin]

On Wednesday 25 March 2020, Denis Medvedev wrote:

> Ну назовите это repo-licenses-all ?

О, вот alt-repo-licenses хорошо звучит, как мне кажется.

-- 
С уважением, Сергей Афонин.

Re: [devel] License tag for source packages

[Alexey V. Vissarionov]

On 2020-03-25 12:32:35 +0400, Sergey Afonin wrote:

 >>> Детали можно отложить на потом. Что если для начала
 >>> предположить, что в компоненту non-free могут собираться
 >>> пакеты, не проходящие sisyphus-check по критерию
 >>> common-licenses?
 >> У многих пакетов собственные уникальные лицензии, что
 >> не отменяет их свободности. Ряд мейнтенеров против их
 >> помещения в common-licenses, потому что они ни разу не
 >> common.
 > Переименовать в used-licenses (или used-in-alt-licenses)?
 > А там уже внутри поделить на всякие разные.

Скорее, alt-package-licenses

Так понятнее, что это собранный нами (^alt-) комплект лицензий
(-licenses$), актуальных для наших пакетов (-package-). В нем,
соответственно, могут быть %package non-free или %package gpl
(для всех разновидностей и вариаций на тему).

А вообще, конечно, 99.99% нашей целевой аудитории на лицензии
откровенно начхать... какое-то подобие fair use они еще могут
изобразить, но только пока их это вообще никак не напрягает.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] License tag for source packages

[Sergey Afonin]

On Wednesday 25 March 2020, Alexey V. Vissarionov wrote:

> Скорее, alt-package-licenses

Тогда alt-packages-licenses :-)

-- 
С уважением, Сергей Афонин.

Re: [devel] License tag

[Sergey Afonin]

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?

-- 
С уважением, Сергей Афонин.

Re: [devel] License tag for source packages

[Alexey V. Vissarionov]

On 2020-03-25 13:46:27 +0400, Sergey Afonin wrote:

 >> Скорее, alt-package-licenses
 > Тогда alt-packages-licenses :-)

Не-а... при формировании множественного числа суффикс "-s"
добавляется только к главному слову в словосочетании.

Я сейчас даже не поленился, дернул знакомых лингвистов -
а то мало ли, вдруг я совсем дурак? Они меня успокоили :-)


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] License tag

[Alexey V. Vissarionov]

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

Re: [devel] nfdump

[Dmitry V. Levin]

On Wed, Mar 25, 2020 at 01:55:09PM +0400, Sergey Afonin wrote:
> 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.

Давайте разберём.
Если пакет содержит LZ4, но не является liblz4, это ошибка, которую следует исправить.
Если пакет ещё и является библиотекой, то эта ошибка критическая.

https://bugzilla.altlinux.org/36391


-- 
ldv

Re: [devel] nfdump

[Sergey Afonin]

On Wednesday 25 March 2020, Dmitry V. Levin wrote:

> Давайте разберём.

> Если пакет содержит LZ4, но не является liblz4, это ошибка, которую следует
> исправить. Если пакет ещё и является библиотекой, то эта ошибка критическая.

Это не про лицензии.

-- 
С уважением, Сергей Афонин.

Re: [devel] License tag

[Sergey Afonin]

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

Кстати можно английский там подрихтовать, явно есть, где...

-- 
С уважением, Сергей Афонин.

Re: [devel] License tag

[Sergey Afonin]

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?

-- 
С уважением, Сергей Афонин.

Re: [devel] License tag

[Andrey Savchenko]

[-- 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 --]

Re: [devel] License tag

[Sergey Y. Afonin]

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+. Так?

-- 
С уважением, Сергей Афонин

Re: [devel] License tag

[Vladimir D. Seleznev]

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

Re: [devel] License tag

[Sergey Y. Afonin]

On Friday 03 April 2020, Vladimir D. Seleznev wrote:

> > Разделяемых библиотек я в пакете ntp сейчас нет. Но  LGPLv2.1 и  LGPLv2
> > присутствуют с пометкой, допускающей следующую версию. Получается, что
> > LGPLv3+ дозволена, а тогда можно писать GPLv3+. Так?
> 
> У нас с лицензиями возникла путаница. Ухудшает картину то, что до сих
> пор нет документации и рекомендаций по оформлению тега.

Это да. Нужно, чтобы кто-то разбирающийся написал. Я хоть и думаю, что
что-то понял, но именно, что что-то. А надо точно и с примерами. 

> Уже в обсуждении проскальзывало, что лицензии распространяются на
> исходный код, поэтому нужно перечислять все лицензии, под которыми этот
> исходный код распространяется.

Это для devel-пакетов, RPM допускает там отдельный тэг.

-- 
С уважением, Сергей Афонин