Gentoo Archives: gentoo-dev

From: Chris Gianelloni <wolf31o2@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] ACCEPT_LICENSE revisited
Date: Mon, 20 Nov 2006 23:05:11
Message-Id: 1164064357.13120.16.camel@inertia.twi-31o2.org
In Reply to: Re: [gentoo-dev] ACCEPT_LICENSE revisited by George Prowse
1 On Tue, 2006-11-21 at 09:08 +1100, George Prowse wrote:
2 > Chris Gianelloni wrote:
3 > > On Sat, 2006-11-18 at 13:25 -0800, Brian Harring wrote:
4 > >>> License groups may be negated with the result that all elements of that group
5 > >>> are also negated.
6 > >> Left out that if it's unset, it should default to ACCEPT_LICENSE=* ,
7 > >> meaning no license filtering.
8 > >
9 > > Except that it shouldn't. It should be set to @NON-INTERACTIVE, as the
10 > > GLEP says, to match what we currently have with the combination of
11 > > portage+eutils.eclass settings.
12 > >
13 > > Certain packages will *always* require interactive acceptance of the
14 > > license, as they currently do.
15 > >
16 >
17 > I agree with Brian on this. No setup should mean no rules.
18
19 I'll be honest. I don't care what your opinion is here. I know that
20 sounds a bit callous, but it isn't, and here's why. I care about what
21 we have to do with these packages that have restrictive licenses which
22 require us to do this sort of thing. You can argue all that you want,
23 but we have a legal *requirement* to do this, which is *exactly* why
24 check_license came about in the first place. The only difference here
25 is we're moving it from the ebuilds to portage.
26
27 > If people decide not to use the function it is not Gentoo's decision to
28 > still filter their packages.
29
30 It has nothing to do with being "Gentoo's decision" and everything to do
31 with following the license to the letter.
32
33 --
34 Chris Gianelloni
35 Release Engineering Strategic Lead
36 Alpha/AMD64/x86 Architecture Teams
37 Games Developer/Council Member/Foundation Trustee
38 Gentoo Foundation

Attachments

File name MIME type
signature.asc application/pgp-signature