On Mon, 2009-06-22 at 19:35 -0700, David Brownell wrote: > On Monday 22 June 2009, Zach Welch wrote: > > On Mon, 2009-06-22 at 19:59 +0200, Dominic wrote: > > > > > > Øyvind mentioned the idea of wrapping the JTAG API in TCP/IP. Aside > > > from performance implications I think this would require some > > > significant development efforts with little immediate benefits. Even > > > worse, it would encourage other JTAG interface vendors to implement > > > their JTAG interface layer as a binary only driver that talks to the > > > OpenOCD via TCP/IP layer, too. > > FTDI doesn't see themselves as a JTAG interface vendor though, > and that's part of the problem. :( > > Getting more driver support wouldn't be entirely bad, would it?
I read his statement as being opposed to more binary drivers, since he started his last sentence with the words "even worse". So, yes, I think that some of us think binary driver support would be bad, but I admit not "entirely" -- provided any such solutions are GPL-compliant. ;) > Most of those JTAG adapter vendors are just ignoring OpenOCD > right now. Maybe they talk to GDB through a proprietary GDB > server engine; maybe they don't talk GDB at all. > > We could be presenting a choice between getting GNU tools > support by either > > (a) writing proprietary JTAG engine *AND* proprietary > GDB server engine; or > (b) writing proprietary JTAG engine but *REUSING* OpenOCD > GDB server engine. > > Anyone switching to (b) would necessarily start improving > the OpenOCD code. And they'd likely realize that adding > Linux support -- instead of being Windows-only -- became > much easier. That's in addition to > > (c) propietary JTAG engine plus proprietary non-GNU tools > > Vendors now in category (c) that provide such OpenOCD > engines seem like incremental wins too. But if any of > them do so, I'd be (pleasantly) surprised. I really would be surprised to see the kind of transition that you envision happening actually occurring in real life, without the hand-in-hand support of the vendors. That said, it seems possible, if apparently improbable. > > I am opposed to this as > > well, for the same reasons. This is why I did > > not suggest it until someone else suggested it. I want to see libusb > > and libfdti fixed, > > I think *everyone* wants to see those get fixed. > "How" is open; Duane's WinUSB note was interesting. I agree -- WinUSB looks promising, particularly since support for it has been indicated to be present in SVN builds (if still incomplete). I am all for talking about "how," but I think we are getting past having to explain "why" it needs to be fixed so badly. > > and I do not want to open the door to more binary > > drivers. If I were to implement the TCP/IP interface without pay, I > > would release it under the GPL to prevent this situation from ever > > occurring. At this point, I am tempted to implement it simply in order > > to close this back door to binary drivers. > > It wouldn't work that way at all. As soon as there's a well defined > protocol, it could be re-implemented without using your code. > > There are two ways to take that reality. One is the Microsoft way: > as a threat, to be responded to by ensuring the protocol is always > changing and abysmally documented, so that interop using anyone > else's code tends to be weak in critical areas. > > The other is the IETF/Internet way, to be responded to by making > sure the protocol is well-documented, well-behaving, and evolves > cleanly. This is how we got HTTP and SSL, not to mention TCP in > the first place. I am totally in favor of developing an open standard for this. However, I am not particularly interested in allowing my investment in OpenOCD to be used in ways that effectively circumvent the GPL, which is what I ultimately see becoming the impetus to pursue this design. Since this is being viewed as a viable option, I started to sketch out this module yesterday. I am willing for it to be licensed under LGPL, but I am not willing to do that work for free and see it be used in that way. I would rather submit it under the GPL, and it would be a very sad day to see it rejected because of that license choice alone. Would the OpenOCD community refuse an implementation if one was given, but licensed only under the GPL? [[How would such a matter be decided fairly and conclusively?]] To me, this is where "first mover advantage" comes into play; you want your code in? Then write it first. That said, once it becomes a public protocol... you are totally right. A clean room implementation can provide a FTD2XX driver. I believe some portions of this loophole were closed with the GPL v3, but I have not studied this version as carefully as v2. Since we use v2, it's moot; the proprietary vendors have found their loophole. That outcome seemed inevitable really; it did not take long for the idea to surface either. I can try to bias the OpenOCD code on the side of the GPL, though. So my metaphor about closing the door on this should be clarified. I meant to say that I never expected to be able to shut it completely. I want to make it both easier for people to find the door and simultaneously have to make the decision as to whether or not to try to go through it. I want them to just embrace the GPL, using my baseline implementation. This will make it easier to license drivers as GPL than not, but I could even dual-license my original code to closed driver authors. Clearly, I do not want others to use my work for that purpose for free, but I am not opposed to such use. Someday, I hope to be able to donate such works for free, but I would go bankrupt today. Put simply, I have a house mortgage, and this kind of work should be paying it off. It would be nice to get some confirmation from the existing vendors that they would spend some money on such a solution; however, these folks** have shown more interest in finding a quick contribution-less solution. In general, this behavior seems representative of their virtually non-existent community support resources, but these same vendors are using OpenOCD to generate sales and profits (one must presume). Why should anyone be surprised when I offer no quick fixes in return, beyond my already excessive amount of community support? You get as you give, or so I would like to believe. This plans seems to be the best approach, given my present perspective on the situation. The community should consider that I could have just as well said "no, ask a lawyer". Or, I could have just kept completely quiet and started suing the violators into settlement after 0.2.0 was out. Think about that folks. Clearly, I am not out to screw everyone out of money, or I am doing a very poor job of it. Indeed, I no longer expect to be hired by vendors in this community after taking this stance, so I figure that my ethics have now fully undermined my own potential to profit here. Cheers, Zach ** The singular exception to this observation would be Zylin AS. Interestingly, I think they would accept the TCP/IP driver if it was provided under the GPL, and I think their word deserves additional consideration. Oyvind actively contributes to the community on a regular basis, which puts him leagues ahead of the other vendors in my book. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
