[devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Andrey Savchenko]

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

Добрый день!

Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
https://www.gnu.org/licenses/license-list.html#OpenSSL

Исключение — когда GPL проект явно указывает OpenSSL exception.
Однако, в нашем license-exception из пакета common-licenses
openssl-exception отсутствует, но при этом есть
openvpn-openssl-exception, который не используется ни в одном из
пакетов (по крайней мере в Сизифе).

Поэтому предлагаю:
1) Добавить общий openssl-exception в common-licenses
2) Удалить неиспользуемый openvpn-openssl-exception
3) Мейнтенерам пакетов с GPL + OpenSSL указать корректную лицензию,
если апстрим даёт такой exception, в противном случае пересобрать
пакет с устранением нарушения лицензии.

Потенциально затронутых пакетов у нас много:
$ git grep -l -i -E "req.*:.*(open|lib)ssl" $(git grep -l -i -E "license:.*\<gpl") | wc -l
357

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

Обратите особое внимание, что исключение для линковки с GPL есть
не у всех пакетов. Например, его нет у ffmpeg:
https://ffmpeg.org/doxygen/4.1/md_LICENSE.html

В тоже время, наш ffmpeg-4.3.2 собран с --enable-gpl и одновременно
слинкован с openssl:
$ ldd ffmpeg  | grep libcrypt
        libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f80fb474000)

По сути, это является нарушением GPL в нашем репозитории: такой
бинарник распространять нельзя.

Поэтому проблему нужно устранить либо отключив компоненту, тянущую ssl,
либо пересобрав без использования GPL кода (это менее предпочтительный
вариант, т.к. зарубит часть оптимизаций и функциональности).

Могут быть и другие пакеты с такой же проблемой, поэтому всё,
где есть GPL и линковка с OpenSSL, нужно тщательно изучить
соответствующим мейнтенерам.

Best regards,
Andrew Savchenko

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

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Konstantin Lepikhov]

Hi Andrey!

On 04/04/2021, at 03:04:23 PM you wrote:

> Добрый день!
> 
> Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> https://www.gnu.org/licenses/license-list.html#OpenSSL
..
We recommend using GNUTLS instead of OpenSSL in software you write.
However, there is no reason not to use OpenSSL and applications that work
with OpenSSL.

Где тут написано, что будут санкции? Incompatible это очень обтекаемое
слово, особенно с рекламой gnutls ниже.

<skip>
> Могут быть и другие пакеты с такой же проблемой, поэтому всё,
> где есть GPL и линковка с OpenSSL, нужно тщательно изучить
> соответствующим мейнтенерам.
Мне кажется, проблемой должны заниматься юристы, а не мантейнеры.

-- 
WBR et al.

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Vladimir D. Seleznev]

On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
> Добрый день!
> 
> Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> https://www.gnu.org/licenses/license-list.html#OpenSSL
> 
> [skip]
> 
> В тоже время, наш ffmpeg-4.3.2 собран с --enable-gpl и одновременно
> слинкован с openssl:
> $ ldd ffmpeg  | grep libcrypt
>         libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f80fb474000)

Не подтверждаю:

	$ objdump -x /usr/bin/ffmpeg /usr/lib64/libav* /usr/lib64/libpostproc* /usr/lib64/libsw* |sed -e '/NEEDED/!d' -e '/libssl/!d'
	$ ldd /usr/lib64/libavformat.so.58 |grep libssl
	        libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fe86074d000)
	$ $ objdump -x /usr/lib64/libavformat.so.58 |sed -e '/NEEDED/!d' -e '/libssl/!d'

Получается, кто-то, с кем слинкован libavformat, слинкован с OpenSSL.
Вопрос: допустимо ли такое связывание лицензиями OpenSSL и GPL?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Vladimir D. Seleznev]

On Sun, Apr 04, 2021 at 02:40:00PM +0200, Konstantin Lepikhov wrote:
> Hi Andrey!
> 
> On 04/04/2021, at 03:04:23 PM you wrote:
> 
> > Добрый день!
> > 
> > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > https://www.gnu.org/licenses/license-list.html#OpenSSL
> ..
> We recommend using GNUTLS instead of OpenSSL in software you write.
> However, there is no reason not to use OpenSSL and applications that work
> with OpenSSL.
> 
> Где тут написано, что будут санкции? Incompatible это очень обтекаемое
> слово, особенно с рекламой gnutls ниже.
> 
> <skip>
> > Могут быть и другие пакеты с такой же проблемой, поэтому всё,
> > где есть GPL и линковка с OpenSSL, нужно тщательно изучить
> > соответствующим мейнтенерам.
> Мне кажется, проблемой должны заниматься юристы, а не мантейнеры.

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

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Andrey Savchenko]

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

On Sun, 4 Apr 2021 14:40:00 +0200 Konstantin Lepikhov wrote:
> Hi Andrey!
> 
> On 04/04/2021, at 03:04:23 PM you wrote:
> 
> > Добрый день!
> > 
> > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > https://www.gnu.org/licenses/license-list.html#OpenSSL
> ..
> We recommend using GNUTLS instead of OpenSSL in software you write.
> However, there is no reason not to use OpenSSL and applications that work
> with OpenSSL.
> 
> Где тут написано, что будут санкции? Incompatible это очень обтекаемое
> слово, особенно с рекламой gnutls ниже.

Вы не тот текст процитировали, следовало:

The license of OpenSSL is a conjunction of two licenses, one called
“OpenSSL License” and the other being the license of SSLeay. You
must follow both. The combination results in a copyleft free
software license that is incompatible with the GNU GPL. It also has
an advertising clause like the original BSD license and the Apache
1 license.

Лицензия OpenSSL содержит дополнительные ограничения на
распространение кода, что не допустимо согласно GPL.

> <skip>
> > Могут быть и другие пакеты с такой же проблемой, поэтому всё,
> > где есть GPL и линковка с OpenSSL, нужно тщательно изучить
> > соответствующим мейнтенерам.
> Мне кажется, проблемой должны заниматься юристы, а не мантейнеры.

Вы предлагаете игнорировать нарушение GPL в репозитории? 

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

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


Best regards,
Andrew Savchenko

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

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Dmitry V. Levin]

On Sun, Apr 04, 2021 at 03:51:19PM +0300, Vladimir D. Seleznev wrote:
> On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
> > Добрый день!
> > 
> > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > https://www.gnu.org/licenses/license-list.html#OpenSSL
> > 
> > [skip]
> > 
> > В тоже время, наш ffmpeg-4.3.2 собран с --enable-gpl и одновременно
> > слинкован с openssl:
> > $ ldd ffmpeg  | grep libcrypt
> >         libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f80fb474000)
> 
> Не подтверждаю:
> 
> 	$ objdump -x /usr/bin/ffmpeg /usr/lib64/libav* /usr/lib64/libpostproc* /usr/lib64/libsw* |sed -e '/NEEDED/!d' -e '/libssl/!d'
> 	$ ldd /usr/lib64/libavformat.so.58 |grep libssl
> 	        libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fe86074d000)
> 	$ $ objdump -x /usr/lib64/libavformat.so.58 |sed -e '/NEEDED/!d' -e '/libssl/!d'
> 
> Получается, кто-то, с кем слинкован libavformat, слинкован с OpenSSL.
> Вопрос: допустимо ли такое связывание лицензиями OpenSSL и GPL?

Если этот кто-то распространяется на условиях, так или иначе легализующих
линковку с openssl (например, под лицензией, совместимой с GPL и OpenSSL),
то это легально.


-- 
ldv

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Dmitry V. Levin]

On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
> Добрый день!
> 
> Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> https://www.gnu.org/licenses/license-list.html#OpenSSL

А если OpenSSL является системной библиотекой?


-- 
ldv

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Dmitry V. Levin]

Hi,

On Sun, Apr 04, 2021 at 02:40:00PM +0200, Konstantin Lepikhov wrote:
> Hi Andrey!
> 
> On 04/04/2021, at 03:04:23 PM you wrote:
> 
> > Добрый день!
> > 
> > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > https://www.gnu.org/licenses/license-list.html#OpenSSL
> ..
> We recommend using GNUTLS instead of OpenSSL in software you write.
> However, there is no reason not to use OpenSSL and applications that work
> with OpenSSL.
> 
> Где тут написано, что будут санкции?

В GPL есть раздел "Termination", в OpenSSL его нет, значит, для неё
действуют правила в зависимости от юрисдикции.

> Incompatible это очень обтекаемое
> слово, особенно с рекламой gnutls ниже.

Incompatible означает, что распространение на условиях GPL и OpenSSL
одновременно невозможно, поскольку как минимум одно из требований
одной из этих лицензий будет непременно нарушено.


-- 
ldv

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Andrey Savchenko]

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

On Sun, 4 Apr 2021 15:58:26 +0300 Dmitry V. Levin wrote:
> On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
> > Добрый день!
> > 
> > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > https://www.gnu.org/licenses/license-list.html#OpenSSL
> 
> А если OpenSSL является системной библиотекой?

Тогда можно. Но является ли? На мой взгляд — нет. Вот пояснение
того, что такое "system libraries" из текста GPLv3:

The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form.  A
"Major Component", in this context, means a major essential
component (kernel, window system, and so on) of the specific
operating system (if any) on which the executable work runs, or a
compiler used to produce the work, or an object code interpreter
used to run it.

В нашем случае OpenSSL — всего лишь одна из многочисленных
библиотек для работы с криптографическими алгоритмами
и протоколами. Никаких стандартных программных интерфейсов она тоже
не реализует: у каждой библиотеки SSL своё не совместимое ни с
чем API.

Можно ли считать популярность библиотеки критерием её системности?
Я думаю, что нет.

Best regards,
Andrew Savchenko

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

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Alexey V. Vissarionov]

On 2021-04-04 15:53:37 +0300, Andrey Savchenko wrote:

 >>> Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
 >>> https://www.gnu.org/licenses/license-list.html#OpenSSL
 >> We recommend using GNUTLS instead of OpenSSL in software you write.
 >> However, there is no reason not to use OpenSSL and applications
 >> that work with OpenSSL.
 > Вы не тот текст процитировали, следовало:
 > The license of OpenSSL is a conjunction of two licenses, one called
 > "OpenSSL License" and the other being the license of SSLeay. You
 > must follow both. The combination results in a copyleft free
 > software license that is incompatible with the GNU GPL. It also has
 > an advertising clause like the original BSD license and the Apache
 > 1 license.
 > Лицензия OpenSSL содержит дополнительные ограничения на
 > распространение кода, что не допустимо согласно GPL.

Значит, на какое-то из требований нужно положить болт. Вот такой:

<<================================================================>>

Это, разумеется, шаг резьбы :-)

 >>> Могут быть и другие пакеты с такой же проблемой, поэтому всё,
 >>> где есть GPL и линковка с OpenSSL, нужно тщательно изучить
 >>> соответствующим мейнтенерам.
 >> Мне кажется, проблемой должны заниматься юристы, а не
 >> мантейнеры.
 > Вы предлагаете игнорировать нарушение GPL в репозитории?

Единственный риск, который это может создать - репутационный, да и
тот (насколько я вкурил ГК РФ) невелик. Особенно если "нарушать" не
GPL, а дополнительные ограничения от OpenSSL.

 > С таким аргументом, как у Вас, можно помещать в репозиторий
 > любые пакеты под любыми лицензиями,

А что мешает?

 > даже проприетарные бинарные блобы,

Бывает и такое. Не от хорошей жизни, но бывает.

 > а на любые вопросы отправлять к юристам.
 > Так что прекращайте этот детский сад, проблема серьёзная.

Серьезная проблема - это, например, зависимости от libsystemd.
А несовместимость лицензий - забота прежде всего авторов оных.

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

Да и хрен с ними. Пусть авторы лицензий GPL и OpenSSL сами между
собой договариваются, а "нам не шашечки, нам ехать".


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

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Andrey Savchenko]

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

On Sun, 4 Apr 2021 15:56:06 +0300 Dmitry V. Levin wrote:
> On Sun, Apr 04, 2021 at 03:51:19PM +0300, Vladimir D. Seleznev wrote:
> > On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
> > > Добрый день!
> > > 
> > > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > > https://www.gnu.org/licenses/license-list.html#OpenSSL
> > > 
> > > [skip]
> > > 
> > > В тоже время, наш ffmpeg-4.3.2 собран с --enable-gpl и одновременно
> > > слинкован с openssl:
> > > $ ldd ffmpeg  | grep libcrypt
> > >         libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f80fb474000)
> > 
> > Не подтверждаю:
> > 
> > 	$ objdump -x /usr/bin/ffmpeg /usr/lib64/libav* /usr/lib64/libpostproc* /usr/lib64/libsw* |sed -e '/NEEDED/!d' -e '/libssl/!d'
> > 	$ ldd /usr/lib64/libavformat.so.58 |grep libssl
> > 	        libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fe86074d000)
> > 	$ $ objdump -x /usr/lib64/libavformat.so.58 |sed -e '/NEEDED/!d' -e '/libssl/!d'
> > 
> > Получается, кто-то, с кем слинкован libavformat, слинкован с OpenSSL.
> > Вопрос: допустимо ли такое связывание лицензиями OpenSSL и GPL?
> 
> Если этот кто-то распространяется на условиях, так или иначе легализующих
> линковку с openssl (например, под лицензией, совместимой с GPL и OpenSSL),
> то это легально.

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

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

В общем, это некая серая зона. Но на практике те же драйвера nVidia
именно так и обходят GPL ядра: через прослойку, которая с одной
стороны GPL, а с другой разрешает использование проприетарной
библиотеки.

Best regards,
Andrew Savchenko

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

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Anton Farygin]

On 04.04.2021 15:56, Dmitry V. Levin wrote:
> On Sun, Apr 04, 2021 at 03:51:19PM +0300, Vladimir D. Seleznev wrote:
>> On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
>>> Добрый день!
>>>
>>> Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
>>> https://www.gnu.org/licenses/license-list.html#OpenSSL
>>>
>>> [skip]
>>>
>>> В тоже время, наш ffmpeg-4.3.2 собран с --enable-gpl и одновременно
>>> слинкован с openssl:
>>> $ ldd ffmpeg  | grep libcrypt
>>>          libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f80fb474000)
>> Не подтверждаю:
>>
>> 	$ objdump -x /usr/bin/ffmpeg /usr/lib64/libav* /usr/lib64/libpostproc* /usr/lib64/libsw* |sed -e '/NEEDED/!d' -e '/libssl/!d'
>> 	$ ldd /usr/lib64/libavformat.so.58 |grep libssl
>> 	        libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fe86074d000)
>> 	$ $ objdump -x /usr/lib64/libavformat.so.58 |sed -e '/NEEDED/!d' -e '/libssl/!d'
>>
>> Получается, кто-то, с кем слинкован libavformat, слинкован с OpenSSL.
>> Вопрос: допустимо ли такое связывание лицензиями OpenSSL и GPL?
> Если этот кто-то распространяется на условиях, так или иначе легализующих
> линковку с openssl (например, под лицензией, совместимой с GPL и OpenSSL),
> то это легально.
>
>
Ну в данном случае это rabbitmq, который под MIT.

Не выглядит как нарушение лицензии как в упаковке ffmpeg, так и в 
упаковке rabbitmq

Ну а про необходимость rabbitmq в ffmpeg знает точно Володя Селезнев.


commit 6a91f3d862c297dfa27f3384224c9cd1846086bd (tag: 
gb-sisyphus-task255225.100, tag: 4.3.1-alt2)
Author: Vladimir D. Seleznev <vseleznv@altlinux.org>
Date:   Wed Jul 22 02:17:48 2020 +0300

     2:4.3.1-alt2

     - Built with support of:
       + chromaprint;
       + frei0r plugins;
       + liblensfun;
       + librabbitmq;
       + libxml2;
       + sdl2;
       + vulkan.

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Dmitry V. Levin]

On Sun, Apr 04, 2021 at 04:35:37PM +0300, Andrey Savchenko wrote:
> On Sun, 4 Apr 2021 15:58:26 +0300 Dmitry V. Levin wrote:
> > On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
> > > Добрый день!
> > > 
> > > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > > https://www.gnu.org/licenses/license-list.html#OpenSSL
> > 
> > А если OpenSSL является системной библиотекой?
> 
> Тогда можно. Но является ли? На мой взгляд — нет. Вот пояснение
> того, что такое "system libraries" из текста GPLv3:
> 
> The "System Libraries" of an executable work include anything, other
> than the work as a whole, that (a) is included in the normal form of
> packaging a Major Component, but which is not part of that Major
> Component, and (b) serves only to enable use of the work with that
> Major Component, or to implement a Standard Interface for which an
> implementation is available to the public in source code form.  A
> "Major Component", in this context, means a major essential
> component (kernel, window system, and so on) of the specific
> operating system (if any) on which the executable work runs, or a
> compiler used to produce the work, or an object code interpreter
> used to run it.
> 
> В нашем случае OpenSSL — всего лишь одна из многочисленных
> библиотек для работы с криптографическими алгоритмами
> и протоколами. Никаких стандартных программных интерфейсов она тоже
> не реализует: у каждой библиотеки SSL своё не совместимое ни с
> чем API.
> 
> Можно ли считать популярность библиотеки критерием её системности?
> Я думаю, что нет.

Там же написано, что
A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.

Можно ли рассматривать OpenSSL в качестве библиотеки, widely used among
developers working на языке C?

В моём понимании библиотека является системной, если без неё система
превращается в тыкву.  Есть ли у нас хоть один дистрибутив, хоть один
опубликованный образ контейнера без libcrypto?  В базовую сборочную среду
libcrypto не входит, дисквалифицирует ли это libcrypto как системную
библиотеку?


-- 
ldv

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Alexey Gladkov]

On Sun, Apr 04, 2021 at 05:13:43PM +0300, Dmitry V. Levin wrote:
> On Sun, Apr 04, 2021 at 04:35:37PM +0300, Andrey Savchenko wrote:
> > On Sun, 4 Apr 2021 15:58:26 +0300 Dmitry V. Levin wrote:
> > > On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
> > > > Добрый день!
> > > > 
> > > > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > > > https://www.gnu.org/licenses/license-list.html#OpenSSL
> > > 
> > > А если OpenSSL является системной библиотекой?
> > 
> > Тогда можно. Но является ли? На мой взгляд — нет. Вот пояснение
> > того, что такое "system libraries" из текста GPLv3:
> > 
> > The "System Libraries" of an executable work include anything, other
> > than the work as a whole, that (a) is included in the normal form of
> > packaging a Major Component, but which is not part of that Major
> > Component, and (b) serves only to enable use of the work with that
> > Major Component, or to implement a Standard Interface for which an
> > implementation is available to the public in source code form.  A
> > "Major Component", in this context, means a major essential
> > component (kernel, window system, and so on) of the specific
> > operating system (if any) on which the executable work runs, or a
> > compiler used to produce the work, or an object code interpreter
> > used to run it.
> > 
> > В нашем случае OpenSSL — всего лишь одна из многочисленных
> > библиотек для работы с криптографическими алгоритмами
> > и протоколами. Никаких стандартных программных интерфейсов она тоже
> > не реализует: у каждой библиотеки SSL своё не совместимое ни с
> > чем API.
> > 
> > Можно ли считать популярность библиотеки критерием её системности?
> > Я думаю, что нет.
> 
> Там же написано, что
> A "Standard Interface" means an interface that either is an official
> standard defined by a recognized standards body, or, in the case of
> interfaces specified for a particular programming language, one that
> is widely used among developers working in that language.
> 
> Можно ли рассматривать OpenSSL в качестве библиотеки, widely used among
> developers working на языке C?
> 
> В моём понимании библиотека является системной, если без неё система
> превращается в тыкву.  Есть ли у нас хоть один дистрибутив, хоть один
> опубликованный образ контейнера без libcrypto?  В базовую сборочную среду
> libcrypto не входит, дисквалифицирует ли это libcrypto как системную
> библиотеку?

Мне кажется, да.

А всякие LibreSSL и BoringSSL имеют такие же проблемы с совместимостью с
GPL ?

-- 
Rgrds, legion

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Andrey Savchenko]

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

On Sun, 4 Apr 2021 17:13:43 +0300 Dmitry V. Levin wrote:
> On Sun, Apr 04, 2021 at 04:35:37PM +0300, Andrey Savchenko wrote:
> > On Sun, 4 Apr 2021 15:58:26 +0300 Dmitry V. Levin wrote:
> > > On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
> > > > Добрый день!
> > > > 
> > > > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > > > https://www.gnu.org/licenses/license-list.html#OpenSSL
> > > 
> > > А если OpenSSL является системной библиотекой?
> > 
> > Тогда можно. Но является ли? На мой взгляд — нет. Вот пояснение
> > того, что такое "system libraries" из текста GPLv3:
> > 
> > The "System Libraries" of an executable work include anything, other
> > than the work as a whole, that (a) is included in the normal form of
> > packaging a Major Component, but which is not part of that Major
> > Component, and (b) serves only to enable use of the work with that
> > Major Component, or to implement a Standard Interface for which an
> > implementation is available to the public in source code form.  A
> > "Major Component", in this context, means a major essential
> > component (kernel, window system, and so on) of the specific
> > operating system (if any) on which the executable work runs, or a
> > compiler used to produce the work, or an object code interpreter
> > used to run it.
> > 
> > В нашем случае OpenSSL — всего лишь одна из многочисленных
> > библиотек для работы с криптографическими алгоритмами
> > и протоколами. Никаких стандартных программных интерфейсов она тоже
> > не реализует: у каждой библиотеки SSL своё не совместимое ни с
> > чем API.
> > 
> > Можно ли считать популярность библиотеки критерием её системности?
> > Я думаю, что нет.
> 
> Там же написано, что
> A "Standard Interface" means an interface that either is an official
> standard defined by a recognized standards body, or, in the case of
> interfaces specified for a particular programming language, one that
> is widely used among developers working in that language.
> 
> Можно ли рассматривать OpenSSL в качестве библиотеки, widely used among
> developers working на языке C?

По-моему, там другое имелось ввиду:
> interfaces specified for a particular programming language

Т.е. стандартные для языка интерфейсы, если их нет в официальном
стандарте, но на практике широко используется как часть стандарта
языка: например, strlcpy.

> В моём понимании библиотека является системной, если без неё система
> превращается в тыкву.  Есть ли у нас хоть один дистрибутив, хоть один
> опубликованный образ контейнера без libcrypto? В базовую сборочную среду
> libcrypto не входит, дисквалифицирует ли это libcrypto как системную
> библиотеку?

Думаю, что да. Волне можно сделать контейнер без криптографии или
сети для специфических задач; чем, в общем-то, сборочная среда
является.

У разных дистрибутивов здесь разное мнение, кстати:
- Fedora сказала, что OpenSSL — системная библиотека и их ничего не
волнует:
https://fedoraproject.org/wiki/Licensing:FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F
- В Gentoo явно запрещается OpenSSL + GPL для бинарно
распространяемых сборок:
https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/ffmpeg/ffmpeg-4.3.2.ebuild#n320
Мало того, лицензии GPL with OpenSSL exception явно выносятся как
отдельные и используются в пакетах по необходимости:
https://gitweb.gentoo.org/repo/gentoo.git/tree/licenses/GPL-2+-with-openssl-exception
https://gitweb.gentoo.org/repo/gentoo.git/tree/licenses/GPL-3-with-openssl-exception

На мой взгляд, весомым аргументом является то, что апстримы,
разрабатывающие GPL код и использующие OpenSSL, обычно явно
добавляют OpenSSL exception в свою лицензию, таким образом не
полагаясь на возможный системный статус библиотеки.

Best regards,
Andrew Savchenko

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

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Andrey Savchenko]

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

On Sun, 4 Apr 2021 16:20:25 +0200 Alexey Gladkov wrote:
> On Sun, Apr 04, 2021 at 05:13:43PM +0300, Dmitry V. Levin wrote:
> > On Sun, Apr 04, 2021 at 04:35:37PM +0300, Andrey Savchenko wrote:
> > > On Sun, 4 Apr 2021 15:58:26 +0300 Dmitry V. Levin wrote:
> > > > On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
> > > > > Добрый день!
> > > > > 
> > > > > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > > > > https://www.gnu.org/licenses/license-list.html#OpenSSL
> > > > 
> > > > А если OpenSSL является системной библиотекой?
> > > 
> > > Тогда можно. Но является ли? На мой взгляд — нет. Вот пояснение
> > > того, что такое "system libraries" из текста GPLv3:
> > > 
> > > The "System Libraries" of an executable work include anything, other
> > > than the work as a whole, that (a) is included in the normal form of
> > > packaging a Major Component, but which is not part of that Major
> > > Component, and (b) serves only to enable use of the work with that
> > > Major Component, or to implement a Standard Interface for which an
> > > implementation is available to the public in source code form.  A
> > > "Major Component", in this context, means a major essential
> > > component (kernel, window system, and so on) of the specific
> > > operating system (if any) on which the executable work runs, or a
> > > compiler used to produce the work, or an object code interpreter
> > > used to run it.
> > > 
> > > В нашем случае OpenSSL — всего лишь одна из многочисленных
> > > библиотек для работы с криптографическими алгоритмами
> > > и протоколами. Никаких стандартных программных интерфейсов она тоже
> > > не реализует: у каждой библиотеки SSL своё не совместимое ни с
> > > чем API.
> > > 
> > > Можно ли считать популярность библиотеки критерием её системности?
> > > Я думаю, что нет.
> > 
> > Там же написано, что
> > A "Standard Interface" means an interface that either is an official
> > standard defined by a recognized standards body, or, in the case of
> > interfaces specified for a particular programming language, one that
> > is widely used among developers working in that language.
> > 
> > Можно ли рассматривать OpenSSL в качестве библиотеки, widely used among
> > developers working на языке C?
> > 
> > В моём понимании библиотека является системной, если без неё система
> > превращается в тыкву.  Есть ли у нас хоть один дистрибутив, хоть один
> > опубликованный образ контейнера без libcrypto?  В базовую сборочную среду
> > libcrypto не входит, дисквалифицирует ли это libcrypto как системную
> > библиотеку?
> 
> Мне кажется, да.
> 
> А всякие LibreSSL и BoringSSL имеют такие же проблемы с совместимостью с
> GPL ?

Да, т.к. оба форки OpenSSL и идут под той же лицензией для старого
кода и + ISC на все новые модификации. 

Best regards,
Andrew Savchenko

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

[devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Vladimir D. Seleznev]

On Sun, Apr 04, 2021 at 04:56:32PM +0300, Anton Farygin wrote:
> On 04.04.2021 15:56, Dmitry V. Levin wrote:
> > On Sun, Apr 04, 2021 at 03:51:19PM +0300, Vladimir D. Seleznev wrote:
> >> On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
> >>> Добрый день!
> >>>
> >>> Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> >>> https://www.gnu.org/licenses/license-list.html#OpenSSL
> >>>
> >>> [skip]
> >>>
> >>> В тоже время, наш ffmpeg-4.3.2 собран с --enable-gpl и одновременно
> >>> слинкован с openssl:
> >>> $ ldd ffmpeg  | grep libcrypt
> >>>          libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f80fb474000)
> >> Не подтверждаю:
> >>
> >> 	$ objdump -x /usr/bin/ffmpeg /usr/lib64/libav* /usr/lib64/libpostproc* /usr/lib64/libsw* |sed -e '/NEEDED/!d' -e '/libssl/!d'
> >> 	$ ldd /usr/lib64/libavformat.so.58 |grep libssl
> >> 	        libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fe86074d000)
> >> 	$ $ objdump -x /usr/lib64/libavformat.so.58 |sed -e '/NEEDED/!d' -e '/libssl/!d'
> >>
> >> Получается, кто-то, с кем слинкован libavformat, слинкован с OpenSSL.
> >> Вопрос: допустимо ли такое связывание лицензиями OpenSSL и GPL?
> > Если этот кто-то распространяется на условиях, так или иначе легализующих
> > линковку с openssl (например, под лицензией, совместимой с GPL и OpenSSL),
> > то это легально.
> >
> >
> Ну в данном случае это rabbitmq, который под MIT.
> 
> Не выглядит как нарушение лицензии как в упаковке ffmpeg, так и в 
> упаковке rabbitmq
> 
> Ну а про необходимость rabbitmq в ffmpeg знает точно Володя Селезнев.

Необходимость в rabbitmq в поддержке сопутствующего протокола. Возможно,
но в подавляющем большинстве случаев не нужен, и его можно выключить.

Я думаю, не сделать ли более компактную сбоку ffmpeg с его библиотеками,
и отдельно статикой собрать, скажем, ffmpeg-max, с включёнными по
максимуму возможностями?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Anton Farygin]

On 04.04.2021 19:18, Vladimir D. Seleznev wrote:
> On Sun, Apr 04, 2021 at 04:56:32PM +0300, Anton Farygin wrote:
>> On 04.04.2021 15:56, Dmitry V. Levin wrote:
>>> On Sun, Apr 04, 2021 at 03:51:19PM +0300, Vladimir D. Seleznev wrote:
>>>> On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
>>>>> Добрый день!
>>>>>
>>>>> Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
>>>>> https://www.gnu.org/licenses/license-list.html#OpenSSL
>>>>>
>>>>> [skip]
>>>>>
>>>>> В тоже время, наш ffmpeg-4.3.2 собран с --enable-gpl и одновременно
>>>>> слинкован с openssl:
>>>>> $ ldd ffmpeg  | grep libcrypt
>>>>>           libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f80fb474000)
>>>> Не подтверждаю:
>>>>
>>>> 	$ objdump -x /usr/bin/ffmpeg /usr/lib64/libav* /usr/lib64/libpostproc* /usr/lib64/libsw* |sed -e '/NEEDED/!d' -e '/libssl/!d'
>>>> 	$ ldd /usr/lib64/libavformat.so.58 |grep libssl
>>>> 	        libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fe86074d000)
>>>> 	$ $ objdump -x /usr/lib64/libavformat.so.58 |sed -e '/NEEDED/!d' -e '/libssl/!d'
>>>>
>>>> Получается, кто-то, с кем слинкован libavformat, слинкован с OpenSSL.
>>>> Вопрос: допустимо ли такое связывание лицензиями OpenSSL и GPL?
>>> Если этот кто-то распространяется на условиях, так или иначе легализующих
>>> линковку с openssl (например, под лицензией, совместимой с GPL и OpenSSL),
>>> то это легально.
>>>
>>>
>> Ну в данном случае это rabbitmq, который под MIT.
>>
>> Не выглядит как нарушение лицензии как в упаковке ffmpeg, так и в
>> упаковке rabbitmq
>>
>> Ну а про необходимость rabbitmq в ffmpeg знает точно Володя Селезнев.
> Необходимость в rabbitmq в поддержке сопутствующего протокола. Возможно,
> но в подавляющем большинстве случаев не нужен, и его можно выключить.
>
> Я думаю, не сделать ли более компактную сбоку ffmpeg с его библиотеками,
> и отдельно статикой собрать, скажем, ffmpeg-max, с включёнными по
> максимуму возможностями?
>
Мне не очень нравится идея держать в репозитории две сборки библиотек 
ffmpeg.

Re: [devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Vladimir D. Seleznev]

On Sun, Apr 04, 2021 at 08:03:03PM +0300, Anton Farygin wrote:
> On 04.04.2021 19:18, Vladimir D. Seleznev wrote:
> > On Sun, Apr 04, 2021 at 04:56:32PM +0300, Anton Farygin wrote:
> >> On 04.04.2021 15:56, Dmitry V. Levin wrote:
> >>> On Sun, Apr 04, 2021 at 03:51:19PM +0300, Vladimir D. Seleznev wrote:
> >>>> On Sun, Apr 04, 2021 at 03:04:23PM +0300, Andrey Savchenko wrote:
> >>>>> Добрый день!
> >>>>>
> >>>>> Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> >>>>> https://www.gnu.org/licenses/license-list.html#OpenSSL
> >>>>>
> >>>>> [skip]
> >>>>>
> >>>>> В тоже время, наш ffmpeg-4.3.2 собран с --enable-gpl и одновременно
> >>>>> слинкован с openssl:
> >>>>> $ ldd ffmpeg  | grep libcrypt
> >>>>>           libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f80fb474000)
> >>>> Не подтверждаю:
> >>>>
> >>>> 	$ objdump -x /usr/bin/ffmpeg /usr/lib64/libav* /usr/lib64/libpostproc* /usr/lib64/libsw* |sed -e '/NEEDED/!d' -e '/libssl/!d'
> >>>> 	$ ldd /usr/lib64/libavformat.so.58 |grep libssl
> >>>> 	        libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fe86074d000)
> >>>> 	$ $ objdump -x /usr/lib64/libavformat.so.58 |sed -e '/NEEDED/!d' -e '/libssl/!d'
> >>>>
> >>>> Получается, кто-то, с кем слинкован libavformat, слинкован с OpenSSL.
> >>>> Вопрос: допустимо ли такое связывание лицензиями OpenSSL и GPL?
> >>> Если этот кто-то распространяется на условиях, так или иначе легализующих
> >>> линковку с openssl (например, под лицензией, совместимой с GPL и OpenSSL),
> >>> то это легально.
> >>>
> >>>
> >> Ну в данном случае это rabbitmq, который под MIT.
> >>
> >> Не выглядит как нарушение лицензии как в упаковке ffmpeg, так и в
> >> упаковке rabbitmq
> >>
> >> Ну а про необходимость rabbitmq в ffmpeg знает точно Володя Селезнев.
> > Необходимость в rabbitmq в поддержке сопутствующего протокола. Возможно,
> > но в подавляющем большинстве случаев не нужен, и его можно выключить.
> >
> > Я думаю, не сделать ли более компактную сбоку ffmpeg с его библиотеками,
> > и отдельно статикой собрать, скажем, ffmpeg-max, с включёнными по
> > максимуму возможностями?
> >
> Мне не очень нравится идея держать в репозитории две сборки библиотек 
> ffmpeg.

Я же написал, что одна сборка библиотек будет.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Alexey V. Vissarionov]

On 2021-04-04 19:18:47 +0300, Vladimir D. Seleznev wrote:

 >> Ну в данном случае это rabbitmq, который под MIT.
 >> Не выглядит как нарушение лицензии как в упаковке ffmpeg, так
 >> и в упаковке rabbitmq Ну а про необходимость rabbitmq в ffmpeg
 >> знает точно Володя Селезнев.
 > Необходимость в rabbitmq в поддержке сопутствующего протокола.
 > Возможно, но в подавляющем большинстве случаев не нужен, и его
 > можно выключить.

