Quake3World

I'd like to fork (I think that's the right term) q3map2 to my own little section of github (mostly for educational reasons but more on that later)

Before I get too far, I have a few concerns:
1.Under the GNU license, can I fork willy-nilly or do I need permission, if so, may I have permission?
2.One of my long term goals is that I'd like to remove q3map2's dependencies on as many libraries as possible to make it a simple, single, enclosed application. Is that an issue for the current gtkRadiant project?
3.Most importantly, to make it a single stand-alone application, I want to isolate it from Radiant. Can I publish code that shows it in this isolated state?


Why am I doing this?

1.Education and passion
I've been tinkering with q3map2 since about 2004 and I've always wanted to understand it on a more comprehensive nuts & bolts level. I figure if I'm going to dig this far into the code to try and make sense of it, I might as well document the journey (github) so other can learn from my successes and mistakes.

2.I want to cleanly compile q3map2 and only q3map2
I don't want to mess with Radiant....yet, but as it stands, all of the stuff that isn't q3map2 is just extra stuff I have to weed through. It would be more convenient if I could isolate the code and have a much smaller code base to deal with.

3.I want to release different versions of my compiled binaries
Until I get fired for gross negligence, I have access to the latest Intel C/C++ compilers, PGI, and ..for more of a laugh, the offical Cray compilers. I'd like to improve what I can, rebuild with the latest optimizations, vectorize and unroll loops, etc... and build these binaries for other folks to use independently of any particular flavor of Radiant.

4.Quake 3 mapping should never die
With things like Doom's Snapmap coming out and game creation technology improving all the time, I hope there will always be a group of dedicated folks who want to look back and see what mapping was like ...nearly two decades ago. If I'm able to produce a measurably more efficient q3map2, I'm hoping that'll spark at least a little interest in this community. If nothing else, those of us who are still here can enjoy the benefits of compiling with modern cpu extensions.

this might help:
https://tldrlegal.com/license/gnu-gener ... license-v2

Also my personal rule of thumb with GPL is:
- modify / fork = yes
- include source / grant access to modified source (IF you distribute it!) = mandatory
- commercial use = yes

The second is usually in issue with big companies like VMware and others. They grab some gpl'd code, sell their product and keep it closed source.
That's not an option with gpl. This is just my very rudimentary recap of the gpl

I don't think you need to proactively make forked source code available. GPL grants 3rd parties the right to gain insight into the code upon request.
It's hairy business though. What is modified existing code and what is new (and thus possibly proprietary) code? Is GPL clear about that?

GPL requires to supply the source code on request, *IF* you are publishing/distributing the a compiled binary to others/public users.
If you modify the code "in your own home" and don't distribute/sell/publish anything, you're in the clear, afaik.

E.g.: the current GPL violation by VMware:
http://www.zdnet.com/article/vmware-sue ... s-license/

I'd keep everything open source. It sounds like there aren't any issues with modification and redistribution though from what your replies suggest