This absolutely thrilled me. Right up until I realized that there's a closed-source, binary-only dependency (FBX SDK). I guess my dreams of playing this game (which I do, in fact, already own a copy of - twice over, actually) on Linux/aarch64 are still a ways off. AutoDesk indicated as of ~2017 that Linux/ARM support for the FBX SDK wasn't on their road map, and nothing seems to have changed since then.
Still- major kudos to Frictional for doing this. It's 100% an appreciated move, and very much in the right direction. The choice of FBX SDK is just, in hindsight, unfortunate, but that doesn't diminish the helpful nature of what they've done here.
(fingers crossed - maybe FBX SDK is just needed for the editor? Hope springs eternal...)
With it being open source now, someone may be able to write a new asset loader using either GLB or UDZ and convert any FBX assets to one of those formats.
Just got the HPL2 engine from TDD to build on Linux/aarch64 right up until it needs to link against the FBX SDK. Only real PITA was getting Newton on ARM going. After that it was a few cmake hacks in HPL2, and a few symlinks in the lib/linux directory of the dependencies archive.
Looks like the culprits are "MeshLoaderFBX.cpp" and "LowLevelResourcesSDL.cpp" - any workarounds for FBX SDK would need to rework and/or replace those.
Does it actually use the FBX SDK during runtime? Most engines I've worked in just use the FBX SDK to convert assets from a DCC into engine specific assets. If that's the case you might just be able to disable it?
This all sounds very fixable, and one of my first programming projects was actually interacting with the FBX SDK. I’ll take a look at it tonight, could be fun.
The copyright holder can do whatever they like with their code. They can multi-license it, add exceptions to the GPL for their own code, whatever.
GPL restrictions apply to you, since you're a third party, a licensee. You can only use the code in compliance with the GPL.
So, if YOU take Amnesia's source code, and redistribute a binary, you MUST redistribute the source code as well.
If you write a software "foo" that links to a GPL-licensed library, then "foo" must be GPL as well.
This old trick was (maybe still is? I don't know) used by QT. There was a free, open source GPL version of QT; and there was a commercial version.
You could develop and distribute QT-based applications as long as they were GPL; if you wanted to write a commercial, closed source applications, you needed to pay for a QT license.
It works in the other way. A closed source program can't rely on GPL code (without special permission) but a GPL program can rely on closed source code since you need permission from the closed source license anyway.
GPL just sets a base level of permission that you get, the rights owner is still free to grant any exemptions they want.
No, you can't distribute a binary under the GPL if it's been linked to GPL-incompatible (e.g. closed source) code. Unlike the LGPL, it doesn't make any difference whether/which part of the program is included from a library.
However, the Amensia devs aren't distributing the compiled game under the GPL, they're only distributing the source code, which doesn't include FBX. You're free to distribute code under the GPL which can't actually be compiled/linked.
That said, what you wrote doesn't make sense to me anyway, maybe I misunderstood it.
I think you are mostly right, only that they can distribute the binary since they have the rights to do whatever they want with their own code.
If I fork it I think I could add a new proprietary dependency and release the code for it but once it is built the binary would be unsharable as you say.
What I was trying to say originally is that if I was writing proprietary code I would not be able to add a gpl library and distribute the binary but I could do it the other way around.
> No, you can't distribute a binary under the GPL if it's been linked to GPL-incompatible (e.g. closed source) code.
No, GP is right. Your GPL license covers software "foo". GPL says what can be done with "foo" and things that depend on "foo"; it says nothing about what "foo" can or should depend on. "foo"'s dependencies can (and should) have their own licenses.
TL;DR: If you're writing a software "foo", you can choose what people do with YOUR OWN software (either directly or by linking into it), not with upstream dependencies.
EDIT:
I think that what you mean is that, if you're a GPL licensee (not the copyright holder) for "foo", you cannot add a proprietary dependency to it and redistribute the binary. But the copyright holder CAN do this, and it CAN add exceptions to the GPL (it's the copyright holder who can choose what to do with its code)
> GPL says what can be done with "foo" and things that depend on "foo"; it says nothing about what "foo" can or should depend on.
False, the GPL (when applied to binaries rather than source code) applies to entire copyrighted works -- entire programs, with the exception of "major essential components" of the OS (ie system libraries). No other limits are placed (unless the author adds them): it's designed to stretch as far as the concept of "copyrighted work" will allow, which is presumed to include dynamically linked dependencies, and commonly presumed to not include other binaries called by your program (e.g. calling the Steam API using RPC is GPL-compatible, doing it using the SteamWorks client library is not.)
I wrote "you can't distribute a binary under the GPL..." which is true regardless of whether you wrote the program. Of course if you own the software you can instead distribute it under a different license, or add exceptions to the GPL.
To reword: basically, you're right in that if you own the code, you can license it under GPL with an exception to allow linking to anything you want. If you don't add necessary exceptions and distribute binaries, you've provided an invalid license to code you don't own, and those binaries aren't lawfully redistributable.
It's complicated, but essentially yes, you can. But you may not be able to distribute the compiled work, just the source code, without bundling the closed source libraries.
Still- major kudos to Frictional for doing this. It's 100% an appreciated move, and very much in the right direction. The choice of FBX SDK is just, in hindsight, unfortunate, but that doesn't diminish the helpful nature of what they've done here.
(fingers crossed - maybe FBX SDK is just needed for the editor? Hope springs eternal...)