On Tue, 2009-06-23 at 20:23 +0100, Zach Welch wrote: > On Tue, 2009-06-23 at 20:19 +0100, Ian Guffick wrote: >> Hello to all, >> >> I don't want to get involved in the 'war' that seems to have erupted over >> this issue. >> I am a user of OpenOCD rather than a developer, I regularly grab SVN head >> and compile it under Cygwin for Windows with FTD2XX.lib. And I will >> continue >> to do so for my private build. > > You are legally entitled to do so. > >> It is clear that OpenOCD is GPL. >> It is also clear that FTD2XX.lib is not, although no license is >> published, >> the source code is also not published - it cannot be GPL. > > Correct. > >> Am I correct in thinking that the 'driver' forms part of the operating >> system? > > Nope. If it did, this would not be a problem. > >> And that the library is the non-GPL part that is the problem? > > Correct. > >> If that is the case, the simple solution is to develop a GPL version of >> the >> library, but continue to use the driver. >> As Xiofan Chen pointed out, there is already an incomplete project at >> http://sourceforge.net/projects/ftd2xx > > Arguably, this could work. > >> IMHO the libusb-libftdi is a massive overkill that causes other problems >> for >> Windows users. Mainly because it is trying to replace the driver, not >> just >> the problematic library. >> My own problems with libusb-libftdi are: >> 1. I have 6 devices that are regularly used with my PC that use one form >> or >> another FTDI device. Because these are of varying ages, the drivers >> versions >> are different, they must be installed in a correct order or some of the >> devices fail. Why is this a problem?, because running FT_Clean in order >> to >> install libusb-libftdi will remove all of these drivers as well. > > This sounds like a bug in FT_Clean. Please report it to FTDI.
This is not a bug in FT_Clean, it is meant to clear your system of all FTDI drivers. > > I does not sound fair to blame libusb-ftdi for this. I'm not blaming libusb-ftdi, just pointing out a few problems with using that method. If I had to use libusb-ftdi, I would have to use two FTDI devices, one installed with the FTDI driver, the other with libusb-ftdi. > >> 2. I have two other programs that make use of my JtagKey, replacing the >> driver with libusb-libftdi will break these programs. > > What do these programs do? Can we replace them with open source code > alternatives, perhaps in the context of OpenOCD? One is a proprietary program, the other an automated test program that writes data to an I2C device. > >> I may be wrong with one or more of my assumptions, if I am then please >> politely point this out, as I said at the start - I do not want propogate >> this war of words. > > The war is over, but battles still rage due to poor communications. > >> My intention of replacing FTD2XX.lib with a GPL version is NOT an attempt >> to >> circumvent the GPL, such as the wrapper methods that have been suggested. >> I >> believe that if a GPL library was available, using the existing driver >> would >> not be a GPL violation, and the whole solution would be a cleaner more >> palatable solution for all. > > Does the GPL ftd2xx library use libusb or libftdi internally? This > alternative has been suggested before this, but it just seems far more > trouble than it would be worth. > >> I kind of don't need to say this next bit ........ but what are your >> thoughts ;-) > > I have posted several alternatives on the list, but you do not make it > clear whether or not you need to distribute binaries. If you do not, > then these matters should be of no serious concern for you. Continue to > build the package for yourself as you have in the past; nothing has > changed. No I do not need to distribute binaries, I will continue to make private builds. I was simply pointing out some of the problems that Windows users will experience (who maybe cannot build their own). And also suggesting a solution that would avoid these problems. > > Cheers, > > Zach > BR, Ian. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development