[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, 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: 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

[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

[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

[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

[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

[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

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

[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

[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

[@ 2020-03-17 21:07 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-17 21:50 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-18 8:16 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-18 9:32 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-18 12:23 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-18 16:21 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-18 16:35 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-18 16:48 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-18 17:04 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-19 4:05 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-19 9:52 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-21 21:21 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-21 21:59 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-22 8:50 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-23 11:53 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-22 15:12 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-25 8:17 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-25 8:22 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-25 8:32 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-25 9:32 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-25 9:46 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-25 10:02 UTC (permalink / raw)]

Re: [devel] License tag for source packages

[@ 2020-03-25 8:33 UTC (permalink / raw)]

Re: [devel] License tag

[@ 2020-03-25 9:55 UTC (permalink / raw)]

Re: [devel] License tag

[@ 2020-03-25 10:07 UTC (permalink / raw)]

Re: [devel] License tag

[@ 2020-03-25 14:06 UTC (permalink / raw)]

Re: [devel] nfdump

[@ 2020-03-25 10:12 UTC (permalink / raw)]

Re: [devel] nfdump

[@ 2020-03-25 10:23 UTC (permalink / raw)]

Re: [devel] License tag

[@ 2020-04-03 11:07 UTC (permalink / raw)]

Re: [devel] License tag

[@ 2020-04-03 12:27 UTC (permalink / raw)]

Re: [devel] License tag

[@ 2020-04-03 14:15 UTC (permalink / raw)]

Re: [devel] License tag

[@ 2020-04-03 14:28 UTC (permalink / raw)]

Re: [devel] License tag

[@ 2020-04-03 14:34 UTC (permalink / raw)]

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

[@ 2020-03-16 5:43 UTC (permalink / raw)]

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

[@ 2020-03-16 22:01 UTC (permalink / raw)]