And, legally, I'm in my right to re-use (currently and AFAIK), the gedit and GtkSourceView names! There is another, different, legal mechanism for protecting that.
What's "legal" and what's "appropriate" can be different, and usually jumping to "it's legal" first indicates that you know you're doing something inappropriate.
Yes, you can legally use "gedit" and "GtkSourceView", because they are not trademarks; but if you create a "gedit" organisation, and you specifically write this:
During many years, gedit has been hosted on the gnome.org infrastructure. This change is about moving the project to GitHub instead, to gain more independence.
it's clear that you assume that you consider your forks of gedit and gtksourceview to be authoritative; ignoring for a second that you're literally hijacking existing, maintained projects with your own forks, this means downstream packagers might be misled into thinking that they should start packaging your projects instead of the appropriate upstreams, hosted on GNOME infrastructure. This, I'm afraid, is something you cannot do, as it would reflect badly on GNOME as a whole.
You also explicitly broke the compatibility between your fork of gtksourceview and the upstream copy of gtksourceview, by dropping all commits between 2018 and 2020, in the most passive-aggressive way possible:
4.0.3 was released (not by me) on gnome.org.
So bump the micro version to 40, to avoid confusion between releases on gnome.org and gedit-org on GitHub. Why 40? Why not, and because the next GNOME version will be GNOME 40.
GtkSourceView 4.0.40 will be used for gedit on Windows, to have a quality implementation.
This means it's an incompatible fork already.
You have two options:
- either you rename your forks
- or you make it abundantly clear that they are your own forks, and they should not be taken as authoritative repositories by anybody
You should also make it clear, if you decide to distribute your own fork of gedit, that any and all issues should be reported to you, not to GNOME.
I'd still recommend calling those projects something else, to avoid any and all misunderstandings.