Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote:
> So, if the technical committee would like to comment on this issue,
> take the decision out of my hands, or overrule any decision I might
> otherwise make, now would be a good time.
The technical committee can't override the constitution (nor foundation
documents) any more than you can.
However it might be worthwhile introducing a "Sarge Exception", making
an explicit grandfather clause applicable only to sarge, and earlier
distributions, so we can release the it. This is philosophically ugly,
but then some people (perhaps RMS) think the same of debian as a whole.
The language of that GR might run something like: In the past, we
have had some disagreements between ourselves about what it is we're
trying to do and what should go in a free distribution. We intend to
fix those issues, going forwards, however to release the version of
the distribution which we were about to release, it's going to have to
include some components which might have been acceptable under our old
social contract but which are definitely not acceptable under the new.
We resolve to distribute the "Sarge Distribution" with packages licensed
as they are currently licensed, even though these license conflict
with the updated social contract. We'll also be providing in "Sarge"
a document listing at least one such conflict for each of these packages.
As an aside... or as a possibly related issue, consider glibc -- here
is a piece of software which is licensed as free (though RMS might say
that the LGPL licensed components aren't as free as he'd like), but
which in practice is still distributed in almost-binary form (you can't
build current versions of glibc on linux without having extremely current
binaries because the version skew is so great). In essence, the preferred
form for working with this software must include its binaries... anyways,
I've not thought this all the way through, but parts of glibc are GPL'd
software and there's some possibility that without the sarge exception
we wouldn't be able to distribute glibc (or maybe any of the GPL licensed
parts of the tool chain) in its current form.
If RMS doesn't agree that this is some sort of problem, I'm not sure
what position that leaves us in. Maybe we need to have an alternative
"can be built and statically linked from source mini libc" explicitly for
bootstrapping when building newer version of debian from older versions of
debian, to avoid this quandry? [I can imagine this having some value in
other contexts, but even a "mini-libc" can take an awful lot of work to
get right -- not to mention the analogous work it would take to replace
other core stuff available from the FSF which we have problems with.]
--
Raul
Reply to: