Re: forwarded message from Jeff Licquia
Glenn Maynard writes:
> > i don't want an explanation for #3 :-) but I would like to see an argument for
> > #2 not being DSFG-complient.
>
> "4. Integrity of The Author's Source Code
>
> The license may restrict source-code from being distributed in modified
> form _only_ if the license allows the distribution of "patch files" ...
> The license may require derived works to carry a different name or version
> number from the original software."
>
> There are other things that are allowed in practice, such as requiring
> modifications to be documented. Filename changing isn't one of them,
> since that's far more cumbersome, especially where filenames have a
> direct impact on the language, as they do here.
i have heard that statement before, but to me it doesn't follow from DSFG 4
and others (regulars on this list I presume) have in my understanding also
expressed that. Not everybody --- the camp is clearly divided.
this is one of the reasons why i asked to review my compiled summary, some
such statements are contained therein, eg
http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00139.html
http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00147.html
-----------
but to try it from a different direction: suppose i have the work "varioref"
consisting of "varioref.sty" and varioref.dtx, say. Now I'm allowed to require
a "name" change according to DSFG 4, correct?
now varioref.sty contains the line
\ProvidesPackage{varioref}
so you agree with me that as part of DSFG 4 it is valid to request that this
line is changed to contain the new name of the work, correct?
problem then is that this line is tied to the external file name directly, ie
in case of a package LaTeX wil bark if you keep varioref.sty but change that
line to \ProvidesPackage{foo}. so to use that modified file with LaTeX you
have rename it to foo.sty as well.
---------
or what about this:
Bernd Link said in
http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00274.html
I think the whole problem would disappear immidiatly, if the licence
would allow and state this clear even to people not used to any form
of TeX, that - *within* restrictions to have a changed version be clearly
recognizeable for the user - anyone can change it in an arbitrary way
without crude hacks (Preload, modifing the loaded image in memory,...),
without having to change the files to be processed( i.e. without having
to change the .tex-Files to work with).
One way might be an restriction on the name of the called entry-point
binary (though this is a very strange thing, it is already accepted for
apache) or an duty to print pages of notifications to the output.
I have no idea if this is only his opinion though his reference to apache
indicates differently. Assuming the latter then i would propose to think
about the formula that
the derived work has to change its name such that when loaded into LaTeX it
will not be confused (by LaTeX) with the original unmodified work, eg if
\usepackage{varioref}
was the loading interface for the varioref work then the modified work has to
identify itself differently to LaTeX --- which again, sorry boils down to a
change in filename, by the way the loading process works.
----------
as we find it important that within the LaTeX contexts different variants of
some work are automatically distinguishable (not repeat reasons here) we
started drafting the license in a way that where honnest to what needs to be
done (while as we thought and still think being complient with DSFG-4)
anyway, as i said before I still don't see how you conclude or derive from
DFSG 4 that a change of name for a work, can't mean for certain types of work
a file name change. I understand that for many types of software it would mean
an unnecessary restriction, but that doesn't mean it is universally true, nor
does it mean that it can be concluded from DSFG.
I can accept the argument: that you want it excluded and intend to change the
clause in this way, but this is a different argument then (and I don't think
that this is actually the consensus within Debian right now).
frank
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: