CygWin GPLing by proxy (Was: Cannot display through rsh)
Igor Pechtchanski [EMAIL PROTECTED]: [snip!] Unfortunately, you wouldn't be able to distribute the resulting application, because anything linked with cygwin1.dll automatically becomes GPLd. If you could find an open-source JDK, this problem would not arise. IANAL, but... can this be right? If I write an application for UNIX/linux and make it available under some other license than GPL, and someone else ports it to CygWin, I don't see how this would automatically make my application be GPL'd? An in any case, this would only apply to the JDK in this case. A Java application running inside the JDK shouldn't be affected in any way. Ah well. Off-topic I guess. And it isn't even Friday anymore.
Re: startx and ssh
In message [EMAIL PROTECTED], Dr.D.J.Picton [EMAIL PROTECTED] said: [Gary Nicholson [EMAIL PROTECTED] said] I have been trying to de-bug a problem with startx. When I tried to run the file, I would get a server window, no clock and no terminal windows. The command-line errors were: .. Xlib: connection to 0.0 refused by server Xlib: No Protocol specified These error messages would repeat until I hit ^Z from the console command line. I found that the script would fail if a .Xauthority file existed in my home directory. If I removed the file, startx ran without errors; the server, the clock and the terminal windows all opened successfully when there was no .Xauthority file in my home directory. I found that the .Xauthority file was being created when I logged onto my Cygwin machine from another machine using ssh with the same login name. I am proposing a fix for this problem: In /usr/X11R6/bin/startx, add the following code before the block that exports the XAUTHORITY variable: # remove $HOME/.Xauthority if it exists if [ -f $HOME/.Xauthority ]; then rm $HOME/.Xauthority fi This code just removes .Xauthority if it exists. If .Xauthority doesn't exist, it does nothing. Does anyone have any feedback? I've seen the problem, and in my view there's a better solution. Remove the code which sets XAUTHORITY. (I think the problem occurs because XWin assumes -auth $XAUTHORITY if the variable is set, then gets upset because it can't find the authorization key for your display.) Even better, don't leave the X server wide open for everybody to screw with. The XFree-86 server includes the security extension (see xdpyinfo) so you should be able to generate a proper X authentication token for the display. Something like: xauth generate :0 . or xauth add $DISPLAY . `mcookie` added to the top of your ~/.xinitrc should do the trick. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions.
Re: startx and ssh
Mail-Followup-To: [EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: startx and ssh Date: Sat, 16 Aug 2003 03:39:02 -0400 From: John P. Rouillard [EMAIL PROTECTED] x-scan-bham: no Even better, don't leave the X server wide open for everybody to screw with. I'm puzzled by this assertion. The default is to allow access only from the local machine, and in my view this is secure enough for most people! The XFree-86 server includes the security extension (see xdpyinfo) so you should be able to generate a proper X authentication token for the display. Something like: xauth generate :0 . or xauth add $DISPLAY . `mcookie` added to the top of your ~/.xinitrc should do the trick. I would like to add a note of caution here. For some reason, Magic Cookie authorization only works for truly local connections i.e. :0, but the server throws up a 'Protocol Not Specified' error for network displays, e.g. 127.0.0.1:0. If you set up the server with Magic Cookie authorization as the only means of access, you will have to make sure that DISPLAY is set to :0, and change any scripts which specify -display 127.0.0.1:0. -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions.
Re: CygWin GPLing by proxy (Was: Cannot display through rsh)
On Sat, 16 Aug 2003, Steinar Bang wrote: Igor Pechtchanski [EMAIL PROTECTED]: [snip!] Unfortunately, you wouldn't be able to distribute the resulting application, because anything linked with cygwin1.dll automatically becomes GPLd. If you could find an open-source JDK, this problem would not arise. IANAL, but... can this be right? If I write an application for UNIX/linux and make it available under some other license than GPL, and someone else ports it to CygWin, I don't see how this would automatically make my application be GPL'd? An in any case, this would only apply to the JDK in this case. A Java application running inside the JDK shouldn't be affected in any way. Ah well. Off-topic I guess. And it isn't even Friday anymore. Steinar, Well, there has been plenty of GPL discussion on the Cygwin list -- let's not also start it on cygwin-xfree. However, since this involves something I said, I'd like to correct one misunderstanding: if you release your application under some licence that's not compatible with GPL (as defined by FSF), whoever ports your application to Cygwin and distributes it is *in violation* of the GPL (but that does not make your application GPL -- you, as the author, completely control the licensing terms). For more information, please review the numerous discussions on the Cygwin list or contact a GPL discussion list. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: Lastest version of xclock (-digital mode) seg faults
Alexander Gottwald wrote: I will try to reproduce the problem. I could not reproduce the crash and can't verify if the patch i mentioned would fix it. NP: Deine Lakaien - Mindmachine -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
