So, I started working on a new project, and I’m thinking of how to license it. Specifically, how to make it as copyleft as possible without making it unusable.

By unusable I mean the license blocking the game (or in a more likely case, any later project that reuses the code) from being published on platforms like Steam. I know that steamshim exists, but I’m not sure if that can be a real solution. Linking against the SDK seems completely optional in Steam’s case, but license compatibility is listed as a hard requirement regardless.

The game code consists entirely of a GDExtension written in Rust, so I think I can just neatly LGPL the GDExtension “library” without restricting the game executable itself. It sounds like it should work, but there are some things that I’m not sure of, like hardcoded references to assets.

I really don’t enjoy thinking licenses so I usually slap on either GPL or something permissive and be done with it. Anyone notice any holes in my plan, or am I good to go?

I know I can use my own code however I please, but it gets more difficult once there are multiple people involved; I’ve had one person express vague interest so far.

Thanks.

    • sevon@lemmy.kde.socialOP
      2·
      2 days ago

      LGPLing the Rust code is what I’m asking about, but I’m unsure if the LGPL could touch the project in some unexpected way, like having project files hardcoded.

      Maybe I’m overthinking it.

      • bruce965@lemmy.ml
        2·
        2 days ago

        Afaik, LGPL means that the library has to remain dynamically linked. That’s it. No static linking is allowed and no embedding (i.e. hardcoding) is allowed unless also the outer project is also in a LGPL-compatible license.

        So, no, they wouldn’t be legally allowed to steal your source by hardcoding it, if that’s what you are worried about.

        The issue is with code and resources that cannot be dynamically linked. I called them “glue code”, that’s the stuff developers need, in order to use your library. That is not directly your library, but you will be shipping it with your library, most likely. You will need a different license for those resources, maybe MIT or even a public domain license such as CC0.

        EDIT: I noticed you mentioned Steamworks SDK in another comment. I know Steam provides an optional DRM solution which wraps games in their own proprietary system. That might be forbidden by LGPL, I’m not sure. But linking an LGPL library to the same game that links to the proprietary Steamworks SDK shouldn’t be a problem, as long as the linking is dynamic and not static.

        • sevon@lemmy.kde.socialOP
          2·
          2 days ago

          I meant by hardcoding that it loads some assets from predefined paths from the project at runtime. I’m now thinking it’s probably not a problem.