Re: NVDA add-ons resources differences?


 

Hi all,

Some answers:

  • Review required: in the past, basic review (license and copyright, security, user experience, documentation, NVDA compatibility) was needed to introduce new add-ons to the community add-ons website (all five parts must pass). Although it had the advantage of letting the community know that the add-on was okay to use, an obvious downside was that only several members reviewed new add-ons (in the beginning add-on updates too were reviewed, which was since relaxed to review only new add-ons). This has changed recently so that add-ons can be introduced to the website (eventually through a store) if a description is given, add-on link is published and working, and does not dodge NVDA compatibility statements (for instance, if an add-on declares compatibility with a version of NVDA not in circulation, it will not be accepted). Therefore, add-on reviews are encouraged but are not required (think of NVDA Advanced OCR add-on - it made its debut a few days ago, and developers provided a description and a download link here; ideally new add-on intros (add-on name, author, description, download link, source code repository if it exists, NVDA compatibility info) would appear on NVDA add-ons list first so interested members can review and comment while the add-on is registered if developers say yes). This change was made in preparation for a store process (discussed below).
  • Store submission process: although not formalized yet, the process involved in distributing add-ons through a future store uses pull requests. An add-on author would submit new or updated add-on release metadata through a pull request, which will be accepted and made visible to add-on store clients (including NVDA). There are things taking place behind the scenes, but details are still yet to be determined (since store submission process was drafted by NV Access and add-ons community with NV Access taking primary responsibilities, it is up to NV Access to finalize things when they are ready).
  • Add-on distribution process, then and now: until early 2021 I (Joseph Lee) served as primary maintainer of add-on files database (the database itself was created in 2013 to host download links for add-ons on the community add-ons website). Whenever new add-ons were introduced (passed the basic review then) or updated, I would log onto add-on files repository and update the database. In 2021, as part of add-on store proposal, I and NV Access staff agreed to use pull requests for add-on submission process. As a result, NV Access manages add-on files database, with add-on authors submitting pull requests whenever folks need to add or update add-ons. Currently, an add-on author would submit a pull request when add-on updates are released, with another add-on author reviewing the pull request (the pull request consists of two parts: the new add-on download link, and updated add-on metadata). After the second add-on author (not the person who developed the updated add-on) reviews add-on metadata, NV Access staff would certify the update by approving the pull request and making the new add-on download link available by updating add-on files database (the entire process of creating a pull request, review from an add-on author, NV Access certification, updating add-on files database) is what I call "queueing for distribution"). The goal of the 2021 process is to test add-on store submission process, with the whole thing being automated and simplified by the time the add-on store becomes reality - that is, after creating a pull request to register new or updated add-ons, add-on store workflow will do its magic and make the new and/or updated add-ons available for you within minutes compared to hours as of now.
  • Add-ons from other sources: you are welcome to install add-ons from sources other than community add-ons website. Note that NVDA may block add-on installation if it determines the add-on is not compatible based on add-on manifest information. You can "overcome" this by editing the manifest, but I strongly discourage this (unless this is the last resort) as add-on modules themselves might be using code that's changed or removed from NVDA itself. This is the reason why members of the add-ons list are informed about changes that can have impact on add-ons.
  • What about add-on security: there is potential for malicious activity by add-ons as add-ons (and for that matter, NVDA) is written in Python. The add-ons community takes security seriously and we take action if told an add-on is not doing what it says it does (folks do provide comment on add-on source code from time to time). Security is the reason why NVDA itself has a "secure" mode where access to the file system, logs, add-ons manager, and updates are restricted or disallowed, and add-ons do check for "secure" flag and exit if NVDA is operating in this mode (unless the add-on author and/or source code says otherwise). Ultimately, add-on security depends on human attitudes (add-on author, community members, and ultimately, users).
  • Can folks propose add-ons for community distribution: of course. For old add-ons, please test them with latest NVDA stable release (2021.3.1) to make sure they are compatible, and if not, either modify the add-on or set compatibility to the oldest supported NVDA release. This is more so if an add-on was not maintained past 2019 and is written in Python 2; although the community does not have an official word on Python 2, in January 2022 add-on development guide (to be discussed on add-ons list) will state that Python 3 is required, and consequently, NVDA 2019.3 or later.
  • What about add-on licensing: what I say should be taken with a grain of salt as I'm not a lawyer. Add-ons community had a debate about this for a while. The consensus seems to be that any part of an add-on that directly touches NVDA screen reader (namely calling functions and inheriting classes from NVDA) must be licensed under GNU General Public license version 2 as these parts are derived works of NVDA. NV Access does state two exceptions in their license document: code included with add-ons (called "plugins" and "drivers" in the document) with a different license (including proprietary code), and Microsoft redistributable modules; in case of the add-on exception, as long as the component that uses something licensed differently still allows the parent add-on to be licensed under GPL 2 and does not use NVDA code and/or used by NVDA, it can be included. For example, Resource Monitor, an add-on that uses NVDA code, is licensed under GPL 2; this add-on relies on psutil, a Python library licensed under 3-Clause BSD (Berkeley Software Distribution) license compatible with GPL, therefore psutil can be used in this add-on. If an add-on author has doubts about license terms of components to be used in an add-on, do ask for advice on add-ons list and/or look up compatibility between the component licenses and GPL.

In closing, let me clarify that I am not an employee of NV Access, nor am paid to maintain add-ons infrastructure for them. Hope this helps.

Cheers,

Joseph

Join nvda@nvda.groups.io to automatically receive all group messages.