>
> >>/ Ø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.
> />/
> />/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, 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.
> /
> Zach,
> This sounds very contraproductive to me. You have been doing a lot of great
> work but if the maintainers of OpenOCD are not open for solutions that just
> work in a real world you'll find that people (JTAG dongle manufacturors for
> starters) will start to fork OpenOCD in seperate projects which results in
> various versions. That would be a waste of your efforts.
>
> I really fail to see the real world problem when mixing open and closed
> source parts. If you contribute to an open source project you know someone
> will make money with the software you wrote but didn't get paid for. So be it.
>
> Perhaps the best way is to link against the closed source driver until there
> is an open source alternative that works just as well. Closed source drivers
> are going to be a problem anyhow since getting a 64 bit Windows driver signed
> is not free. It is also becoming easier to write software that runs on both
> Linux and Windows. Therefore it is very likely that more open source projects
> will run into similar problems. So 'closing the door' may actually backfire
> in worse ways than you can imagine now. Maybe the GPL license has expired.
> Many bigger projects are published under other licenses like BSD, Mozilla,
> etc or even have dual licensing like MySQL. GPL 3 has seen a lot of debate
> before being finalized. Those are the real signs on the wall!
>
> Nico Coesel
You're right, Nico Coesel.
There is the ideal world and the real world.
One month ago, we, Amontec Team, asked customers to know how many was
working with OpenOCD on Windows and/or on Linux with our Amontec
JTAGkey. The result on 247 users :
- 85% windows
- only 10% use both windows and Linux
- about 95% use FTd2xx driver (on windows or linux).
Before talking too much about GPL issue ... bla bla bla ... we should
ask us some basic questions related to the success of OpenOCD project
itself:
{LOOP}
WHY OPENOCD IS NOW POPULAR (2009) :
- because it is Open Source
- because the initial Dominic's work was excellent (2004)
- because there are a lot of end-users( since 2005)
WHY THERE ARE A LOT OF END-USERS :
- because OPENOCD works on windows since end-of-2005, close to the begin
of OpenOCD
- because easy USB JTAG solutions was provided via FTd2xx as the Amontec
JTAGkey. The FTd2xx was and is faster than libftdi and was more stable.
The FT2232 provide an cheap solution.
- because Yagarto / sdk4arm (MS) was providing an ideal out-of-the-box
for 85% of end-users
WHY A LOT OF NEW DEVELOPERS
- because the OpenOCD project IS popular
{LOOP WHILE OPENOCD IS POPULAR}
I really think the GPL license must be respected , but we are all in the
same world. And this world is never IDEAL as we want!
Is an Open Source project must be GPL at all?
Is OpenOCD installed/used because it is Open Source, because it is GPL,
or because it works !
Also, the FTD2XX is just an important part of the success of OpenOCD !
Laurent
Amontec Team
http://www.amontec.com
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