И даже нужно выключить, ибо экзотика, а тащит кучу всего.

 > Я думаю, не сделать ли более компактную сбоку ffmpeg с его
 > библиотеками, и отдельно статикой собрать, скажем, ffmpeg-max,
 > с включёнными по максимуму возможностями?

Если ffmpeg-max будет собран монолитным пакетом без -devel, это может
оказаться хорошим решением.


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

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Konstantin Lepikhov]

Hi Andrey!

On 04/04/2021, at 03:53:37 PM you wrote:

> On Sun, 4 Apr 2021 14:40:00 +0200 Konstantin Lepikhov wrote:
> > Hi Andrey!
> > 
> > On 04/04/2021, at 03:04:23 PM you wrote:
> > 
> > > Добрый день!
> > > 
> > > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > > https://www.gnu.org/licenses/license-list.html#OpenSSL
> > ..
> > We recommend using GNUTLS instead of OpenSSL in software you write.
> > However, there is no reason not to use OpenSSL and applications that work
> > with OpenSSL.
> > 
> > Где тут написано, что будут санкции? Incompatible это очень обтекаемое
> > слово, особенно с рекламой gnutls ниже.
> 
> Вы не тот текст процитировали, следовало:
> 
> The license of OpenSSL is a conjunction of two licenses, one called
> “OpenSSL License” and the other being the license of SSLeay. You
> must follow both. The combination results in a copyleft free
> software license that is incompatible with the GNU GPL. It also has
> an advertising clause like the original BSD license and the Apache
> 1 license.
> 
> Лицензия OpenSSL содержит дополнительные ограничения на
> распространение кода, что не допустимо согласно GPL.
Я не юрист, а вы?

> 
> > <skip>
> > > Могут быть и другие пакеты с такой же проблемой, поэтому всё,
> > > где есть GPL и линковка с OpenSSL, нужно тщательно изучить
> > > соответствующим мейнтенерам.
> > Мне кажется, проблемой должны заниматься юристы, а не мантейнеры.
> 
> Вы предлагаете игнорировать нарушение GPL в репозитории? 
см. выше. Без надлежащих коментариев юриста этот разговор бесполезен.

-- 
WBR et al.

Re: [devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Anton Farygin]

On 04.04.2021 20:18, Vladimir D. Seleznev wrote:
>>>> Ну в данном случае это rabbitmq, который под MIT.
>>>>
>>>> Не выглядит как нарушение лицензии как в упаковке ffmpeg, так и в
>>>> упаковке rabbitmq
>>>>
>>>> Ну а про необходимость rabbitmq в ffmpeg знает точно Володя Селезнев.
>>> Необходимость в rabbitmq в поддержке сопутствующего протокола. Возможно,
>>> но в подавляющем большинстве случаев не нужен, и его можно выключить.
>>>
>>> Я думаю, не сделать ли более компактную сбоку ffmpeg с его библиотеками,
>>> и отдельно статикой собрать, скажем, ffmpeg-max, с включёнными по
>>> максимуму возможностями?
>>>
>> Мне не очень нравится идея держать в репозитории две сборки библиотек
>> ffmpeg.
> Я же написал, что одна сборка библиотек будет.

А второе что будет ?

Re: [devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Vladimir D. Seleznev]

On Sun, Apr 04, 2021 at 09:11:43PM +0300, Anton Farygin wrote:
> On 04.04.2021 20:18, Vladimir D. Seleznev wrote:
> >>>> Ну в данном случае это rabbitmq, который под MIT.
> >>>>
> >>>> Не выглядит как нарушение лицензии как в упаковке ffmpeg, так и в
> >>>> упаковке rabbitmq
> >>>>
> >>>> Ну а про необходимость rabbitmq в ffmpeg знает точно Володя Селезнев.
> >>> Необходимость в rabbitmq в поддержке сопутствующего протокола. Возможно,
> >>> но в подавляющем большинстве случаев не нужен, и его можно выключить.
> >>>
> >>> Я думаю, не сделать ли более компактную сбоку ffmpeg с его библиотеками,
> >>> и отдельно статикой собрать, скажем, ffmpeg-max, с включёнными по
> >>> максимуму возможностями?
> >>>
> >> Мне не очень нравится идея держать в репозитории две сборки библиотек
> >> ffmpeg.
> > Я же написал, что одна сборка библиотек будет.
> 
> А второе что будет ?

Отдельно без разделяемых библиотек собранные ffmpeg, ffplay, etc с
по максимуму включёнными возможностями.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Anton Farygin]

On 04.04.2021 21:22, Vladimir D. Seleznev wrote:
> On Sun, Apr 04, 2021 at 09:11:43PM +0300, Anton Farygin wrote:
>> On 04.04.2021 20:18, Vladimir D. Seleznev wrote:
>>>>>> Ну в данном случае это rabbitmq, который под MIT.
>>>>>>
>>>>>> Не выглядит как нарушение лицензии как в упаковке ffmpeg, так и в
>>>>>> упаковке rabbitmq
>>>>>>
>>>>>> Ну а про необходимость rabbitmq в ffmpeg знает точно Володя Селезнев.
>>>>> Необходимость в rabbitmq в поддержке сопутствующего протокола. Возможно,
>>>>> но в подавляющем большинстве случаев не нужен, и его можно выключить.
>>>>>
>>>>> Я думаю, не сделать ли более компактную сбоку ffmpeg с его библиотеками,
>>>>> и отдельно статикой собрать, скажем, ffmpeg-max, с включёнными по
>>>>> максимуму возможностями?
>>>>>
>>>> Мне не очень нравится идея держать в репозитории две сборки библиотек
>>>> ffmpeg.
>>> Я же написал, что одна сборка библиотек будет.
>> А второе что будет ?
> Отдельно без разделяемых библиотек собранные ffmpeg, ffplay, etc с
> по максимуму включёнными возможностями.
>
А какой сценарий их использования ?

Вся прелесть ffmpeg - в библиотеках.

Ну а у тех приложений, кто использует ffmpeg через утилиты, как правило, 
захардкожены пути и названия.

Re: [devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Vladimir D. Seleznev]

On Sun, Apr 04, 2021 at 09:25:57PM +0300, Anton Farygin wrote:
> On 04.04.2021 21:22, Vladimir D. Seleznev wrote:
> > On Sun, Apr 04, 2021 at 09:11:43PM +0300, Anton Farygin wrote:
> >> On 04.04.2021 20:18, Vladimir D. Seleznev wrote:
> >>>>>> Ну в данном случае это rabbitmq, который под MIT.
> >>>>>>
> >>>>>> Не выглядит как нарушение лицензии как в упаковке ffmpeg, так и в
> >>>>>> упаковке rabbitmq
> >>>>>>
> >>>>>> Ну а про необходимость rabbitmq в ffmpeg знает точно Володя Селезнев.
> >>>>> Необходимость в rabbitmq в поддержке сопутствующего протокола. Возможно,
> >>>>> но в подавляющем большинстве случаев не нужен, и его можно выключить.
> >>>>>
> >>>>> Я думаю, не сделать ли более компактную сбоку ffmpeg с его библиотеками,
> >>>>> и отдельно статикой собрать, скажем, ffmpeg-max, с включёнными по
> >>>>> максимуму возможностями?
> >>>>>
> >>>> Мне не очень нравится идея держать в репозитории две сборки библиотек
> >>>> ffmpeg.
> >>> Я же написал, что одна сборка библиотек будет.
> >> А второе что будет ?
> > Отдельно без разделяемых библиотек собранные ffmpeg, ffplay, etc с
> > по максимуму включёнными возможностями.
> >
> А какой сценарий их использования ?
> 
> Вся прелесть ffmpeg - в библиотеках.
> 
> Ну а у тех приложений, кто использует ffmpeg через утилиты, как правило, 
> захардкожены пути и названия.

