On Wed, Jun 24, 2009 at 13:29, Zach Welch<z...@superlucidity.net> wrote: > 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.
I don't see what is unethical here. The ethical discussion might have more weight if it wasn't directed at a solution that in the eyes of many people has helped the open source software project OpenOCD to become more popular on the Windows platform. I corrected myself in a later mail on the relicensing. No relicensing is necessary because the use of headers is permitted under the LGPL. Even if it were not it would be only a minor obstacle that can be easily circumnavigated legally by recreating them from scratch. > 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. I don't see a legal gray area there at all. The gray area might be when distributing the replacement DLL *with* the package. >> > 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. Your premise is wrong. The user is not restricted in what he can do with the software on his PC. This is crystal clear from the license and the FAQ. You can do all sorts of kinky stuff with the software in the sanctity of your hard drive, if you want to flip all bits or increment all jump addresses by 13 or replace a DLL, that is your right under the GPL. > 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. This is not necessary. Your copyright on parts of OpenOCD does not preclude a third party or in fact this project from developing a libftdi.dll replacement for whatever purpose and under whatever license. > 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. FTD2XX.dll is not the enemy, OpenOCD has used it to great advantage. My company's contribution to this project was not based on ethics but on the calculation that contributions from other users would feed back into the program and be of benefit to us. The potential for such additions is greatest when the quality/performance/usability of the product is at its maximum so as to attract more users and developers. What you describe as the ethical position is detrimental to the goals that we have with our contribution to this project because it reduces performance and usability. > 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. Having to build OpenOCD yourself is a significant obstacle to wider distribution. The libusb improvements certainly sound interesting, however no one has stepped forward to implement them or to pay someone to implement them. They may or may not also require some reverse engineering plus extensive profiling that would make them more time-consuming than the wrapper. So they don't seem like a near-term solution at the moment. > 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. Given that you are in the USA you could probably patent it as a business method and prevent anyone from using it or collecting money for it. > 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. I think providing binaries for Windows users is a high priority for OpenOCD. Building stuff on Windows especially with many libraries is hard and turns off potential users. Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
