[devel] License tag for source packages

[Andrey Savchenko]

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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20200318/78a7c1a0/attachment-0001.bin>