Re: OFL license analysis
Mark Rafn <dagon@dagon.net> wrote:
>> Mark Rafn <dagon@dagon.net> wrote:
>>> This discussion seems to have gone into the weeds about WHY someone
>>> would want to make a change and whether Debian is able to make such
>>> changes reasonably.
>
> On Mon, 30 Jan 2006, Frank Küster wrote:
>> Well, only in part. A font that you can't rely on is mostly useless...
>
> I assume the "you" in this sentence is a hapless user of a system
> whose software she does not control/understand, not the person wishing
> to make and distribute changes to the font. Correct me if this is an
> incorrect reading.
ACK.
> A license that tries to protect a user from an incompetent
> developer/distributor/sysadmin is going to be non-free. There's
> really no way around this. The only way to be free is to allow a true
> fork of the software, which means a dropin replacement, even if the
> licensor disapproves.
Most existing forks *do* identify themselves as being something
different.
>>> What ever happenened to the LaTex license, by the way? That had the
>>> same non-freeness.
>>
>> You seem to have a different opinion on this as the debian-legal people
>> who negotiated with the LaTeX project and together developped the LPPL
>> version 1.3. In this version, the requirement to change file names (or
>> LaTeX package names) was dropped, probably because it was regarded as
>> "too non-free", whereas it was decided that any changed version should
>> indicate that it was changed in the version string that is (or to some
>> degree only will be) part of the API.
>
> Hmm. I claim that it is a mistake for Debian to consider something
> free if it requires binary incompatibility to distribute a modified
> version. Version strings are a funny edge-case, where if they're
> normally just human-readable information with no programmatic effect I
> can live with it, but when it becomes common to programmatically read
> them and behave differently, then it's part of the API and must be
> modifiable (or not) without restriction.
The revised LPPL says:
a. If a component of this Derived Work can be a direct replacement
for a component of the Work when that component is used with the
Base Interpreter, then, wherever this component of the Work
identifies itself to the user when used interactively with that
Base Interpreter, the replacement component of this Derived Work
clearly and unambiguously identifies itself as a modified version
of this component to the user when used interactively with that
Base Interpreter
In practice, this means that the version string displayed in the file
log of a LaTeX run will be different, and that the user, or a developer
of a package that uses "the work", has the possibility to check for the
version and act accordingly; it does of course not mean that he must do
such a check.
> It's possible that Debian made a mistake if that's what LaTeX does
> with these strings. Wouldn't be the first time.
I guess before we continue discussing this, we both should look up in
the archives the discussion that has taken place between the LaTeX team
and Debian people.
>>> It seems a clear test: if I can't distribute a changed version that
>>> can be dropped into a system without changing other software,
>>> it ain't free.
>
>> You can never distribute a bugfixed version of a font with the same name
>> (identifiers, ...) and, without changing other software, get the same
>> system behavior. That's not a question of freeness, it's a technical
>> problem.
>
> No, the intent is to get DIFFERENT system behavior by changing the
> free component, without changing other software or documents. That's
> the freedom I'm worried about here. Though the ability to get the
> same behavior is there too (perhaps a performance fix or other
> result-compatible implementation change), it's just a special case of
> the real freedom to make changes.
I know, the freedom to shoot yourself into the foot. But I think it's
not unreasonable to require that the user is at least notified what
happened, and that can only be done by changing the identifier in an
interactive dialog, or by issuing font substitution warnings in a batch
run.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Reply to: