License issues

[jacob-likens]

I really do like the idea of a GPL gldsrc clone, however after some research I've discovered a bit of an issue.

The engine is somewhat notorious for making use of leaked source code, and indeed Valve as supposedly remarked that the engine as it stands is illegal (though I have yet to personally corroborate that.) This is troublesome because I want to use xash3D for a commercial project, so as it currently stands that dream is unworkable. But what if it wasn't?

I turned to the codebase and I've picked out all the obvious files that violate Valve's copyright:

• common/weaponinfo.h
• common/beamdef.h
• common/entity_state.h
• common/net_api.h
• common/r_studioint.h
• common/demo_api.h
• common/r_efx.h
• common/kbutton.h
• common/const.h
• common/netadr.h
• common/con_nprint.h
• common/usercmd.h
• common/studio_event.h
• common/pmtrace.h
• common/cvardef.h
• common/ref_params.h
• common/wadfile.h
• common/screenfade.h
• common/event_args.h
• common/mathlib.h
• common/qfont.h
• common/triangleapi.h
• common/cl_entity.h
• common/event_flags.h
• common/event_api.h
• common/dlight.h
• common/hltv.h
• common/particledef.h
• common/entity_types.h
• common/ivoicetweak.h
• engine/alias.h
• engine/studio.h
• engine/keydefs.h
• engine/customentity.h
• engine/anorms.h
• engine/custom.h
• engine/edict.h
• engine/cdll_int.h
• engine/progdefs.h
• engine/shake.h
• engine/sprite.h
• engine/eiface.h
• pm_shared/pm_defs.h
• pm_shared/pm_movevars.h
• pm_shared/pm_info.h

I'm not sure about any snippets of code that might violate Valve's copyright, so I'll perform a more indepth analysis to check if any exist. I doubt much if any such snippets exist, so barring that; If we rewrite these headers, the legal and licensing issues associated with this project should be resolved and full GPL compliance will be achieved.

[a1batross]

Thanks for obvious!

These headers are part of HLSDK and we can't get rid of them until we have a proper alternative. Xash doesn't have any leaked code, that's a known misunderstanding, so the only problem is SDK headers and game logic.

The thing is, we can't rewrite them by ourselves, as we already seen the HLSDK and any rewrite attempt may be considered as illegal relicensing of copypasted code.

I've had idea and still thinking about: 0) Writing a documentation about HLSDK interface. 1) Hiring a lawyers, so they can check if nothing of Valve's IP was leaked. 2) Hiring a programmer to write headers based on our documentation and asking for a agreement that he or she doesn't even seen Half-Life code and will not copy code from SDK. 3) Repeating step 1 for headers.

But, there is something that you need to consider. We don't have any commercial-grade games yet and didn't even tried to push a commercial game on Steam. Some people already tried and thanks for them, we know that Valve doesn't allow Xash3D in Steam for legal reasons. Yet they never asked to stop using HLSDK in Xash, so they probably don't care. So I don't see reason to fix license incompatibility right now.

[jacob-likens]

I'm glad to have my misunderstandings cleared up, the whole issue isn't very well discussed on the internet. This extra context is good, thank you.

I'm well aware that the issue at hand can't be simply resolved with just slightly changing the headers. That being said, it's important to note that due to the nature of this project, non-literal copying is essentially legally unappliable. I'm not aware of any legal precedent where a FOSS rewrite of non-free software (whether open or closed source) was ruled to be in violation of copyright. Valve no longer licenses gldsrc upon request, Xash3D does not do anything that threatens Valve's business model or causes the company damage. These are important considerations. I'm not a lawyer, however, so certainly I think getting a legal expert on-board for their opinion is a wise idea. I am personally planning on contacting Valve soon to see if they will offer up an opinion, however unlikely.

I have of course considered there haven't been any commercial games made with Xash3D! However, I still would like to make a commercial game with this engine, and hope to publish it to Steam, so naturally I am invested in this issue ;-)

[nekonomicon]

@jacob-likens, First of all check headers in Quake engine and ID Tech 2. HLSDK has modified Quake headers under Valve's EULA.

[jacob-likens]

Yep! One of the first steps I was going to take in this project was to compare the infringing files against Q/QW/QII's GPL source. Starting from something upstream (that's since been re-licensed as GPL) and adding interoperability is pretty legally bulletproof.

[a1batross]

I recommend you watching at NetQuake(first Quake released, before QuakeWorld) then. In id's Quake-I repository, it has been put under "WinQuake" folder. It's most close to GoldSrc.

[mirh]

It's not that Valve doesn't care, simply put the SDK license is basically as open as you can get minus the requirement for derivation to be "free" (as in beer).

But put the quake thing aside, I don't see why you couldn't license everything under GPL already plus an exception for just those files.

[a1batross]

The thing is, both HLSDK and GPL are incompatible.

HLSDK forbids using HLSDK licensed code in anything else than "Half-Life Engine", which is and only GoldSource.

GPL forbids non-free code being shared in same address space with GPL code.

We just violating them both.

We can't just do anything with HLSDK until Valve permits us to do so.

We can't just do anything with GPL code until we have HLSDK code in same process(the only solution is the IPC).

So... let's hope that Valve don't care.

[mirh]

GPL forbids non-free code being shared in same address space with GPL code.

Yes, but that would only apply to binaries. For as much as all the other source files are concerned (even if it those wouldn't build alone) you can still stick to them the license that you wished.

[a1batross]

Sorry for long answer.

Yes, but that would only apply to binaries

But what's the point of source if binaries are still violate the license? :)

BTW ReHLDS guys license their code as GPL but they add an exception for HLSDK. I don't know is this someone's fantasy or lawyer's recommendation.

[nekonomicon]

I don't know is this someone's fantasy or lawyer's recommendation.

Probably, fantasy of amxmodx's author.

Wait... Seems such exception really exists, but this exception must be written by original code author. https://en.m.wikipedia.org/wiki/GPL_linking_exception

[mirh]

GPL forbids non-free code being shared in same address space with GPL code.

Ok I'm sorry. I have actually read the GPL license, and I really did not know that there were limitations on linking even in this direction (i.e. unfree bits inside a GPL executable, rather than the usual "GPL bits inside unfree program"). Though to be fair the v3 is really a sore to understand. Thankfully the FSF has some official FAQs.

https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#FSWithNFLibs https://www.gnu.org/licenses/gpl-faq.en.html#FSWithNFLibs

The HL aren't a "system library", so you don't get a free pass.. But Xash3D is small enough that it doesn't seem a big deal to get those notes added.

[mittorn]

Xash3D uses code from quake-1, quake-2, quake-3, qfusion and maybe some libraries. Yes, i think it's possible to add exception to our code and code by Unkle Mike, but not for ID Software's and all quake ports authors. And it is almost impossible even to find all contributors, xash3d has very long history: https://github.com/a1batross/Xash3D_ancient And much of this code refactored and moved in different places of engine. Even finding all contributors is almost impossible

[Cloudwalk9]

Might I recommend FTEQW's implementation of these offending headers?

[a1batross]

@Cloudwalk9 thanks for linking them.

Anyway, we need a real lawyer here and I'm not ready yet to ask somebody to verify that ours or FTEQW headers are indeed does not derived from HLSDK and instead were rewritten in "clean room" manner.

[grepwood]

This is a real shame, because I want to package Xash in Gentoo along with a gamedata ebuild to enable us a fully libre and legal Half-Life experience along the lines of current Quake3 arrangements.

[a1batross]

@grepwood pack it in your own overlay. :) I guess you can even write an ebuild for downloading game data with steamcmd or depotdownloader.

[grepwood]

@a1batross I do employ such things in my ebuilds for obtaining gamedata and give it a fair level of integration with Portage for a seamless experience. See https://gitlab.com/src_prepare/src_prepare-overlay/-/blob/master/eclass/gog.eclass and https://gitlab.com/src_prepare/src_prepare-overlay/-/blob/master/games-rpg/fallout1/fallout1-1.1.ebuild.

Only problem is the lack of license. This is really uncommon for an open source project and Xash would be the first such to receive LICENSE="UNKNOWN".

[a1batross]

@grepwood it's better to write it's GPLv3(see COPYING file) but move Half-Life binaries into standalone package with HLSDK license.

Game files itself are proprietary and can be obtained only through Steam.

[a1batross]

Aaaand I just realized there is no COPYING file.

Gonna add it then.

[SugaryHull]

Might I suggest temporarily relicensing the GPLv3 code under a 2 or 3-clause BSD license? This would, of course, require the consent of every contributer, but it doesn't appear entirely out of the question.

[nekonomicon]

@SugaryHull And how you can relicense quake engine to BSDL?

[SugaryHull]

@nekonomicon I stand corrected. Carry on.

[a1batross]

@SugaryHull I doubt we can ask id Software, DarkPlaces developers, Unkle Mike and everyone who contributed to xash3d-fwgs to relicense it permissive licenses.

Even if it was possible, I'm personally not fan of permissive licenses and probably wouldn't even consider it.

[JJL772]

Sorry to resurrect this dead thread again, but I'd like to address this from @a1batross's initial comment in this thread:

These headers are part of HLSDK and we can't get rid of them until we have a proper alternative. Xash doesn't have any leaked code, that's a known misunderstanding, so the only problem is SDK headers and game logic.

Many of the comments and code in s_mix.c matches exactly to code in Source's audio system (in snd_mix.cpp to be specific). I can't seem to find any corresponding code in quake 1/2/3 or other idtech games. If the sound mixing code isn't from a leak, where is it from?

---

P.S. Thanks for all the work on this project. I don't mean to stir up any drama with this comment- I'm just curious where the code is from.

[a1batross]

@JJL772 yeah, indeed.

This is simple sound mixing and upsampling code that I planned to rewrite at some point. Writing your own audio mixer or naive upsampling isn't too hard but on other hand, it's very minor task. Yes, it was copypasted by Unkle Mike at some point, even earliest versions from 2007 still has this file: https://github.com/a1batross/Xash3D_ancient/blob/2007-11-11/source/!source/engine/snd_mix.c

And while this can be considered as a violation, this is still a minor problem compared that we still highly depend on HLSDK.

I'm sorry I hid this fact but it's so miniscule compared to Half-Life SDK, it's even not worth mentioning. Mixing could be rewritten in a day or two. HLSDK cannot be dropped due to compatibility.

[Cloudwalk9]

@a1batross That is a serious copyright violation. At least you could maybe get away with the HLSDK headers because APIs (at least in the US) aren't copyrightable. But this pretty much orphans Xash3D from the open source community and makes any binary distribution liable to DMCA takedowns by anyone with their GPL code in the engine.

You don't need to violate the HLSDK copyright for compatibility. There's ways to clean-room it. That's what Wine and ReactOS are doing.

I would consider taking this extremely seriously if you care about Xash3D's reputation. A lot of work was put into the engine but legally no one can actually use it for their own games. No one can use Xash3D to implement Goldsrc support in other Quake engines or software.

[JJL772]

@JJL772 yeah, indeed.

This is simple sound mixing and upsampling code that I planned to rewrite at some point. Writing your own audio mixer or naive upsampling isn't too hard but on other hand, it's very minor task. Yes, it was copypasted by Unkle Mike at some point, even earliest versions from 2007 still has this file: https://github.com/a1batross/Xash3D_ancient/blob/2007-11-11/source/!source/engine/snd_mix.c

And while this can be considered as a violation, this is still a minor problem compared that we still highly depend on HLSDK.

I'm sorry I hid this fact but it's so miniscule compared to Half-Life SDK, it's even not worth mentioning. Mixing could be rewritten in a day or two. HLSDK cannot be dropped due to compatibility.

Yep, completely agree with you on all points. Hopefully Valve will open source goldsrc as a whole in the future, so this project will no longer be in violation of any licenses. But yeah, until then it doesn't matter too much.

It would be interesting to email valve asking for some sort of hlsdk license exception for xash3d, but I doubt they'd even respond.

[a1batross]

@Cloudwalk9 your truth.

I'm not even sure somebody should use it for their own games. The learning curve is high but the output is low. At this point I would recommend switching to Godot or Quake derivatives. Some of them are pretty nice.

Clear room sounds right thing to do but the situation right now is more that we got a legacy code that nobody else is willing to maintain. Even Unkle Mike dropped it in favor of XashNT.

If you know a good lawyer, please leave their contact, so they could help with the clean room process of rewriting HLSDK and problematic parts of the engine.

[a1batross]

@JJL772

They never respond.

[Cloudwalk9]

(Obligatory IANAL)

@a1batross Generally speaking, someone has to go through the source code and write comprehensive documentation, then someone else who has never seen the source code has to reimplement the problematic code based on that documentation. This is similar to how Wine and ReactOS do it. I am not sure this necessarily requires a lawyer.

[Joshua-Ashton]

@Cloudwalk9

Wine does not use or take advantage of any loopholes like this or leaked code in any form. It is entirely clean-room.

[Cloudwalk9]

@Joshua-Ashton What I described is a form of clean-room reverse engineering, but I didn't say Wine was doing exactly that.

[a1batross]

@Cloudwalk9 yep. Except I'm not sure we can afford ourselves dropping everything, documenting and then rewriting from scratch.

Woah, even @Joshua-Ashton is here. Thanks for your contributions :)

[Cloudwalk9]

@a1batross

Woah, even @Joshua-Ashton is here. Thanks for your contributions :)

I didn't do that (unless you were thanking him).

[basxto]

Might I recommend FTEQW's implementation of these offending headers?

There is also https://gitlab.com/headcrab-junkyard/ogs-sdk from a different GoldSrc reimplementation, though I don’t know how finished or how good cleanroomed it is. It claims that remake is based on Quake and it certainly has some Id Software, Inc. copyright in it.

[a1batross]

Many headers seem to be filled in there, but I would say it's just too good to be true.

Though I'm a bit biased here, I know the guy making it, despite working with Xash3D codebase even more years than us, he never published anything finished.

[Cloudwalk9]

Might I recommend FTEQW's implementation of these offending headers?

There is also https://gitlab.com/headcrab-junkyard/ogs-sdk from a different GoldSrc reimplementation, though I don’t know how finished or how good cleanroomed it is. It claims that remake is based on Quake and it certainly has some Id Software, Inc. copyright in it.

I'd say any Id code unchanged from Quake 1 is probably fair game even on Xash3D. Even though it's used in the context of a proprietary licensing with Valve, I'd imagine there's no practical or (IANAL) legal difference if the code is identical to the GPL release of Quake 1 anyway.