> Date: Wed, 24 Jul 2002 13:20:52 -0700 (PDT) > From: Mark Rafn <[EMAIL PROTECTED]>
> > 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]