Henning Makholm writes: > Scripsit Frank Mittelbach <[EMAIL PROTECTED]> > > 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]