Hello Øyvind and the list, Øyvind Harboe napsal(a): > welcome back it's been a while! I hope that you'll stick around > to submit some more good patches. You've contributed lots of nice > stuff in the past!
I am still here, monitoring the forum and I surely also do have future plans to contribute to OpenOCD in the future. > GPL stops closed source target & interface for OpenOCD. Sure, I understand that and I have to say I am not arguing about this. I like open source, it is just I really do not like if suddenly appears someone literally interpreting a legal document making a problem from something which has not been problem for years - I believed that ftd2xx.dll is linked "per design" by the will of the original author, giving me an impression that in such case it is not a license infringement. Anyway, as I noted in my post, it is better to (technically) solve this for good rather than argue forever, I suppose you see it the same way. But we shall not become GPL slaves, solving how to pass literal interpretation of the license instead of pushing OpenOCD further. > That's one of the *main* reasons I got involved with OpenOCD in the first > place. Actually me to, I am not for closed interfaces, and PRESTO is also open. The only closed thing is ftd2xx, a hw driver wrapper with rather trivial API which is mostly the same as OS file I/O API so the discussion about this seems to me a bit ridiculous. Open interface to FTDI chips does not make much sense without the chip itself, noone is going to implement a compatible silicon, that is why I consider ftd2xx as part of the hw and why I see the discussion pointless, bringing no real benefit to the project itself > I also knew that since the project was GPL to start with, it wouldn't > switch to another license once a sufficient # of contributors had signed > up. At least not without *everybody* agreeing to a license change. This > ensures that any license change won't be full of holes. Agreed. Too late, too complicated these days. > I *know* there are hardware vendors out there that > are aching to use OpenOCD together with closed source target support, > and they *would* find any tiny loophole and throw money at lawyers to > exploit it. Actually, this is not what I want. But I also do not like the silly madness about ftd2xx. BTW I like Linux, but what I really hate on it is lack of binary driver interface making many problems with hw compatibility - this is simply not the right way to do it, single word: interoperability. GPL does not mean the project shall not be able to communicate with non-free world and the attempt GPL made to classify "allowed" and "forbidden" ways of communication is far from ideal solution, neither does it guarantee freedom: binary communication over socket may be non-transparent in such a fashion that the code actually is not free (liberty) despite it is open. So this is what I was pointing at in my post: it is necessary to see the the principles of the license, its real meaning, so that we choose the right way, not just a technical workaround which passes the rules. > Now, I *know* you can fix these USB problems with both hands tied > behind your back in your sleep with a modest effort. The acceptable > solutions have been outlined. For sure it's a million times easier for > you to solve this technically than legally. You are right. > You stand out amongst the hardware vendors because you have made > *very* significant contributions in the past. Thank you very much. Personally I do no think it was such a big contribution. Without having the OpenOCD sources I would not have courage to start working on ARM JTAG debug solution, neither I have had time to program it from scratch. That is what I like on open source. Hopefully there will be more contribution from me (or us as company). > How about using the bitq stuff forl a generic JTAG over TCP/IP solution? ;-) Surely possible, but not much convenient, another process running on users computer, however, speed shall not be a big deal, probably a way to go. What I really would like is to separate all the JTAG logic from all low level drivers (if all drivers make use of bitbang or bitq). I am not sure about current status, I have not looked into recent source for an extensive period. On contrary, creating socket bitq interface would make it easier for vendors selling proprietary JTAG interfaces without giving any contribution, they would just implement the other side of the pipe. As you see every coin has two sides - implementing socket bitq would comply with literally interpreted GPL but at the same time, it would undermine its principles. Binary compatible libftdi->ftd2xx is also fine but opposite solution might be even more interesting: reimplement ftd2xx.dll using libftdi, giving a free solution also for other projects which use ftd2xx. In other words to take ftd2xx ABI as a standard and reimplement it to get fully free solution to fully comply with the license. Either way, I like the idea to remove conditional compilation choosing among libftdi and ftd2xx - just a single and clean interface. It is also possible to tunnel communication to/from FTDI through TCP instead of passing it FT_Write() and getting from FT_Read(). Now you see what I meant above and why I see the discussion pointless - this does not make anything better or more free! But this might help people to understand: literal interpretation of GPL, cliche about same memory space does not help to protect the principles and original idea of the GPL - that is what shall be defended. (BTW on an microcontroller without MMU everything is in a single memory space, does that mean GPL cannot be used there?) There has been a political discussion in the Czech Republic about some legal problem some years ago. I do not remember in particular - anyway it was so that the literal interpretation of the law was fulfilled but it was clear to everyone that it was not the way it should be. If in doubt, the way the original author most likely meant shall be considered, not only the way it is literally written and it is the same with GPL. This is why I wrote the post so that people are not just blindly reading the "words" of the license, but try to understand the principles it defends. My belief is that main aim of GPL is to protect GPLed code from integration into a closed project (or a project without compatible license) so that the closed world profits without contribution. However the situation is different here, GPLed code _makes_use_ of a library, without the library being modified for this. Sure there is still problem to tell difference, to judge who actually profits, the line is too thin. One more time: No flame war, I am NOT rejecting GPL requirements, I fully respect the license, I just call for thorough consideration before calling out "This is not GPL! Evil! Kill it!" Best regards, Pavel _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
