[ggo-discussion] Re: source code?

Thanks for replying so quickly!

Peter Strempel wrote:

> /usr/ looks like the standard location for binary installations to me. 
> I first had it install into /opt, but changed it to /usr/games after 
> getting some user feedback concerning this.
>  
>
I've always thought that /usr was the standard location for package 
based programs (e.g. rpm for redhat, deb for debian) while /usr/local or 
/opt was for all non-package based, sysadmin maintained, programs.  FYI. 
I don't care either way, my setup is working fine.

> By the way, the .tar.gz binary installer is created by EPM. That's not 
> common standard, but so far the best Linux installer I found which 
> allows me to create .deb, .rpm and .tgz files without messing with 
> distribution-specific stuff. I don't want to boot Debian to make a 
> .deb, Suse to make a .rpm, etc.
>  
>
That totally makes sense.  I was interested in the source code because 
with gentoo it is very easy to turn a source tar file into a completely 
installed binary package.  The big advantage is that you can then 
compile the package for multiple architectures (PPC, ARM whatever).  A 
lesser advantage is that you can compile the package with lots of custom 
compiler options and gentoo users can easily install the package with 
"emerge glGo".  If the source code was available I would have no problem 
maintaining the gentoo package.

> Why the change? Because some idiots considered it cool to change the 
> client-time code and got a client which made them win all games by 
> time. Now, who got blamed for this? They or me? Guess...
>  
>
That really sucks.  I've heard about problems with real time games but 
am surprised to hear it was able to happen with Go.  When you connect to 
the IGS server, doesn't the server only allow legal moves?  How could 
the client subvert that?

> As the glGo source code is 100% written by me, I see no problem 
> changing the license. Used libraries are mostly LGPL except wxWidgets 
> which can be statically linked, and linked dynamically, except on 
> Linux where two libraries are linked statically (more convinient to 
> the enduser, caused lots of trouble when I had them linked dynamically 
> in earlier versions), so the glGo Linux object files are made 
> available to comply with the LGPL. I am no lawyer, but had the current 
> situation checked by a lawyer, and the result was positive.
>  
>
I'm not lawyer either so take this with a grain of salt.  I have written 
a bit of GPL and non GPL code and am pretty sure that:

1) you can link to LGPL libaries with no problems
2) When you write code it is automatically copyrighted by you.  You can 
then choose license it under the GPL, another license or even many 
licenses.
3) Once your code is released under the GPL you (the copyright holder) 
can choose to fork the code and change the license.  This seems to be 
what you did.
4) If someone else starts mucking with your old GPL code, all of their 
added code must be under the GPL license.  No one besides you can create 
a closed source version.

In a nutshell.  I think you're fine.  The only problem would have been 
if other people contributed code while the project was GPL  It would be 
problematic for you to use the contributed code.  It seems you have 
written this all by yourself so that's not a problem.


Anyway, please don't take any of these questions negatively.  I 
appreciate everything you've done.  I think the program is fantastic and 
expect it to become my default SGF viewer.  Thanks again for all the 
great work!

Robert.

Other related posts: