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

Reply via email to