Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)
Scripsit Frank Mittelbach <frank.mittelbach@latex-project.org>
> 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 debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: