Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)
> Date: Wed, 24 Jul 2002 13:20:52 -0700 (PDT)
> From: Mark Rafn <dagon@dagon.net>
>
> On Wed, 24 Jul 2002, Boris Veytsman wrote:
> > Perhaps because LaTeX people want to give other people (basically
> > themselves) a couple of other rights, namely:
>
> > 1. The right to use fragments, ideas or algorithms of their code in
> > any way whatsoever without any limitations
>
> Cool. This right is incompatible with your interoperability guarantee,
Why? I took snippets of code from David Carlisle's enumerate.sty and
used it in my envlab.sty. This action is not going to break the
interoperability guarantee.
> and with some other license terms for at least some uses of some
> fragments, but I like the sentiment a lot.
>
I meant only the code released under LPPL.
> Ideas and algorithms aren't really covered by copyright, so this right is
> covered (though stating it in the license is nice). Code fragments are
> not clear unless your license specifies them. I'd strongly recommend you
> declare under what circumstances a code fragment may be distributed under
> a more liberal license than other derived works.
>
I think it might be spelled out, but my (and seems to be other
developers') understanding is exactly this: a code fragment per se is
in public domain under LPPL. This is *much* more free than, say GPL,
where I cannot take a substantial part of gcc code and put it into my
new cool compiler without putting it under GPL.
Of course not mentioning in the comments the people whose code you
used will not make you many friends...
> > 2. The right to *extend* the API by adding new features, based on the
> > old code.
>
> Which is included in #1. From what I've understood, there is one very
> large limitation, which is "as long as it's done in an approved way" or
> perhaps "as long as you don't change the way existing code behaves".
>
The latter phrase nicely summarizes it.
> > Again, I think there is a philosophical difference between the
> > interpretation of the word "modification" in our communities. For you
> > the right to modify means "I can take the published function foo and
> > make it do bar if I want". For us it means "I can write a function bar
> > OR I can write a function baz such as after it is invoked all
> > functions foo in the following code actually do bar".
>
> This sums it up well. You would like people to be able to create add-on
> software but not modify the base. We would like people to be able to
> modify the software itself.
Exactly. Note that you are limited by your programming language
(mostly C): we can modify the base by add-ons in the ways which would
be difficult or impossible for you. That is why we do not feel the
need to modify the base *directly*.
>
> I think I see the truth behind your approach. It is intended to
> maintain beneficial control over how the software evolves and is
> used, motivated at least in part by some bad experiences with people
> distributing unlabelled modifications. This is a fine and good
> goal, but it's not free. There are lots of other proprietary
> no-charge software examples with similar goals.
>
I think you are thinking in "C-ish" terms again. This is not C. This
is a macro language. Freezing the common base does not change the way
the language evolves or used. On the other way, since it is infinitely
flexible, not freezing the base makes the divergence and balkanization
almost unevitable. Look at the history of Lisp, for example.
Again, you come to this with preconcieved notions: here is source,
here is binary, here is data. Here the is freedom of distribution of
sources, here is the freedom of compilation, here is the freedom of
data copying. The problem is, our documents, classes, styles, font
description files, kernel etc. are not exactly program sources or
compiled binaries or data. They are in some sense all three and in
some other sense none of these.
Imagine that you have a set of laws about marriages and divorces. It
works fine, and you are assigned a task of drafting similar laws for
Martians. You find out that instead of two sexes these Martians have
six. Or, even better, they have none, but can choose any during
certain times (see the nice novel by Ursula Le Guin). It does not make
your task impossible (albeit it will be hard), but you must analyze
you preconcieved notions and be willing to adapt them for this
situation. The basic principles of fairness and justice still apply,
but you implementation of them might be completely revised.
I have the impression Debian people on this list do not exactly
realize the difference between their common practice and our situation
-- and between the goals of free software and the means to achieve
these goals. Yes, we use different ways to modify our programs. I
hope you could understand that it does not mean that we do not have
the freedom to modify them. We just do it in our way.
> I'd characterize this as a beneficial dictator. It's nearly ideal
> as long as the dictator is beneficial (in latex, he is) and one
> doesn't mind that a few malcontents aren't allowed to do things they
> otherwise could.
>
The thing is, there is no dictator. Or, if you wish, the LaTeX
community in toto is such dictator. The LaTeX3 project is responsible
for the kernel, but LaTeX is not the kernel or even kernel+packages
from the required directory. LaTeX is the union of the code presently
in the latex directory on CTAN, and mind you, CTAN managers are just
registrars: they do not make decisions about the code itself.
--
Good luck
-Boris
BOFH excuse #293:
You must've hit the wrong anykey.
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: