Matter of fact, this question was raised a couple of days after the
anouncement of the discontinued development of WinEyes. I will get back
to what Doug said back then. First of all, let's take a quick look at
facts.
Had it been as easy as WinEyes would have been a stand-alone software,
with all its coding done 'in-house', things would have been pretty easy.
And had it been that Doug and Dan had been the only ones to develop the
software, they could have decided whatever they wanted.
Things are not that easy!
First of all, what doug pointed out, was that to get the better
functionality of WinEyes, they had to reach certain agreements with -
for instance Adobe - to get access to third-party software, kind of
behind the scene. If they open-sourced the code, now these techniques
might be disclosed to the public, threatening the products of the
third-party manufacturer. In turn, this of course would lead to people,
not working on assistive technology at all, to get hold of the key for
the backdoor of - say Adobe's reader - and use it for unwanted activity,
or even malware development.
Secondly, WinEyes had a feature of offering you loads of apps. Many of
them are open-sourced, but WinEyes holds a chance for the app developer
to cryptize his code, for protecting against peekers. This was a
benefit, for instance when the app has to access a server, and maybe
even use some login credencials, to perform the activity. Without me
knowing for sure, we could think of an app like WeatherOrNot, which has
to access a server, retrieve weather details, and process them for you.
Now if the developer has reached a given agreement with the
weather-server provider, that his app will gain free access, under the
condition of not disclosing the login credencials, we are in trouble in
open-sourcing WinEyes. By doing so, we would disclose the cryptizing
code, opening up for people to break the cryptized code of the app, get
to the credencials, and then misuse it.
Part of the agreement GW made with their app developers, by providing
the cryptizing feature, was to keep the app code an enclosed program.
They might get into legal issues, should they disclose the cryptizer,
thereby lay bare the very code of the app developer, who in turn might
sue GW for breaking the agreement. This is kind of backed up, by a
message Doug posted several years back, when someone claimed they had
broken the cryptizer.
Furthermore, it has been confirmed from Aaron, that some of the apps
directly from GW, like AppGet, do hold credencials for accessing the
servers of GW. It is unlikely that they want to have these credencials
open-sourced. In particular so, if you remember the attack someone gave
them a few years back, when the code of the GWToolkit was hacked, and
gave many a WinEyes user quite a shock the morning they turned on their
computer, and got a threatening message on their screen.
Mind you, GW got into a cooperation with Microsoft, when they introduced
the WEForOffice program. Even here, they told that this agreement would
put them in specially close relationship with the ingeneers of
Microsoft. Who knows what closures might be involved there, and which
would be broken, had WE got open-sourced.
Now let's move back to the answer Doug gave back in the spring this
year. The above is a bit of an elaboration of what he said. You will
find his answer in the archives, but in very short terms:
NOPE! WinEyes code CANNNOT go open-source; If for no other reasons,
due to the infringement of third-party agreements involved.
All of this, actually leads me to once again raising the very question:
Does VFO even have access to the WinEyes code?
VFO might have bought AISquared, thereby also the former GWMicro. But
they might not have bought the copyright of the source-code. And perhaps
that was never intended either. Seems all they wanted, was to rid the
market of any competition, period. Who knows, maybe Doug simply hit the
Delete-key, the last thing before he handed in the key for the Office
front-door?
And to assume that VFO's tech personel would bother to plow the
thousands of lines of coding for WinEyes, in hope of hitting the
technique used to perform a simple task, is out of range. It would take
hours, days or even weeks, to figure why things have been done the way
they were. Or, to find the part of a signed contract, that possibly
could be renewed in VFO's favor. Far more cost-effective, and resource
sufficient, to simply look at the behavior of the WinEyes product, and
sit down developing the same bahavior from scratch. Even calling Adobe,
Microsoft, AVG, Avast and so forth, asking for a brand new contract. A
contract VFO already has in place. So my big guess is, VFO DO NOT NEED
the code of the WinEyes screen reader, and never did. They needed the
market, and that is what they've currently got.
On 9/10/2017 3:01 AM, Josh Kennedy via Talk wrote:
> hi
>
> Is there any possibility since window eyes is no longer supported to
get the window-eyes source code make it open source and put it up on the
github website? then other developers could keep developing window eyes.
>
>
