From: Andrey Savchenko <bircoph@altlinux.org> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] License tag for source packages Date: Wed, 18 Mar 2020 01:16:01 +0300 Message-ID: <20200318011601.087b46c0f197bbb1af30d369@altlinux.org> (raw) In-Reply-To: <d7d21d8e-2938-3a45-f91a-32cb107cb02a@gmail.com> [-- 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 --]
next prev parent reply other threads:[~2020-03-17 22:16 UTC|newest] Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-15 16:42 [devel] mysql-workbench-community, License tag Sergey Y. Afonin 2020-03-15 18:43 ` Andrey Savchenko 2020-03-15 19:36 ` Sergey Y. Afonin 2020-03-15 21:58 ` Alexey Gladkov 2020-03-15 22:51 ` Dmitry V. Levin 2020-03-16 5:46 ` Sergey Afonin 2020-03-16 8:10 ` Dmitry V. Levin 2020-03-16 10:52 ` Sergey Afonin 2020-03-16 11:16 ` Alexey Gladkov 2020-03-16 11:37 ` Sergey Afonin 2020-03-16 12:16 ` Sergey Afonin 2020-03-16 12:27 ` Sergey Afonin 2020-03-16 14:40 ` Alexey Gladkov 2020-03-16 22:14 ` Andrey Savchenko 2020-03-16 23:03 ` Alexey Gladkov 2020-03-17 6:24 ` Ivan A. Melnikov 2020-03-17 10:37 ` Alexey Gladkov 2020-03-17 13:31 ` Sergey Afonin 2020-03-17 16:40 ` [devel] License tag for source packages Dmitry V. Levin 2020-03-17 16:56 ` Andrey Savchenko 2020-03-17 20:06 ` Dmitry V. Levin 2020-03-17 20:52 ` Leonid Krivoshein 2020-03-17 22:16 ` Andrey Savchenko [this message] 2020-03-17 22:31 ` Dmitry V. Levin 2020-03-17 22:48 ` Leonid Krivoshein 2020-03-18 8:49 ` Andrey Savchenko 2020-03-17 22:56 ` Alexey Gladkov 2020-03-17 23:10 ` Dmitry V. Levin 2020-03-18 8:45 ` Andrey Savchenko 2020-03-18 9:45 ` Sergey Afonin 2020-03-20 8:17 ` Sergey Afonin 2020-03-18 10:50 ` Dmitry V. Levin 2020-03-18 20:04 ` Andrey Savchenko 2020-03-18 20:08 ` [devel] License tag for source packages (и лишние сущности) Michael Shigorin 2020-03-18 20:11 ` Dmitry V. Levin 2020-03-18 20:14 ` Michael Shigorin 2020-03-18 20:22 ` Dmitry V. Levin 2020-03-18 20:35 ` Andrey Cherepanov 2020-03-18 12:42 ` [devel] License tag for source packages Alexey Gladkov 2020-03-17 21:07 ` Leonid Krivoshein 2020-03-17 21:50 ` Andrey Savchenko 2020-03-18 8:16 ` Alexey V. Vissarionov 2020-03-18 9:32 ` Andrey Savchenko 2020-03-18 12:23 ` Alexey Gladkov 2020-03-18 16:21 ` Anton Farygin 2020-03-18 16:35 ` Alexey Gladkov 2020-03-18 16:48 ` Anton Farygin 2020-03-18 17:04 ` Alexey Gladkov 2020-03-19 4:05 ` Anton Farygin 2020-03-19 9:52 ` Alexey Gladkov 2020-03-21 21:21 ` Dmitry V. Levin 2020-03-21 21:59 ` Vladimir D. Seleznev 2020-03-22 8:50 ` Andrey Savchenko 2020-03-23 11:53 ` Sergey V Turchin 2020-03-22 15:12 ` Alexey Gladkov 2020-03-25 8:17 ` Pavel Isopenko 2020-03-25 8:22 ` Andrey Savchenko 2020-03-25 8:32 ` Sergey Afonin 2020-03-25 9:32 ` Alexey V. Vissarionov 2020-03-25 9:46 ` Sergey Afonin 2020-03-25 10:02 ` Alexey V. Vissarionov 2020-03-25 8:33 ` Sergey Afonin 2020-03-25 9:55 ` [devel] License tag Sergey Afonin 2020-03-25 10:07 ` Alexey V. Vissarionov 2020-03-25 14:06 ` Sergey Afonin 2020-03-25 10:12 ` [devel] nfdump Dmitry V. Levin 2020-03-25 10:23 ` Sergey Afonin 2020-04-03 11:07 ` [devel] License tag Sergey Afonin 2020-04-03 12:27 ` Andrey Savchenko 2020-04-03 14:15 ` Sergey Y. Afonin 2020-04-03 14:28 ` Vladimir D. Seleznev 2020-04-03 14:34 ` Sergey Y. Afonin 2020-03-16 5:43 ` [devel] mysql-workbench-community, " Sergey Afonin 2020-03-16 22:01 ` Andrey Savchenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200318011601.087b46c0f197bbb1af30d369@altlinux.org \ --to=bircoph@altlinux.org \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git