tags 411078 -patch thanks Mohammed Adnène Trojette <[EMAIL PROTECTED]> wrote:
> when I look for license.terms in the package, I see this: > > % grep -r license.terms * > utils/base64/yencode.tcl:# See the file "license.terms" for information on > usage and redistribution > utils/base64/base64.tcl:# See the file "license.terms" for information on > usage and redistribution > utils/base64/uuencode.tcl:# See the file "license.terms" for information on > usage and redistribution > utils/macosx/QuickTimeTcl3.1/movie.tcl:# See the file "license.terms" for > information on usage and redistribution > utils/BWidget-1.7.0/Makefile.in:# See the file "license.terms" for > information on usage and redistribution > utils/BWidget-1.7.0/ChangeLog: * LICENSE.txt: Removed LGPL license; added > Tcl-license terms. > utils/http2.4/http.tcl:# See the file "license.terms" for information on > usage and > > And when I have a look at utils/BWidget-1.7.0/LICENSE.txt as suggested > by the grep results, I actually find the terms of the Tcl license as > stated in Philippe's link. Actually, I have no idea why you think the grep results "suggest" to look into utils/BWidget-1.7.0/LICENSE.txt for the license terms of files in other subdirectories of utils/ than utils/BWidget-1.7.0/, while the actual text suggests a filename "license.terms". This looks to me just like guessing, and it may actually be right. But I do not think that it is possible to resolve that without asking upstream, or finding the relevant files somewhere else. The link posted by Filipus in the initial message point to a project that works on http stuff in tcl, but I think even here we need more hard facts to be able to take this as the license for utils/http2.4/http.tcl - in particular because this is a file with client code, whereas the project the link points to is a httpd. > Is it necessary to create a license.terms file here and put it in > /usr/share/doc/amsn for instance? Err, no, that would be a bug. The license information should be in debian/copyright, complete, and nowhere else. > Isn't is sufficient to ask upstream to correct this in a later release? If we can get clarification from upstream, we can as well put it into the package, but whether this would be etch-ignore I don't know. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
