On Sun, 2009-06-21 at 22:05 +0100, John Devereux wrote: > Zach Welch <z...@superlucidity.net> writes: > > > Harald, > > > > Thank you for taking the time to participate in this discussion. > > > > On Sat, 2009-06-20 at 12:53 +0200, Harald Kipp wrote: > >> 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. > > > > Static or shared, linked directly or through other libraries: it makes > > no difference with the GPL. > > There must be *some* limit to how far this principle can extend. > > For example, a non-GPLed FTDI "server" communicating via sockets (or > via some other messaging).
Congratulations! You have suggested another potentially legal mechanism for distributing a FTD2XX binary driver. However -- for this to be legitimate -- you would need to implement a fully generic "socket-based JTAG interface" driver... which is what has been previously discussed on this list as the TCP/IP driver. With such a generic mechanism, one could build and distribute a completely and totally separate binary that contains the FTD2XX driver. It would _not_ be legal to define a FTD2XX-only socket interface, because that would be deferring the link step to the socket open call!! It must be a generic interface. This interpretation derives from past experience with other projects, though I cannot recall exactly from where this particular bit of wisdom derives. More importantly, any driver-side code for this socket-based interface would need to be licensed under the LGPL, or the present situation will remain unchanged. Clearly, this will not be possible for 0.2.0, but the build-kit idea would be a temporary workaround. Furthermore, both will improve the functional capabilities of OpenOCD for users, so it is by far the best solution in terms of delivering tangible value to the community. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
