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. > >> 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. 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. The actual difference from the GPL is that you can link LGPL libraries into proprietary applications. When you turn it the other way around, they treat linking proprietary bits into the library binaries the same: you must provide all of the source code to reproduce the binary you shipped under compatible terms. Others may affirm or disavow this interpretation, but this is what I recall from my own past research. The FTD2XX library necessarily imposes "additional restrictions", which prohibit it from being GPL-compatible. > 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. But all copyright holders must agree to adding one. I do not. This makes OpenOCD "pure" GPL, and you will have a challenging burden of proof defending distribution of binaries linked to FTD2XX. Personally, I believe the FTD2XX driver components fail to meet the conditions for exemption under the terms of the paragraph you specify. > 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. The problem is that there is no good reason: libusb+libftdi does the same job and can be made to be equivalent. They would never grant an exception, even if they had standing -- which they do not; as far as I know, no one in the OpenOCD community has assigned their individual copyrights to the FSF. Only through unanimous action could OpenOCD's copyright holders make changes to the license; my dissenting vote precludes any such change. > Anyway, for the intermediate library LGPL is IMHO the better solution. Under the terms of the GPL as I understand them, I believe that libusb and libftdi is the only legally distributable 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? My present definition revolves around legality. The "best solution" will be one that is legal to distribute. 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. Did you stop to consider that -- by ensuring GPL compliance -- we are preventing copyright holders from launching submarine copyright attacks for non-compliance? It could be that I have just foiled a potentially profitable plot to do exactly that; who knows what all of major past contributors are thinking (or how desperate they are for cash). Oops! I fear that I may have now given them this very idea, if they did not have it before now.... Silly of me. At worst, I simply forced them to move the execution of this plan to the present, before you and other vendors provide sufficient remedies voluntarily. Unless this issue has been raised in the past and ignored, they will be hard pressed to show willful intent to do damage after such actions. > 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. 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. ;) You are the second person to reach this erroneous conclusion, so I guess it deserves say that this has nothing to do with my own preferences beyond wanting to see the code that I contributed used in accordance with the terms under which it has been licensed. > 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. You are correct to say that we are in a competition with closed source. As a result, the proprietary driver deserves to be handicapped. This is an intentional "subsidy" for code that uses Free Software licenses, which is exactly what the GPL licenses were designed to do. This was not an accident; it was very intentional. > 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. 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. I am not willing to turn a blind eye to such violations, but I do not want to harm anyone's business either. Personally, I have no standing claim on past releases, so my principle concern is with 0.2.0 and forward. Moreover, I recognize that these transgressions were probably not made maliciously; however, they will no longer be excusable. I will never permit changes or exceptions to the OpenOCD GPL license. If you are making money from selling products supported by OpenOCD, then you (and other vendors) -- above all others in the community -- need to be contributing to help the libusb and libftdi projects to remove remaining limitations. If its deficiencies posed that big of a problem for your users, you should have 1) fixed them before ever distributing OpenOCD binaries with FTDI chip support or 2) selected a similar tool with a license to which you could comply. If the FSF's own legal interpretation of this license can be defended in court, then you have never had any other alternatives for binary tool distribution. 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. 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. 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. Sincerely, Zach Welch OpenOCD Leader, Pro Forma Corvallis, OR * I am available for hire, and I believe that I can solve some of these problems for you. They will go away if you throw enough money at them. I do not care who gets the work -- just help fix the problems. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
