Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)
Henning Makholm writes:
> Scripsit Frank Mittelbach <frank.mittelbach@latex-project.org>
> > Henning,
>
> > My intention is and was to point out that while it was several times
> > expressed that the user is on your mind as well as the developer my
> > impression is that it is heavily weighted towards the latter and in
> > this particular case (in my opinion) partly sacrifying the former.
>
> The fact is that we're most emphatically not out to sacrifice the
> user.
sorry, I believe that (from everbody I've heard so far speak). Again I
expressed myself badly i guess.
> As the discussion clearly shows, we don't agree that the
> advantage $A_{ou}$ that the ordinary user gets from certain of the
> ways you attempt to protect him is significant enough to justify the
> corresponding disadvantage $D_{\overline{ou}}$ so the non-ordinary
> user [1]. But the core of the disagreement is about the size of
> $A_{ou}$, not about how to weight the comparison between $A_{ou}$ and
> $D_{\overline{ou}}$.
The disgreement is also about the size of $D_{\overline{ou}}$ to which I still
think there aren't many real arguments on the table (most are of the type: "i
think this is not free"). And what I was trying to point out is that, as you
normally do not have to make a distinction between group 1 and 2 because most
of your software if not all is relevent only to a single machine and may
differ between different machines so there is no need interest in
cross-machine equality. So if was asking you to reflect upon the question
whether a certain fixed type interpretation what is free or not is not
actually (in that particular case --- not in others) a problem for the
majority of your users.
> I don't think we'll manage to agree on the size of $A_{ou}$ by
> beating that matter any further, and in any case it ought to be
> possible to reach a workable compromise about the actual licensing
> without agreeing on that size. So couldn't we just agree to disagree
> about that matter and not make false inferences about the other
> party's morals based on the flawed assumption that we do agree about
> $A_{ou}$?
again I didn't ant to make moral statements and again apologize for probably
having sounded like that. I wanted to make you think about further on the
size of the disadvantages of $D_{\overline{ou}}$ and compare both in the light
of the situation for a cross platform exchangibility.
> > i don't really think it is the courts.
>
> I think this has been in the thread before, but: From debian-legal's
> point of view, licence texts are all about courts. When you write in a
> licence that so-and-so is forbidden, the message is that you intend to
> sue anybody who does it (to the extent that you learn of it at all).
sorry, I didn't mean that. the legal threat is not unimportant and in case of
a very crippled LaTeX distribution by a commercial supplier I sort of made it
once (and it helped).
I just meant that things normally don't end up in court.
> > or alternatively providing article.fcl ---- remember i offered to have LaTeX
> > come already with a second format that contains the remapping feature.
>
> Personally I have already declared myself happy with that.
which I find encouraging. I understand that LPPL is an edgy case, but I think
it is a case which is relevant to more than just LaTeX (or other
macro languages on top of TeX or a a variant) it is relevant to the case of
languages those domain is not a single computer but basically an open set of
nodes on the internet. At thesame time I sure would like to see it limit to
the domain it belongs to and not further and this could be properly encoded.
> I would be more happy if the remapping could be part of the source for
> the standard format (but not enabled there, of course), such that we
> wouldn't have to distribute a 'latex-free' for the diehards who want
> absolute freedom of everything they use, and a 'tetex' in non-free
> that contains the pristine LaTeX that sane people wants to use.
I already offered that though, the question is what is "not enabled".
- it is trivially possible to provide a package that opens that up
- it is equally trivially possible to provide a second format that has it
enabled.
As long as both formats are distributed side by side I would see no problems
to provide both solutions.
I personally prefer them over the "register" solution, though I guess with
suitable care that one could be added to the list of choices as well.
> > but people strongly trying to push that onto the level of Debian packaging
> > (basically). I can understand that from the developers point of view but it
> > doesn't haelp users from group 1 at all
>
> Strangely enough, my impression was that it is the other way around. I
> see the "ULL as a whole" viewpoint as one that concerns mostly the end
> user (who has no reason to concern himself with the division of labor
> among the people who wrote the software), whereas "lots of little
> individual works" would be the natural viewpoint of a developer such
> as you.
>
> I think it is important that LaTeX be free from *either* of those two
> viewpoints. The reason why we haven't talked much about the "little
> individual works" viewpoint is that that it is adequately covered by
> the license - renaming is not a problem when one adopts that
> viewpoint, so we have nothing to disagree about there. Makes for dull
> discussion.
not sure I understand that (perhaps it is simply to late (or too early) in the
day.
> > I have however tried to find other ways to overcome the problems
> > that some see in the filename restriction, eg
>
> > - the idea of full separate trees (unresolved yet)
>
> Hm, do I understand you correctly here? I don't think we (i.e. Debian)
> would have any problem with mandating fully separate directory trees
> in the case of changes. However I had gotten the impression that *you*
> didn't consider that a solution because of the (perceived or actual)
> risk of contamination between the separate trees.
it is indeed the worst of the possibilities for both thereason you give above
as well as the reason that it means you have to find a solution to the problem
that you only want to change one of the small individual works (and would need
to dsitribute a whole tree together with kernel etc) for it to be allowed.
> > ps i presume you are also on debian legal so that i don't need to cc you?
>
> True.
ok will try not to cc you then
good night
frank
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: