That’s no less true than games written in C, or otherwise with few dependencies. Doom is way more portable than RCT precisely because it’s written in C instead of assembly.

Shared dependencies or death
Docker

🤔

Kinda. IANAL, but here’s my understanding: If you’re explicitly dual-licensing and publish the proprietary license then contributions can be assumed to also follow the same dual licensing. You’d need to be extremely careful with writing the proprietary license though, since your business is now using non-employee proprietary code.

If you write “the copyright holder may choose to allow an entity to use this work”, then you do actually need permission from every contributor. If you write “this work may be copied, modified and redistributed freely by Blah enterprises” now the business cannot be sold without losing access (or possibly have it’s name changed). If you write “Neshura may freely copy, modify and redistribute this” then you can’t be fired or move jobs without the company losing access.

You can also never ever change this license, since every contributor needs to agree. So if a mistake is made when writing it you’re just fucked.

On the other hand with a CLA that transfers copyright ownership you don’t need to dual-license at all since everything already belongs to the business. Much less risky.

Only until you have any other contributor, as you’re then no longer the sole copyright holder. If you still want to work like that you’ll need a CLA.

TLDs are valid in emails, as are IP V6 addresses, so checking for a . is technically not correct. For example a@b and a@[IPv6:2001:db8::1] are both valid email addresses.

Mesa isn’t a kernel driver. AMDGPU is the name of the kernel module and it’s primarily developed by AMD. Mesa provides OpenGL, Vulkan, etc. implementations and is funded by AMD, Intel and Valve (among others). There’s also AMDGPU-PRO which is a proprietary alternative to Mesa from AMD.

My experience with Apple issue reporting is that you’re speaking into a void.

In recent memory I’ve had both a microphone driver bug in Linux and one in macOS with specific hardware. Only one of them was fixed with an update.

Oh I’m sure they can justify spending the time porting the game. I just can’t blame them for not doing so when Apple’s policy is to not give a shit.

Yes, but it’s highly unlikely they can reuse that effort. TF2 uses an older version of source, so you either end up having to update everything to a newer version or redo all the effort you’ve already put in to porting source, but for an older version. Now multiply that by the number of source games.

I can see how you might come to that conclusion, but porting to 64bit is way more involved than it may seem. x86-64 is different enough to x86 that you’re basically porting to a new architecture: all your assembly will break just like it would porting to arm. On top of that all your sizes have changed and caused all sorts of bugs, for instance: long is 4 bytes under 32 bit on all platforms, but it’s 8 bytes on macOS & Linux and 4 bytes on Windows under 64 bit.

It’s mind boggling that Apple would drop 32bit support. Adding 64 bit support can be a lot of effort, especially on older code bases, and there’s a whole bunch of games that’ll never receive updates again. You could’ve had arm32 support, with the ability to run any x86 games.