From: Ryan Hill <dirtyepic@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
Date: Thu, 2 Jan 2014 06:50:06 -0600 [thread overview]
Message-ID: <20140102065006.59a2bad9@caribou.gateway.pace.com> (raw)
In-Reply-To: 21188.38566.180273.751353@a1i15.kph.uni-mainz.de
[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]
On Wed, 1 Jan 2014 23:28:54 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> Hi,
> According to GLEP 23 [1], the LICENSE variable regulates the software
> that is installed on a system. There is however some ambiguity in
> this: should it cover the actual files installed on the system, or
> everything that is included in the package's tarball? This question
> was asked several times in the past and arose in bug 492424 [2] again.
>
> I've always preferred the first interpretation, because the second one
> would inevitably require us to repack many tarballs, in order to keep
> their license in @FREE. This would for example include the Linux
> kernel, where we could no longer use deblobbing, but would have to
> provide our own tarball with firmware blobs removed. Not sure if users
> would be happy if we wouldn't install from pristine sources any more.
> We also have mirror and fetch restrictions which allow us to control
> what tarballs we distribute, independent of the LICENSE variable.
I've always believed that when it comes down to it all Gentoo basically does
is provide a link to some source code and a script to build and install it.
Unless we violate someone's license by redistributing that source then we really
don't have to worry about it, and as you said we already have mechanisms to
deal with that. What the user does with that source is their business, and
they are solely responsible for following the terms of the license(s). IIRC
this is the stance we took back in 2006 with the cdrtools debacle [1].
So I don't understand why we would have to remove anything from the tarballs.
Unless there's a license in there that forbids mirroring then there's no need
to list other licenses that aren't relevant. The user wants to know what
conditions he needs to follow to build and use the package, not what the
tarball happen to contain. If you tell him that he can't install something
because of a license on a piece of code that is never used, built, or
installed, he isn't going to be very happy.
> Within existing EAPIs we have only one LICENSE variable available.
> (Extending it would be possible in future EAPIs, but we would end up
> with a very long transition period.) USE conditional syntax is allowed
> in LICENSE, though. So I wonder if this couldn't be used for the
> intended purpose. For example, for specifying licenses of distfiles:
>
> LICENSE="<licenses of installed stuff>
> srcdist? ( <licenses of unused stuff in distfiles> )"
>
> This idea was discussed within the licenses team, and the overall
> reaction was positive.
>
> What do you think?
Wouldn't that just prevent you from installing the package altogether?
Some people might be okay with that, but if it's a package you need then you
are forced to choose between either disabling the USE flag or stop filtering the
license for that package. Either way you end up with non-distributable stuff in
your distfiles.
Maybe we could add RESTRICT=srcdist which would cause ebuilds to save
their distfiles in a separate directory controlled by PORTDIR_NODIST or
something. If the variable is unset then it's business as usual.
--
Ryan Hill psn: dirtyepic_sk
gcc-porting/toolchain/wxwidgets @ gentoo.org
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2014-01-02 12:41 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-01 22:28 [gentoo-dev] RFC: new global USE flag "srcdist" Ulrich Mueller
2014-01-02 1:21 ` Rick "Zero_Chaos" Farina
2014-01-02 1:51 ` Michael Orlitzky
2014-01-02 2:10 ` Rich Freeman
2014-01-02 2:19 ` Michael Orlitzky
2014-01-02 2:38 ` Rich Freeman
2014-01-02 2:50 ` Michael Orlitzky
2014-01-02 2:57 ` Rich Freeman
2014-01-02 12:54 ` Ulrich Mueller
2014-01-02 15:25 ` Michael Orlitzky
2014-01-02 16:24 ` Rich Freeman
2014-01-02 11:35 ` Ulrich Mueller
2014-01-02 2:13 ` Rick "Zero_Chaos" Farina
2014-01-02 2:40 ` Michael Orlitzky
2014-01-02 2:43 ` Rick "Zero_Chaos" Farina
2014-01-02 8:56 ` Michał Górny
2014-01-02 12:45 ` Ulrich Mueller
2014-01-02 12:50 ` Ryan Hill [this message]
2014-01-02 12:54 ` [gentoo-dev] " Ryan Hill
2014-01-02 13:18 ` Ulrich Mueller
2014-01-02 14:07 ` Kent Fredric
2014-01-02 14:01 ` Kent Fredric
2014-01-02 16:10 ` Ian Stakenvicius
2014-01-02 16:28 ` Luis Ressel
2014-01-02 16:37 ` Kent Fredric
2014-01-02 17:02 ` Luis Ressel
2014-01-03 14:09 ` Kent Fredric
2014-01-02 16:53 ` Ulrich Mueller
2014-01-02 17:02 ` Luis Ressel
2014-01-02 18:17 ` Ulrich Mueller
2014-01-02 18:27 ` Rich Freeman
2014-01-02 18:34 ` Ulrich Mueller
2014-01-02 21:11 ` Ryan Hill
2014-01-02 21:20 ` Rich Freeman
2014-01-02 22:07 ` Ryan Hill
2014-01-02 22:53 ` Ryan Hill
2014-01-02 23:53 ` Ulrich Mueller
2014-01-05 3:00 ` Ryan Hill
2014-01-02 17:13 ` Ian Stakenvicius
2014-01-02 18:25 ` Luis Ressel
2014-01-02 21:24 ` Ryan Hill
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=20140102065006.59a2bad9@caribou.gateway.pace.com \
--to=dirtyepic@gentoo.org \
--cc=gentoo-dev@lists.gentoo.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox