Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)
Mark and others,
> > We already allow for the concept that programs may not be allowed to
> > "lie" about their origin in that they may be required to have a
> > different name.
>
> 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.
who is the human here? the Debian developer or the (typical?) user who uses
ready packed/installed/whatever systems.
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)
[ as a recall from last night:
LaTeX Language (LL) = union of all definitions that are lodable ontop of the
latex format regardless of their licensing or availibility
Unique LaTeX Language (ULL) = subset of LL which is licensed under LPPL and is
publically available, eg on CTAN
Now ULL (but not necessarily LL)has the property that if documents only use
commands from it then these documents either compile on an installation (and
giveidentical results) or stop at some point with a request for a part of the
ULL which is not installed.
]
Now people in the second situation know that their documents even if written
in ULL may not be processed elsewhere in the same way and they do not expect
it.
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.
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)
as a result if her document contains, say
\usepackage{geometry}
she expects the geometry from Hideo (which its features and misfeatures) but
not that something else is happening still identifying itself as "geometry"
from LaTeX's point of view.
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).
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).
Now I couldn't argue much about the singular interpretation of what free
software is, if it would the the interpretation of DSFG. But DSFG is not a
singular interpretation but for good reasons leaves leeway in several
directions, ie embraces very different licenses as free software.
Our claim is that the intentions behind LPPL (which have been stated, restated
and discussed here) do satisfy DSFG #3 already alone as well as being in
agreement with DSFG #4 or at least not in disagreement. And satisfy all other
clauses.
Branden very authoritatively explained to me why we would be in conflict with
DSFG 3:
> That means that all methods of modification must be allowed (as, I have
> said elsewhere, with the exception of deletion of or semantic alteration
> of applicable copyright notices and license terms).
which he made sound (to me at least) as if that would be the standard
interpretation needed to be fulfilled by every license you check --- which
turned out not to be true, not only for GPL but also for Artistic, both of
which are listed as DSFG-complient (and i would guess for many others as well
in one form or the other).
Branden later said:
> However, I see no reason to loosen our standards still
> further in the instant case.
I repeat my challenge: you are loosen your standards on #4 of the Social
Contract in order to prevent a simple modification restriction that
- allows everything to achieve (easily) by the provided means.
In fact we tried to offer several other alternatives, like the one that was
suggested as part of this thread, eg
\NeedsLaTeXFormat{...}
or the discussion on alternate formats (which is still unresolved).
in some sense the essense of those not wanting it where IMO it is non-free but
not really giving reasons, as in
> Adding the facility is no worry. Requiring derived works to use that
> facility is non-free IMO.
so? why?
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?
>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.
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).
thanks
frank
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: