8 ms·

Super cool. I always loved that mid-90s 3D look. I'm familiar with how the GPL applies to regular system/web software, but I haven't had experience with it and

Super cool. I always loved that mid-90s 3D look. I'm familiar with how the GPL applies to regular system/web software, but I haven't had experience with it and game engines before. Since this engine is GPL-licensed it seems like any game built with this engine would then also need to be GPL-licensed, correct?

klodolph 8y ago
> Since this engine is GPL-licensed it seems like any game built with this engine would then also need to be GPL-licensed, correct? Yes, mostly correct. In order to comply with the GPL, and distribute game binaries, you need to make the source to any game you make with it available under the same terms. Technically that does not mean that you have to distribute the game under the GPL, but in practice that's how you would comply with the engine's license.
- tracker1 8y ago
  Could just release the game engine binary with a separate loader for assets and license check... Utilizing steam for distribution and in game features could help too.
  - klodolph 8y ago
    You can't link a GPL engine against the Steam library (Steamworks SDK is proprietary) and then distribute binaries without violating the GPL. It's also not assets that are the problem, it's the game-specific code.
    - tracker1 8y ago
      You could separate the rendering logic from the game logic and create messaging channels for them... Also, the game specific code is rarely worth anything without the assets... that's why Id has released these codebases, so that people can learn/adapt... the assets retain copyright, etc. Also, you can separate out the game runtime from launcher parts... the launcher can contain other communication channels and be responsible for delivering assets. As I said, it isn't even about creating a perfect abstraction, just enough to minimize the effect of piracy.
      - klodolph 8y ago
        I think when engineers answer these questions it's easy to get bogged down in issues like whether something is a single process linked together or whether you have multiple processes communicating with one another. I don't think these arguments have serious legal merit. The question at hand is whether the game you are making is a work based on the engine. If true, to comply with the GPL you must release source. Establishing communication channels so that you can put your game logic and the engine in separate processes are not a silver bullet, they don't change the question of whether your game is a work based on the engine, they mostly change the mechanics of how your game is a work based on the engine. There are a lot of difficulties in making this argument. The court is probably not interested in hearing about whether different components are running in the same process and linked together or whether they are running in separate processes and communicating through IPC. At best, I'd say that you're running the risk of an expensive court case, and at worse I think you stand a good chance of losing it, not having enough money to fight it (because the legal arguments are quite sophisticated), and suffering from things like DMCA takedown notices in the meantime. I think the trap that software engineers fall into, far too often, is that we try to answer legal questions using the same techniques we use to solve technical questions. The question of, "Is this an executable?" or "Does this use dynamic linking?" is something you can answer based on your definitions of what an executable is. However, legal arguments don't happen in such a mechanical fashion. Contracts and laws are written in prose, not code, and they are interpreted by humans which are basically trying to do understand some combination of "what did the author mean?" and "how would people generally interpret this sentence?"
        tracker1 8y ago
        In either case, the game isn't much use without assets... and those can be copyrighted separately from the executable.
        klodolph 8y ago
        That’s not really true, you can swap out the assets for your own. People do this. You just have to swap out all the assets. Projects vary between “total conversions”, which give you essentially a new game with the existing engine, to things like Freedoom, which are complete sets of replacement assets for the stock game. Freedoom isn’t really a different game from Doom, but it combines the GPL Doom source with a new set of assets so it’s completely free.
- setr 8y ago
  Wouldn’t a game engine have the same role as gcc? As a tool, unless you’re extending the source itself, you shouldn’t be infected by the engine’s license
  - robbrit 8y ago
    Depends. In this case the engine is just a blob of code that you clone, and you modify it in order to make your game. You'd have to comply by the rules of the GPL.
  - klodolph 8y ago
    GCC explicitly has exceptions in the license for code that it inserts into your program during compilation. https://www.gnu.org/licenses/gcc-exception-3.1.en.html https://www.gnu.org/licenses/gcc-exception-3.1.en.html Also, I’d like to complain about your terminology—I don’t think “infected” is the right term. I think it’s a bit unfortunate that the word caught on. You’re never infected by the engine’s license, because you are never forced to use the same license. It’s also not a question of whether you are extending the source itself, but whether you are creating a work based on something which is GPL. Extending the source of an engine makes it clear and unambiguous that you are making something based on the engine, but it’s not the only way. An engine really isn’t a tool. You can’t interact with the engine and a game made with it separately. You can’t really swap out engines. There’s not a ton of case law exploring this, though.
- peterkelly 8y ago
  It depends on how the game engine works. If your game code is directly linked with the engine in the same executable (or a shared library) it would fall under GPL. If the game engine provides a virtual machine that executes bytecode compiled from game scripts I don't believe that would count.
  - klodolph 8y ago
    That's an argument, but I belive it wouldn't stand up in court. If you have something like the JVM, you can make a case that the program and the JVM are separate works. If you have something like Quake, I don't think that would hold up, I would consider the bytecode and Quake to form a combined work. At best, I think you would be testing in-court what a "derived work" is or what it means for a work to be "based on" a program. The legal risk is not only the fact that your game might be considered in violation of GPL (and therefore copyright infringement), but that the case might be difficult and involve sophisticated legal arguments (which would make it expensive) and you might also experience adverse effects before successfully arguing your case (DMCA takedown notices, etc).
    - ascagnel_ 8y ago
      FWIW, the source to Quake's bytecode (progs.dat, written in QuakeC) is available under the GPL. I think, since the bytecode source was distributed separately from the engine source, you could get away without distributing later bytecode source as long as you start from scratch.
      - klodolph 8y ago
        The key difference about the bytecode is that the sources are available under terms other than the GPL, but the SDK license they use does not permit commercial exploitation. I think you could distribute an open source Quake + open source progs.dat, but I don’t think you could really mix and match (distribute open-source Quake + your own closed-source progs.dat, as one product).
vortico 8y ago
Yes. If you want a business model for a game with GPL licensed libraries, the best model seems to be to sell the binaries, give away the source (which would also be licensed GPL), and plead others to not distribute binaries. It might also be possible to lock down the artist's assets as long as you comply with the GPL for distribution.
- hjek 8y ago
  According to the FAQ on gnu.org, it's fine to distribute non-free artwork with a GPLed game: > Keep in mind that some programs, particularly video games, can have artwork/audio that is licensed separately from the underlying GPLed game.[0] https://www.gnu.org/licenses/gpl-faq.html https://www.gnu.org/licenses/gpl-faq.html
badsectoracula 8y ago
Yes the code needs to be GPL, but that does not apply to the assets of course since the assets (including any scripts, although Q2 does not use scripts) are just "data". For PC games this isn't really a limitations, there are several games on Steam using GPL engines (mainly based on id's releases) - a known one is Quadrilateral Cowboy which uses the Doom 3 engine.
- vanderZwan 8y ago
  Interesting thing about the scripts being considered data. Sounds like it would be a very grey area, are there legal precedents here?
  - badsectoracula 8y ago
    I'm not aware of any legal precedent (GPL isn't contested that often in courts), but this is mentioned in the GPL FAQ: https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
deleted 8y ago
[deleted]

klodolph 8y ago

> Since this engine is GPL-licensed it seems like any game built with this engine would then also need to be GPL-licensed, correct? Yes, mostly correct. In order to comply with the GPL, and distribute game binaries, you need to make the source to any game you make with it available under the same terms. Technically that does not mean that you have to distribute the game under the GPL, but in practice that's how you would comply with the engine's license.

tracker1 8y ago
Could just release the game engine binary with a separate loader for assets and license check... Utilizing steam for distribution and in game features could help too.
- klodolph 8y ago
  You can't link a GPL engine against the Steam library (Steamworks SDK is proprietary) and then distribute binaries without violating the GPL. It's also not assets that are the problem, it's the game-specific code.
  - tracker1 8y ago
    You could separate the rendering logic from the game logic and create messaging channels for them... Also, the game specific code is rarely worth anything without the assets... that's why Id has released these codebases, so that people can learn/adapt... the assets retain copyright, etc. Also, you can separate out the game runtime from launcher parts... the launcher can contain other communication channels and be responsible for delivering assets. As I said, it isn't even about creating a perfect abstraction, just enough to minimize the effect of piracy.
    - klodolph 8y ago
      I think when engineers answer these questions it's easy to get bogged down in issues like whether something is a single process linked together or whether you have multiple processes communicating with one another. I don't think these arguments have serious legal merit. The question at hand is whether the game you are making is a work based on the engine. If true, to comply with the GPL you must release source. Establishing communication channels so that you can put your game logic and the engine in separate processes are not a silver bullet, they don't change the question of whether your game is a work based on the engine, they mostly change the mechanics of how your game is a work based on the engine. There are a lot of difficulties in making this argument. The court is probably not interested in hearing about whether different components are running in the same process and linked together or whether they are running in separate processes and communicating through IPC. At best, I'd say that you're running the risk of an expensive court case, and at worse I think you stand a good chance of losing it, not having enough money to fight it (because the legal arguments are quite sophisticated), and suffering from things like DMCA takedown notices in the meantime. I think the trap that software engineers fall into, far too often, is that we try to answer legal questions using the same techniques we use to solve technical questions. The question of, "Is this an executable?" or "Does this use dynamic linking?" is something you can answer based on your definitions of what an executable is. However, legal arguments don't happen in such a mechanical fashion. Contracts and laws are written in prose, not code, and they are interpreted by humans which are basically trying to do understand some combination of "what did the author mean?" and "how would people generally interpret this sentence?"
      - tracker1 8y ago
        In either case, the game isn't much use without assets... and those can be copyrighted separately from the executable.
        klodolph 8y ago
        That’s not really true, you can swap out the assets for your own. People do this. You just have to swap out all the assets. Projects vary between “total conversions”, which give you essentially a new game with the existing engine, to things like Freedoom, which are complete sets of replacement assets for the stock game. Freedoom isn’t really a different game from Doom, but it combines the GPL Doom source with a new set of assets so it’s completely free.
setr 8y ago
Wouldn’t a game engine have the same role as gcc? As a tool, unless you’re extending the source itself, you shouldn’t be infected by the engine’s license
- robbrit 8y ago
  Depends. In this case the engine is just a blob of code that you clone, and you modify it in order to make your game. You'd have to comply by the rules of the GPL.
- klodolph 8y ago
  GCC explicitly has exceptions in the license for code that it inserts into your program during compilation. https://www.gnu.org/licenses/gcc-exception-3.1.en.html https://www.gnu.org/licenses/gcc-exception-3.1.en.html Also, I’d like to complain about your terminology—I don’t think “infected” is the right term. I think it’s a bit unfortunate that the word caught on. You’re never infected by the engine’s license, because you are never forced to use the same license. It’s also not a question of whether you are extending the source itself, but whether you are creating a work based on something which is GPL. Extending the source of an engine makes it clear and unambiguous that you are making something based on the engine, but it’s not the only way. An engine really isn’t a tool. You can’t interact with the engine and a game made with it separately. You can’t really swap out engines. There’s not a ton of case law exploring this, though.
peterkelly 8y ago
It depends on how the game engine works. If your game code is directly linked with the engine in the same executable (or a shared library) it would fall under GPL. If the game engine provides a virtual machine that executes bytecode compiled from game scripts I don't believe that would count.
- klodolph 8y ago
  That's an argument, but I belive it wouldn't stand up in court. If you have something like the JVM, you can make a case that the program and the JVM are separate works. If you have something like Quake, I don't think that would hold up, I would consider the bytecode and Quake to form a combined work. At best, I think you would be testing in-court what a "derived work" is or what it means for a work to be "based on" a program. The legal risk is not only the fact that your game might be considered in violation of GPL (and therefore copyright infringement), but that the case might be difficult and involve sophisticated legal arguments (which would make it expensive) and you might also experience adverse effects before successfully arguing your case (DMCA takedown notices, etc).
  - ascagnel_ 8y ago
    FWIW, the source to Quake's bytecode (progs.dat, written in QuakeC) is available under the GPL. I think, since the bytecode source was distributed separately from the engine source, you could get away without distributing later bytecode source as long as you start from scratch.
    - klodolph 8y ago
      The key difference about the bytecode is that the sources are available under terms other than the GPL, but the SDK license they use does not permit commercial exploitation. I think you could distribute an open source Quake + open source progs.dat, but I don’t think you could really mix and match (distribute open-source Quake + your own closed-source progs.dat, as one product).

vortico 8y ago

Yes. If you want a business model for a game with GPL licensed libraries, the best model seems to be to sell the binaries, give away the source (which would also be licensed GPL), and plead others to not distribute binaries. It might also be possible to lock down the artist's assets as long as you comply with the GPL for distribution.

hjek 8y ago
According to the FAQ on gnu.org, it's fine to distribute non-free artwork with a GPLed game: > Keep in mind that some programs, particularly video games, can have artwork/audio that is licensed separately from the underlying GPLed game.[0] https://www.gnu.org/licenses/gpl-faq.html https://www.gnu.org/licenses/gpl-faq.html

badsectoracula 8y ago

Yes the code needs to be GPL, but that does not apply to the assets of course since the assets (including any scripts, although Q2 does not use scripts) are just "data". For PC games this isn't really a limitations, there are several games on Steam using GPL engines (mainly based on id's releases) - a known one is Quadrilateral Cowboy which uses the Doom 3 engine.

vanderZwan 8y ago
Interesting thing about the scripts being considered data. Sounds like it would be a very grey area, are there legal precedents here?
- badsectoracula 8y ago
  I'm not aware of any legal precedent (GPL isn't contested that often in courts), but this is mentioned in the GPL FAQ: https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

deleted 8y ago

[deleted]