Re: Towards a new LPPL draft
Jeff Licquia writes:
> > The LaTeX Project is not collecting a bunch of seperate works and combines
> > them into LaTeX. It only provides 3 or 4 core parts of what is known to be
> > LaTeX as well as providing a license (LPPL) which helps to keep that thing
> > "LaTeX" uniform between different installations.
>
> I see. I was under the impression that what you distribute included
> lots of third-party stuff.
>
> Debian is really only concerned here with the core license on the core
> parts of LaTeX. If others within the LaTeX community don't like what
> you've done with the license, then they can add modification
> restrictions, and Debian can then decide to distribute them or not, or
> negotiate directly with them, or whatever.
sorry, but we are not concerned only with the core stuff. even though we don't
distribute the rest. The whole set of files put on ctan and identical (on a
pristine LaTeX installation) is what makes LaTeX useful, not their quality as
such. So either we find a solution which keeps this intact (and we
had found something with LPPL, though we are happy to reword it, to iron out
mistakes in it that do not fit the intended meaning).
but there is no point in providing a largely useless core (identical) and
having all the rest happily return to the state of 1990 where no two site had
identical LaTeX packages and thus document exchange turned out to be largely a
matter of luck or sending whole latex package trees along with the document.
> But before we can deal with the add-ons, we need to deal with the core.
no. sorry. if that is what only we are trying to do then I guess we have to
give up.
> > What i was pointing out in my second reply to Brian is this: suppose you would
> > only want to modify the work overcite.sty which consists of single file, or
> > the work geometry which consists of geometry.sty + .dtx + a number of test
> > files and manual then to be able to modify that without renaming you would
> > need to build a "nonLaTeX" format with its own tree and place it in that
> > tree. Now that "nonLaTeX" format wouldn't work at all unless you also copy a
> > good proportion of the standard latex tree (couple of 1000 files if you
> > include the fonts etc) into the new tree as well. That is certainly possible
> > but i think it is far more painful than
> >
> > providing a nonLaTeX format with filename remapping and put
> >
> > overcite.fst and geometry.fst into the main tree
> >
> > thereby having LaTeX use the main tree (ignoring those two new files)
> > and nonLaTeX using the main tree and loading overcite.fst when overcite.sty
> > would by loaded by LaTeX and the same for geometry.
>
> Please clarify something for me. What are the .fst files? Are they
> patches?
if the nonLaTeX format supports the global remapping features
for .sty files .fst files will be used if they exist
for .cls files .fcl files will be used if they exist
and so on
then the only thing that one has to do to fix any file under LPPL is to
produce a modified version and name it .fst instead of do .sty and then
nonLaTeX will use it. No need to copy huge trees of identical software
that was only rehashing why we think the suggested renaming together with the
global remapping feature is fully complient with DSFG and easy to use
> The rights we demand are usually for special cases. For example,
> someone might want to create LaTeX Plus with some of his/her new ideas
> for how document formatting should be done. Or, you guys might get hit
> by a bus, and our obligation to our users requires us to make sure that
> LaTeX is taken care of in your absence while the Project figures out who
> should take over. Or maybe no one wants to take over, and we maintain
> it as a legacy package (which we do for lots of the things we ship).
- if somebody wants to make LATeX plus he can already and it is simple and
can reuse all things untouched with the above method (and in fact is
already done, eg by Lambda
- if we get hit by a bus (which we hopefully are not) then the maintainers
clause would allow to have people take over without the need to start a new
fork
- if nobody wouldwant to takeover you could become maintainer (and support it
as a legacy package) again without the need to make a fork
so there is no problem with the rights needed by Debian for a) its users nor
for b) itself
> > > Would it work for you to require the following?
> > >
> > > - if the whole is named "LaTeX", every changed file must be renamed
> > >
> > > - if the whole is named something else, files may be changed without
> > > renaming
> > >
> > > (We would need to come up with a suitable definition for "naming", of
> > > course.)
> >
> > if there is provision that a pristine LaTeX is distributed as well so that the
> > user has the choice, probably, otherwise I think not.
>
> OK. Now I'd like to hear the Debian side. Here are the conditions for
> modification that are being proposed as I understand them:
>
> - you must rename all modified files, or
>
> - you must rename the whole of LaTeX in your modified copy AND
> distribute a pristine copy of LaTeX as well.
>
> Comments? Branden, Walter, Mark, and Jeremy, I'm especially interested
> in your opinions, since you three are the current objectors.
before anybody comments, please keep in mind that this has to work for
the whole of LaTeX, eg something roughly of the size of tetex at least.
The fork of course can be as small as it wish (even if it becomes useless this
way).
> > i'm also very interested to hear any comments on
> >
> > http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00472.html
> >
> > because that may be a different way to come together.
>
> I have an errand to run and some things to do, but I can reply to that
> in more detail. The short version: distributing
>
> foo.c (original) + foo.diff + foo (patched binary)
>
> is a minimal requirement for DFSG 3 and 4 for C files. We have rejected
> licenses before that did not allow this (pine, djb-ware).
okay. as i said already in the mail that was something i nearly concluded
myself.
However, the second question is at least equally important (I'm going to reply
to Branden there in detail) but I would like to hear other opions concerning
the question of what is source and binary in cases of LaTeX related software.
> > Personally I think also we could go one step further (though others my call me
> > back): already provide two formats
> >
> > - pristine latex
> > - nonportable-latex (for the lack of a better name, for them moment)
> >
> > where nonportable-latex is a latex-variant format that contains the
> > fileremapping feature builtin. Then then for each file type in pristine LaTeX
> > there would be a "shadow" file type that could be used to modify things to
> > your hearts wishes as long as you use the nonpartable-latex. if properly
> > drafted
> > it could be assured by LPPL that shadow files can't be restricted from
> > modifying in place. would that help?
>
> It sounds like this is a "subcase" of the case I mentioned above, where
> you can change the name of LaTeX and distribute a pristine LaTeX, but
> then can otherwise modify files without renames for not-LaTeX. Let me
> know if I'm missing something.
i think you missed something. With my suggestion the only thing one would need
to do if one would want to modify (and distribute) any file under LPPL that
falls under the filename rename requirenment is to copy it to its "shadow
file" which could then be modified freely (without further restriction).
And dueto the fact that we already provide the two formats nothing else would
need to be done.
> As I mentioned before, the fonts are in a limbo state while we figure
> out if we think data files should be required to meet the DFSG. As for
> the rest of TeX, I suspect that this will be a future topic of
> discussion here.
well, do you say that plain.tex is a data file? if that's the case how
different is this from latex.ltx (which contains most of thecode in
plain.tex)?
because if thats the case then the whole of what is currently distributed
under LPPL wouldn't make any problem any more as they would all be data
files. :-)
> But whatever the outcome for TeX, if LaTeX is deemed DFSG-free in the
> final analysis, you won't have that taken away from you if TeX is moved
> to non-free.
no. whatever the outcome is for TeX, LaTeX will go with it at least if it is
declared unfree because with TeX not in the free tree of Debian, LaTeX there
would be useless.
frank
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: