Re: forwarded message from Jeff Licquia
Glenn Maynard writes:
> On Fri, Jul 19, 2002 at 01:28:53AM -0400, Boris Veytsman wrote:
> > So, you are defending abstract principles against a very unlikely
> It sounds like you're dismissing Debian's strict free software principles
> because they're "abstract".
I for my part am not dissmissing Debian's software principles because they are
abstract, on the contrary (and in fact i don't think that Boris does either,
though he can speak up for himself). But at the same time it would be nice if
we don't have to rehash the same arguments over and over again. To repeat a
quote from Jeff's recent mail:
> I think this is the main issue. You have a tradition for allowing
> modification that is different from what we're used to. The question is
> whether this tradition meets the qualifications of DFSG 3 and 4.
> - A program is modifiable if a user has the legal right to change the
> program's behavior in an arbitrary way without excessive inconvenience
> or requirements.
the question is: is LPPL-x (x for a carified version) conformant with DSFG 3+4
(and the others) yes or no. In other words, do our "abstract" principles
conflict with yours.
> Don't forget, however, that they're abstract principles that have
> proven to be extremely successful for all involved. People defend them
> with good reason.
right, but that goes for both sides and i think statements like the one in
Boris' mail result from the fact, that we get your "abstract" principles
repeated over and over again without ever coming to the point that anyone
acknowledges that our abstract principles also have some merrit so that we can
(together) tackle the question: can they coexist and if so how?
I see in some posts people actually trying to work on the latter question
(which i find encouraging), but on the other hand there are a good number of
posts that always return to the argument chain
- we have "good" valid abstract prinicples % which is fine; i for my part
% agree with them
- we are used to see them implemented as % i know, doing it myself too
follows ... % when the circumstances are
- so get rid of your nonsense and % this is where I stop to
follow suit % follow
often followed by
- if the LaTeX people do not value free software then ...
the DSFG describe features a license has to have to be complient with free
software in the debian sense. To fcome to a common understanding about that
(in case of LPPL) I tried to sumarize the concerns posted and the arguments
given. I still wait for further comments on that summary to see if that covers
your concerns and thinking about LPPL (as of now).
If we get those further comments I think we should be able to have a focused
discussion of whether LPPL is complient or can be made complient.
There are a number of myths it seems concerning what is allowed or not and how
LPPL must or can be applied. Now that might be born out of the fact that the
text of LPPL is badly written, or might be born out of the fact that people
simply have incorrect information (like they not use TeX but a free tetex :-)
here are some of them:
- to fork you have to rename every package under LPPL
- to get support from the kernel for a new package you have to fork the
- when modifying all future names pile up as being unchangeable
all of them wrong (and explained over and over again by now)
there have been detailed questions (intended to show that LPPL produces
"excessive inconvenience" when doing modifications (for whatever reason)) ---
I think the answers have shown that this is not the case.
so let us come back to the question whether the intentions behind LPPL (eg
our abstract principles) are in conflict with DSFG and if not try to help us
reformulating it so that everything gets clearer.
so let me repeat:
I still wait for further comments on that summary
to see if that covers your concerns and thinking about LPPL (as of now).
And please give David and me (as two of the authors of LPPL) the credit that
we have indeed looked at DSFG already when version 1.0 of LPPL came out and
are convinced that it was written to be complient with DSFG.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org