License acceptance dialog when installing an add-on

[tseykovets]

NVDA Add-ons are isolated software with the properties of a separate object of copyright.
Add-ons may contain components that are distributed under license terms that are fundamentally different from the NVDA license. For example, this is very common in the case of third-party speech synthesizers (especially commercial speech synthesizers).
All this makes it necessary to explicitly inform the user about the license of the add-on and obtain from him a clear acceptance of this license.
In this regard, it is proposed to consider the following feature request:

• Add support for the licenseFileName parameter to the add-on manifest file. This parameter must refer to a text file (encoding UTF-8) containing the add-on's license.
• The licenseFileName parameter should be treated similarly to the docFileName parameter. That is, first look for the specified file in the active localization directory, and if there is no then look in the default localization directory.
• If the licenseFileName parameter has a value then when installing the add-on, the user should be shown a license acceptance dialog.
• The dialog should have the title "License agreement" and contain a read-only edit field with the text of the license, a button labeled "I accept the agreement" and a button labeled "I do not accept the agreement". Pressing the first button starts the add-on installation, pressing the second button closes the installation wizard.
• Copying add-on files to a *.pendingInstall directory and calling the onInstall() function from the installTasks.py file should occur only after pressing the "I accept the agreement" button.

Issues Needing Further Analysis

• Should a license acceptance dialog be shown when manual updating an add-on?
  Since the text of the license may well change,, it seems that asking for user consent is required even if updating an already installed add-on.
• Should a license acceptance dialog be shown when automatic updating an add-on (e.g., in the context of a developing add-on store)?
  Yes, the request to accept a license for each add-on when automatically updating a large number of add-ons looks cumbersome, but in this case, the remark about the possibility of changing the license text is also true. It may make sense to add a setting to automatically accept licenses during automatic updates, but by default, ask for accept a license for each add-on.

Note

This improvement is desirable to implement in the NVDA version with the loss of add-on compatibility. That is, 2023.1 is suitable from the nearest ones.

[josephsl]

Hi,

I think it should be implemented when installing the add-on for the first time or when the license file changes for some reason. At the store level, I think it makes sense to present the license dialog before downloading the add-on package via the store mechanism.

I think the "license" flag should be optional - not all add-ons ship with components that are not licensed the same as NVDA itself (GNU GPL 2). The store mechanism itself will record add-on license (GPL2, for example), and it might be possible to let NVDA retrieve the license file from somewhere in the add-on code repository itself before downloading the package via store. Also, making the license flag optional allows the implementation to happen at anytime without loss of compatibility.

As for scheduling this for 2023.1, I think it is late at this point - beta 1 release can happen at any moment.

Thanks.

[tseykovets]

Hi Joseph,

I think it should be implemented when installing the add-on for the first time or when the license file changes for some reason.

To do this, some mechanism is needed to determine that the text of the license has changed.
NVDA can compare the checksum of license files of old and new versions of the add-on and only show the dialog if the checksums are not equal.

I think the "license" flag should be optional

I agree with this and also implied it. Maybe I didn't describe it clearly enough in the third point of the feature request.

As for scheduling this for 2023.1, I think it is late at this point - beta 1 release can happen at any moment.

If the parameter is optional then the aspect of release with loss of compatibility is not so important.
Although implementing this parameter in a release with loss of compatibility would motivate add-on developers to add their licenses through this new mechanism.

Thank you for your opinion.