Вот я, например, пользователь ffmpeg. И для утилит можно, например,
сделать альтернативы.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Alexey V. Vissarionov]

On 2021-04-04 21:38:34 +0300, Vladimir D. Seleznev wrote:

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

Не надо их делать! Пусть будет нормальный конфликт.


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

Re: [devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Anton Farygin]

On 04.04.2021 22:06, Alexey V. Vissarionov wrote:
> On 2021-04-04 21:38:34 +0300, Vladimir D. Seleznev wrote:
>
>   >> Вся прелесть ffmpeg - в библиотеках.
>   >> Ну а у тех приложений, кто использует ffmpeg через утилиты, как
>   >> правило, захардкожены пути и названия.
>   > Вот я, например, пользователь ffmpeg. И для утилит можно, например,
>   > сделать альтернативы.
>
> Не надо их делать! Пусть будет нормальный конфликт.
>
>
и конфликтов не надо делать, т.к. придётся делать provides и это 
приведёт к проблемам.

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Andrey Savchenko]

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

On Sun, 4 Apr 2021 19:57:06 +0200 Konstantin Lepikhov wrote:
> Hi Andrey!
> 
> On 04/04/2021, at 03:53:37 PM you wrote:
> 
> > On Sun, 4 Apr 2021 14:40:00 +0200 Konstantin Lepikhov wrote:
> > > Hi Andrey!
> > > 
> > > On 04/04/2021, at 03:04:23 PM you wrote:
> > > 
> > > > Добрый день!
> > > > 
> > > > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > > > https://www.gnu.org/licenses/license-list.html#OpenSSL
> > > ..
> > > We recommend using GNUTLS instead of OpenSSL in software you write.
> > > However, there is no reason not to use OpenSSL and applications that work
> > > with OpenSSL.
> > > 
> > > Где тут написано, что будут санкции? Incompatible это очень обтекаемое
> > > слово, особенно с рекламой gnutls ниже.
> > 
> > Вы не тот текст процитировали, следовало:
> > 
> > The license of OpenSSL is a conjunction of two licenses, one called
> > “OpenSSL License” and the other being the license of SSLeay. You
> > must follow both. The combination results in a copyleft free
> > software license that is incompatible with the GNU GPL. It also has
> > an advertising clause like the original BSD license and the Apache
> > 1 license.
> > 
> > Лицензия OpenSSL содержит дополнительные ограничения на
> > распространение кода, что не допустимо согласно GPL.
> Я не юрист, а вы?

Я даю консультации юристам по вопросам лицензий на ПО.

> > > <skip>
> > > > Могут быть и другие пакеты с такой же проблемой, поэтому всё,
> > > > где есть GPL и линковка с OpenSSL, нужно тщательно изучить
> > > > соответствующим мейнтенерам.
> > > Мне кажется, проблемой должны заниматься юристы, а не мантейнеры.
> > 
> > Вы предлагаете игнорировать нарушение GPL в репозитории? 
> см. выше. Без надлежащих коментариев юриста этот разговор бесполезен.

Не знание законов или отсутствие «надлежащих комментариев юриста»
не освобождает Вас от ответственности.

Best regards,
Andrew Savchenko

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

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Vladimir D. Seleznev]

On Mon, Apr 05, 2021 at 12:55:18AM +0300, Andrey Savchenko wrote:
> On Sun, 4 Apr 2021 19:57:06 +0200 Konstantin Lepikhov wrote:
> > Hi Andrey!
> > 
> > On 04/04/2021, at 03:53:37 PM you wrote:
> > 
> > > On Sun, 4 Apr 2021 14:40:00 +0200 Konstantin Lepikhov wrote:
> > > > Hi Andrey!
> > > > 
> > > > On 04/04/2021, at 03:04:23 PM you wrote:
> > > > 
> > > > > Добрый день!
> > > > > 
> > > > > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > > > > https://www.gnu.org/licenses/license-list.html#OpenSSL
> > > > ..
> > > > We recommend using GNUTLS instead of OpenSSL in software you write.
> > > > However, there is no reason not to use OpenSSL and applications that work
> > > > with OpenSSL.
> > > > 
> > > > Где тут написано, что будут санкции? Incompatible это очень обтекаемое
> > > > слово, особенно с рекламой gnutls ниже.
> > > 
> > > Вы не тот текст процитировали, следовало:
> > > 
> > > The license of OpenSSL is a conjunction of two licenses, one called
> > > “OpenSSL License” and the other being the license of SSLeay. You
> > > must follow both. The combination results in a copyleft free
> > > software license that is incompatible with the GNU GPL. It also has
> > > an advertising clause like the original BSD license and the Apache
> > > 1 license.
> > > 
> > > Лицензия OpenSSL содержит дополнительные ограничения на
> > > распространение кода, что не допустимо согласно GPL.
> > Я не юрист, а вы?
> 
> Я даю консультации юристам по вопросам лицензий на ПО.
> 
> > > > <skip>
> > > > > Могут быть и другие пакеты с такой же проблемой, поэтому всё,
> > > > > где есть GPL и линковка с OpenSSL, нужно тщательно изучить
> > > > > соответствующим мейнтенерам.
> > > > Мне кажется, проблемой должны заниматься юристы, а не мантейнеры.
> > > 
> > > Вы предлагаете игнорировать нарушение GPL в репозитории? 
> > см. выше. Без надлежащих коментариев юриста этот разговор бесполезен.
> 
> Не знание законов или отсутствие «надлежащих комментариев юриста»
> не освобождает Вас от ответственности.

Это ли не серая зона? Какую ответственность несёт мейнтейнер,
слинковавший программное обеспечение под несовместимыми лицензиями?
Не более ли опасно это для коммерческой фирмы, которая продаёт это
программное обеспечение за деньги.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Aleksey Novodvorsky]

пн, 5 апр. 2021 г. в 01:03, Vladimir D. Seleznev <vseleznv@altlinux.org>:
>
> On Mon, Apr 05, 2021 at 12:55:18AM +0300, Andrey Savchenko wrote:
> > On Sun, 4 Apr 2021 19:57:06 +0200 Konstantin Lepikhov wrote:
> > > Hi Andrey!
> > >
> > > On 04/04/2021, at 03:53:37 PM you wrote:
> > >
> > > > On Sun, 4 Apr 2021 14:40:00 +0200 Konstantin Lepikhov wrote:
> > > > > Hi Andrey!
> > > > >
> > > > > On 04/04/2021, at 03:04:23 PM you wrote:
> > > > >
> > > > > > Добрый день!
> > > > > >
> > > > > > Обращаю внимание, что лицензии OpenSSL и GPL(все) не совместимы:
> > > > > > https://www.gnu.org/licenses/license-list.html#OpenSSL
> > > > > ..
> > > > > We recommend using GNUTLS instead of OpenSSL in software you write.
> > > > > However, there is no reason not to use OpenSSL and applications that work
> > > > > with OpenSSL.
> > > > >
> > > > > Где тут написано, что будут санкции? Incompatible это очень обтекаемое
> > > > > слово, особенно с рекламой gnutls ниже.
> > > >
> > > > Вы не тот текст процитировали, следовало:
> > > >
> > > > The license of OpenSSL is a conjunction of two licenses, one called
> > > > “OpenSSL License” and the other being the license of SSLeay. You
> > > > must follow both. The combination results in a copyleft free
> > > > software license that is incompatible with the GNU GPL. It also has
> > > > an advertising clause like the original BSD license and the Apache
> > > > 1 license.
> > > >
> > > > Лицензия OpenSSL содержит дополнительные ограничения на
> > > > распространение кода, что не допустимо согласно GPL.
> > > Я не юрист, а вы?
> >
> > Я даю консультации юристам по вопросам лицензий на ПО.
> >
> > > > > <skip>
> > > > > > Могут быть и другие пакеты с такой же проблемой, поэтому всё,
> > > > > > где есть GPL и линковка с OpenSSL, нужно тщательно изучить
> > > > > > соответствующим мейнтенерам.
> > > > > Мне кажется, проблемой должны заниматься юристы, а не мантейнеры.
> > > >
> > > > Вы предлагаете игнорировать нарушение GPL в репозитории?
> > > см. выше. Без надлежащих коментариев юриста этот разговор бесполезен.
> >
> > Не знание законов или отсутствие «надлежащих комментариев юриста»
> > не освобождает Вас от ответственности.
>
> Это ли не серая зона? Какую ответственность несёт мейнтейнер,
> слинковавший программное обеспечение под несовместимыми лицензиями?
> Не более ли опасно это для коммерческой фирмы, которая продаёт это
> программное обеспечение за деньги.

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

Rgrds, Алексей

>
> --
>    WBR,
>    Vladimir D. Seleznev
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Лицензионная проблема в GPL пакетах, линкующихся с OpenSSL

[Andrey Savchenko]

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

On Mon, 5 Apr 2021 01:11:25 +0300 Aleksey Novodvorsky wrote:
> пн, 5 апр. 2021 г. в 01:03, Vladimir D. Seleznev <vseleznv@altlinux.org>:
> >
> > On Mon, Apr 05, 2021 at 12:55:18AM +0300, Andrey Savchenko wrote:
> > > On Sun, 4 Apr 2021 19:57:06 +0200 Konstantin Lepikhov wrote:
[...]
> > > > > > > Могут быть и другие пакеты с такой же проблемой, поэтому всё,
> > > > > > > где есть GPL и линковка с OpenSSL, нужно тщательно изучить
> > > > > > > соответствующим мейнтенерам.
> > > > > > Мне кажется, проблемой должны заниматься юристы, а не мантейнеры.
> > > > >
> > > > > Вы предлагаете игнорировать нарушение GPL в репозитории?
> > > > см. выше. Без надлежащих коментариев юриста этот разговор бесполезен.
> > >
> > > Не знание законов или отсутствие «надлежащих комментариев юриста»
> > > не освобождает Вас от ответственности.
> >
> > Это ли не серая зона? Какую ответственность несёт мейнтейнер,
> > слинковавший программное обеспечение под несовместимыми лицензиями?
> > Не более ли опасно это для коммерческой фирмы, которая продаёт это
> > программное обеспечение за деньги.
> 
> Нет, если речь напрямую о коммерции.
> Опасен репутационный ущерб проекта и, как следствие, фирм его
> использующих. Коммерция здесь затронута косвенно.
> Замечу, что не только Андрей, но и Алексей Смирнов консультирует
> юристов по вопросам  FOSS.
> И мы, конечно, можем их спросить. Но важно четко поставить вопрос в их
> компетенции, а для этого надо разобраться самим и наметить наиболее
> оптимальные для нас пути решения.

Думаю, что прежде всего нам следует устранить проблему неправильного
указания лицензии в ряде пакетов: если у апстрима лицензия GPL*
with OpenSSL exception, то именно так и должно быть указано
в информации о пакете. Для этого не нужна консультация с юристом —
это просто обеспечение корректности информации о пакете.

Для решения этой проблемы в исходном письме я предложил:
1) Добавить openssl-exception в license-exception.
2) Для всех пакетов, использующих GPL и допускающих сборку
с OpenSSL провести ревизию информации о лицензии пакета.

п.2 — это как раз работа мейнтенеров соответствующих пакетов.
Для подавляющего большинства пакетов будет достаточно корректно
указать их лицензию и проблема будет решена.

С оставшимися уже можно предметно разбираться. В исходном письме
я привёл в пример FFmpeg — как известный мне пакет с лицензионными
особенностями — но более детальное изучение вопроса со стороны
Володи показало, что нарушения у нас в репозитории нет. Возможно,
других нарушений и не будет. Но сперва требуется выполнить п.2.

Best regards,
Andrew Savchenko

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

Re: [devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Alexey V. Vissarionov]

On 2021-04-04 22:15:43 +0300, Anton Farygin wrote:

 >>>> Вся прелесть ffmpeg - в библиотеках.
 >>>> Ну а у тех приложений, кто использует ffmpeg через утилиты, как
 >>>> правило, захардкожены пути и названия.
 >>> Вот я, например, пользователь ffmpeg. И для утилит можно, например,
 >>> сделать альтернативы.
 >> Не надо их делать! Пусть будет нормальный конфликт.
 > и конфликтов не надо делать, т.к. придётся делать provides и это
 > приведёт к проблемам.

И даже Provides: не надо - файлового конфликта вполне достаточно.


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

Re: [devel] FFmpeg flavors (Was: Лицензионная проблема в GPL) пакетах, линкующихся с OpenSSL

[Anton Farygin]

On 05.04.2021 05:47, Alexey V. Vissarionov wrote:
> On 2021-04-04 22:15:43 +0300, Anton Farygin wrote:
>
>   >>>> Вся прелесть ffmpeg - в библиотеках.
>   >>>> Ну а у тех приложений, кто использует ffmpeg через утилиты, как
>   >>>> правило, захардкожены пути и названия.
>   >>> Вот я, например, пользователь ffmpeg. И для утилит можно, например,
>   >>> сделать альтернативы.
>   >> Не надо их делать! Пусть будет нормальный конфликт.
>   > и конфликтов не надо делать, т.к. придётся делать provides и это
>   > приведёт к проблемам.
>
> И даже Provides: не надо - файлового конфликта вполне достаточно.
>
>
И правда - Provides для пакетов с файлами в /usr/bin сам сгенерится,