Scripsit Frank Mittelbach <[EMAIL PROTECTED]> > Our point is that that a user of LaTeX is (normally) in either of > two situations:
> - she starts "LaTeX" on a installed unix or windows system where the > installation of the system was not installed by her or was > installed by her but using the default packings of the supplier > (which might be debian suse whatever) > > - she has installed LaTeX by herself and is aware that she added packages > that on their human names identify themselves as not belonging to the ULL > (unique latex language) as i defined it sometime last night. > > there might be a third category, which is users that run SniffenLaTeX instead > of LaTeX (those i put into category 2 for this argument) [...] > In other words, I challenge you that in this case you don't live up to your > social contract in particular to #4 of it. I.e. you are not guided be the > needs of your user _and_ the free-software community but guided only by one > singular interpretation of what is free-software (a view that is sensible in > many cases, but not necessarily in all). This paragraph, and the rest of the article, is looking disturbingly like an attempt to start a flamefest. Really, all that's going on is that we try to make sure that users of the second kind can get their work done without meeting any excessive legal or technical barriers on the way. We believe that it is possible to protect the needs of users of the first kind using the free software community's normal social mechanisms, combined with a few natural requirements that users of the second kind do not misrepresent what they are doing. We don't think that using courts to force the second group to put the first group's needs before their own will actually improve the situation of the first group enough to justify the disadvantage that the second group will suffer. The discussion at the moment is focused on determining a) How much disadvantage for group 2 your legal measures are in practise. b) How much disadvantage we can let group 2 suffer and still have good conscience about telling them that we think they will be able to get their work done. c) Whether there are alternative (legal or technical) measures that will provide the first group with the protection you desire yet yield a larger probablity that we can make (a) and (b) meet. These things (plus some more, and various fallout from things we have covered, and editorial questions about understanding what your proposed legal solution is at all) are going on in parallel. That can be confusing, especially because (b) is basically an internal Debian debate where there is yet no unanimous consensus and no authoritative test that can easily resolve the matter. However, that's the way things have to be, given the social structures in which they unfold. > From my perspective (which is undoubtely biased) this looks this > looks as if some people are very hard trying to ensure, that the > above type of user has no way at all to detect that, she is not > getting what she things she is getting. This is simply false. No people at all have been arguing against requiring modified versions to have all applicable identification strings and comments changed or amended with clear statements about the changes made. (Indeed, in several jurisdiction an author cannot even legally waive his right to have derived works clearly labeled as derivates). Your perspective looks as if you're claiming that any way of inspecting the software that is based on anything but looking at its filename and only its filename, is "no way at all". -- Henning Makholm "`Update' isn't a bad word; in the right setting it is useful. In the wrong setting, though, it is destructive..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]