Repository: godotengine/godot (language: cpp)

Issue:
The third-party license window does not accomplish its intentions, and should be an addon instead of in core.
### Tested versions

N/A

### System information

N/A

### Issue description

#79599 introduces the license notice dialog in core to "Providing zero (or minimal) effort way for license compliance."

But this purpose can be easily solved by auto-generating a license file in the export folder. On platforms like Web/Mobile where the file cannot be bundled with the game, the license dialog is also not accessible without a keyboard.
It requires the developer to manually add a button to show the dialog, rendering this PR awkward as the developers need to first know that the license is a thing before they can add the button to show the dialog.
If a developer already knows the license stuff and is willing to show it in their game, they'll either make their own UI that fits their game, or download the license dialog as an addon.
The dialog itself is fairly simple and is not eligible enough to be in core. And the default dialog integration seems taking away the control from the developers and making decisions for them without asking their opinions. Many developers won't even notice that there's a hidden license dialog in their game without their permission.

If the team supports the solution of the license dialog, it should be an addon with editor support. When the project is loaded for the first time or an option is selected in the tools submenu, a prompt should pop up to tell the developer about the license thing, advises them to add a button in their game to show the licenses, asks whether to add the license dialog addon and sets the shortcut up.

My opinion is that #79599 should be reverted, and this license compliance dialog integration thing should be discussed thoroughly and implemented cautiously.

### Steps to reproduce

N/A

### Minimal reproduction project (MRP)

N/A


Discussion / hints:
I disagree with the issue for multiple reasons.

The issue states that the third-party license window does not accomplish its intentions, but it doesn't actually talk about the intention behind the PR. It just complains about the "awkwardness" of such a dialog. Unfortunately, #79599 doesn't state itself the intention, rather to only state the "result".

The idea is to address the issue that almost all of the games that were made with Godot don't comply with third-party licenses. We could continue to put our heads in the sand, stating that it's the responsibility of the developers to comply properly. But that stance wouldn't make the project a good open-source citizen.

Is the third-party license window perfect? No.
Is the third-party license window awkward? Yes.
Is the third-party license window has issues and the default bindings don't include a controller shortcut? Yes.
Is the third-party license window will release in its current state in 4.5? I highly doubt it.

But does it need to be perfect? I consider it doesn't.
But it does easily accomplish its intention!: to make more games compliant.

Legalese is boring and is something that nobody "enjoys". But it doesn't mean it's optional.

Also, this issue is moot by the following fact: it is more than trivial to remove the default binding.

https://github.com/user-attachments/assets/f15da356-c4cf-4153-a996-312c0d41f3a3

I do hope that making developers to disable the default binding if they don't want it is a good incentive for them to actually implement a replacement, instead of doing nothing. And again, just that makes it accomplish the intention.

For these reasons, I highly encourage the release management team to close this issue.
Just general thoughts ahead:
 
As https://github.com/godotengine/godot/pull/79599 is:
- The keyboard shortcut works for most platforms Godot is exported on, but it practically does not for mobile devices, or potentially consoles. 
    - This requires the developer to manually implement _something_, which is also documented and encouraged in `input/ui_toggle_licenses_dialog`'s description.
- Despite best efforts, there's heavy concern the default shortcut to display the dialog  (`CTRL + SHIFT + L`) conflicts with other functionalities of the operative system.
    - Simplest workaround would be to make the shortcut even stricter (`CTRL + SHIFT + ALT + L`), at the cost of accessibility.
- The dialog can absolutely be refined more over time, to further justify its inclusion.
- Despite potential concerns, the dialog takes barely any additional memory, and barely no overhead at runtime.
    - All of the licensing text has always been present in every Godot executable, regardless if the developer chose to expose it or not.
- We must absolutely document and encourage third-party attribution as much as possible, even in the editor.


There's a few alternative solutions to the same problem, but I personally think the solution in the above PR, while flawed, is probably the best way to go about it, generally. That's not to dismiss how other options could be implemented along with it.

Keep in mind, "letting the developer do it" rarely works in practice. Most developers don't bother with exposing the huge chunk of legalese, even if they don't have to write it themselves.


> I disagree with the issue for multiple reasons.
> 
> The issue states that the third-party license window does not accomplish its intentions, but it doesn't actually talk about the intention behind the PR. It just complains about the "awkwardness" of such a dialog. Unfortunately, [#79599](https://github.com/godotengine/godot/pull/79599) doesn't state itself the intention, rather to only state the "result".
> 
> The idea is to address the issue that almost all of the games that were made with Godot don't comply with third-party licenses. We could continue to put our heads in the sand, stating that it's the responsibility of the developers to comply properly. But that stance wouldn't make the project a good open-source citizen.
> 
> Is the third-party license window perfect? No. Is the third-party license window awkward? Yes. Is the third-party license window has issues and the default bindings don't include a controller shortcut? Yes. Is the third-party license window will release in its current state in 4.5? I highly doubt it.
> 
> But does it need to be perfect? I consider it doesn't. But it does easily accomplish its intention!: to make more games compliant.
> 
> Legalese is boring and is something that nobody "enjoys". But it doesn't mean it's optional.
> 
> Also, this issue is moot by the following fact: it is more than trivial to remove the default binding.
> Enregistrement.d.ecran.le.2025-03-08.a.14.55.19.mov
> 
> I do hope that making developers to disable the default binding if they don't want it is a good incentive for them to actually implement a replacement, instead of doing nothing. And again, just that makes it accomplish the intention.
> 
> For these reasons, I highly encourage the release management team to close this issue.

Perhaps more should be done at the editor level, such as when creating and exporting projects. The presence of `Engine.get_license_info` and #79599 is too weak, and there's a potential for shortcut conflicts in #79599.
The default shortcut key assignments are ineffective on some platforms and may cause conflicts on others. By default, only code triggers should be retained, and more prompts should be provided to developers at the editor level, such as during project creation.
Moreover, if we only discuss intentions without considering the outcomes, why are there still 3.5k pull requests (PRs) that haven't been merged? And how many of the closed PRs lacked good intentions?
> The idea is to address the issue that almost all of the games that were made with Godot don't comply with third-party licenses. We could continue to put our heads in the sand, stating that it's the responsibility of the developers to comply properly. But that stance wouldn't make the project a good open-source citizen.
>
> But it does easily accomplish its intention!: to make more games compliant.
> 
> Legalese is boring and is something that nobody "enjoys". But it doesn't mean it's optional.
> 
> I do hope that making developers to disable the default binding if they don't want it is a good incentive for them to actually implement a replacement, instead of doing nothing. And again, just that makes it accomplish the intention.
> 
> For these reasons, I highly encourage the release management team to close this issue.

You are repeating things I already stated in the description: The license dialog is to automatically let the games comply with the licenses.
But as I said, an auto-generated LICENSE file takes absolutely no effort for developers on most platforms. For platforms like Mobile and Web, this PR neither accomplishes this without developer's prior knowledge of license stuff. The license file solution is a lot less intrusive and does the same thing when the developer takes no effort on the license complying.

For platforms that need developer efforts, editor prompts and supports is needed. Once editor-side things are added, there's no reason to keep the base dialog stuff implemented in core level. The editor should just grab this dialog into the project as an add-on when it is needed by developers.

