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. > > _______________________________________________ Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Ai Squared. For membership options, visit http://lists.window-eyes.com/options.cgi/talk-window-eyes.com/archive%40mail-archive.com. For subscription options, visit http://lists.window-eyes.com/listinfo.cgi/talk-window-eyes.com List archives can be found at http://lists.window-eyes.com/private.cgi/talk-window-eyes.com
