Does anyone know of a documented position from the GNOME project and/or the primary GTK authors on the threshold that would trigger concerns about code copied into non-GPL projects?
I am trying to support both GTK3 and GTK4 in Vim. I have code paths that were designed around the blocking dialog API. GTK4 has pared back the dialog API, only providing a non-blocking API. I’ve read through the rationale for this change and, while appropriate for the GTK project, the motivations don’t apply cleaning to my current project. My best path forward appears to be re-implementing the GTK3 blocking API.
Having dabbled with re-implementing that API I don’t see any way to do it that could withstand a prima facie allegation of copying the LGPL code in GTK3 because the shape of the API dictates the little that needs to be done to block in a nest glib main context and carry the dialog results back to the caller.
At the same time, the meager amount of code and the inherent similarity also seems on par with the many non-(L)GPL applications that begin as a copy/paste of the GTK example code that is also distributed under the LGPL.
The Vim license makes a special provision for the distribution of Vim under the GPL for changes that link to GPL code. However:
I would need a lawyer to clarify whether that provision is self-triggering and whether it applies to code contributed to the Vim project. The explanatory text in their docs specifically mention linking.
I think that provision would still require the code in the Vim repo to carry the LGPL license and that would significantly complicate the review of contributions to that project.
There seems to be a path forward whereby I author a gtk4to3-dialog-compat library that copies code from GTK3 and distribute it under the LGPL. However that seems like quite a bit of dependency management and packaging overhead to solve the riddle posed by this API change.
I’m hoping this has come up before and resulted in a clear position statement from the GTK project about the extent of API re-inplementation allowed under other licenses. Anyone have links to share to anything of that sort?
Hi, you’re maybe overthinking this. Just create a GMainLoop using the default GMainContext, call g_main_loop_run(), and then when the user closes the dialog call g_main_loop_quit(). Now you’ve effectively reimplemented gtk_dialog_run() and didn’t need to copy any code from GTK. Here’s an example. This is so minimal that you should probably feel safe copying it, but for avoidance of doubt, feel free to copy it into Vim. (You don’t even need the GMainLoop at all; it’s just sugar over manually calling g_main_context_iteration().)
That said, gtk_dialog_run() was removed for a reason: it’s dangerous and frequently leads to bugs because it can cause callbacks to execute at unexpected times (example). So although you can, you really probably shouldn’t.
As Michael said, open coding gtk_dialog_run() isn’t going to trip up any copyright/licensing issues: it’s how nested main loops work. Aside from running a nested main loop, you’ll have to handle the destruction of the dialog, but it’s nothing really complicated.
The main issue is that blocking the control flow of a dialog with a nested main loop is the cause of various issues, especially when it interacts with IPC like:
I have no idea which rationale you read, but it applies to any project using the GTK API; just because you designed your project in a certain way, it doesn’t mean it’s a good design—with both GTK3 and GTK4.
Thank you both for the perspective. I feel comfortable moving forward now. I really appreciate you both taking the time to provide your input here.
Blockquote
I have no idea which rationale you read, but it applies to any project using the GTK API; just because you designed your project in a certain way, it doesn’t mean it’s a good design
@ebassi the rationale I was referring to was the passage in the migration guide as well as the commit message you left. I didn’t mean to say anything was good or bad. I simply meant that Vim’s use of GTK is quite limited and eschews many of the practices that would enable re-entrancy bugs. The possibility of these bugs does exist in Vim, but the probability is lower and thus is much lower on my priority list. To be clear, my long term goal is to find a way to use the GTK4 dialogs as advised. I just need to find a compromise position to sync on temporarily before I dive into that.
