Change in add-ons review policies #AdminNotice


Noelia Ruiz
 

Hello:

After a discussion with NV Access, I've received their agreement to
change the review processes, according with current requirements set
for the addonFiles repo:

https://github.com/nvaccess/addonFiles

Since the add-on store is in progress and human reviews won't be
required, they accept to change the review policy accordingly. I'll
document it in a few hours at

https://addons.nvda-project.org/processes.en.html

Of course, this doesn't mean that human and code review is not
important. We should encourage users to provide feedback and also
promote code reviews, useful contributions in pull requests and so on.
Comments are appreciated, so I want to inform before proceeding to
document this.

Requirements will be:

1. The provided link in addonFiles must work.
2. Never try to post add-ons by-passing the security mechanism set in
NVDA about compatibility:

https://github.com/nvaccess/addonfiles

Kind regards


Noelia Ruiz
 

Hi again:

Providing more info about this, I'll also change the content of the
main page of the add-ons website:

https://addons.nvda-project.org, and other pages that don't match the
current review process, that is, I'll clarify that code review is not
required for add-ons to be posted on the website. Requirements are,
for now:

A pull request must be created against addonFiles repo, and reviewers
will follow the process described at

https://github.com/nvaccess/addonFiles


In the document dedicated to review processes I'll copy these
requirements and, additionally, I will add references to the add-on
store submission repo
Kind regards



2021-10-04 6:38 GMT+02:00, Noelia Ruiz via groups.io
<nrm1977=gmail.com@groups.io>:

Hello:

After a discussion with NV Access, I've received their agreement to
change the review processes, according with current requirements set
for the addonFiles repo:

https://github.com/nvaccess/addonFiles

Since the add-on store is in progress and human reviews won't be
required, they accept to change the review policy accordingly. I'll
document it in a few hours at

https://addons.nvda-project.org/processes.en.html

Of course, this doesn't mean that human and code review is not
important. We should encourage users to provide feedback and also
promote code reviews, useful contributions in pull requests and so on.
Comments are appreciated, so I want to inform before proceeding to
document this.

Requirements will be:

1. The provided link in addonFiles must work.
2. Never try to post add-ons by-passing the security mechanism set in
NVDA about compatibility:

https://github.com/nvaccess/addonfiles

Kind regards






Sukil Etxenike
 

Hi,

I have mixed feelings about this change. On the one hand, it means that add-ons will be accepted faster, but on the other hand that someone with malicious intention can release a harmful add-on that will get released without any checks.

(We must considder also the pace at which reviews are made, of which I am to blame too, as I haven't reviewed any add-on).

Thanks,
Sukil

El 04/10/2021 a las 8:19, Noelia Ruiz escribió:
Hi again:

Providing more info about this, I'll also change the content of the
main page of the add-ons website:

https://addons.nvda-project.org, and other pages that don't match the
current review process, that is, I'll clarify that code review is not
required for add-ons to be posted on the website. Requirements are,
for now:

A pull request must be created against addonFiles repo, and reviewers
will follow the process described at

https://github.com/nvaccess/addonFiles


In the document dedicated to review processes I'll copy these
requirements and, additionally, I will add references to the add-on
store submission repo
Kind regards



2021-10-04 6:38 GMT+02:00, Noelia Ruiz via groups.io
<nrm1977=gmail.com@groups.io>:
Hello:

After a discussion with NV Access, I've received their agreement to
change the review processes, according with current requirements set
for the addonFiles repo:

https://github.com/nvaccess/addonFiles

Since the add-on store is in progress and human reviews won't be
required, they accept to change the review policy accordingly. I'll
document it in a few hours at

https://addons.nvda-project.org/processes.en.html

Of course, this doesn't mean that human and code review is not
important. We should encourage users to provide feedback and also
promote code reviews, useful contributions in pull requests and so on.
Comments are appreciated, so I want to inform before proceeding to
document this.

Requirements will be:

1. The provided link in addonFiles must work.
2. Never try to post add-ons by-passing the security mechanism set in
NVDA about compatibility:

https://github.com/nvaccess/addonfiles

Kind regards







Noelia Ruiz
 

Hello, I have mixed feelings too. But, since in the add-on store code
reviews won't be required, and since they are 5 pending reviews
(including your add-on, though it has feedback), and since they are
just a few people completing formal basic review, and also since some
add-ons require specialized reviewers, for example users of Chinese
keyboards, but especially considering the fact that the store won't
require code reviews, I've maintained this discussion with NV Access
and with notification to other admins of this list.
Anyway, at least from my part, if I see a malicious add-on, I won't
approve the pull request sent to add-on files, and I think we should
notify about malicious add-ons even if they are accepted in the store,
and should try to provide feedback to authors, and as add-on
developers we should try to send just reliable add-ons, trying to test
them locally, use GitHub Actions or other mechanisms to provide code
that other reviewers can understand, linting the code, checking for
comments for translators with GitHub Actions etc. These are personal
advices that I try to follow.
Cheers

2021-10-04 11:22 GMT+02:00, Sukil Etxenike via groups.io
<sukiletxe=yahoo.es@groups.io>:

Hi,

I have mixed feelings about this change. On the one hand, it means that
add-ons will be accepted faster, but on the other hand that someone with
malicious intention can release a harmful add-on that will get released
without any checks.

(We must considder also the pace at which reviews are made, of which I
am to blame too, as I haven't reviewed any add-on).

Thanks,
Sukil


El 04/10/2021 a las 8:19, Noelia Ruiz escribió:
Hi again:

Providing more info about this, I'll also change the content of the
main page of the add-ons website:

https://addons.nvda-project.org, and other pages that don't match the
current review process, that is, I'll clarify that code review is not
required for add-ons to be posted on the website. Requirements are,
for now:

A pull request must be created against addonFiles repo, and reviewers
will follow the process described at

https://github.com/nvaccess/addonFiles


In the document dedicated to review processes I'll copy these
requirements and, additionally, I will add references to the add-on
store submission repo
Kind regards



2021-10-04 6:38 GMT+02:00, Noelia Ruiz via groups.io
<nrm1977=gmail.com@groups.io>:
Hello:

After a discussion with NV Access, I've received their agreement to
change the review processes, according with current requirements set
for the addonFiles repo:

https://github.com/nvaccess/addonFiles

Since the add-on store is in progress and human reviews won't be
required, they accept to change the review policy accordingly. I'll
document it in a few hours at

https://addons.nvda-project.org/processes.en.html

Of course, this doesn't mean that human and code review is not
important. We should encourage users to provide feedback and also
promote code reviews, useful contributions in pull requests and so on.
Comments are appreciated, so I want to inform before proceeding to
document this.

Requirements will be:

1. The provided link in addonFiles must work.
2. Never try to post add-ons by-passing the security mechanism set in
NVDA about compatibility:

https://github.com/nvaccess/addonfiles

Kind regards












 

Well We don't want another blind extra on here, that really busts our reputation.

There is a reputation in some places that we break addons for no reason except to get on the whick of users.

We don't need those especially on audiogames with more amunition and those same people would be vary happy to spread rumors about the new nvda virus about because there are a lot of trolls on there.

Most users on there are not trolls but they are some about.

On 4/10/2021 10:36 pm, Noelia Ruiz wrote:
Hello, I have mixed feelings too. But, since in the add-on store code
reviews won't be required, and since they are 5 pending reviews
(including your add-on, though it has feedback), and since they are
just a few people completing formal basic review, and also since some
add-ons require specialized reviewers, for example users of Chinese
keyboards, but especially considering the fact that the store won't
require code reviews, I've maintained this discussion with NV Access
and with notification to other admins of this list.
Anyway, at least from my part, if I see a malicious add-on, I won't
approve the pull request sent to add-on files, and I think we should
notify about malicious add-ons even if they are accepted in the store,
and should try to provide feedback to authors, and as add-on
developers we should try to send just reliable add-ons, trying to test
them locally, use GitHub Actions or other mechanisms to provide code
that other reviewers can understand, linting the code, checking for
comments for translators with GitHub Actions etc. These are personal
advices that I try to follow.
Cheers

2021-10-04 11:22 GMT+02:00, Sukil Etxenike via groups.io
<sukiletxe=yahoo.es@groups.io>:
Hi,

I have mixed feelings about this change. On the one hand, it means that
add-ons will be accepted faster, but on the other hand that someone with
malicious intention can release a harmful add-on that will get released
without any checks.

(We must considder also the pace at which reviews are made, of which I
am to blame too, as I haven't reviewed any add-on).

Thanks,
Sukil


El 04/10/2021 a las 8:19, Noelia Ruiz escribió:
Hi again:

Providing more info about this, I'll also change the content of the
main page of the add-ons website:

https://addons.nvda-project.org, and other pages that don't match the
current review process, that is, I'll clarify that code review is not
required for add-ons to be posted on the website. Requirements are,
for now:

A pull request must be created against addonFiles repo, and reviewers
will follow the process described at

https://github.com/nvaccess/addonFiles


In the document dedicated to review processes I'll copy these
requirements and, additionally, I will add references to the add-on
store submission repo
Kind regards



2021-10-04 6:38 GMT+02:00, Noelia Ruiz via groups.io
<nrm1977=gmail.com@groups.io>:
Hello:

After a discussion with NV Access, I've received their agreement to
change the review processes, according with current requirements set
for the addonFiles repo:

https://github.com/nvaccess/addonFiles

Since the add-on store is in progress and human reviews won't be
required, they accept to change the review policy accordingly. I'll
document it in a few hours at

https://addons.nvda-project.org/processes.en.html

Of course, this doesn't mean that human and code review is not
important. We should encourage users to provide feedback and also
promote code reviews, useful contributions in pull requests and so on.
Comments are appreciated, so I want to inform before proceeding to
document this.

Requirements will be:

1. The provided link in addonFiles must work.
2. Never try to post add-ons by-passing the security mechanism set in
NVDA about compatibility:

https://github.com/nvaccess/addonfiles

Kind regards











 

Hi all,
At least a compromise would be that people should at least give folks an intro about an add-on before posting new ones via Add-on Store/add-on files repo.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Shaun Everiss
Sent: Monday, October 4, 2021 10:06 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Well We don't want another blind extra on here, that really busts our reputation.

There is a reputation in some places that we break addons for no reason except to get on the whick of users.

We don't need those especially on audiogames with more amunition and those same people would be vary happy to spread rumors about the new nvda virus about because there are a lot of trolls on there.

Most users on there are not trolls but they are some about.



On 4/10/2021 10:36 pm, Noelia Ruiz wrote:
Hello, I have mixed feelings too. But, since in the add-on store code
reviews won't be required, and since they are 5 pending reviews
(including your add-on, though it has feedback), and since they are
just a few people completing formal basic review, and also since some
add-ons require specialized reviewers, for example users of Chinese
keyboards, but especially considering the fact that the store won't
require code reviews, I've maintained this discussion with NV Access
and with notification to other admins of this list.
Anyway, at least from my part, if I see a malicious add-on, I won't
approve the pull request sent to add-on files, and I think we should
notify about malicious add-ons even if they are accepted in the store,
and should try to provide feedback to authors, and as add-on
developers we should try to send just reliable add-ons, trying to test
them locally, use GitHub Actions or other mechanisms to provide code
that other reviewers can understand, linting the code, checking for
comments for translators with GitHub Actions etc. These are personal
advices that I try to follow.
Cheers

2021-10-04 11:22 GMT+02:00, Sukil Etxenike via groups.io
<sukiletxe=yahoo.es@groups.io>:
Hi,

I have mixed feelings about this change. On the one hand, it means
that add-ons will be accepted faster, but on the other hand that
someone with malicious intention can release a harmful add-on that
will get released without any checks.

(We must considder also the pace at which reviews are made, of which
I am to blame too, as I haven't reviewed any add-on).

Thanks,
Sukil


El 04/10/2021 a las 8:19, Noelia Ruiz escribió:
Hi again:

Providing more info about this, I'll also change the content of the
main page of the add-ons website:

https://addons.nvda-project.org, and other pages that don't match
the current review process, that is, I'll clarify that code review
is not required for add-ons to be posted on the website.
Requirements are, for now:

A pull request must be created against addonFiles repo, and
reviewers will follow the process described at

https://github.com/nvaccess/addonFiles


In the document dedicated to review processes I'll copy these
requirements and, additionally, I will add references to the add-on
store submission repo Kind regards



2021-10-04 6:38 GMT+02:00, Noelia Ruiz via groups.io
<nrm1977=gmail.com@groups.io>:
Hello:

After a discussion with NV Access, I've received their agreement to
change the review processes, according with current requirements
set for the addonFiles repo:

https://github.com/nvaccess/addonFiles

Since the add-on store is in progress and human reviews won't be
required, they accept to change the review policy accordingly. I'll
document it in a few hours at

https://addons.nvda-project.org/processes.en.html

Of course, this doesn't mean that human and code review is not
important. We should encourage users to provide feedback and also
promote code reviews, useful contributions in pull requests and so on.
Comments are appreciated, so I want to inform before proceeding to
document this.

Requirements will be:

1. The provided link in addonFiles must work.
2. Never try to post add-ons by-passing the security mechanism set
in NVDA about compatibility:

https://github.com/nvaccess/addonfiles

Kind regards












 

On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:
Hello, I have mixed feelings too.
-
As, I think, will everyone.  But this really is a "damned if you do, damned if you don't," sort of choice.  There are major advantages and disadvantages to each route.

Historically speaking, there has been very little malicious activity, and that which there has been has been detected quickly and shut down.  In addition, if the NVDA Add-On user community does not yet already know, and understand, in the core of their individual beings that using any unvetted add-on is an "at your own risk" proposition, then they need to learn that, now.

I've been a big advocate for a centralized add-on repository, and one that allows "home grown" add-ons to be hosted while being clearly indicated as being such.  End users have to start getting used to the idea that the due diligence side of the equation is theirs when it comes to unvetted software, regardless of the repository from which that unvetted software is obtained.

People are already used to this, at least to some extent, with venues such as the Google Play Store, which used to be the wild, wild, west and only recently began a review process worthy of the name.  Even then, certain things that I'd certainly consider malicious, or at least potentially so, get on to the Play Store because the authors simply declare that virtually any permission you can name is in use.  And heaven only knows what they're doing with any data they obtain, but they declare they have access to it, and that's all that's required.  And I don't consider the permission descriptions to be nearly precise enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?

             ~ Stanislaw J. Lec


 

On Mon, Oct 4, 2021 at 01:08 PM, Joseph Lee wrote:
At least a compromise would be that people should at least give folks an intro about an add-on before posting new ones via Add-on Store/add-on files repo.
-
Not having undertaken the process I would have presumed that, at a minimum, a description of the intended functionality of an add-on must be provided before it can be uploaded.  And, ideally, additional documentation as needed to actually use the thing.

And that should apply to each and every add-on.

Even if it's something you created for your own use, if you're putting it out there for others to use they need to have been given basic instruction on purpose and "how to."
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?

             ~ Stanislaw J. Lec


Doug Lee
 

For reference: I believe that all other screen readers we've had over time that were publicly and documentably scriptable have been free to script without vetting. Specifics:

* JAWS has no centralized repository, so people script and post how and where they like.

* Window-Eyes had a central repository but, to my recollection, did not require code to be reviewed or verified.

* Again to my knowledge, any other screen reader that allowed anything like scripting had no centralized place to post such things.

I mention this because of the result, which is that any requirement of vetting will come across to many would-be developers as an undue burden in comparison to other screen readers for trying to help
the community. I'm not calling this right or wrong; I'm just calling it real.

I will admit though that there is a counterbalancing fact: NVDA, as compared to other screen readers, gives an add-on access to far more resources than scripts in other screen readers tend to do. This
is because add-ons are natively written in a full-fledged programming language rather than in a script engine language like VBScript, Javascript, or the JAWS scripting language, which inherently
provide only partial support for accessing things outside of the screen reader sandbox. This does mean that there is more risk for malicious add-ons than there has been for malicious scripts in other
settings.

However these decisions turn out, I favor continued permission to post add-ons any and everywhere as for other current screen readers, even if we also have a centralized store that requires code to be
vetted. I actually considered the Window-Eyes approach to be somewhat problematic in its requiring absolutely every script, or "app" as they were called, to be posted in one place. This complicated
issues like contract-based development, scripts/apps for specific localized settings such as within a company, beta groups for scripts that worked together on code before it became visible to the
public, etc.

On Mon, Oct 04, 2021 at 10:16:07AM -0700, Brian Vogel wrote:
On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:

Hello, I have mixed feelings too.

-
As, I think, will everyone. But this really is a "damned if you do,
damned if you don't," sort of choice. There are major advantages and
disadvantages to each route.
Historically speaking, there has been very little malicious activity,
and that which there has been has been detected quickly and shut
down. In addition, if the NVDA Add-On user community does not yet
already know, and understand, in the core of their individual beings
that using any unvetted add-on is an "at your own risk" proposition,
then they need to learn that, now.
I've been a big advocate for a centralized add-on repository, and one
that allows "home grown" add-ons to be hosted while being clearly
indicated as being such. End users have to start getting used to the
idea that the due diligence side of the equation is theirs when it
comes to unvetted software, regardless of the repository from which
that unvetted software is obtained.
People are already used to this, at least to some extent, with venues
such as the Google Play Store, which used to be the wild, wild, west
and only recently began a review process worthy of the name. Even
then, certain things that I'd certainly consider malicious, or at least
potentially so, get on to the Play Store because the authors simply
declare that virtually any permission you can name is in use. And
heaven only knows what they're doing with any data they obtain, but
they declare they have access to it, and that's all that's required.Â
And I don't consider the permission descriptions to be nearly precise
enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?
            ~ Stanislaw J. Lec

--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com http://www.LevelAccess.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)


Andy B.
 

Having a collection of actively maintained addons can cause developers
problems...

* Addon community requires addons comply with NVDA's license terms. This in
itself is a review because someone has to check compliance. Besides, there
isn't a true way to check compliance except look at the header of each file
to see if a license is provided.
* The addon store is severely limiting. If it requires all addon developers
to post open source addons, then the NVDA community effectively removed the
addon developer's legal claim to the addon. If I post it to addon store, I
can no longer distribute it under another license, removing my ability to
sell it. If I sell it, then I am no longer able to post it to the addon
store. We are addon developers working on our own, not on behalf of NVDA. If
we were employed or contracted by NVDA to create such addons or features, it
is understandable that NVDA dictates the rules. On the other hand, NVDA
community came up with this rule to keep unsuspecting addon users safe from
unwanted code. By now, users are aware of security risks of using 3rd party
code, so the responsibility is on them, as much as it is on us for creating
safe responsible code. The addon store should do away with the license
requirement and allow any license type aboard. The only requirement in terms
of licenses is the addon developer posting to the addon store is only
allowed to post trialware of their for purchase addons. This opens a way for
addon developers to market to a relevant audience. Then again, you are still
stuck with a review process, so I don't know how you will get away from it.

When I first created my addon I wasn't aware that future users were willing
to pay a significant amount of money for its use. Unfortunately, it is owned
by the NVDA community, no longer on the private market. In the end, I think
everyone is missing out somehow.

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Doug Lee
Sent: Monday, October 4, 2021 1:35 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Change in add-ons review policies #AdminNotice

For reference: I believe that all other screen readers we've had over time
that were publicly and documentably scriptable have been free to script
without vetting. Specifics:

* JAWS has no centralized repository, so people script and post how and
where they like.

* Window-Eyes had a central repository but, to my recollection, did not
require code to be reviewed or verified.

* Again to my knowledge, any other screen reader that allowed anything like
scripting had no centralized place to post such things.

I mention this because of the result, which is that any requirement of
vetting will come across to many would-be developers as an undue burden in
comparison to other screen readers for trying to help the community. I'm not
calling this right or wrong; I'm just calling it real.

I will admit though that there is a counterbalancing fact: NVDA, as compared
to other screen readers, gives an add-on access to far more resources than
scripts in other screen readers tend to do. This is because add-ons are
natively written in a full-fledged programming language rather than in a
script engine language like VBScript, Javascript, or the JAWS scripting
language, which inherently provide only partial support for accessing things
outside of the screen reader sandbox. This does mean that there is more risk
for malicious add-ons than there has been for malicious scripts in other
settings.

However these decisions turn out, I favor continued permission to post
add-ons any and everywhere as for other current screen readers, even if we
also have a centralized store that requires code to be vetted. I actually
considered the Window-Eyes approach to be somewhat problematic in its
requiring absolutely every script, or "app" as they were called, to be
posted in one place. This complicated issues like contract-based
development, scripts/apps for specific localized settings such as within a
company, beta groups for scripts that worked together on code before it
became visible to the public, etc.

On Mon, Oct 04, 2021 at 10:16:07AM -0700, Brian Vogel wrote:
On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:

Hello, I have mixed feelings too.

-
As, I think, will everyone. But this really is a "damned if you do,
damned if you don't," sort of choice. There are major advantages and
disadvantages to each route.
Historically speaking, there has been very little malicious activity,
and that which there has been has been detected quickly and shut
down. In addition, if the NVDA Add-On user community does not yet
already know, and understand, in the core of their individual beings
that using any unvetted add-on is an "at your own risk" proposition,
then they need to learn that, now.
I've been a big advocate for a centralized add-on repository, and one
that allows "home grown" add-ons to be hosted while being clearly
indicated as being such. End users have to start getting used to the
idea that the due diligence side of the equation is theirs when it
comes to unvetted software, regardless of the repository from which
that unvetted software is obtained.
People are already used to this, at least to some extent, with venues
such as the Google Play Store, which used to be the wild, wild, west
and only recently began a review process worthy of the name. Even
then, certain things that I'd certainly consider malicious, or at least
potentially so, get on to the Play Store because the authors simply
declare that virtually any permission you can name is in use. And
heaven only knows what they're doing with any data they obtain, but
they declare they have access to it, and that's all that's required.Â
And I don't consider the permission descriptions to be nearly precise
enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?
            ~ Stanislaw J. Lec

--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)


Andy B.
 

This is still a review. If NVDA community is trying to get away from reviews, it is nearly impossible.

 

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Brian Vogel
Sent: Monday, October 4, 2021 1:19 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Change in add-ons review policies #AdminNotice

 

On Mon, Oct 4, 2021 at 01:08 PM, Joseph Lee wrote:

At least a compromise would be that people should at least give folks an intro about an add-on before posting new ones via Add-on Store/add-on files repo.

-
Not having undertaken the process I would have presumed that, at a minimum, a description of the intended functionality of an add-on must be provided before it can be uploaded.  And, ideally, additional documentation as needed to actually use the thing.

And that should apply to each and every add-on.

Even if it's something you created for your own use, if you're putting it out there for others to use they need to have been given basic instruction on purpose and "how to."
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?

             ~ Stanislaw J. Lec


Noelia Ruiz
 

Hello, thanks for this info. I've made the following updates to the
website. Comments are welcome and I'll review if all is well formatted
since I have no processor to do this locally:

Summary:

- I haven't deleted/modified the old processes document, respecting
the previous work for historical reasons and since there was an
ellaborated document and I haven't felt comfortable changing it.
- I have removed extra explanations in the dev.mdwn document,
corresponding to the Add-ons under development section of the website,
since they didn't match the contents of the main page. There it was
reflected that add-ons would be post on the website at the discretion
of the community taking account factors as quality or interest.
- On the main page, I have put a link to a new document, intentionally
concise and short, listing requirements for add-on inclusion or
updates on the website, that is, making a PR against add-on files
taking care of having a unique id in get.php, valid url and manifest
latest tested version (I have copied/pasted requirements).
- In the main page, I've mentioned that this list maybe used to share
tips about development and the created subgroups if, optionally,
someone wants to get automated notifications about updates on the
website or in add-on commits, mentioning that this may facilitate code
reviews to improve quality of add-ons development. Though this is not
required for inclusion, I think it's important to mention it. Also, I
have moved the link to the list of add-ons repositories to the main
page. So the development page has no extra info. For me this was
confusing and if the list of repos was created so authors can request
to have their add-ons listed there to get feedback, I think that this
may be reflected in the main page, so users can provide feedback also
on GitHub.
Let's see how it goes.
Cheers


2021-10-04 19:35 GMT+02:00, Doug Lee <nvda@dlee.org>:

For reference: I believe that all other screen readers we've had over time
that were publicly and documentably scriptable have been free to script
without vetting. Specifics:

* JAWS has no centralized repository, so people script and post how and
where they like.

* Window-Eyes had a central repository but, to my recollection, did not
require code to be reviewed or verified.

* Again to my knowledge, any other screen reader that allowed anything like
scripting had no centralized place to post such things.

I mention this because of the result, which is that any requirement of
vetting will come across to many would-be developers as an undue burden in
comparison to other screen readers for trying to help
the community. I'm not calling this right or wrong; I'm just calling it
real.

I will admit though that there is a counterbalancing fact: NVDA, as compared
to other screen readers, gives an add-on access to far more resources than
scripts in other screen readers tend to do. This
is because add-ons are natively written in a full-fledged programming
language rather than in a script engine language like VBScript, Javascript,
or the JAWS scripting language, which inherently
provide only partial support for accessing things outside of the screen
reader sandbox. This does mean that there is more risk for malicious add-ons
than there has been for malicious scripts in other
settings.

However these decisions turn out, I favor continued permission to post
add-ons any and everywhere as for other current screen readers, even if we
also have a centralized store that requires code to be
vetted. I actually considered the Window-Eyes approach to be somewhat
problematic in its requiring absolutely every script, or "app" as they were
called, to be posted in one place. This complicated
issues like contract-based development, scripts/apps for specific localized
settings such as within a company, beta groups for scripts that worked
together on code before it became visible to the
public, etc.

On Mon, Oct 04, 2021 at 10:16:07AM -0700, Brian Vogel wrote:
On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:

Hello, I have mixed feelings too.

-
As, I think, will everyone. But this really is a "damned if you do,
damned if you don't," sort of choice. There are major advantages and
disadvantages to each route.
Historically speaking, there has been very little malicious activity,
and that which there has been has been detected quickly and shut
down. In addition, if the NVDA Add-On user community does not yet
already know, and understand, in the core of their individual beings
that using any unvetted add-on is an "at your own risk" proposition,
then they need to learn that, now.
I've been a big advocate for a centralized add-on repository, and one
that allows "home grown" add-ons to be hosted while being clearly
indicated as being such. End users have to start getting used to the
idea that the due diligence side of the equation is theirs when it
comes to unvetted software, regardless of the repository from which
that unvetted software is obtained.
People are already used to this, at least to some extent, with venues
such as the Google Play Store, which used to be the wild, wild, west
and only recently began a review process worthy of the name. Even
then, certain things that I'd certainly consider malicious, or at least
potentially so, get on to the Play Store because the authors simply
declare that virtually any permission you can name is in use. And
heaven only knows what they're doing with any data they obtain, but
they declare they have access to it, and that's all that's required.Â
And I don't consider the permission descriptions to be nearly precise
enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?
            ~ Stanislaw J. Lec

--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)






 

Hi,
An important question that must be answered: any explanation about add-on license? NVDA's own license notes that add-ons are derivative works of NVDA and therefore code fragments that use NVDA interface such as classes and functions must be licensed under GNU GPL version 2; for this reason, folks would state that their add-on source code is licensed under GPL a the top of the files and add statements about modules using a different license. We know that we do touch on this, but Andy's license concern is a valid one that should be addressed soon.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Monday, October 4, 2021 11:24 AM
To: nvda-addons@nvda-addons.groups.io; Doug Lee <nvda@dlee.org>
Subject: [Special] Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hello, thanks for this info. I've made the following updates to the website. Comments are welcome and I'll review if all is well formatted since I have no processor to do this locally:

Summary:

- I haven't deleted/modified the old processes document, respecting the previous work for historical reasons and since there was an ellaborated document and I haven't felt comfortable changing it.
- I have removed extra explanations in the dev.mdwn document, corresponding to the Add-ons under development section of the website, since they didn't match the contents of the main page. There it was reflected that add-ons would be post on the website at the discretion of the community taking account factors as quality or interest.
- On the main page, I have put a link to a new document, intentionally concise and short, listing requirements for add-on inclusion or updates on the website, that is, making a PR against add-on files taking care of having a unique id in get.php, valid url and manifest latest tested version (I have copied/pasted requirements).
- In the main page, I've mentioned that this list maybe used to share tips about development and the created subgroups if, optionally, someone wants to get automated notifications about updates on the website or in add-on commits, mentioning that this may facilitate code reviews to improve quality of add-ons development. Though this is not required for inclusion, I think it's important to mention it. Also, I have moved the link to the list of add-ons repositories to the main page. So the development page has no extra info. For me this was confusing and if the list of repos was created so authors can request to have their add-ons listed there to get feedback, I think that this may be reflected in the main page, so users can provide feedback also on GitHub.
Let's see how it goes.
Cheers


2021-10-04 19:35 GMT+02:00, Doug Lee <nvda@dlee.org>:
For reference: I believe that all other screen readers we've had over
time that were publicly and documentably scriptable have been free to
script without vetting. Specifics:

* JAWS has no centralized repository, so people script and post how
and where they like.

* Window-Eyes had a central repository but, to my recollection, did
not require code to be reviewed or verified.

* Again to my knowledge, any other screen reader that allowed anything
like scripting had no centralized place to post such things.

I mention this because of the result, which is that any requirement of
vetting will come across to many would-be developers as an undue
burden in comparison to other screen readers for trying to help the
community. I'm not calling this right or wrong; I'm just calling it
real.

I will admit though that there is a counterbalancing fact: NVDA, as
compared to other screen readers, gives an add-on access to far more
resources than scripts in other screen readers tend to do. This is
because add-ons are natively written in a full-fledged programming
language rather than in a script engine language like VBScript,
Javascript, or the JAWS scripting language, which inherently provide
only partial support for accessing things outside of the screen reader
sandbox. This does mean that there is more risk for malicious add-ons
than there has been for malicious scripts in other settings.

However these decisions turn out, I favor continued permission to post
add-ons any and everywhere as for other current screen readers, even
if we also have a centralized store that requires code to be vetted. I
actually considered the Window-Eyes approach to be somewhat
problematic in its requiring absolutely every script, or "app" as they
were called, to be posted in one place. This complicated issues like
contract-based development, scripts/apps for specific localized
settings such as within a company, beta groups for scripts that worked
together on code before it became visible to the public, etc.

On Mon, Oct 04, 2021 at 10:16:07AM -0700, Brian Vogel wrote:
On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:

Hello, I have mixed feelings too.

-
As, I think, will everyone. But this really is a "damned if you do,
damned if you don't," sort of choice. There are major advantages and
disadvantages to each route.
Historically speaking, there has been very little malicious activity,
and that which there has been has been detected quickly and shut
down. In addition, if the NVDA Add-On user community does not yet
already know, and understand, in the core of their individual beings
that using any unvetted add-on is an "at your own risk" proposition,
then they need to learn that, now.
I've been a big advocate for a centralized add-on repository, and one
that allows "home grown" add-ons to be hosted while being clearly
indicated as being such. End users have to start getting used to the
idea that the due diligence side of the equation is theirs when it
comes to unvetted software, regardless of the repository from which
that unvetted software is obtained.
People are already used to this, at least to some extent, with venues
such as the Google Play Store, which used to be the wild, wild, west
and only recently began a review process worthy of the name. Even
then, certain things that I'd certainly consider malicious, or at least
potentially so, get on to the Play Store because the authors simply
declare that virtually any permission you can name is in use. And
heaven only knows what they're doing with any data they obtain, but
they declare they have access to it, and that's all that's required.Â
And I don't consider the permission descriptions to be nearly precise
enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?
            ~ Stanislaw J. Lec

--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)






Andy B.
 

Thanks... I will help when needed.

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Joseph Lee
Sent: Monday, October 4, 2021 2:35 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hi,
An important question that must be answered: any explanation about add-on license? NVDA's own license notes that add-ons are derivative works of NVDA and therefore code fragments that use NVDA interface such as classes and functions must be licensed under GNU GPL version 2; for this reason, folks would state that their add-on source code is licensed under GPL a the top of the files and add statements about modules using a different license. We know that we do touch on this, but Andy's license concern is a valid one that should be addressed soon.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Monday, October 4, 2021 11:24 AM
To: nvda-addons@nvda-addons.groups.io; Doug Lee <nvda@dlee.org>
Subject: [Special] Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hello, thanks for this info. I've made the following updates to the website. Comments are welcome and I'll review if all is well formatted since I have no processor to do this locally:

Summary:

- I haven't deleted/modified the old processes document, respecting the previous work for historical reasons and since there was an ellaborated document and I haven't felt comfortable changing it.
- I have removed extra explanations in the dev.mdwn document, corresponding to the Add-ons under development section of the website, since they didn't match the contents of the main page. There it was reflected that add-ons would be post on the website at the discretion of the community taking account factors as quality or interest.
- On the main page, I have put a link to a new document, intentionally concise and short, listing requirements for add-on inclusion or updates on the website, that is, making a PR against add-on files taking care of having a unique id in get.php, valid url and manifest latest tested version (I have copied/pasted requirements).
- In the main page, I've mentioned that this list maybe used to share tips about development and the created subgroups if, optionally, someone wants to get automated notifications about updates on the website or in add-on commits, mentioning that this may facilitate code reviews to improve quality of add-ons development. Though this is not required for inclusion, I think it's important to mention it. Also, I have moved the link to the list of add-ons repositories to the main page. So the development page has no extra info. For me this was confusing and if the list of repos was created so authors can request to have their add-ons listed there to get feedback, I think that this may be reflected in the main page, so users can provide feedback also on GitHub.
Let's see how it goes.
Cheers


2021-10-04 19:35 GMT+02:00, Doug Lee <nvda@dlee.org>:
For reference: I believe that all other screen readers we've had over
time that were publicly and documentably scriptable have been free to
script without vetting. Specifics:

* JAWS has no centralized repository, so people script and post how
and where they like.

* Window-Eyes had a central repository but, to my recollection, did
not require code to be reviewed or verified.

* Again to my knowledge, any other screen reader that allowed anything
like scripting had no centralized place to post such things.

I mention this because of the result, which is that any requirement of
vetting will come across to many would-be developers as an undue
burden in comparison to other screen readers for trying to help the
community. I'm not calling this right or wrong; I'm just calling it
real.

I will admit though that there is a counterbalancing fact: NVDA, as
compared to other screen readers, gives an add-on access to far more
resources than scripts in other screen readers tend to do. This is
because add-ons are natively written in a full-fledged programming
language rather than in a script engine language like VBScript,
Javascript, or the JAWS scripting language, which inherently provide
only partial support for accessing things outside of the screen reader
sandbox. This does mean that there is more risk for malicious add-ons
than there has been for malicious scripts in other settings.

However these decisions turn out, I favor continued permission to post
add-ons any and everywhere as for other current screen readers, even
if we also have a centralized store that requires code to be vetted. I
actually considered the Window-Eyes approach to be somewhat
problematic in its requiring absolutely every script, or "app" as they
were called, to be posted in one place. This complicated issues like
contract-based development, scripts/apps for specific localized
settings such as within a company, beta groups for scripts that worked
together on code before it became visible to the public, etc.

On Mon, Oct 04, 2021 at 10:16:07AM -0700, Brian Vogel wrote:
On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:

Hello, I have mixed feelings too.

-
As, I think, will everyone. But this really is a "damned if you do,
damned if you don't," sort of choice. There are major advantages and
disadvantages to each route.
Historically speaking, there has been very little malicious activity,
and that which there has been has been detected quickly and shut
down. In addition, if the NVDA Add-On user community does not yet
already know, and understand, in the core of their individual beings
that using any unvetted add-on is an "at your own risk" proposition,
then they need to learn that, now.
I've been a big advocate for a centralized add-on repository, and one
that allows "home grown" add-ons to be hosted while being clearly
indicated as being such. End users have to start getting used to the
idea that the due diligence side of the equation is theirs when it
comes to unvetted software, regardless of the repository from which
that unvetted software is obtained.
People are already used to this, at least to some extent, with venues
such as the Google Play Store, which used to be the wild, wild, west
and only recently began a review process worthy of the name. Even
then, certain things that I'd certainly consider malicious, or at least
potentially so, get on to the Play Store because the authors simply
declare that virtually any permission you can name is in use. And
heaven only knows what they're doing with any data they obtain, but
they declare they have access to it, and that's all that's required.Â
And I don't consider the permission descriptions to be nearly precise
enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?
            ~ Stanislaw J. Lec

--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)






 

Hi,
To clarify: add-ons are composed of modules that could be using different and sometimes incompatible licenses. I think if any of the modules contained within an add-on uses features provided by NVDA, then these modules should be licensed under GPL 2. Folks could say "my add-on is licensed under GPL 2 simply because all the code inside use NVDA features in one way or another". But after some thinking, I realize that this may not be the case if there are code from modules (third-party or created by the author) that are using different licenses; in other words, we might as well take this opportunity to:
1. Acknowledge that we are misleading people by saying that the whole add-on is licensed under GPL when in fact it isn't unless all modules inside the add-on use NVDA features.
2. Acknowledge that it is perfectly possible and permissible that add-ons use modules using different licenses- only the parts that use NVDA features directly should be licensed under GPL 2.
3. Begin to clearly define the distinction between an add-on and a module - an add-on is package of a collection of modules designed to extend NVDA in one way or another, while a module is a file containing code that Python will use to accomplish add-on tasks.
Hope this helps.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Joseph Lee via groups.io
Sent: Monday, October 4, 2021 11:35 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hi,
An important question that must be answered: any explanation about add-on license? NVDA's own license notes that add-ons are derivative works of NVDA and therefore code fragments that use NVDA interface such as classes and functions must be licensed under GNU GPL version 2; for this reason, folks would state that their add-on source code is licensed under GPL a the top of the files and add statements about modules using a different license. We know that we do touch on this, but Andy's license concern is a valid one that should be addressed soon.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Monday, October 4, 2021 11:24 AM
To: nvda-addons@nvda-addons.groups.io; Doug Lee <nvda@dlee.org>
Subject: [Special] Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hello, thanks for this info. I've made the following updates to the website. Comments are welcome and I'll review if all is well formatted since I have no processor to do this locally:

Summary:

- I haven't deleted/modified the old processes document, respecting the previous work for historical reasons and since there was an ellaborated document and I haven't felt comfortable changing it.
- I have removed extra explanations in the dev.mdwn document, corresponding to the Add-ons under development section of the website, since they didn't match the contents of the main page. There it was reflected that add-ons would be post on the website at the discretion of the community taking account factors as quality or interest.
- On the main page, I have put a link to a new document, intentionally concise and short, listing requirements for add-on inclusion or updates on the website, that is, making a PR against add-on files taking care of having a unique id in get.php, valid url and manifest latest tested version (I have copied/pasted requirements).
- In the main page, I've mentioned that this list maybe used to share tips about development and the created subgroups if, optionally, someone wants to get automated notifications about updates on the website or in add-on commits, mentioning that this may facilitate code reviews to improve quality of add-ons development. Though this is not required for inclusion, I think it's important to mention it. Also, I have moved the link to the list of add-ons repositories to the main page. So the development page has no extra info. For me this was confusing and if the list of repos was created so authors can request to have their add-ons listed there to get feedback, I think that this may be reflected in the main page, so users can provide feedback also on GitHub.
Let's see how it goes.
Cheers


2021-10-04 19:35 GMT+02:00, Doug Lee <nvda@dlee.org>:
For reference: I believe that all other screen readers we've had over
time that were publicly and documentably scriptable have been free to
script without vetting. Specifics:

* JAWS has no centralized repository, so people script and post how
and where they like.

* Window-Eyes had a central repository but, to my recollection, did
not require code to be reviewed or verified.

* Again to my knowledge, any other screen reader that allowed anything
like scripting had no centralized place to post such things.

I mention this because of the result, which is that any requirement of
vetting will come across to many would-be developers as an undue
burden in comparison to other screen readers for trying to help the
community. I'm not calling this right or wrong; I'm just calling it
real.

I will admit though that there is a counterbalancing fact: NVDA, as
compared to other screen readers, gives an add-on access to far more
resources than scripts in other screen readers tend to do. This is
because add-ons are natively written in a full-fledged programming
language rather than in a script engine language like VBScript,
Javascript, or the JAWS scripting language, which inherently provide
only partial support for accessing things outside of the screen reader
sandbox. This does mean that there is more risk for malicious add-ons
than there has been for malicious scripts in other settings.

However these decisions turn out, I favor continued permission to post
add-ons any and everywhere as for other current screen readers, even
if we also have a centralized store that requires code to be vetted. I
actually considered the Window-Eyes approach to be somewhat
problematic in its requiring absolutely every script, or "app" as they
were called, to be posted in one place. This complicated issues like
contract-based development, scripts/apps for specific localized
settings such as within a company, beta groups for scripts that worked
together on code before it became visible to the public, etc.

On Mon, Oct 04, 2021 at 10:16:07AM -0700, Brian Vogel wrote:
On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:

Hello, I have mixed feelings too.

-
As, I think, will everyone. But this really is a "damned if you do,
damned if you don't," sort of choice. There are major advantages and
disadvantages to each route.
Historically speaking, there has been very little malicious activity,
and that which there has been has been detected quickly and shut
down. In addition, if the NVDA Add-On user community does not yet
already know, and understand, in the core of their individual beings
that using any unvetted add-on is an "at your own risk" proposition,
then they need to learn that, now.
I've been a big advocate for a centralized add-on repository, and one
that allows "home grown" add-ons to be hosted while being clearly
indicated as being such. End users have to start getting used to the
idea that the due diligence side of the equation is theirs when it
comes to unvetted software, regardless of the repository from which
that unvetted software is obtained.
People are already used to this, at least to some extent, with venues
such as the Google Play Store, which used to be the wild, wild, west
and only recently began a review process worthy of the name. Even
then, certain things that I'd certainly consider malicious, or at least
potentially so, get on to the Play Store because the authors simply
declare that virtually any permission you can name is in use. And
heaven only knows what they're doing with any data they obtain, but
they declare they have access to it, and that's all that's required.Â
And I don't consider the permission descriptions to be nearly precise
enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?
            ~ Stanislaw J. Lec

--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)






Noelia Ruiz
 

Hello, I think this is not related to this thread since licenses
aren't reviewed and each add-on publisher is responsible for his work,
included legal implications, right?
I think that the distinction about an add-on and module is clear.
Maybe I'm missing something or some email has been sent to spam.
SApologies if I'm missing something.

2021-10-04 20:49 GMT+02:00, Joseph Lee <joseph.lee22590@gmail.com>:

Hi,
To clarify: add-ons are composed of modules that could be using different
and sometimes incompatible licenses. I think if any of the modules contained
within an add-on uses features provided by NVDA, then these modules should
be licensed under GPL 2. Folks could say "my add-on is licensed under GPL 2
simply because all the code inside use NVDA features in one way or another".
But after some thinking, I realize that this may not be the case if there
are code from modules (third-party or created by the author) that are using
different licenses; in other words, we might as well take this opportunity
to:
1. Acknowledge that we are misleading people by saying that the whole add-on
is licensed under GPL when in fact it isn't unless all modules inside the
add-on use NVDA features.
2. Acknowledge that it is perfectly possible and permissible that add-ons
use modules using different licenses- only the parts that use NVDA features
directly should be licensed under GPL 2.
3. Begin to clearly define the distinction between an add-on and a module -
an add-on is package of a collection of modules designed to extend NVDA in
one way or another, while a module is a file containing code that Python
will use to accomplish add-on tasks.
Hope this helps.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Joseph Lee via groups.io
Sent: Monday, October 4, 2021 11:35 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hi,
An important question that must be answered: any explanation about add-on
license? NVDA's own license notes that add-ons are derivative works of NVDA
and therefore code fragments that use NVDA interface such as classes and
functions must be licensed under GNU GPL version 2; for this reason, folks
would state that their add-on source code is licensed under GPL a the top of
the files and add statements about modules using a different license. We
know that we do touch on this, but Andy's license concern is a valid one
that should be addressed soon.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Noelia Ruiz
Sent: Monday, October 4, 2021 11:24 AM
To: nvda-addons@nvda-addons.groups.io; Doug Lee <nvda@dlee.org>
Subject: [Special] Re: [nvda-addons] Change in add-ons review policies
#AdminNotice

Hello, thanks for this info. I've made the following updates to the website.
Comments are welcome and I'll review if all is well formatted since I have
no processor to do this locally:

Summary:

- I haven't deleted/modified the old processes document, respecting the
previous work for historical reasons and since there was an ellaborated
document and I haven't felt comfortable changing it.
- I have removed extra explanations in the dev.mdwn document, corresponding
to the Add-ons under development section of the website, since they didn't
match the contents of the main page. There it was reflected that add-ons
would be post on the website at the discretion of the community taking
account factors as quality or interest.
- On the main page, I have put a link to a new document, intentionally
concise and short, listing requirements for add-on inclusion or updates on
the website, that is, making a PR against add-on files taking care of having
a unique id in get.php, valid url and manifest latest tested version (I have
copied/pasted requirements).
- In the main page, I've mentioned that this list maybe used to share tips
about development and the created subgroups if, optionally, someone wants to
get automated notifications about updates on the website or in add-on
commits, mentioning that this may facilitate code reviews to improve quality
of add-ons development. Though this is not required for inclusion, I think
it's important to mention it. Also, I have moved the link to the list of
add-ons repositories to the main page. So the development page has no extra
info. For me this was confusing and if the list of repos was created so
authors can request to have their add-ons listed there to get feedback, I
think that this may be reflected in the main page, so users can provide
feedback also on GitHub.
Let's see how it goes.
Cheers


2021-10-04 19:35 GMT+02:00, Doug Lee <nvda@dlee.org>:
For reference: I believe that all other screen readers we've had over
time that were publicly and documentably scriptable have been free to
script without vetting. Specifics:

* JAWS has no centralized repository, so people script and post how
and where they like.

* Window-Eyes had a central repository but, to my recollection, did
not require code to be reviewed or verified.

* Again to my knowledge, any other screen reader that allowed anything
like scripting had no centralized place to post such things.

I mention this because of the result, which is that any requirement of
vetting will come across to many would-be developers as an undue
burden in comparison to other screen readers for trying to help the
community. I'm not calling this right or wrong; I'm just calling it
real.

I will admit though that there is a counterbalancing fact: NVDA, as
compared to other screen readers, gives an add-on access to far more
resources than scripts in other screen readers tend to do. This is
because add-ons are natively written in a full-fledged programming
language rather than in a script engine language like VBScript,
Javascript, or the JAWS scripting language, which inherently provide
only partial support for accessing things outside of the screen reader
sandbox. This does mean that there is more risk for malicious add-ons
than there has been for malicious scripts in other settings.

However these decisions turn out, I favor continued permission to post
add-ons any and everywhere as for other current screen readers, even
if we also have a centralized store that requires code to be vetted. I
actually considered the Window-Eyes approach to be somewhat
problematic in its requiring absolutely every script, or "app" as they
were called, to be posted in one place. This complicated issues like
contract-based development, scripts/apps for specific localized
settings such as within a company, beta groups for scripts that worked
together on code before it became visible to the public, etc.

On Mon, Oct 04, 2021 at 10:16:07AM -0700, Brian Vogel wrote:
On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:

Hello, I have mixed feelings too.

-
As, I think, will everyone. But this really is a "damned if you do,
damned if you don't," sort of choice. There are major advantages and
disadvantages to each route.
Historically speaking, there has been very little malicious activity,
and that which there has been has been detected quickly and shut
down. In addition, if the NVDA Add-On user community does not yet
already know, and understand, in the core of their individual beings
that using any unvetted add-on is an "at your own risk" proposition,
then they need to learn that, now.
I've been a big advocate for a centralized add-on repository, and one
that allows "home grown" add-ons to be hosted while being clearly
indicated as being such. End users have to start getting used to the
idea that the due diligence side of the equation is theirs when it
comes to unvetted software, regardless of the repository from which
that unvetted software is obtained.
People are already used to this, at least to some extent, with venues
such as the Google Play Store, which used to be the wild, wild, west
and only recently began a review process worthy of the name. Even
then, certain things that I'd certainly consider malicious, or at
least
potentially so, get on to the Play Store because the authors simply
declare that virtually any permission you can name is in use. And
heaven only knows what they're doing with any data they obtain, but
they declare they have access to it, and that's all that's required.Â
And I don't consider the permission descriptions to be nearly precise
enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?
            ~ Stanislaw J. Lec

--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)





















Noelia Ruiz
 

Hi don't see problems with the format of changes made on the website.
If someone finds some mistake please let me know to fix it.

2021-10-04 21:12 GMT+02:00, Noelia Ruiz via groups.io
<nrm1977=gmail.com@groups.io>:

Hello, I think this is not related to this thread since licenses
aren't reviewed and each add-on publisher is responsible for his work,
included legal implications, right?
I think that the distinction about an add-on and module is clear.
Maybe I'm missing something or some email has been sent to spam.
SApologies if I'm missing something.

2021-10-04 20:49 GMT+02:00, Joseph Lee <joseph.lee22590@gmail.com>:
Hi,
To clarify: add-ons are composed of modules that could be using different
and sometimes incompatible licenses. I think if any of the modules
contained
within an add-on uses features provided by NVDA, then these modules
should
be licensed under GPL 2. Folks could say "my add-on is licensed under GPL
2
simply because all the code inside use NVDA features in one way or
another".
But after some thinking, I realize that this may not be the case if there
are code from modules (third-party or created by the author) that are
using
different licenses; in other words, we might as well take this
opportunity
to:
1. Acknowledge that we are misleading people by saying that the whole
add-on
is licensed under GPL when in fact it isn't unless all modules inside the
add-on use NVDA features.
2. Acknowledge that it is perfectly possible and permissible that add-ons
use modules using different licenses- only the parts that use NVDA
features
directly should be licensed under GPL 2.
3. Begin to clearly define the distinction between an add-on and a module
-
an add-on is package of a collection of modules designed to extend NVDA
in
one way or another, while a module is a file containing code that Python
will use to accomplish add-on tasks.
Hope this helps.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io>
On Behalf Of Joseph Lee via groups.io
Sent: Monday, October 4, 2021 11:35 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hi,
An important question that must be answered: any explanation about add-on
license? NVDA's own license notes that add-ons are derivative works of
NVDA
and therefore code fragments that use NVDA interface such as classes and
functions must be licensed under GNU GPL version 2; for this reason,
folks
would state that their add-on source code is licensed under GPL a the top
of
the files and add statements about modules using a different license. We
know that we do touch on this, but Andy's license concern is a valid one
that should be addressed soon.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io>
On Behalf Of Noelia Ruiz
Sent: Monday, October 4, 2021 11:24 AM
To: nvda-addons@nvda-addons.groups.io; Doug Lee <nvda@dlee.org>
Subject: [Special] Re: [nvda-addons] Change in add-ons review policies
#AdminNotice

Hello, thanks for this info. I've made the following updates to the
website.
Comments are welcome and I'll review if all is well formatted since I
have
no processor to do this locally:

Summary:

- I haven't deleted/modified the old processes document, respecting the
previous work for historical reasons and since there was an ellaborated
document and I haven't felt comfortable changing it.
- I have removed extra explanations in the dev.mdwn document,
corresponding
to the Add-ons under development section of the website, since they
didn't
match the contents of the main page. There it was reflected that add-ons
would be post on the website at the discretion of the community taking
account factors as quality or interest.
- On the main page, I have put a link to a new document, intentionally
concise and short, listing requirements for add-on inclusion or updates
on
the website, that is, making a PR against add-on files taking care of
having
a unique id in get.php, valid url and manifest latest tested version (I
have
copied/pasted requirements).
- In the main page, I've mentioned that this list maybe used to share
tips
about development and the created subgroups if, optionally, someone wants
to
get automated notifications about updates on the website or in add-on
commits, mentioning that this may facilitate code reviews to improve
quality
of add-ons development. Though this is not required for inclusion, I
think
it's important to mention it. Also, I have moved the link to the list of
add-ons repositories to the main page. So the development page has no
extra
info. For me this was confusing and if the list of repos was created so
authors can request to have their add-ons listed there to get feedback, I
think that this may be reflected in the main page, so users can provide
feedback also on GitHub.
Let's see how it goes.
Cheers


2021-10-04 19:35 GMT+02:00, Doug Lee <nvda@dlee.org>:
For reference: I believe that all other screen readers we've had over
time that were publicly and documentably scriptable have been free to
script without vetting. Specifics:

* JAWS has no centralized repository, so people script and post how
and where they like.

* Window-Eyes had a central repository but, to my recollection, did
not require code to be reviewed or verified.

* Again to my knowledge, any other screen reader that allowed anything
like scripting had no centralized place to post such things.

I mention this because of the result, which is that any requirement of
vetting will come across to many would-be developers as an undue
burden in comparison to other screen readers for trying to help the
community. I'm not calling this right or wrong; I'm just calling it
real.

I will admit though that there is a counterbalancing fact: NVDA, as
compared to other screen readers, gives an add-on access to far more
resources than scripts in other screen readers tend to do. This is
because add-ons are natively written in a full-fledged programming
language rather than in a script engine language like VBScript,
Javascript, or the JAWS scripting language, which inherently provide
only partial support for accessing things outside of the screen reader
sandbox. This does mean that there is more risk for malicious add-ons
than there has been for malicious scripts in other settings.

However these decisions turn out, I favor continued permission to post
add-ons any and everywhere as for other current screen readers, even
if we also have a centralized store that requires code to be vetted. I
actually considered the Window-Eyes approach to be somewhat
problematic in its requiring absolutely every script, or "app" as they
were called, to be posted in one place. This complicated issues like
contract-based development, scripts/apps for specific localized
settings such as within a company, beta groups for scripts that worked
together on code before it became visible to the public, etc.

On Mon, Oct 04, 2021 at 10:16:07AM -0700, Brian Vogel wrote:
On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:

Hello, I have mixed feelings too.

-
As, I think, will everyone. But this really is a "damned if you do,
damned if you don't," sort of choice. There are major advantages
and
disadvantages to each route.
Historically speaking, there has been very little malicious activity,
and that which there has been has been detected quickly and shut
down. In addition, if the NVDA Add-On user community does not yet
already know, and understand, in the core of their individual beings
that using any unvetted add-on is an "at your own risk" proposition,
then they need to learn that, now.
I've been a big advocate for a centralized add-on repository, and one
that allows "home grown" add-ons to be hosted while being clearly
indicated as being such. End users have to start getting used to
the
idea that the due diligence side of the equation is theirs when it
comes to unvetted software, regardless of the repository from which
that unvetted software is obtained.
People are already used to this, at least to some extent, with venues
such as the Google Play Store, which used to be the wild, wild, west
and only recently began a review process worthy of the name. Even
then, certain things that I'd certainly consider malicious, or at
least
potentially so, get on to the Play Store because the authors simply
declare that virtually any permission you can name is in use. And
heaven only knows what they're doing with any data they obtain, but
they declare they have access to it, and that's all that's required.Â
And I don't consider the permission descriptions to be nearly precise
enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?
            ~ Stanislaw J. Lec

--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)

























 

Hi,
License and copyright is the first thing reviewed, or at least the most important thing reviewed in the basic review phase. It was done due to the clause in the NVDA's own license that says add-on modules (parts of add-ons ) are considered derivative works of NVDA and things using NVDA interface should be licensed the same as NVDA itself, which is GPL 2.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Monday, October 4, 2021 12:12 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [Special] Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hello, I think this is not related to this thread since licenses aren't reviewed and each add-on publisher is responsible for his work, included legal implications, right?
I think that the distinction about an add-on and module is clear.
Maybe I'm missing something or some email has been sent to spam.
SApologies if I'm missing something.

2021-10-04 20:49 GMT+02:00, Joseph Lee <joseph.lee22590@gmail.com>:
Hi,
To clarify: add-ons are composed of modules that could be using
different and sometimes incompatible licenses. I think if any of the
modules contained within an add-on uses features provided by NVDA,
then these modules should be licensed under GPL 2. Folks could say "my
add-on is licensed under GPL 2 simply because all the code inside use NVDA features in one way or another".
But after some thinking, I realize that this may not be the case if
there are code from modules (third-party or created by the author)
that are using different licenses; in other words, we might as well
take this opportunity
to:
1. Acknowledge that we are misleading people by saying that the whole
add-on is licensed under GPL when in fact it isn't unless all modules
inside the add-on use NVDA features.
2. Acknowledge that it is perfectly possible and permissible that
add-ons use modules using different licenses- only the parts that use
NVDA features directly should be licensed under GPL 2.
3. Begin to clearly define the distinction between an add-on and a
module - an add-on is package of a collection of modules designed to
extend NVDA in one way or another, while a module is a file containing
code that Python will use to accomplish add-on tasks.
Hope this helps.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io>
On Behalf Of Joseph Lee via groups.io
Sent: Monday, October 4, 2021 11:35 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Change in add-ons review policies
#AdminNotice

Hi,
An important question that must be answered: any explanation about
add-on license? NVDA's own license notes that add-ons are derivative
works of NVDA and therefore code fragments that use NVDA interface
such as classes and functions must be licensed under GNU GPL version
2; for this reason, folks would state that their add-on source code is
licensed under GPL a the top of the files and add statements about
modules using a different license. We know that we do touch on this,
but Andy's license concern is a valid one that should be addressed soon.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io>
On Behalf Of Noelia Ruiz
Sent: Monday, October 4, 2021 11:24 AM
To: nvda-addons@nvda-addons.groups.io; Doug Lee <nvda@dlee.org>
Subject: [Special] Re: [nvda-addons] Change in add-ons review policies
#AdminNotice

Hello, thanks for this info. I've made the following updates to the website.
Comments are welcome and I'll review if all is well formatted since I
have no processor to do this locally:

Summary:

- I haven't deleted/modified the old processes document, respecting
the previous work for historical reasons and since there was an
ellaborated document and I haven't felt comfortable changing it.
- I have removed extra explanations in the dev.mdwn document,
corresponding to the Add-ons under development section of the website,
since they didn't match the contents of the main page. There it was
reflected that add-ons would be post on the website at the discretion
of the community taking account factors as quality or interest.
- On the main page, I have put a link to a new document, intentionally
concise and short, listing requirements for add-on inclusion or
updates on the website, that is, making a PR against add-on files
taking care of having a unique id in get.php, valid url and manifest
latest tested version (I have copied/pasted requirements).
- In the main page, I've mentioned that this list maybe used to share
tips about development and the created subgroups if, optionally,
someone wants to get automated notifications about updates on the
website or in add-on commits, mentioning that this may facilitate code
reviews to improve quality of add-ons development. Though this is not
required for inclusion, I think it's important to mention it. Also, I
have moved the link to the list of add-ons repositories to the main
page. So the development page has no extra info. For me this was
confusing and if the list of repos was created so authors can request
to have their add-ons listed there to get feedback, I think that this
may be reflected in the main page, so users can provide feedback also on GitHub.
Let's see how it goes.
Cheers


2021-10-04 19:35 GMT+02:00, Doug Lee <nvda@dlee.org>:
For reference: I believe that all other screen readers we've had over
time that were publicly and documentably scriptable have been free to
script without vetting. Specifics:

* JAWS has no centralized repository, so people script and post how
and where they like.

* Window-Eyes had a central repository but, to my recollection, did
not require code to be reviewed or verified.

* Again to my knowledge, any other screen reader that allowed
anything like scripting had no centralized place to post such things.

I mention this because of the result, which is that any requirement
of vetting will come across to many would-be developers as an undue
burden in comparison to other screen readers for trying to help the
community. I'm not calling this right or wrong; I'm just calling it
real.

I will admit though that there is a counterbalancing fact: NVDA, as
compared to other screen readers, gives an add-on access to far more
resources than scripts in other screen readers tend to do. This is
because add-ons are natively written in a full-fledged programming
language rather than in a script engine language like VBScript,
Javascript, or the JAWS scripting language, which inherently provide
only partial support for accessing things outside of the screen
reader sandbox. This does mean that there is more risk for malicious
add-ons than there has been for malicious scripts in other settings.

However these decisions turn out, I favor continued permission to
post add-ons any and everywhere as for other current screen readers,
even if we also have a centralized store that requires code to be
vetted. I actually considered the Window-Eyes approach to be somewhat
problematic in its requiring absolutely every script, or "app" as
they were called, to be posted in one place. This complicated issues
like contract-based development, scripts/apps for specific localized
settings such as within a company, beta groups for scripts that
worked together on code before it became visible to the public, etc.

On Mon, Oct 04, 2021 at 10:16:07AM -0700, Brian Vogel wrote:
On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:

Hello, I have mixed feelings too.

-
As, I think, will everyone. But this really is a "damned if you do,
damned if you don't," sort of choice. There are major advantages and
disadvantages to each route.
Historically speaking, there has been very little malicious activity,
and that which there has been has been detected quickly and shut
down. In addition, if the NVDA Add-On user community does not yet
already know, and understand, in the core of their individual beings
that using any unvetted add-on is an "at your own risk" proposition,
then they need to learn that, now.
I've been a big advocate for a centralized add-on repository, and one
that allows "home grown" add-ons to be hosted while being clearly
indicated as being such. End users have to start getting used to the
idea that the due diligence side of the equation is theirs when it
comes to unvetted software, regardless of the repository from which
that unvetted software is obtained.
People are already used to this, at least to some extent, with venues
such as the Google Play Store, which used to be the wild, wild, west
and only recently began a review process worthy of the name. Even
then, certain things that I'd certainly consider malicious, or at
least
potentially so, get on to the Play Store because the authors simply
declare that virtually any permission you can name is in use. And
heaven only knows what they're doing with any data they obtain, but
they declare they have access to it, and that's all that's required.Â
And I don't consider the permission descriptions to be nearly precise
enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?
            ~ Stanislaw J. Lec

--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)





















Andy B.
 

Technically, we can sell our own addons under the GPL 2/3. So, NVDA has no recourse except where copyright and source code are concerned. The question becomes why does NVDA addon store require only open source addons? Why not include those for purchase as long as there is a trial?

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Joseph Lee
Sent: Monday, October 4, 2021 2:50 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hi,
To clarify: add-ons are composed of modules that could be using different and sometimes incompatible licenses. I think if any of the modules contained within an add-on uses features provided by NVDA, then these modules should be licensed under GPL 2. Folks could say "my add-on is licensed under GPL 2 simply because all the code inside use NVDA features in one way or another". But after some thinking, I realize that this may not be the case if there are code from modules (third-party or created by the author) that are using different licenses; in other words, we might as well take this opportunity to:
1. Acknowledge that we are misleading people by saying that the whole add-on is licensed under GPL when in fact it isn't unless all modules inside the add-on use NVDA features.
2. Acknowledge that it is perfectly possible and permissible that add-ons use modules using different licenses- only the parts that use NVDA features directly should be licensed under GPL 2.
3. Begin to clearly define the distinction between an add-on and a module - an add-on is package of a collection of modules designed to extend NVDA in one way or another, while a module is a file containing code that Python will use to accomplish add-on tasks.
Hope this helps.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Joseph Lee via groups.io
Sent: Monday, October 4, 2021 11:35 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hi,
An important question that must be answered: any explanation about add-on license? NVDA's own license notes that add-ons are derivative works of NVDA and therefore code fragments that use NVDA interface such as classes and functions must be licensed under GNU GPL version 2; for this reason, folks would state that their add-on source code is licensed under GPL a the top of the files and add statements about modules using a different license. We know that we do touch on this, but Andy's license concern is a valid one that should be addressed soon.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Monday, October 4, 2021 11:24 AM
To: nvda-addons@nvda-addons.groups.io; Doug Lee <nvda@dlee.org>
Subject: [Special] Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hello, thanks for this info. I've made the following updates to the website. Comments are welcome and I'll review if all is well formatted since I have no processor to do this locally:

Summary:

- I haven't deleted/modified the old processes document, respecting the previous work for historical reasons and since there was an ellaborated document and I haven't felt comfortable changing it.
- I have removed extra explanations in the dev.mdwn document, corresponding to the Add-ons under development section of the website, since they didn't match the contents of the main page. There it was reflected that add-ons would be post on the website at the discretion of the community taking account factors as quality or interest.
- On the main page, I have put a link to a new document, intentionally concise and short, listing requirements for add-on inclusion or updates on the website, that is, making a PR against add-on files taking care of having a unique id in get.php, valid url and manifest latest tested version (I have copied/pasted requirements).
- In the main page, I've mentioned that this list maybe used to share tips about development and the created subgroups if, optionally, someone wants to get automated notifications about updates on the website or in add-on commits, mentioning that this may facilitate code reviews to improve quality of add-ons development. Though this is not required for inclusion, I think it's important to mention it. Also, I have moved the link to the list of add-ons repositories to the main page. So the development page has no extra info. For me this was confusing and if the list of repos was created so authors can request to have their add-ons listed there to get feedback, I think that this may be reflected in the main page, so users can provide feedback also on GitHub.
Let's see how it goes.
Cheers


2021-10-04 19:35 GMT+02:00, Doug Lee <nvda@dlee.org>:
For reference: I believe that all other screen readers we've had over
time that were publicly and documentably scriptable have been free to
script without vetting. Specifics:

* JAWS has no centralized repository, so people script and post how
and where they like.

* Window-Eyes had a central repository but, to my recollection, did
not require code to be reviewed or verified.

* Again to my knowledge, any other screen reader that allowed anything
like scripting had no centralized place to post such things.

I mention this because of the result, which is that any requirement of
vetting will come across to many would-be developers as an undue
burden in comparison to other screen readers for trying to help the
community. I'm not calling this right or wrong; I'm just calling it
real.

I will admit though that there is a counterbalancing fact: NVDA, as
compared to other screen readers, gives an add-on access to far more
resources than scripts in other screen readers tend to do. This is
because add-ons are natively written in a full-fledged programming
language rather than in a script engine language like VBScript,
Javascript, or the JAWS scripting language, which inherently provide
only partial support for accessing things outside of the screen reader
sandbox. This does mean that there is more risk for malicious add-ons
than there has been for malicious scripts in other settings.

However these decisions turn out, I favor continued permission to post
add-ons any and everywhere as for other current screen readers, even
if we also have a centralized store that requires code to be vetted. I
actually considered the Window-Eyes approach to be somewhat
problematic in its requiring absolutely every script, or "app" as they
were called, to be posted in one place. This complicated issues like
contract-based development, scripts/apps for specific localized
settings such as within a company, beta groups for scripts that worked
together on code before it became visible to the public, etc.

On Mon, Oct 04, 2021 at 10:16:07AM -0700, Brian Vogel wrote:
On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:

Hello, I have mixed feelings too.

-
As, I think, will everyone. But this really is a "damned if you do,
damned if you don't," sort of choice. There are major advantages and
disadvantages to each route.
Historically speaking, there has been very little malicious activity,
and that which there has been has been detected quickly and shut
down. In addition, if the NVDA Add-On user community does not yet
already know, and understand, in the core of their individual beings
that using any unvetted add-on is an "at your own risk" proposition,
then they need to learn that, now.
I've been a big advocate for a centralized add-on repository, and one
that allows "home grown" add-ons to be hosted while being clearly
indicated as being such. End users have to start getting used to the
idea that the due diligence side of the equation is theirs when it
comes to unvetted software, regardless of the repository from which
that unvetted software is obtained.
People are already used to this, at least to some extent, with venues
such as the Google Play Store, which used to be the wild, wild, west
and only recently began a review process worthy of the name. Even
then, certain things that I'd certainly consider malicious, or at least
potentially so, get on to the Play Store because the authors simply
declare that virtually any permission you can name is in use. And
heaven only knows what they're doing with any data they obtain, but
they declare they have access to it, and that's all that's required.Â
And I don't consider the permission descriptions to be nearly precise
enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?
            ~ Stanislaw J. Lec

--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)






Noelia Ruiz
 

But this won"t be reviewed in the store. I think that the question is if human reviews have or not to be done, since other things like malicous code is also important. Also, I have seen at least an add-on posted on the website without specifying a license in the source code itself, what doesn"t mean that the license doesn"t exist. I"m not sure about the add-on but if I remember correctly I may search it to confirm.
I think that licenses maybe also specified in the repo. For example, if I"m not wrong, GPL2 allows to distribute the source code separately if the code is offered. In the store the license needs to be specified in the .json file. What I mean is that the fact that the source code doesn"t specify a license maybe a formal failure, but the add-on maybe subject to a license and this won"t be reviewed in the store. You may suggest that this should be reviewed or checked automatically finding valid texts.
But in add-on files we"are not reviewing this.
Enviado desde mi iPhone

El 4 oct 2021, a las 21:16, Joseph Lee <joseph.lee22590@gmail.com> escribió:

Hi,
License and copyright is the first thing reviewed, or at least the most important thing reviewed in the basic review phase. It was done due to the clause in the NVDA's own license that says add-on modules (parts of add-ons ) are considered derivative works of NVDA and things using NVDA interface should be licensed the same as NVDA itself, which is GPL 2.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Monday, October 4, 2021 12:12 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [Special] Re: [nvda-addons] Change in add-ons review policies #AdminNotice

Hello, I think this is not related to this thread since licenses aren't reviewed and each add-on publisher is responsible for his work, included legal implications, right?
I think that the distinction about an add-on and module is clear.
Maybe I'm missing something or some email has been sent to spam.
SApologies if I'm missing something.

2021-10-04 20:49 GMT+02:00, Joseph Lee <joseph.lee22590@gmail.com>:
Hi,
To clarify: add-ons are composed of modules that could be using
different and sometimes incompatible licenses. I think if any of the
modules contained within an add-on uses features provided by NVDA,
then these modules should be licensed under GPL 2. Folks could say "my
add-on is licensed under GPL 2 simply because all the code inside use NVDA features in one way or another".
But after some thinking, I realize that this may not be the case if
there are code from modules (third-party or created by the author)
that are using different licenses; in other words, we might as well
take this opportunity
to:
1. Acknowledge that we are misleading people by saying that the whole
add-on is licensed under GPL when in fact it isn't unless all modules
inside the add-on use NVDA features.
2. Acknowledge that it is perfectly possible and permissible that
add-ons use modules using different licenses- only the parts that use
NVDA features directly should be licensed under GPL 2.
3. Begin to clearly define the distinction between an add-on and a
module - an add-on is package of a collection of modules designed to
extend NVDA in one way or another, while a module is a file containing
code that Python will use to accomplish add-on tasks.
Hope this helps.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io>
On Behalf Of Joseph Lee via groups.io
Sent: Monday, October 4, 2021 11:35 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Change in add-ons review policies
#AdminNotice

Hi,
An important question that must be answered: any explanation about
add-on license? NVDA's own license notes that add-ons are derivative
works of NVDA and therefore code fragments that use NVDA interface
such as classes and functions must be licensed under GNU GPL version
2; for this reason, folks would state that their add-on source code is
licensed under GPL a the top of the files and add statements about
modules using a different license. We know that we do touch on this,
but Andy's license concern is a valid one that should be addressed soon.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io>
On Behalf Of Noelia Ruiz
Sent: Monday, October 4, 2021 11:24 AM
To: nvda-addons@nvda-addons.groups.io; Doug Lee <nvda@dlee.org>
Subject: [Special] Re: [nvda-addons] Change in add-ons review policies
#AdminNotice

Hello, thanks for this info. I've made the following updates to the website.
Comments are welcome and I'll review if all is well formatted since I
have no processor to do this locally:

Summary:

- I haven't deleted/modified the old processes document, respecting
the previous work for historical reasons and since there was an
ellaborated document and I haven't felt comfortable changing it.
- I have removed extra explanations in the dev.mdwn document,
corresponding to the Add-ons under development section of the website,
since they didn't match the contents of the main page. There it was
reflected that add-ons would be post on the website at the discretion
of the community taking account factors as quality or interest.
- On the main page, I have put a link to a new document, intentionally
concise and short, listing requirements for add-on inclusion or
updates on the website, that is, making a PR against add-on files
taking care of having a unique id in get.php, valid url and manifest
latest tested version (I have copied/pasted requirements).
- In the main page, I've mentioned that this list maybe used to share
tips about development and the created subgroups if, optionally,
someone wants to get automated notifications about updates on the
website or in add-on commits, mentioning that this may facilitate code
reviews to improve quality of add-ons development. Though this is not
required for inclusion, I think it's important to mention it. Also, I
have moved the link to the list of add-ons repositories to the main
page. So the development page has no extra info. For me this was
confusing and if the list of repos was created so authors can request
to have their add-ons listed there to get feedback, I think that this
may be reflected in the main page, so users can provide feedback also on GitHub.
Let's see how it goes.
Cheers


2021-10-04 19:35 GMT+02:00, Doug Lee <nvda@dlee.org>:
For reference: I believe that all other screen readers we've had over
time that were publicly and documentably scriptable have been free to
script without vetting. Specifics:

* JAWS has no centralized repository, so people script and post how
and where they like.

* Window-Eyes had a central repository but, to my recollection, did
not require code to be reviewed or verified.

* Again to my knowledge, any other screen reader that allowed
anything like scripting had no centralized place to post such things.

I mention this because of the result, which is that any requirement
of vetting will come across to many would-be developers as an undue
burden in comparison to other screen readers for trying to help the
community. I'm not calling this right or wrong; I'm just calling it
real.

I will admit though that there is a counterbalancing fact: NVDA, as
compared to other screen readers, gives an add-on access to far more
resources than scripts in other screen readers tend to do. This is
because add-ons are natively written in a full-fledged programming
language rather than in a script engine language like VBScript,
Javascript, or the JAWS scripting language, which inherently provide
only partial support for accessing things outside of the screen
reader sandbox. This does mean that there is more risk for malicious
add-ons than there has been for malicious scripts in other settings.

However these decisions turn out, I favor continued permission to
post add-ons any and everywhere as for other current screen readers,
even if we also have a centralized store that requires code to be
vetted. I actually considered the Window-Eyes approach to be somewhat
problematic in its requiring absolutely every script, or "app" as
they were called, to be posted in one place. This complicated issues
like contract-based development, scripts/apps for specific localized
settings such as within a company, beta groups for scripts that
worked together on code before it became visible to the public, etc.

On Mon, Oct 04, 2021 at 10:16:07AM -0700, Brian Vogel wrote:
On Mon, Oct 4, 2021 at 05:36 AM, Noelia Ruiz wrote:
Hello, I have mixed feelings too.

-
As, I think, will everyone. But this really is a "damned if you do,
damned if you don't," sort of choice. There are major advantages and
disadvantages to each route.
Historically speaking, there has been very little malicious activity,
and that which there has been has been detected quickly and shut
down. In addition, if the NVDA Add-On user community does not yet
already know, and understand, in the core of their individual beings
that using any unvetted add-on is an "at your own risk" proposition,
then they need to learn that, now.
I've been a big advocate for a centralized add-on repository, and one
that allows "home grown" add-ons to be hosted while being clearly
indicated as being such. End users have to start getting used to the
idea that the due diligence side of the equation is theirs when it
comes to unvetted software, regardless of the repository from which
that unvetted software is obtained.
People are already used to this, at least to some extent, with venues
such as the Google Play Store, which used to be the wild, wild, west
and only recently began a review process worthy of the name. Even
then, certain things that I'd certainly consider malicious, or at
least
potentially so, get on to the Play Store because the authors simply
declare that virtually any permission you can name is in use. And
heaven only knows what they're doing with any data they obtain, but
they declare they have access to it, and that's all that's required.Â
And I don't consider the permission descriptions to be nearly precise
enough.
--
Brian - Windows 10, 64-Bit, Version 21H1, Build 19043

Is it progress if a cannibal uses knife and fork?
            ~ Stanislaw J. Lec

--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)