I'm not using Quake code directly, i'm referencing it to rebuild parts of GoldSource. I can't change the license because i'm using code from the SDK to rebuild parts.
You won't find actual Quake code in this because it's C code and pretty outdated. You wouldn't be able to to see any matching code as a result since it's still completely rewritten.
We've talked this over and we've concluded that no actual Quake code is in use at all, and the Quake license states this:
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
SharpLife is based on GoldSource, and is largely designed from scratch, with reused code from the SDK.
From now on i won't reference Quake anymore when working on this project, so there will be no legal issues with that codebase.
I've taken this opportunity to make a list of systems that are needed to make a working GoldSource engine, and how Quake relates to it:
- Platform specific code used for window, input, graphics management: Provided by SDL2
- Platform specific code used for file input/output: provided by NET Core APIs
- Common code (tokenization, string utility functions): Tokenization code comes from multiplay_gamerules.cpp, string utility functions are provided by NET Core APIs
- Math functions: Provided by NET Core APIs
- Graphics: Provided by Veldrid, GoldSource specific code derived from public SDK code and completed by me
- Sound: Provided by FMOD SoundSystem library
- Memory management: Quake memory management is largely obsolete even in modern Quake derivatives, and C# doesn't allow that kind of control anyway
- File loading: Derived from SDK code
- Networking: I'll be using a networking system built using a NET Core library and ProtoBuf, completely different from Quake's QSocket and Quake 2's NetChan (used by GoldSource). GoldSource's networking code is pretty terrible so reusing any of it is a waste of time and effort anyway
- Various engine and game logic functions: derived from SDK code (parts of Quake engine code were moved into game code in Half-Life), missing parts can be re-implemented
Anything else is minor and can be reproduced without the use of Quake code.
Also of note: Quake is C with some assembly, which can't be used in C#. GoldSource has a C engine and largely C++ game logic. Quake code would have to be heavily modified to even be usable, to the point where it has to be redesigned from scratch to be useful. Since Quake and GoldSource rely on global variables in many areas, any properly designed C# equivalent would be drastically different.
Thus, no licensing issues.