Re: That "vision" thang...

Mats Lidell writes: Note that we also need to think about promotion to stable; I don't know if Vin would consider 21.5 something he's willing to take on. *Can* do. To relicense to GPLv3 in principle is just a global substitution, and exchanging the license text in COPYING. We should also make sure we have the FSF's address right everywhere. Finally, there is a small number of files that either have no permissions notice or lack the "or later" clause, and we need to decide what to do about that. Larry Rosen told me that it's not a crime to violate copyright unless you do it willfully to make a profit. It follows, he said, that as long as you do nothing that upsets a copyright holder, anything else is "legal". Even if a copyright holder objects, the worst that can happen is we have to take out his content, or revert to the previous license. (The latter may be possible for documentation files and freestanding helper applications like etags -- not that etags could be a problem, it's just an example of "freestanding".) So it seems to me that to satisfy both the law and ourselves that we're making the license change in good faith, we need to (1) identify "problem" files (this is done or at least there's a script to do it, I think) (2) find the relevant authors (reading the file and grepping ChangeLogs and CVS history) (3) write them an email, and wait a month (4) if there are no objections, change the license For any file where there's an objection, we'd need to decide how to deal with it. In cases of no answer, IMO we made a good faith effort, and then we decide if the risk of having to rip it out is worth it. I don't understand why you think we need to wait. It's a basically mechanical process, and one that a non-technical volunteer can do everything except assess the risk and cost of "rip outs" of code whose owner refuses to change license. That should be doable concurrently with the technical stuff that needs to be done. Actually, supporting the window systems is not so hard. Very few of the problems come from the window systems themselves as far as I know. The problems with display that I know of are due to (1) the as-yet unstable move of window configuration code to Lisp, which has little to do with redisplay and window systems, (2) font-related stuff which we must handle ourselves (unless we want to change redisplay to something like Gecko; the hideous state of Xft is one example), and (3) interactions with garbage collection. The reason that GTK or wxWindows really doesn't help that much is that in order to do things like faces, invisible text, wrapping or truncation of lines, etc, we need to handle text redisplay ourselves. That's the complex stuff, and Pango goes partway to handling Mule-related font stuff, but none of the windowing systems support a text widget with the capabilities we need. Unless you think an XEmacs where Emacs windows have the enormous power we've come to associate with browser text-entry boxes is sufficient!<wink> I believe it's in conflict with the basic architecture of *any* Emacs- like editor. Well, five of my candidates are 1. straightfoward configuration of Xft fonts from resources or Lisp (unification to Lisp only can come later; we really should provide an X-resource-file-to-Lisp translator), 2. general improvement of face and other customization, 3. Xft font turds, 4. fix window configuration management (VM at least suffers horribly), and 5. SUMO-in-source distribution (at least a simple version). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta