Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)
> > A different name to humans. A different package name, sure. In some
> > cases, a different executable name (This would be problematic if it
> > were broad enough). A different name in it's API? I don't think that
> > follows.
>
On Wed, 24 Jul 2002, Frank Mittelbach wrote:
> who is the human here? the Debian developer or the (typical?) user who uses
> ready packed/installed/whatever systems.
I'd start with GPL 2c for this definition.
when started running for such interactive use in the most ordinary way ...
with the exception that this cannot be required if the original program
does not have such output.
It can be required to identify itself to any user who bothers to look. It
should not be required (though I welcome it to be encouraged) to identify
itself to programs as part of a standard API. Yes, there is a gray line.
> - 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)
If 'latex -v' or 'latex document' normally identifies itself by name and
version (in human-readable form not intended to technically prevent
modifications), it's fair game to require modified versions to say so on
this output.
It's fair game to require it to be stated in the comments in a modified
file, if such a file has comments about origin to start with.
> - 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.
Same as above.
> But people that are in the first situation expect that documents written
> using only ULL will behave identical on different installations or more
> exactly behave as explained in brackets above.
I expect that as well, as long as those installations are running standard
latex. If not, she'll have to 1) find this out and 2) install it or
complain to her sysadmin. I welcome the addition of a "latex -v" command
to make it easy for her to determine what version of latex she has and
whether it's been modified.
I even welcome making this available in the API, but only as a strong
suggestion, not a requirement for distribution. One similar example might
be the User-Agent header sent by browsers. It's strongly recommended that
this be changed when modifying a browser, but it would be non-free to
require it, as it's intended to be read by a machine rather than a user.
> But if the installing process that was used to put "LaTeX" on that system,
> combined LPPL works with works derived from LPPL works (properly humanly
> identified in its package name but disguising itself inside LaTeX) then this
> is not at all any longer visible for her as she will never see those (Debian)
> package names but only their unpacked runtime files in the texmf file tree
> (which show up identically to the orginal as far as LaTex is concerned)
Yes. This seems to be a flaw in LaTeX - it doesn't interactively identify
itself when run.
> Thus the fact that you intend to provide identification only in the name for
> the packaging method (which isn't any longer visible in most situations) means
> that as far is this user is concerned, you are misguiding her (willingly or
> unwillingly).
She can do whatever users normally do to determine the version and type of
software she has. I always start with "foo -v" or "foo -h", but other
packages have Help...About or some other method. How does she currently
tell which version she has?
> 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).
I think this challenge will fail. The Debian users I personally
talk to have two main reasons to prefer Debian over other Linuces. I
can't tell which order these come in, but the top two are:
- Apt rocks.
- I know it's free.
Thrown in there is completeness, architecture support, and various
preferences as to specific packages, but my point is that the freedom
guarantee is vital to at least one set of our users.
> would it worry you less if packages belonging to the ULL would have to contain
> a line
>
> \ULLcomplientPackage{foo}
>
> and we require that this is removed?
Same thing. Freedom to fork a package means the freedom to make an
incompatible change that normal programs won't notice. Humans can be
required to be able to find out by reading something.
>> 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. And I would ask you to think about whether this
>> is true or false.
I am trying very hard to make sure that no software in Debian can't be
modified at will. I don't want to prevent the user from finding out, but
I do want to prevent that the notice of change be so embedded in the
program that I can't write an API-compatible (i.e. calling software and
documents can't tell) derivative.
> In other words, please think about how you weight your social contract
> commitments, eg "user needs" and "free-software" (and don't forget what you
> say is not free about LPPL).
We think about it a lot, as evidenced by this disussion and dozens like it
in the archives. Please think about how you weight your goals of allowing
modification (in ways you haven't imagined yet) and of how forcefully you
need to inform users that they have a modified version.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: