this post was submitted on 18 Feb 2025
13 points (100.0% liked)

Godot

6250 readers
276 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

[email protected]

Credits

founded 2 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
13
Copyleft GDExtension? (lemmy.kde.social)
submitted 3 days ago* (last edited 3 days ago) by [email protected] to c/[email protected]
22 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 3 days ago (1 children)

Why not LGPL the Rust code, and CC0 the glue code?

[–] [email protected] 2 points 3 days ago (1 children)

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.

[–] [email protected] 2 points 3 days ago* (last edited 3 days ago) (1 children)

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.

[–] [email protected] 2 points 3 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.