The shortcut is never a problem, the problem is:
1. the lacking of the shortcuts on some platforms makes the PR not work better than a license file;
2. The intrusiveness of this PR to core is too high for something can be implemented by an addon with editor prompts. 

The team should consider the same question of "Is there a reason why this should be core and not an add-on in the asset library?" in godot-proposals issue creation page, just like any other contributors do.

Therefore, I think this issue should not be closed before an actually working and less intrusive approach is discussed and implemented.
> Moreover, if we only discuss intentions without considering the outcomes, why are there still 3.5k pull requests (PRs) that haven't been merged? And how many of the closed PRs lacked good intentions?

This is a non sequitur and it's off-topic.

The title of the issue specifically mentions that the window doesn't accomplish its intention. I just said that the intention wasn't considered at all in the issue description and that in fact, it clearly does accomplish its intention.
I think what OP actually means is that the current implementation is too intrusive. There are lighter implementations that can achieve identical functionality.

While the current implementation can simplify the work needed to display licenses for web and mobile developers; the argument is whether it's necessary `*edit*` as a part of core.
> The title of the issue specifically mentions that the window doesn't accomplish its intention. I just said that the intention wasn't considered at all in the issue description and that in fact, it clearly does accomplish its intention.

Sorry if my point is not clear at that time. My exact point is that the license window doesn't accomplish its purpose well enough to be in core. It's neither essential enough nor implemented well enough to be a mandatory part of core. Everything of this PR should be an add-on.
Also can you read my statements and replies? I've quoted the intention stated by the team member in the original PR at the first line of the description, and I've also explained it more comprehensively in my previous reply. Please refer to those more detailed arguments. Otherwise, I don't think our current conversation can lead to anything productive.
> This is a non sequitur and it's off-topic.
> 
> The title of the issue specifically mentions that the window doesn't accomplish its intention. I just said that the intention wasn't considered at all in the issue description and that in fact, it clearly does accomplish its intention.

For Android, web and some other platforms, it just doesn't achieve its goal, and the PC platform that achieves its goal will have other effects. Again, I am not against the built-in license pop-up window, I like it too, but it currently has very inappropriate occupation of shortcut keys. We should improve the presence of licenses at the editor level. #79599 and the existing license API are too weak. We should not make choices for developers on the grounds of "I think this is useful to developers", but we should make developers aware of the existence of license APIs and make their own choices.
Again, I know that manually deleting the default shortcut key is not a problem, but its presence is too weak, and many developers may not be aware of its existence at all until some players are affected by the game experience and then feedback to the developers, which is not good.
Aside from the necessity of this feature, the current implementation of this feature is not very good, it embeds the license window in the SceneTree, and can cause confusion in future maintenance.
Even if want to keep this functionality, it may be better to add the license window node which detects shortcuts and toggles visibility to autoload, so that the implementation is less intrusive and identical to the current functionality.(If they want in the future, this node can also be exposed outward, and the user only needs to actively add it to the autoload to implement the current functionality, instead of making it the default)
>  to autoload which includes a license window node that detects shortcuts and toggles visibility

That's already the current implementation, see [LicensesDialog](https://github.com/godotengine/godot/blob/master/scene/gui/licenses_dialog.cpp#L55), and based on the implementation, the dialog is lazy-instantiated, so it won't have processing cost if not opened.
> > to autoload which includes a license window node that detects shortcuts and toggles visibility
> 
> That's already the current implementation, see [LicensesDialog](https://github.com/godotengine/godot/blob/master/scene/gui/licenses_dialog.cpp#L55), and based on the implementation, the dialog is lazy-instantiated, so it won't have processing cost if not opened.

I means the autoload feature of engine. The current implementation seems adds code to scene tree and instantiate licenses dialog in it.
> I means the autoload feature of engine.

I don't think there is a precedent for engine features inserting additional autoload items into the project automatically.
I see conflicting arguments here. Detractors cannot complain that the current window isn't accessible by default on some platforms and suggest a solution with the same caveats.

I'm not a lawyer, but I simply don't think that a simple hidden LICENSE file is public enough to comply with the third-party licenses. I truly believe that the license info _must_ be accessible from the software itself. Some software offers a link to their website for the licenses, but it's arguable if it's enough.

And it cannot be an add-on, for the arguments I brought. We wouldnt make a good open-source citizen if we setup our users to fail. We do have a responsibility, and offering an add-on that something that is technically mandatory for every game/app is silly. We wouldnt have this argument about whether or not the engine needed to support audio in core.

And again. **It's an easily customizable binding.** I don't understand why there's so much pushback. I agree that we could add another modifier on top of the ones existing to reduce conflict chances. But to be honest, if the game needs the same bindings, there is 0 chance that the game developer "forgets" to test that binding.
> > I means the autoload feature of engine.
> 
> I don't think there is a precedent for engine features inserting additional autoload items into the project automatically.

Current autoload feature seems only allows resource path, if want to do this some additional changes is needed. I just think add code in main.cpp is less invasive than change the scene tree
There are two main points in this issue:

1. This dialog could be an add-on instead of being part of the core.
I completely agree that this dialog can be an add-on. However, that wouldn’t address the root issue -- developers not complying with third-party licenses in their projects. Additionally, this is a common requirement, if not essential, for all projects. That’s why integrating it into the core seems totally justified.

2. It uses a shortcut key that could be triggered accidentally.
This argument doesn’t seem valid to me. The shortcut key can be added to the game's shortcut list, making it clear to users what it does. We would also consider informing developers about it in our release blog posts. Furthermore, the shortcut can be easily removed or reconfigured if needed.
> Aside from the necessity of this feature, the current implementation of this feature is not very good, it embeds the license window in the SceneTree, and can cause confusion in future maintenance.

I don't understand the "is not very good" part: there's no way to do otherwise (as far as I know).
> > Aside from the necessity of this feature, the current implementation of this feature is not very good, it embeds the license window in the SceneTree, and can cause confusion in future maintenance.
> 
> I don't understand the "is not very good" part: there's no way to do otherwise (as far as I know).

This is my meaning
![Image](https://github.com/user-attachments/assets/338ccb21-8669-493b-b1d9-8275bd69ff51)

(I add ProjectSettings::AutoLoadInfo::resource variable to make autoload feature handle a resource reference(instead of resource path))
These code are in main.cpp, it could be less invasive than change scene tree
> I'm not a lawyer, but I simply don't think that a simple hidden LICENSE file is public enough to comply with the third-party licenses. I truly believe that the license info _must_ be accessible from the software itself. Some software offers a link to their website for the licenses, but it's arguable if it's enough.

You only need to bundle the license file with the game to comply with the license on PC, because it's easily accessible on PC.

> And it cannot be an add-on, for the arguments I brought. We wouldnt make a good open-source citizen if we setup our users to fail. We do have a responsibility, and offering an add-on that something that is technically mandatory for every game/app is silly. We wouldnt have this argument about whether or not the engine needed to support audio in core.

It can and it should be an add-on. An editor dialog is enough to prompt the user not only about the license knowledge, but also sets up this feature automatically if the user wants it. As an addon, the user can also easily customize it and integrate this dialog with the way they want.
Also, please note that, the license complying is technically mandatory, but the implementation of that PR is not. It's the users' choice to whether include that dialog in their game, to choose which implementation to use.
Making that PR as an addon with editor support solves this perfectly.

> And again. **It's an easily customizable binding.** I don't understand why there's so much pushback. I agree that we could add another modifier on top of the ones existing to reduce conflict chances. But to be honest, if the game needs the same bindings, there is 0 chance that the game developer "forgets" to test that binding.

The binding is not the problem, the implementation of a random dialog forced in SceneTree is the problem.
Also the developers typically don't want things that they are not manually presenting, so if developers don't use that binding, that binding is either not appropriate to be enabled by default. Other developers also don't like things they don't want or things they can implement themselves to be forced ON in the engine, especially in the part that is so foundational as SceneTree.
> it could be less invasive than change scene tree

> it could be less invasive than change scene tree

Moving the logic that is part of the scene tree out of the scene tree file will likely complicate maintenance. Engine developers may find nodes appearing unexpectedly at runtime, leading to confusion during future maintenance.

This does not make the dialog non-invasive. In this context, non-invasiveness means that no additional code should be added to the core of the Godot Engine. Simply relocating the code away from the source file of the scene tree does not change the fact that the dialog remains invasive.
> You only need to bundle the license file with the game to comply with the license on PC, because it's easily accessible on PC.

No, consumers of games on platforms like Steam and Epic do not launch the game by navigating to the installation directory, making the license file less accessible.

> Also the developers typically don't want things that they are not manually presenting

Most developers should implement the license dialog themselves, but few actually do.

I understand that it can be disturbing for engine users to discover hidden pop-ups in new versions, and the team should take responsibility for educating the user about the presence of these GUIs & be more conservative about adding more of these embedded GUIs in the future. 

However, in the case of the license topic, I think being parental (developers should explicitly opt out) is understandable.
I have this thought on elevating this license dialog to a dedicated, before-game splash screen popup: The player needs to click OK to enter the main scene. This should achieve every intention, and the developer will certainly notice this (surely everyone will at least launch test their game once before shipping, right?).

In the project settings, options are provided to disable this popup (either for editor play or globally). When disabled it globally, we can display an additional notice under the option to educate the user that they have to implement such a window in the game.

This is just a proof of concept. For convenience, I copied everything from the COPYRIGHT document instead of formatting it nicely.

https://github.com/user-attachments/assets/ef6273d6-4187-4572-b943-15f84dcd4a76

![Image](https://github.com/user-attachments/assets/79f03a8b-1043-45c2-889e-e00172e1c38c)

![Image](https://github.com/user-attachments/assets/63b2c1ae-a73a-4a0d-81e6-0d7ac7a998e8)

![Image](https://github.com/user-attachments/assets/f6b1e783-833b-4eb9-8179-a7378419f5ba)

And to guide the developer to the editor settings:

![Image](https://github.com/user-attachments/assets/d1b2e356-703c-4a60-ab74-edb1b52ee1b4)
> There are two main points in this issue:
> 
>     1. This dialog could be an add-on instead of being part of the core.
>        I completely agree that this dialog can be an add-on. However, that wouldn’t address the root issue -- developers not complying with third-party licenses in their projects. Additionally, this is a common requirement, if not essential, for all projects. That’s why integrating it into the core seems totally justified.
> 
>     2. It uses a shortcut key that could be triggered accidentally.
>        This argument doesn’t seem valid to me. The shortcut key can be added to the game's shortcut list, making it clear to users what it does. We would also consider informing developers about it in our release blog posts. Furthermore, the shortcut can be easily removed or reconfigured if needed.

First of all, the current default shortcut keys have already caused conflicts in my friend's project, and he had no idea about it until I shared this PR.

Then, I think merely mentioning it in the development blog is far from sufficient. How many developers would patiently go through every single development blog post and notice it? I dare say, although the API for retrieving license text has been around for a long time, many developers still don't know about its existence (including myself a few days ago). So, I believe https://github.com/godotengine/godot/pull/79599 will fall into the same situation, where Android developers remain completely unaware of it, and PC developers will only learn about it through player reports.

However, we can completely inform developers about the existence of the license pop-up at the editor level, such as when creating a project, and give them the option to choose: whether to add default shortcut keys, etc.

We shouldn't design APIs under the assumption that most developers won't know about the existence of the license pop-up and try to make it work automatically. Instead, we should find ways to make more developers aware of its existence and let them make their own choices.
> I truly believe that the license info _must_ be accessible from the software itself.

This belief is incorrect. Read the licenses themselves. There is typically no such stipulation in third party licenses.

As an example, the OFL (Open Font License) contains this, among several of its clauses:

```
2) Original or Modified Versions of the Font Software may be bundled,
redistributed and/or sold with any software, provided that each copy
contains the above copyright notice and this license. **These can be
included either as stand-alone text files**, human-readable headers or
in the appropriate machine-readable metadata fields within text or
binary files as long as those fields can be easily viewed by the user.
```

Another example, the Apache License 2.0 (a very commonly used license):

```
   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) **You must give any other recipients of the Work or
          Derivative Works a copy of this License**; and
```

Note the highlighted parts. This is a fairly common stipulation in most licenses. Now, obviously, any third party creator of content/assets is free to even create their very own license which _would_ require actually being viewable from within the software itself. But, this is simply not an automatic given for _all_ licenses. Again, read the examples I provided. There is no presumption, implied or otherwise of a requirement to make such licenses viewable from within the software.

Nor would this be very practical. Since there are cases where this is simply not possible. Take, say, a visual piece which might include an OPL licensed font. What would you expect, for the visual piece to have the license splattered all over the artwork? This obviously would be silly. But it would fall within your expectation.

This is why it simply is not feasible to _demand_ that software includes clickable/viewable copies of third party licenses.
> First of all, the current default shortcut keys have already caused conflicts in my friend's project, and he had no idea about it until I shared this PR.
> 
> Then, I think merely mentioning it in the development blog is far from sufficient. How many developers would patiently go through every single development blog post and notice it?

If your friend is running Godot directly from the master branch, I'm sorry, but yeah, things like that can happen and it's expected.

Also, your friend was able to discover that there was a conflict ahead of time. And conflicts do happen in game development. So I don't know what's the issue here.
> Nor would this be very practical. Since there are cases where this is simply not possible. Take, say, a visual piece which might include an OPL licensed font. What would you expect, for the visual piece to have the license splattered all over the artwork? This obviously would be silly. But it would fall within your expectation.

No, because I'm not talking about visual pieces, but about software.

Licenses aren't usually especially descriptive on how to actually share the license notice itself. But that's what licenses are: they describe the intent of the author about sharing their work.

But please, everyone, if you know legal precedents that state that just sharing a license file besides an executable is enough, I'll gladly agree with you. Until then, the current solution is a good (and safe) one.
> I have this thought on elevating this license dialog to a dedicated, before-game splash screen popup: The player needs to click OK to enter the main scene. This should achieve every intention, and the developer will certainly notice this (surely everyone will at least launch test their game once before shipping, right?).
> 
> In the project settings, options are provided to disable this popup (either for editor play or globally). When disabled it globally, we can display an additional notice under the option to educate the user that they have to implement such a window in the game.
> 
> This is just a proof of concept. For convenience, I copied everything from the COPYRIGHT document instead of formatting it nicely.
> 
> https://github.com/user-attachments/assets/ef6273d6-4187-4572-b943-15f84dcd4a76
> 
> ![Image](https://github.com/user-attachments/assets/79f03a8b-1043-45c2-889e-e00172e1c38c)
> 
> ![Image](https://github.com/user-attachments/assets/63b2c1ae-a73a-4a0d-81e6-0d7ac7a998e8)
> 
> ![Image](https://github.com/user-attachments/assets/f6b1e783-833b-4eb9-8179-a7378419f5ba)
> 
> And to guide the developer to the editor settings:
> 
> ![Image](https://github.com/user-attachments/assets/d1b2e356-703c-4a60-ab74-edb1b52ee1b4)

I do find the third-party license window splash screen a little bit overwhelming, but I love the idea shown in the screenshot of activating or not the feature in the project settings, and actually explain to the users what to do to comply.

And maybe we could offer users to supply their own scene to show when the shortcut is pressed.
> I do find the third-party license window splash screen a little bit overwhelming ... maybe we could offer users to supply their own scene to show when the shortcut is pressed.

While it is overwhelming, it can properly guide the developer to visit the specific settings page, and then the developer can decide whether to enable this page or create one on their own. I'm worried about the short-cut approach not explicitly enough and have platform issues.
+1 to using the splash screen.

Like the bios startup shortcut in Windows and other operating systems, it would be fine to be able to display a license dialog when a specific shortcut is pressed while the splash screen is displayed, and await the start of the scene until it is closed.

For example, if the shortcut is noted in the bottom right of the splash screen, any user will know easily how to see it. Or we could simply put a button on the bottom right of the screen. This way, the same functionality could be provided on mobile devices.

Then finally, a toggle option could be placed in the project settings to indicate license dialog on splash screen availability, so that when it is disabled, a dialog would warn the user that the license notations must be placed elsewhere.
The bios idea sounds like a fair balance between my proposal and the original PR, but that won't work with web and mobile.
I am not familiar with how to implement a mobile splash screen, but if it is outside of Godot, it may require some interrupt processing on the Swift or Android Studio side.

However for the web, there is a wasm loading screen, so we may be able to place something there, but if that is difficult, there is a hack to embed the license texts in the html so that you can see it when you open the page with the developer tools' source code viewer.
> ... it may require some interrupt processing on the Swift or Android Studio side ... there is a wasm loading screen ...

My idea is to implement the splash screen at the Godot level so that the engine loads a special license scene instead of the main scene. Then, when the continue button is pressed, the engine changes the current scene to the user-defined main scene.

> embed the license texts in the HTML

I believe the PR intends to make the license text visible to players instead of embedding it into a file or HTML codes.
If the screen before the app icon is tapped to open (in the case of the web, the wasm loading screen) is the splash screen that Godot currently assumes, then it may need to be implemented to add a default splash scene to Godot as you suggest.

My concern is that it would result in a double screen when the app is launched. Then, probably we need to separate terms/concepts like Boot Screen (environment dependent native language implementation) and Splash Screen (implemented within Godot).
> it would result in a double screen when the app is launched

Yes, and it's not ideal. This splash screen would be a last resort if the developer does not want to add in-game license displays. They should turn off this splash screen from the project settings and create their own game-specialized license display implementation.
This splash screen idea seems too much to me. We can simply inform about the Licence compliance and the existence of shortcut key in the export dialog. Android already has two splash screens, first by Android and second by Godot. I don't want a third one.
> > You only need to bundle the license file with the game to comply with the license on PC, because it's easily accessible on PC.
> 
> No, consumers of games on platforms like Steam and Epic do not launch the game by navigating to the installation directory, making the license file less accessible.

The purpose of this PR is not to let user view the license easily, but to comply the licenses for law reasons. Putting the license in the install folder is already enough for complying the licenses.
When I analyzed this in the PR comment area, nobody even replied on that. I don't know why I have to repeat those statements for so many times and you guys just keeps ignoring it. There's a lot of other more important ideas in the PR comment and this issue post, and they kept getting ignored.
> I do find the third-party license window splash screen a little bit overwhelming, but I love the idea shown in the screenshot of activating or not the feature in the project settings, and actually explain to the users what to do to comply.
> 
> And maybe we could offer users to supply their own scene to show when the shortcut is pressed.

An editor dialog prompt on project first-time startup that can add this license dialog as an addon does the same thing and introduces no intrusive code to core.
You can even made that addon bundled into a project template to let the user easily modify it or completely remove it when the user has other ideas. If a user chose to not include the license dialog, it means that they wanted it that way.

As a last resort, an option that automatically generates a license file in the export folder when exporting the game can be default checked. It's not intrusive, can be easily opted-out and respected the users' decision.
As for web and mobile, the license can be embedded into the HTML code and the app settings menu to make it comply the licenses.

The team said that the purpose of that PR is to let the game project automatically comply with the licenses, not to let players easily view the licenses.
The license file, html embedding and app settings embedding already does this with absolutely no interference to the game developers.
If you really want to educate the developers about the licenses and want them to make an in-game license dialog, just prompt them in the editor when the project is created and auto set it up when the user agrees to that or want it automatically set up. For the situations when the user doesn't want them by clicking "Don't configure" in the editor prompt, add nothing to the project to respect the users about their decisions.
@syntaxerror247 
>  Android already has two splash screens, first by Android and second by Godot. I don't want a third one.

The idea is to replace the second Godot splash screen with this license screen, not add a third one.
It all depends on the team's perspective. From the original PR, @Calinou mentioned the idea is to [make the software comply with the license automatically](https://github.com/godotengine/godot/pull/79599#issuecomment-2708399944), where in this discussion @adamscott believe we should [ensure license available for players in-game](https://github.com/godotengine/godot/issues/103830#issuecomment-2708479093) as well, it'd be better if the team can have a conseus on the degree we want the license to be available, it also helps directing the discussion.

Correct me if I'm wrong, but based on the discussion context, @TML233, @scgm0, @Invium-GH, and others think the PR is too much for achieving the former target(make the software comply with the license automatically); I think the PR is not enough to achieve the latter target(ensure license available for players in-game as well).
> Correct me if I'm wrong, but based on the discussion context, @TML233, @scgm0, @Invium-GH, and others think the PR is too much for achieving the former target(make the software comply with the license automatically); I think the PR is not enough to achieve the latter target(ensure license available for players in-game as well).

To the latter target, I think it's not the team's responsibility to do that. The team neither have the permission to decide what would be presented to the player. The latter target is just showing that the team has gone too far and stretched their hands too long. Only the game's developer can choose to display that dialog to the player.
> I think it's not the team's responsibility to do that. The team neither have the permission to decide what would be presented to the player. The latter target is just showing that the team has gone too far and stretched their hands too long.

You have made this point very clear multiple times already.
> Only the game's developer can choose to display that dialog to the player.

Again. Even in its current flawed state, the window bindings are easily disabled by the game's developer. This is a non-issue.
> The purpose of this PR is not to let user view the license easily, but to comply the licenses for law reasons. Putting the license in the install folder is already enough for complying the licenses.
> When I analyzed this in the PR comment area, nobody even replied on that. I don't know why I have to repeat those statements for so many times and you guys just keeps ignoring it. There's a lot of other more important ideas in the PR comment and this issue post, and they kept getting ignored.

I just don't agree. And I already answered. 

> I see conflicting arguments here. Detractors cannot complain that the current window isn't accessible by default on some platforms and suggest a solution with the same caveats.

And please, don't repeat statements just because you feel that "we guys just keep ignoring it". This is just adding more noise. That's what I think @Delsin-Yu meant by saying
> You have made this point very clear multiple times already.
> I just don't agree. And I already answered. 

You and your team have different opinions on what this PR is for. Please discuss the true purpose of that PR before continuing. Quote from Delsin-Yu:
> It all depends on the team's perspective. From the original PR, @Calinou mentioned the idea is to make the software comply with the license automatically, where in this discussion @adamscott believe we should ensure license available for players in-game as well, it'd be better if the team can have a conseus on the degree we want the license to be available, it also helps directing the discussion.

> And please, don't repeat statements just because you feel that "we guys just keep ignoring it". This is just adding more noise.

You did ignore my statements for multiple times and kept holding on things like "good open-source citizen" and "there are no better ways to implements this". But my point is that there is better way to implement this for both purpose of the team member's thought on that PR's purpose.

I'm going to implement it and let developers choose which one is better.
> You did ignore my statements for multiple times and kept holding on things like "good open-source citizen" and "there are no better ways to implements this". But my point is that there is better way to implement this for both purpose of the team member's thought on that PR's purpose.

I made myself clear that I don't think that just putting a license file in the install folder is enough to comply with the licences. So no, I didn't ignore any of your statements.
> > But my point is that there is better way to implement this for both purpose of the team member's thought on that PR's purpose.
> 
> I made myself clear that I don't think that just putting a license file in the install folder is enough to comply with the licences.

I and @Invium-GH already made clear that it is sufficient to comply with the licenses. There're real example of this instead of your "intent describing" idea.
Go checkout those games published by Nintendo themselves on Nintendo Switch. There're rarely in-game license windows. Those licenses are presented outside the game, in the settings menu provided by the console itself. It works almost the same as an accessible license file. Legal team at Nintendo surely knows about legal things better than us normal developers.

Also there're the editor solution which is clearly better, customizable and more respectful to the engine users.
I think this question is now up for the team and border engine developers & users.
> Go checkout those games published by Nintendo themselves on Nintendo Switch. There're rarely in-game license windows. Those licenses are presented outside the game, in the settings menu provided by the console itself.

You're talking apple and oranges. If there's a known section dedicated to license info of each game built-in by the OS, of course it's OK to put that info there and not in the game. Because it's a largely known fact that Nintendo Switch games work that way.

I don't think it's a largely known fact that you'll find the third-party license data in the install folder of a game. That's what I mean.

> I think this question is now up for the team and border engine developers & users.

I agree. I think @TML233, you made your points clear. There's no need to repeat them.
> > It's not widely known that you'll find the third-party license data in a game's install folder.
> 
> No, it's not largely known to players, but it is largely known to software and game development developers/companies.

It still ends up with how the team think of what the PR is for. We can hardly make progress on this topic before the team themselves made the purpose of the PR clear.
> I and @Invium-GH already made clear that it is sufficient to comply with the licenses. There're real example of this instead of your "intent describing" idea.

To be certain, I just parsed some of the installed games on my computer, old and new.

### Games with thirdparty licenses in their install directory
| Game | Has thirdparty licenses in their install directory |
| :--- | :--- |
| Caves of Qud | ☐ |
| DARK SOULS™: REMASTERED | ☐ |
| Tomb Raider I-III Remastered Starring Lara Croft | ☐ |
| CRUEL| ☐ |
| Command & Conquer™: Generals | ☐ |
| The Sims™ Legacy Collection | ☐ |
| METAL GEAR SOLID 3: Snake Eater | ☐ |
| Dwarf Fortress| ☑ <br><em>though it names in-game each thirdparty and tells users to read the SDL2 license in the install directory</em> |
| Mafia | ☐ |
| Hard Chip | ☐ |
| Shiren the Wanderer: The Mystery Dungeon of Serpentcoil Island | ☐ |
| Call of Duty 4: Modern Warfare (2007) | ☐ |
| F.E.A.R | ☐ |
| Vanquish | ☐ |
| Call of Duty (2003) | ☐ |
| Virtua Fighter 5 R.E.V.O | ☐ |
| Quake II | ☐ |
| Halo: The Master Chief Collection | ☐ |
| The Sims™ 2 Legacy Collection | ☐ |
| RoboCop: Rogue City | ☐ |
| Fallout 4 | ☐ |
| Super Monkey Ball Banana Mania | ☐ |
| Rogue | ☐ |
| Baldur's Gate 3 | ☐ |
| System Shock <em>(the remake)</em> | ☐ |
| Brotato | ☐ |
| Jet Set Radio | ☐ |
| Baldur's Gate: Enhanced Edition | ☐ |
| Vampire Survivors | ☐ |
| Worms Reloaded | ☐ |
| Quake | ☐ |
| Poly Bridge 2 | ☐ |
| shapez 2 | ☐ |
| Mars First Logistics | ☑ |
| Factorio | ☐ |
| Teenage Mutant Ninja Turtles: Shredder's Revenge | ☑ |
| Corn Kidz 64 | ☐ |
| Celeste | ☐ |

I don't think "real examples" are as clear as you say. Yes, some games do this, but it's not as widespread as suggested.

And I reiterate:
> But please, everyone, if you know legal precedents that state that just sharing a license file besides an executable is enough, I'll gladly agree with you. Until then, the current solution is a good (and safe) one.
![image](https://github.com/user-attachments/assets/6a2ef3ce-11e1-488a-aaad-81b791937c2d)
That looks great, but as the GDScript is an optional module, we might need another way to implement this.
> That looks great, but as the GDScript is an optional module, we might need another way to implement this.

I think this is for the fast prototyping projects, helping them comply with the license with zero effort. For a serious project or power users, they typically will have their own license dialog and won't even bother to auto-configure this dialog on project creation.

Fix patch:
diff --git a/core/input/input_map.cpp b/core/input/input_map.cpp
index 205b6b2c5768..c846a468d834 100644
--- a/core/input/input_map.cpp
+++ b/core/input/input_map.cpp
@@ -402,7 +402,6 @@ static const _BuiltinActionDisplayName _builtin_action_display_names[] = {
     { "ui_filedialog_show_hidden",                     TTRC("Show Hidden") },
     { "ui_swap_input_direction ",                      TTRC("Swap Input Direction") },
     { "ui_unicode_start",                              TTRC("Start Unicode Character Input") },
-    { "ui_toggle_licenses_dialog",                     TTRC("Toggle License Notices") },
     { "",                                              ""}
 	/* clang-format on */
 };
@@ -790,12 +789,6 @@ const HashMap<String, List<Ref<InputEvent>>> &InputMap::get_builtins() {
 	inputs.push_back(InputEventKey::create_reference(Key::QUOTELEFT | KeyModifierMask::CMD_OR_CTRL));
 	default_builtin_cache.insert("ui_swap_input_direction", inputs);
 
-	// ///// UI Misc Shortcuts /////
-
-	inputs = List<Ref<InputEvent>>();
-	inputs.push_back(InputEventKey::create_reference(Key::L | KeyModifierMask::CMD_OR_CTRL | KeyModifierMask::SHIFT));
-	default_builtin_cache.insert("ui_toggle_licenses_dialog", inputs);
-
 	return default_builtin_cache;
 }
 
diff --git a/doc/classes/ProjectSettings.xml b/doc/classes/ProjectSettings.xml
index af316ef82175..54baf6a242ec 100644
--- a/doc/classes/ProjectSettings.xml
+++ b/doc/classes/ProjectSettings.xml
@@ -1403,10 +1403,6 @@
 			Default [InputEventAction] to toggle [i]insert mode[/i] in a text field. While in insert mode, inserting new text overrides the character after the cursor, unless the next character is a new line.
 			[b]Note:[/b] Default [code]ui_*[/code] actions cannot be removed as they are necessary for the internal logic of several [Control]s. The events assigned to the action can however be modified.
 		</member>
-		<member name="input/ui_toggle_licenses_dialog" type="Dictionary" setter="" getter="">
-			Toggles the built-in dialog which displays Godot's third-party notices. This can also be toggled from a script using [member SceneTree.licenses_dialog_visible].
-			Since the default shortcut is not usable on mobile platforms, it is recommended to create a button that sets [member SceneTree.licenses_dialog_visible] to [code]true[/code] when pressed in your project's menu. See [url=$DOCS_URL/complying_with_licenses.html]Complying with licenses[/url] in the documentation for more information.
-		</member>
 		<member name="input/ui_undo" type="Dictionary" setter="" getter="">
 			Default [InputEventAction] to undo the most recent action.
 			[b]Note:[/b] Default [code]ui_*[/code] actions cannot be removed as they are necessary for the internal logic of several [Control]s. The events assigned to the action can however be modified.
diff --git a/doc/classes/SceneTree.xml b/doc/classes/SceneTree.xml
index 1b3c9201b230..77baef9d0898 100644
--- a/doc/classes/SceneTree.xml
+++ b/doc/classes/SceneTree.xml
@@ -255,9 +255,6 @@
 			The root of the scene currently being edited in the editor. This is usually a direct child of [member root].
 			[b]Note:[/b] This property does nothing in release builds.
 		</member>
-		<member name="licenses_dialog_visible" type="bool" setter="set_licenses_dialog_visible" getter="is_licenses_dialog_visible" default="false">
-			If [code]true[/code], shows the built-in dialog which displays Godot's third-party notices. This dialog can also be toggled by pressing the [member ProjectSettings.input/ui_toggle_licenses_dialog] built-in action. See [url=$DOCS_URL/complying_with_licenses.html]Complying with licenses[/url] in the documentation for more information.
-		</member>
 		<member name="multiplayer_poll" type="bool" setter="set_multiplayer_poll_enabled" getter="is_multiplayer_poll_enabled" default="true">
 			If [code]true[/code] (default value), enables automatic polling of the [MultiplayerAPI] for this SceneTree during [signal process_frame].
 			If [code]false[/code], you need to manually call [method MultiplayerAPI.poll] to process network packets and deliver RPCs. This allows running RPCs in a different loop (e.g. physics, thread, specific time step) and for manual [Mutex] protection when accessing the [MultiplayerAPI] from threads.
diff --git a/editor/icons/LicensesDialog.svg b/editor/icons/LicensesDialog.svg
deleted file mode 100644
index 77c55524d12d..000000000000
--- a/editor/icons/LicensesDialog.svg
+++ /dev/null
@@ -1,1 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16"><path fill="#8eef97" d="M1.3 12.362a1.041 1.041 0 0 0 0 1.465l.865.874a1.041 1.041 0 0 0 1.465 0l2.935-2.944a1.041 1.041 0 0 0 0-1.505l2.07-2.07 1.02 1.02a.38.38 0 0 0 .549 0l-.242.242a.784.784 0 0 0 0 1.1l.457.457a.784.784 0 0 0 1.097 0l3.3-3.3a.784.784 0 0 0 0-1.1l-.457-.457a.784.784 0 0 0-1.1 0l-.242.242a.38.38 0 0 0 0-.549l-2.815-2.815a.38.38 0 0 0-.549 0l.242-.242a.784.784 0 0 0 0-1.1l-.457-.457a.784.784 0 0 0-1.1 0l-3.3 3.3a.784.784 0 0 0 0 1.1l.457.457a.784.784 0 0 0 1.1 0l.242-.242a.38.38 0 0 0 0 .55l1.019 1.02-2.07 2.07a1.041 1.041 0 0 0-1.553 0z"/></svg>
\ No newline at end of file
diff --git a/scene/gui/licenses_dialog.cpp b/scene/gui/licenses_dialog.cpp
deleted file mode 100644
index 95652f7be0c2..000000000000
--- a/scene/gui/licenses_dialog.cpp
+++ /dev/null
@@ -1,150 +0,0 @@
-/**************************************************************************/
-/*  licenses_dialog.cpp                                                   */
-/**************************************************************************/
-/*                         This file is part of:                          */
-/*                             GODOT ENGINE                               */
-/*                        https://godotengine.org                         */
-/**************************************************************************/
-/* Copyright (c) 2014-present Godot Engine contributors (see AUTHORS.md). */
-/* Copyright (c) 2007-2014 Juan Linietsky, Ariel Manzur.                  */
-/*                                                                        */
-/* Permission is hereby granted, free of charge, to any person obtaining  */
-/* a copy of this software and associated documentation files (the        */
-/* "Software"), to deal in the Software without restriction, including    */
-/* without limitation the rights to use, copy, modify, merge, publish,    */
-/* distribute, sublicense, and/or sell copies of the Software, and to     */
-/* permit persons to whom the Software is furnished to do so, subject to  */
-/* the following conditions:                                              */
-/*                                                                        */
-/* The above copyright notice and this permission notice shall be         */
-/* included in all copies or substantial portions of the Software.        */
-/*                                                                        */
-/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,        */
-/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF     */
-/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. */
-/* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY   */
-/* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,   */
-/* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE      */
-/* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.                 */
-/**************************************************************************/
-
-#include "licenses_dialog.h"
-
-#include "core/license.gen.h"
-#include "core/string/string_buffer.h"
-#include "scene/gui/box_container.h"
-#include "scene/gui/button.h"
-#include "scene/gui/label.h"
-#include "scene/gui/margin_container.h"
-#include "scene/gui/panel_container.h"
-#include "scene/gui/rich_text_label.h"
-#include "scene/main/canvas_item.h"
-#include "scene/resources/style_box_flat.h"
-
-void LicensesDialog::_close_button_pressed() {
-	SceneTree::get_singleton()->set_licenses_dialog_visible(false);
-}
-
-void LicensesDialog::unhandled_key_input(const Ref<InputEvent> &p_event) {
-	if (p_event->is_action_pressed(SNAME("ui_cancel"), false, true)) {
-		SceneTree::get_singleton()->set_licenses_dialog_visible(false);
-		Node::get_viewport()->set_input_as_handled();
-	}
-}
-
-LicensesDialog::LicensesDialog() {
-	// Set on the highest layer, so that nothing else can draw on top.
-	set_layer(128);
-
-	// Keep UI interactions functional even if the game is paused.
-	set_process_mode(Node::PROCESS_MODE_ALWAYS);
-
-	set_process_unhandled_key_input(true);
-
-	MarginContainer *margin_container = memnew(MarginContainer);
-	margin_container->set_anchors_preset(Control::PRESET_FULL_RECT);
-	const float default_base_scale = margin_container->get_theme_default_base_scale();
-	const float default_font_size = margin_container->get_theme_default_font_size();
-	margin_container->add_theme_constant_override("margin_top", Math::round(20 * default_base_scale));
-	margin_container->add_theme_constant_override("margin_right", Math::round(20 * default_base_scale));
-	margin_container->add_theme_constant_override("margin_bottom", Math::round(20 * default_base_scale));
-	margin_container->add_theme_constant_override("margin_left", Math::round(20 * default_base_scale));
-	add_child(margin_container);
-
-	PanelContainer *panel_container = memnew(PanelContainer);
-	margin_container->add_child(panel_container);
-
-	MarginContainer *inner_margin_container = memnew(MarginContainer);
-	inner_margin_container->add_theme_constant_override("margin_top", Math::round(10 * default_base_scale));
-	inner_margin_container->add_theme_constant_override("margin_right", Math::round(10 * default_base_scale));
-	inner_margin_container->add_theme_constant_override("margin_bottom", Math::round(10 * default_base_scale));
-	inner_margin_container->add_theme_constant_override("margin_left", Math::round(10 * default_base_scale));
-	panel_container->add_child(inner_margin_container);
-
-	VBoxContainer *vbox_container = memnew(VBoxContainer);
-	vbox_container->add_theme_constant_override("separation", Math::round(10 * default_base_scale));
-	inner_margin_container->add_child(vbox_container);
-
-	Label *title_label = memnew(Label);
-	title_label->set_text(RTR("Third-party notices"));
-	title_label->add_theme_font_size_override(SceneStringName(font_size), Math::round(1.333 * default_font_size));
-	title_label->set_horizontal_alignment(HORIZONTAL_ALIGNMENT_CENTER);
-	vbox_container->add_child(title_label);
-
-	// Based on `editor_about.cpp` with references to TreeItem removed,
-	// as we only have the "All Components" view here. A preamble is also added.
-	StringBuffer<> long_text;
-	long_text += RTR("This project is powered by Godot Engine, which relies on a number of third-party free and open source libraries, all compatible with the terms of its MIT license. The following is an exhaustive list of all such third-party components with their respective copyright statements and license terms.") + "\n\n";
-
-	long_text += RTR("Components:") + "\n\n";
-
-	for (int component_index = 0; component_index < COPYRIGHT_INFO_COUNT; component_index++) {
-		const ComponentCopyright &component = COPYRIGHT_INFO[component_index];
-		const String component_name = String::utf8(component.name);
-		long_text += "- " + component_name;
-		for (int part_index = 0; part_index < component.part_count; part_index++) {
-			const ComponentCopyrightPart &part = component.parts[part_index];
-			String copyright;
-			for (int copyright_index = 0; copyright_index < part.copyright_count; copyright_index++) {
-				copyright += String::utf8("\n    \xc2\xa9 ") + String::utf8(part.copyright_statements[copyright_index]);
-			}
-			long_text += copyright;
-			String license = "\n    License: " + String::utf8(part.license) + "\n";
-			long_text += license + "\n\n";
-		}
-	}
-
-	long_text += RTR("Licenses:") + "\n\n";
-
-	for (int i = 0; i < LICENSE_COUNT; i++) {
-		const String licensename = String::utf8(LICENSE_NAMES[i]);
-		long_text += "- " + licensename + "\n";
-		const String licensebody = String::utf8(LICENSE_BODIES[i]);
-		long_text += "    " + licensebody.replace("\n", "\n    ") + "\n\n";
-	}
-
-	RichTextLabel *rich_text_label = memnew(RichTextLabel);
-	rich_text_label->set_text(long_text);
-	rich_text_label->set_threaded(true);
-	rich_text_label->set_v_size_flags(Control::SIZE_EXPAND_FILL);
-	rich_text_label->set_focus_mode(Control::FOCUS_ALL);
-	rich_text_label->add_theme_font_size_override("normal_font_size", Math::round(0.75 * default_font_size));
-
-	// Add a background to the scrollable area with the license text.
-	Ref<StyleBoxFlat> background;
-	background.instantiate();
-	background->set_bg_color(Color(0, 0, 0, 0.5));
-	background->set_content_margin_all(Math::round(10 * default_base_scale));
-	rich_text_label->add_theme_style_override(CoreStringName(normal), background);
-
-	vbox_container->add_child(rich_text_label);
-	// Allow for keyboard navigation by grabbing focus immediately on the scrollable control.
-	callable_mp((Control *)rich_text_label, &Control::grab_focus).call_deferred();
-
-	Button *close_button = memnew(Button);
-	close_button->set_text(RTR("Close"));
-	close_button->set_h_size_flags(Control::SIZE_SHRINK_CENTER);
-	close_button->set_custom_minimum_size(Vector2(100, 40) * default_base_scale);
-	close_button->connect(SceneStringName(pressed), callable_mp(this, &LicensesDialog::_close_button_pressed));
-	vbox_container->add_child(close_button);
-}
diff --git a/scene/gui/licenses_dialog.h b/scene/gui/licenses_dialog.h
deleted file mode 100644
index 1b295b8080b4..000000000000
--- a/scene/gui/licenses_dialog.h
+++ /dev/null
@@ -1,45 +0,0 @@
-/**************************************************************************/
-/*  licenses_dialog.h                                                     */
-/**************************************************************************/
-/*                         This file is part of:                          */
-/*                             GODOT ENGINE                               */
-/*                        https://godotengine.org                         */
-/**************************************************************************/
-/* Copyright (c) 2014-present Godot Engine contributors (see AUTHORS.md). */
-/* Copyright (c) 2007-2014 Juan Linietsky, Ariel Manzur.                  */
-/*                                                                        */
-/* Permission is hereby granted, free of charge, to any person obtaining  */
-/* a copy of this software and associated documentation files (the        */
-/* "Software"), to deal in the Software without restriction, including    */
-/* without limitation the rights to use, copy, modify, merge, publish,    */
-/* distribute, sublicense, and/or sell copies of the Software, and to     */
-/* permit persons to whom the Software is furnished to do so, subject to  */
-/* the following conditions:                                              */
-/*                                                                        */
-/* The above copyright notice and this permission notice shall be         */
-/* included in all copies or substantial portions of the Software.        */
-/*                                                                        */
-/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,        */
-/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF     */
-/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. */
-/* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY   */
-/* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,   */
-/* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE      */
-/* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.                 */
-/**************************************************************************/
-
-#pragma once
-
-#include "scene/main/canvas_layer.h"
-
-class LicensesDialog : public CanvasLayer {
-	GDCLASS(LicensesDialog, CanvasLayer);
-
-	void _close_button_pressed();
-
-protected:
-	virtual void unhandled_key_input(const Ref<InputEvent> &p_event) override;
-
-public:
-	LicensesDialog();
-};
diff --git a/scene/main/scene_tree.cpp b/scene/main/scene_tree.cpp
index 3ffbd771a158..4043eb55ac96 100644
--- a/scene/main/scene_tree.cpp
+++ b/scene/main/scene_tree.cpp
@@ -41,7 +41,6 @@
 #include "scene/animation/tween.h"
 #include "scene/debugger/scene_debugger.h"
 #include "scene/gui/control.h"
-#include "scene/gui/licenses_dialog.h"
 #include "scene/main/multiplayer_api.h"
 #include "scene/main/viewport.h"
 #include "scene/resources/environment.h"
@@ -1698,36 +1697,6 @@ bool SceneTree::is_multiplayer_poll_enabled() const {
 	return multiplayer_poll;
 }
 
-void SceneTree::set_licenses_dialog_visible(bool p_visible) {
-	if (p_visible) {
-		if (licenses_dialog == nullptr) {
-			licenses_dialog = memnew(LicensesDialog);
-			// Begin name with an underscore to avoid conflict with project nodes.
-			licenses_dialog->set_name("_LicensesDialog");
-			get_root()->add_child(licenses_dialog, false, Node::INTERNAL_MODE_BACK);
-		} else {
-			ERR_PRINT("Licenses dialog already exists.");
-		}
-	} else {
-		if (licenses_dialog != nullptr) {
-			// Free when closing to avoid reserving memory during the project's run duration.
-			licenses_dialog->queue_free();
-			licenses_dialog = nullptr;
-		} else {
-			ERR_PRINT("Couldn't find licenses dialog to hide.");
-		}
-	}
-}
-
-bool SceneTree::is_licenses_dialog_visible() const {
-	if (licenses_dialog) {
-		return licenses_dialog->is_visible();
-	}
-
-	// Licenses dialog isn't created yet. Therefore, it's not visible.
-	return false;
-}
-
 void SceneTree::_bind_methods() {
 	ClassDB::bind_method(D_METHOD("get_root"), &SceneTree::get_root);
 	ClassDB::bind_method(D_METHOD("has_group", "name"), &SceneTree::has_group);
@@ -1802,9 +1771,6 @@ void SceneTree::_bind_methods() {
 	ClassDB::bind_method(D_METHOD("set_multiplayer_poll_enabled", "enabled"), &SceneTree::set_multiplayer_poll_enabled);
 	ClassDB::bind_method(D_METHOD("is_multiplayer_poll_enabled"), &SceneTree::is_multiplayer_poll_enabled);
 
-	ClassDB::bind_method(D_METHOD("set_licenses_dialog_visible", "visible"), &SceneTree::set_licenses_dialog_visible);
-	ClassDB::bind_method(D_METHOD("is_licenses_dialog_visible"), &SceneTree::is_licenses_dialog_visible);
-
 	ADD_PROPERTY(PropertyInfo(Variant::BOOL, "auto_accept_quit"), "set_auto_accept_quit", "is_auto_accept_quit");
 	ADD_PROPERTY(PropertyInfo(Variant::BOOL, "quit_on_go_back"), "set_quit_on_go_back", "is_quit_on_go_back");
 	ADD_PROPERTY(PropertyInfo(Variant::BOOL, "debug_collisions_hint"), "set_debug_collisions_hint", "is_debugging_collisions_hint");
@@ -1816,7 +1782,6 @@ void SceneTree::_bind_methods() {
 	ADD_PROPERTY(PropertyInfo(Variant::OBJECT, "root", PROPERTY_HINT_RESOURCE_TYPE, "Node", PROPERTY_USAGE_NONE), "", "get_root");
 	ADD_PROPERTY(PropertyInfo(Variant::BOOL, "multiplayer_poll"), "set_multiplayer_poll_enabled", "is_multiplayer_poll_enabled");
 	ADD_PROPERTY(PropertyInfo(Variant::BOOL, "physics_interpolation"), "set_physics_interpolation_enabled", "is_physics_interpolation_enabled");
-	ADD_PROPERTY(PropertyInfo(Variant::BOOL, "licenses_dialog_visible"), "set_licenses_dialog_visible", "is_licenses_dialog_visible");
 
 	ADD_SIGNAL(MethodInfo("tree_changed"));
 	ADD_SIGNAL(MethodInfo("tree_process_mode_changed")); //editor only signal, but due to API hash it can't be removed in run-time
diff --git a/scene/main/scene_tree.h b/scene/main/scene_tree.h
index 9803dbe3e546..6233518a5d82 100644
--- a/scene/main/scene_tree.h
+++ b/scene/main/scene_tree.h
@@ -43,7 +43,6 @@ class Node;
 #ifndef _3D_DISABLED
 class Node3D;
 #endif
-class LicensesDialog;
 class Window;
 class Material;
 class Mesh;
@@ -191,9 +190,6 @@ class SceneTree : public MainLoop {
 	Node *prev_scene = nullptr;
 	Node *pending_new_scene = nullptr;
 
-	// Initialized lazily and destroyed eagerly to decrease RAM usage, since it contains a lot of text.
-	LicensesDialog *licenses_dialog = nullptr;
-
 	Color debug_collisions_color;
 	Color debug_collision_contact_color;
 	Color debug_paths_color;
@@ -433,9 +429,6 @@ class SceneTree : public MainLoop {
 	void set_multiplayer_poll_enabled(bool p_enabled);
 	bool is_multiplayer_poll_enabled() const;
 
-	void set_licenses_dialog_visible(bool p_visible);
-	bool is_licenses_dialog_visible() const;
-
 	static void add_idle_callback(IdleCallback p_callback);
 
 	void set_disable_node_threading(bool p_disable);
diff --git a/scene/main/viewport.cpp b/scene/main/viewport.cpp
index bf04dc0f4d4e..06e71563ccaf 100644
--- a/scene/main/viewport.cpp
+++ b/scene/main/viewport.cpp
@@ -2161,10 +2161,6 @@ void Viewport::_gui_input_event(Ref<InputEvent> p_event) {
 			}
 		}
 
-		if (!Engine::get_singleton()->is_editor_hint() && !Engine::get_singleton()->is_project_manager_hint() && p_event->is_action_pressed("ui_toggle_licenses_dialog")) {
-			SceneTree::get_singleton()->set_licenses_dialog_visible(!SceneTree::get_singleton()->is_licenses_dialog_visible());
-		}
-
 		if (gui.key_focus && !gui.key_focus->is_visible_in_tree()) {
 			gui.key_focus->release_focus();
 		}


Test patch: