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.
>
>
