Zach Welch wrote: > On Fri, 2009-06-19 at 18:26 +0200, Harald Kipp wrote:
>> Dynamic linking to proprietary libraries by adding LoadLibrary and >> GetProcAddress to OpenOCD is a gray area. While the FSF would not allow >> this, some lawyers may have a different view. > > The big problem with gray areas is that you can be sued anyway, and -- > even if you have lots of money -- you will have no idea as to whether or > not you will be able to defend the legality of your actions. Same view here. That's why I suggested a different solution, which avoids direct static linking of a proprietary library to GPL code. >> IMHO, the best solution is to create a new DLL, which is distributed >> under LGPL or GPL with a special exception (may be even BSDL). It should >> not provide any problems to link OpenOCD with this new library. And for >> this library it should be no problem to link to FTD2XX.dll. >> >> OpenOCD(GPL) - links - OpenFTD2XX(LGPL) - links - FTD2XX(Closed) > > I would be just as opposed to such circumvention as I would to linking > to it directly, but I believe the legality of this strategy is suspect. > Quite simply, an exception to the LGPL would create a new license, and > the modified legal verbiage would no longer be compatible with the GPL. Sorry, if I didn't explain this clearly enough. LGPL won't need an exception, it explicitly allows linking to proprietary code. Referring to pure GPL: It explicitly allows exceptions and in reality there are many Open Source projects make use of this. In fact GPL itself makes an exception (V2, clause 3, last but one paragraph). Otherwise no GPL program would ever be able to run on Windows. We may also consider to ask the FSF directly to confirm a specific exception. If we are able to provide good reasons, they will probably agree. Anyway, for the intermediate library LGPL is IMHO the better solution. > To reiterate my earlier statements on this subject, I will consider > distribution of any OpenOCD binary that links to FTD2XX to be a > violation of the GPL. If the libftd2xx library loads in the OpenOCD > process, then distributing the binary would violate the GPL. Same view here. That's why I suggested linking OpenOCD to LGPL, which in turn links to FTD2XX. > The "best solution" is to fix libftdi; it is a replacement for FTD2XX. Would you agree, that the "best solution" depends on one's attitude? I understand your point and I agree, that in general it makes a lot more sense to put some effort in GPL code than in trying to integrate proprietary libraries. I also understand, that many contributors (you, probably also Øyvind) do not care much about FTDI libraries, because they simply don't need them. But please consider, that GPL is in competition with proprietary software. Many OpenOCD users are already convinced, that OSS is the better choice, but the proof needs to be furnished for every new user again. I do have a clear interest in FTDI library support. My company manufactures and sells the Turtelizer 2, which includes an USB-RS232 bridge. RS232 is still in wide use on embedded systems. Packed with OpenOCD/Eclipse we are able to offer a nice solution for Windows users, which are still the majority of our customers. I assume, that the OpenOCD user base created by our products is at least several hundreds, the figures of Amontec (manufacturer of the JTAGkey) are probably higher. To put things right, sales of Turtelizer add less than 1% of our revenue. We published all informations and allow hobbyists and competitors to copy the hardware design. Our key products are embedded Ethernet systems (based on BSDL, for good reasons ;-) ). We simply want to provide a convenient tool at a reasonable price. In summary, with Turtelizer and OpenOCD our embedded boards (all Open Source hardware, btw.) are able to compete against products based on closed source software. As far as I understood the current discussion: If we are no longer able to distribute OpenOCD with FTDI support, the RS232 port on the Turtelizer will become useless for Windows users and the JTAG speed will be reduced by up to 2.5 times. This will definitely hurt our ARM based products. In that case OpenOCD is no longer a good solution for us and the majority of our customers. Harald _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
