On Sun, 2009-06-21 at 11:28 +0200, Freddie Chopin wrote: > As no satisfying solution has been decided I will try to summarise the > options I think are fine for Windows users. Please - put away your > "linux >> windows" attitude aside for a moment and do keep in mind three > things before proceeding: > > 1. Windows users usually have no knowledgle of linux and linux tools > 2. Windows users expect a software package to work "out of the box" > 3. Windows users are not familiar with open-source and GPL ideas > > Because of 1. a solution with VM running OpenOCD on linux is bad, > because instead of questions "how to use libftdi version" we will be > flooded with "how to use linux VM version". Because of 1. it is naive to > expect more than 1% Windows user to be able to compile OpenOCD for > private use. Becaue of 1. it is not a solution to distribute a VM with > linux crosscompiler and apropriate scripts. Because of 2. it is bad to > ship OpenOCD with libftdi which expects user to create custom drivers > (there are NO libusb drivers for FT2232 posted on vendor's websites), > download a hacked version of libusb0.sys and overwrite the original and > so on... Because of 3. Windows users see nothing wrong in using a freely > aviable ftd2xx library that is faster and supports virtual COM ports. > > So in reality I see only two solutions: > > 1. A ftd2xx.dll wrapper library, which would be published under GPL with > exception for ftd2xx.dll. Such library would dynamically link ftd2xx and > - as an open-source solution - could be linked with OpenOCD. This is a > very good proposal made by Herald Kipp and described in detail here: > https://lists.berlios.de/pipermail/openocd-development/2009-June/008265.html > > 2. A binary patch which would "convert" a libusb+libftdi based > executable to ftd2xx based one. Me and Michael Fisher managed to produce > such patch with bsdiff/bspatch. The patch is 30kB in size and works. > > Now, it's obvious that option 1 requires some work. The library has to > be created and OpenOCD code has to be modified to work with that. As the > libary would be a "wrapper" the change in OpenOCD would be merely a name > replacement "FT_..." => "OpenFT_..." (or whatever name would be chosen). > Before such work can be started it would be nice for anybody to comment > on what Herald wrote in the post I linked above. I took some time > yesterday to browse gnu.org website and I think that this solution would > not violate GPL. > > Moreover - _maybe_ such library could also provide a method to "switch" > ftd2xx to libftdi so that it would be up to user to decide what he/she > wishes to use (libftdi and ftd2xx are more or less compatible). This way > OpenOCD would not require a decision of library at compile time. > > The most obvious problem with that solution is that it requires time and > this would not be finished until 0.2.0 (which I hope is coming soon). > Maybe even a bigger problem is your attitude towards such solution... > > The second solution can be used right away. Nothing needs to be changed. > The major concern is - will you allow a patch, patch tool and > instructions to use that to be included in the installer in a folder > named - for example - "Non-GPL"? (I'm asking this for the third time and > I'd really like to hear the answer). > > Some will say that there is a third solution - improve libftdi and > libusb to work as good ad ftd2xx. That solution is very GPL friendly, > but... I think I would be able to create a "wrapper library" with some > (a lot [; ) help, but improving libusb and libftdi code is way beyond my > capabilities. I also haven't seen any volunteers that could do that job. > That's why I suggest to first use the "patch" solution, than "wrapper > library" while waiting for libftdi/libusb improvements, because these > may be complete in a month, in a year or in ten years... > > Currently There are many arguments against libftdi and libusb on > windows, most important of them: > 1. speed, > 2. no support for serial ports on the second channel, > 3. lack of vendor provided drivers online, > 4. no support for composite devices in published libusb code (need for > hacked libusb0.sys). > > That's why I think that without a good solution OpenOCD is more or less > dead for most of Windows users. So please - put at least half of "spaces > vs. tabs" energy in this discussion. This way we can find a solution > that is satisfactory for both parties, because now it's a win-lose in > GPL vs. windows users. > > Or maybe you just wish to ignore Windows and it's n00b users - if that's > the case, state that out loud, and we will be gone and stop bothering > you with our problems.
Please DO NOT try to cheat the GPL license. You do not understand how far I am willing to take these matters, and I believe any form of binary distribution to be a violation: a DLL wrapper, a binary patch, anything! Fix the problems with libusb and libfdti. Period. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
