Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)
On Wed, 24 Jul 2002, Boris Veytsman wrote:
> > > 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,
> > and with some other license terms for at least some uses of some
> > fragments, but I like the sentiment a lot.
>
> 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.
"for some uses of some fragments". The fragment "all of latex except for
one one file" is clearly not in bounds for use in any way whatsoever
without any limitations.
> I meant only the code released under LPPL.
Sure, I just didn't see this in the current or draft version, so while it
may be common practice to use snippets, it's not allowed.
> 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.
Completely agree that it's more free, and I laud you for including it. I
just didn't notice it in the license, but it's been awhile since I read
it and I wasn't looking for parts that are free. If it's there to your
satisfaction, excellent.
> Of course not mentioning in the comments the people whose code you
> used will not make you many friends...
Sure. There's lots of things licenses must allow to be free that I don't
recommend actually be done.
> 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*.
No, it's true of C as well. We wouldn't accept a Perl, for instance, that
forbade incompatible changes to the API, even if it allowed addition of
keywords. It really is the case that we want to preserve the right to
make machine-indistinguishable subtly-incompatible changes. We recommend
against it, but if someone can't do it, it's not free.
> 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.
Sure it does. It prevents a certain kind of evolution - that of
incompatible forks. This really isn't a C vs Script issue, although what
is tolerable is more clearly defined for compiled programs.
> 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.
Ok, "beneficial dictatorial committee" then. The point remains that there
are certain types of modifications you oppose on principle (that which
could concievably be missed by a user who does not examine the software
she runs). I agree that such changes are undesirable, but I'm unwilling
to take away the right to make them.
--
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: