References: <199511151659.LAA01214@aleph.bu.edu>
            <199511162216.XAA20836@spock.iti.informatik.th-darmstadt.de>
Message-ID:  <199511171521.QAA19884@frank.zdv.uni-mainz.de>
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@VM.URZ.UNI-HEIDELBERG.DE>
In-Reply-To:  <199511162216.XAA20836@spock.iti.informatik.th-darmstadt.de>
Date:         Fri, 17 Nov 1995 16:21:15 +0100
From: Frank Mittelbach <mittelbach@MZDMZA.ZDV.UNI-MAINZ.DE>
Sender: Mailing list for the LaTeX3 project
              <LATEX-L@VM.URZ.UNI-HEIDELBERG.DE>
To: Multiple recipients of list LATEX-L
              <LATEX-L@VM.URZ.UNI-HEIDELBERG.DE>
Subject:      Re: distribution conditions on packages and other LaTeX software
Status: R

Joachim,
 > > > As code written under GPL tries to embrace any code that integrates
 > > > it, i don't think i can even look at it
 >
 > Sorry, but this is nonsense. Copyright works on the expression level,
 > not on the algorithm level.

that might be the case theoretically but there have been other rulings
as well. however i don't think i want to enter that discussion.

 > > > let alone integrate any such
 > > > code into LaTeX -- which is unfortunate
 >
 > If one _wants_ to integrate it, one can ask the author to release it
 > under a different copyright for integration. Actually, one will go a
 > step further and will probably demand a copyright waiver from the
 > author, to prevent coping with dozens of copyright holders.

yes that is certainly true

 > Please note further that mere distribution (i.e., aggregation) does
 > not affect LaTeX. For this reason stand-alone packages may use GPLed
 > code without any affects on the LaTeX base distribution or on any
 > LaTeX turn-key distribution.

yes

 > PS: How much code has been integrated until now, is that really a
 > problem? I had the impression that not much code from outsiders is
 > used (to say it politely... :-)

a lot (some of which done by some Joachim Schrod :-) although we do
encurrage people to write extension packages rather than suggesting
patches for the kernel files of LaTeX as in our experiences most
people suggesting "improvements" have their own special applications
in mind and not the overall picture which means trying to balance the
kernel code between conflicting requirements.

maintaining the bug address (ie reacting to bug reports) is only
possible if we have a stable kernel that we can maintain (and
understand). It also means that contributed code has to be maintained
by the contributors which again suggests packages.

If one looks into the bug database (which i recently started to sort
for statistical purposes) than you find that beside the real bugs
(which are ususally found fast and several times (sometimes by the
same person :-) there are a lot of suggestions for improvements
several of which we have integrated but a lot of them diametral to the
suggestion by somebody else. So adding code unreflected can't be the
solution. Another important point is that we try to avoid the feature
bug (ie adding adding adding to the kernel).

But if you don't like the way latex does tabulars (like i didn't some
time ago) then writing a package which provides a different interface
is fine as everybody liking it can use it and the document clearly
shows that it is used etc. This also gives much better ways for
exporing features one might wish to see in ltx3.

btw the biggest contribution in the winter release will be a complete
rewrite of docstrip which now will produce up to 16 (surprise surprise
:-) files within one go. This will be extended (probably by june) with
a configuration mechanism which then will allow to even distribute the
unpacked files into different directories!


frank