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

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

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

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

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

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

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

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

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

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

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

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

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

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

Best regards,
Andrew Savchenko