On Wed, 2009-06-24 at 16:00 +0200, Michael Bruck wrote: > On Wed, Jun 24, 2009 at 13:29, Zach Welch<[email protected]> wrote: > > On Wed, 2009-06-24 at 12:23 +0200, Michael Bruck wrote: > >> On Wed, Jun 24, 2009 at 11:42, Zach Welch<[email protected]> wrote: [snip] > >> 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.
First, thank you! Yours has been one of the most pleasurable threads to engage in among these topics, and you have responded exactly as merited. Second, you win! You presented -- clearly -- the reasonable case for why this should be allowed. I sincerely apologize for taking the contrary view on this particular idea; your points above nailed me to the tree! It _is_ okay to produce a libftdi-ftd2xx wrapper package that is ABI compatible with the open source libftdi. Mea culpa. I am sorry to Magnus, you and the community for this unintentional oversight; I _really_ hope that I did not miss this suggestion from someone else, much earlier in these threads. You now have me second guessing myself on that! There has been too much action, and too many intentions to avoid the GPL entirely. Lacking such clear arguments, I may have shot them down prematurely, but I hope that is not the case. To be truthful, I think my original replies involved my continuing to think about the ftd2xx ABI, its restrictions, and a wrapper for that ABI (which doesn't even make sense, in hindsight). I am very glad that you pursued this matter to its fullest and kept my attention on it in a respectful way, and I am sorry if my earlier messages failed to return those favors. It was after 2am when I got the first message in this thread; it's 8am now. It has been a full day, and my desire to be highly responsive to the community has started to become a double-edged sword at this point. Even as such, you managed to help resolve this. I _really_ wish everyone would come at these issues with the same kind of lucidity as you have demonstrated. So, again, thank you. There is now another option for the community to consider, which is lower hanging and probably more appealing for most distributors. [snip] > > 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. Others have stated emphatically that the specifications are open and available for the developers to take a whack at replacing their library. Unless it is incomplete or inaccurate, the matter should be straightforward enough. :) Heh. I would love to help fix it, but I am constrained in ways that I have previously expressed but will not repeat out of modesty and respect. > > 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. Good idea. Thanks.... Heh, just kidding. I'm fairly anti-patents, given the current mismanagement of that system. Copyright is not in a much better state (e.g. the RIAA), but I am guessing that you are among those that fully understand international copyright laws empower the GPL as much as any other EULA. Things could be worse -- we could have laws banning free software entirely. > > 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. Incidentally, are we talking MinGW32 binaries or CygWin? Which are the required poison? If I had to guess, it would be the former, since the later can include a development environment? This point eludes me. However, I have tried to make their priority clear in other messages. If most users rely on binary distribution, this should be consider a "blocker" for 0.2.0. This is hardly an impossible task. Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
