On Wed, 2009-06-24 at 12:23 +0200, Michael Bruck wrote: > On Wed, Jun 24, 2009 at 11:42, Zach Welch<z...@superlucidity.net> wrote: > > On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote: > >> Simple project for a CS student. > >> > >> A wrapper with a libftdi interface calling libftd2xx, as a project using > >> a LGPL license > >> > >> So any user can take their binary copy of OpenOCD linked against libftdi > >> and simply replace the libftdi dll file, no need to play with system > >> files or drivers. > >> > >> Is such a library illegal ? Who would have standing to complain ? > > > > You are doing it to circumvent the GPL. I think that is illegal. > > > > You would be contravening this copyright holder's intention, which would > > make you liable for any possible infringement that I could show. > > If a third party develops a libftdi.dll replacement then there is no > reason a user can not use that replacement. The GPL license that > applies to the user does not restrict at all what he does with the > code or binary as long as he does not distribute binaries of it. > > Obviously to put the dll wrapper wrapper under a GPL+exceptions > license it would have to be written from scratch rather than just > copy&pasting GPLed libftdi header files (although one could ask the > libfti author to re-license his/her files).
No matter how you want to call the legality of the situation, I hope that you will admit there is something clearly unethically about what you are proposing. I hope the libftdi author(s) would never allow re-licensing for such dubious efforts. Since it remains a legal gray area, it seems silly to go down this road when solutions exist that are compliant, without any kind of effective subterfuge. > > Furthermore, I think individuals can be held liable for "inducing" > > infringement, which is where IANAL becomes useful in some respects. > > > > I have been repeatedly warning _against_ infringement and to consult > > with an attorney on any possible solutions that you intend to distribute > > in binary form. You should be too. > > There is no infringement here, so there is nothing to debate. The > issue gets a bit murky when the replacement dll is bundled with > OpenOCD, but that is not really necessary, the user can load it from > elsewhere. The intention to design this library for the purpose of circumventing the GPL is being documented on this list. Sure, it's murky, but the discussion only helps to build my case to defend against this option. The problem you will face: can anyone in this community show they were working on that option for us, before all of these issues came to light? Lacking a paper trail, how can you explain your motive for doing this? If there _is_ shown to be infringement, it will be plainly intentional, and that may mean some cash will be left over after paying the lawyers. By all means, show me this evidence and I will permit this option. If you cannot, then please drop it from further consideration, for the ethical considerations alone. Or are "ethics" an unrealistic position from which to make such a plea? Certainly, you _are_ free to ignore my ethical stance; likewise, do not expect me to help you in those efforts. I see them as sabotaging the free software community. Legal gray areas do not have GPL-compliant solutions. They take risks of being compliant or not. Risks are unacceptable for OpenOCD vendors, when there may exist potential threats. These risks can be avoided, because they disappear by embracing full and unarguable GPL-compliance. > >> - FTDI ? no their libray and driver is called in accordance with > >> their documentation. > >> - OpenOCD ? nobody has touched a single line of OpenOCD code > >> - Copyright holders of libftdi, Intra2Net AG ? no, libftdi is LGPL and > >> the new library would only use the header file in accordance with LGPL > >> section 3. > >> > >> Would it work? with a bit of tweaking I would think so. > >> > >> Is this a blatant attempt just to work around the problems with OpenOCD, > >> GPL and libftd2xx ? What do I know ? Maybe yes, but that does not make > >> it illegal. > > > > It might. This is a very gray area. For the love of all that is sane, > > why do you want to keep pressing these fronts, when other options have > > been presented that will solve the problems without any objections? > > TCP/IP will impose a speed penalty. It may be a nice extension for > other purposes, but for daily work it is most likely not the best > solution. In addition to that solution, I have pointed out that libusb and libftdi features and performance can be improved. The community can try to get FTDI to go LGPL with their code. There is also a "build kit", which creates user-built binaries; this should produce the same binaries they were getting before this "problem", so there would be zero performance impact to users (other than a longer install process). Altogether, this puts four options on the table, all of which still seem realistic to me. Can you show me concrete evidence to the contrary? The build kit solves the problem completely, and that kind of tool does not seem like a difficult challenge for an experienced developer. I have come up with another new idea, but I need to vet it with the FSF before I suggest it here. I _may_ have found a new loophole (related to the build kit), but I am very uncertain about its legality. Heck, I may ask the FSF to pay me to bury it forever, if it is truly novel! ;) While it would improve things a little, I do not want to get hopes up. Also, developers that build OpenOCD can use it like it is today, right? Rick pointed out that we are catering to binary distributions with these considerations, which is not strictly our mission. We produce source, and the project already appears to be GPL-compliant in that respect. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
