1 |
On Thu, 26 Oct 2006 21:43:56 +0200 |
2 |
Marius Mauch <genone@g.o> wrote: |
3 |
|
4 |
> On Thu, 26 Oct 2006 12:50:01 -0500 |
5 |
> Grant Goodyear <g2boojum@g.o> wrote: |
6 |
> |
7 |
> > Marius Mauch wrote: [Thu Oct 26 2006, 12:02:59PM CDT] |
8 |
> > > Ok, as there is currently a lot of work going on for GLEP 23 |
9 |
> > > (licese based visibility filtering aka ACCEPT_LICENSE) the topic |
10 |
> > > of license groups came up, in particular the way how they should |
11 |
> > > be (technically) defined. |
12 |
> > > |
13 |
> > > The simplest way is a line based format |
14 |
> > > <groupname> <license1> ... <licenseN> |
15 |
> > |
16 |
> > At the risk of reopening a large can of worms, can somebody explain |
17 |
> > to me why the license groups idea won't run into the same conceptual |
18 |
> > issues that derailed GLEP 29 (USE groups)? Am I missing something |
19 |
> > obvious? |
20 |
> |
21 |
> Maybe my memory is wrong, but wasn't the problem only that people |
22 |
> couldn't agree on one set of semantics for negations and being afraid |
23 |
> of confusing users? In that case I don't see a big problem as long as |
24 |
> the semantics are clearly defined, as most users will probably stick |
25 |
> with just one predefined group (if they use this feature at all) |
26 |
> adjusted by a few handpicked licenses. |
27 |
|
28 |
Little discussion in #gentoo-portage resulted in the conclusion that |
29 |
license groups may only contain positive elements, and negating a |
30 |
license group will negate all elements contained in it. This avoids the |
31 |
nasty problem of double negation that was IIRC one of the killers for |
32 |
GLEP 29. |
33 |
|
34 |
Marius |
35 |
|
36 |
-- |
37 |
Public Key at http://www.genone.de/info/gpg-key.pub |
38 |
|
39 |
In the beginning, there was nothing. And God said, 'Let there be |
40 |
Light.' And there was still nothing, but you could see a bit better. |
41 |
-- |
42 |
gentoo-dev@g.o mailing list |