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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
