Zach Welch wrote: > Thank you for taking the time to participate in this discussion.
Zach, thank you for taking the time to respond to my lengthy explanations. I'll try to make it short now. :-) > I think you need to get legal counsel to confirm your point; I believe > this case is no different than the GPL. AFAICT, you must distribute the > source to the library, which cannot be done legally with the FTD2XX > library. You end up in the same place as we find ourselves now with the > GPL, with a new library that tries to obfuscate this fact. You definitely cannot do this, if... 1. The driver is distributed with OpenOCD. 2. The executable fails to work without the driver included. Both items are not required, because... 1. Windows users can easily install FTD2XX separately. 2. The same executable continues to work with other interfaces. The intermediate LGPL library can use LoadLibrary and GetProcAddress to dynamically link to FTD2XX, without crashing OpenOCD, if FTDI DLLs are not available. IMHO, it could be done this way by OpenOCD directly without violating GPL, but a number of contributors do not share this view and the LGPL part may not make its way into the official release. >> Referring to pure GPL: It explicitly allows exceptions and in reality >> there are many Open Source projects make use of this. > > But all copyright holders must agree to adding one. I do not. Fully understood and fully accepted. > OpenOCD binaries linked to FTD2XX drivers could never be distributed > legally, even if no one was called out on it until now. This is not > about attitude, other than compliance with the language of the license > in the manner which its authors intended. Just because of the language? C'mon...admit that there is at least a little breeze of attitude to win the fight against non-free software. ;-) >> I also understand, that many contributors (you, probably also Øyvind) do >> not care much about FTDI libraries, because they simply don't need them. > > I helped improve the high-speed patch for the FTD2XX driver, and I now > own a couple of FTDI-based interfaces. Furthermore, I have been > improving and maintaining all of the code in the tree, regardless of > whether or not I will ever have the related hardware. Judging only by > the number of patches, I care about this code more than you do. ;) Oops, I should have checked the contribs before making this statement. I'm sorry. > Let me say it again. As far as I can tell, no one has ever had the > legal right to distribute OpenOCD binaries with FTD2XX support included > in them, and it is only by the good graces of the existing copyright > holders that violators are not being held accountable with consequences. > In this way, that driver has never been a viable commercial solution. In fact we should have checked the legal situation before starting to sell Turtelizer 2. All problems we have now are definitely our own fault. Anyway, I must try to solve this for our customers and my company in the most economic way. > Developers exist that would be happy to solve these problems for you,* > or you could contribute the required patches yourself. The limitations > of libusb+libftdi are solvable, because the FTD2XX drivers have solved > all of them (or they would not be limitations). You just need to hire > someone that realizes this fact and will do the required work to reach > functional parity; the same goes with libusb support for the secondary > UART on those chips. Probably more than 50% of work done in my company is for Open Source projects under different licenses, including GPL. And, like other companies that focus on Open Source as a successful business model, we do hire external resources for this work as well. In this special case, however, I think, that the effort to add the missing parts to libftdi (RS-232 port plus Vista 64 support) may be to big for us. It may work as a unique feature for the Turtelizer to push its sales, but it will not work in competition with other vendors taking the benefit from our investment. Simply because the Turtelizer is not one of our main products. > I hope that you chose to continue to support the OpenOCD project, but > that does mean abiding by the terms of the GPL. To this end, I want you > to ask this chip vendor to release their library under the LGPL. As > their customer, you should have both a channel and some amount of > leverage to help the open source community accomplish this goal. Of course, we have to investigate all options. Before designing the Turtelizer 2 we intended to buy an alternative solution from Amontec first, which failed because of their prices at that time. Today they are much cheaper. Laurent faces the same problem and FTDI programmers are part of his main business. So one of my hopes is, that he will come up with a solution, which also fits our needs. > I hope everyone thinks this is the absolutely "best solution." It makes > me wonder what would happen if all of the OpenOCD JTAG vendors made a > concerted push on this front.... Want to organize such an effort? > Maybe work toward a Slashdot write-in campaign? I have heard that > vendors are starting to respond quickly to such grassroots movements, > when they see the mob headed toward them with torches and pitchforks. With a few hundred Turtelizers sold so far, our voice has has not much weight. But, as I said, we will investigate all options. Luckily we have only a few ARM-based boards and Turtelizers left in stock, so we are wide open to any solutions. Nevertheless, after Michael and I removed OpenOCD Win32 binaries from yagarto.de and yagarto.org, our customers are left in the rain with a rather old FTD2XX library which we missed to replace before this discussion came up ;-). Finally I want to emphasize the value of our discussion. Don't be mislead by any square-headed arguments I may have made above, Harald _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
